[Freeciv] Re: Freeciv
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Tomasz Wegrzanowski wrote:
> On Sun, Jun 18, 2000 at 10:50:08PM -0400, ???í?? wrote:
> > Also, I can "set maxplayer 1; set aifill 7" and play the game
> > without /start in earlier versions, but not anymore.
>
> Someone thought this was a bug
> (his rationale : you should have possibility to set server variables before
> start)
I have been working on a game in the same genre, and here's how I have it
working.
(This scheme was inspired by discussions on this list last year.)
o To start the game, you type "freeciv" (or whatever).
o A "game manager" pops up a window. The window has radio buttons for options
such
as "play a solo game", "join a remote game", "serve a remote game", "serve a
game and
join in", "run the map editor", etc.
o After you pick your option and click the start button, the "game manager"
launches
one or more processes, depending on what you checked. For "join a remote game"
it
just launches the client. For "serve a remote game", it just launches the
server.
The interesting one for this discussion is "play a solo game". This option
launches
the server with a --solo switch, lets you set the desired server settings with
a GUI,
and then when you tell it to start, it starts the server process *and* launches
a
client, telling the client which server to connect to.
The user is not aware that the various pop-ups belong to different processes;
s/he
just types the name of the game to start it.
This would take a fair amount of hacking to make Freeciv work the same way,
since the
server is a pop-up window rather than a terminal (but also has to be able to run
without a GUI, so you can do things automatically like the civserver does).
However,
it might be worthwhile, considering how frequently we hear complaints about the
way
you have to start it. I think it would take an amount of work similar to what
the
original creation of the GTK client took, or perhaps a bit less.
As a side note, I'll mention that the "game manager" removes its display but
stays
running during the game. It doesn't actually do anything during the game,
except to
wait on one of the processes it spawned to exit (usually the server process).
When
that process exits, the "game manager" pops its little options window back up,
and
you're ready to start another game. Since it's a fairly small program, I just
leave
it running all the time, though it does have an exit button. (It's nice for
development too -- the "game manager" rarely changes, and it's always there
waiting
for me to test run the changes to the actual game. Since it launches the game
as a
separate process, I always see the most recent version of the game at the click
of a
couple of buttons.)
Bobby Bryant
Austin, Texas
|
|