The development of HactEngine started out of a desire to learn game development. When we started making it, we didn't even know what a vertex is, but now it has become a part of our daily vocabulary.
This blog post is part of an "introductory" series about HactEngine. This second issue tells you about HactEngine's past and how it has gotten to where it is now. If you haven't already, we recommend that you read the first part before this one.
HactEngine's development started in early 2012. The main reason we decided to develop our own game engine, was that we wanted to learn as much as possible about game development. And we've learned a lot.
The following is a somewhat chronological account on what we've been up to for the past 2 years.
HactEngine has gone through a few major rewrites. The first version was written in Java and used the Lightweight Java Game Library (LWJGL).
We chose Java because we thought it would make writing a cross-platform game engine easier. Personally, I like the idea of the code running in a virtual machine, so that the programmer doesn't need to care about platform-specific stuff. This is part of the reason why we later started using Lua.
We chose LWJGL because we chose Java, and there weren't a lot of other alternatives. And because we like Minecraft.
However, Java was a bad choice performance-wise, although that probably had more to do with our inexperience than the language or the virtual machine it runs on. Nevertheless, we soon abandoned that version of the engine.
We decided to start fresh and use C++ for the core of the engine. We also decided to focus on one platform (Linux) and expand to other platforms later. We should have realized earlier, that by not using platform-specific libraries, we could quite easily convert the engine to multiple platforms.
Around the same time (2012), support for C++11 was improving a lot. This brought things like cross-platform threads and other cool stuff into the C++ standard library, so we had to rely less on external libraries. We briefly used Boost, but C++11 soon had all of the features we were using.
When we began writing the C++ version of the game engine, we chose the Simple DirectMedia Layer (SDL) for graphics, input, audio and whatnot. And it sucked.
It doesn't really, but we thought it did, because we really had no idea what we were doing. We didn't know what shaders were, so we were stuck using SDL's 2D "blitting". This was fine for basic 2D stuff, but we knew we would eventually have to find something more powerful. SDL wasn't particularly easy to get into for someone like us, who knew absolutely nothing about game development. But the reason why we started building our own game engine was to learn all of this stuff. The hard way. :)
Still, we managed to do simple sprite based animation, we had our own basic scripting language and simple collision detection. Despite how simple the engine was, we could actually make a demo for a simple adventure game. This was exciting, because we had made all of it by ourselves.
Our own scripting language
The original version of the engine had all of the game's logic directly in the engine's code, so it couldn't be reused for another game.
Our first foray into scripting languages was to create our own. And it was horrible. Still, it was better than having a game engine without a scripting language.
It was XML-based, which isn't a pleasant format for coding. Also, because of the way it was loaded into the engine, every change in the script required a reload of the entire engine. But it taught us a lot, mostly about how not to implement scripting in a game engine.
We wanted to integrate editors into the game engine, to speed up development and reduce the repetitive, manual tasks, which accounted for a lot of our development time.
Qt also seemed to have all of the functionality we needed from SDL, so we decided to switch altogether. At the time, neither Qt nor SDL had support for Android or iOS, although both had support in development.
Switching to Qt was also how we were introduced to shaders, because Qt didn't have support for the (deprecated) fixed function pipeline in OpenGL. At the time, we had no idea what the fixed function pipeline was, what shaders were and what the difference between them was.
Our graphics system was sprite based and we were just drawing quads. It was simple and seemed good enough for what we were doing, which is probably why a lot of people learning OpenGL are wondering why the fixed pipeline was removed.
It didn't take us too long to get things working again, and shaders were a revelation to us. The performance difference wasn't noticeable, because our graphics were so simple. But we realized that our graphics system was going to get a lot more complex (and prettier), because shaders provided a lot of opportunities for expansion.
We managed to make a small game demo with our own scripting language, but it had taken far too much work for the simple puzzles the game had. We started looking for a proper scripting language and decided to use Lua.
We had never used Lua before, but it turned out to be a fantastic language. It's one of the fastest scripting languages available, it runs on just about every platform and it's very easy to learn.
Lua is a very simple language, but its simplicity allows for extensions and a lot of customization. It also has a lot of users, especially among the game development community.
The road forward
You might have already read the first part of this series, which tells about the current status of HactEngine. In the next part of this series, you can read about our plans for HactEngine's future. It will also contain some info about HactEngine's alpha release, which is scheduled for late 2014.
Unfortunately, it will be a few weeks before the third part of this series. We've been quite busy with getting ready to establish our company and we also want to expand the blog to different types of posts. Follow us on Twitter to hear when the new post is up!