ZombiesWithGuns.io (https://zombieswithguns.io/)

I think all you need is a hook. Like splattoon or eggshells or whatever you got. Like its nice and smooth, juicy and all. Just needs a hook

Yeah player.position.z += controls.w*input.dt is approximately the form of movement that I use on multiplayer games with prediction. The inputs are queued, and any framerate on the client is allowed. So a player with 30 fps is producing half as many inptus as 60 fps, and much less than 144 fps, etc. If people keep making screens w/ really high framerates maybe I would throttle that a litlte bitā€¦ but at the moment I just leave it.

None of this is required by nengi (can send whatever) but it is my current recommendation for making the client feel as smooth as a single player game (and I would extend that recommendation to people making their own networking lib). Iā€™m also totally open to other ideas.

The downsides of packing the delta alongside the input and sending it to the server are that it introduces two potential problems: A) hackers that increase the delta and/or hackers that repeat the same command multiple times, and B) game clients that freeze will send a large delta, and game clients that experience packetloss will send no commands and then a whole bunch all at once. Those those two things seem very similar: large delta, and strange clumps of commands fraudulent or valid.

Thereā€™s a really easy fix for the hacking: the sum of all the deltas is the length of time that a player has been connected. If we add up 60 fps of deltas (16.6666 ms) for 5 seconds, it adds up to 5 seconds! So at any given point in time we can always tell if the delta of the client input is valid. If they tamper with it, it will be clear that they have sent more than 5 seconds worth of input during 5 seconds of gameplay (or however long).

The actual laggy player is much harder to fix, and I would be totally open to new ideas. What Iā€™ve done in this game and in bruh, is that I maintain two positions for each player. One position comes directly from processing the clientā€™s input, and the second position just smoothly follows the first. The game only renders this second (smooth) position.

I write this whole wall of text b/c i consider this to be the full set of considerations when sending inputs that include delta at whatever rate to a server that then processes them at 20 ticks per second (or any rate, but the point being that it isnā€™t fixed to the clientā€™s rate).

I should also mention that this is for making a game that plays like ZombiesWithGuns or Bruh. For a game without client-side prediction It is much more simpleā€¦ can send input (but not position!) and process it at the server tick rate and no need to think about delta, speed hackers, desyncing etc.

1 Like

I love that bjs is potentially 33tick hitscan precision.

I was considering a chain-authoritative model for world state and a server-authoritative model for real time play

colored teams - colored bases - hordes of (computer guided) zombies.

HOOK: teams survive zombie horde

HOOK: team zombierun - run from point to point avoiding zombies

always ideas, sorry. ideas easy, make it work - hard.

ā€¦

The ā€œwall of textā€ is cool!

Yeah thatā€™s gameplay juice esp. With voice comm.

Considering the difference between 1v1 games and team 5v5+ [or 1vMany], comms are key

The interpolation for this is part of nengi. Setting it up looks like this:

class ExampleEntity {
    constructor() {
        /* stuff */
    }
}
ExampleEntity.protocol = {
    x: { type: nengi.Float32, interp: true },
    y: { type: nengi.Float32, interp: true },
    z: { type: nengi.Float32, interp: true },
    /* etc for rotation */
    // deliberately not interpolated:
    skinType: nengi.UInt8,
    weaponType: nengi.UInt8,
}

The game client will interpolate data from the server from 20 tick to whatever the frame rate is (e.g. 60, 144, etc).

Instead of a something like a tween from/to, I would say it is more like sampling/synthesizing a position from between two frames. The math is still just a lerp in the end but the process is more like this: Source Multiplayer Networking - Valve Developer Community (entity interpolation sub section in specific).

1 Like

Iā€™ve been manually using computeWorldMatrix which is the thing that actually commits the position, rotation, and scale of a mesh to whatever form it needs to be before the changes to these transform stuff can be used in a collision. If used manually one can perform collisions at any tick rate (this game has a few times where there are 144 tick collisions occurring, albeit unnecessary).

1 Like

Oh nice I thought about throttling down collision etc, not increasing the precision on demand.
Correction: I did think about doing a narrow band collision for limb-accurate model placement. Which, as you point out, is actually just a time available operation.

1 Like

I too value client responsiveness with network speed and fidelity.
@timetocode I have to figure this interpolation. Do you place extrapolation at any phase? I think i am accidentally over-extrapolating
Very clean fps btw.

I see. Thatā€™s actually the same way i dealt with input injections in the past. I made sure to cap deltas as well, as you donā€™t want players to send 500ms deltas. If that hit a lag spike like that, they wonā€™t mind the correction anyway.

