Complete.Org: Mailing Lists: Archives: freeciv-dev: July 2006:
[Freeciv-Dev] Re: Project goals - Multiplayer
Home

[Freeciv-Dev] Re: Project goals - Multiplayer

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Project goals - Multiplayer
From: saywhat@xxxxxxxxxxxx
Date: Wed, 12 Jul 2006 10:17:35 -0600

banjo <banjo@xxxxxxxxxx> wrote:
Hi
I'm splitting the thread coz i it's discussing two different things...
multi-player & game balance. At least i want to add game balance to the discussion. This post is about the multi-player issues, i'll also post about game balance.
Per Inge Mathisen wrote:
> The single player game suffers heavily under the restrictions imposed
> by multiplayer. The ban on modal dialogs has improved multiplayer
> significantly, but along with timeout and the undeclared ban on
> pausing the game to display information, it rules out many ways of
> displaying information to the player that can be highly beneficial
> for single player. Opening up a tab for tech selection and throwing it
> beneath the map tab is very nice for multiplayer, where it is
> imperative that you do not hide what happens in the early seconds of
> the new turn, and do not pause other players, but not optimal for
> single player, where it would not matter if the game waited for player
> confirmation of tech selection. Extending the rules of diplomacy for
> more interactivity with AI turned out to be extremely painful, and
> made me give up (see past threads).
The current (single player) turn model is based on rapid feedback to
the player, you give an order and the unit obeys. This is useful for
the player as it cuts down on the amount of memory and planning they
need to hold in their head. In various multiplayer modes, this could let you be overwhelmed by a surprise attack, or demand that you have to be there for every move,
or make it awkward for the reading the dialogs etc.  This mode seems
to favour the fanatical gamer.
It is also completely historically unrealistic, for most of history
and even arguably today, the rulers got reports of events that were
in the past (pre telegraph they could be years old). The new orders
they wrote were not executed immediately, they first had to be sent
(by boat?), and then it took time for the orders to be executed.
What i am saying is that a write/execute method for handling orders
is more realistic, it may be easier to program, and seem to be what
is needed for multiplayer games.
It may be less desired for single player mode.  It may be harder to
code the ai, if it has to keep a record of what it has planned, as
opposed to just looking at what currently is.

  I think that the write/execute model that you described is
good.  Global Conquest (GC) uses a form of that (in both single
player and multi-player games).
  Of course, in GC, all the orders that a player "writes" (for
his troops) actually reach his troops during the execution phase
of that same turn.  Did you intend that some orders would take
longer than one turn to reach the troops?

<snip discussion of AIs playing Freeciv in our place>
Per Inge Mathisen wrote:
> Fixing multiplayer Freeciv would either involve a change to
> "turn-less" playing, similar to what Civ4 offers
> (http://www.civ3.com/devupdate_multi.cfm), which would not work very
> well for long-turn games, giving priority to shorter games, or a more
> radical redesign towards a Moo2 model where players queue up actions
> that are executed in the turn end, which is what will work best for
> long-turn games. (If at this point you ask "why not offer both as
> options?", you have simply not understood the depth of the problem and
> the amount of redesign required for either to work well.)
The first thing the link discusses is a ruleset that allows for rapid
games, more suitable coordinating multiple players.  This can be done
in the rulesets (by using a tournament ruleset), in the server config file (fast city growth, fast tech advancement) and by adding some new victory conditions as options.
These in themselves are not major changes, and the first two are easy
to implement and probably already are.
Then the link discusses how turns could work, ive added more options
to this list, i think having all the possibilities laid out could be
useful....
* Turn Based
* Turnless
* Simultaneous Moves
* Play by Email
* Hotseat
* Queued Actions
* Real Time
* What we have now (is it Simultaneous Moves?)
Are there any more? Please add any that ive missed
Are there any meta patterns here?
Could someone define how each works?
Of all the multiplayer examples in that link, i like the play by email
one the best.  Especially when coupled with the idea of scripting your
ai to play for you when you can't.

"Real Time" (as in RTS - Real Time Strategy) implies (to me): 1) Simultaneous orders
 I.e. All players can issue orders concurrently (and
 continuously).

2) Simultaneous movement
 I.e. When a unit receives an order it tries to execute it
immediately, if possible. 3) No turns
 I.e. There are no restrictions on the number of orders a
