There are moments during development when the game changes for you. The most important one for me is when the game is first fun. This update isn't about that, that one happened years ago. But there was another one recently when I switched from text-rendered characters to pixel art images.

Today is another change like that. I know how the game works intimately... obviously. So it's never a huge deal when the game isn't clear in telling me what's going on. Feedback from players during playtests always called out that they can't figure out what's going on. Some of that is expected. The game is intentionally complicated, and it takes some time to learn it.

Today's change is a small delay whenever a panel is created. It's a small change, but it makes a big difference. I think it's a big step-change in understandability. I hope you enjoy!

You can now turn the page back! Yay! This is one of the most obvious UX implications of framing the game as a comic book, and yet, it took me until today to get it right. It turns out it's quite complicated! You may have noticed that I missed my update last week. It was because the page turn stuff was just not done. Unity threw me some curveballs, but I eventually got everything cleaned up.

This patch also comes with a small rebalance to the challenge order. Indigo Cobra was way too hard to be the 4th enemy. There are a few other little nuggets and bugfixes in here, but the big thing was the page turning.

This is going to be a bit of a tech deep dive into why it works the way it does. I've mentioned in the past that the panels (the code refers to them as "logs" for historical reasons) have been through a lot of revisions. Surprisingly, many of those revisions were driven by performance problems.

I don't like to solve performance problems before they occur. If you wait until they actually happen, you can see exactly what the problem is, and you don't end up fixing things that aren't problems. It's a lot more efficient, from a development perspective, even if it is a little less clean, from an architecture perspective.

My first solution for logs was to create a game object with a text rendering component in a scrolling view. This worked for a while, but as the game developed, more and more text was being dumped into that view, and it did end up being a problem. The original solution to this was to move it to one game object and concatenate the text together, but that scaled poorly for a number of reasons.

Eventually, I had to move towards a system that removed old log lines. This system is still present today in the pagination. Only the most recent 6 panels are displayed. Another important step in the evolution of the logs was the introduction of popups.

I got a little crazy with those popups. For example, if you mouse over a skill, you can recursively mouse over popups to go into great detail about how that skill works. Truly unnecessary detail. Regardless, each of those popups is at least one (realistically many) text field. To be able to display so many potential text boxes, I needed to reach into my bag of engineering tricks.

The two main tools are object pooling and latent constructors. That means that the text boxes are reused, rather than being recreated. It also means that the in-memory representation of a text box that isn't being shown is very minimal, with little more than just the text to allow the text box to get re-filled when needed.

However, because there are SO MANY POPUPS, even the tiny in-memory representations needed to get disposed of eventually. And so they are! Every time you turn the page, the popups associated with the content on that page are destroyed. That's why you can't mouse over the panels after you turn the page back.