RPGDX > Forums > General Discussion > Writing a game in two days?

Not logged in. [log in] [register]

Writing a game in two days?
RPGDX >> Forums >> General Discussion >> Writing a game in two days?

Goto page Previous 1, 2

View previous topic - View next topic

Author

Message

Aptyp
Egg-Sucking Troll Humper

Joined: 09 Jun 2004
Posts: 36

Posted: Tue Nov 16, 2004 6:26 pm Post subject:	[quote]

Teams of dozens of veteran programmers can work on a single project for two years and STILL release buggy code. Did it occur to you that maybe, in context of things, you're actually moving at a break-neck speed? _________________ "Megaton" CRPG: http://www.livejournal.com/users/megaton_game/

biggerUniverse
Mage

Joined: 18 Nov 2003
Posts: 326
Location: A small, b/g planet in the unfashionable arm of the galaxy

Posted: Wed Nov 17, 2004 3:19 am Post subject:

[quote]

Hajo wrote:

Nephilim wrote:

Even if you're a team of one, having some milestones in place and a clear idea what needs to be done by those milestones goes a long way. It helps keep your momentum up (by having achievable goals), it keeps morale high (because you have successes, rather than a long slog), forces you to reconsider "black hole" features, prompts you to think ahead and have a good plan for proceeding, and keeps you focused on the task at hand.

I've usually got a plan. Sometimes like this:
http://www.simugraph.com/forum/viewtopic.php?id=9&t_id=54

And sometimes a more blurry vision like this:
http://h-world.simugraph.com/space/data/space.txt

I'm keeping track of progress:
http://h-world.simugraph.com/news.html

How can I improve this?

Something has to be said for "guerilla development". I have tended to cling to old, fat engines because I put so much effort into them; but what most people here have done is write many, many failed engines, then restart from scratch. This trains you on how to build up very quickly. The idea is that a large, full-featured engine can not be maintained and changed as quickly as a small, fresh engine.

If you can, switch gears and spend a few weeks writing a new engine from scratch based on what you learned from H-World. Call it I-World. ;) You'll see what I mean.
_________________
We are on the outer reaches of someone else's universe.

Hajo
Demon Hunter

Joined: 30 Sep 2003
Posts: 779
Location: Between chair and keyboard.

Posted: Thu Nov 18, 2004 8:54 am Post subject:

[quote]

biggerUniverse wrote:

If you can, switch gears and spend a few weeks writing a new engine from scratch based on what you learned from H-World. Call it I-World. ;) You'll see what I mean.

H-World _is_ the refined experience from a lot of former tries, failures and successes. It's a very nicely structured piece of sofware and way better than all of the old ones.

I'm sorry, but H-World is in large parts the result of what you suggest.

Also, my problem isn't to create an engine, I'm quite good at that. The problem is rather making a game with it. "The Jungle" is a very boring module, noone seems to like it. "Arxigle Xentrophore" is stuck with a lot of design problems, e.g. how to implement research of alien artifacts in a fun way.

I'll not rewrite H-World. There is no need. Also it doesn't make sense to dump three years of works and spend another three years on a new engine. I'd do that if there'd be serious concerns with H-World features or maintainabililty. The engine really is one of the best pieces of software that I've designed and implemneted so far. I did almots 9 months of research and design before I started coding and it includes a lot of experience from my former projects.

Hajo
Demon Hunter

Joined: 30 Sep 2003
Posts: 779
Location: Between chair and keyboard.

Posted: Thu Nov 18, 2004 9:15 am Post subject:

[quote]

Aptyp wrote:

Teams of dozens of veteran programmers can work on a single project for two years and STILL release buggy code. Did it occur to you that maybe, in context of things, you're actually moving at a break-neck speed?

Some people say so. But I don't really have a comparison. I think my strength are designing architecture and structure of programs. I tend to use overly generic and therfore complex structures that sometimes don't pay off because the genericity isn't used and the complexity caused mistakes in the implementation.

One of my current goals is to try to use simpler solutions that still cover all requirements. Simpler solutions can be implemented faster and it's less likely to do something wrong.

I agree with Reiner Dyke that scripting languages really help to speed up development. I'm moving more and more functionality from C++ to Lua - the price to pay is reduced runtime, but i guess it's worth it.

