Blamite Game Engine - September 2023 Progress Update

Howdy, folks - it's been a long time since we've last had a proper development update on the Blamite Game Engine. Nearly 3 years, in fact - yikes.

Let's fix that.

Switching to OGRE

The most significant feature in terms of technical significance was the switch to a new graphics engine - OGRE. More specifically we're using Ogre-Next 2.3.

For those of you who have been lurking or chatting on our Discord server, you might have caught wind of some of our adventures in switching graphics libraries over the past while. From plain old DirectX, to Vulkan, to OpenGL, to bgfx, to trying some other more capable libraries such as OpenSceneGraph, The Forge, Diligent Engine, Filament, then giving up and going back to bgfx, and now finally starting to settle into Ogre. It's been quite the journey - one that we hope will finally come to a close now that we're starting to make real headway with Ogre. If you'd like to read about the journey we took to get here, check the spoiler below. Otherwise, keep reading.

While we don't have anything too fancy to show yet, we hope to change that sooner rather than later. Ogre has support for PBR, lighting, particles, and more out of the box. It's built entirely around scenes and objects, which should make it much easier for us to start to get some real visuals going within the engine - and we hope to share some of that with our next development update.

Thus far, our efforts have been centered less so on that, and moreso on building our all of the systems needed to support everything going forward.

Editing Kit

Blamite's Editing Kit (which includes Guerilla, Sapien, Tool, Foundry, and FontTool as of right now) is our toolset used for working with the game engine and creating content. Since our last major update, a lot of changes have been made.

All of the tools now use Qt 5.15 for their GUIs, rather than Windows Forms - and as such, are all written in C++ instead of C#. To achieve this, we've introduced a new library - Keystone. This library contains all of the Qt GUI code (along with all of the stuff needed to drive that UI). Mind you, this library includes all of the GUI code for all of the tools within the Editing Kit. Additionally, all of the backend code that's specific to each tool is contained within a separate library from the executable.

The result of these changes is that sharing code within each of the editing tools is painless. It means that in theory, you could edit tags within Sapien, and fly a camera around the engine in Guerilla. However, the more practical implementation that we'll be going for - this allows code for Guerilla and Sapien to be easily reused within Foundry, which will become the unified editor for Blamite - acting as a complete alternative to the original Editing Kit. Having things set up this way means that we don't have to reinvent the wheel twice over, and also means that changes can go the other way, too - if we make improvements to Foundry, the legacy tools will get those improvements, too. It also allows us to actually do things like open a game viewport from Sapien within Guerilla - which can be used for previewing render models, textures, materials, and more.

Additionally, Keystone has support for themes - which can be authored both by us, but also by you! We've set things up to allow for users to create their own themes, and we've even got documentation already available if you'd like to take a crack at it.

Beyond technical changes though, several tools have received new features compared to their C# versions - which are outlined below:

Guerilla - Tag Designer

Something that I had discussed as a sort of "nice-to-have" later on ended up finding its way in much sooner - largely out of necessity.

Previously, creating tag classes within the game engine required that developers create both a data structure, and a separate field list containing metadata about those fields. Both of these had to exactly match, and both had different purposes. The data structure is used for the tag data itself - as it allows for tag data to have minimal overhead. No need to parse through a ton of hashmaps or anything - just read the data as a tag struct and use it like any other C++ structure. The field list is part of a BlamTagClass class, and this is used to generate plugin files directly from the game engine, as well as provide things such as an in-engine tag editor.

The problem is, these two structures have to EXACTLY match - or else you can run into issues such as read access violations or memory corruption, and by extension, crashes - if you're lucky. You might not get a crash outright, and instead just get weird unexpected behavior. After a few (thankfully brief) instances of this, we decided that there was only one ideal fix: we needed a way to author a tag class one time, and then somehow have those two things generated from that. But how?

Well, the Tag Designer is how. It's a visual, drag and drop tag class editor, available right within Guerilla. It can export to the standard plugin XML format, as well as to C++ header and source code ready for use within the game engine. Not only that, but it introduces the ability for tag fields to have default values - so you don't have to populate a ton of fields with a default value when creating a new tag. Additionally, tag classes can now include both a short and long description - which will eventually be used within the tools to provide a more user-friendly tag creation experience.

Down the road, we plan to also allow tag classes to be registered by engine extensions - the idea being that if you're creating a game with Blamite, you can create your own tag classes with the designer, and while the game engine itself won't do much to them out of the box, you'll be able to use them in your own code and scripts. We believe this will become key in allowing Blamite to be used in a more general capacity than the original Halo engine - which was designed purely for first-person shooters and little else.

Tag Field Changes

Additionally, we've introduced a few new tag fields, and improved some existing ones.

We've introduced vector2, vector3, and vector4 fields - which allow for 2D, 3D, and 4D vectors respectively. Along with that, we've introduced a new type of reference field: field references. These allow for fields to store a reference to another field - which we make use of currently within the material tag to allow for things such as material input parameters.

Additionally, most tag fields have support for "input hints" - which are a small piece of text displayed on the right edge of a field, providing additional context for what kind of data is expected. This could be a range of values, such as [0,1], or a unit indicator such as world units or decibels, or really anything you'd like! 

Sapien

Sapien is still a bit rougher around the edges for now - however, it's got the basics of the Hierarchy View and Properties Palette. It also now uses its own configuration file for settings, and it's received a few bugfixes. You'll also now see a loading dialog as a scenario is loaded - rather than things just freezing for a moment until it shows up.

