🚀 go-pugleaf

In article <1992Aug13.101432.16647@jyu.fi> ap@jyu.fi (Patric Aalto) writes:
>
>I am coding a game, called 'LineWars II',

Still working on that one, huh? How many years has it been? ;-)

>1) What should happen when the player's ship gets destroyed? I want the game
>   end only after all the enemy ships or all friendly ships are destroyed.

Well, you can let the game play itself out (pretty boring, since all the
human gets to do is watch). Or you can reincarnate the human player. Why
don't you want the game to end when all human players have been
destroyed?

>3) Should the player's ship be stronger/faster/whatever, or equal to the
>   other ships? Currently it is equal.

I think they should start out equal, but as game play progresses they
might be able to enhance their ships' capabilities. For example, if you
land on Planet Xargathia, the engineers there can install a faster drive
system for your ship. Something like that.

>4) As I am planning to add LAN support, how should I handle players that
>   pop in in the middle of on-going battle?

That's a tough one to support. The simple solution is to make all
players start at about the same time. The first person to start the game
on the network becomes the "master" machine. The master waits until all
the other machines have linked up, and then the human presses a key to
start the game. Players who pop up after this point are made to wait
until the current game ends before they can join.

There are two basic ways to implement multimachine games: the
peer-to-peer model (which LineWars uses) and the Client/Server model.
Using a ptp model, all machines have complete "game state" information
available locally. Whenever a player makes a move, the move is broadcast
to all other machines in the game, who then update their own local
copies of the game state to keep things current. If a player pops into
the game in the middle, the other machines have to bring the new machine
"up to date" on the state of the game (e.g. player A is in sector 172, a
planet has been destroyed in sector 6, etc.) This could take a LONG
time, and would either slow or stop the game in progress for the other
players.

If you use a Client/Server model, such as that used by MUD games,
players can join the game at any time, but you have to send more
information to each client machine on every turn. The server has to tell
the client everything: what room he's in, what the room looks like (and
how to display it), what other players are in the room, etc. With
text-based MUD games, that's no big deal. With a graphics based game
that wants to run at 60fps, that's a tall order. You would probably want
to implement some sort of caching scheme on the client machines to help
reduce the amount of data that must be transmitted by the server, but
still you're sending MORE with the C/S approach than with the ptp
approach.

In a graphics-intensive game, the price of allowing a player to join at
any point during the game is pretty high. BTW, if you're supporting
multimachine gaming via serial links, how do you intend to support
"adding a player at any time" capability with machines connected via
serial ports?