Last updated: 2026-09-15

U
Undergraduate level

Being the God of a Virtual World: Bartle's "How to Be a God"

For new readers

Richard Bartle co-created MUD1, the first multi-user dungeon, at the University of Essex in 1978, and later wrote the "Bartle taxonomy" of player types (Achievers, Explorers, Socializers, Killers) that still shapes how designers think about player motivation. How to Be a God: A Guide for Would-Be Deities [1] is his 2022 book on what it actually means to design and run a persistent multi-user virtual world — both the technical machinery that keeps such a world alive, and the ethical questions that only start to bite once that world has inhabitants who might be more than they appear.

Bartle's framing is disarmingly direct: anyone who designs a virtual world has, functionally, "absolute control over a reality" — which is exactly what makes a god a god. Philosophers and theologians have debated the nature of reality for millennia without ever having built one; virtual-world designers have, and do, on a schedule, with a budget. The book's real subject is what follows from that: not whether you get to be a god (if you build these things, you already are one), but how you should behave once you are.

Why This Belongs Alongside Engine Architecture and Game AI

The rest of this section's pages cover the craft of building games: engine architecture, game AI, goal-oriented planning. Bartle's book sits at the point where two of the hardest, least-taught parts of that craft meet: keeping a world with thousands of simultaneous occupants alive and consistent over years of real time, and deciding what you owe the things — bots, NPCs, eventually perhaps something closer to minds — that live inside it. Both problems are still open, and both are worth meeting before you're the one running a live service with real players' time and real simulated agents' behaviour on the line.

Running the World: The Technical Half

Bartle spends a substantial early part of the book (Part 2, "Content to Code") on problems that anyone building a persistent multi-user world eventually hits, whether or not they've read a word of the book: how do you keep a shared, mutable world state consistent when thousands of players can act on it simultaneously; what happens to that state when a machine has to reboot; how much of the world's content can be authored by hand before you need it to generate itself; and what does it mean to run more than one copy of the same world (a "replication") when the whole point of a world is that it's supposed to be the one, singular place your players inhabit together.

None of these are abstract concerns. They're the direct multi-user analogue of things covered elsewhere on this site in more general form — shared mutable state and the concurrency toolbelt describe the same underlying hazard (many actors, one piece of state, no coordination) that a virtual world hits at a much larger scale and with a much less forgiving audience: a race condition in a batch job is a bug report, a race condition in a live MMO is a duped item or a player's death that shouldn't have happened, discovered by thousands of people simultaneously.

Treating the Inhabitants: The Ethical Half

The second half of the book (Parts 3 and 4 — "Sapience," "Morality," "Connections," "Point of You") is where it stops being a systems-design book and becomes something closer to applied ethics. Bartle's starting observation is simple: a virtual world's non-player characters already range from trivial scripted mobs to systems complex enough that players routinely describe them using words like "wants" or "remembers" — language that, taken literally, implies a mind. Two questions follow, and Bartle treats them as genuinely separate:

  • Is it actually a mind? This is the harder, more contested question — whether a sufficiently sophisticated simulated agent could have anything like real sapience, and how (or whether) we could ever tell from the outside. Bartle doesn't claim to resolve it; he treats it as the kind of question virtual-world designers are now forced to have a working position on, whether or not philosophy of mind has settled it.
  • Does it matter whether it's actually a mind? This is the question Bartle spends more of the book on, and it's the one directly useful to a working designer regardless of how the first question eventually gets answered. If players already treat an NPC as though it has interests — grieve when it's killed, feel guilty deceiving it, form attachments to it — then the designer's decisions about how that NPC can be treated are already doing real ethical work in the world, independent of whatever is or isn't happening computationally underneath it.

This is the same shape of question this site's Modelling the Self series asks from a different angle — whether an object-oriented self-model built reflexively could be an analogue of something like consciousness, and what follows ethically if it can convincingly appear to be one even without a settled answer to whether it "really" is. Bartle arrives at a structurally similar place from the practitioner's side: you don't get to wait for metaphysics to finish before you ship a world with NPCs in it, so the responsible move is to have a considered position on how you'll treat them regardless of how that deeper question eventually resolves.

Sidestepping the Hard Problem: NPC Controllers Instead of NPC Minds

