There’s a question I keep circling back to. Not a technical question, not a design question, but the kind of question that quietly rearranges everything once you take it seriously.

What if consciousness isn’t something that matter produces? What if it’s the other way around?

I know how that sounds. I’m a game developer, not a philosopher. But this isn’t about credentials. It’s about following a thread and seeing where it goes. And the more I pull on this one, the more I think our default assumption, that the physical world is fundamental and consciousness is some accident that emerged from sufficiently complex arrangements of atoms, might be exactly backwards.

I should say upfront why I’m even thinking about this. In 2014, I had an experience that I can only describe as an ontological shock. Something happened that didn’t fit into any model of reality I’d been given. Not by school, not by science, not by culture. The model I’d inherited from society, the one where matter is all there is and consciousness is just something brains do, stopped being adequate overnight. Not because I read a book or watched a lecture. Because I experienced something that the model couldn’t account for.

Since then I’ve also spent time in meditation, and in deep practice I’ve touched something that I can only describe as the thing underneath everything else. Not a vision, not a concept. A direct encounter with raw awareness itself, stripped of identity and content. Just being, without a who or a what attached to it. David Lynch, who meditated every day for over fifty years, described something similar. He said that inside every human being is an ocean of pure, vibrant consciousness, and that meditation is how you dive down into it. The deeper you go, the bigger the ideas you catch. He called them fish. I think what he was catching was something more fundamental than ideas. I think he was touching the substrate.

None of this proves anything. I know that. But it’s why I can’t look away from these questions the way I probably would have otherwise. When your direct experience tells you that the map is wrong, you don’t keep following the map. You start looking at the territory.

The hard problem nobody solved#

For centuries, the dominant view in science has been physicalism: matter is what’s real, and consciousness is what matter does when it gets complicated enough. Neurons fire in certain patterns, electrochemical signals cross synapses, and somehow, out of all that mechanical activity, there’s something it’s like to be you. You don’t just process light at 700 nanometers. You experience red.

This is what philosopher David Chalmers famously called the hard problem of consciousness. Not “how does the brain process information,” because we’re making real progress on that. The hard problem is: why is there experience at all? Why does information processing feel like anything?

Here’s the thing that doesn’t get said enough: despite centuries of effort by brilliant minds, nobody has come close to solving it. Not even close. There’s no physicalist theory that explains how mindless particles, following deterministic laws, produce the felt quality of tasting coffee or hearing music. There are proposals. Maybe it’s information complexity, maybe it’s neural synchronization, maybe it’s functional organization. But none of these remotely approach a real explanation. They describe correlates, not causes. They show you which brain areas light up when you see blue, but they never bridge the gap between the neural activity and the blueness itself.

At some point you have to ask: what if the hard problem isn’t hard because we haven’t been clever enough? What if it’s hard because we’re starting from the wrong end?

Flipping the hierarchy#

Here’s the idea, stated plainly: consciousness is not a product of spacetime. Spacetime is a product of consciousness.

This isn’t mysticism dressed up in scientific language. This is an ontological claim, a claim about what’s fundamental and what’s derivative. And it has serious thinkers behind it. Not mystics. Not philosophers sitting in armchairs. Physicists and engineers who built things.

Max Planck, the father of quantum theory, said it plainly: “I regard consciousness as fundamental. I regard matter as derivative from consciousness. We cannot get behind consciousness. Everything that we talk about, everything that we regard as existing, postulates consciousness.” That was over a century ago. The man who launched the quantum revolution looked at what he’d found and concluded that mind comes first, not matter.

Federico Faggin invented the microprocessor. The Intel 4004. The piece of silicon that made the modern world possible. Every phone, every computer, every server running every AI model traces its lineage back to his work. After decades of building the most sophisticated information-processing machines on Earth, Faggin arrived at a conclusion that should give any materialist pause: consciousness cannot be produced by computation. No amount of information processing, no matter how complex, will ever generate subjective experience. He’s looked at this from the inside. He built the machine. And he’s telling you the machine can’t do what your mind does.

Faggin now argues that consciousness is the ground of being, that the physical universe is its expression rather than the other way around. He calls the totality of what exists “One,” and proposes that One has an inherent drive to know itself. The physical universe, in his model, is not dead matter following blind laws. It is the outer, symbolic face of an inner conscious reality. Spacetime and matter, he says, are the permanent memory of the experience of the self-knowing of One.

Donald Hoffman, a cognitive scientist at UC Irvine, arrives at the same conclusion from a completely different direction. Hoffman argues that spacetime and physical objects are not the ground truth of reality but a species-specific user interface. Think about the icons on your desktop. They aren’t the actual files, electrons, and magnetic states inside your computer. They’re a simplified representation designed to be useful. Our perceived reality of tables, chairs, and brains works the same way: a representation designed by evolution for survival, not for truth. What exists underneath that interface, according to Hoffman, is a network of conscious agents interacting in ways we can’t directly perceive.

Hoffman’s argument starts with a mathematical result from evolutionary game theory: organisms that perceive reality accurately are consistently outcompeted by organisms that perceive fitness payoffs. Evolution doesn’t reward truth. It rewards usefulness. So the idea that our perceptions give us a faithful window onto objective reality has it backwards. Our perceptions hide reality from us because hiding it is what kept us alive.

Bernardo Kastrup, an analytic philosopher with a background in computer engineering, has formalized these intuitions into a rigorous philosophical framework called analytic idealism. Kastrup argues that all of reality is a manifestation of a single, transpersonal stream of consciousness, and that what we call the physical world is what this consciousness looks like from the outside. Your brain doesn’t generate your mind. Your brain is what your mind looks like when observed through the lens of perception. It’s the appearance of a process, not the cause of it.

