Here are my thoughts on the outline.

1. In the section on "Technical Spec" there are some things that you might want to add:

- Designer and artist guidance for asset creation - including poly counts, sizes, texture sizes, naming conventions, etc.

- Solving the scaling problems on the windows platform. 500mz with Geforce 1 vs. 2.5 ghz with Geforce 4.

- Hitting the moving target of new tech - when the hot new card comes, should you care? What happens when marketing forces you to care?

2. Chapter 14 - design issues section - need a section on scripting and dealing with non-programmer programmers. Remember AGIL?

3. Somewhere - I don't know where, but talk about the great/horrible role of the programming team in being the center of the team - no one else sees their ideas unless a programmer implements it (or the system). Horrible athority/responsibility there.

4. Pretending to be Donavon - most programmer need to know this about the graphics systems:

- How it starts and stops
- How resources are built for it
- How the pipeline works.
- What chokes it.
- What makes it go fine
- Who to talk to add stuff
- How to draw debug text on the screen.

Most programmers don't need to know how to write a shader - but they all know that they should not try to shove polys to the screen at the wrong time, or render twice.


5. Chapter 13 - note that making custom tools is as big of a responsibility as a small game itself - you should design it well, track bugs in the database, assign ownership, have an internal team customer/qa person. Ad-hoc it and you are doomed. People are relying on those programs to do their job - treat them as such.



I had more - but I forgot. I'll reread at lunch tomorrow.

You have a lot of Joel's rules. Read the rest. joelonsoftware.com.

One thing that might be cool, and something we here could contribute - horror/war stories of games gone wrong when not following your rules. Anecdotes for each section. "My game was late, so we decided to add 30 programmers and make the QA team add content while releasing demos every 2 weeks."

Yadda yadda. Good outline. Lots of stuff. Too much for one book? Good luck!

Comments for:

Chapter 12, Application Failures
Debate: Code defensively and recover, or fail right away?

I want to discourage using the phrase "code defensively" in this context. The reason is because of Steve Maguire discusses "defensive" programming in his book Writing Solid Code, and I don't think your subject is the same as his. Maguire uses "defensive" in the context of writing code that tolerates coding mistakes, but you're going to write about coding for "application failures", and to me the more correct terminology for that context is "exception handling".

Certainly there can be a lively debate about both defensive programming and exception handling, but I do believe they are separate topics. I suspect that within your topic, you could discuss some of the following sub-topics:

(1) Diligent, manual, exhaustive checking of error return codes on every function, everywhere.
(1a) Deeply nested "ifs" versus "goto cleanup"
(1b) Bool, enum, or int return codes, and techniques for keeping unique error return codes in maintenance.
(2) Set/GetLastError technique, probably combined with actual "defensive" programming.
(3) Compiler-supplied automatically generated EH.

I think an interesting section to have in the book would be something like "levels of the programming heirarchy" in which you go into detail about the types of programmers that exist in the market, what their skills levels would be... and what expected of them.

On one scale would be the fresh out of college student who has a lot of fresh knowledge, but not a lot of experience. On the other end would be someone like Donavon who knows all the answers to all the questions. This is not a linear heirarchy, and so those types of issues might be discussed as well. I think in all of your years of working in the industry, you must have come across a wide range of people and personalities in all fields ranging from coding to art to production and design. Maybe you can put in a blurb about what these people are responsible for so that people interested in getting into the industry would know just what to expect from a person by knowing their title... if it works that way.

Another section on miscellaneous coding advice would be interesting as well. Stuff like place the constant on the left side of a comparision operator to minimize human error. Place some identifier before the names of class members to ease knowledge of whether a variable is a class member or local variable, etc.