1 Like

Thereā€™s no extrapolation at the moment. Since this uses 100 ms of interp delay, there can be up to that much time spent with no data received before the movement of networked entities stops. I used to have extrapolation code, but in my experience with 100 ms of interp, it essentially never came into play ā€“ and when it did there was always a pretty big hitch when the game recovered. So now I just let the entities freeze if people go 100 ms w/o any data.

1 Like

Another little feedback: if Iā€™m not wrong we canā€™t set our username thatā€™s it?

Do you get stronger when you eat more brains like tf2 highlander demo? I cant land anything with bad ping, I wonder if thats where extrapolate is ok, predicting other players locally.

You shouldnā€™t predict other players. That is bound to fail in a game like, as you can quickly change direction and orientation. And as he is using lag compensation, all you need to see is the player - in the past.

1 Like

Thereā€™s only one server for the game atm, and it is in California. While the netcode technically can hide like 500 ms of latency (or moreā€¦but i should probably tamp that down), the goal would still be to have 5-6 regions.

The red onhit crosshair indicator is the only part of the game that does not attempt to conceal latency ā€“ so if you fire a shot that hits, the crosshair wonā€™t turn red until the server actually confirms it. I could hide this too, but Iā€™ve left it in so far.

@Vinc3r ppl can set a username if they sign in (also saves stats and puts scores on the leaderboard). I disabled anonymous names b/c the kids were putting too many bad words and I was lazy.

@withADoveInOneHand the brains essentially give shields (a second hitpoint bar) up to 100. The regular hitpoints have passive regen so with enough brains and careful fights one can always regen to full. I was hoping to promote kill streaks.

Regarding demos/templates here is a game example of nengi+babylon: GitHub - timetocode/3d-top-down . Though I havenā€™t really been pushing it for like 3 reasons:

  1. it is a 2D game, with the renderering+collisions done in babylon just as a proof of concept. I donā€™t think many people would make a game like this. At best it could represent an early template of an isometric action rpg or something.
  2. it is an unpredicted, uncompensated game (just synchronization and interpolation). I figured everyone who likes how zwg feels is more interested in a demo with prediction+compensation (which unfortunately is much more complex).
  3. Iā€™ve recently come to the conclusion the nengi api is too low-level and I have a plan for a higher-level api.

The current api is all about high perf synchro and tools for solving the harder problems (interp, prediction, compensation, time dilation, etc) while expressing no opinion about how a game should be made. At first I thought this was ideal: powerful and flexible. What hadnā€™t occurred to me was that this makes it unclear how to proceed in actually making a multiplayer game. The only ppl who seem super happy w/ nengi are those who were already deep into making their own multiplayer engines ā€“ they already have an idea for how the pieces go together.

So Iā€™ve started to build a much more opinionated layer over the current nengi api which streamlines the whole thing (totally an optional api btw, can still use the low level stuff). Itā€™s like hey, process commands from clients over here, and then create/update/delete entities here, etc. It is already SO much easier to use that Iā€™m honestly a little embarrassed that I didnā€™t make it earlier. So Iā€™ve been kinda stalling on tutorials until this is released, sorry!

For those who want to see the current demos, here are some links to repos:

2 Likes

Re: ZWG, a little more visual/auditory/gameplay ā€˜juiceā€™ on brain consumption would be great. Brains do look juicy af though btw.

1 Like

Iā€™ve been playing battlefield hardline for a long time. The structure of the game is very similar to that
good luck

1 Like

Iā€™ve finally made a game template with Babylon collisions (moveWithCollisions), client-side predicted movement, and lag-compensated ray casted shots. Itā€™s literally just cubes and very-hard-to-see raycasts, but with all the netcode fanciness setup for others to build a game on it.

Thereā€™s also a video that runs through how the advanced features work


(advanced refers to anything related to client-side prediction or lag compensation). I do not currently have any Babylon or 3D-specific material regarding the basic nengi api, but there are some some demo games in 2D and a manual: nengi.js - JavaScript Multiplayer Networking Engine that hopefully bridges some of that gap.

With regards to ZWG, Iā€™ve redone the controls and a lot of things to make the game better for io gamers. For the most part Iā€™m going to hang back until September when there is an opportunity for more traffic. Iā€™d also really like to program some bots that know how to navigate the level to give the game some playability when there arenā€™t [m]any players.

5 Likes

Awesome game!

2 Likes