The Game Designer's Manifesto

I've been recently interviewing lots of game designers and one of my questions is "what is your game design philosophy?"

I figured if I asked a question like this, I'd better have one for myself ... and it turns out I do. I rediscovered my "Game Designer's Manifesto" in an old notebook and have transcribed it here for you.

**************************************

GAME DESIGNERS MANIFESTO

1. I will be open to good ideas no matter who and where they come from.

2. I will focus on the "moment to moment" gameplay without losing sight of the whole project.

3. I will work out ideas and concepts on paper, in prototypes and in discussion before committing other people's time, energy and effort to work.

4. I will accept that change happens and is neccessary as long as it is not constant and arbitrary.

5. I will strive to lock down the "Three C's" (Camera, Control, Character) as soon as possible and not change them unless absolutely neccessary.

6. I will communicate ideas and changes in design with team members and work with them on how best to execute those ideas and changes.

7. I will play my own game as often as possible during the course of production.

8. I will play other people's games in order to expand my own knowledge.

9. I will always follow a negative comment with a "because" and be open to civilized debate if disagreements arrise.

10. I will provide feedback as quickly and clearly and in person if possible.

11. I will give a positive comment when providing feedback.

12. I will create gameplay that enables and empowers the player towards success.

**************************************************

I hope all you current and future game designers take these points to heart - or are inspired to cultivate your own "game design philosophy."

Are you a responsible game designer?

I've recently been thinking about all the little things that can go wrong on a project and all the things that can be avoided early.

One developer I was talking to was telling me how they lost several days of production time just reorganizing the naming conventions of their files. Imagine being half way done with a project and realizing that you have to go back and rename EVERYTHING in the game? A nightmare.

So I thought of a few things to keep in mind when starting a game in regards to naming files and some other things...

1) Keep it to eight characters if possible.

I can't remember which programmer I worked with told me about this, but he said that any file larger than eight characters actually took up more memory. I don't know if I believe him, but I do know that several programs will only display the first 8 characters leaving you with a file that looks like this:

AirWorld...

AirWorld what? Air World War two? Air World Level five? Air World Enemy one? It could be anything.

2) Come up with an easy to understand shorthand for file names.

Make a consistent legend of abbreviations to name files. Air World could be "Air" or "AW" or even "A" - just make sure you don't create redundant named files. I found it's useful to name things phonetically. If you're not sure about how to name something, think of it like a personalized license plate. "Level Designer" becomes "LVLDSGNR".

Just don't get cute and name things using 8 for "ate" or something like that. Naming conventions are not a puzzle for the other team members to figure out. Otherwise your files will end up reading like the titles of Prince songs.

3) Group files accordingly.

OK, I'm guilty of this one. Having well organized files that separate various design assets is really important not only to you but to your co-workers. Generally organize files by stages of production (concept, pre-production, production) and/or by components of information (level maps, character, feedback) You should always ask yourself, "if I were to die tomorrow, would my team be able to find the results of my design work?"

This, of course, is even more important when creating assets to be used in game. Asset management software like Alien Brain, DevTrack, Perforce and Subversion can make or break your project's production. Pick the right one for you and make sure everyone uses it. And backup files often. (daily if not more!)

Speaking of files, there's one other area that gets neglected by teams during pre-production...

4) For God's sake, get those cheats working early!

Getting your cheat camera up and running early is one of the best things you can do for your production. Not only will it help you develop camera postitioning during grayboxing your levels, but also you can use it to help block out "puppet shows" for cinematics. It's extremely invaluable for creating videos and capture screens for marketing purposes. Remember, other people are going to eventually going to want these kinds of assets and they don't want to play through the entire game to get to that one cool spot in the level.

The same is true for player character cheats. Invulnerability, the ability to "fly" your character around, ammo adds, health adds, money adds, the ability to turn powers, weapons and abilities on and off are very important to get in as soon as possible. Not only does it make it easier for you to play and test your levels, but it allows you to show off your levels in the best possible light when your head of production or that guy from the press comes around.

Make sure your level cheats (the ones that take you from one world/level/location/checkpoint) to another is in early as well and MORE IMPORTANTLY easy to access. Don't make the player/tester have to enter the "Capcom code" just to bring up a level or feature. Make it as user friendly as possible. I know it's something that the final product will never see, but you will be living with this game for a year or two or three and getting around it easily will allow you the time to concentrate on the good stuff like design.

5) Make sure you communicate all of the above to everyone on the team.

It's easy to assume that everyone is keeping up with what you are doing, but make sure that this information is easy to find, easy to read and easy to understand. Just because you ARE writing "stereo instructions" doesn't mean it has to read like them.

Good luck!