[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: cirrus
Subject: Re: Global game design (Was: Re: [Adonthell-devel] Battle System)
Date: Wed, 30 Jan 2002 16:43:22 +0000

All sounds mighty cool - one question though:
Does this also make it possible to have multiple players on one machine?
Like if you have 2 or more gamepads or a pad and a keyboard? Obviosly
they'd share one screen and could walk very far apart but it's still fun
if you have friends round and they can just join in.

Alexandre Courbot wrote:
> > 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 (,
> 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.
> --

   ___    ___  ___       ___ 
  /    / /__/ /__/ /  / /__                 Reg. Linux User #148821
 /___ / / \  / \  /__/ ___/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]