How do I design video games properly?

[TheMassiveChipmunk]

Hello, for the past weeks I have been working on a video game and I always screw up in the design. After realizing my mistake I rewrite a lot of the code. My question is how do I keep this from happening? Could you recommend any tutorials, videos, articles, or books?

[zwA4jE8b]

Do you plan out the game flow before hand. Write out the process, maybe illustrate with charts.

http://www.mediafire.com/?qkaah71i3wd7e

here is a link to our newest game. all the source is there. The graphics still suck but the code is pretty good.
Robo-venger.zip

[chrisname]

Try writing the game engine first. I've not written a video game (yet) but with everything else, I think about the features I need and then write the header files (if the language I'm using has them), then the source files, and then the code that uses them. Often in the last stage I'll realise I needed something else (a new function for instance), but by that point it's very easy to add whatever I need.

I will often rewrite large chunks of code rather than just rework it, because I can't stand having code that I know isn't the best I can write. If I think I can do better, I have to do it, which is partly why I rarely finish my projects :P

With games, I think good practice is to separate the game engine from the game logic.

[edit]
Also, a very interesting and related article I read, proposing a concept called "anti-objects": http://goo.gl/rfn2N

[TheMassiveChipmunk]

@CreativeMFS I like really the game and the graphics do not suck I like them. I guess you are right I should plan out more, I'll start using charts much more.

@chrisname I feel the same way if I wrote code that I see has mistakes, I think it is my duty as a developer to write better code. I have not read the entire article but it looks very interesting.

[chrisname]

The idea of anti-objects seems confusing and radical at first but if you think about it, it does sort of make sense. I still haven't tried using them yet, though.

[hanst99]

With games, I think good practice is to separate the game engine from the game logic.

Yes, but the problem is that you won't know what to put in the engine if you've never written a game before. I think for a newbie it's probably easier to hard code everything at first, and then gradually make parts reusable.

[chrisname]

I disagree, but let's not stray off topic (I try not to do that any more :P).

[zwA4jE8b]

Thank you, and hopefully you find the source helpful. I guess the biggest advice I can give is plan out how the objects will interact with each other. And of course a good game loop is key.

while(!done)
{
  get_input();
  update();
  check_collisions();
  remove_dead_objects();
  render();
}

lol, that is somewhat simplified, but you get the idea

[hanst99]

I'm just talking from personal experience. I had to scrap several projects already because I focused so much on making a single reusable that I never actually got to produce something - the problem was also that it would happen more often than not that I realized that I needed some kind of information in another part of my would-be engine , forcing me to rewrite the interface of whatever I had been wasting my time on before that, essentially turning everything in a giant mess over time. Maybe some people can write a system like that from scratch, I personally need to write prototype code first to get some actual perspective on what I need where, especially if it's something I've never done before.

[zwA4jE8b]

lol, i often experience similar situations hanst99. Luckily I have not yet had to scrap anything.

[TheMassiveChipmunk]

@CreativeMFS I will try to make the program as simple as that.

@hanst99 Thanks for the advice, I will keep that in mind.

[NGen]

My best engine experiences have come from keeping KISS in mind at all times throughout the design process. Game engines are large, complex things with a LOT of moving parts, and you can very quickly get bogged down with the interaction of just a few systems if they're too complex. Keep the API simple, and keep the underlying systems simple.

More often than not, you'll lose a certain amount of flexibility by strictly following this rule. This sacrifice is acceptable most of the time, since overextending flexibility often makes for a complex and verbose API or a framework that has to make a lot of assumptions for you. Remember that the engine you make is one that you're going to maintain and use yourself. If you want to use it in another project, it's often easier (and more efficient) to just modify the engine slightly to fit your needs than to make one that requires more work to configure.

Also, clearly define the responsibilities of each of your systems. When you are unsure of what domain a feature is supposed to exist in, you'll often give systems too many responsibilities and make them difficult to maintain. Another outcome that I'm quite familiar with is a system that nearly duplicates the functionality of another system, just so that it can maintain its own operations. This leads to difficulties in determining when interaction with each system is meant to occur and how the interaction is meant to influence other dependent systems.

Overall, the simplest advice I can give is that it's better to make a flexible paradigm than to make a flexible library.



A book that I might recommend is Game Engine Architecture, by Jason Gregory.

[roberts]

So much of it is trial and error. It's part of the learning process.

I've had to do major rewrites of code for utils that are prep to game development. Eventually, you'll get a feel for it.

The book NGen recommends is highly regarded. If you can swing the cost, get it. I don't have it but want, badly.

[chrisname]

@NGen,
That's good advice, especially since even if your version 1.0 game engine lacks flexibility, it's easier to add than to take it away.

[Computergeek01]

The advice that I want to share is to make incremental backups EVERYDAY! Just copy and paste the source code to another folder (another physical drive would be ideal if you have a spare) under a different file name, saving text is cheap so don't worry about this bogging down a modern HDD. It's important to keep these records to measure your improvment as well as to avoid a major loss in progress due to catastrophic drive failures.

[chrisname]

Source control is also pretty important, since every time you want to add a new feature you can just create a new branch, and then merge it back into the main branch when the new feature is stable.

[BHX]

There really is no set process. Some are majorly thought out and others are just general. I miss the old days when nothing was needed. I remember Crash Bandicoot or one of those first games didn't even have a design doc or anything, they just made it as they went.

[1yR4jE8b]

I bet Crash Bandicoot didn't have 25 Terabytes of assets and history:

http://gamerfitnation.com/2011/09/christophe-balestra-of-naughty-dog-shows-a-picture-of-naughty-taking-up-a-whopping-24-2-tb/

[Gaminic]

Oh for the love of..
Thanks a lot, darkestfright. There goes my week.

<boots Crash Bandicoot 3>

[rapidcoder]

Start from small and simple things and build bottom-up. If you start top-down, as they recommend in many software engineering books, you have 99 chances out of 100 your design will be crap and your code will be a mess.

Additionally: learn to use a good distributed VCS, e.g. Mercurial or Git and then use it. Saves lots of time if you want to "go back in time". And it saves you from accidentally breaking the project.

And the last one, very important: refactor early and often. Don't wait until you have to do a complete rewrite.