[C2 Performance] Best Way To Handle Large Game Worlds

Discussion and feedback on Construct 2

Post » Mon Sep 26, 2016 11:36 am

The runtime is architected so that with "render cells" enabled, an offscreen sprite with no animations or events has a zero performance overhead. (Animated objects have to tick their animation and events still check against all the objects in the layout.)

This means that if you create even a gigantic layout which consists solely of static objects (no animations or events), it should run perfectly no matter the size of the layout.

The performance problems tend to stem from running events against a large number of "live" objects in the layout. You may need some techniques to avoid having too many of them at once, possibly by dividing the layout in to certain segments and destroying all the objects outside of the segment, but as far as the static objects go you should be able to create as many as you want (providing render cells is on).
Scirra Founder
B
387
S
230
G
87
Posts: 24,248
Reputation: 192,228

Post » Mon Sep 26, 2016 11:48 am

Ashley wrote:The runtime is architected so that with "render cells" enabled, an offscreen sprite with no animations or events has a zero performance overhead. (Animated objects have to tick their animation and events still check against all the objects in the layout.)
This means that if you create even a gigantic layout which consists solely of static objects (no animations or events), it should run perfectly no matter the size of the layout.

Amazing, that eliminates all my concerns about having tons of static sprites in the background.


Ashley wrote:The performance problems tend to stem from running events against a large number of "live" objects in the layout. You may need some techniques to avoid having too many of them at once, possibly by dividing the layout in to certain segments and destroying all the objects outside of the segment ...

To be honest I personally have no idea on how I could approach this. My game is based on the concept of an old GBA game, meaning that there are units off-screen that fight each other and I have no clue on how I could destroy them and keep the illusion of them fighting off-screen.
ImageImageImageImage
B
56
S
20
G
76
Posts: 634
Reputation: 43,357

Post » Mon Sep 26, 2016 1:09 pm

Ashley wrote:The runtime is architected so that with "render cells" enabled, an offscreen sprite with no animations or events has a zero performance overhead. (Animated objects have to tick their animation and events still check against all the objects in the layout.)

This means that if you create even a gigantic layout which consists solely of static objects (no animations or events), it should run perfectly no matter the size of the layout.

The performance problems tend to stem from running events against a large number of "live" objects in the layout. You may need some techniques to avoid having too many of them at once, possibly by dividing the layout in to certain segments and destroying all the objects outside of the segment, but as far as the static objects go you should be able to create as many as you want (providing render cells is on).


So, that's what render cells are.
@Ashley, It would be great if you make a sample capx regarding this with a lot of similar tiles and mouse movement so that users can understand and experience this quickly on their own.

TheRealDannyyy wrote:To be honest I personally have no idea on how I could approach this. My game is based on the concept of an old GBA game, meaning that there are units off-screen that fight each other and I have no clue on how I could destroy them and keep the illusion of them fighting off-screen.


@TheRealDannyyy, as I understand it, some old games do it by calculating the position, orientation and results in arrays/datatable for offscreen situations instead of enacting it in objects to save performance.
B
36
S
18
G
11
Posts: 248
Reputation: 8,694

Post » Mon Sep 26, 2016 1:21 pm

Sethmaster wrote:So, that's what render cells are.
@Ashley, It would be great if you make a sample capx regarding this with a lot of similar tiles and mouse movement so that users can understand and experience this quickly on their own.

Already done and explained in full detail, as I just found out. (HERE)


Sethmaster wrote:@TheRealDannyyy, as I understand it, some old games do it by calculating the position, orientation and results in arrays/datatable for offscreen situations instead of enacting it in objects to save performance.

I will have to find a way through trial and error I guess.
At least I have a ton of options on how I could handle this, I just need to come up with a good technique.
ImageImageImageImage
B
56
S
20
G
76
Posts: 634
Reputation: 43,357

Post » Tue Sep 27, 2016 8:32 am

TheRealDannyyy wrote:To be honest I personally have no idea on how I could approach this. My game is based on the concept of an old GBA game, meaning that there are units off-screen that fight each other and I have no clue on how I could destroy them and keep the illusion of them fighting off-screen.


