Friday, 19 February 2010

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!

1 comment:

  1. I understand the moral of the stuff from example of FPS described!!

    Nice to shared!!

    game design program