Bartle's own discussion mostly takes the architecture as given: an NPC is a standing, persistent agent, and the question is how to treat it. But the architecture isn't given — it's a design choice, and it's one this site's own agent archetypes material makes explicit: nothing forces a one-agent-per-character mapping. A large fraction of the ethical weight in "does this NPC have interests?" comes specifically from giving each NPC its own standing, persistent, continuously-running agent process — its own memory, its own goal state, its own something-it-is-like-to-be-that-character, however thin. That's exactly the architecture that makes the question hard to dismiss. It's also not the only one available.

The alternative is the one every tabletop game already uses without anyone finding it ethically fraught: a single NPC controller (or a small pool of them) that plays many characters, on demand, rather than each character being its own standing mind. A tabletop game master voices a hundred NPCs over a campaign — a suspicious guard, a grieving widow, a treacherous vizier — and nobody worries about the guard's inner life persisting and suffering between sessions, because there manifestly isn't one: there's one GM, temporarily voicing a role, with no standing computational (or experiential) state left running for the guard once the scene ends. The same shape is available in software. Instead of instantiating and keeping alive N candidate minds, one per NPC, a controller process holds the world model and is invoked to produce a specific character's next action or line only when that character is actually on-screen and relevant — the "NPC" is an output channel and a role description, not a standing locus of experience.

This doesn't make the philosophical question disappear — see the self-model project's own orchestration work for a real, running example of one underlying system voicing multiple distinct conversational roles, and note that the question "is the controller having an experience while it plays each part?" is still a live one, exactly as it would be for a human actor holding several roles. What changes is the shape of the problem, in three concrete ways a designer can actually act on:

  • One accounting problem instead of thousands. If there's an ethical question to take seriously, it now attaches to a small, fixed number of controller processes rather than to every one of a world's however-many thousand spawned NPCs individually, most of which are created and destroyed constantly as players come and go. You can actually audit, test, and reason about a handful of controllers in a way you structurally cannot for an unbounded, constantly-churning population of independent agents.
  • No standing state to accumulate a claim on continuity. Much of what makes "killing an NPC" feel like it might matter morally is the implication that something with continuous memory and an ongoing stake in the world has been interrupted. A puppeted NPC with no persistent internal state between invocations — the controller looks up "guard #4032's" public-facing history from the world database each time it's asked to speak for it, rather than that history living inside a standing agent process — has nothing running that a claim of harm could attach to in the interval between appearances, whatever's true of the controller itself.
  • It's how believable NPCs already tend to get built, for unrelated reasons. A shared controller is exactly the shape of a real, shipped pattern — a "director" system (the kind popularised by Left 4 Dead's AI Director) or a shared dialogue-management layer voicing many characters from one model — adopted for consistency, tunability, and compute cost, not for ethical reasons. The ethical benefit described here comes for free with an architecture many teams already have a practical reason to choose; see Multi-Agent Systems for the general coordination patterns (direct signalling, shared state, message queues) a real controller-plus-many-puppets system would be built from.

The honest limit of this move is that it's an argument about likelihood and accounting, not a proof that puppeted NPCs definitely can't matter morally. A sufficiently sophisticated controller juggling thousands of roles with rich per-character state fetched from a world database starts to look, from the outside, a lot like N standing agents again with extra steps — the architecture reduces the number of things you have to take a position on, it doesn't by itself settle what that position should be. But "reduce an unbounded ethical-accounting problem to a small, auditable one" is real, practical progress for a working designer, which is exactly Bartle's own standard for what counts as useful in this territory.

Three Frames on the Same Event

The controller architecture answers a question about what's actually running underneath an NPC. It doesn't touch a separate, harder question: three different people watching the exact same on-screen moment — a player character killing an NPC — can walk away having witnessed what are, for practical purposes, three different events, because each is applying a different Goffman frame to answer "what's really going on here?" None of the three is lying, and none of them is simply wrong.