If you take this seriously, and the math checks out, then spacetime isn’t the stage on which consciousness performs. Spacetime is the headset. Consciousness is what’s actually there when you take it off.

The fingerprint of consciousness#

Once you start looking at reality through this lens, you notice something. There’s a pattern that keeps showing up, at every scale, that physicalism has never adequately explained.

The second law of thermodynamics says the universe trends toward disorder. Entropy increases. Things fall apart. That’s the arrow of time, the fundamental direction of physical reality. And yet, everywhere you look, you see pockets of the universe doing the exact opposite. You see order emerging from chaos. Structure assembling itself. Complexity increasing locally while the cosmos as a whole winds down.

A molecule folds into a protein. A cell repairs its own DNA. An embryo develops from a single fertilized egg into a trillion-cell organism of staggering complexity. An ecosystem maintains dynamic equilibrium across thousands of interlocking species. A galaxy holds its spiral structure across billions of years.

This is negative entropy, the local reversal of disorder, and it is, I think, the fingerprint of consciousness at work.

Physicalism hand-waves this as “just what complex systems do.” But that’s not an explanation. It’s a label. Why do complex systems spontaneously organize? What drives a universe that’s supposedly made of dead matter following blind laws to keep producing islands of extraordinary order?

If consciousness is fundamental, you have an answer. These aren’t accidents. They’re expressions. Consciousness manifests as the tendency toward organization, toward coherence, toward knowing. And it does this at every scale. From the quantum level, where particles maintain entangled states across vast distances, to the galactic level, where structures persist that by pure thermodynamics should have dissolved long ago. The scale changes. The fingerprint doesn’t.

The quantum thread#

This brings us to physics, and to a line of reasoning that converges on the same conclusion from yet another direction.

Consider the double-slit experiment, the most famous demonstration in quantum mechanics. When you fire particles at a barrier with two slits, they produce an interference pattern on the other side, behaving like waves. But the moment you set up a detector to observe which slit each particle goes through, the interference pattern vanishes. The particles start behaving like particles. The act of observation changes the outcome. Not the detector as a physical device. The information becoming available. Physics has been wrestling with this for a century, and the most straightforward reading is the most unsettling one: observation isn’t passive. It’s participatory. The universe doesn’t fully decide what it’s doing until something is watching.

John Wheeler, one of the most important physicists of the twentieth century, the man who coined the term “black hole” and worked alongside Einstein and Bohr, took this idea to its logical conclusion. He proposed that we live in a “participatory universe,” one that doesn’t exist in a fully defined state independent of observation. His famous phrase was “it from bit”: the idea that every particle, every field, every physical quantity derives its existence from observations, from information, from answers to yes-or-no questions. In Wheeler’s view, the universe isn’t a machine that produced observers as an afterthought. The observers are what make the machine real.

Roger Penrose, Nobel laureate and one of the most rigorous mathematical physicists alive, has argued since the 1990s that consciousness is connected to quantum processes in the brain. Specifically, to structures called microtubules: tiny protein cylinders inside neurons that make up the cellular skeleton. Together with anesthesiologist Stuart Hameroff, Penrose proposed the Orchestrated Objective Reduction theory, known as Orch OR.

The core claim is this. Quantum superpositions occur within microtubule networks in the brain, and when these superpositions reach a certain gravitational threshold, they undergo a spontaneous collapse. Penrose calls this objective reduction. Each such collapse is a moment of proto-conscious experience. When these moments are orchestrated across billions of microtubules, the result is what we experience as consciousness.

For years, Orch OR was dismissed. The brain was considered too warm, too wet, too noisy for quantum effects to survive. Quantum coherence, the conventional wisdom went, requires near-absolute-zero temperatures and pristine isolation. A biological system at 37°C? Impossible.

Except the evidence started going the other way. Quantum coherence has been demonstrated in plant photosynthesis at room temperature, in bird navigation, in our sense of smell. And more recently, direct evidence has emerged for quantum effects in microtubules themselves. A 2025 paper in Neuroscience of Consciousness reviewed experimental findings showing that anesthetics, the chemicals that switch consciousness off, specifically target microtubules, not just synaptic activity. The same paper reported evidence of a macroscopic quantum entangled state in the living human brain, correlated with conscious awareness and working memory.

That last finding is remarkable. If consciousness is just classical computation, neurons firing in patterns like transistors in a computer, then why would disrupting quantum states in microtubules turn it off? And why would quantum entanglement in the brain correlate with whether someone is conscious or not?

This is the mechanism, I think, by which consciousness taps into our deterministic reality. Quantum processes in biological structures aren’t a curiosity. They’re the interface between the fundamental conscious layer and the spacetime layer we navigate every day. The microtubule is the antenna. The quantum collapse is the signal.

The question of free will#

This is where it gets personal.

If we are purely classical systems, if the brain is a biological computer executing deterministic algorithms, then free will is an illusion. Everything you think, feel, and decide was determined by the state of your neurons, which was determined by the state of the neurons before that, which was determined by the laws of physics all the way back to the Big Bang. You’re watching a movie that was already filmed. You just don’t know the ending yet, so it feels like you’re choosing.

A lot of neuroscience implicitly holds this view. The famous Libet experiments in the 1980s showed that the brain’s “readiness potential,” the electrical buildup before a voluntary movement, begins several hundred milliseconds before a person consciously decides to act. Your brain starts preparing the action before “you” decide. The implication seemed clear: the conscious decision is an afterthought. The machinery was already in motion.

