Complete.Org: Mailing Lists: Archives: freeciv-dev: March 2003:
[Freeciv-Dev] play by email version (PR#663)
Home

[Freeciv-Dev] play by email version (PR#663)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: SCFKyle@xxxxxx
Subject: [Freeciv-Dev] play by email version (PR#663)
From: "John Allman" <allmanj@xxxxxxxxxxxxxxxxxx>
Date: Wed, 26 Mar 2003 09:58:36 -0800
Reply-to: rt@xxxxxxxxxxxxxx

Raimar Falke recommended that i send a summary of a discussion we had on and 
off the freeciv@xxxxxxxxxxx mailing list regarding what would have to be done 
to implement a play by email version and what the difficult problems to 
overcome would be. Since i'm lazy i think i'll just do it with quotes from our 
mails.

I've placed segments of mails between [quote] and [/quote]


The following is my response to a mail from Jason Short (with parts of his mail 
included):

[quote]
Jason Short wrote:


>> I had a few thoughts on what would be needed for such an
>> implementation.  But then I ran into a wall, and I'm sure in any case
>> there are many things I haven't thought of.
>>
>> I assume we want to be sending one e-mail per player per turn.  This
>> e-mail is sent to the server, which also receives every other player's
>> emails and sends an e-mail back to each player.
>>  
>>
>  
>
First off, thanks for your response. You've clearly put some time into 
considering this! I'm just a little concerned by the way you said "sent to the 
server". The way i'm envisioning such a system is that any email server could 
collect the "turn files". Once all files are collected for a round they could 
be then processed in bulk by a server. All the server would need would be the 
current game state and the turn files and it would only ever need to be run 
once per turn. It would produce "update files" explaining the new state to the 
clients. Scripts for automating this could be made for each particular setup, 
but i think the idea of keeping the email server completely seperate from the 
game server is important both for security (i wouldn't like to write an email 
server, even a minimal one from scratch - i'd be far too wary of introducing a 
backdoor) and for convenience (you could run your game server on a dial up 
machine if you wanted - no need to be permanently connected to!
 the internet).

I'm guessing that's what you were thinking of yourself (certainly that's the 
way most play by email games work) but i just wanted to make sure!


>> There are two things this implementation would need:
>>
>> 1. Change the network protocol to deal with binary files that can be
>> emailed rather than a continuous stream.
>>
>> 2. Extend client functionality & change game rules so that the server
>> and client don't need to communicate at all *during* a turn.  This is
>> assuming one email per turn will be sent.
>>
>>
>> #1 should be pretty easy; the dataio code just needs to be extended. 
>> Basically, we still do have a continuous stream of data - it's being
>> sent in e-mail rather than through TCP.
>>  
>>
>  
>
Sounds good:)


>>
>> #2 would be much harder.  To begin with, nobody can make moves during
>> the turn - we'd need something like the proposed goto-at-end-of-turn
>> system where everyone enters goto moves and the server processes them
>> all at the end of the turn.
>>
>> But this is just the beginning.  Currently almost every player action
>> involves the client sending a packet to the server and receiving another
>> packet in return.  Here the return packet needs to be cut out.  In most
>> cases this just means the client needs to know more about the game
>> logic.
>>  
>>
>  
>
Ah - now again i dont know too much about the internal workings of the game. 
Each action in a turn alters the games state? So action A by client 1 before 
action B by client 2 could produce a different result than action B before 
action A? This indeed is a problem. As far as i understand it, most pbem games 
are processed in stages. A moving stage, a constructing stage, an attack stage 
or whatever. The system is designed so that the order in which actions were 
taken during a turn makes no difference. Clearly this could be a real problem 
for making a pbem version of freeciv. I'd really need to know more about how 
actions are processed by the server before i could say more though...


>>
>> My question is, what is the point?  The only advantage I can see to
>> play-by-email is that a direct connection to the server is not
>> required.  But the implementation would have many spin-off benefits from
>> reduced lag effects.
>>
>> jason
>>
>  
>
The point would be 1) that you wouldn't need to have a server permanently 
connected to the internet, 2) you wouln't need to all be online at the same 
time to take your turns 3) firewalls wouldn't be an issue and 4) everything 
else i cant think of off the top of my head:)

Realistically a pbem version of the game would possibly be a little different 
than the current version of freeciv. As i understood it freeciv was a true turn 
based game, in which case it should lend itself very easily to becoming a pbem 
game. Maybe somebody could point me to a place where i could gain a better 
understanding of the internal workings of the game and how client actions are 
processed? I feel freeciv as a pbem game would be a great feature and would 
love to see it integrated into freeciv as opposed to becoming a code fork.
[/quote]

From a conversation with Raimar Falke:

[quote]

>> The solution which comes at first to mind is to use a proxy. The
>> unchanged client connects to proxy server (each player has one) and
>> the proxy server collects the commands and than sends these to the
>> "real" server. The "real" server than executes the commands in some
>> (to be defined) fair way.
>  
>


Right... Part of the reason for wanting a pbem version is to avoid having a 
server running all the time. An alternative to this would be to put a proxy in 
front of each client which simply caches the actions and gives the client back 
results to keep it happy. The file containing the actions could then be sent 
on, gathered and processed by another program. When it comes right on down to 
it though this means sorting out the order in which things happen. If you're 
going to do that, you may as well do it in freeciv proper, no? And avoid this 
kind of cheap hack altogether...
[/quote]

In further discussion with Raimar Falke, he pointed out the flaw in my thinking 
and in a response i summed up the worst problem as i saw it as follows:

[quote]
I think i finally understand the real problem. The game isn't designed to be a 
rigid turn-based game. It's *supposed* to have real-time effects. This 
obviously simply isn't possible in a pbem version and it's an issue that cant 
be brushed over lightly. I could hack a little proxy the way i described it 
before, but it would only ever be a cheap hack and since its ignoring part of 
the game could cause some serious problems.

I think until freeciv becomes a true turn based game, with no real time 
elements (which is something i dont see happening) there wont be a pbem version
[/quote]

So therein lies the problem as i see it. If you want to keep the pbem idea as 
part of freeciv proper somebody is going to have to think of a smart way of 
resolving the conflict between the demands of a pbem game (rigidly turn based) 
and the current reality of freeciv with its real time interraction during a 
turn.

As Marco Colombo said:

[quote]


The point isn't technical. The point is that the game is based on
the fact you see the *effects* of your actions (and of the ones of
your opponents) in the *same* turn. Game internals do take into
account this fact, and this implies that the order of the actions
*in the same turn* is important, too. So you can't just collect
all players actions (without any inter-action) and "play" them
at the end of the turn.

[/quote]





[Prev in Thread] Current Thread [Next in Thread]
  • [Freeciv-Dev] play by email version (PR#663), John Allman <=