Choosing the Heart of Your Game

Unity, Unreal, Ogre3D, Havok – perhaps you’ve heard of these before. They are just a few of the vast amount of game development tools you can use to create games. The choice of the development tool is extremely important – the technology used will define what your game is capable of and what it isn’t. The very heart of your game should be chosen wisely.

But what exactly should you use?

This topic is extremely vast and complex. There’s thousands of tools that help you make games, starting from the very heart of your game, going over to software tools that help you manage, build, deploy your project. We will focus on the stuff games are made of: code (or the lack of it if you’re using Construct!)

You need to consider the following:

  1. What is my target platform?
  2. How about scale? How large will this game be? How fast do I want to be done?
  3. What is my motivation to make this game?

What is my target platform?

It’s important you define where your game is going to end up. Some tools or software aren’t available on every platform. A C++ game compiled on a Windows PC cannot run on a Mac, for example. It’s also pointless to ensure your game is multi-platform when you just want to play around with it. If you want to monetize your game, you perhaps want to go multi-platform because you automatically increase your market-range that way.

If you want to port your game to as many platforms as possible, you can use Unity3D, Unreal, or Java-based middle-ware libraries or software.

C/C++ usually is tricky to port: bugs exclusive to certain systems can happen, but they should be your first choice when you need optimization and performance (the case with big games).

C# can prove tricky to port, if you can port it at all.

Often, sophisticated game engines or frameworks spare you the work to convert your game into platform-specific binary files (like Unity3D and Unreal). They are usually a good choice.

How about scale?

Let’s start out with some general observations about software. These will affect development speed and the scale of your game.

  • The closer you’re to the hardware, the slower the development time: You have to code more to get the desired results.
  • The farther you’re from hardware, the faster the development time: You are using tools and software someone else created.
  • The faster I can develop a game, the more features it’s possible to implement (when comparing hardware-close and hardware-far).
  • Exception to these observations apply.

Creating a side-scroller on a GameBoy (hardware-close) will likely take you longer than creating the same one on PC using existing game engines or libraries (hardware-far).

Creating a side-scroller on a GameBoy can be accelerated if you are using development tools for it that others have already created.
When you’re using existing tools, like IDEs, libraries, frameworks, engines, someone else already did a good amount of work for you. This way you can save some time creating your own software. Let’s sum them up:


If working close to the code, IDEs (Integrated Development Environments) are inevitable. They offer you all required functionality to modify and maintain your project and code. Typical IDEs are Visual Studio, Eclipse or Netbeans. In a way, game engines like Unity3D are specialized IDEs.


Libraries complement your code. They provide a certain functionality and do not offer much beyond that (e.g. a DOM parser library to read HTML). As such, you will still have to code most things yourself. At the same time this also means you have a lot of freedom creating your game. If you’re using an IDE, you may also use one or multiple libraries in your project. Examples: JDOM, LWJGL, SDL.


Frameworks are a collection of multiple functionalities that are related to the other. They spare you lot of work and still add the possibility for low-level coding, but on the other hand, you still end up with enough coding you have to do yourself. They do not offer the same span and depth of features like engines, either. Examples of frameworks are LibGDX or Allegro.


Engines are very handy for they do most (not all) the work for you by default. They usually include some kind of interactive GUI that allows you to make changes to your game. You don’t have to worry much about how things work because chances are, they are already integrated in the engine. That means you have to do less coding, allowing you to concentrate on other things (like getting your game done). Unity and Unreal are engines you can use; but also physics engines like Box2D exist which can be integrated into your projects.

So when do we use a library, when a framework, when an engine? To figure that out, we need to know what our goal is first.

Read: Other software you can use for making games.

What is my motivation to make this game?

Is your goal to make a quick buck?
Is your goal to deliver innovation and experimental games?
Is your goal to learn and explore the art of game development?
Is your goal to create a big game and get it done?

Choose the ideal tool to create a game with! After all, your tools will affect your development speed and development ease (or difficulty).  For example, you don’t want to recreate No Man’s Sky using JavaScript from scratch, but perhaps it’s okay to use JavaScript to create quick and dirty proof-of-concepts.
Generally spoken, if you want…

  • …to develop quickly for whatever reason, use game engines or frameworks.
  • …to develop large scale games, also use game engines or frameworks.
  • …to learn it the hard way, like learning to code, figure out tech or workflows etc., use frameworks, libraries, or create games from scratch.
Dev-Method Tools Languages for From-Scratch-Games
Large-scale  Unity3D, Unreal OOP languages like C#, C++, Java, Pascal
Quick-dev Construct, Phaser, GameMaker  HTML5/JavaScript
The hard way OpenGL, SDL, LWJGL, JMonkeyEngine, LibGdx, any IDE Any programming language, but C/C++ especially


  • Some engines/libraries/frameworks are only available for certain programming languages (e.g. Phaser is a HTML5 library, while Box2D is both available for C/C++ and Java, Unity uses C#, GameMaker has it’s own scripting language).
  • I’m ignoring aspects like performance or portability here. Engines usually are suited for high-performance games because they are shipped with necessary optimizations.

Below is an overview with above software and what language they use.


  • Unreal
  • SDL
  • OpenGL


  • Unity
  • OpenGL


  • Phaser


  • OpenGL
  • LWJGL (uses OpenGL)
  • LibGdx (uses LWJGL)
  • JMonkeyEngine (uses LWJGL)


With the knowledge you have now you may find easier to chose a suitable engine from the giant lists below:

Comments? Critique? Corrections?

What other tools do you know of? Which engine or framework do you like the most?

Let me know in the comments!


Leave a Reply

Fill in your details below or click an icon to log in: 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