dev diary 1: full circle, a year of noir et blanc

in april 2025, a latent notion in my mind, dormant since childhood, became manifest.

i decided i was going to make a videogame.

this is significantly different from my previous endeavours like “think of making a videogame” and “mess around with making a videogame.” i am not sure, precisely, why this was different from the very thought that i have had a thousand times over. you see, i’ve always wanted to make videogames. i’m pretty sure that notion began with the legend of zelda: a link to the past, a game which fully captured my imagination. i spent my time imagining the worlds i would create, rich immersive worlds like in the legend of zelda. the love was not for the medium, per se, but rather for that experience, the feeling of wonder, of truly immersive fiction, that i wanted to capture. a few years later, by the late 90s, i was a full fledged computer nerd, and it had formally become the plan. open a game studio, release the next smash hit. easy, right?

it wasn’t until i was in college for computer science that i came to the realization that i wasn’t the only one who dreamt of being a game developer, and that game studios knew it. that childhood dream of unbridled innovation in favor of that feeling of wonder… i realized that was not a job which the market had listed. finding an actual game dev job would be hard, especially without a long, possibly unpaid internship, or at least some experience doing something that wasn’t making games. i realized the creative beauty of the medium was something that 99% of game developers never really got to direct; most of the time you’re locked into a design you didn’t necessarily want and an idea that wouldn’t have been the one you chose. you’re not even creating someone else’s art in most cases, you’re creating someone else’s idea of a viable product in the market place. and that idea could be a delusion, it could be an artless cash grab, or it might be one of those generational titles that actually struggles to push the medium forward. in short, i wanted to make things my way, i didn’t want to execute a vision i did not agree with, and as a lifelong fan of the games industry, by the time i was in college i knew full well what that future would actually be like.

so i gave up on my dreams, i guess. i went the pragmatic route. instead of a programmer, i became an IT guy. i threw myself into it, and if i say so myself, i think i succeeded. i rose through the ranks from technician, to sysadmin, and finally to a system architect, which is currently my day job. when i chose this path, it was me deciding to walk away from videogames, to pick the practical, if i am being honest, somewhat easy path. fixing a router in an emergency is one thing, but you weren’t going to catch me working 80 hours a week just to ship some crappy mobile game in time for the quarterly earnings report. IT isn’t easy, but it is possible to carve out something resembling work life balance, at least compared to the game dev industry.

what i wasn’t expecting is that my path could actually lead me back to game dev, precisely because of that work life balance. now that i have become somewhat established in my career, i find myself no longer fixing broken routers at night. i also found myself with a good deal of knowledge about programming and system architecture. i’ve spent my life dabbling in many gamedev adjacent tasks; 3d animation and surface modeling, photoshop/illustrator, web design, game modding, sound design. so i have the skills, i have the means, all i needed was an idea.

that idea came to me a year ago. a grand strategy game. i’ve got a lot to say about the game concept itself, but i’ll properly unveil it another day. it’s a big, ambitious process, and as i began developing the scope, i quickly realized none of the game engines available were sufficient for what i had planned.

the problem is that traditional game engines are very poorly optimized for scale. the fundamental loop oriented system, in which every entity in the game world does all its operations one after another, is fundamentally the wrong model for large scale simulators. if you have a huge population of npcs, you can’t afford to have them all simply update themselves every 60 times a second. that’s a solved problem in itself, but the way you typically solve it is by rigging up a rube goldberg machine, allowing each system to function independently within the parameters of a complex environment. you’re managing complexity with more complexity.

and as i thought more about this ‘paradox’ of game design i realized the fundamental issue with our current paradigm. it’s not about speed; there’s a fundamental weakness in how we model relationships. relationships are an afterthought. relationships are expensive. relationships are usually represented in bolt-on, parallel systems that have to be carefully hand integrated. ecs, entity component systems, the last big paradigm shift, made some major strides in decoupling systems and components, but still don’t represent relationships as a first class concept. this is why dynamic simulator games take so much work; every new system has to be integrated with every other system, and changes can cascade through the whole structure as it becomes a tangled graph of dependencies.

but worse than that, it’s just not right. i mean philosophically. as an IT systems architect, i looked at game engines and i shuddered. game developers get away with so much that, frankly, i find insane. in my world you don’t just mutate data all willy nilly. it’s insane to me that you would set loose a pack of entities with the imperative to go around altering the state of your world dozens of times per second. you would think there should be some sort of ‘business rules’ that clearly state in a central way how the world should evolve, and those evolutions should go through a transaction system. i mean imagine if your bank account and all the other bank accounts were each entities with lots of methods and they could unilaterally decide to just change other people’s accounts. that’s how i view most game engines. when you think about it architecturally it sounds insane.

why things are this way, of course, is understandable. videogames, for the vast majority of their history, haven’t merely been limited by their hardware, but defined by it. performance isn’t just the user experience, it also defines the upper limits of what you are capable of doing. game design has often eschewed safe for fast. but in our modern era, the average gaming PC is, frankly, absurdly powerful. if properly optimized you can do literally trillions of operations in a second. that wasn’t a typo, trillion with a t, although that is certainly not what real apps achieve in most cases, we start getting limited by memory speed, but my point stands, modern hardware is incomprehensibly more powerful than the systems developers in the 80s and 90s had to deal with.

i’ve spent the last year exploring this. “what should a proper engine for a strategy game in 2026 look like?” and i have come up with the answer. it would look like the tao engine. a year into the project this engine is complete. at least, it is no longer a pre-requisite to the work of developing noir et blanc. i think what i have built is truly novel, as far as i can tell, nobody has done anything like this before in a game engine. it’s absurdly ambitious on one hand, but on the other, in a way my complex engine will create games that are simpler to build and faster to iterate than a standard engine. i’ve invested in solid architecture to solve problems before they happen. i’ve spent a lot of time thinking about how bugs occur in videogames and then structurally making them impossible. i’ve spent the last 6 months pushing the performance envelope as far as it will go, scaling up to a massive world capable of ~1 million real persistent NPCs living detailed lives.

looking back on my journey, it certainly seems like kismet. or perhaps, more appropriately, wu wei. if i had become a programmer and game developer, i would, interestingly, have become blind to the issues of the medium. i would have gained such skill at technical execution that philosophical and architectural principles would have become an afterthought as they are at virtually every game studio. i would have never considered the task of building a new type of game engine in the first place. the conventional wisdom says shut up and ship games, don’t reinvent the wheel. but building a grand strategy game written in an object oriented way is like putting square wheels on your wagon just because they’re quicker to build than round wheels.

i am so excited to show you what i have built, but i don’t want to jump the gun just yet. this is all pretty heady stuff, so i’ll have to give these ideas some time to soak in, so i plan to drop one of these diary posts per month, and then when i feel like it i will release other smaller updates. the dev diaries will be a little more personal and the other documents will be more technical in nature. stay tuned, big things to come!

ian