oosyrag's Recent Forum Activity

  • Even if you call it a real time game, as long as the players have no direct interaction with each other at any given time it is in effect no different than a turn based game. Which means syncing becomes a much lower priority, and you have tons of options to hide latency.

    Even if they do have to interact at some point though, it always helps to break down what information is most important to be consistent across players, and when is it necessary? Anything that has the potential to interrupt or change what is expected to happen from any players point of view needs consideration.

  • One option, given that player 2 doesn't actually know when player 1 hit the ball in real life, is to not send the shot information to player two until it's completed. Then you'd be able to send information about the complete trajectory and end location all at once for player 2 to replay, in a sense.

    Another option is to not sync the ball location at all. Let player two run his own simulation based on the input of player one, and then update the final location to the actual one upon (or right before) coming to rest, whenever that information is available. The difference should be mostly imperceptible if both users are running the same physics engine.

    Basically instead of syncing the ball location at all times, only sync it at key moments, wherever it would be most effective to hide latency (I imagine the final resting position is the only real value of importance here). You can even add an ease/lerp/tween upon syncing the final location, to hide any unnatural looking jumps that might occur.

  • If you want it to increment, you'll need set value at 0 to array at 0+x. You're setting it to array at 1+2, which never changes because you are not changing array at 1.

  • Post a screenshot of your events or right click and copy as text.

    Fwiw, as you described, array.(0) is incorrect and it should be array.at(0), but I don't know if you just typed it wrong here or if construct actually let you do that.

  • Option A. Don't even use the mouse over condition on the peer end. Let the host decide if the mouse was over the object or not.

    Option B. Don't worry about keeping drag and drop host authoritative and synced. Basically favor local input prediction and responsiveness over host authority, and have the host and other peers catch up to the current peer location instead.

    There is no way to remove latency in the real world. You just have to design around it, weather you decide to favor host authority or local authority is up to you. Designing netcode is all about how to best hide the latency from each party involved while preventing inconsistencies and conflicts.

  • I wonder if renaming the wait action to something like "Delay following actions" might help reduce confusion.

    And/or a tooltip maybe in the description that explicitly states that it does not pause event execution.

  • Use an instance variable, put the UID in that.

    Or put the sprite and array in a container so that when you pick (and create) the sprite the correct array is also picked.

  • It wouldn't require it, you can post and get from a webserver with AJAX too.

  • I don't know if this will work for you but here's a trick I've used before.

    dropbox.com/s/wyiz1r06s2p3o5w/autotile.c3p

    The water is it's own layer under the tilemap, which is transparent where there should be water. It consists of two tiled backgrounds sliding across each other with the sine movements.

    Alternatively, I imagine animating by swapping tiles should work perfectly well, if you constrain the updates to happen only if the tile is on screen, or animate only a random portion of the tiles at a time rather than all at once.

  • I would just use higher resolution pixel style images.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Don't know much about your specific implementation, but did want to suggest the possibility of using invisible hitbox helper sprites either at the corners or all along the top edges of a platform to trigger ledge grabs instead.

  • Alt-click the preview button.

oosyrag's avatar

oosyrag

Member since 20 Feb, 2013

Twitter
oosyrag has 39 followers

Trophy Case

  • 12-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • Unrelenting Visitor Visited Construct.net 180 days in a row
  • Continuous Visitor Visited Construct.net 365 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

22/44
How to earn trophies