Imagine ...

Imagine a world, a game, a server, a client. Imagine all of us creating a programming world in which people can learn from experience and from seeing what we have done.

Imagine that it’s 0500 and you’re getting an idea, or a world of ideas. Or ideas of a world.

Imagine that last night you spoke with some friends about teams of students, learning programming. Imagine that you spoke of a team assignment. Imagine that you dreamed of providing a spec of some kind as part of that assignment. Imagine that you could invite many programmers of long and short experience to work on that assignment, that spec, showing how they might address some part of the assignment, in a language and style of their choice. Imagine students—imagine anyone, really—studying these examples and learning by that and by creating their own examples.

Imagine …

It’s a game. It’s a world. It’s about programming, creating a world, in which you can play the game, create the game, program the game, test it, read it, change it, learn from it.

Imagine …

Your way of building a product is inherently incremental, focused on learning what it is that needs to be built by building it in the presence of people who can help decide what it is to build, help build it, help assess what has been built.

Imagine …

You want to provide people with experiences from which they will learn. You believe that they will likely learn things similar to the things you have learned, and you’re sure that they’ll learn things that are different as well. Mostly, you want to provide them with experiences that will give them a chance to learn to find the joy you have found in creating things via programming in the presence of others, working together to build a thing that is taking shape in all their minds, via the work of all of them.

Imagine this, or something like this:

There’s a server. There’s a world in this server, no, a universe, albeit a small but growing one. The server / world has some properties built into it. Because “incremental”, it starts with zero properties, then we add more. The server / world contains entities, which are groupings of properties. One kind of property is “behavior”.

There are clients. Clients can talk to the server / world, populating it with entities defined by groups of properties.

The server plus clients together create a shared universe. Early on, it’s almost nothing, a static sort of space with entities in it. We’ve already written too many words about it and should get to programming it. But it’s 0520 and we are here with just an idea, for now.

We don’t know, here at 0520, what properties or behaviors will exist. We’ll invent and implement a few so that we can work with a trivial client and a trivial server to build a trivial world. Probably an entity has a position, a small set of numbers, maybe x and y. It might have a name or a type, maybe “Spot” is a Cube. Maybe we start with even less than that.

Spot might be able to “move”, by telling the world / server something like “move north 5”. The world replies with some information “you are now at position <x1, y1>”.

You begin to evolve the server world and client entities toward something you can now vaguely describe like this:

GameWorld is a programming space in which clients written in any language¹ can talk to a server world, putting entities into that world to interact with the world and with each other. All the entities from all the clients are in principle able to interact. Of course, if they are far enough away from each other, they might interact very little or not at all.

GameWorld entities have some inherent properties to be defined later. However, any client can define a new property, giving it a name, a description, a value. Property names are managed in some reasonable way yet to be invented. Perhaps an entity can be created as some kind of assembly of other entities. Could we build a Maze out of Cubes? Surely we could. Could we build a truck that could carry goods? Possibly?

Entities have some inherent behavior, such as the ability to move some distance in the world. A client can define a new behavior somehow. One way is to provide the server with a “script” for the new behavior, in terms of existing behaviors. Perhaps another way is to handle the behavior itself. A client might define a behavior “Teleport x, y”. When that client, or any other client tries to teleport, the server allows the defining client to determine what happens. That probably comes down to the defining client doing some calculation and then sending the server a command series on behalf of the calling client.

Is that too vague? Yes. But we can remain open to the idea and see whether we can do something with it.

It is now 0600 and I would like to get some more rest, since I only turned in at 2359 yesterday.

But imagine …