oosyrag's Forum Posts

  • First up, avoid using gestures - they are kinda finicky and not very responsive. I'd recommend using the conditions under "touch" instead.

    You can't put else after a trigger, but you can after a normal condition like "is touching object" ('x' is the shortcut to create an else event). However, note that you won't want it as a subevent of event 2 the way you have it now. Since touching the sprite will set the animation to 1, event 2 will no longer be true and it's subevents won't run.

    Alternatively, since the entire event sheet will run every tick top to bottom, you can do something like 'every tick - set animation to 0', and after it, have your event that changes it to 1 when touching the sprite.

    What do you mean by fitting the scene on your screen?

    The viewport, within the dotted line, will be your visible screen when exported. You might need to zoom the layout editor out to see it (shortcut: ctrl-mousewheel), since you've set it to be about the same size as a normal monitor's resolution.

    As for general advice... read the manual.

    construct.net/en/make-games/manuals/construct-3

    It's actually not that long! At least read up through the tips and guides sections, the rest of it is just references and details for how all the behaviors and plugins work. I've found the documentation for Construct to be fantastic in that it's very clear, concise, and complete.

    For a more hands on introduction, follow the official beginners tutorials. There are two, and I'd recommend going through both of them.

    construct.net/en/tutorials/beginners-guide-to-construct-3-1

    construct.net/en/tutorials/platformer-game-2329

  • I once had the idea it would be pretty nifty to have a "50 events or less" game jam. I recall Scirra had run some contests in the past with licenses as prizes.

    If you know what you're doing and make good use of behaviors and conditional expressions, I'd say pretty much any classic arcade game could be recreated in 50 events or less.

  • When you mirror a sprite, there is a possibility the collision box will shift, as is the case when the origin is not centered. This can potentially cause trigger once to reset as it is no longer colliding.

    The reason it happened in this situation is because the higher frame rate allowed for smaller steps, where your sprite just collided by a fraction of a pixel and it gets mirrored, thus exiting the collision state. Lower framerates would result in the collision being more than a pixel overlap, so even when mirroring it didn't matter as your origin was only off by a fraction of a pixel.

    Common practice for platformers is to use a rectangular invisible helper sprite as your base object for collision purposes, and pin the visible texture/sprite to it. This helps to minimize many potential collision issues.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Does it happen if you don't mirror the sprite?

  • Start with the beginner tutorials, read the manual.

    You can also check out the monk fight example built in to construct 3. A quick Google search also fonts up with a few video tutorials.

  • I'd say 500mb is pretty safe in recent devices within 5 years, outside the absolute bare bones lowest end budget devices.

  • Hmm that's a rough one to diagnose, as I don't really have a way to replicate it. Sorry!

  • I don't think there is a way to limit the refresh rate afaik.

    However, if you properly used dt everywhere you're supposed to it should not matter. If you're having situations where a high refresh rate is affecting your gameplay, low framerate on a low end device would presumably also result in problems.

    Triggers should still work properly. Collisions for fast moving objects normally have more issues with lower framerates when more pixels are skipped, but that should not be an issue with stepping enabled.

    Note that you don't want to use dt with behaviors. Behaviors (except physics) already use dt, so if you use dt expressions to control behaviors, you'll actually make them framerate dependent again.

  • You use animations with invisible helper sprites as hit and hurt boxes.

    Spawn and size the boxes depending on the animation frame, and on collision play the relevant resulting animation.

  • 1000x1000 is massive. What is your target device? A standard HD screen is only 1080 pixels tall. Does your main character usually fill up the entire screen from top to bottom? There is no point in having a sprite that large if you're going to scale it down anyway. Standard practice is to create your sprites the same size as you plan on displaying them, or upscale them if memory is expected to be an issue. There is usually no reason to downscale, as it is a huge waste of resources.

    When you debug a layout, one of the lines under "performance" is estimated memory use. It's not exactly accurate but it can give a general idea, especially relative to other projects. You can try loading up the example projects to see how much memory they use on any given layout.

    Here are some additional links for memory management.

    construct.net/en/make-games/manuals/construct-3/tips-and-guides/memory-usage

    construct.net/en/blogs/construct-official-blog-1/remember-not-waste-memory-796

  • It can be, but running out of vram usually involves long loading times or crashes rather than low fps. How big are your textures and estimated vram use?

    Otherwise - construct.net/en/make-games/manuals/construct-3/tips-and-guides/performance-tips

  • An example made for someone else, but I believe it should give you a rough idea of how to approach your question.

    dropbox.com/s/od4zgfohtuaqugy/compareorder_example.c3p

  • You can set the Fullscreen scaling property from high to low as a system action.

    You can use the sprite action load by url.

    Or you can make a duplicate layout with the low resolution textures.

    The system memory management tools can also be of use.

    The latter three are most likely more work than it is worth, when you could just design your game with appropriate specifications for your target device in the first place.

    Also note that lowering texture/vram use won't get you "better performance" anyways, depending on how you define performance. If your game is running slow in terms of fps, Vram usage is probably not your problem.

  • + Sprite: Platform is jumping

    -> Sprite: Set animation to "run" (play from current frame)