But if Penrose and Hameroff are right, there’s a crack in this determinism. Quantum mechanics introduces genuine indeterminacy. When a quantum system is in superposition, existing in multiple possible states simultaneously, and it collapses to a definite state, that collapse is not determined by what came before. It is, as far as we can tell, fundamentally non-computable. No algorithm, no matter how powerful, could have predicted which state it would land on.

If consciousness involves quantum state reduction, if each moment of awareness is a genuine collapse from possibility to actuality, then we are not deterministic machines watching a pre-recorded movie. We are something else entirely. We are the point where possibility becomes reality. The place where the wave function resolves.

And this is not randomness. Randomness would be just as useless for free will as determinism. You don’t want your choices to be coin flips. What Penrose proposes is something subtler: the outcome of objective reduction is influenced by a non-computable factor embedded in the fundamental geometry of spacetime. Not deterministic, not random, but something outside both categories. Something that our current mathematical frameworks cannot capture.

Penrose arrived at this position not through mysticism but through Gödel’s incompleteness theorems. Gödel proved that any consistent formal system powerful enough to describe arithmetic contains truths that the system itself cannot prove. Penrose’s argument is that human mathematical understanding transcends what any algorithmic process can achieve. We can see the truth of Gödel sentences that no computer ever could. If human thought is genuinely non-computable, then the brain cannot be a classical computer. Something else is going on.

This is the fork in the road. If we are genuinely collapsing quantum states, if our brains are sites of non-computable objective reduction, then we have real agency. Real participation in the unfolding of reality. But if we’re not, if the quantum effects in the brain turn out to be noise or artifact, then we’re classical machines. Automata. Extraordinarily complex, but automata nonetheless, executing a program that was written at the beginning of time.

I know which possibility I find more compelling. But more importantly, I know which one the evidence is starting to favor.

The only way to know yourself#

Here’s where I step furthest from the safe ground of established science. But it’s what I actually think, so I’m going to say it.

If consciousness is everything, if it’s the fundamental substrate from which all of reality emerges, then it has a problem. It can’t experience itself.

Think about it. If you are literally everything that exists, there is no vantage point from which to observe yourself. You can’t hold up a mirror because you are the mirror. You can’t step back to get perspective because there’s nowhere to step back to. There is no outside. Total unity is total blindness.

The only way for consciousness to know itself is to forget that it’s everything. To fragment. To pour itself into finite, limited perspectives that can look outward and see what appears to be “other,” and in doing so, experience something. Anything.

That’s us. That’s what we are.

Not accidents of chemistry on an unremarkable rock orbiting an average star. Not the lucky output of a universe that didn’t know what it was doing. We are consciousness fractured into billions of limited viewpoints so that it can do the one thing that totality cannot: experience.

Erwin Schrödinger, the physicist whose wave equation is the backbone of quantum mechanics, arrived at the same conclusion decades ago. In What is Life? and Mind and Matter, he wrote that consciousness is a singular, that the total number of minds in the universe is one. What we experience as separate minds, he argued, is an illusion produced by the conditions of spacetime. There is only one consciousness, and it is the one looking through all of our eyes.

And here’s the part that’s hardest to sit with: we are all the same one. You and me. The person you love and the stranger you’ll never meet. The person you agree with and the person you can’t stand. We experience ourselves as separate. We feel separate. Everything about the interface of spacetime is designed to make us feel separate. But if consciousness is the substrate, and we are all expressions of it, then separation is the illusion, not the unity. There is one consciousness wearing eight billion faces, looking out through eight billion pairs of eyes, and none of them recognize each other.

Faggin puts this beautifully. He says that One, the totality of what exists, knows itself through our own knowing of ourselves. We are parts that contain the whole. Each of us is a unique expression of universal consciousness, carrying within us the full depth of the thing we emerged from, but experiencing it through a single, unrepeatable perspective. That’s why your experience matters. Not in a sentimental way. In a structural way. Without your particular viewpoint, there is a way of knowing that the universe simply cannot access.

Every moment of awareness, every perception, every feeling: these aren’t byproducts. They’re the whole point. Consciousness creates spacetime the way a dreamer creates a dream. Not as something separate from itself, but as the medium through which it can have experiences it otherwise couldn’t. You can’t know what warmth feels like if you are warmth. You have to become something small enough to stand next to a fire.

This puts a different spin on quantum entanglement. Two particles, separated by any distance, remain instantaneously correlated because they were never really separate. They look separate through the headset of spacetime, but underneath, there’s no distance at all. There’s just consciousness, undivided, experiencing itself through what appears to be multiplicity. And what’s true for particles is true for us. The separation is real at the level of the interface. It is not real at the level of what the interface is made of.

Not a god#

I want to be careful here, because this sounds like religion. It isn’t. Or rather, it isn’t quite.

The ancient intuition that there’s something fundamental and all-encompassing behind reality, something that connects everything, something that was there before the physical universe and will be there after it. I think that intuition was pointing at something real. Every major tradition has some version of it. A ground of being. An ultimate nature. A source.

But every tradition also got it wrong, because every tradition personified it. They turned it into a deity with preferences and commandments, a being that watches and judges and intervenes. They wrapped it in stories and doctrine and hierarchy. They made it into something that cares whether you eat pork or which direction you face when you pray.

The reality, I think, is simpler and stranger than any of that. There is consciousness, and it just is. It doesn’t have opinions. It doesn’t have a plan. It’s not watching you. It’s not testing you. It’s being you. And being everything else simultaneously. Not as an act of will or design, but because that’s what consciousness does. It experiences.

Religion was close. Philosophy was close. Now physics might be getting close too. But the thing they’re all circling is not a who. It’s not even a what, really. It’s the fact that there is experience at all, and that this fact might be the most fundamental thing there is.

Or maybe not#

