Is Using Large Layouts Viable?

A while back when I first started Viktor, I made the first level into one layout. The level took about 5 minutes to beat, so it was relatively long (maybe 40,000 x 40,000 layout size). I had a friend who had a non web-gl pc to test the game, and his fps was in the low single digits. When I split the entire stage into 10 "mini stages", his fps dramatically improved (to the high teens; low 20s). So my question is this:

If you're not adding more "new" images by creating large layouts and instead reusing 90% of the sprites you're going to have in every mini stage anyway, is there a bad reason to have a super large layout like this? I did a test to see the memory and CPU usage, and the memory usage was virtually the same between the full size layout and the mini layout. The CPU, however, did seem to jump a fair amount (went from 30 to about 60), but I think that's normal given that a lot of sprites, even though being reused, all had sine behaviors, etc.

I personally have no way of testing this because I get 60 fps no matter what, but Viktor had some minor complaints on Steam that would experience certain framerate related issues that were otherwise untestable on my end. I'm assuming due to the fact that some pc gamers don't have a webgl-enabled graphics card.

There's nothing wrong with having large layouts, as long as there is something to manage the entities so that you're not running the entire world all the time ; sprites not on screen still consume CPU time to perform their computations for behaviours, logic, collisions, etc. if these are enabled.

For large levels, you'll want most entities in a "dormant" state, that you activate only when necessary on triggers, or create them as they're about to enter the screen via invisible spawners.

Also, you should be able to test some of that locally, even on a powerful machine, by disabling hardware support, slowing down your CPU, or running CPU-prefkillers that are sometimes used for emulating old software

Refeuh - thanks for the reply. That does make a lot of sense. I tried something similar on Viktor, but ran into problems (probably because of my skill level in terms of coding), but I would "disable" things off screen and then re-enable them when they were on screen. However since there are so many of the same object type on screen simultaneously, it seemed to bug out if it was off screen, on screen, and then off screen again.

Could you technically do a

"For Each Sprite"

if Distance(Sprite X & Y and Player X & Y) < Layoutwidth+500 = ENABLE BEHAVIOR

Else = DISABLE BEHAVIOR

I haven't tried this example directly, but yes, something along this line should work !

Note that if you have entities with "follow"-like behaviours, there's always a risk of the player aggro-ing the entire map, at which point you're back to square one, with the entire world being alive at the same time chasing the player, thus crippling performance.

Which is why most of the time trigger areas are more reliable and robust ; you can activate but also de-activate certain entities when you enter/leave their area.

Also, don't do "for each... distance-check" ; try to see if you can use the built-in sorting and distance-based sorting functionalities of C2. These are likely to run a quick-sort on the squared distance under the hood, which will save you a lot of computations and expensive square-roots. I haven't checked, 'just a guess really.

If you can divide the layout into sections, you could use invisible tiled backgrounds as area sensors. When the player is overlapping a tiled background with an object variable a, with trigger once, set all sprites in area a active. When it's not overlapping the same, with trigger once, set them inactive and set all of their behaviours and collision checks to off to reduce CPU use.

Refeuh - correct me if I'm wrong, but there is no built-in sorting and distance-based functionality other than distance(x,y,x,y)?

I do have entities will follow-like behaviors, but it's as simple as "if x < player.x, follow player > that way". And I'm using line of sight in order to determine whether or not the chasing boolean is active. I could always just disable the platform behavior for enemies until you're close enough to them, though?

Colludium - thanks for the advice. Stupid question, but if an object has no collision events but has collision enabled, is it using any cpu/memory? I'm also wondering if distance between every object will run less cpu than overlapping a tile. I'd imagine at that level it's not a huge difference, but I want to be able to optimize to the fullest extent possible.

I don't believe Canvas 2D has any sort of memory management, which would explain why it ran like crap on your friend's non-webgl computer. Large layouts shouldn't be a problem with WebGL depending on how nuts you go. My bigger layouts in my RPG aren't huge, but still quite large. 12,000x12,000ish with about 11,000 objects. The CPU use isn't particularly low, but it runs very well and has run well enough on every PC I've tried it on.

Colludium - thanks for the advice. Stupid question, but if an object has no collision events but has collision enabled, is it using any cpu/memory? I'm also wondering if distance between every object will run less cpu than overlapping a tile. I'd imagine at that level it's not a huge difference, but I want to be able to optimize to the fullest extent possible.

I don't think any collision checks will be carried out against an object that doesn't have them checked in the events - I'd have to do a quick test to confirm that, though. It will be using memory, but that matters not IMO - it's the cpu time that's going to slow your game down. The collision system in C2 is quite well optimized, including the use of collision cells, so distance between objects will make a difference in a positive way, AFAIK.

Aside from collision checks, you're going to burn cpu time by having any movement behaviors enabled on those objects that the player can't see.

If you last tested your large layout before collision cells were added, it would definitely be worth trying again. They can make a very big difference to the performance of large layouts with lots of collision detection going on.

Ashley - I know for a fact is was before collision cells were added, so I'm sure that'll help immensely.

Colludium - I didn't think it did either, but just wanted to be sure.

C-7 - thanks - that's really good to know, actually!

Also layers can enable "render cells", that might be useful for large layouts too.

So basically there is no limit in layout size, if I handle assets via offscreen-turnoff?

Just wondering, because I thought about some Bear Grills escape from wilderness game a few weeks ago.

Beaverlicious - seems that way. Although one thing to note about construct (might be html, not sure) is that when you create more objects that take up memory, destroying them does nothing to your memory pool until you leave the layout. So if you base everything on a single level, everything you have contained in the level AS WELL as everything you create will be permanently added to the memory pool.

ome6a1717

I was thinking something along the line of :

for each ordered (ascending)

expression : distance^2 , i.e. (x1-x2)*(x1-x2) + (y1-y2)*(y1-y2)

using "Stop loop" as soon as the loop entity is beyond a threshold distance (meaning all other entities after the one in the current iteration are also beyond that value, since the loop is ordered)

I'm not sure you actually gain anything, but at least you rely on the built-in sorting of the "for each ordered", which is likely to be a quick-sort of some kind, and would be faster that using distance() on ALL the entities

You can also run that at a capped framerate below the actual fps, a few hertz would be sufficient to enable/disable entities