Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: I Built Multiplayer Deathmatch Joust

joust.life

Post reply on HN
Print view View original

81–90 of 107 posts

Re: Show HN: I Built Multiplayer Deathmatch Joust

#81

Post by yoz »

jasonkester wrote: post #2

Most of this code dates back to 1998, when I built a little 2 player Joust game to push the bounds of what you could do with Div (and at the time Layer) tags in the latest browsers such as IE4 and Netscape 3. Surprisingly, most of it still worked when I thawed it out recently, provided your browser knew about document.all. Over the weekend, I brought it up to date a bit and introduced it to Socket.io. Thus far it has…

This is superb, addicting as hell, and now I have to force myself to stop because I have real work to do.

The game gets increasingly jittery as it gets busier. It might be worth writing some tests to simulate lots of players moving around so it's easier to tune the performance.

Re: Show HN: I Built Multiplayer Deathmatch Joust

#82

Post by sib301 »

kgwxd wrote: post #75
airhead969 wrote: post #60

Earlier quoted context omitted.

Operational transformations (OTs).

I don't see "game" mentioned in the wiki at all. Is that something typically used for games or do they tend to use something else?

Collaborative text editing is what it’s traditionally used for.

Re: Show HN: I Built Multiplayer Deathmatch Joust

#85

Post by westoncb »

yoz wrote: post #81
jasonkester wrote: post #2

Most of this code dates back to 1998, when I built a little 2 player Joust game to push the bounds of what you could do with Div (and at the time Layer) tags in the latest browsers such as IE4 and Netscape 3. Surprisingly, most of it still worked when I thawed it out recently, provided your browser knew about document.all. Over the weekend, I brought it up to date a bit and introduced it to Socket.io. Thus far it has…

This is superb, addicting as hell, and now I have to force myself to stop because I have real work to do. The game gets increasingly jittery as it gets busier. It might be worth writing some tests to simulate lots of players moving around so it's easier to tune the performance.

Glancing at the code, it looks like he's rendering everything via DOM elements. I think player sprites are positioned using the top/left properties; could potentially optimize by keeping those props constant and just updating `transform: translate(x,y)` instead...

Re: Show HN: I Built Multiplayer Deathmatch Joust

#86

Post by aidenn0 »

stuaxo wrote: post #34
jasonkester wrote: post #2

Most of this code dates back to 1998, when I built a little 2 player Joust game to push the bounds of what you could do with Div (and at the time Layer) tags in the latest browsers such as IE4 and Netscape 3. Surprisingly, most of it still worked when I thawed it out recently, provided your browser knew about document.all. Over the weekend, I brought it up to date a bit and introduced it to Socket.io. Thus far it has…

Fantastic :) It would be nice if you could change the scaling to use nearest neighbour on the players so they don't look all smooged,

I don't know what the obsession is with blocky graphics; they didn't look blocky back in the day, so maybe faux-nostalgia?

Re: Show HN: I Built Multiplayer Deathmatch Joust

#88

Post by rtkwe »

Scaevolus wrote: post #52
jasonkester wrote: post #2

Most of this code dates back to 1998, when I built a little 2 player Joust game to push the bounds of what you could do with Div (and at the time Layer) tags in the latest browsers such as IE4 and Netscape 3. Surprisingly, most of it still worked when I thawed it out recently, provided your browser knew about document.all. Over the weekend, I brought it up to date a bit and introduced it to Socket.io. Thus far it has…

If you can figure out a way to only send inputs for each player instead of their full state, it should significantly reduce network traffic and lag for each player-- right now it's sending ~1KB/frame!

You'd have to resync fairly often to avoid desync especially for Joust where positioning during fighting is pretty important.

Re: Show HN: I Built Multiplayer Deathmatch Joust

#89

Post by airhead969 »

sib301 wrote: post #82
kgwxd wrote: post #75

Earlier quoted context omitted.

I don't see "game" mentioned in the wiki at all. Is that something typically used for games or do they tend to use something else?

Collaborative text editing is what it’s traditionally used for.

It can also be used to mutate hard game state (I wouldn't try it with dynamic, interpolated values like object position, angle, acceleration, or velocity.)

There are many other methods, some are more precise and compressible than others:

Trailing State Synchronization

https://www.cs.ubc.ca/~krasic/cpsc538a/summaries/38/

Basic ideas

https://www.gafferongames.com/post/state_synchronization/

https://engineering.monstar-lab.com/2021/02/09/Game-server-S...

https://www.gabrielgambetta.com/client-side-prediction-serve...

Re: Show HN: I Built Multiplayer Deathmatch Joust

#90

Post by Scaevolus »

rtkwe wrote: post #88
Scaevolus wrote: post #52

Earlier quoted context omitted.

If you can figure out a way to only send inputs for each player instead of their full state, it should significantly reduce network traffic and lag for each player-- right now it's sending ~1KB/frame!

You'd have to resync fairly often to avoid desync especially for Joust where positioning during fighting is pretty important.

Desync is possible with UDP protocols, where a dropped packet would mean lost inputs, but this uses websockets, which are reliable TCP connections, so just the list of inputs combined with a deterministic engine is sufficient.
Post reply on HN