Do not wait for the cavalry
First posted on 17 October 1999. Last updated on 25 February 2006.
If we want more adventure games in the near future, then we are going to have to write them ourselves! By adventure games I mean games that can be played at a nice slow thoughtful pace rather than games that are action or role-playing hybrids. Why write the games ourselves? There are a few commercial developers still producing worthy adventure games (good for them), but they are swimming against the tide. If adventure games are going to evolve to be successful again, the evolution may have to happen outside the commercial arena.
I am not an artistic type so I am not threatening the world with a potential game. I cannot draw, act, or juggle. I am happy to encourage those actually developing adventure games, and there is much "amateur" development deserving encouragement. What I can toss into the pot are some thoughts on the software engineering side of implementing adventure games. The first question may be "are the available authoring tools flexible enough?". Those who write games are the best to answer this. The tools available today are probably flexible enough for the games that are being written now, but there is intelligent behavior I like to see in games of the future which is cumbersome to do with the current tools.
Another question may be "why are there so many bugs in the latest crop of games?". I see bugs often listed as the reasons games are late. Games are released with buggy interfaces that even discourage the most patient gamers. If the bugs can be reduced it may cut costs of development without turning off potential players. I do not believe that bugs exist because of bad programmers. If anything, the game industry should have the best programmers. I do not think it is because adventure games are difficult to implement. This may be heresy but adventure games are not the most complicated bits of computer software around.
Here are 2 possible answers to why there are so many bugs. Firstly, there is the "cannot see the forest for the trees" effect. Developers get so focused on implementing clever new behaviors that they lose sight of basic functionality, and by the time it is noticed that the simple things do not work it is already too late or too expensive to fix. This has happened with a number of 3D adventure games of the past. Secondly and more seriously, the APIs which developers now have to use to implement effects such as graphics are too sophisticated and rich. The more sophisticated an API is, the more involved and hard it is to find the bugs. If you have a crude API it is going to well exercised and tested, as everyone must do things the same way (which itself avoids a lot of bugs).
I must apologize for the above jargon talk. API stands for Application Programming Interface. An example of an API is Microsoft's DirectX. The rest of this article deals with aspects of implementation for adventure games and is of most interest to those with a programming bent.
Divide and conquer
In many adventure games the game logic and game interface are tightly coupled. For instance, defining an item for a text adventure means you may define its description and name at the same time. In a graphic adventure you may define a hotspot and its behavior. This approach is certainly sensible, but there is additional merit in putting the game logic into one layer and the interface into a separate one.
Separate layers allow developers to easily port a game from English to another language such as French or German. It also means that you can first think of implementing a game as a text adventure or very simple 2D graphic adventure, then change the interface to a marketable 3D one. Why bother with a simple interface if you are going for a super 3D one? A simple interface can be a storyboard equivalent to show what the game may be like. Separate layers can then make it easier to change to the final interface. This flexibility is clearly an issue given the long development times for adventure games.
The exception proves the rule
A long time ago "proves" means "tests". This saying makes sense. Adventure games consist of a lot of rules governing what happens (or does not happen as the case may be). There are rule-based computer languages available, and these may be better tools to implement adventure games than some of the authoring tools currently used. An example is the logic programming language Prolog. Prolog is short for PROgramming in LOGic. It is a logical and a declarative programming language. Its heritage dates back to the research on theorem provers and other automated deduction systems developed in the 1960s and 1970s.
A rule-based language should mean less code and also more readable code. Rules expressed in a C-like language are not as instantly readable and not as maintainable. It is true that current adventure authoring tools provide you with basic game definitions. For example, you cannot see anything if there is no light source. Nonetheless, it is not a big job to write these in a rule-based language, and the authoring tool may have limitations which are difficult to code around—for example, if you want an item to be in two rooms at the same time, or you want to use more controls than the tool allows. In a rule-based language you do not have these problems.
Another benefit of a rule-based language is that programs written in a well defined language have a longer shelf-life than programs written in a less defined language such as Visual C++ using DirectX.
It is not what you say but the way you say it
Most adventure games work by an engine interpreting a compiled script. This still applies even in a graphic adventure where behavior may be defined visually. This has great advantages as can be seen from the success of game engines developed by Infocom or Sierra On-Line.
Another option is to translate the script into Java or other languages such as C++ or Delphi. The generated code can include whatever common engine code that is required. This is simpler and cheaper to implement, and you can make use of someone else's development environment. There are no problems with backwards compatibility which can complicate the development cycle. It may also be easier to interface with the operating system to do graphics and implement the user interface.
Painting go faster stripes
Loading up new levels in current games can take an inordinate time. Some games seem to make an access to the CD-ROM each time a sound is played. Software caching can really help here, together with loading on demand. While the player thinks the game engine can be pre-fetching from the CD-ROM to speed up response time.
The game engine should access sounds, images, and movies through an abstract layer which hides whether the data is on the CD-ROM, on the hard disk, or in memory. This should allow for easy caching and pre-fetching. Opening a file is a very heavyweight operation. Concatenating the files on the CD-ROM into a super-file which is kept always open can help. You can compile in the offsets in the super-file.
Do not open until Christmas
If you are making calls to something like DirectX, consider using wrapper functions round them. Firstly, if you ever decide to port to another version of DirectX (let alone OpenGL) this can reduce the changes you need to make. Secondly, this can simplify your code if the wrapper functions hide some of the messiness in the DirectX API. Lastly, this enables you to add trace code around calls to DirectX which can help in finding problems during debugging.