Going into a project with a large portion of the game’s technology already developed is also a fairly common occurrence. If this is not the development team’s first project together at a
new company, then it is likely that there will be an existing technology base that the project is supposed to build from. Even if the project is to use a “new” engine, this often only means an older engine updated, and as a result, the style of game best suited to the engine will not change significantly. Even if an engine is being written from scratch for the project, it is likely that the lead programmer and her team are best equipped to create a certain type of engine, be it indoor or outdoor, real-time or pre-rendered, 3D or 2D, with a complex physics system for object movement or something more simple. The programmers may be
interested in experimenting with certain special lighting or rendering effects, and will create an engine that excels at these objectives. The designer is then presented with this new technology and tasked with coming up with a game that will exploit the sophisticated technology to full effect.
Other times it is predetermined that the project will be using an engine licensed from some other source, either from another game developer or a technology-only company. Though some of these licensed engines are becoming more and more robust and as a result can allow for a fairly broad number of games to be made with them ( Criterion’s RenderWare is certainly a good example of this), many licensed engines are still developed with one game genre in mind, and no engine is without its fundamental limitations. Sometimes the project leaders have enough foresight to consider the type of game they want to make first and then pick an engine well suited to that. Sometimes the engine licensing deal that seems to deliver the most “bang for the buck” will be the one chosen. Then, with an engine choice decided, the team is tasked with creating a game and story that will fit together well using that technology.
Just as starting with a desired sort of gameplay dictates what type of engine should be created, starting with set technology requires that the game designer consider primarily gameplay that will work with that sort of technology. If the engine is 3D, the designer will need to create a game that takes place in a 3D world and uses that world to create interesting 3D gameplay. If the engine is only 2D, a first-person shooter is out of the
question. If the engine has a sophisticated physics system, a game should be designed that makes use of the physics for puzzles and player movement. Of course, the designer does not need to use every piece of technology that a programmer feels compelled to create, but it is always better to have your gameplay work with the engine instead of fight against it.
Often, when a project is using a licensed game engine, that technology will have been chosen with a certain type of gameplay in mind. The designer needs to seriously consider how far she should deviate from that initial technology, for it is surely going to be easier to make the engine perform tasks for which it was intended instead of pushing it in directions its programmers never imagined. For instance, the oft-licensed Quake engine (in all its various incarnations) was created for handling an indoor, first-person perspective, fast- action game involving a lot of shooting. Though some teams that have licensed that engine have tried to push it in different directions, one of the most artistically successful licensees thus far, Valve, retained much of the standard Quake gameplay that the engine excelled at for their game Half-Life. Certainly Valve added a lot of their own work to the engine,
technology that was necessary in order to do the type of game they wanted. But at the
same time they did not try to do something foolish such as setting their game primarily outdoors or using only melee combat, at least not in their first title with the technology.
When technology is handed to a game designer who is told to make a game out of it, it makes the most sense for the designer to embrace the limitations of that technology and turn them into strengths in her game.
The designers of Half-Life smartly used the indoor first-person shooter gameplay
established by Quake, the engine licensed for the game’s creation. Pictured here: Quake II.
The technology can also limit what sort of story can be told. Without a sophisticated language parser, it is going to be difficult to tell a story in which players need to
communicate with characters by typing in questions. Without an engine that can handle outdoor environments reasonably well, it is going to be difficult to make a game about
mountain climbing. Without robust artificial intelligence, it is going to be hard to make a good game about diplomacy. Without streaming technology that allows for the playback of large sounds, it will be hard to have huge amounts of dialog and hence hard to have characters whose dialects are important to the story. Without the ability to have large numbers of moving units on the screen at once, it will be impossible to tell a story where the player must participate in epic, massive battles between armies. The game designer needs to consider how the story line will be communicated to the player through the engine that she must use. Trying to tell a story with an inadequate engine is just as likely to compromise the game as tying a particular story to inappropriate gameplay. Again using the example of Half-Life mentioned above, if the team at Valve had tried to set their game in Death Valley and involve the player battling gangs of twenty giant insects at once, the Quake engine would have ground to a halt on the machines of the day and the game would have been miserable to play. In the Death Valley scenario, Valve might have been telling the story they wanted, but no one would have cared since the game would have been miserably slow and looked horrendous. For the greater good of the game, the story and the technology must be compatible with each other.
Something else to always keep in mind when considering how your technology will limit your
gameplay and story is how you can creatively work around your limitations. For example, if you are trying to do a game about massive battles with thousands of individual units, do all of the units need to be represented in 3D, or will a 2Drepresentation work just as well? Or, perhaps you never need to have all of the units in the world at the same time; you could tell the story of such a gigantic conflict from the viewpoint of a single soldier in that battle, with between-mission updates that show the larger picture. For an example out of my own past, my ill-fated game Gunslinger tried to capture the myths and storytelling of the OldWest.
We had a technology that was perfectly suited to rendering sprawling outdoor environments in 3D, so it was a natural fit to the game. But if we had only had a 2D engine, there is
nothing to say we could not still have done a tale about the legends of the Old West in a 2D game with a god’s-eye view of the proceedings. As a game designer, it is possible to get stuck in a rut of how a game “needs to be done” and forget the potential for alternate implementations that may be a better fit for your technology.