Live data from Hacker News

Show HN: I Built Multiplayer Deathmatch Joust

joust.life

101–107 of 107 posts

Re: Show HN: I Built Multiplayer Deathmatch Joust

#101
post #34

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,

It's just vanilla javascript, html and css. Pull up dev tools and notice this in the css:

  img {
    image-rendering: pixelated;
  }
Lop that off (or uncheck it in dev tools) and you can have things as blurry as you please.

Re: Show HN: I Built Multiplayer Deathmatch Joust

#102

Great work on the 'feel' of the movement. Would love to know how the gravity/jumping works. I'm a little disappointed the sound effects of the feet are missing - that was one of my favorite things about Joust.

Gravity is just a constant acceleration downward, so nothing special there. I have the footstep sounds ready to go, but I found that I really needed to limit what sounds I played because they get overwhelming pretty quickly. There's now a pretty tight radius to the player for what gets played. First cut was to have all 200 players' flapping sounds audible to everybody. That was suboptimal...

For the footsteps, it’s probably fine to only play the fx for the one character the player is controlling.

Re: Show HN: I Built Multiplayer Deathmatch Joust

#103
post #88

Earlier quoted context omitted.

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.

They can arrive out of order so you still have to deal with rewinding an re'simulating' the whole sequence of moves since the skipped packet then dealing with resolving the client vs server when they disagree.

Re: Show HN: I Built Multiplayer Deathmatch Joust

#105
post #103

Earlier quoted context omitted.

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.

They can arrive out of order so you still have to deal with rewinding an re'simulating' the whole sequence of moves since the skipped packet then dealing with resolving the client vs server when they disagree.

The TCP connection is never closed with websockets.

Re: Show HN: I Built Multiplayer Deathmatch Joust

#106
post #103

Earlier quoted context omitted.

They can arrive out of order so you still have to deal with rewinding an re'simulating' the whole sequence of moves since the skipped packet then dealing with resolving the client vs server when they disagree.

The TCP connection is never closed with websockets.

That doesn't change that TCP packets can arrive out of order does it? (It's been a while since my college networking class and it's not something I come into contact with in my job)
Post reply on HN