oosyrag's Forum Posts

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

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

  • That's not right, all behaviors, including physics, should already be framerate independent. You might have some other issue.

    Note that there is a minimum framerate of 30fps.

    MINIMUM FRAMERATE

    At very low framerates, dt can become very large. For example, at 5 FPS, dt is 0.2. An object moving at 500 pixels per second is therefore moving 100 pixels per tick. This can cause it to "teleport" through walls or miss collisions with other objects.

    Games are usually unplayable at such low framerates, but it is even worse if they become unstable like that. To help the game stay reliable even at very low framerates, Construct 2 does not let dt get larger than 1/30 (about 0.033). In other words, below 30 FPS, dt stays at 0.033. This does also mean below 30 FPS the game starts going in to a slow-motion effect (described earlier as one of the issues of framerate dependent games), however this is usually a better result than the "teleporting objects" problem.

    If you want to set a different limit to 1/30, you can use the system action Set minimum framerate.

  • Some simple logic for a rectangle fill tool might go like this...

    You'll need at least two points for inputs, those would be the corners of your rectangle. You could use the mouse coordinates on mouse clicked and on mouse released.

    Translate these coordinates to your tilemap tile values.

    Then you're going to run two for loop, for min(x1,x2) to max(x1,x2) and for min(y1,y2) to max(y1,y2), to set each tile within these bounds to the proper tile.