lennaert's Forum Posts

  • Wait, my players have to be *on the same layout*? This is a huge, huge problem.

    My plan for multiplayer (a zelda-y world that players can move freely around in) was:

    -Every screen of the world is a separate layout (makes life easy in a number of ways)

    -Players only sync data with other players in the same layout as them (so if you're the only player in a given layout, you're not syncing with anyone)

    -Global world variables (is it day or night? Are there orcs attacking the castle?) sync globally once every five seconds (for low bandwidth consumption)

    This seems like it would be low data while still allowing the feeling of a 'permanent' world (with most things including character save data handled by the client, at least at first, I'm not a professional operation I don't feel the need to move everything server-side).

    But according to what you're saying, this extremely simple vision would be impossible?!

    Ugh.

    No your players do not have to be on the same layout.

    As long as you do not want a single host determining everything, you should be in the clear.

    ATM it is like, every single layout, requires at least 1 host. Be it peer or a 'super host'

    —, how about writing up your own javascript version of the server side, and use node.js with the web RTC module to communicate with the peers ?

    That should be definitely possible, and , if your any good at programming, you can make the host run without the need of a browser.

    You would just have to write up the host side of things in a code only set up. Tough, do-able though.

  • lennart I don't want to have multiple tabs open OR have palyers acting as the server in any way at all. The game isn't specifically for 2 people either. I don't know how many people will be in the game and what maps they will be on.

    Even if you have a server running a single tab in a browser ... isnt it capped with connections ?

    I believe the browser has 256 soft cap on connections, not sure how it is with webrtc.

    I am guessing is that if you want to have a single server running something as host, you will have game instances around that number per window.

    I think the smartest approach with this is to have to have players act as a host for a rooms where other peers can join.

    Thats how the mechanic of the current plug in is set up and works fine.

    You can toy around with instance names and room names and find nice ways to manipulate them to simulate some sort of world with entries and exits everywhere leading you to another layout where you automatically join existing rooms or create on one the fly.

  • layouts as levels.

    a sprite somewhere, which is the entrance to the cave, .. upon overlaps, set room name cave_layout, autojoin room.

    Another player pops over the sprite, room name set to cave, and pops in the cave as well joining whoever joined it first.

    Would not require a server, just a player indicating an available room.

    Say you want to make it a quest requiring 2 players ..

    player overlapping cave sprite entrance, set boolean on cave entrance

    pick players cave entrace boolean true

    picked count = 2

    for each player boolean cave entrance is true send tag entercave message "caveroomname"

    on message received "entercave", set room name to multiplayer.message, autojoin room

    voila 2 man enter for quest

  • Use peer messaging peers for commands/controls

    Eliminating Host control / logic needed.

    Only use host functions to determine active rooms so players can join.

    Effectively one of the peers would still be host, but would not be fulfilling host duties.

    You can use ajax / php / mysql to store various info.

    Chop up huge layouts into smaller.

    Switching layouts is basicalyl just loading a new layout once all players are already in the room.

    Upon loading the new layout, all players get created again.

    Just make some back and forth checks if all the players are on the new layout and ready.

  • Add second instance variable, indicating which click/touch cycle it is in.

    Have a global or dedicated object var increment upon releasing mouse button or on touch end, combine with the add 1 to age, and you will have have sets of ages.

    on touch/click end add 1 to global var clickcycle.

    on line create, add 1 to line.age, plus set line.clickcycle to clickcycle.

  • You do not have permission to view this post

  • Check around for rex plugin manager.

    It has lots of plugins and behaviors able to be added through the manager .

  • All definitely possible.

    But, I will carefully say to not underestimate the skills needed to create any game with any tool or code.

    It generally requires experience and or lots of trial and error work.

    As for coding, I could easily make a similar game like ghost with a bit of html and php.

  • Just give them instance variables.

    ie

    line1.linenum

    linenum instances variables could be 1,2,3,4,5,6,7,8 etc

    And for the other matter

    Add pathfinding to the vars

    searchvariable = 1

    function "findpath"

    event

    pick all line1,

    pick by eval line1.linenum = searchvariable

    action

    find path line1.X line1.Y

    event

    on path arrived

    action

    add 1 to searchvariable

    call "findpath"

    event

    on path found

    action move along path

    Simply call "findpath"

    and it will find paths to the line1's in consecutive order based on their instance variables

  • From the top of my head, If you have a square layout, you could perhaps use the scaling.

    Every Tick

    set layoutscale = lerp(layoutscale, 1 - (distance(layoutwidth/2,layoutheight/2,player.x,player.y) / layoutwidth), 1*dt)

    This can be applied to layers too.

    Near the same as fisholith said, but with lerping (smoothing) and easily applied

  • Multiplayer is actually easier then it appears, one quickly can get lost on who is telling who what to do ..... (I did lots of times )

    Signalling (not signal server) is actually just a small part, its the same as sending a message to all peers and have them set a state as the host sets it himself.

    Lots of times when I made a bug, it was because I was having actions performed twice due to sending info around too much.

    keep in mind:

    peer sent message to host to be broadcasted to all: perform action on peer, sent message to host

    host receives message from peer to relay to all: host performs action (same as peer just did) and sents a broadcast with information to all peers

    all peers (NOT! the original sender) : should receive the message and perform needed actions the original sender and host just did.

    Effectively, 1 action is performed 3 times. You, host and all other peers (not host and not you, because those 2 already did it)

    This process is about the same for every other aspect in a multiplayer game where you want a peers action/setting to be synched with all outside of the sync var functionality.

    Now with a bit of smart approaching, you can stuff near all general actions in 1 big for each peers loop in the common sheet, and have every body tell one another what their states are. Based on these states the loop performs needed actions for all the players (host and peers).

    big tip:

    when making sent and broadcast messages, becarefull with textuall content, also with their naming tags.

    just imagine

    Tag names:

    "ThisIsABigTextActingAsTheTagTitleToSentInfoToPeers"

    v.s.

    "tp"

    The tags are sent along too, the bigger/longer the names, the more data needs to be submitted, more overhead.

    Or

    message content:

    tag: "PlayerDied"

    message: "The player has died in a horrible way"

    v.s.

    tag: "pd"

    message: "1"

    event:

    on peer message received "pd"

    action

    set text "player has died in a horrible way"

    In the second example, the text is taken from the event sheet, in contrast to sending it along.

    its like a couple K bytes vs several bytes.

  • One way would be to have the host determine their values.

    Use sync variable and leave the client tag empty "" and do not add a client input value tag.

    This will force the value of the var to be the same as the host vars

    Now its just a matter of informing the host of what your value is (sent message with info to host, host sets variable based on that)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Not dying, or wrong player dying: Add a for each to the hosts event sheet for the health check.

    ie

    for each peer

    peer health <=0

    Also, you should add some checks whether or not either of the players are allowed to control their elements, who knows, either of them could be dead while they are pressing the buttons

    Also, I have found that container elements referencing not always work in a multiplayer scenario, so I give everything IDs and use those as references for peers tied objects.

    Also, you have an AI calling the destroy, which is processed on peer and host, and only host processes the re-position.

    Would be nicer, to have the peer and host process half, peer sent message waiting for re-positioning, wait for a signal from host for replacement ready, then continue to replace the peer and set visible etc.

    A bit of ping pong to verify the next action

  • In my skeleton slayer 2 game in the arcade, if you get halfway through the game, it changes to a platformer game for 1 level to cross over between two top down view layouts,

    So yes, it is definitely possible.

  • lennaert

    > The floors just required a smart approach to them, lots of knowing when 'not' to invoke something combined with a couple else's in the right order. (image below of floor leveling collisions core)

    > hanks for the screenshot.

    > As to the multiplayer, I spent weeks on end working out the mechanics and best approaches ... and in the end I managed quite well.

    >

    > -Knowing what to execute by who (host/peer/both) really makes a difference.

    > -As few datasynchs as possible with a smart approach to movement.

    > o you still keep the host authoritative of all connected peers?

    The host does the handling of the common rocket tank rockets and the tank shells impacts.

    The host and peer both have restrictive properties and functionality in the common events.

    Such as the level collisions core, it runs in a big for each playertanks loop.

    Part of the smooth movements ... if you steer ... your need to steer everywhere host, yourself, other peers

    When you tell the host to move, make sure to move yourself too on the peer, so the updates from the host back to you do not have that high of an impact as you were already in the right direction yourself

    The peers and the host each have the same map, and both can make use of its properties to run things smoother.

    Most of the level problems arise when you are determining restrictions for others.

    > I named my layers to: level0, level1, level2

    > Referencing them like move to layer: "level"&playertanks.activelevel

    > hat's what I have so far, except "floor0, floor1, etc."

    You have to start somewhere

    One of the more daring issues with "being on a floor" .. is having everyone determine where you and they are on when they begin/die/restart etc