GPGT Postmortem - Part 2 of 3 (Project Analysis)

Synopsis
After much deliberation, I have decided to ignore the trend to write a postmortem using the standard 3-3-3 format (three things that went wrong, three things that went right, and three things learned). So, consider yourself warned, this postmortem is a little long.

I am writing this postmortem for the community and for myself. It is my hope that those who read it will be able to take away some useful bits of information.

This postmortem contains the following three sections:

1. History Of GPGT - In this first section of the postmortem I traverse the entire history of this project, highlighting the important events that occurred along the way. The purpose of this is to show how a whim and a hobby can turn into something more serious.

2. Project Analysis - In this second section of the postmortem I will do a detailed analysis of the project, providing a more formal look at the different parts of writing this book. I will discuss such details as schedule, budget, tools, etc.

3. Lessons Learned - In this third and final section I examine some specific things that I learned along the way.



Part II - Project Analysis *** WARNING *** No Pictures, See part 1 for that :) *** WARNING ***


Project Data

Project Name: The Game Programmer's Guide to Torque (GPGT)

Design Overview: Originally, GPGT, known first as the "Essential Guide to the Torque Game Engine" (EGTGE), was intended to be a short (~100 page) quick reference discussing some tools, scripting, and a few tips and tricks.

I intended to have two versions:

- EGTGE Lite (a free version used as a 'loss leader')

- EGTGE Full (a for pay version)

Quote:

---

"This will be a multi-month project, culminating in a guide containing documentation on many significant Torque topics with full references and many accompanying examples. The guide will be fully illustrated and come with an accompanying resource disk. Currently, I have not decided if this will be printed or an e-book."

- Original EGTGE Description From Torque Notes Page

---

Intended Customer: New Game Developers, Veteran Torque Users, Teachers and Students.

Product's Purpose: Teach folks how to use Torque to make games and other products.

Project Start / Finish Dates (Estimated): I officially started writing in November of 2002. I estimated I would be done between June and August of 2003.

Project Start / Finish Dates (Actual): I did in fact start November 2002, but the book did not actually go to press until March of 2006.

Budget (Estimated): None.

Budget (Actual) : By the end of the project I ended up making several purchases related to the book, coming to a grand total of about $2000 dollars.

Release Date: The official (bookstore) release was May 2006.

Release Format: Soft cover (600 pp) with accompanying CD containing 580 (pp) reference, samples, and a lesson kit. The kit was designed to run on all Windows platforms, OSX, and in a degraded mode on Linux systems.

Lines of Code: I ended up writing/generating about 42,000 lines of new script.

Art Assets: > 1000 unique pieces.

Development Software:
- Windows 2000

- Torque Game Engine

- Torque Show Tool

- Open Office versions 1.1 through 2.0 Beta.

- Visual Studio 7

- Paint Shop Pro 7, 8, 9

- Various Flaming Pear Filters

- Milkshape

- GameSpace

- Unwrap 3D

- Audacity

- Fraps

- Hammer

Development Hardware:
- 1.8 GHz Pentium 4 with 1GB memory and a late model nVidia video card.

- Laser Printer

Other Development Materials:
- Book: "Books, Typography, and Microsoft Word: How to Get High-Quality Type for Desktop Book Publishing, Self Publishing, and Print on Demand, or Tips on Type"

- Book: "Print-On-Demand Book Publishing: A New Approach to Printing and Marketing Books for Publishers and Authors"

- Book: "The Self-Publishing Manual"

Known Bugs: About 50 errata have been discovered to date. More details can be found here:

http://gamers.hallofworlds.com/support/gpgt/

, and here:

http://www.garagegames.com/mg/forums/result.forum.php?qf=178

Known Compatibility Issues: There were recently some issues on OSX systems. These have been resolved.

Team Members and Responsibilities:

Edward F. Maurina III - Writer

Teresa Tse - Business Manager


Project Ratings 1 (poor) to 10 (outstanding)

==> How well did the project achieve its goals? 8
I wanted to cover more in volume 1 than was possible due to page constraints.


==> Was the project developed in a reasonable amount of time? 3
No. I was way over estimate.


==> Was this a cost-effective project? 7
I'm still in the negative, but will recover my expenses eventually when my royalty check comes in.

To be completely realistic, if this project were only about making money, then the rating would be a 1. Why? Well, if I considered my time worth only $50/hr (which is low), then 2500 hours x $50 comes to $125,000. It is highly unlikely that I will earn that kind of money from this book. Fortunately, money wasn't my primary motivation.


