What steps and processes do you go through to refine and create a game? I find that my organizational skills and planning is very lackluster, creating a not very fun development experience. What I normally do is come up with a general idea of what to do and start working on the engine immediately and fill in the details as I go along. I do this because I really don't know what I want the specifics of my game to be at the initial stage but it gets frustrating trying to figure everything out on the fly.

Basically, do you plan everything in advance or just kinda wing it?

I believe planning key aspects in advance helps the most. You don't want to program your battle system and then realize you don't like it. You should think through the general systems, such as combat, movement, etc. ahead of time.


I myself tend to enjoy writing down skills/spells, characters, plots, items, and other pieces of less immediately important information along with the more important things. It's just a matter of personal preference, I suppose, but I think it's best to get new ideas and aspects down in a document instead of saying "oh, that's a good idea, I'll have to add that to the game later" because there's a chance you'll forget it while either implementing the primary systems or developing pieces that you need to have before you can develop your new idea.

What I normally do is come up with a general idea of what to do and start working on the engine immediately and fill in the details as I go along.[/quote]
I did this about 10 times with about 4 engines I re-wrote from scratch each time. The thing you have to think about is from the highest level of any single game list every class you can think of:

class Mesh3D, class Light, class AIController.......Texture, InputController,Event,Sound,AnimationController

When I did this a while back I came up with about 30 or so classes that pretty much would be used in every game. With that you can start figuring out how you want to connect them. Does a Mesh3D hold an AnimationController, or does the AnimationController have a pointer to the Mesh3D. As long as you take an hour or two you can come up with something decent and on paper. Your code will happen a lot faster because you won't have to think of these things on the fly and try connecting things just to make it work. Connect them first how they make sense to you.

I believe planning key aspects in advance helps the most. You don't want to program your battle system and then realize you don't like it. You should think through the general systems, such as combat, movement, etc. ahead of time.


I myself tend to enjoy writing down skills/spells, characters, plots, items, and other pieces of less immediately important information along with the more important things. It's just a matter of personal preference, I suppose, but I think it's best to get new ideas and aspects down in a document instead of saying "oh, that's a good idea, I'll have to add that to the game later" because there's a chance you'll forget it while either implementing the primary systems or developing pieces that you need to have before you can develop your new idea.[/quote]

I did this about 10 times with about 4 engines I re-wrote from scratch each time. The thing you have to think about is from the highest level of any single game list every class you can think of:

class Mesh3D, class Light, class AIController.......Texture, InputController,Event,Sound,AnimationController

When I did this a while back I came up with about 30 or so classes that pretty much would be used in every game. With that you can start figuring out how you want to connect them. Does a Mesh3D hold an AnimationController, or does the AnimationController have a pointer to the Mesh3D. As long as you take an hour or two you can come up with something decent and on paper. Your code will happen a lot faster because you won't have to think of these things on the fly and try connecting things just to make it work. Connect them first how they make sense to you.[/quote]

The more I think about it more and more, it seems like planning would help out a lot =P. Is it just because I don't have much experience in game programming (I've never finished a game engine, let alone an entire game) that I don't feel very comfortable with planning every single large step before I do them?

The problem in starting with a game engine can be tough especially if you are hand-coding your own. The problem with existing game engines is that you have to whittle them down to the experience you want to portray. The problem with starting from scratch is that you have to consider all the features you want and how you want to use them. Both obviously take a great deal of time.

Keeping it simple helps to keep you focused on the general idea and not on the engine itself. Unless you are planning on selling the game engine as a standalone product, there is no need to make your code in anticipation of all the crazy things you can think of. Start with the core ideas, things like who, what, where. Jonathan Blow, in a talk I don't actually remember the link for, mentioned that in creating Braid, he only used class nesting (at most) a few classes deep. He had some sort of Entity class to represent something that was displayed on screen, then most everything worked upwards from there. As you develop, you may notice that your code doesn't support feature X, but if you have kept things very straightforward, it should be almost no problem at all to add it in. The toughest issue I've experienced with that process is I started much too complex and ended up having to add a new class under two others in the inheritance chain. In the end, it probably didn't take me any more time than it would have to do the whole thing the right way anyways. Biggest thing that has changed my coding so far? The knowledge that no one else needs to ever see my code and as long as it works, there is no reason to change it.

It can be really helpful to take a similar existing game and describe it in detail. Then it's easier to identify which parts you need to implement a similar version of in your own game, and for the parts you want to change you should try to write with an equal amount of detail what you want to replace them with.

Why not use a tool like Unity3D to help your prototype? much faster than writing from scratch. I tend to focus on the feel of the game, and write down those aspects so that I can tweak combat systems later, because lets face it, your combat system might work on paper, but it's quite hard to experience the feel of an action game from words.

I think one of the benefits of getting your thoughts down on paper and testing them on paper is that you aren't introducing the necessity of any other discipline. Granted, it all depends on the size or mechanic you need tested, but by introducing code and art to a prototype, you have just tripled your ability to get distracted from the true idea. Then again, I totally agree with BLiTZWiNG that it's very tough to experience the feel of action, and I imagine that certain aspects of your game will remain un-testable until the final product is put together.

I actually "kinda wing-it" I have no idea if I like a new mechanic until I can play it. Then I decide if it should stay, go, or improve. This can only happen if I program the mechanic. I find that only writing down my design for the idea rarely gives me the insight to improve on it. Granted it takes more time, but writing about a game mechanic is like drawing a comfortable sofa, The general look of the sofa does not necesserally reflect it's feel.

I plan everything in plenty of detail for the final game. But when prototyping I give myself a rough list of objectives and then wing it. Personally I find it helpful to come across some of the problems this leads to and helps me learn from my mistakes before it actually matters. And then I can make changes to my design document to help me avoid the issues I uncover when prototyping. Such as not keeping every single one of my variables in my player's Pawn...

That one was a rookie mistake!