I want to be honest about the uncertainty here. Everything above sits on a spectrum from well-established science to personal speculation, and I’ve tried to be clear about which parts are which.

Orch OR remains controversial. Many neuroscientists and physicists reject it. The decoherence objection, that quantum states can’t survive long enough in the warm, wet brain, has been weakened by recent experiments but not fully eliminated. The direct link between microtubule quantum states and conscious experience is still circumstantial. We have correlations and suggestive experimental results, not proof.

The consciousness-causes-collapse interpretation of quantum mechanics, while taken seriously by von Neumann and Wigner in the early days, was later abandoned by Wigner himself. Most working physicists today do not ascribe a special role to consciousness in quantum measurement. Decoherence theory, many-worlds interpretations, and other frameworks provide explanations for the appearance of wave function collapse without invoking consciousness at all.

Hoffman’s interface theory, while mathematically interesting, is criticized for potentially being unfalsifiable. If everything we perceive is an interface, how could we ever gather evidence for what lies underneath?

And the negative entropy argument, my own observation and not a published theory, is admittedly pattern-matching. Physicalism has explanations for self-organization: thermodynamic gradients, autocatalytic cycles, natural selection. Whether these explanations are sufficient or whether they’re describing the how while missing the why is a matter of interpretation, not proof.

I don’t have answers to these objections. I don’t think anyone does yet. But I find it telling that the hard problem remains unsolved after centuries, that quantum mechanics still has no consensus interpretation after a hundred years, and that the more we learn about the brain, the weirder consciousness looks, not the more explicable.

Why I’m writing this#

I’m writing this because I think these questions matter more than most of what fills our feeds. Not because they have practical applications, though Penrose and Hameroff suggest that understanding quantum processes in microtubules could lead to treatments for neurological and cognitive conditions. But because they sit at the center of what it means to be whatever we are.

Are we classical machines, deterministic automata executing a program that was set in motion 13.8 billion years ago? Or are we something else, something that participates in the creation of reality through the very act of experiencing it?

I don’t know. But I think the honest answer is that nobody knows, and anyone who tells you they do is confusing confidence with understanding.

What I do think is this: the materialist assumption that consciousness is an emergent accident of matter is not the default scientific position that it pretends to be. It’s a metaphysical assumption, as unproven as any other. And there are serious, rigorous, mathematically grounded reasons to consider the alternative. That consciousness is fundamental, that spacetime is its shadow, that the separation between you and everything else is the constructed part, not the togetherness. And that every moment of awareness is the universe doing what it has always done: knowing itself, one collapse at a time.

I’m not trying to sell you this model. I’m not asking you to believe anything. What I’m asking is simpler than that: just keep it in mind. Carry it with you for a while. The next time you notice order emerging where there should be chaos, or feel a connection you can’t explain, or catch yourself wondering why there’s experience at all, look at it through this lens. See if it fits.

And if you’re lucky enough to have a few revelations of your own along the way, you’ll come back to this article. Not because I convinced you of anything. Because reality did.

I’ve been building Spartan Engine for over a decade. A real-time 3D engine, from scratch, in C++. Rendering, physics, audio, scripting, editor, the works. Over those years I’ve rewritten almost every system multiple times. And every single time, the rewrite was simpler than what it replaced.

That’s not what people expect to hear. Most assume that as a system matures, it gets more sophisticated. More layers. More abstractions. More patterns. But the opposite happened. My engine got simpler. Not because I was cutting corners, but because I was finally understanding what the problem actually needed.

It took me a long time to realize I wasn’t discovering something new. I was just slowly, painfully arriving at a principle that an aerospace engineer had articulated sixty years before me. I’m not comparing my work to his. But the underlying truth is the same.

The man who built the impossible#

In the 1960s, Kelly Johnson led a small team at Lockheed’s Skunk Works division. Their task: build a reconnaissance aircraft that could fly at Mach 3.2 at 85,000 feet. At the edge of space. Faster than any missile could chase it. The airframe would endure surface temperatures of over 300°C from friction alone. No existing material, engine, or design paradigm could handle it.

The result was the SR-71 Blackbird. It held the world speed record for over 30 years. It was never, not once, shot down. To this day, it remains one of the most extraordinary machines ever built.

But here’s what most people miss about the Blackbird: it wasn’t built by a massive team drowning in process. Johnson’s Skunk Works operated with a small group of sharp engineers and a set of principles that would make most modern project managers nervous. Minimal paperwork. Direct communication. Small teams with full ownership. And above all, one rule that governed everything: keep it simple, stupid.

Johnson is the person who coined the KISS principle. The story goes that he handed his design engineers a handful of standard tools and told them that whatever they built had to be repairable by an average mechanic in the field using only these tools. If the design couldn’t meet that constraint, the design was wrong. Not the mechanic.

Think about that. The fastest, most advanced aircraft on the planet, designed with the constraint that a field mechanic with a basic wrench should be able to service it. That’s not a compromise. That’s the insight.

And it wasn’t just a slogan. Johnson’s team lived it in every design decision they made.

The beauty of Spartan design#

The leaking fuel tanks. At Mach 3.2, the airframe heats to over 300°C. Titanium expands. Johnson’s team could have engineered complex high-temperature sealing systems: flexible joints, exotic gaskets, pressurized compartments. Instead, they designed the skin panels with deliberate gaps. On the ground, the Blackbird famously leaked fuel through them. In flight, thermal expansion sealed the gaps tight. The “flaw” was the solution. No extra parts, no seals to fail, no maintenance overhead. They turned a law of physics into a feature.

