Using Zoom to Control View Size

Zoom-based View Sizing

On the heels of a lot of UI work, I took a step back to re-think the camera zoom features. Those of you who are following this blog (thanks a million!) already know that I am not currently chunking my tilemap tiles. Every movement of the player forces a refresh of the tilemap based on a set viewport size. For example, if the view size is set to 25x18y, a tilemap "view" is created virtually instantly showing all of the (25x18=450) tiles in the view minus a few tiles on the outside edges which are just out of view but able to load the flora and other objects so they appear to enter the view as if they are always there. Each movement wipes the entire tilemap and redraws it. This means that my game world tiles are not ever entirely loaded into the tilemap, only the ones around the player out to a fixed view size.

I have changed this approach slightly after thinking about the camera zoom. If the view is 25x18 = 450 tiles but I zoom in to a view that only shows 15x9 = 135 tiles, why load all 450? It actually isn't necessary. To solve this, I decided to implement a flexible view-zoom-based viewsize and tilemap loading scheme. By that, I mean when the player zooms the camera in or out, I alter the size of the view and the tilemap tile loading to accommodate the smaller or larger view size. This works amazingly well. Naturally, when zoomed all the way out, there is more noticeable stutter in the refresh of the view. Conversely, zooming all the way in loads fewer tiles and thus less stutter. As of this writing, zooming all the way out or all the way in will result in a view that looks like these respectively.

Zoomed Out

Zoomed In

Where things have changed is when the player starts moving around in whatever zoom the camera is in. Zoomed out loads a tilemap of 1590 tiles. However, zooming all the way in will reduce the amount of tiles loaded down to just 336. This really optimizes the view and the tilemap in ways I had not considered before. This also allowed me to zoom out farther than before so that a player can see more of the immediate area.

Smaller Flora

Sometimes a feature can creep into something that is really not worth it in the grand scheme of things. Such was the case with my flora. I had 5 age categories for the flora (sapling, young, mature, old, and dead). This is all well and good, but I started thinking about whether this was too much and came to the conclusion it was. The old-aged trees were the biggest in size and when you consider that I have to compensate for their vertical and horizontal size when loading tiles around the edge of the view, I was spending quite a bit of resources just to show the bigger trees. This got me thinking generally about the sizes of my flora and whether they really needed to be as large as I have them. Dense forests swallow the player in thick foliage that is not pleasant to deal with. This is before considering the dangers of predators. I started to play with the flora scene's flora sprite scale. I reduced it to half size and with the zoom work, the game world really opened up and became more manageable. To increase the benefit, I deprecated the old-aged trees. Sapling (planted by the player), young, and mature are quite sufficient for any purpose I have for trees and other flora. Hence, I removed the old-aged models entirely. This trims the edge-tile requirements down even more, which improves performance. Here is a comparison. Notice how much room the trees take up when the larger models are used.