Take the Blue Pill, Neo

    Up until now, I’ve been dealing mainly with abstract concepts: what types of players there are, acquisition vs. retention, other things that you can’t pick up and hold in your hands. While there are a lot of these things I could go over, I don’t think it would make for a very interesting column to keep hearing about general theories every two weeks.

    So, starting with this week’s column I’m going to be discussing things that are actually tangible. Maybe only on burned CDs, but those are CDs you can take to the bank! What they’ll do with them, nobody knows. This week, let’s talk about the driving force behind every game: the engine.

    Now, if you were to walk up to most people on the street and say “tell me about your engine,” …well they’d probably think you were crazy. Once you convinced them you weren’t nuts, though, they’d almost certainly think you were talking about their car’s engine; that thing that makes it go.

    Before you think “that’s not it at all,” consider what the engine does for that car. It provides power. It gives the car momentum. Without the engine, the car just sits there, not doing anything. In reality, you can push that gas pedal as much as you want, if the engine’s broken you’re still not going anywhere.

    In many ways, a computer game’s engine is the same as the engine for a vehicle; without the engine, all those pretty graphics just sort of …sit there, and it doesn’t matter how quickly you can move your mouse or press the any key. Just as the car engine is the heart of the car, the game engine is the center of the game.

    Now, what the engine can do is entirely up to you, and your design documents. How it works and is something I couldn’t even dream of covering in less than thirty of these articles, and that would get pretty boring, being mostly pseudo-code. This column isn’t about the engine per say, it’s really about a choice.

    There are two options to consider when it comes to the engine:
    [*]Write it from scratch. When the design documents are finished, you know precisely what the engine will be required to do, and you have the opportunity to craft it to your specific requirements.
    [*]Lease someone else’s engine. I mean, really, how many times do the same thirty thousand lines of code need to be written? Someone else has already done the dirty work, why not use their solution?

    If you think about it for a little bit, both of these choices have their own benefits and flaws. It’s really a balancing act you need to perform between time, cost, and manpower. Let’s look at both options a little more in depth, as we tend to do in this column.

    If you create your own engine, you have one major advantage: you control the code. Every piece of the engine is known to do exactly what you need it to do; no more, no less. If your game doesn’t require the user to dig, the engine doesn’t handle it: it would be a waste of code. There’s an aspect to this particular concept that isn’t at all obvious, so please indulge me.

    Suppose there’s a numeric value in the engine’s database that doesn’t get used by your game, but just sits there at the default value of 0. It’s not hurting anybody, it’s just sitting there basking in its own nullness. Now, suppose some game event triggers a calculation that requires that value to be a positive number. If it’s 0, the results are unpredictable, which is very bad for the controlled environment of your game. If you’d written the engine yourself, that value wouldn’t even exist, and the offending calculation would not need to call upon it.

    Before you shun this as irrelevant, I actually encountered it last week doing some freelance consulting. The client had installed a new piece of software that accessed an old database, and required a default value of 1 instead of 0 for its calculations. This sort of thing does happen in the real world, and must be a serious consideration.

    Alternatively, you can save your coders’ time by acquiring the rights to someone else’s engine. People have been doing this with the Quake Engine for years. As with anything, though, there’s a tradeoff for doing this. You’re saving your coders some time, but if you want an engine that’s current you’re looking at spending a significant amount of money for the rights to use it.

    The main advantage to leasing someone else’s engine is that it saves you time while gaining you a (probably) tried and true piece of code, but there’s also an unexpected downside: if you manage to lease the engine of a game that hasn’t been released yet, you’re actually not allowed to advertize your game until they advertize theirs.

    This happened to Troika Games with their upcoming game Vampire the Masquerade: Bloodlines. They’re using Valve’s Source Engine, which is powering Half-Life 2. Troika was not even allowed to tell anyone about their game until Half-Life 2 was officially announced, because that would have resulted in a third-party announcement of Half-Life 2.

    There’s one other disadvantage to borrowing someone else’s engine: you have to learn it. Anyone programming for the engine needs to spend time learning what functions control what aspects of the game world, and how to design new software to use the legacy code. For a complex engine, this can literally take weeks.

    And that’s my brief overview of the engine options. I could easily write a doctoral paper comparing the two choices, but since that’s a little beyond the scope of this column I’m going to leave the small issues like balance and scalability alone. One question still remains though: How do you choose which way to go?

    Ignoring how customizable a leased engine is, because you can always acquire the rights to modify it, there are two main concerns you must address when deciding how you will deal with your game’s engine. The first is, of course, money.

    Let’s suppose it costs $2,000,000 to lease the engine you want to use. Let’s also suppose that it will take $1,000,000 to have your own coders design, write, test, and modify a brand new engine, but that it will also take six months to do (these numbers are purely hypothetical, don’t take them as accurate in any way). The question you need to ask yourself is whether it’s worth the extra million dollars to cut your development time by six months. It could very well be the better solution, but this is something you need to consider on your own before your programmers start cutting code.

    The other thing to think about is if there’s a specific reason to write your own engine. This usually comes in the form of cutting-edge technology, where your game is doing something nobody else has even thought of before. You could also be writing a very simple game that only requires the engine to do a handful of tasks, and everything else is significantly over-powered. After all, do you really need the Quake Engine to play Minesweeper?

    In the end, this is one of those choices where each decision is correct in its own way. Without looking at your design documents and charging you a stupid amount of money to do it, I can’t give you any advice other than to look at the two options carefully, examine the abilities of the engines available to you, and base your decision on what you need rather than what you want. Believe me, the last thing you need is for a programmer to say “Wow, the engine can do that? I’m going to write something that uses it!”

    Another area of game design that has a similar choice available is the game world itself. Do you use someone else’s, or develop your own? We’re going to return to the concept side of game design and cover this next time.


    Disclaimer: Behind the Veil was written by Chris Marks and hosted by Diabloii.net. The opinions expressed in these columns are those of the author, and not necessarily those of Diii.net.

    You may also like