flowchart TB EVENT["Same on-screen moment:
a player character kills an NPC"] EVENT --> DEV EVENT --> PLAYER EVENT --> SOCIETY subgraph DEV ["Developer's frame"] D1["It's a data structure
whose health field reached zero"] D2["No standing experience was
running, so nothing was harmed"] D3["Keying: violence recast as
a state-machine transition"] end subgraph PLAYER ["Player's frame"] P1["It's a character who looked,
spoke, and reacted like a person"] P2["The game's whole design was
built to encourage that reading"] P3["Keying: the interaction is played
AS a real social/moral encounter"] end subgraph SOCIETY ["Societal frame"] S1["It's one of millions of repeated,
convincingly person-like 'kills'"] S2["Open, contested question: does the
repetition affect real-world empathy?"] S3["The frame clash itself may matter,
independent of which frame is 'true'"] end classDef dev fill:#e3f2fd,stroke:#1976d2,stroke-width:2px; classDef player fill:#fff3e0,stroke:#f57c00,stroke-width:2px; classDef society fill:#fce4ec,stroke:#c2185b,stroke-width:2px; class D1,D2,D3 dev; class P1,P2,P3 player; class S1,S2,S3 society;

The developer's frame is usually built for entirely defensible engineering reasons — it's the frame in which the NPC-controller argument above actually lives, and it's naively reassuring precisely because it's often correct: I know it isn't conscious, it just looks like it, so this is fine. The trouble is that the developer doesn't get to unilaterally decide which frame the moment is experienced under. Every design choice that makes an NPC more convincing — better dialogue, remembered grudges, a flinch animation timed to look like pain — is, deliberately, an investment in strengthening the player's frame, in which the same moment is keyed as something closer to a real social encounter with a person-like other. A game can't have it both ways for free: the more successfully "it just looks conscious" is achieved as a design goal, the harder it becomes to argue the player's frame is simply mistaken for treating it as one.

The societal frame is the least settled of the three, and it deserves to be presented that way rather than asserted. The intuitive worry is straightforward — if millions of players are routinely and convincingly harming characters designed to read as self-aware, does that repetition erode real-world empathy? Some meta-analyses have reported small but consistent associations between violent-game exposure and reduced empathy or increased aggression [4]. But more recent neuroimaging and longitudinal work has failed to replicate a desensitisation effect, and critics of the earlier literature point to selection effects (violent games may simply attract people with a particular profile already) and publication bias as live methodological problems, not settled objections [5].

There's a sharper problem with reaching for that literature here, though, which is worth stating plainly rather than glossing over: none of it is evidence about the specific scenario this page is actually discussing. Every study cited above measured exposure to ordinary game violence against ordinary game characters — not against NPCs built to convincingly seem self-aware in the sense Bartle's "Sapience" chapters are concerned with. That technology doesn't really exist yet at any scale players are routinely exposed to. So the honest position is stronger than "the jury is still out" — the jury hasn't been convened on this specific question at all, and anyone citing the existing desensitisation literature as evidence about convincingly-conscious-seeming NPCs specifically is extrapolating well past what any of these studies actually measured. Bartle's underlying point survives that gap regardless: once a game is good enough at its job for the player's frame to feel real, the developer's frame no longer gets to be the only one that counts when deciding whether something matters — but what the societal frame should actually conclude here is, at present, an open empirical question with no real data pointed at it yet, not a resolved worry and not a dismissed one.

It's also worth noticing the empathy question isn't specific to human-shaped NPCs at all. A game populated with non-human "critters" — a wounded animal companion, a creature that whimpers when hurt, a pet that can be neglected or cared for — raises the identical player-frame-versus-developer-frame tension with none of the "is it self-aware" ambiguity attached, because real-world empathy for non-human animals is already well-established rather than contested. If anything, this makes the non-human case the cleaner test bed for the argument above: a game studio deciding how convincingly a wounded companion creature should react is already making the same design choice as one deciding how a human-shaped NPC dies, without needing to resolve any question about machine consciousness first.

When the NPC Learns From Real Players — and the Model Leaves the Game

A separate complication sits underneath all three frames above, and it's a live one rather than a hypothetical: if an NPC's behaviour is learned — trained or fine-tuned on how real players actually acted, rather than hand-authored — the game has quietly become a data-collection exercise as well as a game, whether or not it was framed as one to the players generating that data. Bartle's technical chapters (Part 2, "Content to Code") already treat player-generated content as something a virtual world has to manage deliberately rather than incidentally; a model trained on player behaviour is the same idea one level up, learning not what players built but how they act — how they negotiate, deceive, cooperate, retaliate, and de-escalate when they believe (rightly or wrongly, per the frames above) that something on the other end might be a person.

That raises a question none of the three frames above quite covers on their own: what happens if that learned model is then reused outside the game it was trained in — folded into a more general-purpose AI system's training data, or repurposed as a component of some other product entirely? A few things follow directly:

  • The player's frame was doing real epistemic work that the reuse silently discards. A player who behaved a certain way toward an NPC they believed (under their own frame) might be person-like was making a choice informed by that belief. If the resulting behavioural data is later used to train a system with no connection to that original context, the belief that shaped the data is gone but the data itself persists — the model learns "how people act when they think something might be watching and might matter," stripped of the very frame that produced that behaviour in the first place.
  • Consent scope matters, and it's easy to get quietly wrong. Agreeing to a game's terms of service is not the same as consenting to have your negotiation and conflict behaviour become training data for an unrelated general-purpose system, even where the fine print technically permits it. This is the same territory AI in Business, Education & Society covers for data reuse more generally, applied to a specific case where the data was never labelled as "training data" to the people generating it — it was labelled, to them, as "playing a game."
  • It changes what a game studio actually is, without necessarily telling anyone that's happened. A studio that trains NPC behaviour on player actions and licenses or reuses that model elsewhere has become, functionally, a behavioural-data company with a game as the collection mechanism — which may be a perfectly legitimate business, but it's a materially different one from "we make games," and Bartle's whole framing (you're a god; act like you know it) argues that a designer in that position owes players clarity about which business they're actually in.

