oosyrag's Forum Posts

  • Are you familiar with the window size? It determines how much of your layout you see at a time. The window can move around with the scrollto action. The viewport expressions gives you the positions of each side of your window within the layout.

    What you do with this position information is up to you.

  • Scale inner.

  • To be clear, your save game will still work if you update a sprite.

    Best practice: make a test and try it out. Most things will work, some will not.

    If you need more fine grained control, manually pick what and what not to save in localstorage keys.

  • As Lasmelan said:

    Best to not use a function.

    Otherwise, you need a condition to pick the specific missile you want destroyed. There are a few ways to do this, including with uid, but again it is best to not use a function here.

    To use UID - in the event where Missile on collision, you would add an action to set a variable to Missile.UID. Then in the function, you would add a condition to Pick by UID, and reference that variable.

  • What is a player box?

    First idea is to use the pin behavior on your player box to your player sprite.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Define good optimized light system?

  • https://www.scirra.com/tutorials/526/ho ... -savegames

    [quote:32tpu308]'No Save' behavior

    Anything with the No Save behavior will not be saved, and won't be affected when loading. It is good practice to add the No Save behavior to any static objects, such as scenery and backgrounds. It can also be used on automatically-updated objects like the HUD and text objects which are updated every tick. This won't make any difference to the game, but it makes savegames smaller and faster to save and load, since the unnecessary information is omitted. (It's also necessary to make continuous preview work effectively.)

    Changing the project after saving

    Savegames should be robust to changes in your project. You should be able to add, remove and reorder various things like variables, behaviors and other objects, and still have old savegames load successfully. Note however anything new you add won't have save data for it, so will not be affected when loading. Also note if you remove anything from the project it won't be able to load again either. You can delete individual instances without affecting savegames, but if you remove entire object types, layouts or layers, they will never be loaded back from a savegame.

  • I believe you'll need a For Each condition.

    When you don't use For Each, the event will run all actions for all picked objects at once. With For Each, the event will run once for each picked object individually.

  • https://www.scirra.com/tutorials/892/mu ... pts/page-9

    As part of multiplayer design, you want to minimize bandwidth use as much as possible regardless. There is no limit, as each person is on a different connection that can handle different amounts of bandwidth.

  • I hesitate to give a shortcut, because I really, really feel you read through all the multiplayer tutorials, but here is the main design consideration:

    All game logic and mechanics should be handled by the HOST. All PEERS generally only send their inputs to the HOST. The HOST will act based on these inputs received from the PEERS, then SYNC the state of the HOST game/objects to all the PEERS, so that they all have the latest state of the game.

    The other main stumbling block a lot of people have is how to get connected and the concept of SIGNALLING SERVER, GAMES, ROOMS, and who is a HOST/PEER. But this really is generally very straightforward and the same for most games, so if you follow the tutorial it should be very clear. I think people have trouble with it because they didn't really read the tutorial to begin with.

    Regarding starting from scratch - that isn't true! We spend the most time when we run into a mechanics problem that doesn't work right away as we imagine. Once you've figured it out, you won't need to figure it out a second time. Also, you can copy/paste events. When your base game works, all you need to troubleshoot is the sending of messages and communications. It is much more frustrating when you have to debug multiplayer communications at the same time as your game mechanics.

  • Hmm... creating the menu with events is very flexible by nature, there are many ways to do it.

    One way I've done it in the past is just have one menu sprite object with all the menu options as animation frames, with an instance variable MenuItem.

    When the menu is triggered, use a loop to place each menu selection, incrementing the position, animation frame, and MenuItem variable.

    On clicked MenuSprite, compare MenuItem value and do whatever.

    To close the menu, destroy all MenuSprite.

    If you use a For loop, you can control the loopindex numbers for submenus.

  • In addition to that, you may also want a stop loop action so that the event will only run on one instance of the object.

  • Sorry I was unable to determine exactly what is wrong in your particular project as it was heavy for me to figure out, but I think I have an idea what you are looking for...

    I've made a small example that will pick an object when is within a certain range of another, with sub events that differentiate which side it is on.

    You can add trigger once while true if you want the event to run just one time when the two objects come in range.

    https://www.dropbox.com/s/eb23u6823hs9b ... .capx?dl=0

    Hope this helps!

  • Have you gone through the multiplayer tutorials? It is worth spending some time to familiarize yourself with it to have a basis to know what sort of work you will need to put in.

    The multiplayer plugin may seem intimidating at first, but it is actually rather well done and very clean to use provided you actually go through the tutorials and understand what each event is for.

    This will help you judge if you want to proceed with a multiplayer game, and it will let you design with multiplayer architecture in mind.

    On the other hand, I always like to prototype my base game first to make sure it's something I want to keep working on. Even if you had to redo some of the events later for multiplayer, it will be much easier the second time around, and you'll be sure your base game works as intended first. It is much easier to diagnose bugs and problems if you focus on one thing at a time!

  • I think on peer connected, as the peer, will not trigger. It seems like on peer connected is for the host to know when a peer connects. For the peer, I think you want to use On Joined Room.