haloman30

Howdy, folks! We've got an unexpected and exciting announcement: We're announcing another project - a top-down 2D sandbox title, made using the Godot engine. If you've been around for any length of time, you've probably got questions - so let's dive right in. What is this Untitled Sandbox Project? As stated before - this game is a top-down 2D sandbox game, similar to things like Minecraft or Valheim, or Terraria to an extent. Right now, it's fairly early in development - however, despite that, there's a lot more to see than what we've had to show with Blamite thus far - at least in terms of anything resembling gameplay. However, you're probably wondering: why? What made us decide to switch gears from Blamite and start on yet another different project? Well, first and foremost - we want to be clear that Blamite isn't going anywhere. It's not cancelled, nor is it being shelved to collect dust forever. We're still excited and intend to continue working on Blamite going forward. As for why it is we decided to temporarily focus on this instead, there's a couple big reasons: Funding You've likely noticed that we don't exactly pull in a ton of funds, which makes sense since we don't have anything to sell just yet. This was one of the starting points of conversation for a project like this: what is a project that I, as one person, can feasibly create in a relatively short span of time? The best case scenario would be that I can focus on it (and Blamite) much more if a project such as this were able to bring in enough revenue to take the place of my full-time job, or perhaps even enough to have some form of paid team members to help those projects move along at a more constant pace. At worst, however - it's still going to be a great benefit in many ways. It gives me some real experience in both developing a game, getting a real sense of what things I might want to consider including in Blamite - but also just understanding what it's like to ship and support a product. It also is a real project I can put on my portfolio, which may help me get into a better paying job than the relatively low-level work I've been able to get thus far - which in turn would also provide more funding to Elaztek, allowing Blamite and other projects to receive some actual funding and help them move along a bit quicker. Development Time One of the benefits of creating a game like this (and in an existing engine) is that, of course, it'll lead to a much shorter development time. Blamite is making good progress, but it's nowhere near game-ready as of yet. Along with that, I've managed to become fairly decent at texture work when it comes to pixel art - which, combined with everything else, means that I could feasibly create this project, as one person, perhaps even within the span of a number of months, maybe a year tops. The clearest illustration you can see of this is in what we've got done thus far. What you see is really just a week and a half's worth of work on my part - and during weekdays, I've only got a couple hours to put in. This same line of thinking on our part previously led us to (briefly) consider another project - one that you'll find and see some leftovers from in the first build of this project: Stripper Run. If you want all the details and backstory on that, check the spoiler below. In future builds, these holdovers will be removed - but we figured it'd be fun to leave them in for this first pre-alpha build. Why Godot? What about Blamite? While we've gone into it earlier, we'll expand on it a little bit further: right now, Blamite just isn't ready for game development. It's made good progress, but it's got a long way to go. With one of the goals of this project being a short development time, using Blamite for this just isn't feasible. But as also stated before: this does not mean that we're ditching Blamite and that we'll be using Godot going forward. Our intent is for this to be a once-off, and for all games beyond this first title to be made using Blamite. We do plan to continue to support the Sandbox project for many years to come, but for any future games, we plan to stick with Blamite. We could've also used Unity, but due to their recent licensing changes and violations of trust (which yes, have been largely rolled back now, but the trust issue remains), and due to genuine technical issues we had trying to get pixel art GUI to display properly at all, we find Godot more preferable. It's free, open source, and we don't owe them any royalty fees - and it just so happens to work better in our case. When can I play it? That's the cool part - as you might've worked out from us mentioning a pre-alpha build earlier, you can play our first build right now, for free! These development builds we share will always remain free, but keep in mind that in the future, once we reach what we'd consider to be an alpha stage, we will start requiring purchases. That being said, we also plan to have a pricing model similar to what Minecraft had - where if you bought it during Alpha or Beta, you'd end up getting a discount. As such, once we reach Alpha, if you choose to buy it at that point, you'll own the game - and you'll get all future updates from then onward. Similarly, we also do plan to allow legacy versions to be played, also much like Minecraft - so if you buy the game at a later date, you'll still be able to go back in time and play those old Alpha or Beta builds if you'd like. For now, though, these initial builds will be free - and they'll remain free even once we reach Alpha. To check out all available builds (both this first one and future ones we publish), check out this page. If you'd like to keep up with our development progress, we've made the Sandbox stratagem page public viewing - just like with Blamite. You can check that out here: https://elaztek.com/stratagem/projects/5-sandbox/ To wrap up, we'll share some screenshots we've taken during this first development period - from the start of the project to now. Enjoy! If there's anything you'd like to see in the final game, be sure to let us know on our Discord or here on the website!

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