R & D - It keeps you honest!

I've recently been working in an R&D group, developing various features that are quite experimental and wouldn't normally be scheduled as part of a project. This is intended to be "practical" R&D - we aim to develop features that have a chance of making it into the game, as opposed to features that are blue sky and would never actually be shipped.

This kind of development approach subtly shifts your approach to developing features. Briefly, you become very focused on doing what is necessary to get the feature into the game. You focus on making sure the feature is on-budget. You make sure that you consult with affected parties. You work out the consequences of incorporating the system and seek to mitigate any problems. You suddenly find yourself becoming a salesman, trying to establish a coalition of support for the feature. Your feature really has to prove itself worthwhile so that management will entertain the perceived risk of incorporating it.

Strangely, you don't always find yourself doing these things during the development of "standard" features. Because they are planned as part of the development effort, their inclusion in the title is automatically assured - pending no major disasters. You don't have to sell them. These features don't need to earn their place. Consequently, it can be very easy to find yourself "going down a rabbit hole" with features like this - exploring functionality that is interesting, but not necessarily focused on shipping. Perhaps these features are ultimately more risk-intensive, as they won't be quite so critically examined as the R&D features.

I tend to find that the whole "posture" you adopt during the development of an R&D feature that is not automatically included in the game is ultimately much better from the perspective of careful software development. It does at least feel more like the kind of process intended by the creators of various software development methodologies. It feels very much along the lines of the approach advocated by Michael Saladino in his "Why Red Lining Your Team Leads to Ineffectiveness".

Perhaps it's not for everyone. Perhaps it's not for every team. Perhaps some may find it quite a pressured, stressful kind of approach. But I really quite like it. It certainly feels a much more considered, deliberate approach. It seems that developing features in branches, that have to prove their worth for integration, sets in motion a slightly changed, more focused set of processes than may be typical.

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!