oosyrag's Forum Posts

  • In your array, you can use a 1 or 0 in each cell to represent if that slot is filled or empty. Check each cell that the item wants to go in and only proceed if all cells are empty.

  • If the size of the inventory is of a reasonable size, I would probably use a brute force guess and check method. Each item of any size should have a "base" tile, for example the top left corner. Then when placing the item in in inventory array, check each additional spot that item requires to fit, and only proceed if all required spots are valid.

    For auto fitting on pickup, you would loop each available slot in the inventory starting with the base tile and checking for validity until it fits or fails.

    Each item should have instance variables to describe it's size either in terms of array positions, or width and height of all items are rectangular.

  • I see. The first thing that comes to mind is simply design your layout with a margin, so your players/cameras can't approach the absolute layout edge, and use your own events to stop them from approaching the layout bounds manually. Basically don't use the bound to layout behavior, make your own.

  • Its hard to ask advice which engine is the easiest to use/learn, because the easiest one will be the one that makes the most sense to YOU.

    Basically if the way the developers set up an engine is similar to how you would do it yourself, it will be incredibly easy to learn and use for you, but not necessarily for someone else. If a highly trained and experienced software engineer were to use an engine like C3, it might be very slow (relatively) for them to get what they want done! On the other hand, for me the flow of logic and events in C3 behaves very much in line with how I would have expected it to, therefore it was very easy to pick up.

    The best way is to try different engines for yourself and see how far/fast you get with each one. It should be pretty clear after a day or so of experimenting.

  • There are a few ways to keep an object in place relative to the viewport. The example currently sets the canvas position relative to the sprite object.

    You can use the anchor behavior on the canvas, put it on a layer with parallax 0, or set position relative to the system viewport expressions.

  • I assumed from your reply that you were not interested in this method so I didn't revisit it. It was a pretty quick modification though.

    dropbox.com/s/p2ilod6sl892gga/splitscreenexample.c3p

  • Set the offset to either 1/4 or 3/4 of the duration of the sine.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Separate your "horizontal" (x,y) movement and your "vertical" (z) position of your sprite. The horizontal position will be a linear tween, while the vertical position will be an additional y offset based on the horizontal position. The vertical motion will start from a velocity of your choosing (delta y, launch speed), which changes by a negative constant every tick (gravity). This should work at any angle/direction you want to go in.

    You can additionally add a size scaling based on your vertical position.

    Edit: I found an old example that had something similar, re-purposed it for this. Can probably be refactored, but you can see the general idea. dropbox.com/s/w2jhdv7oe62gdc4/verticalarc.capx

  • Your best bet is probably to either write to local storage every time you need to make a savable change to data if you're making a stateful game, otherwise just auto save pretty often if you're using the system save action.

  • You'll be interested in this part in particular:

    Offset every object by the difference between player 1 and player 2

    Paste to canvas

    Return objects to original position

    The canvas portion of the screen will show the area around one player, while the normal viewport will show the area around the other.

    I'll make a more usable example later.

  • Syncing needs to happen before the object is spawned. Usually this is done on start of layout, and only needs to be done once.

    For a card game, you don't necessarily need to use the sync feature. A more straightforward method could be to simply send messages between peer and host, and have events on both host and peer side to handle what happens when any given message is received. It will be up to you do keep the host and peers in sync in terms of what is shown, but this is relatively simple to check and implement in a turn based or card game.

    I recommend you to actually follow and complete all four multiplayer tutorials until you can understand everything that is written on the multiplayer plugin's manual page. Implementing multiplayer isn't easy - it basically amounts to making two versions of your game that rely on outside (each other's) inputs.

  • You do not have permission to view this post

  • Maybe I was wrong. Else does always seem to run after loops no matter what. I looked at the example file I made and it looks like I didn't end up using else after a loop after all.

  • Bounce off solids with the bullet behavior will treat corners as rounded.

    LOS ray casting will get you the "real" angle of reflection on collision with solids.