Team Leadership in the Game Industry Seth Spaulding II

The Review

Simply put, I really liked this book. In fact, I thought the book was so good that I bought two additional copies as gifts for a pair of coworkers who were just getting started as leaders of their own teams.

It contains a wealth of knowledge on the subject of leadership in the context of the game industry. Understandably, the book leans towards the artist camp in a game company, but the advice offered in the book is most certainly applicable towards other engineering or game design (I myself am an engineer and as I mentioned above, I found it to be very useful!).

But beyond the organizational charts and high level discussion of team dynamics, the book drills into some very important topics. For example, I was very impressed with the section on how to best evaluate whether someone is suited for a leadership position or instead set them into a senior position without placing them in charge of a team. Spaulding lays out several different scenarios and guides the reader through each one, explaining why people with different skill sets and personalities may or may not work out when placed in charge of over a team.

Another topic that is addressed in detail is what to do when things go sour: personality conflicts, team meltdowns, over-zealous leaders, and both incompetent team members and team leaders.

The book also contains insights directly from the GDC Roundtable sessions, including a detailed look at the question “What traits would you want in your ideal team leader?” Spaulding outlines the traits that are commonly chosen common and explains not only why they are common, but also why they are good traits or which ones may be more important than others.

On top of all of this, the book includes a collection of interviews (one at the end of each chapter) with industry veterans from an assortment of leadership positions and disciplines (art, production, engineering, etc). I especially enjoyed these because they showed both a variety of answers to some questions, while others most answered with the same useful advice.

I would recommend this book to anyone in the industry who is currently leading a team, or is thinking that they might want to lead a team in the near future.

Software Engineering for Game Developers John P Flynt, Ph.D.

Thoughts Overall

SEGD is a detailed post-mortem of a small team’s game project: Ankh. It focuses in on the process of developing a game from start to finish… with a heavy emphasis on the process. The book spans 800+ pages, many of which are tabular explanations of forms and documents. In other words — this book has “academic” written all over it. Okay, granted the Ph.D. at the end of the author’s name also indicates this fact, but I was willing to give the book a chance (as I am with a lot of books!).

Overall, I felt let down about a hundred pages into the book and it never recovered. Initially, I had high hopes because I like reading post-mortems from game projects (even if it may have been from a game that no one’s ever heard of) and I like process. However, SEGD takes its readers down a road that veers strongly towards the managerial side of game development, sans a couple of chapter sections sprinkled with the code of a few classes in an attempt to catch the attention of software engineers. Don’t get me wrong, I don’t mind reading about practices and methodologies — I grew up on SCRUM and Test-Driven Development, but there’s something wrong when a book is detailing forms from the ISO standard.

Yes, I read all of it. The best parts were when they explained the expectations they had, the methods they used, the overall outline of their setup, the roles that team members had, and the problems they ran into and how they resolved them. These were great discussions. In fact, I think the “Stripe” (iteration) methodology used is a pretty viable structure. But all this could have been wrapped up well before hitting the 500 page mark.

Do I Recommend this Book?

For this particular book, I need to you to answer my question first: Do you like digging for your information?

This book is dense and is, in fact, rewarding on varying levels for both managers and members of a game development team, but you’ll have to dig through layers of mechanics for those nuggets.

Pros

I really appreciated the effort that went into tracking the info during the Ankh project. In fact, this is exactly why I bought the book: to read about a team project that goes from design doc to a fully functional game. It was very interesting to read about how a bunch of ideas were turned into something tangible and fun.

This book has a lot to offer in terms of how a team formulates a game and gets their ideas implemented from the initial scribblings they wrote weeks/months before. It examines an iterative development methodology (each iteration they call a “Stripe”). Each stripe is actually a complete demo that fulfills a certain set of specified requirements, along the way to the final stripe with completes the game. The book takes the reader through each stripe (not in detail for all 17, but that’s okay — it started to become monotonous after a while), and explains many important issues that arose and addresses the team dynamics.

Furthermore, each stripe is outlined (with requirements and use cases), implemented, and tested. All of these steps are elaborated upon with good context, though there is a heavy emphasis on the outlining and documentation and less so on the actual implementation.

As you might have expected, the topic of design patterns surfaces throughout the discussion. Although I had feared for the worst when I reached this chapter (due to the overall view being so lofty it made me feel uncomfortably distant from the software), it actually turned out to be one of the best chapters of the book. For SEGD, patterns wasn’t the be-all end-all I have been reading about in other sources. The chapter takes a very practical point of view and after you have finished reading it, you don’t feel like the world can be solved by patterns, rather that they are proven, structured designs to solve a distinct class of problems. This tone and treatment was very refreshing.

Cons

After finishing this book I felt like I needed to have a formal review before moving on to the next book in my queue. My biggest complaint is the book was too focused on formalities of the game development process. I kept asking myself, “How did these guys make any progress with all these documents and meetings?”

Can I think of anything more boring to read about than metrics? I know: tables of ISO standard forms! Why the author could not have merely suggested the reader to take a look at a few forms to use as templates when setting up their design document or other related documents, rather than include pages upon pages of tables with explanations of each section (some of which boil down to “you probably don’t need to include this section”) I cannot fathom.

Don’t expect code. Classes, their objects, and the messages/events passed between them are all examined at a high architectural level. I was thinking this book might have explained more about library modules to form a game engine, but the game project itself was quite tiny in comparison to what I had already been exposed to at work, and did not discuss engine architecture to any detail. Instead, the focus was on using UML and SmartDraw to design every class in your game. Personally, I believe if you have enough foresight and patience to draw out the UML and maintain it throughout the life of a game project, you should take a step back and consider how much time you’re spending not implementing your game. Tools and documentation are there to help you convey ideas and save time — not become a ball-and-chain!

Final Word

This was an interesting read — though I had higher hopes. The cursory content of the vast number of subjects could have been thinned and left to the reader to investigate by reading authoritative, dedicated books on the subjects. The core of the book was really the Ankh project and the Stripes methodology, but it was often times buried under too many layers of formalization. Don’t pick up this book unless you’re willing to spend a lot of time sifting through those layers.