One somewhat significant change that will likely find its way to the rest of the editing kit is that it does not allow you to open a scenario tag directly. Instead, you are prompted to choose an available project, and then load a scenario within that project. This was done because, without the editor having the context of a project, it doesn't know how to resolve tag references - as it can't know where the relative tag root is. While Blamite is set up by default to follow the usual /levels/multi/whatever/whatever.scenario format, it isn't enforced by the engine - and you could in theory structure your content however you like. As such, we can't make any real assumptions about where the tag root is without having the existing context of a project.

For now, though, we'll leave you with a screenshot of Sapien with its default Midnight theme:
 

FontTool 2.0

For those unaware, FontTool (originally FontExtractor) is our tool used to create font packages and export fonts for use within the engine. It was originally written in C# and only had the ability to export TrueType and OpenType fonts - and it would export each character as its own image.

As we started rebuilding our UI systems under Ogre, we realized that we needed to clean this up a fair bit - as while it can support loading textures this way, it is slow. So, for 2.0, one of the highlight features is the ability to export to a font atlas - a single texture with all your characters. It's even got handy guidelines that you can toggle, so you can see just how your atlas gets split up.

Along with support for font atlases, it has an improved preview UI that is much more accurate to what you'd see in-game, and it properly respects the various export settings listed in the top part of the window. And of course - since it now uses C++ and Qt5, it should be a little bit faster too.

Other Changes

With all those changes to the Editing Kit, out of the way, let's look over some of the other less significant, but still exciting changes:

Tag Classes

Several new tag classes are now supported within the engine. These include:

• [bitm] bitmap - Used to store texture information
• [cusc] cui_screen - These store UI widgets that generally encompass an entire viewport, currently supports basic primitives, text, and groups
• [ligh] light - These allow for lights to be created and used within a level, though are currently unused
• [mat] material - These store material settings, and are used to define the appearance of a 2D sprite or 3D model - currently these support PBR and Unlit material information
• [matg] globals - These store global settings and data shared across an entire project, and currently store default materials and bitmaps, as well as the default fallback bitmap
• [scnr] scenario - These are the "entry point" for a level, and currently include blocks for primitives and project folders

Console and Debug Menu

The console and debug menu have also received some improvements. The console now supports column display in special circumstances (such as the help guide when pressing Tab), and both the console and debug menu are now noticeably faster. The debug menu now also has additional hotkey support, similar to what you'd find in later versions of the Halo engine.

What's taken so long? Why is progress so slow?

No doubt, while there's a decent number of changes described here - it may at first glance seem absurd that it's taken this long for these changes to finally happen. And, yeah - you're right.

Progress has been kind of slow for some time, in no small part due to the consistently mentioned lack of other team members. Thus far, it's essentially just been me - slowly chipping away at this thing over years. However, even beyond that - in a lot of ways, we've actually been somewhat spinning in place for a little while now.

Migrating our toolset from Windows Forms to Qt5, switching rendering libraries several times, and then migrating all of our old systems over to these new systems - it's a process. And while there are certainly new features and enhancements that have come from this, it's not entirely inaccurate to say that a lot of the work done has been retracing old steps. There's more to it than that from a technical standpoint of course, but from an end user standpoint - it's easy to see the project as making poor progress - even with the consideration that it's just one guy behind it.

You might even compare some screenshots of the engine now to some of the first ones from 2016 - and things at first glance look almost the exact same: the default blue ImGUI background color with a menu bar. There's more to things if you dig for them, and of course there's editing tools now, but it's easy to write things off as "wow, 4 years from when active development started, and no 3D yet - what a joke". And perhaps that's not even an unfair assessment

However, unlike the past while, today marks a real turning point - as today, all of the old functionality from DirectX and bgfx have been rebuilt using Ogre, and we've even gone so far as to drop those renderers from the game engine - leaving Ogre as our only one.

Going forward, our plan is to first do a bit of housekeeping - making sure everything is well-documented (which shouldn't take too long, as most stuff is already documented), getting rid of any old and unnecessary code, and making sure performance is at a reasonable spot. From there, we're going to be focused exclusively on new features - which hasn't been the case for a long time. But that finally changes now - we are finally past the point of having to perform major code migrations, and going forward - it's all about new stuff.

This leads us into the last part of this update - another development build.

With this last build, the old DirectX 11 and bgfx renderers are all in working order. As such, we thought it'd be fun to keep them around for this next development build - so that they can live on in at least some form, even if limited. You can switch rendering engines by changing the rendering_engine configuration setting (located under the rendering section) within either the configuration editor or directly in engine.cfg. The valid values to try out each renderer are as follows:

• DirectX 11 - directx11
• BGFX - bgfx
• OGRE - ogre

This marks the last build that will ever utilize these renderers - as by the time you're reading this, we've already dropped them from the codebase.

As per usual, you can expect to find plenty of bugs, errors, and even crashes - run these builds at your own risk. It should also go without saying, but the engine is currently not in a state where it could be feasibly used for game development. These builds are mostly for historical preservation for the future, and also to allow those of you interested in the project to toy around with things and get a taste of what's to come.

Our hope is that the next development update will show real meaningful progress, and that we can even include a proper tech demo to showcase what the engine can do. Is that ambitious? Perhaps - but I suppose time will tell.


For now, though - that's all we've got. If you'd like to follow development more closely in the meantime, you've actually got several options:

• Stratagem - Our trello-like board where we keep track of bugs, features, and so on
• Commits - A page where you can view every commit made to the Blamite repository, going back to 2017 when Blamite was first tracked using Git
• Discord - Our community Discord server, within which you'll find the #blamite channel, where you can effectively see progress in real-time as I type and showcase features and fixes as I work on them

As per usual, we're always looking for more folks to join our team - the more the merrier! If you're interested in joining the development team for the Blamite Game Engine, feel free to apply using the button below! You'll also find a button to take you to the download page for the mentioned Blamite development build.

 

Join the Team Download the Latest Development Build