Studio News
Newest Login
Choosing the Right Technology for Windforge
By on

When starting a project, one of the first questions that comes to the mind of the developer is “which technology should we choose for this game?”. When starting Windforge, we had to answer the same question and, although the decision was easy for us to make, I think it worthwhile and interesting to analyse.

When speaking of game development technology, we’re mainly referring to the game’s engine. Of course, other technologies are involved such as the operating system, computer type, server infrastructure, build system, continuous integration tools, bug tracking, etc. In this case, we’ll focus solely on the game engine.

The game engine is what delivers the experience to the user. Often, for marketing reasons companies will refer it as a 3D engine, because it speaks more to end users and it’s a great selling point, but engines are far more complex than only the rendering portion of it. Engines mainly do three things:

  1. Engines process input device signal (Keyboard, Mouse, Touch, Microphone, etc.) and translate it to game data.
  2. Engines handle game logic (Artificial Intelligence, User Interfaces, Physic simulation, Game Mechanics, etc.)
  3. Engines deliver content to user (Visual assets, kinetic feedback, music and sounds, etc.)
Game Engine Process
The Game Engine Process

We refer it to an “engine” because it is very similar in it’s behaviour to what’s under your car hood: something that takes your input (steering wheel, speed shift stick, pedals) and converts it to an experience (driving), using some internal resource (Oil, Gas, etc.).

When starting a new project, choosing the appropriate game engine plays a critical role.

The good news for developers is that there are a wide variety of options. Multiple technologies are available and developers can usually pick an existing engine without having to start from scratch every time. If the project design is the most important factor in the final decision (as is usual) multiple aspects are to be considered:

  1. Game Genre: For instance, puzzler, 2D Platformer and 3D open-space games all have very different technical needs
  2. Cost: Some engines are free to use, some have a low cost and others have a very high cost (easily up to the $1M range). While developing your own technology does not involve licensing costs (assuming it doesn’t make use of external tech), this approach has a lot of development costs that need to be factored in.
  3. Team experience: Ramping up on complex technology could hurt a project
  4. Multi-platform compatibility: Some engines are made to run on various types of devices (PC, Mac, iOS, Android, Web, Consoles, etc.), where others are targeting specific platforms.
  5. Technical Requirement Compatibility: Several platforms (especially game consoles) need your technology to follow strict technical rules. Some engines already are “compatible” and others need to be adapted
  6. Community: In some cases, support from the community or the company that licences the engine can be invaluable
  7. Source code access: Some engines are “black boxed” and developers cannot change the inner code. Others allow full-access and the ability to customize the technology. Most of the time, gaining access to the source code can be done at an extra cost. Sadly, it also means that your “custom engine” will no longer be supported by the company that sold it to you: in a way it is very similar to making modifications on your car engine!
  8. Game features: When picking your engine, you need to make sure that most of the features of your game will be supported by the technology
  9. Ease-of-use: Some engines are really hard to use, others are much simpler. Usually, the harder it is, the more flexibility it gives to the developers (but some engines are also just terribly designed). A proper evaluation of your technology with this in mind is critical to avoiding bad surprises…
  10. External tool support: Remember that a game engine is not only used by programmers. Having an engine with a simple pipeline that allows quick integration of art assets, design and UI is also a very important factor.
  11. Code language: Make sure your technology will be easy to understand by your development team, given their skill sets
Existing Game Engines

In our case, Windforge is a 2D platformer, with some cool AI, RPG features, world generation and a lot of exploration. As we are working with an “indie” style budget, all really expensive engines were out of scope. Further, because of some of the unique aspects of the game – mainly those related to world generation – none of the existing technologies could provide us with an “out of the box” solution. We therefore knew that we would need to have access to a full source code. Also, most of the modern engines’ features were useless to us:

  • Advanced 3D rendering (Advanced shaders, Lighting, Bump mapping, etc.)
  • Cross platform technology (We are PC only, which does not mean that we won’t be supporting consoles and mobile, but this is not a priority)
  • Advanced 3D physic simulation
  • Networking support
  • Advanced 3D Audio

Given these facts, most of the commercial solutions would have offered more features than we need and would have required us a lot of modification in order to enable our unique game features. Even the free solutions could not have been properly adapted to our needs.

Windforge Banner
Windforge’s Characteristics Require a Custom Engine

In the last two years, we have been prototyping some 2D games using no other technology than a simple engine we wrote ourselves. This engine was quite simple, but already had the following support:

  • 2D Rendering – with basic shader support
  • LUA script support – Allowing designers to do modification to game logic without having to change source code
  • Basic UI framework – Allowing designers easily create their UI
  • 2D physic integration – Box2D

Because the team was already comfortable with this technology and because it was already supporting several of our needs, it was clear to us that the smartest choice was to simply evolve this “Snowed In Studios” technology to the needs of Windforge. Of course a lot of effort was made in customizing the engine to Windforge’s needs, but at this stage it still seemed like the right decision. Nevertheless, we could be wrong since a lot of developers have tendencies to try to “reinvent the wheel” because they prefer to work on their technology. However, I think our analysis was well done and, in this case, working with external technology would have made things more complex.