• Content Count

  • Joined

  • Last visited

Posts posted by Loonride

  1. I have been working for a while on a game called loons.io (https://loons.io) using Phaser 3. Some people have said the game is very laggy for them, and there are some assumptions about performance that I made previously which probably led to frame rate drops for players. If you can give me advice on any of these questions, that would be very helpful.


    1. Are large GameObjects.Graphics bad for performance? If I have a single, huge circle, most of which is not visible on the screen, will that cause any problems? Similarly, if I draw some polygons far from the origin of the GameObjects.Graphics, is that bad? Or should both of these things have a negligible effect?


    2. Are tileSprites the best option for a repeating pattern that will not change? This is how I have the grid pattern in my game, then simply shift it by the dimensions of a single tile each time the player moves a certain threshold.


    3. Will scaling up the canvas within CSS affect performance? I have a canvas container which I adjust to fit the screen, then I do width: 100% and height: 100% for the canvas. Is scaling up the canvas element different in any way from the options that the Phaser 2 ScaleManager provided?


    4. How much does the actual size configuration of the game affect performance? For example, my game is currently at 720x1280. Would I recieve high performance benefits from 540x960, at the cost of quality on screens larger than those dimensions?


    5. Does camera zoom affect performance? Obviously it will if more is being drawn as a result of zooming out. But what if you set a zoom of 0.5, then scale the dimensions and everything to 2 for all of your game objects, would it perform the same as zoom of 1 and scale of 1?


    6. Ultimately, is Phaser 3 ready for rendering to the same extent that Phaser 2 was, or should I still be using Phaser 2 for things such as the ScaleManager or to avoid frame drops?

  2. 30 minutes ago, Antriel said:

    Phaser 3 smoothes the delta time, which could cause the issues you are seeing. You would want to either change phaser's timestep or calculate the dt yourself.

    Also keep in mind that computers use crystals for tracking time and they don't exactly have high precision. With clock drift of around 20ppm, your time which can mean around 16ms difference between server and client within 7.5 minutes. Not much, but something for long plays, it can start showing.

    What exactly does smoothing delta time mean? I realize that Phaser 3 has a varying timestep. Would you simply calculate dt yourself by doing

    dt = Date.now() - pastTime;
    pastTime = Date.now();

    each time in your update loop? Also, as long as I'm never comparing client and server timestamps, clock drift should not matter, correct?

  3. I have some questions about my real-time multiplayer game. My game is already on the domain dinoman.io, but I think I need to redo how client prediction works. I sometimes notice that the movements of other players are quite choppy, and sometimes slower than the speed that they are supposed to be. Here is what I am currently doing:

    I get the dt from the Phaser update loop: update(timestep, dt)

    When the player presses an arrow key, I move them to a new position by the distance: speed * dt

    I then send their new position to the server at the end of that update loop

    The server checks that their speed is legitimate like this: It adds up the distance that they travel for a few seconds, then takes that distance and compares it to the time that passed on the server to see if it closely resembles the speed that the player should have had. However, I have to add some extra allowable distance to make sure that normal players aren't labelled cheaters. I thought this would be the best way to fight cheaters, but I'm wondering if there are better ways.

    The server sends out the players new position to all other clients

    The other clients do not move this player to that exact position in their update loop, but rather use their own dt in their update loop and the knowledge that this player should have a certain speed to move this player smoothly. If the predicted player position becomes too far away from the real position, the predicted position moves just far enough so that it is not too far away from the real position. This method seems to work most of the time, but there are times where I still see choppy movements from players, maybe because they are using really low-end devices. I almost never see choppy movements of players in popular IO games, and I am wondering where I went wrong.


    I mentioned that I sometimes see players moving slower than expected. Shouldn't multiplying speed * dt in their client always fix this problem, regardless of how low-end their device is? I want to say that there are times when it seems I move slower than the speed I have set when I start playing my game, but maybe that is rendering lag or something. How could the dt possibly be wrong?

    Thanks for the help, I know this is a lot!

  4. On 7/18/2018 at 9:27 PM, Krisztian Varga said:

    You've done a great job, especially in a week!

    I'have a question regarding player movement prediction in multiplayer: when you use the velocity and direction and let's say a player or enemy is heading towards a wall. The distribution of network packages is uneven expectedly. Have you not run into an issue, where a package was in late, that describes a player/enemy turning before hitting the wall, therefore client predicting that it went through the wall, using existing velocity and direction for the prediction. ..I've personally run into this a lot and had to abandon the approach. Is there anything that I'm missing here?

    Here is how I solve this. I adjust the predicted position of an opponent when it runs into a wall in the same way that I adjust your own players position without going through walls. I am doing collision checking for the opponent predicted positions as well for your own player (but only if in visible area). I always try to keep the predicted position within a certain range of the actual position. If an opponent's predicted position starts getting out of that range, I move it the minimum distance possible to get it back into that range, account for any collision. So the most choppy parts are when an opponent changes directions, but choppy movement is minimized by having this acceptable range of inaccuracy.

  5. Thanks for the feedback. In the future we will work on allowing the community to collaborate with us for this project. In the meantime, any other ideas are appreciated! We may make the core algorithms open-source, or instead we might start using a graphics library that already exists. Improving our outlining algorithm is our first priority.

  6. 2 hours ago, spinnerbox said:

    Meh, generic stuff. The obstacles are preset from the beginning of the level, and I cannot pass the 4th level without getting spiked.

    No offence, but if you want to make a Flappy Bird game, just make a Flappy Bird game with a different name :D or spend more time balancing the levels.

    Thanks for the feedback. Levels will definitely receive more thought in the future. The main focus of the game, however, is endless mode. It is much more unique because each loon has a special shooting ability. Did you try endless mode?

  7. Loon Ride, the epic loon game, has received major updates on all platforms! Collect loons, shoot cacti, and soar through endless mode.

    This game was made using Phaser.

    Read more about the game here: https://loonride.com/about/loonride

    Play the game in your browser here: https://loonride.com/games/loonride

    Get the game on Google Play here: https://play.google.com/store/apps/details?id=com.loonride

    Promo video: 


    S-DUI5ThYmLlqj_ltlTO0k0dgraGuF-4aSYXr5gQtYFPM61hTLC2sZBcAtnRCL5gxV4=h310-rw Loon Ride- screenshot thumbnail Loon Ride- screenshot thumbnail tof4YwSqvBHohno6ir59_UpGeToXfeFNT3gTJPrsyJFg5BDdYz7MntzntRfmp1UpwsI=h310-rw XWocYcNziSGElN1D-ONugWUrtWHOSTOoTjyy177XxfBTnYVcewE7vxyBipiFx7FOyDI=h310-rw dQ_uHsDcIYkd4y7S6xc3TCL9vRMe1g_jdx8LDQuoyK_fJ1tKTrQvfytapxNj7bXWLg=h310-rw VD9uoUOhbuzvMsLTSJmvm68fp2k9zWdyOquhUU2rbfBch6-h0qL8YIIF7idNmzmxYg=h310-rw EX1RyGyglMA6gH5LiEpOk_dlkmDj5v0KfASOoqzVMDhYBdDOoxyM9bHIipp3fzJaec9B=h310-rw