"And, in my expierence, Coders get handed out designs that are half done, at best. "Well, this is an RPG, using a system much like square''s Active Battle System, where characters can cast spells, attack, defend, use an item, or a special ability." Great. But there''s a lot of info in there missing. " -ThoughtBubble I''d personally like to here more indepth coverage about this fact. I can imagine that as a game designer,your thought proccess can be totally left of a programmers, if you do not have any programming exp, yourself. I''ve been designing games for a long time, but I am just working on a first actually (very small NES) production with a professional programmer and it''s interesting to hear comments like these. I wanted to start a post to gain feedback from all the programmers and designers to feel out what each side "really" needs in order to be able to work at their maximum level and some suggested solutions and balances to these needs if you could append a post giving some personal insight on this topic, please. I think it would be benificial for all. thanx -Sage13

The most prominant problem is leaving stuff out. While it''s ok to specify stuff later, or only partially spec things out, you have to say so. If you say your battle system will have five commands, then change it to six, your coders will be pissed at you. If you say that the battle system will need to be designed for a variable number of commmands, becaust it will cange depending on time, resources, and inspiration, well ok, they won''t be happy, but they can work with it (designing the code to be loaded from a data file instead of hard coding it for example).

Another good thing to do is to give examples. Sometimes, you''ll just miss things because it seems blindingly obvious. Let''s take powerups scattered around a map in a first person shooter. You''ve finished your design document, and somewhere even have a listing of all the types of power ups. But it never gets mentioned specifically that each level is goin to store the location of the power ups held in it. But you have a sample of gameplay "You duck around another corner, bullets spraying the wall behind you. You can hear your heart beating in your ears, and you''re leaving a trail of blood behind you. Fortunately, you made it into the infirmary. You grab a medkit and patch your wounds, finishing as the enemy comes pouring around the corner." That could be enough to alert a smarter coder to the fact that something''s up.

The classic example I was thinking of was the typical first time designer working on an RPG. For some reason, 9 out of 10 it''s an rpg. So they churn out pages of character designs, hundreds of weapons, hundreds of monsters. The better ones will write out a plot, and listings of all the important locations. And they''ll talk a little about their battle system. And when I get done reading the design I know it has an active turn system, and people in it (though I don''t know how many) and equipment (though shops and treasure chests were left out) and monsters, and a map, but I still don''t know how the active battle system works. I still don''t know how big the map is. I don''t know if the map is devided into small play areas, or simply one huge play area. I don''t even know how you can talk to people, just that you can.

The best design documents I''ve worked with all had a feature by feature breakdown, and had good descriptions of the capabilities of each. They also had a general version, something that explains what it does, and the ''coder version'', something that explains how it works.

Ok, other side, what a designer needs to hear from programmers.

The first thing that I think is important is getting an honest answer to "Can you do this?" Usually, the designer gets a "yeah sure" or "not even going to try" from the coder. The best answers are the ones that are truthful. And I know it seems obvious, but it''s surprizing how often the coders I work with will just toss out an answer just because they don''t feel like working with me.

The next thing that is usually good to hear is honest opinions. It''d sure be nice if someone would actually explain the flaws in our plans. An example of this is in a game where you could fall unconcious, and regain it after so much rest. The problem was that since the players health didn''t change, they''d fall asleep, gain conciousness, then since there health was so low, fall back asleep again in a short amount of time. Obviously not what I''d intended. Since it got caught, it saved us from a later hack to fix, and an annoying play bug.


Well, hope that helps some

quote: Original post by Sage13
I''d personally like to here more indepth coverage about this fact. I can imagine that as a game designer,your thought proccess can be totally left of a programmers, if you do not have any programming exp, yourself.

My advice - get some programming experience. You don''t need to code a 3D engine, but at least try writing some java-script rollovers for a webpage or something. Appreciate how the programming paradigm in general needs a set of concrete and sequential instructions. Perhaps read up on object orientated programming to see how your ideas could be better presented to a C++ or Java programmer. Maybe even code basic mods for Unreal or something like that. Just get a feel for the medium.

Now, an example of my own based on ThoughtBubble''s useful example:
Original spec: "Well, this is an RPG, using a system much like square''s Active Battle System, where characters can cast spells, attack, defend, use an item, or a special ability." Great. But there''s a lot of info in there missing. "

Now, let''s look at how to change this vague concept into a real design...

"Active Battle System" - not everyone has played these games. So, which ones? If you want your programmer to research game design, then be specific. And surely that should be your job anyway. A programmer may not know whether this means real time, turn based, concurrent attacking or sequential attacking, action points or time-limited rounds, or whatever.

"Cast spells" - does it cost mana or any other kind of spell point? Does it drain any other statistic like health or stamina? Or maybe the number of spells to be cast is limited per day, like D+D. How long does a spell take to cast? Does it vary, and if so, what factors are there? Same for mana or other costs. Are there different types of magic? Different target types, different effects... do the effects vary, and if so, based on what factors (eg. caster skill, target defence, random factor, caster level, skill level, spell level...)

"Attack"... is this just a standard attack, or can it be varied? Does it just use one weapon, or can the user use 2 weapons? If so, can they choose between them, or use both at the same time? Both per round or only one per round? How often do you want an attack to hit on average? What about versus an opponent of half your level/skill? Or versus an opponent of double your level/skill? On average, how many hits should it take to defeat an opponent of equal level? And for half/double level? How does armour modify this? Do attacks take different lengths of time, and if so, based on what statistic or factor?