I also need to improve my usage of tools. OTOH I really dislike to pay more than 200 Euros for a copy of Poser, just because I'm bad at drawing human figures. But I noticed that sometimes I underestimate the amount of time savings better tools can provide. The problem is learning new tools. This usually takes a while, particularly complex tools.

Nevertheless I still hope that I can improve some things, do things more efficiently or with higher quality. That's why I was askinmg :) I hoepd someone has an idea that is new to me and helps to improve one aspect of game development.

I'm sorry if I often sound ignorant. The problem is that I'm programming since more than 15 years, and I've seen and tried lot of things. There isn't so much that is genuinely new, and if someone presents his latest discovery, sometimes it's something that is rather old to me. OTOH there always is the danger that I just don't understand the new idea, and think it's just a variation of something old, while it really provides an new edge.

If you think, I just didn't understand the benefits of your proposals, and feel ignored, please forgive me and try to explain again.

E.g. in case of BiggerUniverse suggestion of dumping lots of code and rewriting, I want to answer again:

A rewrite of an engine makes sense if the former engine can be expanded or maintained with reasobale effort.

But often refactoring the existing code is a better solution than a rewrite. Refactoring allows to keep what you did, and get it into a better shape, so that it becomes extensible and maintainable again. I agree that sometimes something is beyond reapir, in that case it must be created newly. But usually refactoring is the better solution:

http://www.refactoring.com/

Nephilim
Mage

Joined: 20 Jun 2002
Posts: 414

Posted: Thu Nov 18, 2004 5:45 pm Post subject:	[quote]

Sounds like this might be the sort of thing you are looking for: http://www.extremeprogramming.org/

Hajo
Demon Hunter

Joined: 30 Sep 2003
Posts: 779
Location: Between chair and keyboard.

Posted: Fri Nov 19, 2004 8:28 am Post subject:	[quote]

Nephilim, you didn't check my link collection on my homepage, did you :) http://www.simugraph.com/en/links.html Xtreme Programming: Their ideas are really good. I can recommend the site to every serious OO developer. Even if you don't plan to do strict XP, the ideas will help to improve your existing software development process. E.g. the "write test first" paradigm is really helpful for anyone. It forces you to think about what you expect from the code before you write it.

MyNameIsJeff
I wanna be a ballerina!

Joined: 24 Sep 2004
Posts: 22
Location: Nebraska, United States

Posted: Fri Nov 19, 2004 11:10 pm Post subject:	[quote]

I once made a game in two days for a contest, using VERGE. It was actually a joke.. but it got second place. I guess I'm just that cool. http://hov.verge-rpg.com/games/thorny.html _________________ Guile says: Go home and be a family man.

DeveloperX
202192397

Joined: 04 May 2003
Posts: 1626
Location: Decatur, IL, USA

Posted: Tue Nov 23, 2004 11:28 pm Post subject:

[quote]

Hajo wrote:

biggerUniverse wrote:

If you can, switch gears and spend a few weeks writing a new engine from scratch based on what you learned from H-World. Call it I-World. ;) You'll see what I mean.

Hajo: I'm afraid that you completely missed biggeruniverses point entirely.

He didn't tell you to REWRITE H-World.
He told you to write a SMALLER-SCALE engine, in 1 day, or 2 days.

Not to write a massive, OOP engine that can be reused for many projects, write a simplistic engine that is to be used for a single project. THAT is how to achieve a game in 2 days.

Sorry, I read your reply, and couldn't believe that you thought he wanted you to rewrite H-World.
If H-World took 3 years to create, it would be completly insane to attempt to rewrite it.

The whole point is to create a game in 2 days, as the name of this thread states.

You need to think on a SMALLER scale to finish a game in 2 days.
My problem with finishing Dream Destroyer in time for the autumn contest, was I had NO tools, nor had I ever written a pixel-scrolling engine before.

If I had stayed with the original design:
tile*tile scrolling, non-animated sprites, 100x100 maps, and 2 layers, I could have finished in the first day.
I made the mistake of listening to my team complain about no animation, and how smooth scrolis the only way to make a good game. I should have told them its my game, and that it will be how I say, and I am 100% positive that I would have completed the game.

