Mark Cooke’s G-Mixer

The TheDigitalLifeStyle has some nice words for the Indicator Maniacs application I programmed for Mission-One:

“Team Leadership in the Game Industry” was recently written by Seth Spaulding, Art Director at Firaxis Games, and analyzes what it takes to be successful in a leadership role specifically for game development. It includes a number of interviews with game industry veterans who are in lead or executive positions and examines case studies of leadership failures via the author’s experience. I ordered it from Amazon.com and when it came to Tokyo it apparently made it’s way from Germany (yay for globalization!).

The book starts off with giving some examples of the organization of game development companies of various sizes. If you’ve been in the industry for a while this is nothing new but for people new to the industry this is a good overview.

What the book does really well is identify positive leadership traits that earn the respect of your colleagues and get the job done. Perhaps more importantly the book identifies many skills that may appear to be of highest importance but really aren’t in a leadership position. A simple example – the lead artist does not need to be the best artist on the team. Of course they must know the tools and technologies that are being used to understand the work and to earn the respect of the team but the primary goal of the lead is to manage and help the team succeed as a whole (and possibly do production work depending on the size of the team). There is nothing wrong at all if they are also the best artist but it should not be the main requirement as making art is usually not the primary job function of the lead on a large team.

In an interview in the book with Joe Minton, the President of Digital Development Management, he summarizes his thoughts on good leadership qualities and bad which match fairly closely with my views as well. From the book:

S.S.: What are the most common traits shared by other effective leaders in your experience?

J.M.: Openness, communication, trustworthiness, integrity, ability to motivate, willingness to take measured risks, not procrastinating, understanding that being in charge doesn’t mean being the expert.

[...]

S.S.: What are the worst traits a leader has exhibited in your experience?

J.M.: Randomness, thinking one is the expert on everything, being wishy-washy, weak willed, easily overwhelmed, operating from fear, pretending to be a celebrity.

The book is loaded with great interviews with experienced industry veterans (not “celebrity” developers) that are quite valuable.

Continuing on it includes advice on how to craft job descriptions for leads such that responsibilities are well defined and understood. This is something I wish happened more often across the industry. When applying for a job it is usually quite clear what your responsibilities will be when hired but internal promotions that come with new responsibilities should also include very clear expectation setting for the requirements of the role. The author has suggestions on how to accomplish this in a clear way.

There are plenty of specific tips on many smaller scale but important job functions such as running meetings. Overall it is clear Mr. Spaulding has been in the industry for a long time and has accumulated a lot of valuable experience. I wholeheartedly recommend the book for both people interested in becoming a team leader and as a way to see new perspectives for existing team leaders.

Working freelance on multiple projects simultaneously has caused me to think a lot about what is worth doing and what is not worth doing. My time feels shorter than ever – because it spread more thin – so focusing on the tasks of highest importance at all times is key.

Sometimes this is very hard to do. Especially if the task I am doing is useful, technically sound, and/or clever. But even if you are doing something that encompasses all of the above it still might not be worth doing… which can be a tough pill to swallow.

Here’s an example – I’m currently working on a project where graphics need to be sequenced to a music track. I created an XML definition for the sequencing so it is primarily data driven and created a little scripting language via XML tags for doing things like moving/scaling/rotating/fading/tinting sprites. It’s working great and dramatically sped up the initial sequencing.

While working with this further, I started to see lots of cut and pasted XML script to repeat the same kind of action. Just like cutting and pasting runtime code this is terrible for maintainability. I wanted to make subroutines for doing multiple combinations of moving/scaling/rotating/fading/tinting that could then be re-used in 1 line of XML to do something more complex. E.g., scale up an object, move it left 100 units over 2 seconds, tint it red, wait 2 seconds, then destroy it.

There were two clear ways to do this:

1. Add new complex commands to the runtime code – hardcode a list of simple actions into a class that does something complex – and then expose them in XML. Still data driven but more specific to the use case and multiple of these would have to be added over the course of the project.
2. Create a way to define these subroutines in the XML itself. This is more extensible and could then be quickly tweaked without recompiling the code.

Being in a “data drive everything” mood I chose the latter and went to create the ability to define a subroutine of commands in the same XML sheet the sequencing commands live in. Basically this was more or less creating a programming language with subroutine calls and passed parameters (albeit very limited in scope). You can define subroutines in XML that do a bunch of sequenced actions then call that subroutine from the XML in the sequencing block. This is far from the most difficult task I’ve completed as a programmer but it was definitely time consuming to set this up in a generic and parametrized way.

I just spent the last 8 hours working on it and I’m not sure it was worth the time. This is a small project and adding some extra subroutine types in a half-data driven half-hardcoded way may have been smarter as each individual case would have taken about 5 minutes to build (and the number of individual cases is unknown… maybe it is just a few!). If this framework was going to be re-used many times by many developers doing it the fully data drive way would have been worth it for sure. But for something that may end up being a one-off I think I should have waited before committing the time to this unless I was sure it was necessary. The agile programming method would have told me “do the simplest thing that will possibly work, refactor later if you need to” which I don’t think is correct 100% of the time but is correct the vast majority of the time.

Live and learn.