So well it has been (checks notes) like over a year since I posted something. Probably time to do so! Why is this? There is a long story and then a very long story.

Art of the Rail paused development due to loss of motivation to build on the shifting sands of Unity Licensing, and has been ported to our own internal custom framework called "BRUTAL". This framework was built from the ground up around the approaches to data, memory, scale, and rendering that AotR was built around.

There will be an initial pre-alpha launch on Itch.io, and once we are happy with the state based on customer feedback we will look into a Steam launch. I remain concerned about Steam launches due to Valve constantly shifting the sands of how downloads, cloud, and other features work - with the customers ending up frustrated with us when Steam breaks and us having no agency to fix it. This hits us especially hard on our products because we tend to update them every week. Steam makes a lot of arbitrary decisions around things like festivals - demonstrated recently by ICARUS customers questioning why we did not include ICARUS in the space exploration festival (Valve denies our requests).

We now have fulltime employees on AotR porting and redevelopment, other than just me (the CEO). We also have a massive amount of content made, such as vehicles for pretty much every continent. You can see the live changelog on our discord to see how this develops.

Last year the maker of one of the engines we use (Unity) considered making changes to how their license worked. This upset a lot of people. At the studio we have used Unity extensively, and while it is certainly true that a "poor worker blames their tools" - we had some legitimate beefs with Unity from technical perspectives. Much of the work at our studio is around games that need to *scale*. This has been talked a lot in previous developer blogs, as well as in the weekly blogposts for our other games. Unity Engine, and Unreal Engine frankly, struggle to move outside of their box in terms of scaling. That is not to say that it is not possible to make games that have massive scale in these engines, but I think it would be uncontroversial to say it is not easy to do so.

We had formed a special team (called "Enterprise") of extremely skilled industry veterans to investigate how we wanted to make games in better ways. Their first project was to implement our own multiplayer system (called RocketNet), that was based on the architecture of RakNet. This involves the very high efficiency process of sending "arrays of bytes" rather than "network messages". Think of it like packing freight in a cargo container, rather than sending the packages individually. This was *enormously* successful. We then moved the team to taking Dear IMGUI (an "immediate mode" UI project) and implementing it nicknamed RocketImgui in some of our projects. This was also enormously successful. Both of these are used in our released project (Stationeers) as well as a number of other unreleased projects.

Emboldened with this success and on the back of Unity's proposed license changes we decided to give the Enterprise team the focus of an *entirely* custom solution to making games. Instead of making an *engine*, we wanted to take all of the lessons from what we needed to scale our games so far and look for a *framework* to do this. Such framework would single-mindedly focus on this scale, at the expense of everything else. We call this the BRUTAL Framework. If we look at the XNA Framework we see similarities, XNA was intended to make C# accessible to make simple (although it has made not so simple!) games - BRUTAL is also about exposing C# natively to making games but for the single-minded purpose of making games that *really* scale.

At the core of everything BRUTAL is the interop layer. You could this is the "communication" between C# as an abstracted language and "everything else". C# as a language is "magical" when it comes to managing memory, or rather it does this for you (sort of). In other languages, like C++, you have to handle how and what you do with memory - allocating and disposing it yourself. One of the key things our Enterprise team has focused on has been this interop layer, making it as efficient for both processing and memory as possible for our C# code to work the various parts of your computer.

Each step along the way, we have looked for the most efficient way - ability to scale - to do what we needed. An example would be integrating the Vulkan renderer directly, rather than through another library. We also took the rendering approach from AotR and took that to another level. In the "old" AotR, rendering was done in batches *through unity*. In BRUTAL, we do this *directly* onto the GPU.

What this has mean is that we have really rethought a lot of basic assumptions around game development in the process, to the enormous benefit of a game like AotR. What is a mesh? How can we draw in batches? The scale that it allows us to unlock is really, really huge. Combined with *complete agency*, this means AotR can meet the requirement of a "forever game" that the studio requires of projects. I.e. when we make a game, we want to make it in such a way it will outlive the studio, the people that make it, and not fully dependent on external APIs like Steam or Discord.