==> Did development proceed smoothly? 6
The project had many jumps and starts, as well as a few complete stops. It was an enlightening but rough ride.


==> How well did the project meet its estimated budget? 5
Not at all, but then the original budget was non-existent which was unreasonable and unrealistic.


==> How well was change managed during this project? 6
I ended up doing major re-writes of sections of the guide for the following reasons:
- Torque 1.2 to Torque 1.3 transition

- Torque 1.3 to Torque 1.4 transition

- False start on sample game: 'Torque Man'

- Writing while learning



Project Questions

What went right?

1. I learned a lot about the engine and making games. Remember, there is always more you can know.

2. I learned a lot about writing and publishing a book. This is big understatement, but this will become clear a bit later when I discuss some writing/publishing specific topics.

3. I hit the target (audience) sweet spot. I feel that I hit the right level of usability to enable both new and experienced users to benefit from this book.

4. Well received. The book has been well received and looks as if it may be adopted by some universities and colleges as part of their game development programs.

5. Built reputation. The book and associated efforts have helped build my reputation, however humble it may be, in the gaming community.

Note: I joke, but this isn't about humility or vanity, but rather reputation and name recognition. Both of these are valuable commodities if you intend to do business in a distributed environment like the Internet.

6. Is improving Torque awareness. The book has helped and is helping to build further awareness of Torque and the GarageGames community. This is a good thing. For members of the community to have the highest likelihood of success in their endeavors, it is important that they be part of a vibrant community with a constant infusion of new members. The community doesn't necessarily need to grow, but it must not stagnate. The GarageGames community has definitely avoided stagnation.

7. Is helping new users. The book has helped and is helping new users get into using the Torque Game Engine more quickly than would otherwise be possible. Struggling for struggling's sake is no fun.


What went wrong?

1. The project failed to meet its estimated time line. This was due to my lack of experience as a writer and because I didn't (initially) treat the project as a job. I didn't create a schedule or a plan until I was well into the project.

2. The project was way over budget. Again, I had no idea when I got into this, just what would be involved in writing a book, and I didn't plan for any expenses.

3. Art in wrong format for printing. All the art had to be massaged into grayscale. Also, by the time I had to do this, several original pieces were lost and and to be re-produced.

4. The first 'sample' game had to be canceled due to poor legal planning (on my part). Originally, I created a Pac-Man like game in 3D. We later decided that although this was probably safe, it would be better to not take chances. So, we changed the game to 'Maze Runner', which is a pseudo-generic 3D platformer.

5. I assumed that AK Peters would 'magically' produce the index for me. Instead I ended up having to write it at the last moment. Therefore, it was written as an, "I thought you were going to do it? Oh crap!", kind of effort. I think this shows in the final version.

6. Failure to back up data. I didn't back up my data properly in the early part of the project and suffered a complete hard-drive failure in early 2004. I ended up having to use a data recovery service to get the book back. It cost me about $300 to retrieve less that 50MB of data.

7. Insidious and silent content corruption. Early on, Open Office was a little buggy. I discovered this during a review when I found data and images both missing and corrupted. Although I stayed with Open Office, I took steps to reduce the likelihood of a repeat of this issue in the future. Among these steps were: upgraded to latest Open Office version, backed up before, after, and hourly while I wrote, checked my documents at the end of the day for any corruption.

Note: After version 1.1 I never experienced this issue again.

8. Did not use a spell checker until after the technical review. Because there are so many non-English words (i.e. Datablock names, etc.) in the guide, I turned off the spell checker at an early date and never turned it back on. So, although I spell quite well, we did end up having to find a few misspelled words during copy-edit sessions. This was a big waste of valuable time.

9. Technical Reviews were hard work and somewhat unexpected. I learned that you should not count on the publisher to do the work for you. When it comes to writing Technical books, you have to do all the technical editing yourself. In other words, don't expect copy-editors at a publishing house to be capable of catching technical issues with your book. This is your job. This sounds obvious, but when we started the process of reviewing I was still quite naive about which party would be responsible for what part of the review.

11. Too many chapters to review in too short a time for the final technical review. Although we did get through it and there have been relatively few errata, I could have done better. The primary problem is the fact that I ended up doing a final technical review of an entire chapter along with all fixes and re-submissions of art (sometimes) in a single evening.

12. Last minute changes to directory structure of kit caused some mismatches between book and disk. At the very last moment I discovered that in some cases, a zipped file will not extract properly if the path is too long. So, I quickly renamed a few files and directories, completely failing to recognize that this caused a mismatch with some of the 'Maze Runner' lessons.


Hall Of Worlds - For Gamers
EdM|GPGT