Time for my first technical blog post in a long time. This is the first in what’s intended to be a series about the design and construction of Metis, the 2D game engine I’m developing to make Vacant Sky: Awakening. I hope it’ll be interesting to fans of the series as a behind the scenes look at the game as well as educational to people who want to know the process of developing a game engine.

Keeping these two audiences in mind, this blog series is going to feature both high level explanations for the non-technically-minded as well as some in-depth stuff (maybe even code!) for the programmers out there.

Getting started

By far the most common first question people ask when building their first game engine is “where do I start?” A good starting point is to look at what exactly a game engine is. Wikipedia says:

author=Wikipedia
A game engine is a system designed for the creation and development of video games. The leading game engines provide a software framework that developers use to create games for video game consoles and personal computers. The core functionality typically provided by a game engine includes a rendering engine (“renderer”) for 2D or 3D graphics, a physics engine or collision detection (and collision response), sound, scripting, animation, artificial intelligence, networking, streaming, memory management, threading, localization support, and a scene graph. The process of game development is often economized, in large part, by reusing/adapting the same game engine to create different games, or to make it easier to “port” games to multiple platforms.

That’s actually a better definition than I was expecting and it touches on just how complex game engines are. If you look through the list of game engines on Wikipedia, you’ll see that they fall into two types: general purpose and domain-specific.

General purpose game engines are generic in the sense that they’re designed to make any type of game. Unity3D, Flixel, and Game Maker are good examples of general purpose engines. They provide lots of common functionality but aren’t geared toward any one specific type of game.

Domain-specific game engines are specialized toward developing certain kinds of games. The most well-known example is probably RPG Maker, which is pretty self-explanatory. There’s also Adventure Game Studio, Unreal, and Ren’py. Each of them have an intended genre in mind and provide highly specific feature sets to facilitate the development of that genre. Typically, working outside the intended genre in a domain-specific engine is very difficult (anyone who has tried making an action game in RM knows what I mean).

The first question to ask is what kind of engine do I want to make. Intuitively, you might think that a general purpose game engine is always better because it’s more flexible, and you might be right if my goal was to make a game engine. However, it’s very important in developing software not to lose sight of what your actual goal is. My end goal is to develop a specific game, not to develop an engine. The game engine is a means to an end. Never lose sight of that. A lot of beginning game programmers want to make a game but lose sight of what they were originally trying to accomplish as soon as they start programming it. Always keep in mind whether you’re trying to make a game or an engine.

In my case, the reason I’m developing an engine at all is because I tend to make games within a specific genre (visual novels and RPGs) and I can see myself needing certain functionality in future games. With that in mind, the goal is to make developing these games as easy and pain-free as possible. That’s why I’m choosing to make a domain-specific engine.

Now that I’ve decided that I want to make a domain-specific game engine, the next question to ask is what features do I want it to provide.

Design requirements

What do I need this engine to be able to do? Well, let’s look at common tasks that I’ll need to complete in making an RPG:

-Saving and loading game state
-Displaying dialog
-Writing and reading map data
-Writing and reading battle data
-Authoring and running enemy AI
-Showing various menus
-Writing cutscenes

Most of those are pretty straightforward, except for the last one, which I’ll come back to in a moment. Since these are the most common tasks I’ll be performing in the development of Awakening, I want to make these as easy as possible.

In addition, let’s look at what other requirements I have for my game:

-Cross-platform (PC and mobile)
-Updating and downloading additional content

Now that we know the requirements that this engine must fulfill, it’s time to look at them and see what they tell us about what direction the engine should take. Fortunately, most of these requirements are fairly straightforward and can be accomplished in almost any engine. The two most restricting requirements are cross-platform portability and cutscene authoring. In fact, the need to fulfill both of these requirements is one of the biggest challenges in developing this engine.

Since the next topic is quite complex, I think I’m going to end this post here. I know it wasn’t particularly exciting, but the next post will touch on a topic that will hopefully be of more interest: authoring cutscenes.