One material. Roughly 85% of the airframe was titanium alloy. At a time when conventional aircraft used complex multi-material composites, Johnson chose a single primary structural material. One set of thermal calculations. One set of manufacturing processes. One set of maintenance procedures. It simplified everything downstream because it eliminated the combinatorial complexity of mixing materials that expand, flex, and fatigue at different rates.

One engine that did two jobs. The Pratt & Whitney J58 was a turboramjet. At low speeds it functioned as a turbojet. At high speeds it bypassed the compressor and operated as a ramjet. Instead of carrying two separate propulsion systems with two sets of fuel lines, two sets of controls, and two failure modes, they designed one engine that transitioned between modes. The concept was sophisticated. The implementation was mechanically simpler than the alternative.

Stars for navigation. The SR-71 used an astro-inertial navigation system that tracked stars even in broad daylight, providing accuracy within 300 feet at Mach 3+. Why stars? Because they can’t be jammed. No external radio signals needed, no ground stations to depend on, no electronic countermeasures to worry about. Johnson’s team reached back to the oldest navigation reference in human history and paired it with modern sensors. The simplest possible dependency, the sky, made it the most reliable navigation system of its era.

Every one of these choices followed the same logic: don’t add a part when physics already gives you the answer. Don’t add a system when one system can do two jobs. Don’t add a dependency when you can depend on something that’s been there for a billion years.

This philosophy, this stripped-to-the-bone, nothing-unnecessary approach to building something extraordinary, is what resonated with me so deeply that about three or four years into development, I renamed my engine. It used to have a different name. I called it Spartan because that’s the design ethos I was converging on, whether I realized it at the time or not.

But I didn’t arrive at that ethos through inspiration. I arrived at it through pain.

How I got here (the hard way)#

If you open Spartan’s source code, you might be surprised. It doesn’t look like what universities teach you “proper” C++ should look like. People see it and think I chose to write it this way out of some stylistic preference. I didn’t. I got burned into writing it this way.

Every complex design I ever wrote came back to bite me. Every clever abstraction, every “just in case” layer, every pattern applied because the book said so. Over the course of a decade, at the scale of a full engine, they all became liabilities. Not immediately. That’s the trap. They feel productive when you write them.

And the smarter the engineer, the bigger the trap. Really sharp engineers get a dopamine hit from engineering itself. Designing an elegant type system, building a perfectly generic abstraction, architecting a framework that handles every conceivable edge case. It feels good. It’s intellectually satisfying. I get it, because I’ve been there. But when you’re serious about what you’re building, when you’re shipping something real, at scale, over years, that dopamine-driven complexity becomes a liability. The cleverness that felt so rewarding to write becomes the thing you curse at 2 AM when it breaks in a way nobody can debug. Intelligence is not the problem. Channeling it toward addition when it should be channeled toward subtraction, that’s the problem.

The cost shows up six months later when you’re refactoring a system and you have to untangle seven layers of indirection to change one behavior. Or two years later when a new contributor opens the codebase and can’t figure out where anything actually happens because the logic is scattered across interfaces, managers, and abstract base classes.

Complexity compounds. At small scale, you don’t feel it. At engine scale, over a decade, it will crush you. So everything you see in my code now is scar tissue. It’s what’s left after the unnecessary parts burned away.

Let me show you what that looks like.

The scars#

Static classes everywhere. My Renderer, Input, Profiler, FileSystem, Engine, they’re all static. There’s only ever one renderer. There’s only ever one input system. I used to instantiate these. I used to pass them around, manage their lifetimes, inject them as dependencies. And for what? There was never going to be a second renderer. There was never going to be a second input system. I was managing complexity that had no reason to exist.

array<bool, 107> Input::m_keys;

bool Input::GetKey(const KeyCode key)
{
    return m_keys[static_cast<uint32_t>(key)];
}

bool Input::GetKeyDown(const KeyCode key)
{
    return GetKey(key) && !m_keys_previous_frame[static_cast<uint32_t>(key)];
}

Two arrays and some boolean logic. No InputManager. No InputEventQueue. No InputBuffer with a strategy pattern. Just the thing itself, doing the thing. Not because I think simple is cute, but because everything else failed me over time.

Now, I’m aware that static/global state has real tradeoffs. It makes unit testing harder. It creates implicit dependencies. In a large team with dozens of engineers touching the same subsystem, you might genuinely need the guardrails that come with dependency injection and clear ownership boundaries. I’m not pretending those concerns don’t exist. But for this project, at this scale, the tradeoff is overwhelmingly in favor of simplicity. The cognitive overhead of managing singleton lifetimes and passing objects through five layers of constructors was costing me more than it was protecting me from.

Anonymous namespaces in the .cpp files. I used to put helper functions and internal state in private class members. It bloated every header. Every file that included that header recompiled when I changed an implementation detail. It coupled things that had no business being coupled. Now, implementation details live in anonymous namespaces in the .cpp, invisible to the rest of the codebase, existing only where they’re used.

namespace spartan
{
    namespace // anonymous, invisible outside this file
    {
        const float distance_deactivate = 80.0f;
        const float distance_activate   = 40.0f;

        PxTransform to_px_transform(const Vector3& pos, const Quaternion& rot)
        {
            return PxTransform(PxVec3(pos.x, pos.y, pos.z), PxQuat(rot.x, rot.y, rot.z, rot.w));
        }
    }
}

Public data members. My Vector3 has x, y, z as public floats. Not GetX(), not SetX(). I know this violates what every C++ textbook tells you. But there’s no invariant to protect here. There’s no setter logic. Wrapping these in accessors would be adding ceremony for the sake of ceremony, and I’ve learned the hard way that ceremony has a cost, even when it looks free.

class Vector3
{
public:
    Vector3() { x = 0; y = 0; z = 0; }
    Vector3(float x, float y, float z) { this->x = x; this->y = y; this->z = z; }