I had to develop a map editor, and I also developed a scripting language, compiler, parser, and editor.
I should have hardcoded the events, instead of using a scripting language, and I should have used an available map editor.
_________________
Principal Software Architect
Rambling Indie Games, LLC

See my professional portfolio

Hajo
Demon Hunter

Joined: 30 Sep 2003
Posts: 779
Location: Between chair and keyboard.

Posted: Wed Nov 24, 2004 9:02 am Post subject:

[quote]

DeveloperX wrote:

He told you to write a SMALLER-SCALE engine, in 1 day, or 2 days.

...

The whole point is to create a game in 2 days, as the name of this thread states.

Ok, the thread title is misleading. I don't want to create a game in two days. I was looking for ways how to speed up development. I thought I could learn from those who managed to write a game in two days how to do things faster.

I've said this alread in my former replies. I'm sorry the the reason and aim of my question wasn't understandable :(

Writing a new engine will not speed up development of H-World (or any of the modules in progress). That's why I wrote such a harsh reply.

I'll try to word my questions more precisely next time.

biggerUniverse
Mage

Joined: 18 Nov 2003
Posts: 326
Location: A small, b/g planet in the unfashionable arm of the galaxy

Posted: Wed Nov 24, 2004 9:19 am Post subject:	[quote]

Well, part of what I was getting at was that big/complex/feature-rish engines change slow, and that can't really be helped. There are too many interdependencies, and too much regression testing that has to happen. I believe they reach a critical mass where they are either done, or must be abandoned. EDIT: even with refactoring. _________________ We are on the outer reaches of someone else's universe.

Hajo
Demon Hunter

Joined: 30 Sep 2003
Posts: 779
Location: Between chair and keyboard.

Posted: Wed Nov 24, 2004 10:24 am Post subject:

[quote]

biggerUniverse wrote:

Well, part of what I was getting at was that big/complex/feature-rish engines change slow, and that can't really be helped. There are too many interdependencies, and too much regression testing that has to happen.

I believe they reach a critical mass where they are either done, or must be abandoned.

EDIT: even with refactoring.

I agree. But it's also a question of design. I hope the design of H-World is good enough to allow some more years of expansion before it runs into trouble. Of yourse you can't judge this because you can't look into the code.

I'll try to explain what happened so far, and what's my impression of the current state.

Simutrans is my other big project. My biggest at this point of time. It has a quite large base of players (we have about 15.000 downloads each month) and it is rather old (started in 1997):
http://www.simutrans.de

Simutrans code quality is definitely worse than H-World. I started it 1997 as an OOD/OOP training project. In the meantime it grew to ~70.000 lines of code. Since early 2000 there is a team working on Simutrans, but the team members changed several times since then). Three times we (=the development team and of the long-time fans) discussed if we should continue or rewrite. The decision always fell in favour of continuing. Interestingly the bug rate has dropped lately. A lot of the code became very stable and rarely has to be changed. New features are added on top of the old code. I think one of the keys to success was the continuity of developement and the well-defined core, that still exists and of course influences the structures of all newly created modules.

H-World was built with the experiences of creating Simutrans, working on Iso-Angband, from a former (unnamed) try to create a RPG and some other of my toy projects. Of course the experiences from my daily work also helped a lot.

Overall the class structure of H-World is much cleaner and easier to expand than Simutrans. I've learned lots about OOD and OOP in the past years and I could avoid some designs that turned out to cause problems in Simutrans later stages of development, due to their rather rigid nature.

The worst part of H-World is the UI library, particularly the event handling. There are some hard-to-find bugs in there that so far resisted several tries to extinguish them. This is a candidate for a redesign and rewrite.

Compared to Simutrans, H-World is small and very clean. The fact that Simutrans still can be expanded, and that the bug rate dropped instzead of grewing with the amount of changes and code written makes me confident that H-World will have a prosperous and long life.

Now, what am I looking for? Basically it condenses to this:

How to implement more features in less time while keeping the bug rate low, and expandability high.

