My MSc Research Project

The games industry has had a long-standing difficulty in successfully delivering projects to market on-time and on-cost.

The industry has tried many different methods to improve this problem; yet still projects slip, are cancelled, or require significant amounts of crunch to complete them. We have tried, with varying success, to import methodologies from other industries. Yet when placed in the context of the games industry, something is still somehow lacking.

My hypothesis is that the industry does not have a project management methodology suited to its nature. This industry is a creative entertainment industry and has different needs to other sectors of the software industry. I believe that creativity is a significant factor in the development of videogames, and that it is a factor that to-date has not been explicitly treated by any project management methodology. This is a significant shortcoming for an industry that is built on creativity. I believe that much of the reason for many development problems is that we are trying to manage a creative process with tools inappropriate to that task. Creative processes are different, and need to be managed differently.

My research project will investigate the effect of creativity on various development tasks, both routine and highly creative, in a real world project. This will be the first study that provides an investigation and understanding of what role creativity plays in videogames programming. These results will be critically analysed to consider the question of how best can we manage creativity in videogames programming?

If all goes well, this should be the first step in establishing a new direction of research and practice in the management of videogames projects.

Reuse

Re-use is now an established trend. And that's a good thing.

But we go about it in a very back-to-front way.

Primarily, code re-use tends to be a very code-oriented practice. We look at a piece of code, its functionality, performance and other characteristics and decide it makes a good candidate for re-use. And so, it gets re-used. And we find that in the re-use, it didn't quite do what we wanted. We then have to spend a lot of effort re-engineering it towards our needs. We bang a lot of square pegs into round holes.

What went wrong? We put the cart before the horse. We attempted to re-use code, a derived artefact of the software engineering process without considering the original, motivating cause of that engineering effort - the requirements.

Written, implemented code is a concrete solution to some specified problem. The requirements for the code are a pure expression of the problem we need to solve. In attempting to directly re-use code without comparison or consideration of the requirements that led to that code, we're hoping that one solution solves two problems. We're hoping that a given solution can solve problems that were not known, or at least addressed during implementation.

More explicit consideration of the requirements in the re-use process has potential benefits for all parties. For the client code, wishing to re-use some candidate piece of code, we can ensure that it is a good fit for our requirements. If there is a mismatch between requirements, this clearly identifies where work is needed. These conflicting requirements can now inform the design process, to ensure that the any modifications to the re-used code are implemented appropriately, and not simply bolted on, polluting the code. We can more accurately estimate the work required, rather than attempting to untangle the specifics of implementation, piece, by piece, by piece.

Critical Chain Project Management

The Critical Chain project management methodology has some interesting ideas that are very relevant to games projects.

1. Time is not used to figure out the critical chain of a project. Instead, dependencies are used.
2. Buffers and padding are not placed at the end of each activity. Instead, they are placed, in aggregate, at the end of the project.

(1) is particularly salient for two reasons. Firstly, as is well known, software remains resolutely incredibly difficult to estimate accurately; what is the point, therefore, in using inherently inaccurate estimates to attempt to calculate your critical chain? Dependencies are a critical factor your ability to deploy resources. You cannot add resources to expediate a particular activity if dependent work is held up. Conversely, identifying those points in a project that have the maximal tasks dependent upon them highlights them as points in the project that need maximal resources to ensure their successful completion and enable dependent tasks to begin.

(2) is simply Parkinson's law. Adding padding to each task makes its timely completion far less critical, and therefore things begin to slip. Critical Chain instead calls for all activities to be begun and completed as quickly as possible (as doing so eliminates them as a dependency allowing further work to begin) and the padding is instead added at the end of the project. This change therefore means that the scheduling of a particular task is purely dependent on its input dependencies, not a function of the dependencies and the padding.

And furthermore, what sense does it make to add 20%, say, to an inherently inaccurate estimate anyway? Why not 10%? Why not 50%? Such a practice is meaningless.

Critical Chain is not a massively revolutionary technique, but its different perspective on some fundamentals of project management is quite insightful.

Feature Creep

Is it fair to describe feature creep in videogames development as "feature creep"?

Is it more the case that it reflects videogames development as a creative process involving uncertainty and discovery?

It'd be interesting to measure how many features get added by "feature creep" at each stage of development of a game and feature, as a proxy measure of much uncertainty is present in the current project plans.

Inappropriate error checking

One interesting anti-pattern I've come across lately is the whole issue of peppering run-time code with things like: if(index >= count), return. Typically this is added to engines to make them more "user friendly", "robust" or "general".

What's wrong with this? Typically, the data that this condition is operating on is a static asset that has been pre-processed by a tool. We're using an expensive run-time check, often for every frame that we do something, to check a static condition that should be done at asset load or compilation time.

Code that can tolerate erroneous data breeds erroneous data. Erroneous data breeds over complicated code. And that is a maintenance and QA nightmare.

Sometimes you just need to throw bad data out as unacceptable. That's actually the most friendly, robust or defensive thing to do.

