[Freeciv-Dev] Re: connect dialog ver 3 (PR#1911)

[Daniel L Speyer <dspeyer@xxxxxxxxxxx>]

On Sun, 20 Oct 2002, Vasco Alexandre Da Silva Costa wrote:

> On Fri, 18 Oct 2002, Daniel L Speyer wrote:
> 
> > On Fri, 18 Oct 2002, Mike Kaufman wrote:
> > > > [snip]
> > > > o I feel this is for _single_player_games_. Inviting your friends to 
> > > > play
> > > >   really merits starting up a different server process don't you agree? 
> > > > This
> > > >   is mainly the reason why I didn't include Daniels patch to show 
> > > > incoming
> > > >   connections. It was a neat little patch, but out of sync with this 
> > > > project.
> > > > [snip]
> >
> > I would seriously disagree here.  It strikes me as unreasonable that an
> > end-user-targeted game should require command-line usage at all.  I hope
> > that RH8.1 will omit civserver from its menu, and people will get used to
> > simply runnig Freeciv, purely graphically.  Now, short of reading
> > documentation or source, how are users who learn of freeciv this way going
> > to know how to start a seperate server?
> 
> This is a Windows centric type of thinking. The mixing up of the client
> and server concepts for the sake of "usability". Well I don't feel such
> bastardisation is really necessary. Even for that.
> I guess it is because I am used to playing multiplayer networked UNIX
> based games.
> 
> IMHO when the original Freeciv designers made this game they used the UNIX
> concept. I also feel that is the correct way to do things in the long run.
> Playing a game with humans is a different thing altogether of playing a
> single-player game against the AI.
> This is the concept that needs to be reeinforced.
> 

How is it so different?

Consider that a player may compete against humans and AIs in the same
game.  Consider that a single nation may switch between human and AI
within a game.  Consider that a long-term development goal is to seperate
AI from server, so that the network structure will be the same.  Consider
that, even now, there are attempts to create freeciv-bots that
network-connect like humans, and that one day they may pass the Turing
test (not on the chatline, just in terms of play style).

Also remember that the dialog to start a single player game is (under any
sane design) a large subset of the multiplayer one.  In therms of this
patch, they aren't very different.

More generally, one of the cool things about the freeciv archetechture
(and about many *nix designs) is how gracefully it expands to
networks.  Sort of like X.  Under the old scheme, starting a multi-player
game is no harder than a single-player, and little different.  We are now
working to make single-player easier -- why should we leave multi-player
behind?

Now, you seam to feal that concealing the server is a violation of good
design principles.  Remember that we are only making it transparent to the
end-user, not technologically mingling server and client.  It is very
common for programs to actually be composed of distinct parts, connected
by pure IPC.  Consider gcc.  It is not uncommen for programs to launch
daemons whose services they will require -- consider every KDE program.

There's no real reason the end-user *should* have to worry about the
server.  Certainly they are welcome to, and it is still possible to invoke
the server manually.  And there's definately no reason the end-user should
need to touch a command line.  In recent distribution reviews, the
benchmark of user-friendliness was
mean-time-between-needing-the-commandline.  It would be highly embarrising
for a fundamentally graphical game to drag those figures down.

> > Now, admittedly, hosting a game could be made seperate from starting
> > single-player, but what would that gain us?  Every single-player option
> > applies in multiplayer, so (considering the GUI design) seperate options
> > would just make clutter at the startup screen and blank space in the
> > start-single-game screen.
> 
> > And yes, based on actual observations, many people who are uncomfortable
> > on a command line will want to play multi-player, and no,
> > civserver.freeciv.org is not a solution, because they will want to save.
> 
> If that is a problem why don't we allow players on civserver.freeciv.org
> to save?
> 

That's not the only problem with civserver.  First of all, centralizing
like that is a *bad idea*.  Civserver is pretty stable, but it's record is
far from perfect.  And what about people with good internal networks, but
whose outward internet connection is phone-modem, or unreliable, or
absent?

Also, civserver has weaknesses besides saving.  It cannot play
home-written rulesets.  It keeps current, and one day will surely forbid
1.15 clients to connect because all server processes are 1.16.  It is a
fundamentally public space, not nessesarily what is wanted.  Finally (I
suspect) it does not have the resources to run all the games that would go
through it if it were massively easier than running your own server.

> Sure it will involve extra coding but so does what you people are proposing.
> 

It would require a *lot* of coding (game-saving is straightforward (though
a large problem), but game *loading* requires a fundamental change in
archetechture -- and authentication is worse).

Adding multi-player support to the connect patch requires *no* coding,
only the resyncing of the existing list-opponents patch, stylifying it,
and perhaps a little debugging.

--Daniel Speyer
If you *don't* consider sharing information to be morally equivalent to
kidnapping and murder on the high seas, you probably shouldn't use the
phrase "software piracy."

> You may think we don't have the space to save the games, but the fact is,
> civserver currently has loads of saved games on it for the purposes of
> scoring and showing summary reports.
> 
> Of course we must impose some sort of limits to people will not abuse the
> system. So some sort of quota system must be in order.
> 
> === I propose the following system:
> 
> Players may register an account on the server. They will be identified by
> playername and password.
> This is not mandatory. Like on IRC, you may use the service if you haven't
> identified, however that way you will not have your score entered into the
> civserver ranking or have load/save permissions.
> 
> As for quotas we could use the time honoured slot system.
> 
> Each player has a certain number of "slots" where he can store games.
> Let's say 3 or 5. An identified player has the following extra server
> commands:
> 
> slotlist
> slotload <number>
> slotsave <number>
> slotremove <number>
> slotname <number> <comment string>
> 
> The server stores the player savegames under a directory specified by the
> FREECIV_PLAYER_DIR variable. e.g.:
> 
> players/
>       vasc/
>               1.sav.gz
>               2.sav.gz
>               ...
> 
> We can ignore security issues related to stolen passwords for now. Most
> webboards and multi-user games ignore them too.
> 
> Comments?
> 
> ---
> Vasco Alexandre da Silva Costa @ Instituto Superior Tecnico, Lisboa
> 
> 
>