The Design Process

z80 » Design

If you ever asked anyone whose made a successful game, they'll tell you it took months and maybe even a year to make the game. Nothing great comes easy or over night.

There is a process involved in making games. You first start with ideas and progress from there to demos and drafts, then the final edition.

This process is analogous to writing an essay. You brainstorm, outline, draft, and polish. You wouldn't go through all that for a two paragraph essay, would you? No, you reserve that process for larger papers. The same goes for games; this process is only applicable for programs 1,000 lines or more.

Don't limit yourself to these steps, they can be substituted or broken down. These are meant to be a rough guideline. You just shouldn't change the order drastically or skip whole steps.

1. Brainstorming
2. Organizing
3. Code Tree
4. Partial Coding
5. Making the Game
6. Alphas/Betas/Demos
7. Polish and Release the Final

Brainstorming

Don't write anything down yet, atleast not specifics. Just play with ideas right now. The really good ones should stick in your head. That can be a test for what's good and what's not.

Brainstorming is where it all starts, the root of all good in your program, and the root of all fundamental flaws. Keep it simple at this point, you don't have paper to write stuff down on so you should only play with ideas. Think about what type of game you want, your target audience, the language you want to write it in (in this case asm), the time you have to complete the project, what ideas you want to convey on the player, what emotions you want to invoke in the player, etc.

Don't limit yourself. You can do anything you imagine through programs. All it takes is a little time and some hard work. The sky's the limit!

Organization

Put all those 3x5 cards in a pile. Sort them into broad catagories and keep narrowing those catagories down until you can't anymore. Bounce some of the ideas off someone else.

List the basic functions needed for each of those cards (Put Sprite, Plot Pixel, draw Tile Maps, display title screen, and so on).

Code Tree

draw 8 rows
	draw 16 columns
		draw sprite
		increase column and repeat
	increase row and repeat

Keep going over your outlines, each time moving in one more echelon to get more specific. The more specific this is, the easier the actual game coding is.

draw 8 rows
	draw 16 columns
		draw sprite
			get value from level data
			find sprite for that value
			draw 8 rows of sprite
				get byte from sprite image data
				draw byte onto video memory
				increase video memory to next row
				increase sprite data by a byte
				loop drawing of sprite
		increase column and repeat
	increase row and repeat

From here, writing the actual assembler instructions is a snap! You can take a look at the source to see what this outline turned out to be.

Make sure that when you're writing the outline, not to get real deep into it too soon. Keep everything at the same level, then move one more indent into the depth of each level. Then again...

Partial Coding

This would be a good time to get a lot of the debugging out of the way. Test these individual routines in demo programs all by themselves. Try to isolate errors by putting break points.

Take a look at the Clean Code Section for tips on how to make this task easier. Here is where the rest of this Guide comes into play!

Making the Game

Remember to debug as much as possible. The more little stuff you debug, the less your chances are of having a monster bug later.

Again, take a look at the Clean Code Section because here is where the rest of this Guide comes into play!

Look for bottlenecks you can optimize. Try to cut down the size of the program as much as you can. While the TI86 has almost "infinite" memory available, people don't like to wait around for huge programs to transfer from calculator to calculator. You should always want to find the shortest and fastest way to do stuff in all your programs.

Alphas/Betas/Demos

You can release a demo with the core game engine with no frills. This should center around basic game play, no options available.

Do not tell the testers anything about the game except maybe the title. Don't ask them any questions about any of their preferences that might trigger feelings before gameplay. These extra emotions can contaminate their reaction to the game. If you ask them a questions like "Do you like a lot of graphics in a game?", they will be on the look out for that while they are playing the game and may be more critical towards it altering their reactions. You want their unbiased opinion on the game, not what you discussed with them beforehand.

Schedule time to meet with these five Beta testers. Before you do so, develop a questionnaire for them. If you can't meet with these individuals, send them the questionnaire via email. Ask them questions about their overall reaction to the game? How did they like the graphics? Did they like the layout of the game? Were the keys easy to use? Did they like the characters?

Pool their answers and make changes accordingly. It's not too late to redesign things, you still haven't released it yet. If you do decide you need to redesign the interface or something, repeat this step with a new set of testers.

Polish and Release the Final

Create a market for your game. If it has plug-ins, make a handful to get the market started. Be sure to include their source code and thorough documentation on how people can make their own. Maybe include some templates and tutorials for these. Finalize any level editors and their documentation. Release copies of it everywhere. Maybe start some gossip for it like codes and cheats.

Congratulations on your new game. I hope it and all subsequent versions are successful.