Supportive goals are making the code well readable (e.g. new team members should be able to become produictive quickly, and the will have to read lost of the existing code) and well testable (a feature that can't be tested easily is a pain if it gets broken for some reason).

I'm looking for measurements to reach those goals.

What am I doing already?

Design:

- Using UML to lay out the structures and relations in the early stages of the project.

Code quality:

- trying to structure my projects in layers, while lower layers may not access higher layers (unidirectional dependency)
- trying to use information hiding to it's very best
- trying to use interfaces (aka abstract classes) to separate components and keep components exchangeable
- using design patterns (look for the book "Design patterns" by Gamma et. al. for a start)
- optimize only that parts fo the code that are time critical, try to keep readability high by avoiding "obscure", "clever", "cool" or other non-intuitive implementations

Project structure:

- externalizing all game data into human readable files (text files) or at least well known formats (PNG images)
- using a scripting language (Lua)
- seperating engine and game modules strictly, define interfaces between them, try to keep the interfaces minimal

Project Management:

- using CVS to be able to revert changes, also to enable the project for teamwork
- using CVS to be able to work on branches in later stages of the project
- keeping logs of past changes and todo list fo planned changes

Ok, now that's what I'm doing to keep the project in a good shape. Now your suggestions what to improve :)

One weak point is probably my usage of tools. Using emacs to write code, GDB to debug and a selfmade painting tool is probaly not the epitome of efficiency todays?

What else could I improve?

Mandrake
elementry school minded asshole

Joined: 28 May 2002
Posts: 1341
Location: GNARR!

Posted: Wed Nov 24, 2004 1:58 pm Post subject:

[quote]

Quote:

I agree with this. Any sensible language is like programming through sludge. The code-compile-debug cycle is a long and slow process. This is why we have scripting languages. Anything that needs to have minor, frequent changes should be tweaked with a script rather than the original code. It could cut down on the time spent doing this drasitcally.

Quote:

I believe they reach a critical mass where they are either done, or must be abandoned.

I'm not so sure I agree with this.

Quote:

Overall the class structure of H-World is much cleaner and easier to expand than Simutrans. I've learned lots about OOD and OOP in the past years and I could avoid some designs that turned out to cause problems in Simutrans later stages of development, due to their rather rigid nature.

The worst part of H-World is the UI library, particularly the event handling. There are some hard-to-find bugs in there that so far resisted several tries to extinguish them. This is a candidate for a redesign and rewrite.

Be careful about this- make sure your redesign/rewrite doens't affect (even though it probably will) other aspects of the code you have working too drastically.

Quote:

How to implement more features in less time while keeping the bug rate low, and expandability high.

Scripting is the best way to accomplish this. You can try out new ideas, keep it in a sandbox, debug faster (no compile, debug bottleneck, just code-debug) and makes it easy to expand (by just adding more scripts). I think the best way to do this (from IMHO) is to create a sort of run-time library for scripts that can be changed on the fly. Sort of like how .dll's work, or CORBA is supposed to work. But with the added feature of being able to swap scripts easily. Want to change how combat works? Just change the script it's pointing to. Want to try a new AI your not so certain will work? Write a script for it. If it needs to be sped up after debugging, move the code over to plain C/C++. It makes for a great sandbox.

Quote:

Supportive goals are making the code well readable (e.g. new team members should be able to become produictive quickly, and the will have to read lost of the existing code) and well testable (a feature that can't be tested easily is a pain if it gets broken for some reason).

You can always rewrite the structure of code without rewriting the underlying code itself. I plan on doing this with Freya. Probably this weekend sometime (that and work on the combat/starting anims of the Changeling....). The code right now works, but is a quick hack. I want to get it so that I can easily port Freya to other scripting languages (like Ruby, Python and Javascript), and with the hacked on nature of the code- this isn't easy. I plan on modularizing it and turning it into a library.

Quote:

- Using UML to lay out the structures and relations in the early stages of the project.

Always a good idea.

Quote:

- trying to structure my projects in layers, while lower layers may not access higher layers (unidirectional dependency)
- trying to use information hiding to it's very best

I know information hiding is good OO practice. But, in C++ it's bad coding practice. Sometimes what makes sense in an OO sense doesn't in the actual code. A good design pattern gets rid of the need for information hiding.

Quote:

- trying to use interfaces (aka abstract classes) to separate components and keep components exchangeable
- using design patterns (look for the book "Design patterns" by Gamma et. al. for a start)
- optimize only that parts fo the code that are time critical, try to keep readability high by avoiding "obscure", "clever", "cool" or other non-intuitive implementations

The problem with this is when you get into the debugging phase after a first release and a lot of people use your project. It's hard to keep bug fixes readable and intact, and still have them work. Sometimes you need to cludge. Working code that is ugly is far better than pretty code that is broken.

Quote:

- externalizing all game data into human readable files (text files) or at least well known formats (PNG images)

XML is good for plain data. Lots of lib's out there make it very easy to read/write XML in a cross platform manner.

Quote:

- using a scripting language (Lua)

Good plan.

Quote:

- seperating engine and game modules strictly, define interfaces between them, try to keep the interfaces minimal

Another good plan, but sometimes you might need to break this. Just be prepared for a day when that might happen.

Quote:

- using CVS to be able to revert changes, also to enable the project for teamwork
- using CVS to be able to work on branches in later stages of the project
- keeping logs of past changes and todo list fo planned changes

From my experience, SVN is far superior to CVS.

Quote:

One weak point is probably my usage of tools. Using emacs to write code, GDB to debug and a selfmade painting tool is probaly not the epitome of efficiency todays?

What else could I improve?

Emacs is nice, depending on how you use it. On Linux, I perfer Vi. GDB is a good way to debug, but another good thing is to have a debugging class (that uses the debug macros) that anything can inherit from (using multiple inheritance) at any time. This can make tracking down bugs easier. Self made painting tool? If you on Linux, use the Gimp. Unless, of course, there is a specific setup that makes it easier to use your own painting tool.
_________________
"Well, last time I flicked on a lighter, I'm pretty sure I didn't create a black hole."-
Xmark

http://pauljessup.com

Hajo
Demon Hunter

Joined: 30 Sep 2003
Posts: 779
Location: Between chair and keyboard.

Posted: Wed Nov 24, 2004 3:21 pm Post subject:

[quote]

Mandrake wrote:

Quote:

How to implement more features in less time while keeping the bug rate low, and expandability high.

I agree fully on this point. Lately I'm moving some existing functionality from C++ to Lua and most of the new features are made as Lua scripts. Somehow Lua is much faster in coding and debugging than C++

Large parts of the AI in H-World are lua scripts and large parts of combat also (see scripts/attacks.lua and scripts/ai.lua)

This way module writers can easily plug in their own combat and AI implementations.

This is the first time that I'm using a scripting language to a larger extend and it's really marvelous :)

Quote:

I'm really curious if and how this will work. I wish you good luck and much success!

Quote:

I tend to agree. I'm mostly a Java guy, doing my private projects in C++ mostly to keep my C++ skills fresh. But I often code C++ like Java and this doesn't work well.

Which design pattern do you refer to?

Public members still seem to be harmful. I know there are strategies to minimize the public interfaces of objects. Do you mean something like that? I agree that it's a very good idea to minimze the public interfaces, although sometimes very difficult.

Quote:

Working code that is ugly is far better than pretty code that is broken.

I think I agree, although ugly code will follow you in your nightmares. But I agree you can fix things now, ugly, and clean it up later. Just don't forget to clean up?

Quote:

XML is good for plain data. Lots of lib's out there make it very easy to read/write XML in a cross platform manner.

From my experience, SVN is far superior to CVS.

I agree. The reason for my choice of plain text and CVS is rather simple: I don't upgrade my systems often. XML and SVN is just too new :)

Btw, dou you know a lean XML parser for C/C++ that can be used in potentially commercial closed source projects?

Quote:

Self made painting tool? If you on Linux, use the Gimp. Unless, of course, there is a specific setup that makes it easier to use your own painting tool.

My oldest project that still lives, started 1992:
http://www.simugraph.com/drops/

I need a bigger HD. GIMP just doesn't fit into the remaining space. My equipment is rather old. Buying a new HD is not the problem, but I can't install another one, and I'm too lazy for a copy and reinstall action. On the first HD I have Linux/Window on the second a BeOS system ... CD-Rom and CD-RW taking up the other two IDE ports. None of Window or BeOS survice a move to another HD without a reinstallation :(

Mandrake
elementry school minded asshole

Joined: 28 May 2002
Posts: 1341
Location: GNARR!

Posted: Wed Nov 24, 2004 3:58 pm Post subject:

