oosyrag's Forum Posts

  • They only push each other if they are both solid, and only overlap if they are both not solid.

    If only the one that isn't moving is solid, then it should work. You can use simulated controls if you still want to be able to push blocks, as I mentioned before.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • On zombie killed, add 1 to a global variable.

    If global variable is greater than x, go to next round.

    On start of round, set zombie life to round number*base zombie life.

  • Forwarding to next room would be the same as if autojoin tried to join a room that was full or locked, on peer connected (after game started) host can kick with the message current room name + 1, which the peer can use to retry joining again after getting kicked.

    If you're not utilizing autojoin, that wouldn't work. In that case, I'm guessing you already have a lobby system where people can browse and pick rooms to join. Then the method of moving to a new room upon starting a game would be the most suitable, as you can then display only rooms that have space as options to join.

  • Alternatively you could just have new peers joining get kicked immediately, and forward them to the next room.

    You say inefficient but it's virtually instantaneous and imperceptible to users.

  • Use an invisible helper sprite as the start position.

    + System: Every 30 seconds

    -> StartPosition: Spawn Car on layer 0 (image point 0) (create hierarchy: False)

  • The debugger opens in a new window when I use it. Chrome/Win10

    Also if you hit the preview button again without closing the previous preview/debug, it stays in the same place.

    Suggestion and bug reports go here -

    construct.net/en/forum/construct-3/general-discussion-7/report-bugs-amp-post-128538

    Edit: There is an option in the settings that lets you choose preview in popup window or browser tab.

  • The only thing I can think of is to use an intermediary "matchmaking" room. Then create a new private non-autojoining room when the number of peers are determined.

  • Object would be the name of your sprite object. I would have no way of knowing what you called it. Self also works.

  • You would use them in an expression, object.startX and object.startY.

    Have you done the beginner's tutorial? You should probably do that before anything else. construct.net/en/tutorials/beginners-guide-construct-1

  • It looks like if both the tile movement objects are solid, then they will push each other based on the bounding box rather than the collision box and not block movement. Ashley is this intended behavior?

    If you turn off solid for your object with default controls, they move together fine even with exact fit collision boxes.

    To work around this, you might want to not use the built in solids behavior at all, and make your own pushing/blocking mechanic through events.

  • Make two instance variables within the object, for example startX and startY. On start of layout, for each object, set startX and startY to self.x and self.y.

  • The built in plugins and behaviours are not available to be modified or copied/forked in Construct 3.

    You can recreate pretty much any behavior with events or JavaScript if it doesn't work the way you want it to.

  • Syncing variables (and objects) happens only one way, from host to peer.

    Synced variables can only be number variables, not strings or booleans.

    To communicate with strings, use messages.

    You can send mouse inputs as strings through messages, like how noahboy described. Or you can send mouse inputs as numbers, as described in the multiplayer tutorial part 4. This has the advantage of being lighter in bandwidth and can take advantage of the built in interpolation feature.

    The normal flow of peer to peer multiplayer communication is as follows: A peer sends it's inputs to the host. The host processes these inputs, makes changes, and syncs the changes back to all the peers.

    In the meantime, to hide latency, the peer who sent the input will show the change on their own screen immediately, before getting what actually happened from the host. This is called local input prediction. After the true state of everything arrives from the host, differences are corrected.

    These are all concepts covered in the multiplayer tutorials. If you don't have a decent grasp understanding everything that is done in the tutorials, making a multiplayer game will be exceedingly difficult. So do go through all the tutorials, even if you're not making a real time multiplayer top down shooter.

    For example, given that you want a host authoritative design, a peer would never try to tell the host "I chopped this tree down". The peer only says "I clicked here", and the host would reply "You clicked on a tree, this is the tree's new life", and sync the fact that happened to all the peers.

  • A dedicated server is any computer that stays on and connected to the internet.

    If you were using the included multiplayer plugin for peer to peer, all the server would need is to be able to open a browser. Any desktop environment running Windows，Linux, or MacOS can do this.

    Would it need DB integration? Maybe. Do you need DB integration? You can build your own DB in an array. If all you need is a DB, you might not even need multiplayer at all. Each player can just communicate with the DB directly and not with each other. You can interact with a MySQL database through PHP with the ajax plugin. This database could be hosted on any normal website server. Or you can just save to local storage on the host machine.

    Do you need remote access and control? Most desktop environments can be accessed through vnc software.

    If you have no idea what you're doing, you're probably best off using a third party backend service like Photon or gamesparks or playfab ect.

  • Just because it is peer to peer, doesn't mean you can't have a server.

    You would have a dedicated server join first to take the role of the host, and always leave it on.