Programming Worlds

For me, one of the biggest problems with programming languages is that they are languages. Languages are inherently one-dimensional: they progress forward along a line and that's it. For the most part, the things we want to communicate are one-dimensional: "I'm going to eat a sandwich" is a straight progression. "Turn left at the third light, then right at the dead mime" is a straight progression.

But there are lots of things that aren't straight progressions - things that language is bad at. For example, teaching someone how to gut a fish. Teaching someone how to make a hat. Showing someone a fractal. Explaining a molecule's structure.

Instead of trying to explain these with a language, we generally try to explain these with images. Usually, we accompany these images with language, because various pieces of the image might be known well enough to not need explaining. "This is a hydrogen atom", the label proclaims. "You should already know what a hydrogen atom is, so I don't need to explain it further."

Language as label is fundamentally different than language as progression. If you say "This is a donut", that's not really the same kind of communication as saying "I'm going to eat this donut" or "a donut is made of dough and nuts". That's probably important to keep in mind...

"Where are you going with this?" you may ask.

Why are we trying to tell a computer how to do complex things by using a linear language? We don't tell people how to do complex things using a linear language. The only reason we still tell computers in that way is because we really haven't figured out how to get the computer to "understand" a richer system.

Except... that's completely not true. Even ten years ago there were visual programming languages. The computer understood that each piece on the screen was part of a whole.

What is missing from that picture is the relationship between the objects on the screen. You could draw eight text boxes, but the computer doesn't really know anything more about them. Unless you specify in a language, behind the scenes.

That part is a real nightmare, logistically speaking. We've gotten used to it, but fundamentally, it's very messy and difficult. We've come up with a lot of ways to try to partition it, to simplify it, to standardize it, but it's still a nightmare. And it gets worse every year.

So... let's think for a minute.

Instead of thinking in terms of linear language, let's think in terms of pictures. When we draw shapes on the screen, the program knows what those shapes are and where they are. It just doesn't know what to do with them. It doesn't know how the shapes interact with the rest of the shapes and the world in general.

You can make assumptions pretty easily. If you download one of the new "2D physics engines" that are all the rage recently, you'll find that you can easily draw remarkably complicated systems and the computer knows exactly what to do with them. I made a spinny thing that swung a bucket around fast enough to keep water in the bucket despite gravity. It took me two minutes, and I'd never used the system before. How long would it have taken in C#?

Obviously, the assumptions that the engine makes are very limiting. It's not really possible to make a real game in the engine. You would have to look outside the engine for things like scoring, stage control, narrative events, inventory management...

But...

What if I had another system for building a narrative, and it understood the "physics" of interacting plot blobbies I draw. I could quickly sketch out an adaptive, dynamic plot. I could watch the nameless colored blobs spin and bounce off of each other. If I built it, I would know what each blob was. That one's the princess, that's the castle, that's the hero, that's the magic sword... tweak until they bounce and stick and move in ways that make sense, even if you allow the hero to have variable inputs.

In fact, it could be the same engine, fundamentally. While you probably don't want to model plots using only Newtonian physics, those dynamics plus a few more (state changes, for example) would probably suffice. You won't be writing 1984, but you can create a fun, dynamic little plot.

In two minutes.

Now, the problem with that is that it really doesn't have any oomph. I mean, you see a pink blob labeled "princess" and a red blob labeled "dragon" and, well, rescue one from the other. Wheee?

What becomes necessary is to allow this system to talk to another system. Which means that you would express yourself, moment to moment, on the physical system. That would determine some of the state changes in the plot system, which in turn would create a new physical layout for you to manipulate.

This isn't straightforward to actually do. It's only easy to say.

For example, if we're sticking to the knight-rescues-princess bit, and assuming you play the knight, then the primary gameplay would probably involve moving around the physical map stabbing things.

We could simply make it so that when your plot-avatar encounters another plot-avatar, the enemy's level starts up. You kill the enemy, we delete the plot avatar, and your plot avatar keeps floating along in his path.

That's not terribly interesting. Why make a plot engine if we're going to limit people to linear plots?

Instead, we want to allow the player to alter his plot-avatar's path and/or state by what he does in the physical bit.

One way to do this is "measures of success". The character adds how many kills he made to his velocity, and changes state depending on how much damage he took. This provides a minimal level of control, usually only useful for changing the timing of plot events. Still, you might be surprised how much of an effect that can have on a well-designed plot.

Another way to do this is through pickups. These would be physical objects that aren't really physically important. For example, you find a letter from the wicked witch to the traitorous general. You read the postmark, and head off towards her house. This changes your direction on the plot level, pointing you towards a certain plot element.

By collecting multiple "references", you could choose which one to move towards...

Anyhow, the point is that a system that can do "anything" is very complicated to program. A lot of the things we do don't require a programming language, but a programming world. I would say "environment", except that already means something.

There are a bunch of these already around. But because they exist in isolation, they are of extremely limited use.

The core idea is that we can link together a bunch of systems that make specific assumptions and come up with what we need. It could just be stacking the same systems over and over, each time tweaking parameters and gluing in links.

...

Well, I like the idea.

What do you think?