Region/Multiplayer idea

[JoeST]

Brought from a post in the main thread. Wouldnt mind some opinions on it



Well...I did some brainstorming today. I thought that a nice way of doing 'multiplayer' mode, would be to store the cities/worlds in a distributed revision control repository. I personally know git and how it works, (including, to some extent, its plumbing mechanisms).

So what we have is world repositories stored on a server. Each one of these worlds holds all the empty-worlds terrain/climate/(other worldwide) data. The author of the world repo is the only one that can update it (unless he gives permission to others).

To start playing with this world, you clone the repo to your local store (a folder on your pc). This allows you to view and edit the world. It also allows you to start creating and building cities.

If you wish you can subdivide the world into rough country/province/region areas (henceforth called region repos), which become sub-repos to the main world. These can then contain multiple city and even sub region (for example, the multiple states in America, or different continents, or (if you LOVE micromanaging) different postal addresses).

A city (or countryside region) contains all the information related to your city. In building mode, every time you do one of these actions:
- Create neighbourhood/transport network/etc.
- Edit LOTish (an abstract, (dynamically created), in-game-editable Lot thing).
- Auto save¹.
- Micromanage economy/etc..
The game saves what you have done in a commit. Which allows for both concurrent playing (two people playing the same city) and undoing actions.
Once you have reached a stage where you wish to share your city: either read-only (so people can browse it on the web/use it as a neighbour) or read-write (a colaborated city project). You publish (what is known as a tag and/or push in git) your city to the public place².


So, an example:

Our good friend David (dedgren) feels like starting a 3RR in our game. He clones (downloads) the Earth repo from a server that has it and opens the game. He now has an empty world thats the size of Earth (relatively) and has a bland outline of the continents and seas and mountains (no point having a fully blown detailed map when you can detail it out in sub-regions). He then has to download (in the background) the North-America sub-region, which includes more detail of that specific area.

He selects New Region from a menu or something. He drags out the space that 3RR occupies in the North-America sub-region of Earth and calls it Three-Rivers-Region. This now has a folder on his pc with all the terrain data of that region in it (I guess it would be blank, or maybe a copied version of the area it covered in North-America) . He sets to terraforming it how he likes (with auto-commits behind tool-change events) and all that data is saved in his Three-Rivers-Region repo.

After that is done, he divides the land up into parts for his collaborators to work on. So he now has a load of sub-project-repos in his Three-Rivers-Region folder/repo. Each is fully editable by him, editable to a level he selects by its named collaborator, privately-viewable by other collaborators (so that they can match boundaries, check out stuff) and publicly viewable to the public (like a web-viewer or something).

The place that he is hosting has something along the lines of Trac, which allows him to set a task-list for the collaborator, and restricts the publicly-viewable repos to be selected to certain 'releases'. It also allows the public to report 'bugs' like where trees grow through buildings, and things like that.


Another Example:

One of the NHP guys releases a map of Middle Earth, and Bob (a fictional user) clones it (as part of an Arda world repo tagged 3rd age). He starts making a region in Rohan with a city called Edoras. He plays out the creation of Rohan from when Eorl is given the lands for coming to Gondors (another region/city, possibly built by someone else) aid. Each update is run on a blog, acompanied with a city-viewer for that particular published (tagged commited) version of the city.

He misses the creation of a sub-building of Meduseld in one of his updates and goes back to fix it so it can be destroyed later on (??). So he finds the update and loads it up (by branching at that published commit), and adds it in. He then needs to merge his fixes in to the main branch (the story thread), which is all possible through git ³.


NB:
1. Obviously automatic...
2. A public place can be any server that has git installed.
3. Binary saved data might make it harder, we would have to write a binary->gui converter for the merge tool and then a gui->binary back again at the end of the merge, probably a hooks script would do it

[croxis]

It is a nifty thought but it depends on a lot of factors which might be difficult to promises.  It also doesn't take advantage of the engine architecture we are developing.  The current engine design can take advantage of multiple players in a city at once, and multiple cities being played at once using a classic client-server model.  Creating region repositories is a brilliant idea.

[JoeST]

The problem with client-server is someone would have to run the server for the client to work yeah? So the server is the simulator, and I guess the place where all the data is kept, so what about the server does the committing to the 'master' branch of the repo? and if someone is offline they commit to their own branch locally..or something...

Joe

[croxis]

But who does the master branch?  And two offline players playing their local copy and then want to try and merge them?  Remember, it is client server for everyone, it is just that in single player the server is being run on the same machine as the client.