Predictable "Random" Generator

Hey there

I'm looking for a way (basically an algorithm) which is 100% predictable, yet shall free as random as possible.

Unless you guys have a better way to achieve what i'm looking forward to:

It's an

online multiplayer environment.

Which means it's important that the HOST handles the actual calculation of where and what the players are shooting.

This means that hit detection all happens on the host side.

I don't want to sync every single shot with the player, because the delay is way too big, which means it won't feel responsive for the players when shooting. (the other bad part about this is that i have to sync a lot more data)

I have already a system which sets a specific accuracy depending on your current wielded weapon.

And as of now, this system works pretty good for a non-online environment by randomly changing the accuracy.

But what the players are getting displayed is not what's actually happening, so while they might think they've hit an enemy, they might have missed it.

Here an example with a shotgun with a lot of random projectiles

(This is a custom projectile system i've created on my own since the bullet behaviour doesn't work for realistic-fast projectiles and fail on the collision part)

What the Player sees:

What the Host calculates:

I want to keep this accuracy system, or at least something similiar. Otherwise it's not going to be fun if every shot hits the exact spot you're aiming for. But i also want to display the bullet direction accordingly to what's actually happening on the host.

The system calculates random directions and random distance for each projectile.

My idea now is to have a specific algorithm which will always get the same results, on host and clients without the need to sync the actual bullets all the time. (Basically predictable "randomness")

Which then runs on each players system and the host. The one on the players side of course will only display the projectiles while the host does the actual hit detection. But the idea is that both, the host and all peers run the same algorithm so they show the same projectile directions while still varying with each shot.

This might not be 100% reliable since some bits may get lost on the host side (not triggering a shot), so maybe i could sync the current algorithm state every ~30 seconds for each player to correct that.

How would you handle this? Maybe an entirely different approach?

And if you think the idea might be somewhat solid, are there any specific algorithms i could use?

Thanks for reading

On SHOTGUN_PELLETS created | Set SHOTGUN_PELLETS.Bullet.Angle to PLAYER_GUN.Angle + random(-5,+5)

Modify the random range to your liking.

If you read the entire topic then you would notice that i have a similiar system already.

My projectile system is entirely custom and generates a line which stretches over time for proper collision detection with fast-speed projectiles.

The projectiles are already generated entirely random, however only on the host part.

The question is now how to handle it within an ONLINE multiplayer environment, to get the same results on HOST and PEER without syncing the data from the HOST to the PEERS since syncing the projectile data would mean that it won't feel responsive for the PEER.

If i sync the data, that means that you will send your shooting input to the server, the server calculates the projectiles and then sends the information back to the PEERS.

This takes quite a while especially with higher latency and means that once a PEER (player) presses the shoot button, it will take some time to actually display the shot. To prevent that my goal is to directly display the shot (only display, not doing anything further since the host will detect actual hits later on), but it shall display the actual correct angle and distance the same as the host will calculate it.

You could pre-generate 'random' values (angles) on the host and he sends them to the clients. The client always pulls a 'random' value from this array, and as values get low, send the next batch on 'random' values.

Use one of the noise plugins.

plugin-noisejs_t93998?&hilit=noise

http://c2rexplugins.weebly.com/rex_noisejsmod.html

Exchange seed.

[quote:3rsaengk]To prevent that my goal is to directly display the shot (only display, not doing anything further since the host will detect actual hits later on), but it shall display the actual correct angle and distance the same as the host will calculate it.

The peer still has to tell the host they have shot, correct? So, why not get them to calculate the angle and send that to the host at the same time? There's no need for the host to do all the calculation.

That way the peer doesn't have to wait for a reply, they can show the shot straight away, and then they only have to wait for the result.

The host can still broadcast for the other peers to fake the shot, but the delay for them isn't important since they aren't the ones who shot.

OddConfection

Calculating such important things on the host is pretty much the basics about online games.

You don't want the peer (player) to tell the host how he shoots.

If you do that, you can easily cheat by let's say triggering 10k bullets in 1 second into any direction and the host will be like *ok let me kill everyone*

That's not how you want to build any multiplayer game unless you don't care about cheating.

All the peer does is sending key strokes, and that's it, anything else is being handled by the host.

So if you press the "shoot" trigger 10k times in 1 second, the host will still only trigger 1 shot if handled properly.

In this particular case i could maybe let the peer handle at least the angle, although i guess that could be abused as well but it wouldn't be too bad.

But handling the distance for instance as well would mean that players can get full control about how far their flamethrower reaches and so on.

99Instances2Go

First time hearing about this.

So that means it's calculated randomly using the fix seed values and i shall sync the seed values between the peers?

Sounds like in the end i would still have to sync all data so it wouldn't be responsive unless i use the idea mentioned by blackhornet

blackhornet

Very interesting idea, i may give it a try.

Although i guess it could get a little bit complicated since i will have to sync data to each single player objects on his own.

That means there will be a lot of data which needs to be synced.

I may take a closer look at this.

Thanks everyone for your first feedback!

Seeded random.

Count the shots.

Seeding is the simpler mechanism (compared to my suggestion). Seeding the algorithm with the same seed, will produce the same results, so the host only needs to send the seed once to the clients. From then on, all random numbers will be in the same order. This is usually a bad thing, so you seed with another random number (like the time/date), but in your case you want to take advantage of this.

Everade

Yeah, I'm not saying give the peer full control, just let them do relatively trivial things like append an angle when they send the keystroke/command to shoot, to improve responsiveness for the peer.

