Ashley's Forum Posts

  • The most efficient way to do rain is to re-position raindrops back to the top when they go off the bottom of the screen. Then you never actually create or destroy any objects, you just cycle round the same few.

    Obviously if you regularly create objects and never destroy them, you will fill up memory and the game will grind to a halt.

  • Any images or sounds not added in the Construct 2 editor are not included in the offline cache, because there's no way for the editor to know about them. Therefore any images you request are not guaranteed to be saved anywhere. This means you could play the game 3 times in a row and it re-downloads the images every time, or if you go offline then the game fails to run at all. It's best where possible to keep all resources within the Construct 2 editor itself so they can be properly cached and loaded offline.

    The best tips to reduce file size are probably the image-related parts from this guide: https://www.scirra.com/tutorials/577/construct-2s-export-time-optimisations

    In particular:

    • duplicate images don't matter, they're deduplicated on export
    • spritesheeting can help compress away similar parts of animations
    • images with <256 colors will automatically be recompressed to much smaller PNG-8
    • use Construct 2's Image Format dialog to manually select JPEG or PNG-8 where appropriate

    Selecting JPEG on backgrounds alone can massively reduce the file size.

    Don't trust Construct 2's 'estimated download size' too much. Everything that happens on export is so complex that it's impossible to accurately predict what it will result, so for best results from time to time you should actually export the project and see how big it ends up.

    Note this is specifically to do with the download size, not memory use. Don't get them confused! Although they tend to roughly correlate, it is not helpful to be looking at memory use if you're actually trying to measure the download size. A0Nasser posted a screenshot of the debugger which only shows memory use and won't tell you anything about the file size.

  • No, from what you've described you don't know what those terms actually are. Interpolation is estimating mid-points between two known values. Input prediction is where you move the local player immediately without waiting for the authoritative host response, and reconcile their position when the host response is later received, thereby preventing cheating whilst removing the round trip latency on the peer's movements. We already did loads of testing with our multiplayer engine over realistic (and often unreliable) Internet connections and without those features the game will perform very poorly and be easily hackable. If something runs well locally it says nothing of how it will run when a player in the US is connected to a player in the EU.

  • You should probably post these as bug reports with repro .capxs made from scratch that clearly demonstrate the problem.

  • Since computers are deterministic, "genuinely random" data needs to come from outside the system. There are specialist hardware devices for this, or you could use a service like random.org, or you could just ask the user to wave their mouse around randomly and then use that as your data (which I've seen other apps do).

  • It sounds like you fundamentally misunderstand how networking programming works. I would strongly discourage you from publishing a plugin until you have a better grasp of the problems of real-time multi-peer networking, and I especially strongly discourage you from encouraging other users to design games like this, because it is absolutely the wrong way to design multiplayer games.

  • troublesum - what, so you don't even implement interpolation or input prediction? Have you actually tested that over a real-world connection?

  • Closing as not a bug, it's just an ordinary floating-point rendering seam. Use letterbox integer scale, pixel rounding and point sampling, or low-quality fullscreen mode, or slightly overlap objects, to get a seamless display.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I'm not sure alpha-videos are widely supported - I don't think there are many video editing tools and encoders that are alpha-aware, and I don't think h.264 supports alpha videos either, so that means IE and Safari wouldn't show transparency.

    In general I'd advise sprites for in-game playable objects, and video for anything that is, well, a video - like cutscenes, short clips, background TVs, etc.

  • Attach a .capx. I'd tested it on Android and iOS and video successfully played providing you touched the screen.

  • Construct 2 attaches normal context menu events. Is the surface pen actually designed to fire context menu events or does it do something else?

  • Closing, please follow the bug report guidelines. "Do something else" is not a step we can do to precisely follow what you are doing, and you did not attach a .capx.

  • Yes, just comma separate them.

  • It's easy to test this yourself with events and see how it works. But yes, the engine fires triggers from the most-deeply-included sheet first, firing on the top level event sheet last. Other events are read normally in top-to-bottom order, and includes are run where they appear in the event sheet.

  • I already gave my reasoning earlier in the thread.