dev diary 2: tao, the pursuit of perfection and the expression of will
today i completed version 0.1 of the game. that little number hides a whole year of work. this means i am essentially ready to start game development instead of working on the engine itself. basically as soon as i set out to make a game, i decided no engine could do what i wanted. i knew i had to be clever and resourceful when it came to spending my time, since i am doing this solo. professionally, i haven’t spent my career in the games industry; i am a system architect, so i inevitably see this challenge through that lens. but where i have engaged with game development is as a modder. if you want to see an integration nightmare, try getting a modlist to cooperate. so i knew integration was the big challenge.
game development’s conventional wisdom is something along the lines of ‘plan small, ship things.’ scope creep is rightly considered a cancer, redirecting resources into growth until critical systems fail. and by that standard, building my own engine isn’t just scope creep, it’s the largest possible case of it. so to people who have, unlike me, actually shipped games, this sounds like hubris. but i think they neglect architecture and pay for it in integration. this ‘just ship it’ mentality is another way to say ‘buy our features with technical debt.’
the deeper problem with ‘just ship it’ isn’t the debt, it’s the product. moving fast means pasting over the details. you don’t model hunger, you trigger a hunger animation. you don’t model a rumor moving through a city, you flip a flag on a quest. what you get is a simulacrum, a thing that looks correct from the outside and has nothing on the inside. and a thing with nothing inside it is a nightmare to integrate, because there is no state for the next system to attach to. add famine later and there’s no hunger to connect it to, only an animation, so you hand write a bridge. then another. every faked detail becomes a seam that has to be stitched by hand, and the seams are where the bugs live.
my point isn’t that everyone should go build the most complicated simulation they can. that’s the opposite of what i’m saying. my point is that you should build architecture to support your design spec, and by architecture i mean systems that are conducive to integration. not systems that can be integrated, systems that don’t have to be. spend the complexity once, in the foundation, so that everything you build afterward connects by default instead of by hand. that’s the trade. the ‘ship it now’ mentality makes current progress quick and future progress slow; architecture first makes current progress slow and future progress quick. i’ve spent a year on the slow part. but a grand strategy game doesn’t have dozens of edge cases, it has thousands. complexity is the whole ballgame. the question is only whether you manage it up front or iterate into it one simple change at a time.
when i looked at my options, none of them fit. it isn’t that unity and unreal are bad, they’re great for most games. they’re built for the industry standard way of doing things, and the industry standard assumes a team of dozens. the problem is that while they are capable of producing simulators, they are not built for simulation at scale. most games fake it. they simulate physics, or a mechanic here and there, but the world itself is a hollow shell with window dressing, a place that doesn’t quite exist until you look at it and stops existing when you turn away, a simulacrum.
the tools built for managing simulation reinforce this, ecs above all. it was a massive improvement over object orientation, and for a lot of games it’s the right answer. but the ‘systems’ part of ecs betrays the problem; bring your own integration. you can organize your data beautifully, but you still have to wire it all up one system at a time. that’s the integration challenge. it grows with the number of pairs of systems, so your tenth game system costs way more than your first. integration is a steep curve, but i think i have found the answer to it.
introducing the tao engine
the tao engine is my answer to the problem of system integration. i’m incredibly proud of what i have built, a unique type of game engine, comprised of two halves:
yin, the game engine layer. receptive, c#, generating no signal of its own. this handles ui, input, rendering, sound, everything except the world state.
yang, the simulation layer. the living half, rust, the one that creates and determines state. everything in the world with semantic meaning is represented in it.
the simulator has no idea about presentation, other than traits. yang has no notion of sprites, polygons, frame rates, or ui screens. yin tells it what the player is looking at and it returns what is meaningfully there, which means the same world can be presented however i want. the entities have nothing to do with their own drawing. there is no traditional game loop. it’s closer to a weather simulator than to most game engines.
but here’s the thing, i’m not making a game engine. if i’m excited about tao it’s because it enables Noir et Blanc. i want to make a proper film-noir simulator… murky worlds of intrigue, deception, crime and heroism. a game where information itself is the most valuable currency, and the strength, or trustworthiness, of your relationships is your only lifeline. this demands a deep simulation the player can get absorbed into.
tao isn’t just the best platform for this game, it’s the only thing in the world that could make it. how exactly the engine does it is for future dev diaries; i’m not gonna kill my golden goose just yet.
you might be wondering why it’s called ‘the tao engine’. honestly, it’s a little bit religious. that might surprise those who know me, because i’m not an outwardly religious person. but taoism isn’t an outwardly religious creed. the way i see it, taoism is an expression of the profound, ineffable harmony of nature. tao isn’t just a name, it’s the driving philosophy of the engine: that harmony is the most important measurable, and that many great and wonderful things can come from a set of simple rules.
i think a certain degree of hubris is a prerequisite for pushing an artform anywhere new. regardless, this is what i was born to do, and doing it has felt effortless. it’s the taoist notion of perfection: not rigidity to an external standard. the true expression of your creative will. being who you were born to be and making the thing you were born to make. it’s an incredible task that constantly humbles me, but i think i can make the best strategy game in a generation. whether that’s confidence or hubris is irrelevant, making it is wu wei, you might as well call the sunflower arrogant for blooming. 🌻
ian