Search the Community

Showing results for tags 'game'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Categories

  • Tutorials and Guides
    • Blamite Game Engine
    • Website and Forums
    • Miscellaneous
  • Resources
    • Guidelines
    • Troubleshooting
    • History
    • Blamite Game Engine
    • Website and Forums

Categories

  • Project: Infinity Issue Tracker

Categories

  • Blamite Game Engine Issue Tracker

Categories

  • Elaztek Launcher Issue Tracker

Categories

  • Introduction
  • Using the Engine
    • Configuration & Settings
    • Debugging
    • In-Engine Tools
  • Using the Editing Kit
    • Foundry
    • Guerilla
    • Sapien
    • Tool
    • Customization
  • Technical Information
    • File Formats

Categories

  • Blamite Game Engine Suggestions
    • Archive
  • Website/Forums Suggestions
    • Archive
  • Discord Suggestions
    • Archive
  • Other Suggestions
    • Archive

Categories

  • Volunteer Positions
  • Paid Positions
  • Submitted Applications

Forums

  • Community Hub
    • News & Announcements
    • Suggestions & Feedback
    • Staff Applications
  • Server Management
    • Support
    • Reports
    • Ban Appeals
  • Projects
    • Infinity
    • Blamite Game Engine
    • DonationStore
    • Sandbox
  • Server Discussion
    • Discord
  • Community Discussion
    • The Den
    • Computers & Tech
    • General Gaming
    • PC Gaming
    • Console Gaming
    • Tutorials & Guides
  • Area 51
    • Archive

Product Groups

  • Games
  • DLC/Downloadable Content
  • Software
  • Merchandise

Blogs

  • Update Notes
  • Raven Runner Game - Official Updates
  • Elaztek Launcher Update Notes
  • Blam Update Notes
  • Blamite Development Blog
  • Haloman30's Blog
  • Eon Blog
  • Galactiminer Update Notes
  • HealthAndMore
  • Hebe Medical Spa
  • Why Manual Testing Five Reasons
  • Breath of life
  • Employee time clock app
  • Sandbox Update Notes
  • test's Blog

Categories

  • Official Games/Projects
    • Blamite
    • Sandbox
    • Project: Infinity
    • Elaztek Launcher
    • Legacy
  • Community
    • Project: Infinity Mods
  • Blamite Game Engine
    • Tools and Utilities
    • Editor Themes

Calendars

  • Project: Blamite Game Engine
  • Project: Miscellaneous
  • Community Calendar

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Github


Minecraft Username


Steam


Gitlab


Xbox LIVE


Website URL


Discord


Skype


Gender


Location


Interests


About Me


CPU


Graphics Card (GPU)


Motherboard


Operating System


Memory (RAM)


Cooling Type


Storage


Other PC Info

