Software Engineering and Videogames
Arts and Science… These terms are the first ones that come to my mind when I talk about videogames. In fact, when I attend a conference about videogames I often find two distinct groups: On one hand the artists (musicians, designers, illustrators, among others) and on the other hand the programmers (technicians, computer scientists or software engineers). People have already talked a lot about whether a videgame is an art or not and I feel that there is not a specific consensus about it. As a software engineer, I’m not best placed to give a critical judgment about that, however, because I’m in the group of programmers I also have a feeling that it is not very clear whether to build a videogame it is necessary to have a larger context than the programming, such as engineering. Therefore, I would like to discuss a subject that is rarely taken into account when discussing the construction of a videogame: The Software Engineering.
As starting point, I would like to quote Jesse Schell, author of “The Art of Game Design”, in which, in one of its sections discusses design-programming cycles, in which he maintains that in order to face long testing and improvement cycles, the game designer should know how to make each cycle worthwhile and take them as quickly as possible. In that paragraph, the author concludes: “Software Engineers have thought a lot about this issue over the past 40 years and have managed to develop some useful techniques”
This leads me to think of the many methods that software engineers have been developing, improving and modeling, according to the author, for 40 years and continue to evolve today, coming to exist different formal methods of software development, some derived from others and come to be applied to the letter in some cases and in others only serve as a reference to create a method adapted to a very particular context. However, without good communication among engineers, game designers and artists, there would not be a proper synergy between those groups. Here I propose a model of interactions between some disciplines that (perhaps, there could be more) are involved in the process of building a videogame:
Looking at the proposed model, according to the names of the disciplines within the circles, we could say that artistic expressions and game design have little to do with software engineering. However, both artists and designers must conduct a synergistic process with engineers in order to carry out the final product. Personally, I believe that this synergy is required, to some extent mandatory, so that the construction process does not became somewhat chaotic. Thus, software engineering could be conceptualized, under the context of building a videogame, as a discipline of support for both art and design.
Now with this concept in mind, we can assume that most of our videogame development projects, from the point of view of the software engineering, we should implement in some way a systematic and disciplined approach that correctly process the outputs of the designers and artists. To do this, there are several models of software develoment, which in complement with the formal methods, could easily be applied in videogames given that, after all, the latter are software products (Entertainment Software). Let me then, to cite some of the currently most known models:
– The incremental iterative model: This is currently the most widely used and on which many methods (both traditional and agile) lay down their framework. Among them, RUP, SCRUM, XP, etc. Its biggest advantage the early delivery of functional builds.
– Spiral Model: Practically based on risks and prototyping. Prototypes are developed continuously focused on implementation risks mitigation. This model is referred to by Schell as a proposal for the evolurionary development.
– Waterfall Model: One of the first models and also the least used in its purest form, that due to their lack of flexibility to return back on the stages of construction.
And as well as the software development models, there are the so-called “Best Practices“, applicable to all the models. It should be noted that best practices are usually groupd by disciplines or areas. For example, according to CMMI maturity model for software development, developed by the Carnegie Mellon Software Engineering Institute, in the Requirements Management area, a good practice is to maintain a requirements database and a history of changes for each of these. Indeed, one could mention N best practices from different sources. However, I personally do recommend reading the CMMI as a basis of best practices adaptable to any reality and context. (For more information about CMMI and its best practrices, please read: CMMI Model or SEI Library)
Now, back to Schell’s concern about design-programming cycles, and taking into account that there are many models, methods and best practices that could be adapted to be used in our develoment processes, another question arises: What to use and when? Well, in reality there is no exact rule for what and when use them, as this willl depend on the nature of each project that we face. So to answer the question, we could reduce somehow the scope thereof: What to use and when in most videogame development projects our actual industry?
Considering that many of the projects that most companies (or in some cases people) could be carrying out in the local industry would be services to others, we are talking about projects whose common characteristics are usually:
Teniendo en cuenta que muchos de los proyectos que podría estar llevando a cabo la mayoría de empresas (o en algunos casos personas) en la industria local serían de servicios a terceros, estaríamos hablando de proyectos cuyas características más comunes suelen ser:
- Time Constraint: Those in which the customer places a deadline that cannot be changed in any way.
- Idealistic Product Scope: Those in which the customer’s requests for a software product do not have a clear idea of what they want or what they really need.
- Low Budget: Those in which the project proposals to the customer depends on what the latter request as terms of participation. Often when dealing with public tenders)
With the above characteristics, and considering the videogame development projects nature in which not only they are trying to achieve a functional and non-functional balance but also the fun factor, it is suggested to review a rapid development method that allows the development team to have functional versions of the product in order to test the current features as early as possible and they can dispose of those features that do not add a significant value to the customer. As described, it might be suggested an iterative-incremental model with agile development formal models and specially considering the implementation of best practices. For example, using an agile methodology such as SCRUM, TDD, FDD or TREDD could help “tidy up” in project with characteristics as described above. By the way, there is an excellent book that explains how to apply Scrum to develop a videogame, its name is Agile Game Development with Scrum and it can be found at Amazon.com
– Again I insist, this will depend on the nature of each project –
To conclude, I would like to sum up some of the most important ideas raised in this article, and hopefully from these, start a discussion about the proposed topic:
- Developing a videogame is mor than just programming a software product
- In many videogames projects it is necessary to use software engineering principles to ensure their success.
- In the process of building a videogame it is important the application of a set of model, methods and best practices in order to achieve the implementation of the prodcut features with a high-quality level.
- Software Engineering can be considered as a support discipline in the process of videogames production.
- hich the Models, methods and best practrices mentioned and referenced should not be regarded as rules, rather as suggestions and they should be applied in different projects depending on their nature.
- There is still much to discuss to reach a formal conclusion on whether one or another development method best fits to our local industry, which is still very young yet.
Finally I invite the community to create research groups to help reach a level of maturity that will open the doors to develop more and more complex projects within the local industry, as well as it happened with the traditional software industry.