You can add in a check on the host side to make sure it's a valid angle, and if it's not then the Host can either ignore the shot completely or generate a new valid angle.

Is your Host a non-player? Because if they are a player and you're worried about a peer cheating by sending an angle, what do you think the host player could get away with?

Sometimes, it pays off to not be too strict about authoritative host when certain requirements need to be met. Bullet spread is definitely a classic problem for real time multiplayer shooters. There are many approaches, for different situations.

1. Fudge the local visual. Example - Counter strike - the bullet holes a player sees doesn't necessarily mean that's where the server decided the bullet actually went, even if they have the same constraints. It is an illusion, but doesn't necessarily affect game play significantly. For a third person view like yours, this works especially well if you have an "accuracy" type system as well, where a bullet passing through a sprite has a percent chance to do damage or "hit". Running with Rifles is a good example. If it is known the enemy has a chance to not get hurt even if it looks like they get hit, they will be more accepting of fudging done due to mismatching host/client visuals.

2. Use a seeded random. A possibility, but not recommended with something as numerous as bullets across multiple peers.... Keeping the order synced sounds like a nightmare to me, but I haven't tried it so I might be wrong.

3. Best for slower projectiles - Have the local input prediction fire off a bullet sprite with 0 angle, and after it receives the actual angle from the host, start correcting the course of the local bullet. The slower the projectile, the less distance it will travel before getting the actual angle, making it not really noticable. There would only be a slight discrepancy near the origin, where the angle has the least impact anyway.

I think for your particular situation you have two best options - just fudge the player's visual feedback and accept that it might not be "real", or allow the peer to be authoritative on the angle of the shot.

An additional nice touch is to have seperate feedback for a host determined "hit", like blood or flashing some other indicator. Then even if it looks like a bullet passes through the enemy, if they don't flash maybe it can look like the bullet went by them (above?). Also if it looks like the bullet missed, but host determines a hit, at least the player will get some feedback that there were hits.

Lastly, the less possible bullet spread the easier it is to fudge acceptably in general, which may be a consideration.

oosyrag

1. I'm fine with it if it's an illusion. But it shouldn't bee too far off.

Since my game isn't going to be competitive (player vs players) it's not so important to be 100% accurate.

But i still want to have some proper visual feedback so in case of weapons which have a really bad accuracy don't shoot into the complete opposite direction, showing a hit but they actualy did not.

Especially if there are smaller fast moving enemies and you try to hit them.

I personally think (as a player) if that happens too much, they blame it on *bad hitbox detection* or network issues or whatever.

The more accurate it is and the more responsive it feels the better for the game and the joy for the players.

And i also don't want to play a game where my visual feedback is always way off.

2. Yea really sounds like a nightmare xD

I'm not sure if this is the best approach. And to prevent too much issues i can imagine that i'm almost forced to send 1 seed per peer, because if they are all shared the possibility that the sequence gets mixed up (delay of shot being triggered due latency)

So that means 1 seed per peer, and to prevent missmatches over a longer time-frame i guess i would have to re-sync the seeds every 30 seconds ~ 2 minutes.

Maybe that way it works out, i will for sure take a closer look at this.

3. I'm actually using realistic real world projectile speeds ~400m/s which is around 266px per tick if running on 60fps with my setting.

Which means that's absolutely impossible for my case

Another reason why the official bullet behaviour would never work for me.

Visualy the players will only see a flash-line similiar to the one showed in the picture i've posted.

OddConfection

I see 1 big problem with that.

Let's say the Peer shoots, and sends the angle to the Host.

The host recieves the angle but assumes that the player was standing at a different position (due movement of the player while shooting)

I don't know if that's going to be accurate enough or if that's going to mean that the shots could be registered at entirely wrong positions.

From host to peer there's the prediction stuff and all that, but what happens if i send this data the other way around?

Is there a way to *sync* the angle together with the actual mouse click sync so the host recieves both data at the same time?

Does anyone have experience with this?

And to your question:

The host is a player.

And i know what that means.

But Construct isn't really made for anything else... is it?

So that means 1 seed per peer, and to prevent missmatches over a longer time-frame i guess i would have to re-sync the seeds every 30 seconds ~ 2 minutes.

Nope. Use same algorithm to produce noise on both sides. Exchange seed only once.

Say, we use 3D Perlin noise.

Then the noise plugin returns a random value for Noise.Perlin(x,y,z) that is always the same for the same x,y&z, but different for different seeds.

Now you can produce noise by something simple as

(random spread angle) = (random spread angle) + (Noise.Perlin(enemy.x,enemy.y,uncorrected spread angle))

Uncorrected spread angle is, i suppose, an iteration from a base angle (base angle + 3, base angle + 6, base angle + 9, base angle + 12)

Ofcourse, the deviation of the noise must meet you needs. The random (with the same seed) will be exactly (as exact as floating can be) the same on both sides.

You might better of to choose a bigger deviation, and round(them) or floor(them).

...

The host recieves the angle but assumes that the player was standing at a different position (due movement of the player while shooting)

...

Is there a way to *sync* the angle together with the actual mouse click sync so the host recieves both data at the same time?

Don't Sync clicks/input, use the On Click event to do a Send Message to the Host, with an encoded string or JSON data containing both clickType and Angle, so both arrive at the same time. You can include player position as well in that for verification/adjustment.

I'd say one seed per session.

Forget collisions as well. The random number is your percent to hit. Displaying bullets is just aesthetics.