Found 9 results

  1. Hey, everyone! Despite it only being less than a couple months since we first started on Sandbox, it's managed to come a long way from what we've shown previously. Those of you on our Discord server are already well aware of most of this - but for the rest of you, you might be surprised at what's happened since the project began. So, without any further delay, let's dive right in. World Generation First and foremost, world generation has been greatly improved and expanded from our earliest screenshots. Biomes are now supported, along with various ground details (which we refer to as decorators) such as small grass tufts, rocks, flowers, and things of that nature. Additionally, tile entities are implemented as well - which currently only includes a basic placeholder tree. However, these can be generated per-biome, and so you'll only find trees generating in forest biomes. The last major improvement to world generation comes in the form of what we refer to as world features - these are any sort of developer-designed structure, land formation, or otherwise that can generate within a world. Currently, the only world feature generated is in the form of an easter egg at a specific location on a specific seed - see if you can find it (hint: check the Discord chat history). With all of these changes also brings with it support for multiple worlds. We've also added a couple of comfort features relating to this - for instance, when creating a world, if you provide a string of text as a seed - that original text will be stored along with the parsed-out seed, so you can still keep track of it later on if you'd like. Additionally, worlds will keep track of the version they were last played on, as well as first created on - so you can not only see if a world was played on an older (or newer) version, but you can also see how far back a particular world goes if you were to keep playing on a particularly old one for many years on end. Inventory/UI Additionally, we've made some changes and additions to the user interface. The F3/debug screen shows a great deal more information now, for starters. But of course, we've also introduced a fully functional inventory - with items and everything! It works exactly as you'd expect. You can pick up items dropped in the world, and you can drop your own items in the world if you don't want them anymore. In the future, you'll of course be able to stash your items away in chests and containers. More broadly, a great deal of UI across the board has been introduced and enhanced. The old placeholder UI from the days of Stripper Run have all been either replaced, removed, or updated to better match the aesthetic of Sandbox. It's not perfect - and we no doubt expect to make some tweaks later on as time goes on, but you can get a sense of the sort of aesthetic we're currently leaning towards. We've also introduced new UI for things such as world creation and selection, game settings, pause menu, and the join server screen. Speaking of which... Multiplayer That's right - we've introduced multiplayer support, already! It's got some kinks that need to be ironed out - as it doesn't take much to strain the connections over the internet - but overall, it works relatively well for being in Pre-Alpha. You can either host a server locally by starting a server while in a singleplayer world, or you can download and run a standalone dedicated server executable - which you can run wherever you like. In the future, we'd love to introduce a Bukkit-like plugin API for servers - allowing server owners to have a great deal of ability to customize and tweak the experience players can have on their servers - though in this early stage, it's more of an idea - rather than a commitment we're going to stand by for sure. Character Editor A more recent development that's still very much a work-in-progress is the character editor. It's exactly what it sounds like - it allows you create and edit any number of characters that you can switch between. These can each have their own name and customized appearance. This is currently still very early on, but you can get a sense of where we intend to take it - we want to make this editor as in-depth as possible to give you a great deal of control over how your character looks. In worlds and servers, each character has its own position, inventory, and other data stored separately - effectively, each character is treated as its own separate player, allowing you to easily progress in different ways within the same world, if you like. Mind you, however - this data is still stored per-world. You won't be able to bring your inventory from one world to another, or from singleplayer to multiplayer, or vice versa. This could've been done in theory, but from experience hosting both Minecraft and Valheim servers over at Chaotic United, we've found that Valheim's inventory system - which does allow for stats and items to be brought from singleplayer to multiplayer - makes cheating in illegitimate items trivial. As such, we've opted to keep it more like Minecraft - where your data is tied to the world, rather than the character. Keep up with Development Most recently, we've been working on setting up ways for those of you interested in the development process to keep a closer eye on things - similar to what we have for Blamite. As such, you can now view the commit history and Stratagem pages for Sandbox. For those already familiar with the equivalent pages for Blamite, the Sandbox pages work identically to their Blamite counterparts. For the rest of you - our commits page allows you to view the full commit history of our Git repository for Sandbox. This will include author information, the commit hash, and a title/description detailing the changes. Meanwhile, Stratagem is a Trello/Kanban-style board system built directly into the website - which is what we use internally to keep track of development. We'll have cards for various bugs, new features, ideas that may or may not make their way in, and more. And, of course, the best way to keep up with development in almost-real-time is to join our Discord! We routinely post in the #sandbox channel over there as we work on the project - so you can see things as they happen, often before they're even commited to our Git repository. Wrapping Up For now, though - that's all we've got. As per usual, though - we are still in fact looking for folks to join the Blamite development team! You didn't think we were done with that, did you? While we (or more accurately, I) have been focusing more on Sandbox, we still very much intend to return to working on Blamite at some point. If you're up for joining our team - you can make that happen sooner rather than later. If you're interested in applying, check for our current openings here. You might also be wondering if we're looking for folks to join the Sandbox development team. Currently, we aren't actively looking for folks to join the Sandbox development team. However, if you think you have something to offer - feel free to drop in a general application! Depending on what you can offer, we might be able to make use of the help. In either case, be sure to hop into our Discord to keep up with both Blamite and Sandbox - and we plan to have another update to share with you in the not-too-distant future.
  2. Version 1.0.0

    1 download

    This is a pre-alpha release of our Untitled Sandbox Project. It currently includes basic terrain modification, chunk generation, and movement mechanics. For a list of all controls, you can press F1 in-game. Stripper Run..? Stripper run was a planned project that was briefly considered in early 2023, with the primary purpose of being a simple, easy-to-develop project that could help bring in revenue to Elaztek. It was later cancelled for a variety of reasons, but its project files were used as a base for the Sandbox project. The current UI aesthetic is also carried forward from Stripper Run. In future builds, this will be properly updated - but for now, these things have been left as-is. For more information on Stripper Run, and the Sandbox project itself, check this announcement post.
  3. 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
  4. Hey, everyone! Not much to actually write here, but we've just uploaded a YouTube video going over the current state of the Blamite Game Engine. We plan to create more of these as time goes along and the engine continues to grow and evolve. We can't say how often they'll be produced, but we want to start showing off new features as they get developed. Sometimes they'll just be simpler stuff without too much visual flare, other times it might be something a bit more exciting. This first video was uploaded yesterday and was recorded by yours truly. It's a fairly in-depth one as I was both somewhat sleep-deprived, as well as the video being entirely unscripted. So, if you want to check it out, bundle up, grab some popcorn, and give it a watch.
  5. Hey, everyone! Not much to actually write here, but we've just uploaded a YouTube video going over the current state of the Blamite Game Engine. We plan to create more of these as time goes along and the engine continues to grow and evolve. We can't say how often they'll be produced, but we want to start showing off new features as they get developed. Sometimes they'll just be simpler stuff without too much visual flare, other times it might be something a bit more exciting. This first video was uploaded yesterday and was recorded by yours truly. It's a fairly in-depth one as I was both somewhat sleep-deprived, as well as the video being entirely unscripted. So, if you want to check it out, bundle up, grab some popcorn, and give it a watch.
  6. haloman30

    Eon Game Engine

    Meant to be reliable and fast, Eon is made to be easy to use and very simple. Eon has the power to produce very large games and is in no way meant to limit game creativity and size. It's simple which means easy to change and very adaptable. It's geared towards 2d game development and comes with all the features necessary to make awesome 2D games. Eon is made with C++ and SFML (Simple Fast Multimedia Layer) which is a widely used and popular graphics library for C++. This means that there are plenty of tutorials and resources available to learn SFML. Making Eon a good choice for any beginners or experts next project. So check it out, see what's possible when you have Eon in your toolbox!
  7. 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!
  8. 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!
  9. Rikez

    Raven Runner

    Version 0.2.2

    25 downloads

    This is the download for the RavenRunner game developed by Elaztek Studios and Ruletech Games Inc. Raven Runner is an Dungeon Runner game through many randomized dungeons that constantly keep expanding and increasing in difficulty. Please Note If you are running Mac or Linux, you will need a program that can open .7z files in order to extract the games content. For Android, you will need to enable Unknown Sources in order to install the game.