lennaert's Recent Forum Activity

  • 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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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)

  • 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

  • this is 1 awesome game, dident laughed so much for long time,really enjoyd it:D need more optimization for sure:D

    hehe, yes, same here !!!!

    was awesome

    I'll look into performance for the next updates too

  • lennaert how do you create such smooth movement between all peers? D:

    Also, would you mind sharing how floors work? I'm trying to get the hang of 2.5D in multiplayer and while I think I've got the theory down, I've yet to try implementing it.

    Hey DatapawWolf

    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)

    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.

    My host and peer event sheets are tiny compared to my common events sheet.

    (host 100 events, peer 50 events, common 500 events)

    Wall is also member of level objects

    I named my layers to: level0, level1, level2

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

  • good game

    Hey man, thanks for testing.

    I have been busy the last month working on lots of updates for TankWars 2.

    Here is an updated version

    *top post updated

    I have been making lots of progress.

    Still working on various updates, better speed manipulation, new touch screen controls, joystick, social logins, and stats keeping offline.

    If you run into bugs, try a reconnect or exit and try again.

    Web RTC can be iffy

  • Progress.

    *top post updated

  • >

    > Your multiplayer isnt really mutliplayer ... well, it is .. but its multiplayer in 1 screen ... not Everade's intention I believe.

    >

    > Here is a tip: Preview your multiplayer game in chrome, and press CTRL + Shift + N

    > A new Incognito chrome pops up, enter the same adres ie localhost:50000 and voila, 2 screens showing your game as a multiplayer game.

    > When you navigate the host or peer in one screen, it should also do that in the other screen.

    >

    > lennaert: You are right, it is not a true multiplayer, but it shows you the solution for walking through objects being one floor above, while the upper player is colliding. I am quite sure, that easily can be implemented in a split-screen or online or whatever multiplayer-kind.

    Thank you for the indeed very useful tip! Never did any real multiplayer before, I'm going to check it out.

    MultipleChoice

    Your welcome

    In a split screen scenario, you can easily manipulate and rely on everything, as you have control over everything, but as soon as it involves another instance of a game, in need of relaying information back and forth, and namely, such as we encountered here, the restrictions, its quite the challenge.

  • It took me a bit of headache hahah, but I think Ive nailed it now ... again, the power came from simplicity ...

    Weird really, every time I run into something that takes way too long to develop, I find myself adding tons of booleans, vars, objects and what not .... just to get 1 thing working lol

    Generally taking a step back and looking at it a day later helps enormously.

    dropbox updated

    90% of the solution was in the approach, where I tried manipulating the objects, all I had to do was manipulate the player.

    MultipleChoice

    Your multiplayer isnt really mutliplayer ... well, it is .. but its multiplayer in 1 screen ... not Everade's intention I believe.

    Here is a tip: Preview your multiplayer game in chrome, and press CTRL + Shift + N

    A new Incognito chrome pops up, enter the same adres ie localhost:50000 and voila, 2 screens showing your game as a multiplayer game.

    When you navigate the host or peer in one screen, it should also do that in the other screen.

lennaert's avatar

lennaert

Early Adopter

Member since 8 Oct, 2013

Twitter
lennaert has 13 followers

Connect with lennaert

lennaerthohe.nl

Trophy Case

  • 11-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
  • x5
    Popular Game One of your games has over 1,000 players
  • Famous Game One of your games has over 10,000 players
  • x2
    Coach One of your tutorials has over 1,000 readers
  • Educator One of your tutorials has over 10,000 readers
  • 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
  • RTFM Read the fabulous manual
  • x2
    Great Comment One of your comments gets 3 upvotes
  • Delicious Comment One of your comments gets 10 upvotes
  • Email Verified

Progress

25/44
How to earn trophies