Global game design (Was: Re: [Adonthell-devel] Battle System)

[Alexandre Courbot]

> Ummm.. wasn't that what we were planning to do? Remember Alex started
> redesigning the map-engine in a server/client way to accomodate exactly
> such a feature. :)

Yes. And the random ideas maturated quite well during these few weeks.
Moreover I had a great example of game design that I think would
perfectly fit to Adonthell. Hang on, it's gonna be... space. ;)

I recently bought Terminus. As you probably don't know this game, it's a
commercial title that has the particularity to be shipped for
Linux/MacOS/Windows in the same box (otherwise, how could I play it,
hehe). But it has another particularity, much more important: it's
probably the best designed game I have ever seen. I'll have to come to
some description of the game.

Terminus (http://www.vvisions.com/terminus/story_frame.htm,
http://www.vvisions.com/terminus/graphics_main.htm) is both a space
simulator and a RPG game. You can either engage as a military, become a
pirate or run as a mercenary. In the latter case (the most interesting)
you'll have to manage your ship(s), gain money, talk to people, and so
on. You travel in the whole solar system, which planets & satellites are
also modelized. I insist that the game as a whole RPG system - but the
most interesting is the way they implemented multiplayer mode &
persistance.

Most often in games, there are a number of key elements/characters, and
a lot of less important stuffs. In Terminus, you'll often meet others
ships and people. The interested thing is that:
-A ship is never a "random" thing or ennemy because
-Each ship belong to another NPC character (there is quite a lot of
them)
-Each characters go on their own business, depending on their alignment.
When I say they go on their own business, if you and Random J. Pirate
are at the two opposite ends of the solar system, you can still locate
him on the radar and know what he is doing. NPC's hijack each others,
make contracts, trade, travel, just like a real player. They do not
depend on you AT ALL. You can sit down and look at how the world
evolves. The game world still exist, with or without you. It's totally
persistant.
-In these conditions, you can guess that implementing multiplayer is
quite easy. Such a design allows the game to be played both in single or
multi player, with the same engine, without any change. To my eyes, it's
the ideal in game design.

How would it work for us? Let's take the map system. A map must be able,
like Terminus, to run with characters doing their own business on a
machine, without graphisms (they are only on the 'client' part), and the
player would only have a special schedule that reacts to the player
input, just as we do now.

A classic map would just contain information for the game to run. No
displaying, nothing. From this class would inheritate another map (or we
could connect others data structures), with the same abilities of
course, but also ways to render on screen.

In single player mode, you'd then have the game that runs on this map
with graphical capabilities, and the mapview would just render it. No
network connections, no performance lost compared to a totally single
player game.

In multiplayer, the server would run a non-graphical capable map.
Clients that connect to it are sent the map information they need to
update their local copy of the map. That is, the client map is exactly
the same as the single-player one (and has all the properties of the
server one, as it inclues it), but instead of running the game, it gets
updated by the information the server sents:

------------------                               --------------------
|                |        Update information     |                  |
| Client map     |  <--------------------------- |  Server map      |
|(server copy)   |                               |    (runs)        |
------------------                               --------------------

In this case, we need a way to serialize the necessary map data to send
it to the client. There is also a network layer that is used, that isn't
needed in single player mode. As you guessed it, a single player game
can easily turn into a multiplayer one: clients connects to the player's
machine, but will experience pings while the local player will not even
use network, as he directly renders the master map.

Uuuuuhhh, saying that I realize it's much like Quake III dedicated or
not servers. Which makes me think it's the way to go! :)

Another advantage is that the multiplayer constraints doesn't need to be
considered immediatly. You can program the classes for single player
only, then extend them with serializing and communicating capabilities
to get a multiplayer stuff. Also, you can easily tune/change the
communication protocols if they doesn't fit first.

The result for single player games would be exactly the same as the
stuff we had with Waste's Edge - NP characters were already not
different from the player, and they were also doing their own stuff.
This structure has the advantage of being much clearer and extensible,
especially extensible to multiplayer games.

Please tell what you think - I thought a lot about it and it seems to me
that it would perfectly work. But until I start programming it a bit, we
can't really know whether or not it's the best idea.

Alex.
-- 
http://www.gnurou.org