Is Using Large Layouts Viable?

Discussion and feedback on Construct 2

Post » Mon Jan 12, 2015 6:52 pm

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.
B
43
S
12
G
1
Posts: 545
Reputation: 4,246

Post » Mon Jan 12, 2015 7:06 pm

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
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 237
Reputation: 2,232

Post » Tue Jan 13, 2015 12:24 am

@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
B
43
S
12
G
1
Posts: 545
Reputation: 4,246

Post » Tue Jan 13, 2015 5:51 pm

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.
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 237
Reputation: 2,232

Post » Tue Jan 13, 2015 5:54 pm

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.
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 237
Reputation: 2,232

Post » Wed Jan 14, 2015 2:52 am

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.
A big fan of JavaScript.
B
76
S
20
G
74
Posts: 2,255
Reputation: 46,484

Post » Wed Jan 14, 2015 9:37 pm

@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.
B
43
S
12
G
1
Posts: 545
Reputation: 4,246

Post » Wed Jan 14, 2015 9:50 pm

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.
B
103
S
38
G
19
Posts: 962
Reputation: 17,996

Post » Wed Jan 14, 2015 10:42 pm

ome6a1717 wrote:@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.
A big fan of JavaScript.
B
76
S
20
G
74
Posts: 2,255
Reputation: 46,484

Post » Wed Jan 14, 2015 10:46 pm

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.
Scirra Founder
B
399
S
236
G
89
Posts: 24,543
Reputation: 195,430

Next

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 11 guests