next »

[tbkn]

Hi,

Was wondering about the game dev process. Once we have a design document that lists the gameplay mechanics, we need to start getting into the details.
So consider a civ-style game for example. The next step would be getting into the details, define the researched technologies, buildings, units, terrain types, etc.

So my question - what do you forum readers think would be best to do first - design the tools that will be used to create this object, understand the capabilities and limitations of such tools, and then define the objects knowing these limitations?
Or perhaps the other way around - define the objects and their behaviors, and only then design the tools that will be used to create these objects, making sure these tools will be able to support all the different behaviors defined for the objects?

Instinctively I'd say objects first, then tools to match the objects, but then you might create a mess of different behaviors and capabilities that will be almost impossible to create a single tool that supports all those capabilities (and keep it flexible enough to create new ones using the same possibilities).

Thoughts?

[Impmaster]

Once you have a design document, you need to start prototyping. Start building an engine. You will soon realize that some things you can't do due to lack of experience.

[Evan Balster]

I'd generally say understand your spec first and foremost.  In code, that means defining your data structures and interfaces early on.  Always build a version number into any saved data format you create so you can revise it later on.

And as impmaster says, get prototyping as soon as possible.  If you work for months before there's a game to play, you won't know what it is you're really working on or whether your efforts are going to the right place.

[Kekskiller]

The tools are useless if there's no stuff to play with them. Furthermore, you'll have a hard nut to crack if you realize that are bazillions of objects, assets, whatever in some system that's not practical or doesn't match the technical requirements. You'll have to update/rework them while developing and that sucks ass as those making them have to redo all the hard work. The bigger your project becomes the worse the situation gets so better start doing some basic you can step-by-step feed with actual stuff.

[Muz]

Game philosophy
Draft design
Cut out 80% of design
Specs
Protoype
Second design draft
Design docs & roadmap
Tools
Cut out more stuff
Simpler tedious game making work

[tbkn]

Thanks, I appreciate all the help.

So let me just be sure that I understand (this is our first real game...):

Now that we have the design for the concept and gameplay mechanics, I'll start building a simple prototype to test the game mechanics, and populate it with a few basic objects.

Now I'm still not sure how to proceed after the prototype. Should I try to plan all the game content in advance, then create the tools that will be used to create this content? Or should I add some content, test, add more, test more, etc. This way I'll have to update the tools as I go along, and have to make sure the existing objects will be upgraded as well. Which sounds like quite some work...

Any further suggestions?

[soryy708]

I believe in iteration.
This basically means that you implement the simplest thing that works, and then iterate over that.

pros:
- Fast release cycles (everybody sees your progress and you stay motivated)
- Easy to test
- Less disastrous when you get the initial design wrong

cons:
- Requires (a lot of) (at times tedious) refactoring

[nikki]

Or should I add some content, test, add more, test more, etc. This way I'll have to update the tools as I go along, and have to make sure the existing objects will be upgraded as well. Which sounds like quite some work...

I think this route is better.

imagine you writing design docs like crazy, for things that turn out to be NOT FUN AT ALL, you'll want to find out those things asap, and think/test new things.

in other word: iterate

[Gregg Williams]

One of the first steps should be seeing if there are off the shelf tools to do what or most of,what you want. This can save a ton of time, and also give you some limits to design within.