WasserXR

Many people have at least thought about making their own game, but few have gone to the lengths of making their own game engine. Today we're featuring Ian Wasser's WasserXR. "XR" stands for "extended reality", which includes augmented, mixed and virtual reality. VR technology dates back to the 1980s but current VR game engines still leave a lot to be desired, which is why you should use WasserXR, if you want VR done right.
Some technical words are annotated with a *, the explanation is at the end of the paragraph.

If you are interested in a more hands-on demo, be sure to join our live showcase on July 17, where Ian will show you the capabilities of his engine on our Discord server!

Why did you choose to make your own game engine?
Basically, none of the more commercial or widely used game engines really fit my needs. In many cases the game engine was a bit in my way of building stuff that I wanted to build. And especially with conventional game engines, VR support always felt like it is just put in there with no real idea of how to build good virtual applications and also no idea of how to actually productively create VR applications. And this is why I wanted to build a game engine that focuses on VR so it's a lot easier to build and debug in VR. Because in other game engines, when you try to build something for VR, you need to debug stuff by changing some values, put on the headset, try it out, "okay, it does not work", take the headset off again, change some values, recompile everything, then put the headset on again. This is just a very long cycle of iteration, which I did not want to do, because it's also physically a bit more straining than just normal development. And this should be fixed by my game engine.

How did you get inspired to make the engine?
I knew, I wanted to build something for VR and there were multiple ideas I had in mind. First, I wanted to build anoperating system for the Meta Quest Headset to have a better way of working with my computer in VR and maybe enhance my productivity in that way. But then I figured out that Meta doesn’t allow that, so I pivoted to creating some desktop environment in VR I can manage all my applications in, like a spherical environment where I use my keyboard. It would be based on an existing operating system but with my own UI. But then I ended up with the problem of not being able to build such a thing in other game engines, because they are just so limiting in the way of how to interact with the operating system. And therefore, I knew I needed some kind of application first with which I can build VR experiences and systems more easily. So, I pivoted to building this game engine first. I realized how much better the system of my game engine is, which motivated me to make building the game engine my main focus.

What is the rough process of making your own game engine?
At first, the process consisted of a lot of learning, because I did not really know much about graphics programming. Engine development is mainly computer graphics development; you need to figure out how to "speak to your GPU" to actually get something to show on the screen. This is quite a lot of math and quite a lot of programming. And when you have a finished game engine it's basically just doing that but scaled up to a lot more graphics operations, a lot more models that you draw a lot of triangles that you draw. And so, this needs a lot of software engineering, architecture and design decisions. Making my engine usable, so that it is not cumbersome to create something with it, has been the most important thing which I focused on so far. Making my game engine interactable, having a system for working with the game objects, processing and loading data is hard. And then it's just a bit of creating game logic, like a physics engine, the whole virtual reality pipeline rendering system, I need to gather codes that my game needs, I need a player, I need my controls.

What language does your engine use?
So the engine is written in C because I first tried to write it in C++, but I figured out that it is a lot easier to create stuff in C because there is much less abstraction that I need to use. It's easier to build my own abstractions than to wrap my head around some of the concepts and to fight with C++.
To actually build code for the game engine you can either use C or any other language that compiles to the C ABI*, which is one of the main features of WasserXR. This makes it quite versatile for larger teams to collaborate on one project, even if they use different languages.
This is a newer approach of having multiple languages. It comes from the entity component system (ECS) of WasserXR, which is doing things by having the code loaded at runtime through the C ABI.
*The C ABI is a calling convention that allows objects from different programming languages to be used together.

What components of the engine did you already make?
So currently I've mainly focused on the ECS part. The ECS is the entity component system, which is how you write the architecture and game code. Everything is classified as an entity, component or a system. An entity is a game object which holds components. Components are data, like, for example, the position or rotation of some object, the player's health, something like that. And a system is code that performs actions on entities and their data.
And now I'm focusing on the core library of WasserXR, which has the core functionality of how to actually build your game, like, for example, you have a basic mesh rendering system, the way to create a window, the way to create the VR session. But the main part, the ECS, is basically what I've currently finished.

