A couple of weeks back, programmer Poya Manouchehri posted a piece about pitfalls in hobbyist game development to #AltDevBlogADay, I am going to use this a ridiculously far-fetched lead-in to something I wanted to write about anyway as I liked this quote of his:

I guess if had to summarize “agile development” (as overloaded as that term is) in a sentence it would be: Write enough code to do the job, no more, no less.

While certainly not an idea unique to agile, to me it encapsulates how agile can be a really good practice – if you use the tools provided by agile to provide simplicity and focus, it can help you solve some of the issues that might pop up in game development without introducing new ones. But I am not going to write about agile – while interesting it has been a hot topic since I started working with games and I have little more to add to what has already been said. What is interesting – bothersome, even – to me is how project management practices in general are sometimes misused in small teams.

In recent years, budding studios have adopted more and more complex development strategies – at first it seemed like this was mostly out of a desire to operate like studios in the large-scale games industry rather than a way to solve a problem. There are numerous annoying results of this; projects caught in eternal meetings as all information must be shared and all sharing must be documented, small teams where individuals refuse to do any development work as they consider their roles administrative and in general projects where the integrity of the development process comes before the quality of the game.

Now, whereas in larger teams (the ones in need of a solution for communication problems) enough people might work in every discipline that solutions are needed to make sure everyone is heard, in smaller teams where people know each other and know who needs what, it is usually faster to just talk to people directly. There is some idea that bringing all decisions through a committee will help people from different disciplines reach consensus, but I would say this is rather ineffective – which finally brings me to my point.

Most people in the AAA game development industry will tell you working with people from other disciplines is difficult. It is a bit eerie, really – it certainly seems like the kind of working relationship a programmer and an artist have, for instance, would create an understanding for each other fairly quickly. While this is true to some extent, with development focus comes a set of goals, methods and priorities. Rather than making sure all details of every change is discussed and agreed upon by each discipline, we instead try and solve issues in ways that allow each other to be creative in as large a space as possible without breaking the game.

While a relationship built on virtual limitations might seem bleak compared to mutual understanding, I would say referring to it as distrust is missing the point. As a programmer, given a broad description of a system instead of a specific feature allows me to build something coherent and robust – as an artist, having tools that will not allow you to create assets that break the game allow you to think about the art instead of  the rules you need to adhere to. More importantly; creation itself is inspiring and by doing more of it we get new ideas.

Some things, like high-level design, will require everyone’s involvement – especially in small projects where people are more invested. But in terms of other things, I find that one of the marks of experience in the games industry is the insight to foresee potential and problems in what you do, and the ability to allow others to do their thing.

No Comment

No comments yet

Leave a reply

Posted on Jul 11/11 by Saint and filed under General game development | No Comments »