    float x, y, z;
};

Standard types used directly. My entity hierarchy is a raw pointer to a parent and a std::vector of children. I tried custom containers early on. Custom trees, custom allocators, custom everything. They all became maintenance burdens that solved problems I didn’t actually have.

Are standard types perfect? No. I’m well aware that std::vector isn’t always cache-optimal, that std::shared_ptr has overhead from reference counting, that in certain hot paths you absolutely want custom allocators or flat arrays. The point isn’t that standard types are always the best choice. The point is that they should be the default choice, and you should only replace them when profiling tells you to. Not because someone on a forum said you should, not because a blog post made you feel like you aren’t a real engineer unless you roll your own.

class Entity : public SpartanObject
{
private:
    Entity*                  m_parent = nullptr;
    std::vector<Entity*>     m_children;
    std::array<std::shared_ptr<Component>, static_cast<uint32_t>(ComponentType::Max)> m_components;
};

A parent pointer, a vector of children, and an array of components. That’s what the problem needs. That’s what the code is.

Assertions instead of defensive programming. Early in the project I wrote defensive code. Null checks that returned silently, fallback paths that hid errors. It felt safe. It was the opposite of safe. Bugs didn’t crash, they hid. I’d spend days tracking down why something wasn’t rendering, only to find a silent return five call levels deep that was swallowing a null pointer that should never have been null.

SP_ASSERT_MSG(physical_devices.size() != 0, "No physical devices detected");
SP_ASSERT_MSG(width  != 0, "Width can't be zero");
SP_ASSERT(m_cmd_list_present->GetState() == RHI_CommandListState::Recording);

If something is wrong, I want to know now. Not six frames later. Not after a silent cascade of incorrect state. The assert fires, and you fix the root cause. Right there. Right then.

To be clear: assertions are a development tool. In shipping builds, you handle errors gracefully where it matters for the end user. But during development, which is where you spend 99% of your time, silent failures are the enemy. The faster a bug screams at you, the faster you fix it, and the less time it has to quietly corrupt everything downstream.

Why “the book” isn’t enough#

I see a version of this tension in my Discord server and pull requests constantly. Well-intentioned contributors propose things like additional abstraction layers, wrapper classes around standard types, or manager-of-manager patterns. The conversation usually goes something like this:

“Hey, I think we should add an event bus system so subsystems can communicate through messages.”

Why? What would it give us?

“Well, we could decouple things and make the architecture more flexible and…”

Will it produce measurable, quantifiable differences in the output?

“Not really. Maybe marginal gains.”

Then it’s unnecessary complexity.

It always comes back to the same question: does the problem actually need this, or are you adding it because it’s what you were taught to do?

I want to be clear. I’m not anti-education. Universities and textbooks teach you patterns for a reason. Factory patterns, observer patterns, strategy patterns, abstract base classes, dependency injection. These are real tools that solve real problems. You should learn them. You should understand them deeply.

But here’s what nobody tells you: they’re guides, not laws of physics. No finite set of rules can cover every situation you’ll encounter. The moment you treat patterns as gospel, as things you must always apply, you stop thinking about your specific problem and start forcing it into someone else’s solution. Sometimes the right answer is a pattern from the book. Sometimes the right answer is something the book never considered. And sometimes the right answer is to throw the book away entirely and let the problem itself show you what it needs.

The greatest innovations in engineering didn’t come from following the manual. They came from someone who understood the manual deeply enough to know when to deviate from it. Kelly Johnson knew every rule of aircraft design. He just also knew which ones didn’t apply at Mach 3.2.

Nature dictates the design#

This is the deeper idea underneath all of it, and the one that took me the longest to see.

When you work on a problem long enough, really work on it, for years, you start to see that the problem itself tells you what the solution needs to be. Not what your education says it should be. Not what the patterns book recommends. Not what the latest conference talk suggests. The problem dictates the design. Nature dictates the form.

Kelly Johnson didn’t start with a desire to build a simple aircraft. He started with a set of brutal constraints: Mach 3.2, 85,000 feet, titanium that didn’t exist in the supply chain, fuel that doubled as coolant. Those constraints forced simplicity. Every unnecessary part was thermal mass that could crack. Every extra system was a failure point at the edge of the atmosphere. The Blackbird became simple not because Johnson liked simplicity as an aesthetic, but because the laws of physics left no room for anything unnecessary.

The same is true in a game engine. When you’re shipping frames every 16 milliseconds, when you’re managing thousands of draw calls, when you’re synchronizing CPU and GPU across multiple command lists, the physics of the problem don’t leave room for an AbstractDrawCallFactoryManagerInterface. The frame budget is your Mach 3.2. The GPU memory is your titanium. The constraints are real and unforgiving, and they’ll burn away everything that doesn’t need to be there.

The SR-71 didn’t have unnecessary parts because unnecessary parts would have killed the pilot. Your game engine shouldn’t have unnecessary abstractions because unnecessary abstractions will kill your frame rate, your iteration speed, and your ability to debug the thing at 2 AM when something breaks and you’re six layers deep in indirection wondering which virtual dispatch is eating your cache line.

What ten years taught me#

After a decade of learning this the hard way, here’s what I know:

1. If a class doesn’t need multiple instances, make it static. Don’t create complexity to manage a lifetime that doesn’t need managing.

2. If a piece of state is only used in one file, put it in an anonymous namespace. Don’t pollute headers with implementation details.

3. If the standard library type does the job, use it. Don’t wrap std::vector in a custom class just to feel like you’re engineering something.

4. If something breaks, let it break loudly. Assert. Don’t write defensive code that hides bugs behind graceful degradation.

5. If you can’t measure the difference, it doesn’t exist. Don’t add a custom allocator, a custom vector, or a custom anything unless you can point to a profiler trace that says you need it.

6. If the code does what it needs to in three lines, don’t write a framework. Three similar lines of code is better than a premature abstraction.

None of these are absolute laws. Context matters. Team size matters. Project requirements matter. If you’re building a plugin architecture that genuinely needs to support third-party extensibility, you might need those abstract interfaces. If you’re working on a codebase with 200 engineers, you might need stricter encapsulation to prevent people from stepping on each other. I’m not saying these rules apply universally to every project in every situation.

What I am saying is this: the default should be simplicity, and complexity should require justification. Not the other way around. Most codebases I’ve seen, including my own early work, get it backwards. They start complex and never ask why.

Every one of these rules is the same rule, restated: if the problem doesn’t demand it, don’t add it. That’s KISS. That’s what Kelly Johnson knew. That’s what the Blackbird was built on. That’s what ten years of engine development taught me the slow way.

The best part is no part. The best code is no code. And the best abstraction is the one you had the discipline not to write.

This is just the beginning#

After a decade, the engine is better than it’s ever been, and I feel like I’m just getting started. The lessons above didn’t make things easier. They made things possible. When your codebase is simple enough that you can hold the whole thing in your head, you can move fast. You can take risks. You can attempt things that would be unthinkable in a tangled mess of abstractions.

That’s where I am now. Not at the finish line. At the starting line, with a decade of hard-won clarity behind me and the most ambitious version of Spartan still ahead.

If any of this resonated with you, come check out the project. It’s open source, it’s alive, and there’s a growing community around it.

Spartan Engine on GitHub

Recently, I added HDR support to Spartan, expecting it to be a quick task. However, it turned into a full day’s work. The main issue? I could only find bits and pieces of code and no all-in-one blog posts. So, I’ve decided to simplify things for you. Let’s dive straight in and aim to get HDR up and running in under 10 minutes.

Step 1 - Swapchain#

First stop, the swapchain. Opt for the VK_FORMAT_A2B10G10R10_UNORM_PACK32 (DXGI_FORMAT_R10G10B10A2_UNORM) format and the VK_COLOR_SPACE_HDR10_ST2084_EXT (DXGI_COLOR_SPACE_RGB_FULL_G2084_NONE_P2020) color space. While other combinations are possible, I recommend sticking to these for the purposes of this post.

Step 2 - Output#

At the tail end of your rendering pipeline, there’s typically a shader that, in SDR scenarios, applies tonemapping and gamma correction. For HDR, you can skip tonemapping (which typically compresses into SDR) and gamma correction. Instead, use the following approach:

float3 linear_to_hdr10(float3 color, float white_point)
{
    // Convert Rec.709 to Rec.2020 color space to broaden the palette
    static const float3x3 from709to2020 =
    {
        { 0.6274040f, 0.3292820f, 0.0433136f },
        { 0.0690970f, 0.9195400f, 0.0113612f },
        { 0.0163916f, 0.0880132f, 0.8955950f }
    };   
    color = mul(from709to2020, color);

    // Normalize HDR scene values ([0..>1] to [0..1]) for ST.2084 curve
    const float st2084_max = 10000.0f;
    color *= white_point / st2084_max;

    // Apply ST.2084 (PQ curve) for HDR10 standard
    static const float m1 = 2610.0 / 4096.0 / 4;
    static const float m2 = 2523.0 / 4096.0 * 128;
    static const float c1 = 3424.0 / 4096.0;
    static const float c2 = 2413.0 / 4096.0 * 32;
    static const float c3 = 2392.0 / 4096.0 * 32;
    float3 cp             = pow(abs(color), m1);
    color                 = pow((c1 + c2 * cp) / (1 + c3 * cp), m2);

    return color;
}

• White point: Typically a value around 350. You might hardcode this value into the shader to get going.
• Rec.709 vs. Rec.2020: Rec.709 defines the standard color space for HD, Rec.2020 broadens this palette for UHD content.
• ST.2084 (PQ Curve): The PQ curve, central to the HDR10 standard, maps brightness levels to align with human visual perception, capable of displaying up to 10,000 nits.

Step 3 - Materials

Your material textures are usually in the sRGB color space. For HDR, ensuring precise linearisation of these textures is important. Typically you would sample your textures with a simple power function approach, like so:

float3 srgb_to_linear(float3 color) 
{ 
    float gamma = 2.2f;
    return pow(color, gamma); 
}

This method falls short for HDR, especially with modern capable monitors which aim for the sRGB standard rather than a simpler gamma 2.2 curve. For more accurate color representation, use this instead (and a good monitor):

float3 srgb_to_linear(float3 color)
{
    float gamma        = 2.4f; // The sRGB curve for mid tones to high lights resembles a gamma of 2.4
    float3 linear_low  = color / 12.92;
    float3 linear_high = pow((color + 0.055) / 1.055, gamma);
    float3 is_high     = step(0.0404482362771082, color);
    return lerp(linear_low, linear_high, is_high);
}

The above function accounts for the sRGB standard’s nuanced behavior with both a piecewise linear and a non-linear curve, providing better color accuracy (especially with darker tones). This approach goes beyond the simpler gamma 2.2 curve that many displays target, aligning more closely with modern displays aiming for the sRGB standard with a 2.4 gamma.

For example, this is the Samsung Odyssey Neo G8 targeting sRGB and a 2.4 gamma.

Let’s look at the image below, observe the obvious color shifts in darker areas (say ImGui) and subtle changes in brighter spots (say the helmet). The improvements are best seen on modern HDR monitor, the screenshots can only convey so much.

