GenkiGenga's Forum Posts

  • Hey mate sorry for the slow reply.

    What you need to do is, before switching a layout have the host destroy all instances of synced objects (this means the peer has to wait a little bit for the update to get through as well once it is destroyed on the host). Otherwise they can carry over and at times you will have 2 of the same object (I'm guessing this is the cause of your x,y issues but couldn't be sure without looking at your project).

    If you refer to the ghost shooter multiplayer demo, you see you have 3 variables synced - health, kills and deaths. Once synced As long as you are only manipulating those variables on the host side it should be working. Remember you can always bring up the debug and find your zombie objects and check the individual variables for each when dealing with problems like this (will let you know if you have duplicates).

    I'm not sure that you can sync variables for the family object itself (I think i remember reading something a while back, its not something I have tried anyway). If you are doing the above correctly then syncing the zombie object instead may solve the problem.

    Let me know how you go.

  • No worries mate, a pleasure.

    You could sync the power-up and use the host to determine the collision, that would avoid the problem of both of them picking it up - but there will still be times where the peer sees them self pick up the object first but they don't have it (since it goes by what the host sees). There isn't really a perfect solution for peer to peer (other than designing the game around the shortcomings) but it is a small price to pay for a server-less gaming experience.

  • Sounds good for the peer. The challenges you face with this style is collisions. Things like, if you are allowing your peer to move without the host authorizing it and the peer walks over a powerup while the host has done the same thing - who actually picks up the item? Do they both get it?

    Build the game around the limitations for the best experience.

    If that proves to be too much of a problem in the long run what you can do is use the sync with inputs method and add on top of that the peer also has it's own movement (I mentioned that the peer fights for control but with a low latency environment this can be enough to feel like there is no lag on the peer side while maintaining a persistent game state between the two).

    Keep up the good work mate, I look forward to seeing a demo

  • That isn't too bad for that many enemies. The readings come out in bytes so its 1.5 to 3kb per second, seems reasonable to me. A quick bit of research and I found world of warcraft typically uses around 4 times that amount.

    The distance between the players is the biggest concern. You can simulate latency in the multiplayer object, just make sure only to trigger it on the host side.

    Just out of curiosity, how do you have your peer movement set up? 1500 inbound seems a bit high compared to using the sync with client input method (the way it is set up in the ghost shooter demo).

    Not that it is necessarily a bad thing mind you.

  • It is really quite simple once you start playing around with it. There are good examples in the ghost shooter and pong demo.

    Basically on the start of layout you sync objects between the host and peer (playing with the precision to see what you can get away with) and from that point forward those objects will react for the peer as they do for the host.

    For this mini example lets use 'position only'. Once this is done the host can instruct zombies to move and the position will be maintained on the peer side. If the peer tries to have events moving enemies they will constantly be fighting the control of the host's position (and losing). The peer can however still manipulate animations and variables from their side with this setup. Just note that these wont be shared so you will still need the peer to send MP messages when needed to the host letting them know of changes and vice versa.

    You can also sync variables but for the sake of this example lets just leave it at position only. Not much bandwidth needed for updating X and Y positions with today's internet.

    I said it to someone else recently but playing with the demos that are provided is the best way to familiarize yourself with what you can do imo. Change variables etc. See what breaks and what bends.

    Regarding the distance check, Yeah if you want more than one zombie to share the event you need a for each.

    Code it up any way you like (there is a lot of different ways you could approach it) but when in doubt remember that the debug button is your friend. You can go into 'profile view' and see how your logic fairs. Taking up a good percentage of your cpu (time to make some adjustments). If not then I personally wouldn't worry too much.

  • Oh ok, I thought you were having both the host and peer do their own pathing.

    I would think it wouldn't be a problem unless you are syncing over 20-30 enemies at a time, I haven't tested that many though.

    I guess if you were dealing with potentially hundreds you could clump some together and sync a group as one object, breaking them up again when you needed to. Hopefully it wont be an issue for you.

  • Generally I think it is best to allow only the host to control the enemy movements and simply sync those instances with the peer. That way you will always be working with the same game state.

    Have you tried that and disliked the result? You can always do some tricky things to simulate predictable effects on the peers side before waiting for a MP message to make the peer experience better.

    If you were determined to keep it low latency friendly you could always keep what you have and periodically update the positions of enemies through MP messages - just to make sure they stay on predictable paths.

  • Imo, a big factor to it's lack of adoption at the time was that it was still bleeding edge tech. It wasn't widely supported with browsers for a long time (and at the time there was no indication of how long it would take until it would be). It is much better now.

    I too think it could be more user-friendly but at the same time it is just a completely different way of coding things up. A lot of the fundamentals you have been building wont apply here. A 'dummies guide to using the multiplayer object' would definitely help bridge the gap.

    If you are determined, study all four of the introductory tutorials again. Change variables, see how things break or bend. I agree with what Ashley says in the manual, "You are likely to struggle if you try to skip ahead and start making a game without fully understanding how various aspects of multiplayer games work".

    Nothing like jumping in the deep end though once in a while

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The 'wait x seconds' is so powerful for creating long event blocks for beginners but it looks like it is time for you to graduate and start using functions instead.

    The problem is exactly as you have said, once that event runs - conditions can change but since the event block has already started it wont stop and can cause all sorts of issues (I know this from experience, my first game was a mess and insane to debug ).

    'Functions' are events that sit there until they are called into action (using the call function action). Whenever you want to use the wait X, instead of simply adding more events to the chain afterwards we can call a function instead. The major benefit of this is that when that function is called we can once again check with new conditions.

    So, after the wait 0.9 seconds - we call the function 'tumble idle' or whatever you want to call it and part of the condition is that the player's life is >0. If it is not then the function wont run and wont bug your project in the process.

  • Unfortunately when multiplayer released not that many people actually used it which is why it didn't receive more support. Still, what you want to do is achievable and you can learn from studying the multiplayer examples that are there (ghost shooter,pong and chat room).

    For a simpler entry point you can check out my tutorial which focuses on a peer to peer setup.

    https://www.scirra.com/tutorials/1432/g ... ayer-games

  • Ha, that's awesome you got it back. I'm happy for you mate. Sometimes the world works in mysterious ways.

    Look forward to seeing a demo at some point in the future.

  • Hey Sandro,

    You have two settings in the properties section on the left hand side of your project that will help.

    First is pixel rounding (set it to on) and the second is Sampling (set it to point).

  • Well done Jook, I am happy for you mate. Keep up the good work.

  • Kuro, sorry I never responded mate I didn't get a notification. PM me for more details if you are still around and interested.

    Acteran, The market place, bank and tavern areas are currently just sprites. In the dungeon though it is set up so all the walls and floors are interchangeable. This allows you to easily create a massive diversity among rooms based on the floor type and size without spending time manually creating room yourself. You can easily add more assets to increase the variety if you wish.

    This is mostly done to assist beginners and novices, you are free to use the graphics to make a tile-set instead after purchasing if you would like to though.

  • Hey Biff.

    I am guessing they are extremely similar in performance but the debug option will help you be sure.