Richard Bartle on Making Virtual Worlds

This is a 2007 talk given by Richard Bartle.

By way of listing out the technologies he needed to know, in order to co-create the first MUD in 1978, this monologue makes convincing points about the really important bits in games. After long minutes about AND gates and compilers, he says, "And I needed a bit of, like, imagination on the top, to create the actual world."

Then, "See what I want, is just to get to the point where all you need is that little bit of imagination on the top."

Video for this used to exist publicly (if you know where it's hiding - let me know!). I thought I'd lost the transcript as well, when a host went down in 2008. I was really happy to find it recently. I've met some of my best friends in MMOs, virtual worlds that may have never existed without Bartle's AND gates, OR gates and compilers. It's really neat to have this snapshot. Thanks again to Richard, for permission to repost his words, and for going to all the trouble in the first place.

Richard Bartle on Building Virtual Worlds

State of Play V: Singapore

I'm glad to see that even at this late stage in the conference there are more people in the audience than there are on the panel.

What we've heard so far, this is a panel about building virtual worlds. And you might have been expecting some kind of technical talk, and you haven't had one. Well, you're gonna get one.

And you're gonna get one as an explanation of why this kind of panel won't be around in ten, fifteen years time. See when I co-wrote the first virtual world, what did I need to know?

Right, well, what I knew to start with was that memory is made of cores. These little torus-shaped pieces of soft iron and they're hung up over this little crosswork of wires with a read wire going through it. I also knew that I could build AND gates and OR gates out of electrical circuits by combining those in a NOT gate, a bit more sophisticated. I could make flip flops. JK flip flops, SR flip flops. You could combine flip flops together to build units which would do half adders, which would do a half the arithmetic of a full adder, which was made up of a several half adders. You could shift registers from side to side. You could also build a register which told you which of the other registers you wanted to use.

And you had a program counter, because you'd have a whole load of memory, and a program counter loads from memory into your central processing unit which has an (fetch?) execute cycle. And that told you what the arithmetic and logic unit which I've just described would do. So I knew that, I also knew that in order to program this you had to type things in pretty well on switches. You had to set some switches. Press the button, switch. Press some more switches, press the button until you'd loaded the memory with just enough so that it could read from a paper tape. Then on the paper tape you put in just enough instructions that it could read from a magnetic tape.

And then from the magnetic tape it could boot an operating system, and then an operating system could then read to a hard drive and write to a hard drive.

From the hard drive it could read all the programs you were going to need, which were things like how to copy a program, a file from one place to another. How to rename, we have programs for all of these things. I also knew that if I wanted to make the program to do anything I would need to write in an assembly language. Which originally would have been written in binary, but now because people had written them in binary we had an assembly language, which was a low level language. Each instruction corresponded to one instruction in the architecture of the hardware.

But even though I could program in an assembly language, I actually wanted to program in a high level language, because it takes a lot of time to program in an assembly language, so we had a compiler. And the way to compile a work we had fifteen, no thirteen different boot steps until, from being written in assembler it could compile itself.

So we had a compiler. BCPL, Basic Computer Programming Language. My favorite language.

In BCPL, plus some assembler, I was able to write my own compiler, and my own database and my own interpreter which is kind of like an operating system for a compiled language. And I did that, and I read from my database a description of what would turn out to be a virtual world. It dropped some assembler, which would be run through an assembly language compiler to create actual executable code.

That would then be loaded into the interpreter, which I had also written. Which would read from a file a database would also hold information about all the players. And then I had a virtual world. And that's what I needed to know.

And I needed a bit of, like, imagination on the top, to create the actual world.

Now, you don't need that nowadays. Nobody goes out and writes a database. They go and buy one or get one for free, there are databases all over. Nobody today writes their own compilers. You don't have to write your own compiler, why would you? They come with lots of documentation. They've been around for years. Nobody writes their own interpreters. What today's people do is they take libraries of software that have already been written and they kind of sew them together. And then they put them as an architecture.

So what we've been hearing here is different architectures for virtual worlds. But none of the people here have gone to the extent of actually writing their own database.

But at the moment, we're only part way along. Part way along where we're going.

Because in ten years time, you won't need any of this. Maybe not ten years time. Maybe fifteen, maybe twenty. Maybe I'll be dead.

Well, I wouldn't know, would I?

See what I want, is just to get to the point where all you need is that little bit of imagination on the top.

Let's say that I want a pagoda inside of a virtual world. Ok, let's say, pagoda, it's like a white thing, it's kind of tall, it's got an odd number of floors and there's little red circles round each floor. Let's say the circles are made of tiles, and the pagoda is made out of white brick and it's got little heart-shaped windows all the way up into the bottom. It's got this nice door with the brass fittings and a little dragon embedded on it.

I want to be able to say, "That." And have a pagoda, "There." That's what I want.

I don't want to have to program all the way from prims, or anything else. I just want to say, "That's what I want, give me it. Where is it?"

We don't have that yet, at the moment we're still on the way.

We're still building, we're still bootstrapping ourselves up; in the same way that the BCPL compiler was written in BCPL. And the BCPL itself was not quite as sophisticated as the final version. And to get to that one you had to write another compiler in a smaller version of BCPL and so on. Until the very smallest version of the compiler you could write in assembler; and then it was all bootstrapped up. We're on a bootstrapping process at the moment.

Virtual worlds have got a long way to go, but we're getting there very quickly.

And in terms of building virtual worlds. The less technology that people need to know, the more people will build virtual worlds. The more people will build them, and the more virtual worlds we'll have. And the virtual worlds we have will be beyond our imaginations at the moment (Richard asides: because there are only 250 of us, or only 10 of us in the room).

But there are millions of people out there, and they've all got their own imaginations. They've got wonderful things that they want to do. All we can do at the moment is to help provide them with the means to do it.

And some people have the ability to create pictures, some of the people have the ability to models or to animate. But eventually, once something's been animated, it doesn't need to be animated more than once. Once a compiler has been written, it doesn't need to be written more than once.

You don't need to know how your internal combustion engine works in order to drive a car.

People won't need to know how these things work, they'll just be able to use their imagination. And this is where we should be, where we will be heading.

This is what you people, half, a quarter my age have to look forward to.

And that's what building virtual worlds is about.

(Paraphrasing Richard: People aren't giving technical talks here, because we've 'bootstrapped' past that point)

And eventually, the aim of virtual worlds is for us not to have a panel like this at all. We'll only be talking about the wonderful marvelous cool things you can do, and how to avoid being sued for doing it.

(Audience question: What keeps you up at night?)

Apart from songbirds, bad opera singers and fierce air conditioning (Neils says: none of which were to be underestimated at the Marina Mandarin), what keeps me awake at night is the worry that people are going to take away my toys. We've got these virtual worlds, and after 25, ehh, 30 years they're finally getting somewhere. They're getting to somewhere which is almost to where we'd want them to be. And I've got this terrible worry that someone's going to take them away.

Because, although virtual world developers are indeed the gods of their worlds, they are not actually gods in the real world. And, sadly, there are people in the real world who've got armies. And they can make you do things.

They do this through lawyers rather than actually throw the army at you. They only throw the army at you if you don't do what the lawyers tell you.

But you can be made to do things, they can switch the power off. They can take anything away.

A few bad court decisions and, ugh, what happened to my toys? You've broke them.

You may have been trying to protect some community from the awful, one-sided EULA. Which, if you then strike it out, nobody ever creates a virtual world, so you've protected the community by removing the community.

You may [become] extinct, in an attempt to protect [your virtual world]. There are many ways that people could break virtual worlds. This is why I come to the State of Play conferences, because this is where much of the thought of how virtual worlds are treated, by the real world, goes on.

On an earlier panel we had the philosophical point raised, which is that virtual worlds are part of the real world. And of course they are, the real world always wins. And of course the players know that the virtual world is part of the real world. They have to try very hard to force themselves to disbelieve that for just long enough that they get a sense of being somewhere else, so that they can treat it as a different place.

If all the sudden the real world comes in and pricks the bubble and says, "Nope, sorry, you're in the real world," they lose what gives them much of their real power.

And that's what keeps me awake. I don't want people to say, "Virtual worlds, they've bled into the real world so much that it's indistinguishable, the real is indistinguishable from the virtual."

Well at times you do actually need the virtual, and that's what worries me.

That, and that air conditioning.