I am reading the book Postmortems from Game Developer this week. In each chapter a designer-slash-developer provides a break down of a specific title’s development. In one chapter Johnathan Chey of Irrational Games says the following regarding the highly acclaimed 1999 PC game ‘System Shock 2’:
First, we designed to our technology rather than building technology to fit our design. Under this model, we first analyzed our technological capabilities and then decided on a design that worked with it. This process is almost mandatory when reusing an engine. Sometimes it can be difficult to stick with this when a great design idea doesn’t fit the technology, but we applied the principal [sic] pretty ruthlessly. And many of the times we did deviate, we had problems.
This gave me cause to stop and think about the approach that Jeff, Jesse and I have taken for our own game over the past year.
Reusing Software Versus Creating Software
In my experience every computer programmer struggle with the urge to reinvent the wheel. I spent some years working at Cyber Sprocket Labs, a small software company that focused primarily on web development. And there I learned some of the most important lessons regarding the practicality of creating software. I joined the company with the youthful naivety of, “This project will be better off if I create my own content-management system from scratch, or forums, or one of the many other web technologies that already exists.”
Early in my career there I was given the chance to lead a relatively simple web project. One feature the client needed was an administrative back-end that would provide some custom functionality specific to her site, which involved creating surveys that users could fill out and submit. A simple feature to implement. But instead of pulling an existing solution off the shelf and modifying that as needed I took the cavalier approach of writing the entire admin interface from scratch. My boss realized how unnecessary that was but instead of pulling me aside to explain that he quietly stepped back and let me shoot myself in the foot. It made the experience painful when my efforts caused the project to go over the deadline and thoroughly pissed off the client. However, allowing the project to blow up in my face also made the lesson memorable: creating your own software instead of reusing existing solutions can cost you more than time.
That experience sticks with me. That is one reason why a year ago Jeff and I decided to use the LÖVE engine for our game. What did we stand to gain by writing our own engine from scratch? It has taken the LÖVE team almost three years to get to where they are now, and they have a larger team. So in our opinion the choice was to either using an existing engine, or we could write our own and spend three years or more to reach a point where we could start on the game. That’s an easy choice to make.
We required no functionality that existing technologies did not already provide. Creating software from scratch is something I love doing, but realistically why go down that path when there is nothing stopping us from using other software that already fits our needs? That gives us more time to instead focus on creating the tools we need that no one else has written, and so that has been our overall mindset when it comes to evaluating software versus writing our own.
How That Choice Impacts Game Design
I said that LÖVE provided all the core functionality we felt we needed for our game. Nonetheless choosing to use a pre-made engine constrains the design of our game. For example, LÖVE comes with no built-in networking capabilities. This impacted our original idea of creating a multiplayer game. We knew ahead of time that we would be resorting to other libraries for the networking code and initially that seemed fine. Yet that still contributed to our decision to abandon that design idea in favor of a single-player game, from my perspective anyways. (Admittedly there were larger factors than LÖVE behind that decision.)
Choosing LÖVE also bound us to writing our code in Lua and C++. Any programmer knows how the choice of language can affect design. Turing equivalence does not prevent programming languages from making certain ideas a pain in the ass to implement.
Choices in technology affect the difficulty of implementation and that directly affects game design. That is why Johnathan Chey’s statement resonated with me:
First, we designed to our technology rather than building technology to fit our design. Under this model, we first analyzed our technological capabilities and then decided on a design that worked with it. This process is almost mandatory when reusing an engine.
By allowing our technology to dictate the plausibility of our game design ideas we avoid the struggle of fighting with that technology to force it into a role it was not built to fill.
Do Not Take the Idea to an Extreme
Game development—all software development really—is a lot easier when you choose existing technologies that fit your needs and then continuously evaluate and refine your ideas based on the capabilities of that technology. However, some people may take this idea too far and think that I am saying you should never write your own technology from scratch. That just isn’t true.
There are always demands in projects that current software cannot readily satisfy. The most common situation in game development seems to be the need for ‘tools’. Inevitably a game design idea illuminates the lack of any technology to comfortably build on that idea.
There are examples of this in our own game. LÖVE is a great 2D engine but it has no tools to help us define the behavior of enemies and NPCs, or to script the paths and structures of bullet patterns. There is no reason to expect an engine like LÖVE to offer those tools because those design ideas are different from one game to the next. Every game would demand a separate feature which the engine would not be able to predict or provide.
So we allow game design ideas such as those to direct our efforts in creating new technology. That is why we invest the time creating our own tool for scripting the behavior of enemies. We have specific concepts in mind about how enemies should behave. We could try borrowing technology from something else but we would rip out all of the aspects we don’t need and still end up having to implement or modify those that are important to our game. Alternatively we could do what we actually chose to do: write our own tool for this purpose.
This approach sounds contrary to the idea of designing to your technology. Creating tools that allow you to execute design ideas is the antithesis. But the reality is that the two approaches share a middle-ground where you can select existing technology to cover as many of your major needs as possible, thus affording you the time to craft focused, specialized tools distinct for your individual game.
Is this middle-ground the best compromise between technology and game design? I don’t know. But that is the approach we chose, so we will see how it works.