This concludes the summary of the Nibbler engine. There is only one glaring point that has been missed:

What the heck do you do with all this crap?

Putting it all together

Let's see...paint program, graphics organizer, level editor, level file grouper, font generator, sound generator, script compiler, C/C++ general purpose compiler, game engine. The tools are all there. Using the tools in the correct fashion is all that it takes to make a professional work. The following list contains prerequisites for using a particular tool.

• Draw or modify bitmap(s) before running the graphics organizer.
• Run the graphics organizer before running the script compiler.
• Run the sound generator before running the script compiler.
• Create or modify levels before running the level file grouper.
• Run the graphics organizer before compiling the main program.
• Run the script compiler before compiling the main program.
• Run the font generator before compiling the main program.

• Modify the bitmap(s).
• Compile the art file (the header file does not change).

• Modify the bitmap(s).
• Compile the art file AND a new header file.
• Compile the NIB-OOL object scripts.
• Compile the main program.

• Modify the level design.
• Change the group spec file info as needed.
• Compile the group spec file to create a group file.

• Modify the CON files.
• Compile the NIB-OOL object scripts.
• Compile the main program ONLY if the changes to the object scripts impact memory storage. For example, the addition or deletion of shared global variables will affect offsets in the memory of the main program, but addition or deletion of local variables will not, as these local variable offsets are created at run-time.

Designing the gameplay

It is not easy to design and debug AI code. General-purpose programming often gives you a cut-and-dry result: it either works exactly the way you want, or it does not. AI programming does not provide this luxury. Only the end user determines whether or not the code "works."

Programmers can debug the code to the extent they think is adequate, but what do they know? Debugging is only really feasible with user feedback, since end users generally stumble across bugs that the designer had not thought about (or did not want to think about).

The following steps need to be performed when designing an object.

1. Get a good idea of the relative size and appearance of the object. One does not actually need the sprite to be drawn to get started, but it helps to have concept art available.
2. Consider the extent that the object will move. If it moves slowly or without changes in speed or direction, less planning (and code) will be required. If it moves quickly or moves in a complicated way, more planning (and code) will be required.
3. Consider how you "want" the object to act. What do you have in mind when you put this object into the game? Will this object interact with only a few other types of object? Or will it interact with potentially all of them? The first version of an object's code should be able to handle only the interactions that you "want" to happen. You can fine-tune the interactions later.
4. Start coding. Try not to deviate from the designs--if you do, your changes will not be flowcharted. If the changes to the code need to be undone, it will be easier to locate the code to take out if the code follows a design on paper. Test and debug the code until basic functionality has been obtained.
5. Now that functionality has been set in stone, enhance the graphics and/or sound programming associated with the object. While it may be tempting to perform this step before step 4, it is generally not a good idea, because potentially large amounts of time and resources can be allocated towards this step. If the functionality needs to be overhauled, it often means more work must also be done with the art.
6. Stop...for now. Work on other objects. Do not get concerned with too many details just yet.
7. Consider the complete functionality of the object (how it will interact with virtually everything else). In reality, this step is rarely complete in most games. Testing and quality assurance can drag on forever to see how every object interacts with every other object.
8. Repeat step 7 until the design is optimal. Of course, nothing is too predictable in AI programming. One may need to return to step 5, step 4, or even step 3 if step 7 finds serious problems in the design. Try to avoid backing into step 3 too much; excessive re-design is often known as "feature creep." Experience should provide insights about a good stopping point.

Closing comments

I have stated that I wish Nibbler to be a "comfortable game" to play. This means giving lots of wiggle room (no pun intended) to the user so that the user can approach the game in a laid-back way. This mentality stresses both good design and quality code. It does not necessarily stress more code, as this is more influenced by complex design than quality design. However, it is a general assumption that the more satisfaction you want from your audience, the more overall code you must write (including code reworked and re-reworked).

But then again, what do I know? Some games out there have worked well with unbelievably simple and even half-assed designs. I will point out that Nibbler, as of writing this, has not been published, so several of the points, both programming and design, have not yet been tested in the real world. The ultimate litmus test is the game's overall performance in a consumer-driven economy. If it works, keep the design. And if it doesn't, rework it.

Carpe diem!