I am working on a WW2 turn based strategy game. Some of the maps can be 250x150 or even more. I managed to work out a mapping system but one issue I have with changing too many tiles via UV is the GPU/CPU time. I am no expert in Unity, not even close.
The issue I am running into is how to implement a weather system that changes each turn. Even though this is a turn based game changing thousands of weather tiles when the player hits end of turn is a serious slowdown on the game.
This is like the Matrix Games: War in the East type of game. I included a snap shot of the screen for a better feel. Each hex is it’s own UV coordinates and for most applications changing a handful of UVs is very quick.
The graphics are just frame holders until I hire an artist
Are you talking about displaying weather or generating it? For display you can use the same system as you use for hexes.
For generation I would start on one side of the map (the prevailing wind direction). Generate the weather their with some pseudo random effect. Then slowly push the weather across the map. Give each weather cell a small chance of randomly mutating as it moves.
Another approach would be to use 3D prelin or simplex noise. Move across and up every frame.
Finally you could research and build a full blown metrological system. Probably overkill.
Naw my problem was the CPU time to render the UVs. I researched a bit more Unity and C# for optimization of code.
.
I ran a simulation on 78,400 UV calls on the maps. It went from 240s update to 22s update with everything I did. 78,400 updates would involved the most massive of maps of 280x280 covering the war on a 30m scale. Which will be the final product probably 1-2 years down the road. So I am happy with the corrections I did.
In case someone else reads this here is how I improved the processing speed. If I am off here please feel free to correct me. #1 I set all the map prefabs to “static” so it calls faster. Since they don’t move and are a flat 2d it applies. #2 Made sure all my types were as simple as possible and 32 bit. #3 Removed loops for updating the 6 UV points in each hex. I used a static float array for the 6 points shift and manually did each point in sequence instead of using a loop. Cuts overhead. #4 moved all the needed vars from the method to the class #5 removed all lighting since basically it is a 2d map sprite but drawn with a 3d mesh due to UVs.
Maps have a 3d mesh but sprite material so it doesn’t need lighting.
It seems to me that the really big win here would not be stuff like that, but rather to only have as many hex tiles as can fit on the screen (plus one row extra). Update those to represent whatever’s currently in view, and only scroll it less than one tile width or height.
The math will be a little more complex, but it will be dramatically faster, because instead of 280x280 tiles you’ve got 30x40 tiles or whatever.
