oosyrag's Forum Posts

  • One of the simplest ways would be to make it invisible while overlapping your player sprite, else visible.

  • If your want a more robust system, you'll probably want to use an array to keep track of all inputs in order and base most your event conditions off of that array.

  • Are they button objects or sprites?

    If they are button objects, are you using css styling?

    Button objects are html elements, so they have the possibility of being rendered differently depending on the browser. You can have more control over their appearance by using CSS, or better yet use a sprite object.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You can do it pretty much as you described.

    When conditions met for a buffer able input, start a timer.

    On action finished and is timer running，do buffered action.

  • You're going to need to give more information to get help.

    For example, if you mentioned what tutorial you tried to follow and show what you ended up with, someone would be able to say why it's not working.

    Construct tutorials generally do not get outdated even from C2 to C3, so you don't have to worry about old tutorials. Even if there is a new feature that might make things easier, backwards compatibility is usually still there.

    There's also many ways to do a particular thing so it helps to be specific. Here's one that uses tiles, which may or may not be relevant to you.

    howtoconstructdemos.com/push-objects-in-tile-based-game-sokoban-style

    Multiplayer adds additional complexity. If someone gets pushed do they lose control of their character for the duration? What happens if there is a conflict? It's best to work on your mechanics one at a time.

  • From a memory management standpoint, different tilesets are what layouts are designed for. If you use different layouts, you won't have to keep all the currently unused textures in memory. You'll then be able to load a lot more/bigger/nicer textures per any given layout.

    Note you can use the same event sheet for all of your layouts, while season specific events can check a simple variable that keeps track of the season as a condition.

    Multiplying the layouts by 4 doesn't seem like much additional work to me, considering you want different seasons to begin with and I'm assuming you don't want the seasons to look the same. That means the 4 sets of different graphical assets have to be made anyway, which is the bulk of the work.

    As for setting up the map 4 times, I believe you can just copy and paste the painted tilemap object and just change the tilemap source image, assuming your 4 season source images use the same tile layout. You'd probably want to use a program like Tiled to build those maps. As an advantage, having them separate allows for individual changes to the map itself for each of the seasons as well.

  • If you want it to look good, you're probably going to have to put the effort in to color night time separately.

    Proper night time visuals generally are not just daytime visuals with a filter on top.

    Edit:

    If you're using an effect mask and isolating it, try turning on the "Force own texture" property on the layer you are applying the mask to.

  • From what I remember of FF6 classic and the one video I could find of atma weapon dying, the boss death animation is a combination of a color tint, fade out, and shaking. Also the flash of white, which can also be achieved with a color tint effect.

    Here's another dissolve type effect I made an example of before, based on the Undertale style. construct.net/en/forum/construct-3/how-do-i-8/dust-effect-monster-dies-157891

  • Based on my understanding, the actions in that event is exactly what the Construct does regardless of if you have the load layout images action there or not.

    When changing layouts, the engine will load all images on that layout into memory.

    The key is, if there are no instances of a particular object placed on that layout in the layout editor, it will not load (I think), even if you have the loat layout images into memory action. If that object is then created later, it needs to be loaded at that time.

    So if you create a lot of objects on a layout that you didn't place in the editor, the engine did not know to load those ahead of time when switching layouts.

  • Try adding an instance of each the objects you are creating in the layout editor. You can delete these placeholder objects on start of layout.

    As long as there is a single instance of an object on any given layout, I believe that object's textures will be preloaded into memory before the layout starts. If you create an object via events that was originally not on the layout, then it has to load it into memory then and there.

  • You would put it in a Tween is running condition.

  • You can use the tween value action instead of tween property, and then the set scale action with the tween.value expression to get the result you want.

  • It sounds like you wouldn't need pathfinding at all for your original approach, since they're ignoring the walls and attacking through them anyway. You would used a fixed path with moveto and maybe invisible helper sprites as waypoints in that case.