• Content count

  • Joined

  • Last visited

About Antriel

  • Rank
    Advanced Member

Contact Methods

  • Website URL
  • Twitter

Profile Information

  • Gender
  • Location

Recent Profile Visitors

987 profile views
  1. For simple static site hosting, amazon web services will cost few cents (literally). It's not even that difficult to setup. And if you didn't use it so far, it comes with pretty big free limits for the first year, i.e. basically free.
  2. Web UDP - public demand

    This guy also tries to push something like that forward:
  3. Kikiki - HTML5 Multipayer Battle Arena

    Looks pretty good! I would add client side prediction (with reconciliation) for the movement. For shooting I would leave it without prediction, just add some animation so there's immediate feedback for the player.
  4. Remaining listeners after removing a group from stage

    Were they? IIRC they were not by default. Unless you used the optional parameter to set it as a weak listener and the object was gc-ed. Although in case of buttons, they indeed would not trigger (because they weren't in display list). The listeners would stay there though. Not sure how Phaser does it, but I expect the listeners to stay connected (although possibly not triggering as you can't really 'inputOver' them). Maybe `group.destroy()` will work? Not sure
  5. Multiplayer Platformer devlog

    Another devlog and it's a big one! Multiplayer Platformer Log #5 – Entity Interpolation Explaining entity interpolation. Implementing client-server synchronization using phase-locked loop. Talking about server update loops. And lot of shared code. Finally some worthwhile gif – moving around on a real server with ~200 ms ping:
  6. Multiplayer desync

    server.js line 55: You use for loop, but then use `inputs.shift()`, which manipulates the array in place. Maybe it's different in JS, but you probably want to use `while(inputs.length > 0)` instead of the for loop. Otherwise you might have issues once there's more than 1 input at a time. I strongly recommend to refactor the code, so that game logic that's shared between the client and the server is separate and shared. You should use the same code to apply update on a player instance on both. This removes code duplication and down the road will save you lot of headaches (that code duplication almost always causes). On the client side you cache all the inputs in `updates` array forever it seems. There's no reason to keep the confirmed inputs, they can be thrown away. I suggest using some big enough circular buffer instead. As for the actual trouble you have: I'm not 100% sure, at first I thought you weren't properly syncing the `lastBoost` variable, but that one is part of the inputs (which might not be a good idea either, see below), so it should work properly. The only thing I noticed is that it seems you apply the last input twice on the client. First you push it to the `updates` and then you iterate all updates and then once again apply this latest `data` update. Maybe this isn't the cause of the issue, but certainly something to check. I recommend inspecting values and trying to find out at what point the reconciliation result becomes different than expected. Regarding sending `lastBoost` and `time` as part of the input data to server: If the server is supposed to be authoritative, all that should be sent are the inputs and the server should simulate it all. Otherwise what stops me from saying my `lastBoost` time is constantly 0 even though I am boosting? Even the delta time shouldn't really be sent, although that is a design decision that might be needed if you need perfect reconciliation results. I do in my game and I went about this in a slightly different way (constant timestep). You can read about my approach on my blog: While it doesn't yet solve all the issues like time synchronization and entity interpolation, that article should come next week
  7. Does my game page scroll?

    It does scroll, it stops when the game is active. I would say that's expected behavior, but I suppose such script could fix that if desired. That script doesn't work though, because it's in the index of your game, which is inserted via `iframe`. The `window` is the iframe, not the whole page. You might be able to use `window.parent` but I think that won't work either unless the iframe is loaded from the same domain as the parent. Basically, the script needs to be included on the retroboltgames html file, not the game's index.html file.
  8. Graphics Darker While Moving

    I would say this is just a mix of optical illusion with display capabilities. That's why only small lines do it and why they need to be moving. Basically your eye sees black color then suddenly blue where the black was. Also the display has to change from black to blue. Other than having very good display and brain not susceptible to illusions, I doubt you can do anything about it.
  9. I never used phaser's box2d, but my guess is that `edgeChains` is a part of phaser's code, sort of extension of the pure box2d. For multiplayer you want to be absolutely sure the physics runs the same on both clients and the server, so my recommendation would be to use box2dweb or any other physics engine you want both on the client and the server. You might also be able to look at phaser's source and see how the `edgeChains` class works and replicate it yourself for the server.
  10. Properly syncing multiplayer movement

    They should be pretty accurate most of the time. As far as I can see the errors come from either: Floating point operation errors. Those shouldn't even be visible unless they resulted in widely different results, like getting stuck on an edge vs moving alongside it. Not much you can do about this, but it should be extremely rare. Too active physics environment where the world state is too different between client and the server. Not much you can do about that, other than increasing tick rate. From what you said in your first post you shouldn't have issues with either of those, so I maybe you implemented the prediction wrong. Are you correctly reapplying unconfirmed inputs on the client (i.e. properly calculating reconciliation result). Are you using the same timings on both client and the server? Usually you should use fixed time step, not really the time it took for the packet to travel (i.e. not the time since last input). Although that depends on the game and could work with high enough tick rate (small time step).
  11. Properly syncing multiplayer movement

    What you implemented is called Client-side prediction. Gabriel Gambetta wrote a nice article about it: I also wrote about how I implemented in my in-development multiplayer platformer game: You also want to implement what Ivan mentioned: Basically, on the client, once you do the reconciliation, you calculate the error, i.e. the difference between predicted and actual position. But you don't apply this difference right away, but instead you apply it over a few frames. You can find some pseudo code for one way of implementing that in an article by Glenn Fiedler:
  12. Yes, Phaser v3 supports both canvas and webgl. You can look at the current examples here:
  13. Once the global coverage hits certain level (right now mobile browsers don't seem to support it yet), certain games will definitely use it. Whether it will replace JavaScript, probably not. JavaScript will still be enough for a lot of uses, possibly some libraries might get a WebAssembly build, but the game code could still be JS. Among the first adopters I would expect people using languages like Haxe, where it should be possible to provide both JS and WebAssembly builds, letting the browsers use whichever they support. I don't see many people, at least not for small web games, using C++ directly. More likely some higher level languages, like C#. It will all depend on what frameworks will be available. Eventually I would expect all bigger frameworks that already support .c target, to add WebAssembly target.
  14. AirConsole uses WebRTC/p2p? On their developer info page they mention: Which suggests standard client-server architecture.