Barrels

by redwall_hp on 09/22/2008 05:11, 12 messages, last message: 09/23/2008 16:50, 2187 views, last view: 05/04/2024 17:04

Why do barrels only work in SP modes and not multiplayer? Is there a reason for this? Will they ever be added into multiplayer mode? I think it would add a fun twist to multiplayer gameplay if they were.

Imagine a map littered with barrels and boxes. You're up on the roof of a building in a far corner of the map. When a player walks by a group of barrels, you shoot it with a crossbow, fragging the other player indirectly. Wouldn't that be cool.

   Board Index   

#1: ..

by tentus_ on 09/22/2008 06:12

The reason is exponential object states. Add in dynamic objects like barrels and you can easily double the amount of data that has to be sent to and from the server, or quadruple that data, etc.

Imagine a map littered with barrels and boxes. When a player walks by a group of barrels, you shoot it with a crossbow, fragging the other player indirectly. The netcode for this has to handle the states of all those barrels in addition to the players and the shot itself, so for a few seconds there's going to be some serious slowdown as half a dozen or more barrels change state and every player in the map has to learn about it. Even if you're trusting your clients a LOT as far as barrel placement and explosion radius, we're still talking about enough information to make someone on dialup lag out.

In a nutshell, the answer is "it would kill the low-bandwidth multiplayer appeal".

reply to this message

#2: Re: ..

by demosthenes on 09/22/2008 09:08, refers to #1

Yes, there was extensive discussion a while back in which the possibilities for handling multiplayer dynamic objects was thoroughly thrashed out. It never got implemented for various reasons, but you can dig up the discussion and take a look if you like.

reply to this message

#3: Re: ..

by demosthenes on 09/22/2008 09:11, refers to #2

The above-mentioned topic is this one: http://cubeengine.com/forum.php4?action=display_thread&thread_id=1538&start=0

reply to this message

#4: Re: ..

by SanHolo on 09/22/2008 20:22, refers to #4

*throws banana*

reply to this message

#5: ..

by redwall_hp on 09/23/2008 00:26

Okay. Thanks for the info and quick response.

Sounds like a good reason to me. My ping is bad enough when there are 16 players on a server. Dynamic objects would probably kill the game entirely.

reply to this message

#6: Re: ..

by SheeEttin on 09/23/2008 03:08, refers to #5

Glad someone actually listens once in a while. :P

Would it really be that bad, though? I mean, I'm not sure you'd even have to send all the data about each and every barrel continuously. If you just tell the client "this barrel exists, is here, and has this much health" then I think the when the client is told a shot was fired, it can figure out that it hit a barrel and it should explode.
As tentus mentioned, though, that'd assume the client is honest...

reply to this message

#7: Re: ..

by Quin on 09/23/2008 03:36, refers to #6

Not at all, Blood Frontier's AI is the first step toward a dynamic state manager distributed across clients, plus we also do rudimentary dropped items. I could have done all this by now, I just couldn't be bothered with it - it's depressing working on things alone.

reply to this message

#8: Re: ..

by tentus_ on 09/23/2008 05:01, refers to #7

I hear that. I'm trying to drum up some interest at the college I attend, but it's an uphill battle. Maybe though.

One of the issues I've been wondering about with the barrels would be the lag time issue. We know that a series of explosions causes some serious lag locally- a weak computer will slow down for a bit, figuring out what barrels need to go boom and which don't. My gaming machine is pretty powerful, so the lag is imperceptible to me: so, in an online game, how do we make sure that my explosions aren't a full second ahead of my buddy with a crap machine halfway across the world? To me, I might start a barrel chain and then sweep in after it to clean up the survivors, but to my buddy it looks like I'm an invincible killing machine striding though the flames (whoops, didn't mean to get all poetical there).

My point is, trying to sync up explosions might not be as simple as "Player X shot in the direction of barrel Y". Being both very flashy and also highly relevant to gameplay, people are going to notice if things don't mesh correctly. And like SheeEtin acknowledged, this is all assuming that the client has not been modified and we can trust them (which our current serverside handling of ammo indicates that we cannot).

reply to this message

#9: ..

by redwall_hp on 09/23/2008 05:16

@SheeEttin, that's what I had been thinking originally.

@tentus_, makes sense. But how are the barrel physics calculated? What if it worked something like this: If you shoot a barrel and start a chain reaction, Sauer figures "okay, so these barrels will blow up with a total blast radius of X" before they explode, and Player A is in the affected area, so Player A will be killed when the blast is set off.

reply to this message

#10: Re: ..

by tentus_ on 09/23/2008 06:52, refers to #9

@redwall_hp: not a bad idea, but what if the barrels aren't in a single cluster? If we have, say, two clusters within reach of each other, or perhaps a line of barrels, then a simple radius wouldn't suffice. You *could* throw a few hastily-calculated bounding points up, but that solution brings us back to the bandwidth issue: a complex explosion could result in a huge lag for all of the clients, and we also have to think about the extra processing the server would have to handle.

This might be one of the situations where the P2P solution could really shine: supposing you distribute the load of the barrel changes to each available client, the systems could asynchronously update, hopefully circumventing that one disastrous second of change that we're dealing with. It might mean that your barrels are exploding slightly out of order, but it could be closer than anything else I've thought of.

Keep the discussion going, I like the topic.

reply to this message

#11: Re: ..

by demosthenes on 09/23/2008 08:42, refers to #10

This has all already been discussed, extensively. A quick re-read of posts 37 and on would cover basically all that's been said about the issue before this topic.

And the relativistic re-syncing updates with the server in charge of who's in charge of what and the players updating newly joined players is probably the best system so far.

reply to this message

#12: ..

by Maxime "Max of S2D" Lebled on 09/23/2008 16:50

DO A BARREL ROLL

reply to this message

   Board Index