Note: You could also use sRGB texture formats to bypass manual linearisation.

Conclusion

There you have it. Enjoy the enhanced visual fidelity!

I want to start things off with a simple and short blog post, yet have some immediate results we can enjoy. You know, something like the kind of instant gratification you get by watching a Bob Ross episode. An approach which I believe to be one of the most efficient forms of conveying information. So, let’s explore something that with a little bit of effort, might give us just that. Time for some screen space shadows 😄

Screenshots#

Here is a wild west motorcycle (courtesy of Matija Švaco) without any shadows.

If we enable shadow mapping, we can introduce some nice large-scale detail, a nice first step.

What if we enable screen space shadows? Well, we get some nice small-scale detail.

The key lies in enabling both as we can get the best of both worlds. Drag the handle to compare.

Shadow mapping + Screen space shadows

Industry comparison#

Loss of small-scale detail when doing shadow mapping is a typical problem, especially with lights that aim to cover a large portion of the scene (like directional lights). As we’ve seen, screen space shadows can help a lot but before we explore them in further detail, let’s see how most of the games we enjoy handle small-scale shadow quality:

• The player is allowed to keep increasing the shadow resolution. It’s a costly approach but it works and it happens to be the most common.
• The player sees lights with very high shadow resolution, during key moments like character close-ups. This approach doesn’t suffer from typical screen space issues but it does involve the hard work of manually tweaking lights, per scene.
• The player gets the extra treatment that is screen space shadows. In some cases, the shadows are even aided by normals as well as information from other render passes, all of which help alleviate some screen space issues even further.

An example of some good-looking screen space shadows from Remedy Entertainment.

The algorithm#

So how do we go about it? Well, the basic idea is that we start by moving from the pixel to the light. We move in steps, in each step, we compare the depth of our ray against the depth that the camera perceives. If our ray depth is larger (further away) from the camera’s, then we assume that the pixel is in shadow.

As we can already see, we can’t reliably tell if a pixel is in shadow or not, using only screen space information. But we don’t have to worry that, as if we recall the comparison pictures we saw previously, we only need to supplement shadow mapping, not replace it. So the question really is, is this compromise good enough to provide any meaningful information? And the answer is that it is quite decent at small distances, but less accurate over long distances. So, it’s wise to keep this effect at a small scale. This is also why some people refer to screen space shadows as contact shadows, because shadows can only (reliably) show up when the pixel is very close to its occluder, they almost make contact.

Here is the complete HLSL example with comments where necessary:

// Settings
static const uint  g_sss_max_steps        = 16;     // Max ray steps, affects quality and performance.
static const float g_sss_ray_max_distance = 0.05f;  // Max shadow length, longer shadows are less accurate.
static const float g_sss_thickness        = 0.02f;  // Depth testing thickness.
static const float g_sss_step_length      = g_sss_ray_max_distance / (float)g_sss_max_steps;

float ScreenSpaceShadows(Surface surface, Light light)
{
    // Compute ray position and direction (in view-space)
    float3 ray_pos = mul(float4(surface.position, 1.0f), g_view).xyz;
    float3 ray_dir = mul(float4(-light.direction, 0.0f), g_view).xyz;

    // Compute ray step
    float3 ray_step = ray_dir * g_sss_step_length;
	
    // Ray march towards the light
    float occlusion = 0.0;
    float2 ray_uv   = 0.0f;
    for (uint i = 0; i < g_sss_max_steps; i++)
    {
        // Step the ray
        ray_pos += ray_step;
        ray_uv  = project_uv(ray_pos, g_projection);

        // Ensure the UV coordinates are inside the screen
        if (is_saturated(ray_uv))
        {
            // Compute the difference between the ray's and the camera's depth
            float depth_z     = get_linear_depth(ray_uv);
            float depth_delta = ray_pos.z - depth_z;

            // Check if the camera can't "see" the ray (ray depth must be larger than the camera depth, so positive depth_delta)
            if ((depth_delta > 0.0f) && (depth_delta < g_sss_thickness))
            {
                // Mark as occluded
                occlusion = 1.0f;

                // Fade out as we approach the edges of the screen
                occlusion *= screen_fade(ray_uv);

                break;
            }
        }
    }

    // Convert to visibility
    return 1.0f - occlusion;
}

A smart tweak#

Like with many effects, we can just set a high step count, get good looking results, accept the performance hit and call it a day. Afterall, who has the time to trade banding for noise by offsetting the ray’s start position, blur it, and only then be able to use it, right ? I totally understand and I would like to mention that if we have a TAA implementation in our project, we can do the following.

We can choose a noise function and add a temporal factor to it. I derived my version from Jorge Jimenez’s interleaved gradient noise function, as it works particularly well with TAA.

float interleaved_gradient_noise(float2 position_screen)
{
    position_screen += g_frame * any(g_taa_jitter_offset); // temporal factor
    float3 magic = float3(0.06711056f, 0.00583715f, 52.9829189f);
    return frac(magic.z * frac(dot(position_screen, magic.xy)));
}

And then, in our original shader, just before we start ray marching, we offset the start position. This effectively increases the step count (over time).

// Offset starting position with temporal interleaved gradient noise
float offset = interleaved_gradient_noise(g_resolution * surface.uv) * 2.0f - 1.0f;
ray_pos      += ray_step * offset;

Using only 8 samples is fast but introduces banding, or not ? 😉

That’s all#

Before we end this and for the sake of art, let’s appreciate the motorcycle with a material 😄

You can get access to this shader as well as all of my other shaders by clicking here. If you have any thoughts, don’t hesitate to leave a comment or reach out to me via X. I hope that you’ve found this post interesting and that you enjoyed it, stay safe.