oosyrag's Forum Posts

  • Bullets do not get "blocked" by solids... but you can set them to bounce off solids.

    It doesn't matter what other behaviors you are using, as in this case bullet would be the one taking care of the movement, and it doesn't care that there is a solid in the way. For example, even if I was using 8 direction, if another event decided to move me into the middle of a solid I would still get stuck in it.

    Although..... how do you define blocked? Do you want it to just stop? Or slide along the edge? Stopping is simple, just set bullet speed to 0 upon collision.

  • Ok this was pretty simple. The height of your worm's collision box isn't the height of the entire sprite. It is only the bottom 42 pixels of the sprite... which gives you the 41 number when the bottom of the player sprite starts to overlap the worm's collision box.

  • Checking it out, but first I think I should mention each group takes up an event towards your free edition limitation - you might want to use comments to organize instead. Groups are generally most useful for toggling sets of events active and inactive, so if you're not doing that they don't really serve much purpose.

  • Option 1 - System save and load actions - https://www.scirra.com/tutorials/526/ho ... -savegames

    Option 2 - Localstorage - An entire array or dictionary object holding values you wish to save can be written to a single localstorage key as JSON. That key can be checked on start of layout to see if it exists.

  • Need more details. Or a capx.

  • The entire event sheet will run once per tick. If the conditions are true, those actions will run.

    The exception are triggers (green arrows) which only run once when triggered. You can turn an event into a trigger by adding the "run once while true"condition.

    Edit: here are two very useful articles you may not have found.

    https://www.scirra.com/manual/75/how-events-work

    https://www.scirra.com/blog/141/common- ... nd-gotchas

  • You can set up a time server with the multiplayer plugin. Connect to an always on host, which sends the servers Unix time.

  • How do you have his movement set up to begin with?

  • Why not just allow the user to choose the first time they run your program? You can save the preference to localstorage so it doesn't ask again next time.

  • Doesn't look blurry to me. I think its just a combination of how fast you go and how small the enemies are. Not to mention there are so many similar looking non-enemies.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Problem 1 - Your target is on Layer 0, your background layer, which has parallax. Turn off parallax or move target to another layer to fix.

    Problem 2 - Point sampling with fullscreen scaling (downscaling in this case). Some pixel stars are too small to be displayed, but when you move certain pixels will be displayed and others won't be, which causes the jumpy stars. Change to linear sampling, or use a better background image.

  • Behaves consistently for me, no matter the order of the events.

    When player is "dead" you are setting his vector to upwards every tick, so he never gets around to falling back down.

    The only way he falls is if you hit space twice to toggle the dead state again. In your video you were probably getting inconsistent results because your condition was "space is down", so that would toggle on and off every other tick. Basically if you didn't let go of the space key within one frame, the dead state would toggle off again. In the example file you uploaded it looks like you corrected this already.

  • Use a container, so each enemy has a text/sprite associated with it. When the enemy is picked by conditions, the objects in its container will also be picked.

  • Your conditions don't go in the array (or dictionary would probably be more appropriate). The array/dictionary only serves as a replacement for instance variables to store if an achievement was completed or not.

    Your condition and event to trigger an achievement should be one time only, and when it triggers it will set the corresponding array/dictionary value and that value can be saved forever. You'll still have an event for each accident, which specifies all the conditions to reach the achievement. The state/animation frame of your achievement​ sprites should be based off of your stored value, and you can loop through all of those in a single event to set them.

  • Generally speaking if you want truly infinite, you generate pieces of your background around the edges of your visible viewport as you approach them.