chriswa

Members
  • Content Count

    15
  • Joined

  • Last visited


Reputation Activity

  1. Like
    chriswa got a reaction from mikhluz in Farmer's Journey   
    Gorgeous! Well done!
    The only criticism I can offer is: (1) a progress indicator on the loading screen would be nice and (2) the camera should probably be panned up a bit: I found myself wishing I could see further ahead, and I noticed that the bottom half of my screen wasn't helpful for gameplay.
  2. Like
    chriswa got a reaction from que in Improving performance of MMO-style canvas game   
    I wasn't able to figure out how to throw a spear, as shown in your video, but I did walk around a bunch, and opened and closed a chest. I didn't register with a valid email, I just typed "qwer" and "asdf" into your two textfields.
    I pasted mrdoob's stats.js into your page and got a consistent 75 fps (that's the highest I seem to be able to get in Chrome) with no noticeable frame delays. Granted, I have pretty beefy hardware, so YMMV.
    I made a Zelda 2 clone 5 years ago with 2d drawImage calls, clearing the canvas every frame; I had at least double the drawImage calls I think you're using and it ran very quickly on older (at the time) hardware, including my phone. I'm not sure what it's costing you to use 3 canvases. Any reason why you're doing that instead of just compositing everything onto one canvas?
    I'm also concerned about your setTimeout loop. I think it's generally preferable to have a pure requestAnimationFrame loop and accumulate elapsed time, updating your world state when the elapsed time reaches a "tick" and rendering everything every animation frame. (As a bonus, this lets you do interpolation between update steps for even smoother animations.)
    I did notice a significant delay in the game responding to my keypresses. It took roughly 800ms for my character to move one tile, and when I tried queuing up several commands, some of them were dropped. There was also some very noticeable delay loading in new map chunks. I'm guessing the delays I experienced were related to your networking.
    Chunk loading can be solved relatively easily by pre-loading a larger border of tiles around the player, but not rendering them yet. Input lag is much trickier to solve.
    One common approach I've read about to deal with these kinds of delays is to predictively start player animations on the client side immediately, and deal with the server's response when it gets back. With the information the client has about the world, it can easily decide whether you will be able to move to the next tile or if a wall will prevent you.
    This gets tricky when there's hidden information (e.g. invisible landmines or invisible walls) or random events (e.g. hits, misses, and damage rolls.) This works well for some scenarios and poorly for others; for example, if there are invisible landmines that explode when you've finished your move, you'll probably get a response back from the server before the player finishes moving to the next tile, so that should be easy to resolve; however, invisible walls may cause players to "rubber-band" back after seemingly travelling part-way through the wall (or all the way through, if their connection is lagged more.)
    And things get very, very tricky when you take other players' actions into account. Modern FPS game servers temporarily rewind time when you shoot your gun to compensate for your lag, to see if your bullet would have hit anything. This means you don't have to lead your targets to account for your network latency, but it also means you can get shot immediately *after* jumping behind cover.
    P.S. Cool to see you're using Vue for UI, I think I might do the same for my current project!
     
  3. Like
    chriswa got a reaction from Asisvenia in Do frameworks provide better performance than pure JS coding or not?   
    You can squeeze a surprising amount of performance out of raw WebGL, especially for tiled backgrounds and sprites which share the same sprite sheet. In my experience, some WebGL-accelerated frameworks sometimes do a poor job of rendering these things: namely by making way too many draw calls. However, using the 2d canvas API is almost always going to be slower than WebGL.
    I think you made the right choice using the 2d API for your first game!
  4. Like
    chriswa got a reaction from austincap in How many simultaneous sprites can Phaser 3.6.0 handle?   
    I don't see more than 1000 sprites in your screenshot. Are you drawing off-screen sprites too? That can slow things down quite a bit. Are you able to skip drawing sprites outside of an (AABB) rectangle which represents your viewable screen size?
  5. Like
    chriswa got a reaction from mattstyles in When to use a database in a game   
    I think the simplest solution would be to send the player their player id when they're first added to a game. Store it persistently client-side (for example in localStorage,) along with the game id. When connecting, the player should send their last known game id and player id from localStorage (if they have one.) On the server, check for a matching game id with a matching, disconnected player id. If you find one, reconnect the player, sending them a snapshot of the game state so they can keep playing. Otherwise, ask the player for a game id as normal, ultimately connecting them as a new player, with a new player id.
    If your game ids and player ids are likely to conflict (e.g. always 0 and 0 for the first player of the only game on the server,) you may need to worry about players mistakenly hijacking disconnected spots when they are intending to enter a different game. You could make this issue statistically impossible by generating random ids.
    P.S. I don't think you need a database for this game, unless you want to survive server crashes, or start tracking win/loss statistics for your players.
  6. Like
    chriswa got a reaction from mattstyles in When to use a database in a game   
    Is your game turn-based or realtime? How much data will you be storing and how frequently will it change? What is acceptable behavior if your server crashes unexpectedly? How many simultaneous players do you want to support? How many non-simultaneous players?
    A very simple solution could be to write a JSON file to disk ("saves/userid.dat") with their current state when a player disconnects. When they connect, look for a JSON file with their user id and load their state.
    If you wanted to save every player's current position 30 times a second (in case the server crashes,) quickly search for any players near a position, or support robust trading between players, this simple file-based approach isn't going to work.
    Databases basically improve read speed and write safety, but they have tradeoffs, including making your project more complex. I think it's important to determine what your requirements are.
    P.S. Mongo doesn't support ACID transactions (except within a single document,) so it can't safely support trading, at least not perfectly.
  7. Like
    chriswa got a reaction from b10b in When to use a database in a game   
    Is your game turn-based or realtime? How much data will you be storing and how frequently will it change? What is acceptable behavior if your server crashes unexpectedly? How many simultaneous players do you want to support? How many non-simultaneous players?
    A very simple solution could be to write a JSON file to disk ("saves/userid.dat") with their current state when a player disconnects. When they connect, look for a JSON file with their user id and load their state.
    If you wanted to save every player's current position 30 times a second (in case the server crashes,) quickly search for any players near a position, or support robust trading between players, this simple file-based approach isn't going to work.
    Databases basically improve read speed and write safety, but they have tradeoffs, including making your project more complex. I think it's important to determine what your requirements are.
    P.S. Mongo doesn't support ACID transactions (except within a single document,) so it can't safely support trading, at least not perfectly.