Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
A New Attitude To Game Engineering: Embrace Change, Re-Use, Fun
View All     RSS
June 14, 2021
arrowPress Releases
June 14, 2021
Games Press
View All     RSS







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

A New Attitude To Game Engineering: Embrace Change, Re-Use, Fun


August 6, 2009 Article Start Previous Page 4 of 5 Next
 

Reuse, and the pitfalls of Object Oriented Programming

The holy grail of object oriented software -- reuse -- is something that seems really great in concept, but in practice it tends to shoot you in the foot. Premature reuse is even worse than premature optimization, often cited as "the root of all (software) evil".

Becoming overly enamored with the potential for reuse gets you thinking about systems and frameworks, things that are general, flexible, pluggable, and generic, as opposed to creating real value and functionality in your program, which are things that are specific, to the point, and concrete.

On top of that, game designers and gamers always want special cases, things you had not anticipated -- things that make you angry, since they don't fit into your grand software design!

But how then are you to achieve software reuse? Instead of planning and designing for reuse you should discover opportunities for reuse! This is often applicable when you find yourself to be duplicating work you have already done, and when you do, you should extract the actual real commonality and put it somewhere re-usable (i.e. in a common library). Truly re-usable software elements are discovered, not designed.

Reuse and Refactoring

Designing for reuse is more often than not based on a "coolness" factor, i.e. it "feels cool" to design and implement reusable systems. The fact of the matter is, however, that such design is always speculative, because you are anticipating things that you might need, or could do with the system you are creating. This is the worst kind of speculation, because you are going outside of the scope of the requirements of the application at hand. That is not the point of writing software. The point of writing software is to deliver useful systems that deliver business value (or entertainment value, or both) to the end customer.

Again: never design for reuse. That is speculative, and you are much better off writing code that you know you need right now than code you think that you might need tomorrow. Only when, whilst maintaining old software and/or writing new software, you realize that you are doing something that you've done before -- only then -- do you reuse some code.

Even then you have options: if you are still maintaining the code base from which you are re-using code, you factor out the commonality to a library and make both the old and the new software depend on this common library. If you are not maintaining the old software, you simply copy the source.

This view is based on a few factors. We all want to write successful and useful software; otherwise what is the point of writing it in the first place? The natural state of such software, due to its usefulness and softness, is a state of constant maintenance. The reason to extract commonality is to have less total code to maintain, which makes maintenance easier. This gives rise to reuse of the common code.

Another reason to reuse code is simply because software is trivial to copy (if you have access to the source), so why duplicate work effort that you can simply copy for free? It is still reuse. It is a very common form of reuse, especially when it comes to copying/re-using an entire application. At the very least it will give you a much better start off point for the new application than having nothing at all to start with. The decision to do this kind of application-wide reuse is based much on how similar the new application is to the old, because you do not want to end up rewriting/adjusting more old code than you write new code.

Reuse can happen on small scales too, even within the same application. This is typical when you are just starting on a piece of new software. In the natural course of implementing customer value, you realize that you can factor out some commonality or parameterize some method in order to minimize the total size of the code base.

All of the above is related to refactoring, which is restructuring your code in order to enhance maintainability and extendibility while not changing its function, a very essential and natural part of software growth and adjustment. Obviously, reuse is part and parcel of the exact same mindset as refactoring, but people become confused due to the (often only perceived) differences in scale and scope. Working with the software design through refactoring should indeed be part of every programmers' daily tasks, with the goal to make the code base as light and changeable as possible.

Controlling Change

However, uncontrolled changes can easily push a project into chaos. Changes should not be allowed to, uncontrolled, creep into the software. Much like requirements, changes need to be collected, analyzed, documented, tracked and organized. A change request have indeed many aspects that are similar to a requirement, though change requests tend to be less detailed and have a greater emphasis on the motivation for a change. The primary goal of a change request is for being a base for evaluation. Typically you want to do a fast, triage-like evaluation -- "toss, wait, treat"-- in order to quickly and efficiently focus on the changes that are believed to have the most positive impact on the project.

Game developers face an endless source of changes and must at the start each iteration be very careful to choose the "best" changes to be handled, otherwise budgets are soon to be exceeded, and very little is added to the product. Being able to embrace change means you have to travel light, to be as agile as possible. Having a big speculative design document, or a complete upfront software design blue-print over the game will certainly make you too heavy and you will fail in making those critical changes that will evolve your game.

Since game developers aim for the moving target, "fun" games tend to change in a more radical way than traditional software products. It is therefore very important to track changes, reasons for changes, and the results of changes.

This database of changes and their respective result could also be an interesting thing to refer to between projects -- in essence, this would become a database of game design dos and don'ts. In this respect it becomes very important to be able to trace a from a change request through requirements to a working copy of the software. You simply need to know what features are implemented in a certain build of your game, otherwise it will be very hard to correctly evaluate the impact of the changes you make.


Article Start Previous Page 4 of 5 Next

Related Jobs

Disbelief
Disbelief — Cambridge, Massachusetts, United States
[06.11.21]

Programmer
Disbelief
Disbelief — Cambridge, Massachusetts, United States
[06.11.21]

Senior Programmer
Insomniac Games
Insomniac Games — Burbank, California, United States
[06.11.21]

Technical Artist - Pipeline
Insomniac Games
Insomniac Games — Burbank, California, United States
[06.11.21]

Technical Artist - Pipeline





Loading Comments

loader image