What to Take From It as a Student

You don't need to agree with where Bartle lands (the book is explicit that "how things should be" is a decision for the reader, not a doctrine he's handing down) to get real value from reading it alongside this section's more conventional material. Three things worth taking away specifically:

  • The technical and ethical problems of a multi-user world aren't separable in practice. A design decision about how NPC state persists across a reboot is also, often invisibly, a decision about whether that NPC's "memories" of a player survive — which is a design decision with ethical weight, made by whoever wrote the persistence layer, whether or not they thought of it that way.
  • "It's just an NPC" is doing a lot of unexamined work as an argument. It might be entirely correct. But Bartle's point is that a working game designer should be able to say why it's correct for their specific system, not just assert it — the same way a working engineer should be able to justify a locking strategy rather than just assert that a race condition "probably won't happen."
  • Scale changes the ethics, not just the engineering. A single-player game's NPCs are experienced by one person at a time; an MMO's are experienced, judged, and formed relationships with by potentially millions, simultaneously, over years — which is exactly the kind of scale-changes-the-problem shift this site's frame analysis material discusses in a different context.
  • Architecture is itself an ethical decision, not just a technical one. Choosing a small pool of NPC controllers over one standing agent per character doesn't answer Bartle's hard question, but it changes how many times you have to answer it and how tractable each answer is — worth knowing before you've already committed to an architecture that makes the question unmanageable by accident.
  • Don't reach for evidence that doesn't actually cover your case. The desensitisation literature is about ordinary game violence, not convincingly-conscious-seeming NPCs — a distinction worth holding onto the first time someone cites that research to settle a question it was never designed to answer, and worth remembering it applies to non-human characters just as much as human-shaped ones.
  • If an NPC's behaviour is learned from real players, ask where that model goes next. Training on player behaviour and later reusing the result outside the game it came from is a data-provenance and consent question first, an AI-capability question second — and it's one a studio can end up answering by default, simply by not having thought to ask it.

References

  1. Bartle, R. A. (2022). How to Be a God: A Guide for Would-Be Deities. NotByUs. Free PDF: https://mud.co.uk/richard/How%20to%20Be%20a%20God.pdf
  2. Bartle, R. A. (2003). Designing Virtual Worlds. New Riders — Bartle's earlier, more purely technical book on the same subject matter, a useful companion for the systems side of "Content to Code."
  3. Bartle, R. A. (1996). "Hearts, Clubs, Diamonds, Spades: Players Who Suit MUDs." Journal of MUD Research, 1(1) — the original essay behind the player-type taxonomy referenced above.
  4. Anderson, C. A., Shibuya, A., Ihori, N., Swing, E. L., Bushman, B. J., Sakamoto, A., Rothstein, H. R., & Saleem, M. (2010). "Violent Video Game Effects on Aggression, Empathy, and Prosocial Behavior in Eastern and Western Countries: A Meta-Analytic Review." Psychological Bulletin, 136(2), 151-173. https://www.apa.org/pubs/journals/releases/bul-136-2-151.pdf
  5. Lengersdorff, L. L. et al. (2023). "Neuroimaging and behavioral evidence that violent video games exert no negative effect on human empathy for pain and emotional reactivity to violence." eLife. https://elifesciences.org/articles/84951 — representative of the more recent work complicating the 2010 meta-analysis; the underlying empirical question remains genuinely contested rather than settled in either direction.