Skip to content

March 30th, 2014

March 30th, 2014 published on

A common complaint during the last external testing was, “why get in battles?”. There were numerous reasons for this: battles could be avoided reasonably well, their rewards were underpowered at the time compared to other things, and they ate more turns than other quests. I fixed most of these issues, but still the question lingered in my mind. Sew proposed a new system where nodes are connected by “wilderness” nodes, places that consist entirely of battle traps and other traps. In a way this finally answers why you get in battles: to get to the other side.

So far in testing the new system surprisingly didn’t drag down pacing like I expected it too. And it finally makes battles feel like they belong in the game. So that’s one trouble off the table. I still need to revise the non-wilderness nodes to make a little more sense in the new map structure, and try to make them a little more distinguishable so players have reasons to prioritize some over others. But I finally feel okay about the game now, the biggest trouble is off my shoulders.

—————————-

For a long time it has bothered me that testers don’t really care about the main quest until the end of the game. I’ve pondered various ways to fix the fact that main quest steps other than the final one don’t really matter in winning: accumulating points for each one you complete that give you special rewards, making all of them timer based to force players to complete them, etc. Nothing seemed right. But I finally realized what was wrong with them. I had made missed the point of the main quest by making it too elaborate. Many of its steps were involved enough to be side quests. Which is where the problem arises: if the main quest is often the same as side quests, why duplicate that role? All it does is confuse players and devalue the main quest’s importance.

What the main quest should be about is a goal post that you race to beat the other players to in order to win the game. It’s a rather peculiar goal post because hitting it doesn’t necessarily guarantee victory, there might be a plot twist that moves that goal away from you. But every goal post should have a chance of being the way to win the game. As long as there’s a chance, it remains the most important thing in the game to achieve. I don’t know how I was blind to this for so long, but at least it finally hit me.

—————————-

Meanwhile I’ve been working on designing the new UI system. There’s really two parts to this work: building the UI stuff itself, and converting the existing sprite system to a scene graph. The existing system just has a big ol’ list of sprites with draw order sorting information, which really isn’t a convenient way to build a UI system in. There’s other advantages to it as well. But it’s going to be a real pain to switch everything over. Even now I consider trying to keep the old UI library around, but it just isn’t worth it anymore.

It’s a little crazy to me that it’s still so hard to find a solid solution to game UI. Building it yourself always ends with strange little deficiencies. The fact that so many game libraries have deep discounts if you use Unity, mobile, or other higher level solutions, but are impossibly expensive for small developers using C++. Sure is a thing. Makes me realize I’m something of an outsider. Only a crazy person would use that for an indie game, apparently. (It probably just has to do with only having source distribution options for C++ which is not something they want to give to anyone without a large company’s accountability. Probably. But it’s a weird world to live in where C++ has the least compatibility options, as more and more small solutions also end up being specific to Unity or other tools.)