Game Engines

Game engines get a bad rap. If you’re a game development company and announce that you are creating a brand new game, and follow it with, “I’m using GameMaker to make it” then the excitement quickly subsides.

Why? Well, to begin, a quick explanation of game engines are in order for those that are unfamiliar. Game engines are pieces of code that glue a game together. You create the engine, which defines how objects interact, how they are drawn, the physics behind everything, etc. Once the engine is done, you have the core of the game. From there, you add on graphics, sound, storylines, scoring system, etc. to complete the game.

As you can imagine, once the engine is done, which really is the hard part from a technical perspective, you can then create all types of different games from that same core engine. Just slap on new graphics, new weapons, new sound, and no one will be the wiser that the core engine of all this is exactly the same.

Game engines go way back. I’m sure they existed long before this, but my earliest recollection of a solid, commercial game engine was the original Doom. John Carmack, the techie behind id software and responsible for the heavy technical lifting, created the Doom engine. By creating an engine, the artists and creative talent would then never have to worry about the technical side of things. They could create the images, the animations, the sound, the music and just plug it in to the engine without knowing how it all actually worked underneath. On top of that, this Doom engine popularized 3rd party modifications, or mods. As a developer dabbling in game creation, you didn’t have to know how Doom drew every pixel on the screen, or how it detected that two objects intersected. You just had to worry about the graphics, your custom code, and the rules around YOUR game and the engine took care of the rest.

Recently, I was researching game engines and came across an indie developer who proudly, in bold letters, at the top of their website stated “We’ve created our own game engine for this. It took 18 months to create, and we are now ready to start development on <their game>”.

I just asked “Why?”. Their game was a simple side shooter. There was nothing unique about it. There was nothing done in their engine that hadn’t been done before. Yet, this small indie team of two people spent 18 months re-creating the wheel.

Nowadays, game engines are everywhere. Google for a list of game engines and you’ll get back hundreds of them. Whatever idea you have for a game, there is an engine out there that can make it happen.

Yet to this day, say “I’m using the Construct engine” and people scoff as if it’s not a real game. Which doesn’t really make sense because software development is built upon blocks, and engines are just another block to help get the job done. If you say you are using a .DLL, of course people don’t scoff. If you say you are using Windows printer drivers, they don’t scoff and would probably laugh hysterically if you said you were writing your own. So there’s always a moving line of what’s acceptable and what’s not.

This stigma is also due to the ease of use of these engines. Without any prior knowledge of game theory, or development, someone can whip out a game and put it online in no time. This means the market has been flooded with crappy games that you have to pick through to find the good ones. Engines are just tools like any other. You give a novice a hammer and they will create a lopsided cabinet. You give the same hammer to a master carpenter and they can come up with something spectacular.

It’s getting better though, for a few reasons. First, the quality of game engines are always improving. You almost always have to make compromises when choosing an engine, but nowadays those compromises are much smaller and easier to take. Second, games are big business and there is a lot of competition. The chances of your game being seen is much, much lower than it was just a few years ago so your game better be good and get some buzz. If it takes a small indie company 2 years to put out a game, and it’s not a success, they will probably have to close up shop due to the time/money invested and lost. However, if they can reduce their development time and pump out 2 games a year, then they are more likely able to come back from a failed project. Third, there are now a lot of success stories of companies using engines. An extremely popular game, Hotline Miami, was written using GameMaker. The sales aren’t released, but it’s estimated to have sold over 500k copies. Assuming $10 a pop, that’s $5 million dollars in revenue. And guess how much GameMaker costs? $600. That’s quite a return on your investment as far as engines go. Lastly, and probably most importantly nowadays, is engines provide cross-platform support. Most engines allow you the use the same codebase to distribute games to iPhone, Android, Windows Phone, Mac, Linux, Windows, Kindle, and the list goes on and on. To code support for all of these platforms from scratch isn’t going to happen if you write your own.

I’ve talked a lot about GameMaker a lot, but that’s just because it’s of the better known ones. Unity is another very popular engine. The majority of games getting funded on Kickstarter are using the Unity engine. It’s become much more accepted now that there has been numerous success stories around it. And again, Unity isn’t expensive. You get Unity3d, with all the bells and whistles and mobile add-ons, for $4,500, or a flat rate of $75 a month. Would you rather spend $4,500 and have a thoroughly tested, well known engine that is behind thousands of games on the market right now, or would you rather spend 18 months writing your own engine?

So, are engines for everyone? Nope! There are certainly cases where one might want to write their own. Game engines need to appeal to the masses to support as many types of games as possible. But perhaps a game studio’s project is so unique, so different, that no existing engine can do it justice, so they need to write their own. Another reason to write your own, is that developers like control. With pre-built engines a developer is confined to the rules of the engine. There are ways around this, such as writing custom plugins, but only to a certain extent (for instance, you won’t be able to change the rendering pipeline or other low-level items). Lastly, developers like to tinker, so writing the engine can be part of the fun of game creation. Most indie devs know they aren’t going to get rich making games, so a feeling of accomplishment knowing they created a game from the ground up can go a long way to a developers satisfaction with the process.

On a personal note, I’ve created a few games in my day, some successful, most of them not, and I’ve always struggled with choosing engines. A few months ago, I decided to forgo an engine and write my new Facebook game using just jquery, javascript and html5. What a huge mistake that was. After 3 months of development I had pretty much nothing to show for it. Sure, I learned a lot about javascript and jquery and underlying frameworks, but nothing even close to a game so I considered it time lost.

I still want to create that game, so decided to chose an existing engine this time that did what I needed it to do. So in the next post, I’ll go into more detail about specific game engines, their pro’s and con’s, and why I settled on a particular engine for the next game I’m writing.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s