How was Game Programming Gems 8 developed?

By Adam Lake (Intel) (2 posts) on September 9, 2010 at 1:39 pm

This is a little bit different than writing an entire book on your own. A better analogy is working on a large one year software project with a team of developers. In fact, there are many corollaries with software development and writing, but that’s probably best for a separate article.

In this blog entry I’ll go into a bit of detail on the stages listed below.

1. Call for Gem abstract
2. Abstract Submission, Routing, and Selection
3. First draft
4. Final draft submitted to Section Editor
5. Editor(s) take ownership of all content
6. Code review and CD Content Submission

1. Call for Gems
It starts with the editor issuing a call for Gems. In my case, I worked with the publisher to put together a website for submissions and fanned out to a few venues to advertise a call for articles with a pointer to the website for submissions. I also leveraged contacts throughout the gaming and graphics community to pass the word that we were accepting submissions. Additionally, I began looking for section editors at around the same time. Section editor selection is tricky. Essentially, this is a Senior Project Manager being a known expert in their field. They need to be experienced in writing, have a proven track record of getting things done on time, be communicative with the other editors and authors, have good organizational skills, and experience with the various personalities and problems that inevitably arise when working on such a project. I was just incredibly lucky to have some of the best and brightest in the industry volunteer their time to be section editors.

2. Abstract submissions, routing and selection
As Gem submissions come in, I route them to the appropriate section editor. Sometimes, the submissions are routed based on how the author classified the work; other times I send them to multiple section editors to discuss the best venue. Submissions can influence the chapters of the book based on the quality and number of submissions. One example is that this year we wanted a specific section on General Purpose Programming on GPUs because this work is transitioning from academic research to be useful in the real world, in particular with APIs such as OpenCL and PhysX.

After the final date submissions are accepted, the section editors rank their submissions based on the values they think are most important for their section. Additionally, I provide a ranking for all articles. I collect these rankings, assemble them into a final spreadsheet, and work with the section editors to resolve any cases where there are dramatic differences in our opinion. I also have to set the sizes of each section and decide based on trends what the sections should be. (Physics, Audio, Graphics, etc.).

I send the final results out to the section editors, who then set internal deadlines for their articles. From this point on, each section editor works toward the deadline at their own pace. Editors answer questions regarding articles in their specific section, but I assist them when ambiguities arise and when they are unable to answer the questions. This amounts to about half a day a week of work during this stage.

3. First draft
After the first draft deadline, there is a crunch period for the section editors and myself to give feedback on all of the articles; we also deal with articles that did not come through or are running late. This is one of the busiest and time consuming stages for all of the editors. In many cases we read the artlcle several times and provide detailed feedback to the article owners for the final article submissions.

4. Final Draft submitted to Section editor
After a few iterations, we receive a final draft of each section. The articles are locked and I take ownership, allowing the section editors and I to do a final pass. At this point, myself or the copy editor, working for the publisher are the only ones making changes. We do not change the meaning but just to bring the book into a cohesive whole. Also, minor nits are addressed like modifying figure numbers to be consistent, references, fixing any issues identified with equations or figures.

5. Editor(s) takes ownership of all content
After several weeks of this process, I start to ftp sections to the copy editor. At this point, I am locked out of making changes and need to specify them to the copy editor. The folks at Cengage were awesome and incredibly patient with me during this process, it was incredibly time consuming. Also, at one point, we realized we were over the page count (my response was: “what page count? Nobody told me there was a page count!”. That didn’t fix it, so I spent a long night with every page of the book laid out across the floor, down the hall, and in two rooms of my home working to find whitespace and making cuts to hit the upper page count limit.

6. Code review, code and CD draft
In the case of GPG, we have code submissions for many of the articles. Each of these needs to be put through at least a little bit of testing to make sure they install and run. This is done once by the section editor and once by me. We don’t have the most rigorous QA process, but we do make sure the components described in the article exist on disk, the code builds, and the .exe executes. If not, I work with individual code owners to resolve the issues and get this feedback to the authors for a final CD submission which is created by the publisher.

Categories: Uncategorized

For more complete information about compiler optimizations, see our Optimization Notice.

Comments (0)

Trackbacks (2)


Leave a comment  

To obtain technical support, please go to Software Support.
Name (required)*

Email (required; will not be displayed on this page)*

Your URL (optional)


Comment*