A post to Open Manufacturing, regarding my game idea, The Clanking Replicators. A 2009 project. I think I’ll do the v0.1 in Python, and kill two birds with one stone.
Update: This is now in a wiki:
http://clankingreplicators.wikidot.com
—
Hi again all,
Paul wrote this:
> If you are getting into Flash, like with your pong game (nice sounds), a
> cool games about open manufacturing might be nice. Anything about making
> things. I have some ideas, but you might have better ones if you just think
> about it yourself first.
Ah well I *do* have a semi-manufacturing game/sim idea, which I’m
working on writing an intial spec for, and which I’m intending to get
started on in 2009.
This is a very geeky for-programmers-only game.
Has anyone here played any of the various tank or robot battle type
games that have come and gone over the years? Ones where you design a
tank/bot (choose weapons, armour, sensors, engine, etc etc), and write
a control program for it, then set it against others in a virtual
arena?
Examples:
http://www.mobygames.com/game/omega_
http://www.mindrover.com/index.html
http://robowar.sourceforge.net/RoboWar5/index.html
I used to have Omega, loved it, and I played a lot of Robowar at uni
in the mac labs.
Anyway, start with this idea in your mind. But then imagine a serious variation:
- What if this was an mmo?
- What if the bots had to find resources to “metabolise”?
- What if the bots could replicate?
Then, you’d have something approaching a life simulation. That’s what
I’m thinking of.
The general idea is this:
- There is a persistent online environment, made up of a multitude of
interconnected but relatively discreet battle fields or arenas. These
environments have resources in them (stuff you can dig up, stuff in
the air, sunlight, broken bot bodies), and are mostly flat and open.
- Players can spec up bots, including providing a control program.
They can test these locally in simulators, then they can inject them
into the online environment according to certain rules (possibly
putting them somewhere isolated to begin with so they can get a chance
to sort themselves out).
- The bots are composed of hardware modules, which all perform certain
functions (weapons, comms, manipulators, sensors, central processor,
etc), and have “metabolism” requirements (eg: energy requirements,
other material requirements, and might require repairs from time to
time).
- The bots can reproduce; ie: they can create new bots. This will
include providing the initial control program for the new bot, which
can be the parent bot’s own program, or something else.
- The control program should be represented as a string, or an array
of bytes, and should be self modifiable.
- Part of the environment will be “chat channels” which bots with the
appropriate comms hardware can talk on. So bots can collaborate fairly
easily.
- The control hardware should support powerful high level languages.
I’m thinking that a JVM, for J2ME, might be the ticket here, with the
bot hardware being accessible through a provided class library. So
then players can use any language for the game which can compile down
to j2me code, any dev environment they like, etc.
Now, when you look at an environment like the above, designed not for
a handful of simulated robots to run around in, but for really large
numbers of bots, you must immediately think “wow, that’s a lot of
processing required”. Yes!
The environment will be designed to scale to as much processing as can
be thrown at it. Think a 2D grid of connected battlefields. Over time,
each battlefield should support roughly the same number of bots, some
constant number. The processing scales, then, by the number of
battlefields growing or shrinking as resources are allocated and
deallocated. It might autoscale, trying to keep a constant ratio
between in-game time and real world time. Or, it might try to maximise
this ratio and just keep the world size constant. Or it might do a bit
of both.
The processing will be primarily based on volunteer computing. The
initial target for the world processing will be Boinc.
One good thing about a game is you can make it artificially match the
constraints of volunteer computing; I aim to do this in the following
ways:
1: The game is temporally segmented (you can process from time X to time Y)
2: The game is geographically segmented (each battlefield is a world
of its own. you can travel between them, but this is constrained as
below)
Volunteer computing requires the ability to process discrete chunks,
and validate the results (you can’t trust the processing nodes). I
suggest doing this as follows:
1 – Cut processing into temporal+geographical chunks as above. One
unit of processing is for a set length of in-game time, on one
battlefield
2 – Movement between battlefields is constrained to happen only
between these chunks (ie: bots have to wait until the end of a time
segment to be moved)
3 – Within one chunk the game is *fully deterministic*.
The third point is important. The game is fully deterministic in one
chunk, and validation is performed by handing out the same chunk
multiple times, and bitwise comparing the results; they must match.
Also, to constrain the work to be done, everything in game must have
an in game time cost, including basic processing. So the JVM
implementation must enforce these time costs on all instructions. It
would need to be controllable from the sim engine where, at time T,
the engine would tell it “perform your next instruction and return the
time cost” (call this C), then the engine would not ask it to perform
another instruction until time T+C.
All these chunks would be assembled at a server, and the raw output of
the sim would simply be a rather stupendous log file, available
online. It might not actually be a file, I’m just using that as a
metaphor.
There need to be a LOT of tools for seeing in to the result log. These
would include action visualisation tools (where you can watch
historical action in “realtime”, maybe a flash front end?), as well as
lots of reporting type tools which can aggregate raw log information
and make it understandable, so for instance players can see how well
their bots are reproducing, all kinds of factors about resource usage,
etc etc, tools for seeing graphs of mutations where a player has
implemented a bot on which selection can occur over time, etc.
Finally, the whole thing must be open source. GPL or BSD style
license? I’m not sure. All of the above probably. Although I’ve
written about a centralised persistent environment, anyone should be
able to make their own server setup and have their own persistent
environment. Anyone should be able to modify the clients and boinc
plugins as desired. Nothing depends on binary code with hidden
secrets.
And, of course, I dedicate this idea in its entirety to the public
domain. Do with it as you will!
