There was a very tiny problem in Zarvot that I hated. The system would chug upon instantiating new maps. The way I’m storing maps are in a 2D array (like a normal person) of Tile enums. I read through this array cell by cell, and instantiate walls as needed.
Obviously, this is pretty slow. The way Unity is set up, everything runs in the main thread. That means when I call my DrawGame(Map) function, it reads through and instantiates the entire map in one frame. Which clearly leads to some sort of chugging. On my beefy computer (i5, GTX670), there are no hiccups. On the MacBook Air however, there is a noticeable stutter upon every map draw. And that sucks! It really did not matter much, as once it drew the map performance was stellar, but every little stutter counts. It doesn’t feel as good.
Remember how I said everything runs in the main thread in Unity? That’s false. Somewhat. Coroutines run alongside everything else. My intent was to “thread” my map loading, having it load a few cells each frame, and then send an event to someone to signal its completion, displaying the full map without any noticeable stutter. I quickly made my DrawMap function into a coroutine, waiting for the end of frame every time I instantiated a block—thereby spreading the load across a whole series of frames.
It ended up looking awesome. Zarvot does have a very clean-retro feel that I’ve been sort of evolving it towards. I call the visual style “voxelike,” as it’s not actually voxels, but it maintains a very similar style, as well as being quite avant-retro. Simple, punishing controls and mechanics, as if gaming never evolved past local multiplayer arcade machines.
My new shiny distributed frame map drawer drew from left to right, evoking feelings of slow dial-up and line-by-line printing. So I scrapped the idea of diving into fully learning C# events and polished up this code a bit more. Looks good to me. It’s neat that this “fix” gave it such a nice subtle effect that keeps with my game’s style.