[C2 Performance] Best Way To Handle Large Game Worlds

  • 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.

    Hope that helps.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 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.

  • 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.

  • 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

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