Games project management is interesting.

We focus so heavily on process. We focus on defining tasks, ordering them, estimating the time required and achieving a smooth production with balanced resources.

Yet we never take explicit account of the nature of our industry in our management methodologies. We work in a creative industry, yet none of our current management methodologies address this explicitly, usually only indirectly or tangentially.

Creativity is not a mystical process. There is a big body of literature out there discussing its origins, various models for it, how to encourage it and how to manage it.

Consider some of the main concepts in creativity:

* Divergence

* Convergence

* Incubation

Divergence and convergence are complementary processes. Divergence consists of generating new approaches, alternatives, ideas and plans of action. Convergence involves evaluating those options to select the most appropriate to achieve a solution.

So, to use creativity to solve a problem, we need to identify and define the problem, consider it from many perspectives and reframe it so that we fully understand it. We then diverge to generate many possible solutions, then converge on a sensible solution. And implement it.

The candidate solutions may not be immediately apparent. We may require time to consider the data before we can offer a solution. This is incubation. This is the idea that we need to allow our unconscious thought processes time to work on a problem, before an idea for a solution bubbles to the surface. Our unconscious thought processes are capable of solving far more complex problems that rational thought alone can solve.

So, returning to the idea of games project management, it's strange that we don't manage our projects in a way that supports these concepts. Typically, when a task is begun that requires creativity to solve or implement it, a developer may struggle to make real progress for the first few days, either "spinning his wheels", or attempting solutions that may turn out to be ineffective. What is happening here?

Our management methodologies haven't facilitated the creative process. When a developer "spins his wheels" for the first few days on a task, that is because we haven't given him time for incubation; we haven't allowed time for his mind to chew over the task and to produce ideas for solutions. Instead, he spends the first few days of a task gathering data and incubating solutions. How much time could we save if we factored in some time for incubation? Instead of simply assigning a task to a developer, we can have a phased commencement, where before implementation is begun, we give the developer the opportunity to fully explore the problem before work begins so they can develop ideas ahead of time. The developer will then be likely to begin the task with clear plans for implementation in mind.

What of the process of attempting solutions, only to discard them? This could simply be an example of experimentation. Experimentation, and learning from the failure of those experiments are key to both creativity and learning. Alternatively, however, this could be an example of insufficient divergence or premature convergence.

If we fail to generate sufficient options for a solution (insufficient divergence), we clearly may overlook a more effective solution. When we reach development, we find none of our options suffice. We then have to either adapt our solution, which may or may not prove ultimately effective, or enter a new divergence and convergence iteration. If our management process had facilitated the divergence process, and given it sufficient time, perhaps we could save time down the line on repeating those processes at a more expensive stage of development.

Premature convergence is the selection of a solution before all solutions have been fully evaluated, with the consequence that a superior solution may be overlooked. Again, this may result in significant adaptation or rework of a solution that proves ineffective, typically at the expensive, implementation stage. Better, explicit management of the convergence stage, ensuring all perspectives are considered, all stakeholders' needs are addressed and the full feasibility of a solution is evaluated could save expensive implementation time.

Creativity offers a new, interesting and potentially productive perspective on the management of games projects.

I have a theory about the nature of games development. Of what differentiates it from other software development effots.

Simply put, I think the difference is the domain for which we are developing software. Most mainstream software development efforts entail developing software for a relatively fixed, external, real-world domain. In games development we are faced with the challenge of developing a piece of software for a domain that we construct or invent ourselves. A domain that we're constantly changing and evolving. A domain with few, fixed, real-world anchor points.

Consider the example of an FPS. The IP and game design for a given FPS defines the domain in which the software must be implemented. It defines the rules of the world of the game. It defines the mechanics of gameplay. It defines the look of the game. It is unique to each title; it cannot be shared or re-used. The genre, technology, market and so on may influence or constrain a particular IP, but it remains something very open and flexible. We can conceivably invent any possible game design and therefore domain for our software to exist within.

Of course, the game design evolves throughout pre-production and production. The software is therefore being implemented in a domain that is changing. What makes this process particularly difficult, is that this is not a domain that is rooted in some kind of external, absolute, objective real-world situation. The game design - and therefore the domain that our software is modelling - stems from a human, creative process.

Typically, this design is a group effort, a socially constructed shared vision. So, in addition to attempting to build software within a subjective, changing, human design, we need to consider the issues of communication and knowledge transfer. A game design is a shared vision; how can we be sure all members of a team share the same vision? How can we be sure it is accurately communicated? How can we know that implementation specific considerations that may constrain an implementation are fed back to the design process and reflected within the game design?

The game itself is not the only piece of software we create during development, of course. We typically also develop tools, editors or server infrastructure. Software is a socio-technical system, comprising both a human and technical component. The technical component is of course the software and supporting tools we develop during the project. The social, human aspect is the team, the team's shared vision and development processes used.

So, we are attempting to construct a socio-technical system to implement a game in an evolving, creative, invented domain. No wonder its challenging!