player can issue to his units or how fast he can issue them.
  AIUI, except for 3), Freeciv uses this model for multi-player
games. Is this correct?

  When I read the article, the "turnless" mode was the only one
that seemed like a new idea (to me).  But I don't think turnless
mode is ideal for Freeciv. Here's why:
  In a RTS game, you can give orders as fast as you like.
AIUI, in "turnless" it is the same with one exception:
You can't issue new orders to a unit until x amount of time has
passed since you issued the previous orders to that unit.
  I imagine that the effect of this is to prevent excessive
action amongst a small group of units.  But, ISTM that, as long
as you use the timer delay to issue useful orders to other units,
then the game is essentially a RTS game.
  If so, then turnless mode is a RTS game with braking applied
to localized activity.  It also requires that the player be able
to rapidly switch back and forth between theaters in order to
play efficiently.  Because of that, I think that turnless mode
(for Freeciv) would still favor the fanatical gamer - to the
detriment of game balance.

  IMO some of the other modes that you list are partial
descriptions of game modes.  There's nothing wrong with that.  Of
those "partial description" game modes, some can be combined and
some can't.  E.g. "Turn based" and "Play By Email" can co-exist
within one game but "Turnless" and "Hotseat" cannot (AFAIK).
  That said, a clever game design can sometimes combine
seemingly incompatible characteristics.  E.g. Global Conquest
combines "Turn based", "Simultaneous Moves", "Hotseat", "Queued
Actions", and some aspects of "Real Time".
  Please read my post about GC (if you haven't already) for a
brief description of its turn structure.  To summarize it, GC
supports simultaneous entering of orders, but it queues the
orders.
  At the end of the orders phase (when all players have
finished issuing their orders), all the orders are given to their
respective units at the same time.  IOW no unit gets to "go
first" because it received its orders earlier than another unit.
  Then the execution phase begins.  There are 8 rounds in each
execution phase.  All units try to carry out their orders (at
their own speed) until they either complete their orders or until
the 8th round ends.  Then a new turn begins (with a new orders
phase).
  GC's system *can* be played in hotseat mode (but then, on
each turn, each player has to wait while all the other players
enter their orders).  I suppose that GC's system could be played
via email too (though I don't think GC itself supported it).
Per Inge Mathisen wrote:
> Concerns from multiplayer often stand in opposition to making a better
> single player game. I think this opposition is our biggest problem. We
> can make a very good single player game, with the option of playing
> (turn-based) with 1-2 close friends. Or we can create a game that is
> fun in multiplayer. Because once we need to take into account the
> needs of higher amounts of players and a competitive and possibly
> hostile environment, the needs of single player must suffer. In the few multiplayer games ive played they all were abandoned because of the length of time they were taking. I suspect this is a fundamental problem. Either have a long complex satisfying one player game ( which is the way i play freeciv) or have a simpler & faster multiplayer game.

  The article also acknowledged the difficulty of transforming
a game which typically takes several hours to play (as a single
player game) into a multiplayer game.  ISTM that alternate
victory conditions are essential if Freeciv (or any other large
4x multiplayer game) is to be playable (to a conclusion) in one
sitting.
I haven't tried long move freeciv, where i assume players get one turn
a day (with an online early game to get things started). But i imagine
there are issues there as well, in that an end turn goto attack, with
a early next turn follow up, may overwhelm a more casual player.
This is possibly realistic, (blitzkrieg, pearl_harbour), but i imagine
would annoy the victim, as they'd feel they didn't have a chance, this
is considered poor game design (ie not fun).

  I agree.  IMO, it is unacceptable that such a tactic is even
*possible*.  Victims of this tactic may feel like they are
newbies who are being abused by veteran players.  IMO that's not
a good way to build a community of players.
Per Inge Mathisen wrote:
> So perhaps what we need is a split of Freeciv into two projects, one
> for a multiplayer game and one as a single player game? If that's what's required, then so be it. However, is it possible for there to be some backend part that's common between the two, with most of the forking being at the client end? Or have i not understood the depth of the problem, and the amount of redesign required for this to work well?

  I hope that a split can be avoided.  As Vasco cautioned in
another post, the history of some games' development (Xconq and
LPmud were the examples that he cited) warns that fragmentation
of the development effort can be the beginning of the end (of
course I'm paraphrasing :-)). -Eddie


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