oosyrag's Recent Forum Activity

  • First off, lag/latency is something that is going to exist and is not physically possible to get rid of. Designing for multiplayer and net code are about how to manage and hide it from each peer and host.

    Local input prediction is one part of it on the peer side. An input from the peer will take time to be sent to the host and more time for the host to update the peer with what happened as a result of the input. The result is when a peer does something, nothing visually gets updated locally until that communication completes. Local input prediction hides this lag by allowing the peer's objects to update and move immediately upon inputs, and gradually correcting the position after receiving what actually happened on the host from the host.

    Reducing client delay isn't always a good thing - it's a lag management system on the host side. The client delay allows for a buffer time for the host to receive inputs from peer, because it takes time for peer inputs to be sent to the host, and also more importantly because latency is not a stable, set amount - it changes all the time. The client delay is how long the host has to collect actual received inputs from peers before updating the game. If the client delay is exceeded by lag, that means the host has to guess (interpolate, another lag management feature) at what the peer actually sent. When the guess and the actual input are different, you'll have a desync and correction = visible rubber banding and lag. It's often preferrable to wait for the actual input when possible to prevent desync. TLDR: what this means in the end is that you want your client delay to be at least longer than the time it takes for the host to receive each input from the peers, or even better the last two inputs from the peers so there's an extra buffer/backup time, because as I mentioned before latency changes constantly. (For more detail regarding timing, note that ping ms is actually the round trip time, so only half of that one way, and also don't forget to add in the maximum time between client input updates, which don't occur every tick.

    Regarding your "offline" disc accessories, assuming you mean those are not synced and displayed locally for each peer and host (which is the correct choice if they have no direct involvement in gameplay logic), it's a simple matter of positioning them when and where you want them on all peers and the host. Because they don't need to be communicated across the network, it is impossible for them to "lag". If you have them set to the disc position locally every tick, it will be at the discs visible position every tick.

  • Did you apply local input prediction to objects on the peer side?

  • Rays and beams generally consist of separate origin, body, and target/hit parts. The body part is the part that tiles with a variable size. This can be done with sprite objects + tiled background for the body, or a 9patch (at least we can rotate 9patches now!).

    Unfortunately, we have animations for neither tiled backgrounds nor 9 patches, so you'll either have to stack multiple of them and manually cycle through their visibility, or create and destroy them as you go to animate.

    You might also consider layering effects/additional sprites atop the path of beam, which can be animated, with the beam itself being mostly static.

  • There is a image transform, scale x and y in the tiled background properties you might have missed, I think that's what you want.

    Then make the base texture half as large pixel wise, but scale 200%.

  • If you're using families to pick multiple instances of the same object, delete both the picked object and the picked family object to get rid of both.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • construct.net/en/tutorials/supporting-multiple-screen-17

    The Scale inner fullscreen mode scales up the game to fill the available space, but if the aspect ratio is different, it cuts off parts of the view.

    The Scale outer fullscreen mode works like Scale inner, but if the aspect ratio is different, it shows more of the layout instead.

    You want scale outer, and design your UI for the narrowest aspect ratio but add "extra" screen space for wider aspect ratios.

    Scale outer is generally the most commonly used.

  • The peer will need to let the host know that it wants to do something, either by sending a message with the result, or sending it's input states, and the host can decide what to do about it.

    For example by input state I mean for example if the peer clicked a button on their screen, the peer would sync/send the input states of clicked, and the coordinates where it was clicked. The host would determine what to do/update, based on what it expects to be at those coordinates.

    By message, it would mean for the peer, on clicked button, would send a message to the host saying " I clicked this button" or equivalent, and the host would determine what to do on message received, for that particular message.

  • Input states can only be values, not strings.

    Did you try seeing input states interpolation to angle instead of none?

  • If it's repeating anyway, why do you have to have the base texture over the limit? Just scale it down.

  • Are you painting the entire level inside the specified width of a tiled background? That doesn't do anything, the point of a tiled background is that it's supposed to tile and repeat with little to no overhead, so you can have an infinitely wide tiled background as long as the repeating texture is less than 4096.

  • Tiled background is the way to go, and preferred practice. Have you tried reducing the width to 4096 as suggested by Construct?

  • Anything you want handled by the host, should be in the host group. This would normally be most of the game.

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