Enginedev insanity

I’m telling you, you can’t even begin to comprehend how utterly nuts this whole endeavour is and has been from the very beginning. One’s event horizon has to be microscopically shallow to somehow escape the obvious realization that this is just a lot of herculean work, for comparatively infinitesimal reward. Recently I started having second thoughts about creating a custom engine for what seems like a very minor title, but I’m way too deep into all of this to quit now.

Also hi, welcome to my new blog.

We have a lot to cover:

ECStasies

Since creating a custom renderer turned out to be such a wonderful experience, a decision to also construct a custom entity component system model implementation was a natural one to follow. It’s not that custom in the end - a lot of the code in this mess of an engine will be created from atop the shoulders of giants. In this case, the ECS is based on the outstanding efforts of Michele skypjack Caini, the author of EnTT. His blog outlined all of the ideas crucial to making the whole thing work coherently, while also still reaping all the benefits that come from shedding the time-tested, intuitive actor model for the maelstrom of LEGO pieces. Figuring out how to implement everything was a bit of a pain; I’m sure I’ve taken shortcuts here and there that completely negate whatever performance advantage that could be eked out from defining tailor-made data structures. Then again, no pain, no gain - although I recommend restrain with this stupid refrain. The actually interesting part of the end result is the automatic struct reflection I’ve managed to hack together using Patrick Urbanke’s work. Thanks to structured bindings and some compiler-specific hacks, the user can get (de)serialization and path-based access to fields of trivial structures for free. This is perfect for simple components and the whole mechanism could still be easily extended to enable implementing and automatically using custom methods to support all necessary operations for complex types. This will come in handy especially once I start grafting some sort of a scripting language onto the engine.

Posterior Bashing Rasterization

All in all, a very instructive experience, if it wasn’t for the fact that it is so domain-specific that at this point I barely remember anything about it. I almost dread having to come back to implement proper light sources. On the other hand, while I don’t and never did consider myself to be a graphics programmer, figuring out how the GPU actually operates helped me gain a lot of confidence when it comes to modelling new features requiring explicit support from the renderer. Exhibit A - the UI - is a bit of an offshoot here, because it doesn’t fit the regular vertices+images -> more images pipeline, but when I was finishing up the PBR work, I was confident tackling that subject wouldn’t be much trouble at all anymore. Oh, how wrong and naive I was…

Newton’s neurotic nightmare

The initial outline of the whole thing assumed using something like Jolt Physics for a physics engine. That would be too simple, obviously. The internet is full of horror stories full of precision errors, incompatible FPUs, O(n^m) algorithms and such, but as a young upstart you gotta take that brazen attitude that inexperience grants you and shoot for the stars. I’ve obtained a copy of the orange book, found a dozen related GDC presentations, including absolutely crucial fundamental work done by Erin Catto on Box2D and an extremely valuable presentation by Valve’s Sergiy Migdalskiy expanding on the previously explained concepts, and got to work. What followed were months filled with gruelling trial and error, fighting the most inexplicable physical phenomena known to man, such as quantum spin interphasement.

Suffice to say, the moment I got a stack of cubes to stand still for two minutes, I called it a day for the time being.

A ✉️ of ❤️

This was the hill I absolutely refused to die on. Imagine deciding to write a game engine and then, along the way, figuring out that heck, maybe it’d be worthwhile to also produce a bespoke Unicode handling library just for kicks. At this point I’m one hundred percent confident in saying I’d much rather learn how to design an ISA and build from there than come in visual acquisition range of text processing, let alone Unicode. I followed the best practice of incorporating ICU, harfbuzz and freetype for the purpose and without much trouble got to render text onto labels.

The next step however turned out to present an issue that put a sudden hard break on progressing - what exactly is text? How is it to be represented and modelled in the engine? As labels-objects? Labels-textures? As sources for textures? What about representing it in the renderer? Does it require a dedicated pipeline, separate from the UI itself? My plan when it comes to interactivity is quite ambitious - viewports as render targets, interactive in-world interfaces, the likes - but this roadblock was harsh and unexpected. I could not for the life of me figure out how to fit text objects into the rather fancy entity-component model that I’ve already grown accustomed to. Weeks turned into months, but I was still without an answer. Only recently, after meeting and talking to some friends I’ve made at university, have I let myself become convinced that this whole debacle can wait and doesn’t have to be perfect or customizable from the get go. I marinated on this some more time, eventually cleared out the whiteboard of all the junk related to the subject and moved on.

got Houston, problem. a we’ve

My preliminary attempts at prototyping Hostile Perimeter in Godot left me with a bunch of useful code integrating Valve’s GameNetworkingSockets with that engine using its extension interface. While not directly applicable, it served as a great starting point for implementing inter-instance communication. Sending messages didn’t pose much challenge, since GNS provides a lot of handy helper procedures (good design); they could however spare their users from having to define global callbacks (bad design). Afterwards however, whatever ideas I had about propagating the state of the world from the server to the clients fell apart the moment they had to be materialized in code. Networking is famously known as Yet Another Tarpit For Ambitious Projects To Rot In. There was a stronger case for dropping the idea of a homebrew implementation - I appreciate that networking is much more dangerous, in the sense that the risks carried by potential mistakes can lead to devastating consequences. However, in some way, I’m also more confident in navigating potential issues here; I’ve spent a lot of time over the years thinking about this stuff, so there’s that for a false sense of security. No other way to become a practitioner, but to practice.

Took me a while to figure out how to properly do clock management, synchronization, input tracking and propagation, but I’ve managed to get there, just today. While having the client operate almost in lockstep with the server is not exactly the most fun experience to take part in over the internet, it’s an important first step in building up netcode for action games; from here, further work will focus on implementing interpolation, lag compensation and all the usual fluff that began with John Carmack’s original descent into becoming a genius and continued later with Valve’s refinement of the formula. As a side note, I highly recommend Masters of Doom, it’s very inspirational, for what it’s worth.

Where next?

Currently I’m working on a Spacewar clone to test the newly founded networking facilities. Not entirely sure if the interpolation model will suit this game best, but it’s a decent testing ground. I’d like to actually put some effort into turning it into a proper game, presentation and all. Lighting is another major topic on the list of things to deal with, so might as well hit the ground running and take a stab at particle effects; making space look nice might make it at least slightly more palatable. Surely a ton of other things need to be figured out before release - UI remains a major thorn in my backside - but with the long-standing history of successes of the feeling of progress as the driving force of progress, it seems rather likely that 0.2 will eventually see the light of day. What follows then, I don’t dare to think about right now; eventually, Hostile Perimeter has to start taking shape. Might as well begin already.