VoidEngine is the semi-pretentious name I have given to the engine I and my wife have designed and built. The decision to create an engine for our project did not come overnight. I had looked at most of the ready-made engines already, even fiddled around with some of them to see what they were capable of.

Our requirements were not overly high. The engine needed to support 3d rendering and audio, some form of scripting and integrated physics. Some form of built in data storage mechanism would also be nice. After going through all the usual suspects I came to the decision to make our own. It wasn’t that some of the engines didn’t support the features we needed, I just decided I’d like to create our own as a learning project. My primary objective was to learn C++ and a scripting language, while doing the integration of various libraries into a cohesive system.

Enter the Void. When we were first thinking about what kind of game we’d like to make, our ideas were grandoise. We’d make an open world adventure game with multiplayer support. We worked on documentation for this project for a while. Docs piled up, mountains of features rose from the ground. We slowly realized that the project was not feasible for two people. As we did not have anyone else willing to work a full-time side job, we decided to scale down a bit. A lot actually.

Our current project involves creating a small dungeon hack style game, albeit with the intended multiplayer support. We felt that there was a niche not filled here. Both of us have played various MMOs to death, and arguably most of those offer what we intend to, but in a more confined space. We have devised a random dungeon generator with dynamic encounter generation, while most dungeons in MMOs are static, i.e. they offer nothing different on repeated run-throughs. Our engine pretty much ensures that any repeat attempt is different from the former. It also scales up by the number of people logged on to the server, so more people means greater difficulty and better rewards.

The major focus of the game is the combat system. All the other stuff is just a vehicle for melee, ranged and spell combat in a fantasy setting. What we’re really doing with this game is create a system of combat and a basic quest system that we can use for a grander scale game. The engine is open ended in that it can support streaming geometry in a future iteration. In its current form it does not do this, but I have paid great attention so as not to exclude that possibility. Thus, if we call this version “Iteration One”, “iteration Two” at a future date will support the features that I mentioned above.

I also want to have integral support for modding, i.e. user created content. The game itself will be cheap to buy and easy to mod. As it stands, it supports multiple resource “feeds” that are just location indices for resource files. All the content can be created in 3ds max using ogremax and havok content tools to export. All scripts for quests and AI are in python, a language widely understood and easy to use. The engine exports classes for inheritance in script space that give a number of functions for interaction with the game internals. The UI can be modified and added to using scripts for example. It’s easy to create new dialogs and interaction methods for them using xml (there is a graphical dialog editor as well) and scripts.

We would also like to reward modders in some form, perhaps signing mods digitally and letting them sell mods for like $1 per download through our site, where we’d take a small percentage probably. There are many business models we are looking into at the moment, though that is not what we spend most of our time on. That is reserved for the business of making the game 🙂