oosyrag's Forum Posts

  • Ok there are a few issues here...

    You only have one input value, at very low precision. This can only contain a 1 byte value, which is a single number between 0 and 255. A 1 byte value can also be represented in binary to simulate 8 on/off switches - this is how they used it in the multiplayer tutorial. With it, they can keep track of up to 8 keys or mouse buttons that are being pressed or not.

    However, consider your own needs. What does the peer need to tell the host? In your game, you'll need to send the fact that the peer clicked, and also where the peer clicked. The location is two values, an x and a y number, that can definitely go above 255. So these two values need a higher precision. I would use normal or high, since you're honestly not going to have bandwidth concerns with just two players and small amounts of data going back and forth.

    So step 1, add two more input value tags, for "mouseX" and "mouseY", precision high, no interpolation.

    You probably also don't need to store the peer values as instance variables in the object, since I'm assuming you may have multiple cards eventually, and either player can move them so the peer inputs are not associated with any particular card. So you can get rid of the sync variable, and use the inputs directly to keep it simpler. 

    -> Multiplayer: Add client input value tag "inputs", precision Very low (uint8, 1 byte), interpolation None
-> Multiplayer: Add client input value tag "mouseX", precision High (double, 8 bytes), interpolation None
-> Multiplayer: Add client input value tag "mouseY", precision High (double, 8 bytes), interpolation None

    Next lets look at the peer events, to send the peer inputs to the host. Lets remove local input prediction for now, since you haven't gotten the underlying system working yet. Since you're only keeping track of 1 button press, left mouse down, you don't even have to worry about setting bits. So keep it simple. If left button is down, set inputs to 1. Else 0. You'll also always want to send your current mouse position every update, so you need to add 

    + Multiplayer: On client update
-> Multiplayer: Set client input state "mouseX" to value Mouse.X
-> Multiplayer: Set client input state "mouseY" to value Mouse.Y
----+ Mouse: Left button is down
-----> Multiplayer: Set client input state "inputs" to value 1

----+ System: Else
-----> Multiplayer: Set client input state "inputs" to value 0

    Your peer events should have nothing else for now. Remember the peer only tells the host what its inputs are, the host will do all the work and sync back the results to the peer.

    As for your host events... the "On client update" is a peer only trigger. So basically your host is doing nothing at all right now. Again, the host needs to do the actual work of moving of the object based on peer inputs.

    So first it needs to have its own way of moving the object. The drag and drop behavior should be enough for this for now.

    Secondly, it needs to check if the peer's mouse is down. If it is, then is it clicking on the sprite? Then after that, if it is clicking and on top of a sprite, update the sprites position every tick to wherever the peer's mouseX and mouseY are.

    At this point, if you've got everything working properly, both players should be able to move the object around with their mouse. You can try adding lag compensation after you get this working.

  • peerid is used as a unique identifier for each person, while myid gets their own.

    You probably don't need to associate if each player isn't controlling a single object.

    Sync object is something the host does. Once an object is synced, if this object gets created or destroyed by the host, create it and destroy it on all connected peers (same for position and angle, if selected).

    So if the host moves a synced object, it will move the same way on all peers.

    Peers cannot move the synced object. They can only tell the host what they are doing with their mouse and keyboard inputs, and then the host can move it based on that.

    This will cause what appears to be input delay/lag on peers. You can hide this lag on the peer side by using "local input prediction".

    Multiplayer concepts definitely take more than the usual effort to learn, even if the game itself is simple enough.

  • What dop said, but you can also try disabling the bullet behavior when the sprite is less than x distance from mouse, and enabling it when more.

    If your player object is moving very quickly, you can use the stepping property and events to prevent overshooting your mouse position.

  • Correct. This is the nature of peer to peer networking. Although it's not exactly instant, there is some leeway in reestablishing a connection.

    Depending on the scope of your game and the amount of data required to sync, it is actually possible to recover or migrate hosts. That is a significantly more advanced topic though, and generally speaking it is not worth investing time into.

    You can also look into cloud services like firebase or photon cloud depending on your gameplay requirements.

  • I have tried the official signaling server. The problem is that the official rules for creating rooms do not apply to my current situation (the first one to enter is the host, and the second one to enter is the player). I need to make sure that some accounts must be the host, regardless of the order of entry.

    Don't use the auto join room feature.

    This can simply be done by requesting the room list after logging on (or otherwise authenticating your user by your preferred method. After you get the room list, you can see what rooms have people in them already, or are full. If you have a designated host client, have them enter/create a room that doesn't already exist, while a peer client will join one that does that has space.

    In addition, I also want to ask if I use the turn server for data relay. The principle of connection is that the host sends it to the turn server, and the turn server distributes the massage to everyone, or the turn server is still P2P.

    That's not how WebRTC works. The signalling/turn server only facilitates connections between peers, it does not otherwise handle any data.

    This won't change even if you host your own signalling server. Actually neither of your issues really has to do with the signalling server.

  • Two ways: Record inputs and time, or record absolute position and time.

    Either way, storage would probably be done via an array. For example...

    Every x seconds, push sprite.x to array, set sprite.y to array at (0,1)

    Would populate an array with the sprite position x and y every x seconds. Then save the array, and have your ai move to each position in the array in sequence.

    Alternatively, you would save what the player was inputting at every time instead of the sprite's position

    Depending on your game and how it is set up, either of these approaches could be optimized for further detail.

  • I believe — sells a firebase plugin.

    rexrainbow used to have a free plugin for C2, but I don't know if that ever got ported to c3 by someone else, probably not.

    Otherwise, you can also access the firebase API directly through JavaScript, which you have access to in C3. construct.net/en/tutorials/construct-firebase-2163

    You can also use an app wrapper service like Enhance.

  • Eventually with percentages you will get a non even number, with a lot of decimals that won't fit into your text box.

    You can make your text box bigger, or try using floor(number) or round(number) instead to get rid of the decimal value.

  • 5% = 5/100, or 1/20.

    So on button pressed, set health to health+(health/20).

  • To run your own signalling server, you will need to purchase the signalling server code, then run or rent a server to host it.

    You can purchase it at - scirra.com/store/game-making-tools/multiplayer-signalling-server-161

    If you don't understand how signalling works or how to put one together already without needing to ask on these forums, I HIGHLY recommended using the official signalling service.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Haven't looked at your project yet (the filesize is rather large), but some possible issues:

    The sync action only syncs object creation, destruction, and optionally angle and position. Any resizing of the object will need to be manually done on both the host and peer and synced. You can either use consistent events between the host and peer (non host-authoritative) to do so, or put the information in a synced instance variable (host authoritative) and update the values on the host which peers read and adjust the object accordingly.

    Make sure the peer isn't running the spawn function, only the host should create or destroy any synced objects.

  • Have you tried using the WarpRipple effect in effects?

    Frequency 3, Amplitude 1%, Speed 15 seems to get a similar result for me. Settings probably depend on the size of the sprite though for whatever specific look you are going for.

  • From memory, start with a size 0 array:

    Repeat tokencount(sourceData," ") times

    Array Push back on x axis tokenat(sourceData,loopindex," ")

  • That looks great! Didn't realize that effect existed. For how well construct is documented otherwise, the effects documentations are conspicuously missing.

  • Sorry took a bit.

    See if this is what you're looking for.

    dropbox.com/s/uuh8u9a2yn6ndgo/preserveangle.c3p