Given the demands of today''s gamer, do you think that it is possible to release a game that was designed on the fly (as the game was coded)?

Such thing has nothing to do with the demands of today''s gamers, I''m sorry.


It *might* be possible to make a good game, but it''ll take 10X the amount of time to produce, 20X the amount of stress, development will be totally chaotic and there are 90% odds the game will never be finished (since nobody planned how long the game should be, or how many levels/models/2D sprites it should have, and how much money/time it would consume).

Unless it''s a tretis/pong/breakout clone or some other simple puzzle game.

Having a well-made design document listing everything that has to be done, by who, and in what order will ensure you have a consistent game. It allow you to see the game as a whole, allow you to design a beginning and an end, define clear objectives, check if the game flow is interesting, or if there are too much slow/annoying moments too close of each other, allow you to properly measure how much work the game will require to be done, along loads of other stuff.

Stop trying to find excuses to not write a design doc.

Plus, the brainstorming sections can be lotsa fun if you''re in a team.

Having been part of a game shop that tried to do that not once but twice. I beg you for the sake of everyone involved not to try it. There are enough problems in game development without the burden of not knowing where you are going or how you are going to get there. This is actually a very touchy subject for me. I''m tempted to launch into a 30 page rant on the subject but instead I will leave you with this thought. After that experience I would rather rip out my own heart than allow myself to be placed in that situation again.

imagine the chaos you would encounter when you tried to add in a new feature after already working out most of the game... sure, it might be a neat-o thing that gamers want (and that wasn''t thought up when you started), but if it wasn''t planned for ahead of time it could destroy the integrity of your previous systems. new bugs, new balancing, and much more time added to your development (and then along comes another nifty ad-hoc feature).

I don''t think it''s got anything to do with the demands of todays gamer. It''s more a matter of practicality and efficiency. Designing games on the fly is bad for a number of reasons.

First of all, you''re just asking for feature creep. If there is no design goal for the game, then it never gets ''finished'', because there is no way of knowing when the design goals have been met. You end up releasing your game some time after Duke Nukem Forever gets released.

Secondly, there''s the issue of engine/code design. If you don''t have a pretty good idea what features your game needs to support at the beginning of the project, it''s very difficult to design an engine that you know will support those features. Of course, you could just dive into the coding without any consideration for code design, but don''t be too surprised if you end up with a horrible mass of tangled, hacked up spaghetti code which is slow, error prone, and very difficult to debug or maintain. You are also likely to end up rewriting a lot of code unnecessarily, which is a massive waste of time.

Of course, all games are designed on the fly to some extent. However, if you want to get your game developed with the minimum of hair loss and wasted effort you should aim to meet certain design goals before proceeding to the next stage of development (broadly speaking, don''t start coding the graphics engine until you know what graphical features the game needs to support)

I'm going to go against the grain here, I would say yes. Designing full-fledged design docs, can get boring and can lead you to dump the project altogether when you're done. A DD is usually used for people in a team, so if you have a team that you can pass the DD off too, then it's okay if you're bored, since they'll implement it.

In general the best way to do game design is incrementally. That is you should have an idea of where you want to go, and probably put it down in an outline, but don't flesh it out entirely. Most games end up different than the original design anyways, and you want to be flexible in that you're able to add changes relatively easy.

This isn't to say you shouldn't write out anything nor have a good idea of what you want to do with it. But basically you should start with an outline, fill in the structure, and basically piece it together. Then you have to tweak it until it's good. You'll eventually have to balance it anyways, so why keep it so rigid as to end up with a boring product?

Just my 2c based on my experience

Keith W II

*************************************
Keith Alan Weatherby II
Uhfgood@artoo.net
http://uhfgood.artoo.net
*************************************

[edited by - Uhfgood on December 12, 2003 2:33:44 PM]

If agile development processes continue to bear fruit, you''ll likely see them come into the game design world in about 5 years. At that point, some shops will say goodbye to the design doc and hello to the Fun Card.

ld

It kind of depends on whether you''re burning your own time and money, or a $5 million advance from a publisher.

YES it''s possible,
but you have to use some method
series and improvisation works this way, and year of experimentation in other art has show that there way to do it,

first you have to think about a SIMPLE concept, let''s call it GOBLIN GENOCID, and from this SIMPLE concept get the BASICS
you will need for ex a character, and goblins, we don''t need many kind, one should suffice for BEGINING
now you know you need the character to move, keep it simple
you know the goblin have to move, keep it simple
now think about one way the character attack and one way the goblin attack
set the hit and death condition, and the sight radius of the goblin,
now keep a basic field editor and build simple physics,
now start the code IMPORTANT, keep every aspect of the engine track somewhere and break it into different module (physics module, rendering module etc....)
now look at the small set and plane a time fall

now code everything while trying to keep the time limit

after coding, make map and start a the gamedesign
now try to find good pattern and bad pattern (every case where the game is fun within the simple basics) explore ALL the possibility of the design,
once get it, adjust the design and the engine with variation of the response of the gameplay (speed of the character and the ennemy, place, number, configuration of the map) and keep track of design within these range

once you have test all the capabilty possible and find some little way of fun, add ONE new idea in the design at each step and at each step make some design pattern finding

you will see that something would emerge from the method and sometimes unexpected and original gameplay

this method is also know as the miyamoto method (ex: if they don''t have animated character they use a simple box to eplace it, with a code of color>> red if hit etc... instead of animation, if the game is not fun with that they give up the idea, the story follow the same process)

the main thing is to keep close to the start concept of the game , the most difficult thing is to do step one in general, but toying with even simple mech give LOT idea to improve (make a list to implement them ONE by ONE at each step), and seeing the game growing up is rewardful and keep you passionate since even you won''t know where you going
one principal aspect is that at each step you have a complete design and a finish game, once the game is complex enough then you can release it (when the standard is met)

>>>>>>>>>>>>>>>
be good
be evil
but do it WELL
>>>>>>>>>>>>>>>

quote:

---

Original post by Uhfgood
Designing full-fledged design docs, can get boring and can lead you to dump the project altogether when you''re done.

---

That''s one of the reasons for creating a design doc in the first place!

If it becomes boring, then the idea obviously wasn''t good enough to hold your interest (or anyone else''s) in the first place and if you give up before it''s done, odds are you wouldn''t have the stamina to complete the coding anyway.