This is a post duplicated from the Digitanks website
Disclaimer: This is mostly a rant of disorganized and sometimes half-baked thoughts that have been going through my head for a couple weeks. It may be a bit of a confusing read and for that I apologize. Still I think there’s a nugget of wisdom in here or I wouldn’t write about it, if you’re willing to piece together my stream-of-consciousness writing style you may derive some value from it.
One of the first problems a game developer will run into when beginning a new game project is what engine to use. Naturally you want to use the engine that’s most suited for your project. You’re not going to make a hidden object game on the Source engine, nor do you want to use the Popcap engine for a first person shooter. There is a slew of free and open source game engines available, and a cavalcade of commercial engines as well. But this is a fairly solvable problem, it’s a straightforward process (if everybody is relatively unbiased) to look at the requirements of your game and the capabilities of the engines on the market to decide which engine is best suited for your purposes at your price tag.
If only life were so simple… You see, in addition to a long list of features, each engine carries with it a huge array of baggage. It’s never just about a list of features. Each engine has other properties that aren’t really quantifiable. Depending on who you are as a game developer and what kind of game you want to make, there’s a number of “question mark” factors that throw a stick in the spokes.
Let’s look at it from a modding perspective, which is where my background lies. Source has a huge online community of people who already play Valve games, and you’re basically selling to that audience. The upside is that Valve is well known for plucking talent from the indie and modding community. If you’re good and a little bit lucky, Valve or some company scoops you up and you get a job in one of the best places to work in the industry. Epic’s engine lacks the kind of community that Source has but it allows you to package and distribute Unreal SDK games independently for free purposes, so your audience doesn’t need to own a copy of any other Epic game to play it. So while you’re not really reaching the kind of crowd that you reach with Source, it’s easier to convince people to play your game since you don’t have to prefix it with “First, buy a copy of Half-Life 2.” Another upside is that Epic runs their “Make Something Unreal” competition periodically, the prize for which is a commercial license for the engine and a huge sack of cash. Now I personally am not averse to a huge sack of cash and I can point to a number of companies that have been built on this strategy, so this sounds like a good deal even though there’s plenty of competition in that area. There are other modding engines but I think these are the two big ones, and the conclusions that I draw are that these are good avenues to go down for game creation, but you basically need to strike gold if you’re going to get anywhere profitable with modding.
Besides, a couple years ago “indie” became the new “modding.” It used to be that two or three guys could get together and change a couple things around to produce a cool game in a couple of months. I used to work on The Specialists, which was produced essentially by one guy (not me) with one or two other people helping in a matter of months, and for a time it was the most popular Half-Life mod. Counter-Strike and Day of Defeat are similar stories. Ever since Half-Life 2 was released and the Source engine came out, that story has changed. Now the amount of work to make a AAA-quality game has exploded and mod teams just can’t keep up. That relegates the one and two man teams to working on indie games, focusing on design and gameplay over competing graphically with the AAA games. As such there’s a number of engines you can use, none of which I’m extremely familiar with. Unity has its new web thing, Torque and ShiVa seem to be dying these days, and then there’s a bunch of open source 3d engines. If there’s competition in modding though, there’s even more competition in indie games. We haven’t even gotten into the 2d platforming and shmup style games, of which there are literally shit-tons. You can take a look at this short video of over 200 free games to see what you’re competing against if you want to make an indie game. Shining against that backdrop is going to be a challenge to any game designer. For every iPhone game that makes a lot of money there are quite a bit of good, fun iPhone games that simply never see the light of day, because nobody famous ever links to them in their twitter.
Ultimately I feel like any of those paths is like playing roulette. It’s possible to have a really nice game that simply never gets seen. In modding your goal is to get picked up by a big company and that involves a good deal of luck. Showing a promise against the sea of commodity games can also be difficult. So where’s the solution? Part of the problem is a failure of imagination. You’re not going to be successful unless you can offer something that hasn’t been there before. The problem with game engines though is that they tend to only offer things that have already existed before, leading the developers of those engines down the same paths others have already tread. Portal required extensive expansions to the Source engine to be able to interact and view portals properly, and its source material (Narbacular Drop) used a custom engine. World of Goo was built from scratch using existing libraries but no single game engine package. The validity of the standpoint of using a custom engine can’t be argued with games like Minecraft. I can’t decide if the author of that game, (known on the internet as Notch) is a diamond in the rough or a genius game designer with too much on his plate. Minecraft is a fun cooperative building game, but his focus on Dwarf-Fortress style survival gameplay seems to be hit or miss. In any case, I don’t see an avenue for Minecraft having become as popular as it was without the web-based Java deployment that it employs. I also don’t see it happening from a technology standpoint in any existing engine. So the argument for custom engines becomes stronger. Incidentally this is the path that Digitanks takes. Using a custom engine let me prototype quickly and add things like terrain deformation that would have been quite difficult in other engines.
But doesn’t this fly in the face of standard business thought? What ever happened to the idea of reusing code? The whole point of having game engines is so that you can save yourself a lot of work. Imagine the mass of code that gets duplicated every time someone starts a new project, like physics, localization, rendering, and networking. Aren’t I creating a huge amount of work for myself by not standing on the shoulders of giants?
Well, yes. None of this should really come as a surprise. My grandfather always told me that anything worth doing is going to be hard. (That’s a lie my grandfather doesn’t speak English that well.) I still make a conscious effort to take advantage of work other people have done. I’ve covered this on the blog before. I use other people’s network code, rendering code, and so on. But there are parts of Digitanks that are so different from other games that it’d probably actually take longer for me to rework another game engine to use them. I used Source for years, and before that I used Half-Life, and before that I used Quake. I could have developed Digitanks in Source, and given my familiarity with the engine it probably wouldn’t have been all that challenging. If I did that though I’d be playing roulette. To succeed I would have pretty much needed to be picked up by Valve, which is a huge gamble. So I’ve taken the lesser trodden path. That comes with a completely different set of problems that I have to face, like building my own community, and getting people interested in an unknown indie game, but it’s a set of solvable problems that I’d much rather tackle than taking a chance at a throw of the dice with the bigger engines.