oolite-multiplayer

[DaddyHoggy]

@cnikiel - your English is very good - I did not realise it was not your first language. However, I remain confused and it could be simply that we're talking about two different things - but, given that I work with networked, military, simulations all the time, I still fail to see how you will accurately position and orientate all the other player controlled ships relative to a particular pilot so that he can shoot at them without having to worry about lead/lag and those ships actually being where he/she thinks they are.

Sorry for being a bit dumb on this one.

[Micha]

You'll always have to approximate (using various technologies) unless you have a zero-lag sufficient-bandwidth network (of which the former is impossible).

A game will never have the level of resources of a military simulation (cool job, DaddyHoggy!!!!) so the approximation will always be a lot worse.

However, you can still achieve reasonable levels of approximation which, while not 100% accurate, will be accurate enough to result in a playable and fun and reasonably fair game.

Donnybrook (http://ccr.sigcomm.org/online/files/p389-bharambe.pdf) is an approach which limits data traffic via various approaches including a form of smart dead-reckoning. It'd be an interesting project to try out..

Furthermore a vehicle simulator such as Oolite is by nature a lot easier to predict than a FPS as the spaceships move and react much slower than an FPS avatar so you should be able to get away with a bit more lag.

[cnikiel]

Yep, dead reckoning would be the way to predict the position.
Every state that the server sends will cause a new evaluation of the state the client sees.
In the best cases this would just verify the predicted calculated positions.
In the worst you will see a jump in position.

I used the networking ideas of parsec http://www.cg.tuwien.ac.at/~msh/netdocs/index.html for some ideas.

It should be possible.
With the decentralized server architecture it should be possible to have a lot of players in the same universe. Not actually on the same planet, but still enough interconnection should be possible.

@DaddyHoggy thanks Used to be in networking support for some years. English was used every day. Still I feel there is a lot to learn.

[Micha]

In the best cases this would just verify the predicted calculated positions.
In the worst you will see a jump in position.

That is the laziest implementation In the case that the actual position differs from the predicted position you would use a smoothing algorithm to converge between the two positions - warping/jumping is just -so- amateurish!

[Captain Hesperus]

What some games have is a non-PvP area where noobies can learn/play the game without being used as target practice. I'd imagine a corridor between the witchpoint and the station that is nPvP, which could fluctuate depending on the system's government (Corporates have vast nPvPs, while Anarchies may have a tiny one). You could incorporate a 'warning system' into the standard ship fitout that alerts pilots to when they are leaving the security corridor. However, although they are safe from other players, pirates can still get within this area.

Captain Hesperus

[BlackKnight]

How about a 30-50km Aegis around the witchpoint, which has to be left within a small-ish period of time after entry, and that ships are not allowed to remain in for more than a certain period of time.

Enforced by either a guard of Vipers or similar, or replacing the witchspace buoy by a large turret with an attitude?

So I space in and boogie on over to the sun to refuel, then go back to the edge of the "safety zone" between the beacon and the planet. Then, when some poor spacer arrives and tres to do a runner using his fuel injectors, I can outrun him since I've got full tanks and he's just jumped in.
Either that, or it becomes a guessing game as to how many missiles and how many external fuel tanks to carry...

[BlackKnight]

Furthermore a vehicle simulator such as Oolite is by nature a lot easier to predict than a FPS as the spaceships move and react much slower than an FPS avatar so you should be able to get away with a bit more lag.

Until you get some aggravating Commander who uses throttle changes to try to throw off an oponent's targetting; it's amazing how much difference in position you can get by rolling/climbing and accelerating/decelerating throughout a fight. A quick applcation of fuel injectors can throw someone's tracking solution out the window faster than saying "Where'd he go this time?"...

[ClymAngus]

Ah, the bounder who will never stand still when I'm trying to shoot them. Yes well, humans will do that. Annoyingly enough.

Furthermore a vehicle simulator such as Oolite is by nature a lot easier to predict than a FPS as the spaceships move and react much slower than an FPS avatar so you should be able to get away with a bit more lag.

Until you get some aggravating Commander who uses throttle changes to try to throw off an oponent's targetting; it's amazing how much difference in position you can get by rolling/climbing and accelerating/decelerating throughout a fight. A quick applcation of fuel injectors can throw someone's tracking solution out the window faster than saying "Where'd he go this time?"...

[DaddyHoggy]

@Micha - the was DIS works re dead reckoning is every entity runs two models of position - a simple dead reckoning one and another which is where they actually are, when the two are out by more than 1m/3deg the entity broadcasts its actual position and resets its own dead reckoning position - all the other games entities do the same (i.e. they update their copy of the same dead reckoning positioner which is running a copy for every entity in the game) - this way slow moving entities don't update very often - fast ones do (because they need to) which helps keep bandwidth down - smoothing algorithms are usually used then to move everybody in your current FOV to avoid warping/teleporting incidents.

Yes, my job is very cool! I work here: http://www.cranfield.ac.uk/dcmt/oams/index.jsp although the photos need updating - we've just refitted - much newer PCs and LCD screens and Plasma TVs...

And I've just noticed the Publications list is 7 years out of date - oops! Must fix that.

[Micha]

@DaddyHoggy - Yeah, I've read some of the DIS papers. I happen to work somewhat relatedly for Sony Computer Entertainment as a network programmer (although not directly on the games teams) - also pretty cool

The basic premise of the Donnybrook paper is to try to reduce traffic by trying to predict what the human is concentrating on - which is usually a very small subset of all entities in the vicinity - and prioritise those for high-fidelity updates while the rest are updated at a much lower rate. Their proof-of-concept work apparently showed good results. It was proposed for peer-to-peer work, but in the case where servers are hosted on typical consumer connections rather than hosting centers this approach is applicable for client-server as well.

The primary difficulty with a game such as Oolite is the instant-effect weapons (in this case lasers). However in a game situation (as opposed to a serious simulation) a certain amount of fudging is quite acceptable as long as it's fair on every participant. The main focus is to make it look good on every client machine.
For example even if it looks to you that you hit your opponent you don't know how much damage you actually caused or how damaged the opponent was - the damage would get allocated and tracked by the server. So what looks like a hit to you could still be a near-miss. Or a near-miss could actually be a hit. Since there's no instant-kill shots this slight fudging works well and in the long run evens out.

@BlackKnight: And I maintain that despite aggressive manouvering a vehicle sim is always easier to handle than a FPS where avatars can jump around randomly and can change direction -very- quickly.

Anyway, I should stop rambling

[DaddyHoggy]

@Micha - cool job to you too! I've now had a proper look at the Donnybrook report - very interesting! I may have to follow it up through work. So thank-you very much for the heads up.

This is the coolest forum in the (u/oo)niverse.