Loonride

Members
  • Content Count

    26
  • Joined

  • Last visited

1 Follower

About Loonride

  • Rank
    Member

Contact Methods

  • Website URL
    https://loonride.com
  • Twitter
    Loonride

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Loonride

    Rendering Questions

    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. Loonride

    Player Speed and Client prediction in Multiplayer

    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. 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. Loonride

    Coding Slither.io in One Week

    Check out my new video about my one week Slither.io project with JavaScript and Phaser!
  6. Part 7 is here, concluding our series: https://loonride.com/learn/phaser/slither-io-part-7 Check out the demo: https://loonride.com/examples/slither-io/slither-io/ Thanks for the support throughout the series! Let me know if you want to see more tutorials like these ones.
  7. Part 6 of my tutorial series on making Slither.io is here! https://loonride.com/learn/phaser/slither-io-part-6 Check out the demo: https://loonride.com/examples/slither-io/part-6/ Enjoy!
  8. Part 5 of our series has arrived: https://loonride.com/learn/phaser/slither-io-part-5 Also check out the demo for this part: https://loonride.com/examples/slither-io/part-5/ In this part you will learn how to add those awesome eyes to your snakes!
  9. The page must have just taken too long to send a response or load. Let me know if it happens again.
  10. Part 4 of making Slither.io with Phaser is here: https://loonride.com/learn/phaser/slither-io-part-4. Check out the demo for this part: https://loonride.com/examples/slither-io/part-4/. In this part you will learn how to recreate the unique collisions seen in Slither.io.
  11. Parts 2 & 3 of my new series, How to make Slither.io with Phaser, are here! Part 2 - Creating your first snake: https://loonride.com/learn/phaser/slither-io-part-2 Part 3 - Extending snakes to be players or bots: https://loonride.com/learn/phaser/slither-io-part-3 Enjoy!
  12. Check out the first part in our tutorial series on how to make Slither.io: https://loonride.com/learn/phaser/slither-io-part-1 Also, take a look at the demo of what you will be making: https://loonride.com/examples/slither-io/slither-io/ Enjoy!
  13. Check out my new tutorial on creating vehicles and terrain at https://loonride.com/learn/phaser/terrain-for-vehicles! You can see the demo of this tutorial here: https://loonride.com/examples/vehicle-terrain/ Don't forget to let me know when you have created the next hit 2D driving game!
  14. Check out our new tutorial, Phaser Cars & Trucks with P2: https://loonride.com/learn/phaser/p2-truck We will cover constraining wheels to the truck body, increasing wheel grip, and creating a bouncy chassis effect that is seen in many popular games today. See what you will learn to create: https://loonride.com/examples/bouncy-truck