[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Where do I begin?
On Wednesday 09 January 2002 10:49 pm, you wrote:
> Henningsen wrote:
> > The one point where I disagree with Steve is that I think if you want to
> > really write good real-time network code, you have to plan that in from
> > the start with a view to minimizing the size of the data you have to
> > exchange over the network in order to keep clients synchronized.
> I think the problem is not so much minimising the amount of data - but in
> resolving the *nasty* problems of simultaneity.
> Two players are walking down a corridor - there is a gun lying in the
> middle. Both reach to pick it up. Who gets it?
> Well, if you have the local game engine decide then you can run into a
> situation where both players have the gun.
The way I solved it on a 2 player game (UEFA Championship League) was to add
specify which frame an event would be happening on (generally about a quarter
second delay), and send the inputs to each player.
This way, each player would know which frame to process a particular input
on. Suprisingly, it works great, even when the delay was up to a second.
> If you have a central server decide then there may be a lot of latency
> between it and the players such that whenever you pick up *anything*, there
> is a long delay before you have it. Picking things up isn't perhaps so
> bad - but shooting certainly is.
That's a situation where full-mediation is useful. All the processing is done
on the server, and what the server says goes. Clients send the changes in
player state (speed, direction, firing etc etc) and it's up to the server to
decide what happens.
The server sends back client changes when they happen, and occasioanlly a
packet containing all the details about a player, just incase things get a
lil' too out of sync.
> Solving these problems is what makes networked games so difficult - and you
> certainly *do* have to plan a comprehensive solution up-front if you want
> it to work flawlessly.
> However, to expect someone who is writing their first game to attack this
> *incredibly* nasty problem as the very first up-front thing they do is
My first C program was a network mail system. I'd expect no less from a
newbie today (granted, I had been playing with BASIC on my CPC 464 for years,
and moved "up" to QBasic when I got my first PC when I was, uh, 8, I think) :)
> Do something quick-and-dirty the first time around - don't sweat the hard
> problems - then you'll know what those problems are for your second game
> and you'll have the knowledge of what you did wrong the first time to help
> you design it right.
Yeah, that one I do agree with. Being one of the GDNet "guru" type ppl, I get
fed up with da clueless newbies (gawd, I hate clueless newbies) telling me
thay need programmers to write a game that is going to be better than Quake
12. Oh yeah, and they don't know how to code....
> > Remember this: One reason Carmack is so good is because he isn't
> > shy do ditch code and start again from scratch.
Man, I missed that one.
All I will do is snicker knowingly, and suggest someone at id invests in a
> ...and that's my advice too. Write *something*. *EXPECT* to get some
> things wrong...then in six months time, put your first game out to
> pasture and write something *REALLY* good for the second effort.
I hate to say this, but my first ever game, Spong, a pong clone with a
difference, was quite good. It even had lil' bonus boxes that dropped from
the sky and shit. I managed to make money from it, too!
Mark 'Nurgle' Collins
Lead Author - Linux Game Programming (Premiere Press)
Author - Advanced AI Game Development (WordWare)
Email: firstname.lastname@example.org Phone: +44 7761 774 152
Email: email@example.com Spam: firstname.lastname@example.org