Jump to content

  • Log In with Google      Sign In   
  • Create Account

Network code for a strategy game


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 dandelion   Members   -  Reputation: 122

Like
Likes
Like

Posted 18 April 2000 - 05:56 AM

Hy! I spent more than a mounth to code the network part for a RTS game, and still I have no result. I don''t know how to make 2 computers to play the same game (and I should do it for 8). Here are all the things I tried: - use the same clock for all the computers in order to shyncronize them (this is a good ideea) - to send the game state to other computers (this slows down all computers becouse they must wait to receive the state from all other players, wich is BIG) - to send a player''s input to all other computers and when they have the input form all players to update the state of the game (this seems to be a good idea becouse the messages are very short (short enough to play the game over a modem) and if on all computers is the same code, they should get to the same result. BUT, becouse I use random numbers in units AI (even it should work) it does not.) I know that some games use to send the commands from their units to all other computers, with a delay time for execution, but this seems to complicated. Can you tell me where can I find the sources of a RTS game that works in multiplayer mode? Any ideas about codding a RTS network game ?

Sponsor:

#2 Drone   Members   -  Reputation: 122

Like
Likes
Like

Posted 18 April 2000 - 07:26 AM

The method of sending inputs to all computers is called ''lockstep''. I believe all the major RTS games
use it because they have no hope of sending game state
for so many units over a modem. The only way is to
compute the state locally.

In Battlezone 2 we used lockstep to keep our game in sync.
Here is a link to a description of the technique:
http://home.earthlink.net/~uubp/mp.htm

The way to deal with random numbers is to agree on a random
number seed at the beginning of the game and then make sure
that random gets called the same number of times on each machine. the easiest way to do this is to have 2 versions of random. One you keep in sync, the other you use for visual effects which don''t have to keep in sync.

I am working on a simple, solid frame work for lockstep
games which is all public domain. If you want to see
where I''m at download:
http://home.earthlink.net/~uubp/move1_1s.zip
It doesn''t work yet but its pretty close and I''d be happy
to talk about the way it works if you are interested.

Later



- Brad Pickering
http://home.earthlink.net/~uubp/
Home for organically grown games


#3 gimp   Members   -  Reputation: 142

Like
Likes
Like

Posted 18 April 2000 - 05:38 PM

Brad!

Fancy finding you here...

I had just sent off a post asking for more information on techniques other than lockstep (that I has read on your page through a link from planetbattlezone).

I was looking for a simpler way of maintaining state, but, since your giving away code samples... I think I''ll take two...

I have read and reread your description a few times and can quite understand how complex the world prebuilding would be to implement.

When your recieving direct data(xyz rpy) re where people are why do you have to build the world in advance? Why not just make the correction''s on the fly?

Thanks

Chris ''gimp'' Brodie

BTW : I liked BZII so much that I''m currently working on a hovertank game of myself, similar to BZ but more combat orientated with no base building at all, also with a more millitary feel to it. I have a world up, and most movement code looking good(acceleration, deceleration, inertia, gravity etc). Reason I mention it is that being able to ask you question would be a major benefit to me. May I contact you directly?

#4 Drone   Members   -  Reputation: 122

Like
Likes
Like

Posted 18 April 2000 - 06:46 PM

The code to implement multiworld is very complicated so
if you are going to use lockstep as your syncronization
method, try a simpler method of world prediction first
to get your feet wet. If your lockstep simulation is
half a second behind the current real time just project
all your tanks .5 secs into the future using their
current heading and velocity. This is called dead reconning.

You could contact me directly but I suspect your questions
and their answers might be of interest to others. Would
you mind posting your questions to the bboard for the
project i have started:
http://pub7.ezboard.com/borganicgames

If the questions are generic enough for this board, keep
them here.

---
When you''re recieving direct data(xyz rpy) re where people are why do you have to build the world in advance? Why not just make the correction''s on the fly?
---

I''m not sure what you mean here but I''ll take a stab.
In lockstep you don''t recieve object state data (xyz rpy),
you only recieve user inputs like joystick settings. Object
state is calculated locally by all machines in the game.

Im not sure what you mean by corrections. You don''t get
new position info over the net so in that sense there
is nothing to correct. You do have to correct the visual
world because it will never be perfectly predicted given
that it is predicted with incomplete information. In
bz2 we throw the predicted world away and recompute it
every 2 secs or so, but there are probably other ways to
reconcile the visual and lockstep world without completely
rebuilding it. We can talk about this on the other bboard
if you want.

Sorry this lingo sounds like jibberish, it almost makes
sense after you''ve worked on it for a year or so .

I am handing out source code but it doesn''t quite work yet
and it only handles half of the problem. It should handle
the lockstep aspect (it still needs a little work), but
it doesn''t handle the world prediction aspect.

Your project sounds cool. Keep me posted.

Later

- Brad Pickering
http://home.earthlink.net/~uubp/
Home for organically grown games


#5 gimp   Members   -  Reputation: 142

Like
Likes
Like

Posted 19 April 2000 - 02:45 AM

Responded to on the board referenced in last email...




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS