Search the Community

Hey, everyone! As you may have noticed, this took quite a bit longer than we expected, for a variety of reasons. We'll get into some of that later - for now, we've got some pretty big changes and updates to share! Renderer Switch (the sequel) You may recall in our previous announcement that a large focus was placed on switching to Ogre (specifically Ogre-NEXT). At the time - again, keeping in mind that so far, this is still a one-man show - I felt that writing shaders from the ground up was a bit too far outside of my skillset, and given my general challenges with math stuff in the first place, I wanted something that had native support for materials and PBR and such. So it may come as a bit of a surprise that, after all of that time - we're now switching away from Ogre entirely, and going with a fully custom renderer built on top of, once again, bgfx. This decision was not taken lightly and came as a result of a number of things all converging together that tipped the scales. Why switch? First and foremost, there was a bit of ongoing issues that kept cropping up with Ogre, mainly crashes here and there, as well as a persistent crash during shutdown. These are almost certainly something that I've done wrong and part of an issue of how I'm using it - but that pretty cleanly takes us to the next issue. Given that we wanted to have our own classes and objects in many cases that abstract Ogre away - this resulted in a lot of cases where there was always this additional layer between the game engine and Ogre. For instance, any object in 3D world space inherits from BlamWorldObject, and each one would reference an Ogre::SceneNode - with attached meshes or lights or whatever else depending on the type of object. This works, but also due to how Ogre itself is built, presented some challenges of its own too. One of our goals is to make as much of the engine as thread-safe as possible, the goal being that the engine won't thread-lock or crash when manipulating objects or running code from various threads, allowing developers to take advantage of multi-threading as much as they see fit, and ensuring the engine itself doesn't make this process a painful one. Ogre is not designed as such - and so often there were many cases where we just had to build these things in ourselves. Abstracting away object positions/rotations/scales behind Get/Set methods is one example - as if you tried to modify an Ogre SceneNode transform from anywhere other than the render thread (or even if you did so later in the render process), you'd get an assertion failure or other error. Another big issue came up when we started exploring 2D rendering - we wanted to implement support for tilemaps, which we wanted to be able to support multiple texture sources. Trouble is, this is where Ogre's high-level material system actually becomes a hindrance. In bgfx, this process would be as simple as a single function call before submitting the geometry. Ogre makes it so that, seemingly, we'd need to create an entirely new HLMS specifically for this use case. Custom shaders suffer from a similar problem too - we were having to modify Ogre to have better error handling for invalid shaders, the idea being that the engine shouldn't crash if a shader is broken, it should just warn or fall back to something else - which would at a minimum be required for having a proper shader editor with a preview, as if you messed something up at any point - the entire engine would go down. These issues gradually crept up over time, and it eventually reached a point where I decided to once again explore the possibility of building a new renderer with bgfx. Something where I can avoid a lot of this extra complexity, and something where even if it wasn't perfect, it'd be good enough that it could be iterated on and improved over time. AI (non)-Slop The last thing that fell into place that ultimately enabled this plan - is the ongoing progression of AI/LLMs. This may or may not be a bit controversial depending on your stance - but given the capability of some frontier models (particularly Claude in our case, especially Opus 5.5 - though we started this back when Opus 4.7 was the latest version), we've found that it's been extremely capable and competent. It may also be worth clarifying - while I will often write "we" out of habit and to refer to the studio, in reality - "we" is really just me. There are no other developers on the project (though we'd love to have some if you've got some time!) - and I don't exactly have the budget to hire people properly, nor the free time I had a few years back. And in areas like this - where it's very math-heavy stuff that I just have a tough time with - I felt the best move ultimately was a purpose-built renderer designed for the engine itself, that can be iterated upon down the line, rather than a heavy library that is mostly out of my hands. The time savings alone are, for me, one of the biggest draws to these kinds of tools. It took probably ~6 months or so of off-and-on work, with me working ~48hrs a week otherwise to keep myself afloat, and in that time I was able to, using Claude, build a renderer from the ground up on top of bgfx that, while imperfect and isn't quite as performant as I want it to be, is already outperforming Ogre in some tests I've done - and is something that is small enough that it can be iterated on. And if I'm being honest - after 10 years since the engine's C++ project was created on my old computer, at the rate things were going - there was no world in which I was going to be able to achieve this on my own in any reasonable timeframe. I'll also add - this renderer was not vibe-coded, at least not in the typical sense. A lot of code was written and authored solely by AI, but it was done so following the existing code style guidelines and organized/structured how I would've done it myself (in terms of what classes/types are named, how stuff is broken up across files, etc). It was a much more involved process than the stereotypical "hey claude write me a PBR renderer" - this has been thoroughly tested as much as I can as one person, and has been designed around an engine and feature set that is entirely my own. Going forward, I'll likely continue leveraging these AI tools in order to hopefully have development be a bit quicker than it has been thus far. We hopefully also won't be doing any major changes to the engine's tech stack anytime soon - since now its on a foundation that exists within the engine itself. We will however be continuing to flag any new classes, methods, or functions that are AI-written with an @author attribute, which is visible in both the code itself as well as Doxygen. If you're one of the folks who are disappointed reading this, due to finding deep moral issues with AI stuff - I do understand - especially given that the most visible cases of AI are either intrusive or of poor quality. I would however encourage you to reconsider, particularly for cases like this - a lone developer with a fairly tremendous scale of a project, using such tools to essentially make up for the lack of resources. The alternative in this case wasn't going to be hiring a developer - it was going to be me, independently continuing this project on my own free time, a resource which has only become more scarce in the past few years. I'll also make it clear that we will never be using AI for art or visual assets - those will continue to be either created by me or will be acquired from some 3rd-party site (either an asset store, online web source, or a marketplace like Fiverr, or something of the sort). When it comes to the programming side of things, however - we don't expect to stop using such tools. We'll be using them more conservatively than some - we aren't looking to create the AI Slop Game Engine®™© - we're just looking to build Blamite, but at a rate where it might be usable for real game development within the next decade . If even that is a deal-breaker for you - then fair enough - in that case I'd highly encourage you to check out Godot, as I've found it quite capable and dead simple to use - and it's free and open-source as a nice bonus. The New Renderer As mentioned before, our new renderer is built from the ground up on top of bgfx. Right now, we're primarily supporting OpenGL, but we're already working on getting some refinements in place to ensure that D3D11 and Vulkan are up and running as well. We did consider making this more of a priority for this release, but we felt that getting a release and a development update out first was a bit more important given just how long it's been. The new renderer is a proper deferred renderer, with Forward, GBuffer, Lighting, Postprocess, Shadow, SSAO, and UI passes as of now. We'll likely be continuing to expand things over time as well. Either way - let's go a bit more into some of the features it has! PBR (Deferred Shading + Forward Pass) and Instancing First and foremost - the backbone is, as we've mentioned earlier, a deferred renderer. Its implementation of PBR has many of the same features as Ogre (though not all as of yet). The existing material tags are still used and behave in much the same way, though a handful of fields are no longer used by bgfx. Most of these fields will likely be removed entirely, as they were setup based on the various properties of Ogre's PBS HLMS datablocks. Instead of the datablock system that Ogre uses, this renderer instead is a bit more simplistic - material parameters are "baked" when first loaded and/or when reloaded, and get used that way - which avoids repeating texture or tag lookups. Additionally, multiple instances of a mesh are batched together and submitted in one draw call, massively improving performance when drawing many of the same object. This is also a use case where we actually achieve better performance than the equivalent with Ogre. For transparent materials, a Forward pass is also implemented. This is the newest and roughest addition - it functions quite well, but performs poorly - though this is something we'll be working to rectify as we continue development. SSAO (Screen Space Ambient Occlusion) Another fairly immediately obvious feature that we've added in, is SSAO - which all on its own helps improve visual quality. You can compare a couple screenshots below with it turned off and on: Fog Another feature now supported is a simple one - fog. Available in Linear, Exponential, and Exponential Squared varieties (pictured is linear and exponential squared, with different options): Surface Shaders (Custom Shaders) A fairly significant introduction is the surface shader system. This is essentially equivalent to how other engines (with Godot being a fairly close example) handle custom shaders. These surface shaders allow for vertex and fragment shaders to be written which run inside the deferred pipeline. Truly custom shader programs are partially supported too - but will initially be limited to the forward pass (though we hope to see if we can change this later on) and are intended primarily for advanced use cases. Other New Features Despite the renderer being the star of the show - it isn't the only change we've made since our last update, far from it. Some of the big highlights include (but are not limited to): Faster scenario loading - There was actually a leftover artificial delay between load stages, forcing scenarios to take longer to load for no actual reason Prefabs - These work essentially the same as you'd expect them to in Unity - they're collections of objects which can be created and then later reused as a single standalone object Project Tag Classes - The engine now properly separates built-in tag classes and project-specific tag classes automatically, and will automatically ensure tag classes are registered in the engine - meaning you can simply author them in Guerilla, save and export, and get to using them right away So... why did this take almost 3 years? A fair question - and with a pretty wide range of answers. First and foremost, I had some personal life events come up starting in 2023 - mainly that my financial situation got a lot more dire, and I had to get some proper employment after taking arguably a bit too long of time being unemployed. This was a bit of added stress for one, and also of course meant I didn't just have an endless amount of free time to work on things. This has been ongoing of course through the present, and there really isn't gonna be much room for that to change anytime soon. Additionally, fairly shortly after the last development update, we started development on Sandbox - which is a 2D top-down sandbox project, as the name implies - which ended up with a substantial amount of development time being spent towards it as well. And of course - we have been continuing to work with Ogre during this time as well, only relatively recently deciding that it was time to make the switch. What's next? This is the real exciting part. First and foremost - we've released a new build of the engine today. Similar to how last time, where we left in the legacy D3D11 and bgfx renderers in place as an option, for this new release, the Ogre renderer has been left in as well. The first thing we're doing after this release is completely removing Ogre from the engine - leaving only our new renderer. From there, we'll be continuing to iterate and make some additions and refinements to 3D and 2D. We want to add a bit more visual effects, refine some of the existing systems (such as UI), and likely explore other features that Ogre had but that we didn't use yet - such as decals, particles, and terrain. On the 2D side, we'll be working on refining tilemaps, getting support for other 2D objects like sprites, as well as working on expanding support for UI controls and having some good starter widgets (like more layout boxes, buttons, panels, etc). On the editor side - it's still pretty far from being a fully-featured editor that you could actually use effectively. It can work for some stuff, but its very clunky in some areas and is nowhere near game-ready - and so this too will be an area of focus. One other thing that we've also decided on with this, that sort of started this whole renderer migration again - is Sandbox. Originally, our plan was to build it using Godot - as we felt that this would be the easiest/fastest approach to get a game developed and released within a good timeframe. At the time, we felt we could get from start to finish in a year or so (). However, we ran into some of the same threading and performance issues there as well. In particular we wanted to have a multi-threaded chunk generator - but turns out Godot doesn't really let you modify tilemaps from other threads, so this ended up killing off that idea. And ultimately the solution we decided on was to actually start fresh and build Sandbox in Blamite. This gives us a chance to fix some of these issues, allows us to use C++ for scripting (as that's currently all we have - though we'll be adding C# in later), allows us to maybe clean some of the codebase up and do things a bit better than we did last time in that regard, and - of course - gives us a real project in the engine that we can start building fairly soon. We've got some other ideas too for 3D projects that we want to develop concurrently - but those are a bit too rough for us to commit to at this time (and realistically is gonna be a lot further out). To close out, we've provided a link at the bottom of this post to the Blamite gallery page, which contains a bunch of screenshots that we've captured during the engine development. All of the ones recently that show the warehouse environment are ones taken with our new renderer (barring ones where things look very broken - those would've been tests to see how ogre dealt with the same scenario), and gives you an idea of what's possible today, right now. We absolutely plan to get some fancier stuff in the future, with some real outdoor environments - but there's a lot of work yet to be done for such environments to be achievable, so we started with this. At some point we do hope to release the tags for this environment as well - however it relies heavily on Quixel assets and materials which we can't just freely redistribute. We're looking to see what we can do to work around this (maybe releasing the non-asset tags, plus a script that can take all the zips from Quixel and extract them to the right spots and import them into the engine, allowing users who own those assets to grab them and get everything back). When we do so, we'll either leave a comment on this post or make a separate announcement somewhere. For now, though, that's all we've got! Be sure to check out the gallery, as well as the link to the latest engine build to check it out for yourself! Blamite Gallery Latest Development Build

Hey, everyone! We have a new project to announce! This one being far more ambitious than any other project we've ever done. That project is the Blamite Game Engine. Now, I know what you guys must be thinking. Over the years we've been announcing project after project, with so far none of them being public. It seems like a joke, like we aren't taking any of it seriously. But this one is different - not because "oh, we're actually working on this one" or anything of the sort. Raven Runner and Project: Infinity have both been worked on since their inception. The thing with Blamite is that it will be the engine for Project: Infinity, as well as all of our games going forward (with the exception of anything that is released before its completion of course). So, why the change? What happened to Unreal Engine? Good question. This decision was made after going back and forth between a custom engine or Unreal. And while, yes, going the Unreal or Unity or any other "ready-to-go" engine would have been a much quicker route, and would at least be something to help us offset the fact that, compared to other projects like Installation 01 or Project: Contingency (two other fan made Halo games, you should go check them out and support them too), it isn't the route we are planning to go. From what has been seen with these teams, they don't seem to have much planning on what comes next for these people. Some of them will probably stick together, but the Installation 01 team themselves have said that they will more or less disperse after that project's time ends. Project: Contingency has not made such statements as far as I'm aware, but it's safe to say that these guys aren't really going in for the long haul necessarily. This isn't necessarily a bad thing really, as some of them will probably get a fair amount of attention by other industry giants and I suspect they won't have much difficulty getting jobs after the fact. Here at Elaztek, we aren't here for a one-hit-wonder. We are here for the long haul. We aren't here to push out one or two games and fade away, we are here to last. This engine isn't going to just be used in one or two games, it's going to be the foundation for all of our games going forward. On top of that, there are real technical reasons as well. First off, by using a custom engine, we have a lot more control over everything. We can choose how we want to store game data, we can choose how to distribute tools, we can change anything we want - it's our engine, and we can do literally anything we wish with it. If we find a bug, we can fix it. If we want a new feature, we can add it. If we want to support DirectX 11, OpenGL, and Vulkan, we can do it. Beyond that, we also have a strong passion for modders. We love when community members create content and expand upon their favorite games, taking them further than ever thought possible. Our marketplace will allow mods of any sort - as long as they aren't cheats, viruses, or anything else malicious of course. We support creativity, not ruining people's fun. If you develop a mod that uses crazy file patching of the actual executable and you need to provide 6 paragraphs of tutorials, you're welcome to distribute it. Got a cool tool that introduces some new features? Awesome! Just note that as a user: we aren't liable for any damages to your game data, account, or anything else as a result of using mods. We can't screen every single one for perfect integrity. If you do find something malicious, do report it to us immediately. But I seem to be getting off topic. The point is, Blamite is being built to enable modding. Not every single game will support it, of course. But we (for the most part) won't take steps to stop you from playing with a game you either obtained free of charge from us, or one you paid for. What exactly is this engine going to do? Our engine is being designed to operate similarly to Halo's Engine (unofficially known as Blam), and use many of the same basic ideas of operation - with some of our own blood mixed in, of course. Our goal is to make it where those used to creating maps for Halo Custom Edition or Halo 2 will find themselves in a fairly familiar environment, as well as make modders feel at home when doing some simple tag editing within a map. Now, I know what you're thinking. This has got to be illegal as hell. We believe that Blamite is legal for the same reason ReactOS, ElDewrito, and other projects are legal. Halo's engine is not sold on its own, only games made with it are sold. On top of that, we have a strict policy against using any reverse engineering to decompile official game executables. We don't use any official code - decompiled or leaked somehow - from the official games. Period. If you happen to be a Microsoft or 343 Industries employee reading this, and you determine that our work is ultimately not within legal bounds, we are more than willing to cooperate and reach an agreement on how to proceed. You can reach us by using our contact form or via emailing us at [email protected]. But the real question is: why? Why start this project that has a chance (albeit an incredibly tiny chance based on our understanding) of getting shut down or massively hindered by "The Man"? Passion. We are developing this for the same reason we are developing Project: Infinity. Out of passion. The Blam engine is an incredibly fun engine to play with, and with our first project being Project: Infinity - a fan made Halo game, it's a match made in heaven. Beyond that, we plan to continue to develop and update the engine from here on moving forward. How can I help this project? Want to help? Great! We have a huge amount of open positions at the time of this topic, since the project is still in very early stages. If you want to help out, you can click here to go to the signup page. Keep in mind that, like Project: Infinity, you will not be paid for work on this. This is being handled the same as Project: Infinity, partially because of the fact that this is being made for Infinity initially. We are mostly looking for those with experience in modding official Blam games (any game, preferably within Halo 3 to Reach, however any is really accepted) or those with experience in creating Halo Custom Edition content and working with the editing tools (Sapien, Guerrilla, Tool, etc). If you happen to just be a programmer with a love for Halo, that's cool too. If you're just a programmer looking for something to do, just understand what this engine is. Regardless of your status as a Halo modder, content creator, or just a fan, you will have relatively strict guidelines on how to develop the engine. As in, you will for the most part be making things work and operate in the same way the official Halo games load content. If you don't know how this works to begin with, be prepared to be educated (by someone, nobody in particular is in that role yet) about the ins and outs of the engine. Modders and creators will be at a strong advantage as they will already understand more or less how the engine operates. Relevant Links We have added some new sections to the website to help account for our new project, and all relevant links can be found below: Blamite Game Engine - Official Site Blamite Update Notes Blamite Development Blog Blamite Subforum Blamite Team Signup Page So, what's the plan? As the engine matures and grows, major updates and improvements will get their own announcement, with smaller, less significant updates being posted more frequently to the development blog. Changelogs for versions can be found in Blamite's update notes blog. What are your thoughts? Are you excited for the future of Elaztek and Blamite, and the future of all our upcoming projects? Do you think this is the dumbest thing ever? Let us know!