How do I optimise large layout with many instances?

0 favourites
  • On the beginning, I read a lot on this forum and scirra page about game optimisation and here no solution for my project or maybe I am doing something wrong.

    I have relative large layout with a lot of instances. Main problem is much more over 400 objects with solid state, where game checking colision. We can say, this is some kind of simple open world game, but not exactly. I have ultra simple sprites and graphic, so visuals no matter for fps. Game is slow because sprite placing and colision checking only.

    I tried to disable off screen objects (solid, colision and visiblity). And here go problems well known. However it working in theory, but big loop (object disable/enable) making fps even worse. And without "optimisation" like this it working also bad, not acceptable. I know how to disable/enable objects off screen or over some distance. This is no problem. Problem is, how slow it working.

    My question is:

    * Is possible to efficiently optimise C2 game with over 400 instances, where most of are always off screen?

    * Is possible to do it in free version, just for checking how it works and whether I should stay with my project on Construct 2/html5 or not?

    * If yes - how?

    I have some kind of large maze game, so here must be a lot of colision checks. It is possible to do it in Construct 2?

    Thank you.

  • Hi Facet,

    it's hard work to find it all out, but possible in all these forums and documentations, tutorials. There are great guide here!

    First of all with families and collision-checks, you can take a look at this: download/file.php?id=10965

    (see post here: isometric-multiple-floors_t121850?start=30)

    I managed to reduce a lot of collisions here, not done yet. You have to be really informed and clever and read a lot, but I managed to work my way through in the past.

    Anyone, who can enhance the list with tips, you are very welcome to do so!

    Reducing collisions (collision checks) hardcore:

    • reduce not just off screen objects, but also objects further away then a specific distance > n, take care though, if you are too low, you might skip the object without colliding, if frame rate drops too much
    • disable not just collisions, but solid behavior as well. Since if you don't, your platform/8-dir-movement behavior gonna check ALL SOLIDS all the time. (since that's what they have to do to work as such on). Collisions also are good to be disabled, since when you check for collisions, they still count, if collision is on. so solid and collisions both on disabled, is important!
    • Turn off also solid engines, platform, 8-dir behaviors (all properly, not just ignore input set disabled, even here collision off, turn it on if you are in the appropriate distance, as described) or path finding (do that as rarely, as needed) and switch on, when approximately needed.
    • Destroy all objects you don't need. Maybe at the beginning already, stuff you need for structure, layout, but not in the game, or just at the very start.

    Use any collision-check-events wisely:

    (like "on collision", "when overlapping" (checks every tick for collision, a killer)

    • Try to abandon unnecessary collision checks, e.g with approximately round (e.g. hexagon) objects, where you can check distance, or squares, where you can compare the "CollsionBox" as coordinates
    • In your code, if you have the exact same collision check twice, it checks twice, thus multiplying your collision checks with times two each tick.. which is a lot.. usually, you should have a transparent object-oriented architecture, but in this case reduce all possible collisions you need to just one event each tick!

    ____________________________________________

    • also place them at the end of your chains, so instead of starting with "player > on collision with Object "wall", if "wall.LayerNumber=player.LayerNumber" rather "Wall.LayerNumber=player.LayerNumber" first, then "player > on collision with Object "Wall". This way, you reduce the objects actually getting checked for collisions. If you have a good chain, (with screen, distance and other conditions you can narrow down the selected possible colliding objects) you can have 2-3 collisions instead of 100.

    NOTE TO THE LAST ENTRY: I just read this, but to be honest, it was written for 155.. I am not sure, since I managed to reduce the displayed collision checks by a lot, and I am quite sure, it helped. Of course you need to be careful... Anyone knows about this more specifically? Now I'm confused <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

    ____________________________________________

    Try all that, first the easyest thing, and you will lick blood <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";)" title="Wink"> Like I did. Ending up with only 10% of the previous collision-checks, than before my optimizing trip (on this game actually: http://www.exitthegame.eu (you can skip through the levels with CTRL+ALT+SHIFT+N, pressed in game level. TAKE A LOOK AT LEVEL 12!)

    Though its not optimal, since I would start completely different today, it was my first game ever.. so I suffered badly with collision check. Used to have over 100.000, peaks even 200-300.000, managed to lower it down to around 1200, peaks at 2800-3500. But I have physics (also checking for each possible collision, multiplying), rocks (platform behavior 5 rocks is nearly 5 times the check), other players running around...

    Additional general advices:

    • Use in general rather tile maps, also background tiles, where you can do that instead of placing multiple sprites as a tile (like I did in exit mostly). Try to redraw everything only when needed with e. g. trigger once (instead of every tick, also the case, if condition left empty)
    • Avoid huge transparent stuff overlaying other things...
    • Set your background-layer "clear background"-option to "No", pixel rounding on (interpolation to point) helps as well (but is problematic)...

    Well, that's it for the first.. I might add some things, if I remember anything else, but that's pretty much I know <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";)" title="Wink">

    Kyatric : You seem to be a crack, and might correct me easily, or give us some more tips on the fly? Wanna loose bad habits and learn <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";)" title="Wink"> Please take a look. Thanks!

    Hope it helps. If you have any further questions to this, just ask.

  • Thank you for your extensive reply! I must study it more now. Some ideas I like very, however, with disabling not needed instances is still same problem - huge loop for checkind what shoule be solid, what not. Maybe js is just too slow for games like this, but I will work on it more.

    Thank you!

  • @Facet : [quote:4ip79otq]huge loop for checkind what shoule be solid, what not

    well, if you have all stuff disabled at start, and just start selecting the ones, where collision is actually on, then checking, if they are off-screen, actually not at all

  • I had all the journey like for half a year studying this. If you think, something does not work or dos not help, or you cant solve it, you know where to find me

    I would have loved to have help.. I had to read this all and try out, test on phnes so on. But it helped massively, so don'T worry too much. How man collision checks do you have so far?

  • I will ask you for sure!

    I have over 400 wall object, different shape/size. And some "furnitures" also need colision check. On screen I have maybe 3 dozens of instances only or mosty less, and sprites are very simple, all on grid, collision polygons are square in 50% and all convex with 45 degree lines only if not 90. Basic cell size is 8px, but game size (windows size) is 320x192px only.

    I must try some of your ideas and I will ask more

  • If you run your preview as "Debug layout" , you can see the collisions there. also polygon-checks. very useful for your task, keep an eye on that!

    So what do you have there? Like a rough number? maybe a screenshot is easyest, of that part of the screen is enough

  • Here is:

    You can see here 0 colision checks per tick. When "player" not moving I see zero, when walking, I have max 32 ~3 per tick.

    Anyway, fps is bad. I am testing it on slow laptop, but on my device, Nokia 1020, 2x 1.2 cpu is better and with WebGL, but not so much better. My target is to run it smoth on this old laptop, on sceen realy simple graphic, so in theory it should. In theory....

  • and here goes layout:

    and here sample what is visible on device/window. Lights no matter for peformance or not important (some "lights" shifted here, just for show.

  • Facet nice dude, keep me up to date how all this works out, I would love to test it

    Okay, then collisions might not be the issue that much, I have like 900 up to 1500 objects how does that run on your system? If that runs smooth or okay, then that is not your issue.

    Also try another browser, and also uploading your game, don't run locally. Or try Web-Nod, also faster. In general seems chrome to be the smoothest way to play.

    But hen most likely it is rather the redrawing end effects slowing it down a lot. Try not to use any fx... they are also fps hungry -- I know, they are tempting, but don't work on all browsers anyhow... (at least some look pretty ugly in some browsers)

    Are you scrolling your map all the time? Maybe you can do map-areas, only scrolling, when you reach the edge of the screen. Since scrolling means all objects have to be positioned and redrawn.

  • MultipleChoice

    I can't send pm yet, so hit me on camerapassion gmail com

  • > Facet nice dude, keep me up to date how all this works out, I would love to test it

    Okay, then collisions might not be the issue that much, I have like 900 up to 1500 objects how does that run on your system? If that runs smooth or okay, then that is not your issue.

    On my old laptop, depending on window size is slow or very slow. On my phone, Nokia 1020 I have 45 to 60 fps, but here no enemies, items and action yet

    Also try another browser, and also uploading your game, don't run locally. Or try Web-Nod, also faster. In general seems chrome to be the smoothest way to play.

    I have it online, testing also on real device. I know, some differences here, but not significant.

    But hen most likely it is rather the redrawing end effects slowing it down a lot. Try not to use any fx... they are also fps hungry -- I know, they are tempting, but don't work on all browsers anyhow... (at least some look pretty ugly in some browsers)

    No fx yet, but I want some in future

    Are you scrolling your map all the time? Maybe you can do map-areas, only scrolling, when you reach the edge of the screen. Since scrolling means all objects have to be positioned and redrawn.

    Yes, is scrolling with player. This is game idea, so will be hard to change it ;P

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Sent a Mail, lets talk soon.. I need to sleep now :/

  • on the debugscreen it says your running in canvas 2d mode, that is probably the biggest issue

  • vtrix yes, but as I said, I tested it also in webgl on device and is too slow.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)