Much is often mentioned about the cultural disconnect between the Business, Design, and Programming fields within the game industry. Different attitudes, different terms and languages, different expectations. I’ve always felt this has been a self-perpetuating problem (when diagnosing it we canonize it by declaring that this is “just how it is” – further reinforcing the meme), and a rather large problem at that.
As one who considers all three to be a passion I may be speaking from personal bias but I see this as a problem with a relatively easy solution. To me, Business, Design and Programming are based on the same fundamental principle:
Define the goal clearly, research the available choices, then weigh the pros and cons of each choice to arrive at the optimal solution.
[This should seem familiar if you read my previous entry]
There is little benefit to shrouding a profession in mystery and much to be gained by integrating these goals into a single representation. The commonly occuring pattern is the separation of these goals into components. The other parts of the original goalset show up in each component typically as a ‘restriction’, but information is lost in this process.
Let’s take a simple example:
You and a friend are looking to go out for dinner and you want something relatively cheap and relatively good. You deliberate for a bit and realize that you know a lot of quality places, and your friends knows a lot of cheap places – so you decide to specialize and divide the problem. You try to find the best restaurant you can under 30$ a person, and your friend meanwhile tries to find the cheapest place with at least 4 stars on Zagat. The chances that you will arrive at the same solution is slim to none (and reduces as the population of choices increases).
This is how game development often actually works. The game needs to be relatively fun and impressive, while being relatively stable, maintainable and scalable, while also being done relatively quickly and cheaply. The meetings are held, restrictions are put in place (typically time via milestones), and then each team optimizes for its pet criteria. This can occasionally cause conflict as all of these are mutually exclusive.
This type of problem is an optimization problem, and there are a few common patterns to solving it:
- Positive Optimize - Pick the one that matters MOST, this reduces one of the variables (e.g. we have exactly 2 years worth of funding to release this – what can we make in 2 years?)
- Negative Optimize - Pick the one that matters LEAST, this also reduces one of the variables (e.g. it doesn’t matter how stable it is – it’s just a prototype). In patterns containing three goal variables, this I like to call the ‘Pick Two’ method, based on the saying: “Cheap, Good, Fast – pick two” or other patterns of “X,Y,Z – pick two”.
- Simultaneous Optimize - this can be difficult to approach but is typically going to be the most accurate. Programmers (especially AI programmers, Collective Intelligence programmers and Data Miners) will likely recognize this one. The idea is to assign a fitness function and then try a number of different techniques to get the best possible result (all of which are generally little more than an advanced version of a random shot in the dark). The ‘king’ of these techniques is more often than not a genetic algorithm.
When faced with a relatively small set of choices, I have a favorite way of tackling the full on simultaneous optimization: Using a spreadsheet, the goal components of the fitness function become columns and the available choices become rows. You rate each cell by how well that goal is satisfied by that choice (use the SAME SCALE for all cells, something like 0-5 or 0-10). Then you apply a weight to each goal as to how important it is to the final fitness. The sum of each cell in the row multiplied by its corresponding weights per column is the choice’s final fitness. It helps to throw in a couple dummy extreme choices to help you balance the goal weights to make sure your balancing is sane.
As soon as there are more variables or interactions between the choices, it becomes clear that you need something more like a genetic algorithm. Luckily we all have something very much like that already – intuition. I like to define intuition as “the sum of all knowledge and experience related to the subject”. Humans are exceedingly good at making good guesses when presented with a problem that they have a wide knowledge and experience base to draw from. However each large missing piece of knowledge or experience will heavily skew our guesses.
A few examples:
- a game designer wants to make a modification to a feature, thinking that it should be easy to change, sneaks it into the schedule – but it turns out to be very difficult
- a programmer finds after implementation that a design concept is not at all scalable, and codes up a tweak to make it scalable that defeats the original purpose of the feature. Not wanting to have ‘lost’ the time on the gantt, the decision is made to keep the ‘fix’ in the final version.
- an executive looks at the gantt and examines where the product will be at for magical tradeshow X – a new trade show the company wants to do that’s 3 months before magical tradeshow Y for which there is a demo planned, and requests a demo version to send with the demo team to show X. The team crunches and gets it done, but has to make enough hacks that the demo for tradeshow Y needs to have some features cut and is now behind on the entire schedule.
What am I arguing for? Simply this:
Open and continual communication of goals so as to bring the choices people make closer to ‘optimal’ for the company/game as a whole.
and
An attempt by all to increase the cross-departmental intuition of everyone involved.
What I am arguing against is the ‘silo’ effect and hyper-compartmentalization of culture and experience that is common of large hierarchies and specialization of labor.
A few things that help towards this end:
- Agile Development or similar methods
- Prototyping
- Small Teams (preferrably multi-disciplinary)
- Task Forces
- A relatively flat heirarchy (which is related to the previous two)
- A shared company calendar or internal blog/rss
- A wiki with an interconnected glossary of terms
- More multi-disciplanary employees (designers who can code, business heads who know design, etc)
- Task transparency (via the workflow management systems)
- Decision transparency (hearing a detailed explanation of a decision works to teach others about that discipline)
- Financial transparency (many companies cannot do this, but for those who can, it often works well)
