Just edit the one you were logged in for to say, "anony post was me!" Save work for our fine moderators.

Design just happens

When you can´t sleep at night, when you´re drawing lil spaceships on napkins it´s time to do a game.

It´s kinda like the ideas accumulate in your head, and when they have reached a critical mass they come out, and then i scribble piles of paper full of stuff (whatever game i´m doing). And after that pile is done, there´s usually something useful in there.

And teaming up helps. If the other asshole says your greatest idea is so-so and could need improvement don´t kill him. Multiple desingers are a lot of fuss, but when everyone has a say the outcome is much better. Everyone should be a part, from the artist to coders to musicians.

Good ideas are too precious to waste. And you can even use some o fthe bad ideas to refine some good ones....

Doesn''t Mr Miyamoto say that he plans the main characters abilities first and then designs the game around them. I think this is a key to good design for 2 reasons. First, games (hopefully) are as interactive as possible. If the player isn''t interacting, then they''re not a player, they''re a viewer. This has got to be the root of all design or one must question if they''re out to make a good game, or a nice graphics demo. You all read Next Generation a few years back when Chris Carter was talking about giving the players ''verbs, '' and letting them communicate with the game, right? Secondly, as a programmer, the interaction between player and environment is certainly the most difficult thing to program. Anybody can draw a hero and a potion on the screen, but what happens when the hero takes the potion? .. Can he take it? Does this trigger a script? Is the inventory full? How do we add to the inventory list? How is the potion used? Does it have limited, or lasting effects? remember not to draw the potion to the screen anymore... If the actions of the players, and the abilities of the game objects are all well defined in the beginning, then the rest of the development is loads easier.

Most everyone else here seems to do a lot of planning before actual coding. That is probably the most sensible, intelligent way to approach design, but... I dunno... I can''t do that. I mean, I try to plan ahead enough to avoid conflicts (I say that today as I begin re-writing my entire terrain LOD algo). I don''t like thinking ahead too much about cool little features of, say, weapon terrain-deformation, when I haven''t even started implementing weapons. Actually, it''s not that I don''t like having a ''master plan'' in advance; it''s more like I never end up sticking to it.

An idea that occured to me recently was to use message boards like these as a kind of Virtual/Intelligent Game Design Scrap Book. It''s not a bad idea to print out some of these theads and staple them to your physical scrap book.

Note: Gotta get myself some more paper for printer :-)

I hope i didn''t offend anyone!

Here's a thought: studying. Knowledge is an extremely valuable tool for the designer. As programmers we often spend time studying technical documents, but as designers we often proceed without much guidance. There's lots of valuable information available, a great deal of it useful to game designers. We should study not only game design, but anything and everything relevant to the game we're making. Knowledge of subjects like physics, psychology, history and philosophy can all be extremely useful to us as designers. When doing a game involving fish, for example, a biology textbook on fish behavior may prove extremely useful.

Such knowledge is a great deal useful in designing original, realistic new games. Instead of relying on some other guy's design for inspiration (basing your game on other people's ideas), rely instead on your own studies (which may, of course, involve knowledge of existing approaches to particular subjects or situations).

It's a lot of work sometimes, but I think it's worth it.

Edited by - chronos on June 24, 2000 9:17:04 PM

When I get an idea for a game, or program, I normally flip it around in my head for a good bit of time. (I do this with problems as well, like programming ect.) Once I work and re-work the idea in my head for a while I try and scope out more stuff in my head, like how I''m going to accomplish the task and such.

When my brain is pretty tired and my hands are eager to type away some code I start to flesh out the design on paper in pencil (remember pencil). Once the design doc is piling up and looks finished I start to read it over.

I read over the document a few times fixing any errors or mistakes I might have made, without altering the original concept, ect. When the document looks perfect, I reach for s good ol'' Bic ball point.

I re-read again and trace over the good ideas, with the pen of course, that I want to keep and seem to fit perfectly. This kind of sets the "don''t touch" look to it. That''s mainly so I don''t mess with a good idea.

What is left in pencil, I leave to be changed later when the time comes. If the pen absolutely has to be changed, I reach for white out.

............
Guardian Angel Interactive

Intoxication is a big plus in my books. But it depends what style of game I''m making. I generally find it best to sit around and do a lot of research into the type of game I''m doing, the type of setting it''s in, the characters. This can range from reading books, playing similar games, television documentaries and other such garbage. I try to get stuck in the world of the game that I''m making and then just write down anything that comes to mind and clean it up when my creative mind has been sapped for all it''s energy.
Still, the largest part of my design process is research.

As someone who has messed around with game design for many years (not just computer games, but board games, card games, etc), I am a big fan of writing everything down. Generally I start off writing down all the little ideas, brainstorming and putting on paper anything that initially sounds neat, or seems to fit the game. This can be anything from different types of weapons, to twists in the plot, to the setting, to a certain C++ method that would be neat to put in a game.

The second stage, once the initial idea rush dies down (although it never stops, so I carry a notepad with me to make such notes on... never forget these ideas!), I go through all these notes, and try to compile them into some sort of orderly fashion. Plot/story on one page. Characters on another, objects on a 3rd, special implementation decisions on the 4th. These quite often degenerate into lists of ''item/attribute'' pairs. The aim here is to categorize similar entities and flesh them out. Also, reject any incompatible ideas, and perhaps add new ones.

Thirdly, I switch the coder brain on. Some of these lists are basically lists of C++ classes, or a list of data to load in. So I start making mock classes for the entities, such as characters, objects, locations, etc. I usually work in some of the implementation details here.

Fourthly, I add all these prototype classes to a basic Visual C++ project, which includes several of my basic classes, such as my tile engine, or a DirectSound module, etc.

From that point on, it''s a case of ''joining the dots'' and meeting self-imposed milestones.

And I''ve never finished a game yet. So ignore everything I just said