Streaming in terrain from an array

0 favourites
  • 4 posts
From the Asset Store
Best car suspension with spring effect and very cool terrain generation.
  • Hello everyone

    So I'm working on a game where there is a forest.

    I have a (currently 80x80) array that stores whether there is a tree or not in each cell. Trees are static, solid objects.

    Originally I had the whole forest be built at the start of the game but I noticed in the inspector that CPU usage was very high, presumably because of the amount of objects (approx. 2000). However I was able to maintain a pretty consistent 60fps on my older machine with no obvious stuttering.

    However I ideally wanted the forest to be bigger and that became very problematic performance-wise. So I thought I'd be clever (uh oh) and have the trees 'stream' in from the array only when the player was near to them.

    My initial crude go at this was:

    Every 0.5 seconds --- Destroy all Trees

    --- For each XY Element in Array

    ------ If CurValue is 'tree' and distance from CurX,CurY to player X,Y < 400 --- Create object Tree at that location

    Now in the inspector the CPU usage is so much better however the framerate is worse. There is now a noticeable stutter every time this loop runs, i.e. every half a second.

    I've deleted parts of this to check and it appears to be nothing to do with the destruction and creation of the trees and purely related to looping through the array.

    Is there a better way to do this loop? Or even a better approach than arrays in this instance?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Your performance issue is unlikely to have anything to do with the number of objects. Static off screen objects should basically be negligible in terms of performance.

    It will be difficult to give more advice without seeing the whole situation though.

    Looping through a large array constantly definitely is not a good idea. If you want to stick with that general method, you'll want to break your map and arrays into "cells". A fair cell size would be a bit larger than your viewport window. As you move around your map, you'll only use the 4 (offset based on half cell sizes) or 9 (whole cells, simpler but less efficient) nearest cells/arrays to populate the map. Also generally speaking you probably want to avoid destroying and recreating an object that is going to be exactly the same as it was before anyway, so adding a check to see if the object already exists then not taking action is better.

    Still, I normally wouldn't recommend this technique outside of completely procedural/endless map type games, it should normally not be necessary.

  • A better approach would be to scrap this terrible idea entirely.

    Early optimization is the bane of game development.

    Most of the processing power is consumed by the graphics, so unless your framerate drops to 5, you're good.

    Are you making a RimWorld/Dwarf Fortress clone where even cat poop is tracked? If not, then don't bother.

  • Whoops, entirely forgot about this thread. Thanks for the pointers guys.

    In case anyone cares, in the end I scrapped looping through an array and instead used picking to essentially do the same thing which works a lot better.

    I've also realised I inadvertently didn't tell the whole truth in the initial post as while the trees were static in the sense that they stayed in the same place they were actually made up of 4 sprites, the top three of which were being moved around relative to the player (for a pseudo 3D effect). Therefore thousands of them doing this when they couldn't even be seen by the player was super inefficient.

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