I got a similiar game here. You can only work on the object that do not interact / fight while offscreen. You can use arrays to keep track of objects variables/position etc, and destroy/recreate them depending on their position/distance from the scrollx/y. Of course, this could be a double edged sword, as the performance impact of the creation/destruction (which should never happen every tick) could exceed the benefict of the reduced object number.
B
62
S
22
G
4
Posts: 357
Reputation: 6,478

Post » Tue Sep 27, 2016 10:57 am

I'm not sure it's helpful in this case but i did some test a while back and noticed that just picking objects with events (conditions) becomes quite heavy when the number of objects increase, even on static objects. So i found out that some conditions were more efficient than others in terms of picking, but in general trying in smart ways to limit the amount of picks using certain conditions, some ways were more CPU friendly than others.

For example. Let's say you have a huge layout, with tons sprites in a certain family. Just picking by family across the whole layout can be quite heavy, even without any actions applied.

This is what you want to limit. Let's say you use the condition "is on screen" to first filter the things that are on the screen. That's a pretty good filtering right there and works quite well. But in some cases even the Line of sight behaviour (without obstacles) set to a radius a bit bigger than the screen width can be even cheaper than the "is on screen" condition. But so far the cheapest way i could find (in some cases) was using it in reverse. First pickin "is not on screen" or reversed has line of sight to, then picking pick nearest. It only applies actions to that particular sprite, that just became closest to any of the screen edges.

I don't know why this particular condition. "Pick nearest" is so cheap, even if you have large amounts of sprites in a layout. I use that condition A LOT. I would like to know how it works, because it can't possible check the distances between every object in layout, that cheaply.

Another good way, was to have one dedicated event setting a boolean value to every object that is on screen or has LOS. That way you don't have to use "is on screen" again in other events to pick by that, because picking by a boolean is way cheaper that picking by "is onscreen". the same amount of objects.

Here's some testing i did using different kind of methods for picking just to check how heavy they are performance wise, picking from 200 sprites.

Image

Hope that helps.
Follow my progress on Twitter
or in this thread Archer Devlog
B
35
S
15
G
17
Posts: 944
Reputation: 12,210

Post » Tue Sep 27, 2016 6:42 pm

Thanks for the help and examples on how I could approach this.
I have to say though, having everything running at once with just minimal optimizations, works out pretty well on my end at least.

I just find it a little disappointing that there's no further use for the loader layout feature,
as I think it would be a nice to use it as some sort of additional parameter for cases like these.
(It would look like this to be more precise: Go To * Layout + Use loader layout = True/False).

I know we all "hate" loading screens and I guess the most people like the loading system as it is right now.
In my point of view loading screens make games look more professional and make the games feel more responsive but that is a topic for a different day.
ImageImageImageImage
B
56
S
20
G
76
Posts: 634
Reputation: 43,357

Post » Tue Sep 27, 2016 8:06 pm

Another method to handle off screen interactions would be a coin flip.
In other words, rather than create some unseen interaction, estimate the outcome using formula that chooses the winner based off of a percent chance.
The same method could be used to determine if there even is an off screen interaction.
Image ImageImage
B
168
S
50
G
163
Posts: 8,220
Reputation: 105,059

Post » Tue Sep 27, 2016 8:44 pm

newt wrote:Another method to handle off screen interactions would be a coin flip.
In other words, rather than create some unseen interaction, estimate the outcome using formula that chooses the winner based off of a percent chance.
The same method could be used to determine if there even is an off screen interaction.

Yeah my events are based on something like that, I basically use a 3 stage system:
1st = On-Screen content, including ragdolls and effects
2nd = Off-Screen content nearby, predictive ragdolls and reduced effects
3rd = Off-Screen content far, almost no ragdolls at all and minor effects
ImageImageImageImage
B
56
S
20
G
76
Posts: 634
Reputation: 43,357

Previous

Return to Construct 2 General

Who is online

Users browsing this forum: Baidu [Spider], dwtiger, newt, Yahoo [Bot] and 4 guests