citron2010's Forum Posts

  • Can't you just disable physics on the object at some point before it hits the slope?

  • I’m guessing this might fix the remote play together issue I ran into a few months ago - I’ll give it a try when I get a chance.

    And thanks working on this - it rather came out of the blue!

  • mayhamurasaki

    Hey, any updates on this? Did you manage to resolve it somehow?

    Sadly not. When I managed to get remote play working without input control, it was two devices on the same network - so close to ideal conditions - and even then, I think the lag wouldn't be ideal for my game which is very sensitive. It would be nice to confirm with input control working, but at the moment I don't have time to investigate deeply enough to either fix myself or confirm there's a bug somewhere.

  • There will always be some delay when data is sent over the internet. That is simply a physical limitation of networking.

    You can make each player’s flipper respond immediately on their own machine, but if the host remains authoritative over the ball, the visible ball reaction will still arrive later. Input prediction does not remove latency, it only tries to hide it by showing the expected result before the authoritative result arrives. And it's just used for inputs, so controlling something. You can't really apply this directly to a physics behavior-ball.

    That is generally what real-time multiplayer networking is about: hiding latency through prediction, interpolation, reconciliation and, in more advanced cases, rollback.

    For this particular game, one possible hybrid approach would be:

    • Let each peer activate their own flipper immediately.
    • Send the input, timestamp and relevant flipper state to the host.
    • Let the peer temporarily predict the resulting ball collision and trajectory.
    • Keep the host responsible for deciding the final authoritative ball state.
    • Synchronize regular ball snapshots from the host.
    • Interpolate normal movement and gradually reconcile small prediction errors over several frames.

    A more advanced implementation would keep a history of inputs and physics states so the client or host can rewind and resimulate from the collision time. That is broadly referred to as rollback.

    Note that this is just a simplified overview. There is no single setting that makes networked physics responsive and consistent. the appropriate solution depends on how much latency, visual correction, implementation complexity and potential cheating you can tolerate.

    Also keep in mind that that applying these techniques using the physics behavior may not be feasible. It would probably be easier to run your own event sheet driven physics solution. Separating the actual ball's collision box with its visuals could also help to further hide position corrections and so on.

    Everade - thanks for this - sorry only just noticed. You've pretty much confirmed what I've found and the solution you're proposing is similar to how I've thought about solving this, but it's a lot of work and I can't be sure it'd work well.

  • First, make sure elasticity is set to zero for both the shape and the ground

    I'm not sure what's causing the shape to move when it touches the ground, but the reason it spins out of control afterwards is likely because there's no angular damping.

    Not sure why you're disabling physics either

  • I've always deliberately ignored anything 3D - not neccessarily because of C3's limited support, but simply because it's whole new paradigm to learn. But with recent developments by Scirra, other third-party plugins and especially this one, I think it might be time for me to delve in. Thank you.

  • Using a client input value to send the flip command from guest to host, then sync’ing the flipper’s position back to the guest unfortunately isn’t cutting it even under optimum conditions of same machine using the LAN bandwidth profile. There’s still too much lag for the precision timing required for the game.

    I still don’t really understand what local input prediction actually does but I tried enabling it whilst also flipping the flippers on the guest but it just causes the flippers to jitter – I suspect it’s because they’re normally moved every tick by applying a physics force, but in my multiplayer test, I _think_ they’re only being moved “on client update” and possibly getting slightly out of sync so they keep being moved back and forth slightly showing the jittering.

    I’ve also tried controlling the flippers using “unreliable” messaging – that reduces the lag but the syn’cing is still messed up.

    And I’ve also tried running the physics on both then sync’ing differences when the ball’s hit – but this just highlights what I think is another fundamental issue – there’s many occasions when the ball hits a flipper then almost immediately hits an opponent’s flipper. Either flipper could be moving, so if they’re out of sync (which they inevitably will be due to physical network/hardware limitations), the positions of the flippers, and particularly the ball, quickly diverge and any subsequent attempts to synchronize them causes noticeable jumps.

    None of this comes as a surprise – I’d concluded several years ago that networking Flippee Ball would unlikely work satisfactorily for the reasons above and that sync'ing physics is notoriously difficult.

    It’s a shame because I’ve had many requests for network play – but unfortunately, it’ll have to stay local only.

    The good news is that I now (mostly – see above!) understand how the plugin works and almost certainly will use it at some point in the future - it seems pretty comprehensive and straighforward to use.

    EDIT - just adding this screenshot so anyone reading this has some idea of what I'm talking about!

  • Do you need to do it every tick?

  • I don't think you can save the canvas directly to an array. IIRC, each canvas can only "hold" one image in its URL, so you probably need to save them to local storage then reference them in your array.

    EDIT - or load them straight into sprites - but that could cause memory issues if there’s many

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • In the MULTIPLAYER: REAL-TIME GAME example, I see that local prediction is enabled for the Peer sprite. When I play the game, I see that the sprite moves immediately on the peer and if I disable local prediction, then there’s a noticeable delay.

    So, what’s happening? I see that “on client update”, “inputs” is updated to reflect the peer’s button press states. Then every tick the peer also uses this value to move the sprite locally.

    With prediction disabled, it feels to me that “inputs” is updated once and should be sent to the host and actioned on the peer at the same time – but there’s a delay and I don’t understand why or how it's different to when prediction is enabled.

    I’m also not sure I understand WHEN “on client update” triggers!

    Any guidance would be hugely appreciated.

  • I think you can easily do it without an array. Give your pixel sprites two instance vars: “id” (integer and set it on all sprites from 1 to 64) and “pixel” (string - either “.” or “#”). Then on click pixel sprite, toggle its animation and the value for pixel. In the same on click, clear the text then do a “for each ordered by id” loop on your sprites and append the value of pixel to the text.

    Importantly, also append

    ”””BITMAP “

    before the value for pixel if id mod 7 = 1, and:

    “””” &newline

    afterwards if id mod 7 = 0

    Note the double quotes - to allow you to put quote marks in a string.

    (Edit - fixed the newline being in the wrong place!)

  • Is this on mobile browsers or Cordova exports? iOS and/or Android?

  • github.com/Scirra/Construct-bugs/issues/7684

    Workaround is to reduce the line thickness to 5!