"Defend"... does this simply mean to do nothing, or does it decrease the chance of getting hit, or does it decrease the amount of damage taken, or some combination of the above? Can you specify to use a shield or is that automatic?

"Use an item" - does the item have to be in that character''s inventory, or in a shared party inventory? What kind of items are there that a player would want to use in combat? Potions, staves, wands, etc? What kind of proportion of a player''s health or spell points would be replenished with the average potion? How long does using an item take? Can it be interrupted by an attack causing the potion to be spilled?

"Special ability" - what kind of special abilities will the player characters have? What about non-player characters? Are they only usable in combat? Are they offensive, defensive, or neither? Will some of them require additional input considerations such as button-pressing combinations or multiple target selection?

Hopefully my examples show you just how much more thought has to be put into the system in order to come to a fully specified design. The first concept was almost totally ambiguous. So you need to think through all the details.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]

One thing that would help is for programmers to speak out when the documents they are given are incomplete. It's very simple: either the game is designed by the designer, or it's designed by the team. When the programmers aren't sure of what to do or they feel like they're doing the designer's job for him, it's a sign there's a problem with communication. The designer needs to write more complete designs, do most of the programming work himself, or schedule some meetings with all the relevant people to discuss what's missing. This applies to the designer's interaction with the artists as well, since they too need a good idea of what to do.

Edited by - chronos on March 11, 2002 5:42:50 PM

Its kind of a double edged sword (is that the right phrase? ), on one hand you get freedom to fill in the missing bits ( they wouldnt expect something that wasnt complete!) but on the other-hand if you program something, and its different to how they pictured it, or they don't like it then you are in trouble

The designers should try to fill in everything that is needed for the programmers to realise their designs. Of course this is rarely done, so the best thing I guess is good communication between designers and programmers at every stage.

EDIT : For the first paragraph I was talking from the programmers perspective. oops.

Edited by - stevenmarky on March 11, 2002 5:47:34 PM

Just my thoughts:

A picture speaks a thousand words.

A couple of sketchs/cheap paintbrush mockups of what the game looks like, and I''m not talking about a pencil sketch of an orge or a sword but an actual outline of what the user should see on the screen can go a long way. Even a bunch of labeled rectangles showing where screen elements should be is good.

As with most team-based projects, communication is key. I don''t see how this is any different. Whether it''s comprehensive documentation or verbal exchange, or (preferably) both, I don''t see how this situation is any different. It''s not like even if the designer provided the most complete GDD ever written questions wouldn''t still arise...the point of a comprehensive GDD is to have a common reference from which to build upon as the game evolves...

Just my two cents.

Keep in mind that things like item lists are irrelevant to a programmer.

The programmer shouldn''t care about endless variations of armor, power up placement, etc. The programmer should be writing tools so the designer can design their own maps and place their own powerups. If your programmer is placing the powerups you have problems..

Whether or not your game has 2 kinds of swords or 200 is not really relevant. What is relevant are things the programmer has to specifically program for. For example, maybe a special enchanted weapon has a chance of casting a spell when used. As a programmer that is the sort of thing I care about. Exactly what number you are going to assign as the strength, or what spell it will cast, doesn''t really matter.

This is the distinction between programming and content. Maps, powerup placement, items, those are content. As a programmer I am interested in *rules.* What are the *types of behaviors* an item can do? Can certain types of armor be resistant to certain types of attacks? The *numbers* are not relevant, just the general rules.

quote: Original post by Anonymous Poster
Keep in mind that things like item lists are irrelevant to a programmer.

Not true.

quote: The programmer shouldn''t care about endless variations of armor, power up placement, etc. The programmer should be writing tools so the designer can design their own maps and place their own powerups. If your programmer is placing the powerups you have problems..

Who has to program the powerups? Who has to decide how to animate them, or what to do when they get collected? How much texture memory are they going to need? Can we use a single image for them all and just change the palette, or will they all be different? Are they so common that you need to keep the number of polygons and alpha blending down? Or rare enough that they can look really good? They need to know the variations. They might not need to know the placement but a rough idea will help.

quote: Whether or not your game has 2 kinds of swords or 200 is not really relevant. What is relevant are things the programmer has to specifically program for.

So, a programmer doesn''t have to allocate 200 memory slots instead of 2 when there are 200 swords? What about ensuring the combat system is balanced? And that it doesn''t roll over? What is the maximum damage they can deal, as this will need to be stored somehow. If the maximum damage is 255, that''s one thing, but if it''s 256, that''s something else. That has an effect on implementation. To think otherwise is naive. The designer should think these things through and present them all to the programmer. The programmer will then be able to pick out what they need to know.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]

I guess what is trying to be said is that really, the programmer doesn''t need to know about all the 200 types of sword; just that there *are* 200 types of sword. (Specific, I know.)

The number of people who don''t know what ''game design document'' actually means.. geesh. In future, I''m going to work on the basis that if there''s no design doc, I won''t program. I may still join the project, but I won''t type out a single line of code until there''s a design doc around. They don''t even read the gamedev.net articles, for god''s sake...

Superpig
- saving pigs from untimely fates
- sleeps in a ham-mock at www.thebinaryrefinery.cjb.net