[quote]

Quote:

It's a combination of things. I find Lua faster to code in because it's very much like LISP, in the fact that it involves implementing and processing lists of things (ie: tables). It also gets rid of the compile-debug-code cycle that can make coding in C++ much longer. Esp since I do all of my coding on a 350mhz pentuim- compiling is long and slow.

Quote:

I'm really curious if and how this will work. I wish you good luck and much success!

Well, right now I have everything as wrappers to Lua with very few functions not directly connected to Lua. What I want to do is create C++ *mirrors* of the current Lua functions. This way, you can wrap the Lua stuff around an already working C++ implementation. Or you can wrap a Python one around it. SWIG makes this even easier, it can just parse through a .h/.hpp file and create bindings for you. Of course, unlike most SWIG users I won't like SWIG creat the Garbage collection routines for my objects, but instead do what I'm doing now and use my own (faster) GC routines.

Quote:

Which design pattern do you refer to?

I'll have to look it up.

Quote:

Public members still seem to be harmful. I know there are strategies to minimize the public interfaces of objects. Do you mean something like that? I agree that it's a very good idea to minimze the public interfaces, although sometimes very difficult.

It's only harmfull if it's data that needs to have specific bounds. If it's just an int, why not make it public? If it's an int that needs a certain range, sure, wrap it. Or if it's a pointer, wrap it. But some things a wrapper might be an overkill and information hiding might not be the way to go.

Quote:

I think I agree, although ugly code will follow you in your nightmares. But I agree you can fix things now, ugly, and clean it up later. Just don't forget to clean up?

Actually, what I meant was code it nice now, but realize at some point some things might have to get ugly when fixing bugs. Sometimes, putting in a bug fix means breaking prettiness.

Quote:

http://sourceforge.net/projects/tinyxml/ TinyXML uses the zlib/png license, which will allow you to do just that.

Quote:

I need a bigger HD. GIMP just doesn't fit into the remaining space. My equipment is rather old. Buying a new HD is not the problem, but I can't install another one, and I'm too lazy for a copy and reinstall action. On the first HD I have Linux/Window on the second a BeOS system ... CD-Rom and CD-RW taking up the other two IDE ports. None of Window or BeOS survice a move to another HD without a reinstallation :(

Why not just put in an external hard drive? If you format it with FAT32, all of the other OS's should be able to read it.
_________________
"Well, last time I flicked on a lighter, I'm pretty sure I didn't create a black hole."-
Xmark

http://pauljessup.com

Hajo
Demon Hunter

Joined: 30 Sep 2003
Posts: 779
Location: Between chair and keyboard.

Posted: Wed Nov 24, 2004 4:27 pm Post subject:

[quote]

Mandrake wrote:

Quote:

One thing that is often forgotten: getters and setters make it easy to attach an additional action on reading/writing the attribute. This is particularly interesting for writing, if some component needs to be notified if the value changes. (E.g. if you want to implemnt the "observer" pattern)

Another point: Debuggers can set breakpoints to functions easily and efficient, but watchpoints (check a memory location for a value change) slow down program execution a lot which can make debugging almost impossible. Thus having getters and setters helps debugging.

A while I was very strict and used getter/setters always.Lately I start to have some attributes public, but I'm quite careful. Maybe I've read too many OO books :)

Quote:

Actually, what I meant was code it nice now, but realize at some point some things might have to get ugly when fixing bugs. Sometimes, putting in a bug fix means breaking prettiness.

Code erodes. Each change will damage the code a bit, blur the intial idea and obfuscate the design.

That's where refactoring kicks in. If many changes damaged the code too much, it must be refactored and brought into shape again.

XP (extreme programming) has developed the term "code smells" - programmers get a nose for rotten code, but often are afraid to touch it an clean it up. XP tries to take measurements to force refactoring of rotten code.

Quote:

http://sourceforge.net/projects/tinyxml/ TinyXML uses the zlib/png license, which will allow you to do just that.

Thanks :)
I'll take a look. I think I'll keep the current config file syntax for H-World but XML surely has a place in my next project.

PS: an external hardrive could be a solution, but my comp has no USB interface, and buying a SCSI drive nowadays doesn't seem to make sense, since my next computer most likely will have USB but no SCSI controller.