Is there an existing game engine that yours will be like, and if yes, is yours directly inspired by it?
Not really. I've used a lot of different game engines, especially the widespread ones like Unity, Unreal Engine and Godot. But I just did not like the way you write code for them. So, I wanted to have something else. I've heard about this ECS concept, which is used as the main thing in the Bevy engine, which is an up-and-coming game engine in Rust. And there this ECS philosophy, or this architecture is heavily used similarly, but since Rust is only capable of statically linking code together, it does not have the capabilities of WasserXR like being able to hot-reload* code at runtime, change stuff while the application/your game is running, which is such a nice feature to have while debugging, developing and coding. So no, I don't know of any game engine that works like WasserXR and that's also why I'm creating this.
*Hot-reloading refreshes only the changed files without losing the state of the app, so it's possible to change code and see those changes without having to close the running instance and re-compiling.

Is there any feature of your engine that you would like to highlight?
Yes, there are some interesting features that the engine supports, which are quite nice. So, one I've mentioned before; the capability that the game engine supports multiple languages, that you can build in C++, Rust, Go.
Then everything is just split into plugins, which is a concept not envisioned by the standard ECS paradigm. In WasserXR a combination of components and systems compiled together build a plugin, so it's basically a compilation unit that you can just load at runtime. If you want to iterate on it, you can just recompile this one plugin and then hot-reload it into the game engine at runtime and have your changes directly visible while coding stuff, which is really, really nice and quite handy.
The ECS part also makes it quite easy to build a maintainable and nice code structure by just building the components. That's quite nice, quite fun. Also, the plugging ecosystem allows you to share certain plugins with other people and to reuse them for other projects. So, you do not need to re-invent the wheel every time, which is also something I noticed in other game engines in VR. You have to write a lot of boilerplate* and it is quite annoying.
*Boilerplate (code) are code segments which are repeated often with little to no variation.

What are the benefits of implementing your own ECS?
The benefits are that I can control what the whole architecture looks like, how stuff works together and how it performs, though it is also maybe a bit of a challenge to get stuff to be really performant. But it (making your own ECS) is quite nice, since you can make design decisions on how stuff will work or how people actually use your game engine. And this whole journey of building the ECS has led me to the design decisions to make the game engine compatible with a lot of other languages, to have this hot-reloading system, to have this plugin system, which is really, really nice.

What are the next steps in the process?
So at the moment, the ECS was the main part that I've been focusing on to get this to a usable state and also make good design decisions in the beginning. And now I'm mostly focusing on getting the core library of components and systems ready for people to much more easily build games, so they don't need to write their own rendering code or VR/XR server runtime code to connect to your VR headset. Basically, to make it really easy to use the game engine to build stuff. And also, physics engine will be implemented, some audio systems. There's still quite a lot to do, but it's getting there.

What is your vision for the final product?
So my vision would be, in the ideal case, that a lot of people will adopt this game engine to build especially VR applications. So that there is this large plugin ecosystem where everyone can collaborate with each other and connect, reuse plugins, receive reviews and have maybe some new standards will evolve for virtual reality. I think the dream vision is having people connect by building plugins together and helping each other, to grow and step-by-step create better VR games. Also, that the development process becomes more fun and less annoying; that you don't need to put on the headset to test something and then take it off, put it back on. It's just this annoying loop of throwing yourself into VR and pulling yourself out. Having better iteration speed, so you are more productive. And also having more maintainable code.

How exactly will your engine make it so that you don't have to take off your VR headset?
The ideal vision is, for my development experience with the game engine is, that you could maybe directly build your game while being in virtual reality. That you could just inspect object properties in there, control the flow, the code and debug stuff in there by opening a window and editing what is going on with certain objects. And that you do not really need to take off the headset to just make some quick changes to everything, that you can just always be in the game and experience it how it will be experienced in VR. Because on a monitor stuff looks quite different than actually being in VR, especially the scale.

How will you publish your game engine?
I'm currently planning on publishing it by having the ECS system be like Unity: you can have it for free and use it, try stuff out, build stuff, as long as you stay under €100'000 per year on revenue with your game. Afterwards, you would probably have to pay some licensing fee to keep on using the ECS.
But to support the whole creator community, I will be making this core library of systems and components that work with the ECS free to use and open source under the MIT license, so you can just play around and also be inspired by how stuff has been implemented by others, to maybe change things, or maybe actually use certain algorithms in other game engines, which might be quite nice.
I really encourage people to try it out and to give me feedback on what to improve, so that we all can improve the user experience of creating virtual reality experiences together.

We are assembling a team of co-maintainers that will work on extending WasserXR with Ian. If you are interested in learning about game engine development or building a small, but still non-trivial video game to demo the engine, join our discord to be part of the demo event soon!

Are you working on something related to game development, digital art or game engines in general that deserves to be seen? Write us an email or reach out to us on discord to be featured next!