It's been a while since I released MonIdle. I thought it unlikely that I would return to it, but recently I had some thoughts about how to improve it, so I made some changes and here we are.

Progression has been significantly altered. Before, whenever you caught a 'Mon', it would add to the number you'd caught and add to your damage, effectively adding to a multiplier. This meant that if you had 2, the damage would be doubled, 3 would triple it, and so on. This meant that the damage output would grow at an incredibly high rate, getting to such high numbers so quickly that the game would be over before you could blink. I first attempted to compensate by raising the health of Mons as you levelled so that it wouldn't get out of hand, but that ended up just moving the goalposts, which isn't how you want to do progression in a game.

Now, catching a Mon instead adds to that Mon's exp. When their exp is high enough, they level up, multiplying their damage. This makes the curve much smoother and easier to manage. These levels cap at 100, the same as the overall player level. Additionally, instead of evolving when you caught a certain number, Mons now evolve at a certain level.

However, I did also feel that early Mons appearing in higher areas still needed to feel like they had grown a bit, rather than barley even appearing on screen because the damage was so high. Thus, I had the idea to add a multiplier to each area, giving the Mons more HP in higher areas without needing to mess with their base health or give them different health levels. This change had the added benefit of making the game much easier to balance, and the numbers generally easier to crunch.

Another pretty simple change that honestly should have been included from the get-go is bars to control the volume of music and sound effects. Now you can shut up just the music, or just the sounds, or both. Hooray.

Developer Talk

(If you're only interested in the changes made to the game and have no interest in game development, you can stop reading).

So while I was replacing text with exp bars for the above update, I noticed that whenever the "caught view" was open the framerate would drop to about 15fps, which was weird, since the game ran at a steady 60fps the rest of the time. The game's not all that intensive, after all.

Did a quick profile and discovered that the caught view's update method was taking over 200 milliseconds to complete. Upon further inspection, I found that the vast majority of that time was being taken up by Unity's "SetActive" function.

Now, in all honesty, I shouldn't have been looping through 124 objects and therefore using "SetActive" 124 times every frame to make sure I only had the objects active that I needed. But in my defence, I had assumed at the time that if an object was already active or not active, and I tried to set it to the same, Unity would effectively just ignore it and return that method call. After all, why bother wasting time setting something to the same state it's already in? 124 method calls is nothing if they each take microseconds to complete. But nope, apparently a "SetActive" call takes over a millisecond to complete each time it is called, so use it sparingly. Seems it's a much more complex method than I gave it credit for.

Anyway, having changed the logic around so that I only updated the UI when changes occurred, would you believe my view's update method was completing in just over a millisecond every frame. No more framerate drops or spikes in CPU usage.

This all probably seems obvious to the vast majority of people reading this, but for those fairly new to Unity, trust me, don't end up in a situation where you're calling "SetActive" every frame. It's a very resource hungry method.