I should probably apologize for the previous entries being so sparse on content. Truth be told writing about weekly work activity has an element of embarrassment to it. Bothering to write something and to put it out there implies that you’re supposed to have a sense of authority on the topic. But I don’t have that authority on any one topic, so it’s inevitable that anything I do is going to not be the best way to do something.

Game development does such a good job at not covering most of its topics very well that I feel pretty ok talking about my dumb methods there, but UI systems are a rather better covered topic so I felt a little worse about talking about it. Clearly this thing is going to take way too long for me to not write any blog entries of substance during it. So here’s some dumb stuff I had to work on this week:

1. Layouting is terrible.

Since I wanted to do this as quickly as possible I settled on having layouts determined by static sizes and then having the children simply adapt to the layout they were given (rather than having the layouter adapt to its children’s sizes). Ain’t writing something for everyone here, for the most part this is good enough for my needs since I can make sure the children fit in the given area. It allowed me to avoid questions like “what’s the size of something that is supposed to stretch to fit its designated area when it doesn’t know what its designated area is yet”.

Then I ran into a snag when I realized I wanted line wrapped layouts (primarily to handle text mixed with images). That had to adapt to its children’s sizes. So I pretty much just scoped out how other UI systems handle it and came upon the concept of minimal sizes. A button might be set to stretch to fill the total available area, but you can also figure out the minimum size required to fit that button based upon the width of the label of the button. By finding the largest minimum size of all your children you can find a pleasing standard area to give to each of them. Good enough. Will even save me some time when I have to build this stuff later.

2. Drawing text is terrible.

Text in computing is one of those things that seems like one of the simplest things ever, but actually isn’t really. Drawing in a game becomes a fairly taxing operation because each character is drawn separately. So 500 characters worth of words is effectively similar to drawing 500 sprites to the screen. You can reduce some of the costs of this by using bitmap fonts and batching their drawing. You can also just pre-render all text into memory once and then just draw that- which is the primary technique I’ll be using since it’s fairly easy to integrate into the current system.

But the big thorn in my side is laying them out. Line wrapping a clump of text is fairly easy: check remaining width for each word, add newlines as appropriate. Line wrapping a clump of text that’s mixed with other UI nodes is a bit more painful. The simplest technique is to just make each word its own node and freely mixing them with all the other UI nodes.

But that has some terrifying implications: do you really want to perform collision checking on 500 words every time the user clicks on somewhere with a bunch of words (even if they don’t check for collisions they still have to get iterated through)? You want to waste memory on storing the position, scaling, etc on 500 words? You want to create 500 sprite objects for them? You want to perform 500 update operations on them any time their parent changes their inherited properties a bit?

Given I was considering implementing the scene graph management in Python to save time I’m extra worried about performance troubles related to doing it this way. But maybe I’m just worrying about nothing. I performed a basic performance test and the game didn’t hit a performance snag until I started drawing around 3500 4 letter text sprites, for instance. I have a relatively high end computer (which makes trying to estimate performance with it scary), but it’s unlikely we’ll go past maybe 500 words on screen at once, and caching will offset the rendering overhead, and it’s unlikely the management of that many nodes is actually that big of a deal. I’m probably just prematurely optimizing. In fact now that I look at what I just wrote I’m pretty confident that I am. If it actually becomes a problem, adding hackier optimizations won’t be much harder to do later than they would be now.

3. UI libraries are terrible?

This marks a month of planning the UI system. There’s so much I could have done for making a better game in that month. It will almost certainly take another month (maybe two!) to actually build this thing. Planning isn’t even entirely complete, I need to make one or two more passes over it. Needless to say I started to panic about the time investment (especially considering that at least 6 months total have been spent on the current UI library and experimenting with other libraries). So I started doing some research one last time on other libraries.

Probably the technique that stood out most in my desperation this time was embedding a browser into the game (via a wrapper such as Awesomium or CEF). My original research years ago I dismissed the idea pretty quickly just because throwing part of a browser into an application just seemed like ridiculous overkill. It still does, but after looking at other people’s implementations of such things I started to see the benefits. You can throw in existing implementations of complicated UI systems with relative ease. A browser will almost certainly do circles around you when it comes to doing extremely dense UI.

Some of the other benefits like “most people are familiar with HTML/CSS/JS” are a little lost on me since I don’t really do webdev, which is a big part of why I dismissed it originally (I honestly couldn’t even conceive of web skinning being good enough for game UI, but research shows that it’s pretty capable). If I had to start this project over again I might go with this solution now. But right now I’m just tired of running into critical problems with other people’s work. I don’t ever want to have to switch the fundamentals of our UI system again. Using another library will always have a risk of investing into it and then finding a show stopping problem. I can’t take that risk this late in the game. I might run into problems with my own stuff, but I can always fix it.

Yep. Still planning it. I haven’t planned this thoroughly since the start of the project. Which well. The code from that phase of the project is also one of the few parts I don’t have a constant desire to re-write so. Maybe not the worst idea. What I worry about is the time the planning is taking. Could I not use it more efficiently? Could I not jump to some other, different task when I get stuck on some problem in planning? I worry about this way more while planning than when I’m actually coding for some reason, even though I have roughly the same flow there.

I’m still solving problems that I’d have to solve while coding the thing, except here I have the leisure of adjusting things to fit. I’m actually thinking about taking it even further than I was initially going to, just to see if it makes the process of implementing the thing trivially fast. But man do I want to get back to the real, unsolved problems I have sitting on my plate.

There’s not a whole lot to talk about this week. UI planning as far as the eye can see. As tempting as it is to rush forward with this stuff, the last time I did that ended in the biggest time wasting disaster in the history of the game. So I’m pretty convinced planning things is a good thing to do. And now that I look at it from that perspective, it’s really easy to see spots where the planning has paid off tremendously. Things that would be way worse off if I started with my initial assumptions. At the same time I feel like I’ve lowered morale and inertia across the board, but that’s as much from having to stop and build a new system this late in the game as it has to do with planning. I’d hoped to wrap up the planning phase this week, but I’ve come a little short of that goal.

I don’t see much value in an old coot telling kids about the trials and tribulations of rolling his own half-baked UI system, with kids these days embedding entire browsers or flash clients into their games to handle it. So I guess that’s it for this week.

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.)

We’re getting pretty close to getting Update 3 playable to make a report, but it has been slow going. Due to the large number of fundamental changes there were quite a few bugs, and no one has felt like testing it all that much for some reason. Most of that is on me for getting distracted with a certain video game that just came out and not putting much work into implementing what we have of the new interface which then proceeded to bum Sew out.

For that matter I’ve been bummed out about the game itself this week in general because it just doesn’t seem like changes will actually improve it that much. It’s a pretty common thread to see making of articles have lines like “even early on you could tell it was fun!”. Which is, well, worrisome when you aren’t fun early on. Most making of articles that cover struggles to make something fun usually end in “and then they scrapped it and that’s why it ended up good” or “and that’s why this game sucks”. Of course this isn’t actually true, lots of things have only come together in the end. But when you’re sitting in it, it gets discouraging every now and then.

Last night Sew also pointed out a desire to add some animations to the interface. This is problematic since our UI library doesn’t directly support animation of any kind, so I need to extend it (and to be fair it’s made for extending it when it comes to stuff like this). But the documentation on said library isn’t fantastic and it looks to be a rather daunting task. There’s also a second problem with said library that I can’t really get it to achieve a certain effect I want. So, again, have to extend it or scrap it. I also worry a bit about layering issues for certain animations since like most game UI libraries this thing has to draw on top of the game. There’s also the fact that we’ve had perpetual memory leak issues with this thing since I started and have poured countless hours into fixing them and learning how to use it (and yet there’s still a memory leak!).

I’m starting to think it’s time to just throw the library away. A decision I should have made the first time I spent a week trying to integrate one. There just isn’t enough control over the thing, and it’s only getting worse now that it has become unsupported over the years we’ve been developing this game. I’ve been putting it off for as long as possible, thinking I might be able to make it work enough to avoid the expenditure. That said, I’m not going to just dump it all at once. It’s going to be a gradual approach of using my own system only when needed by the art. If we end up needing to replace every menu then so be it. If we can salvage the UI library for parts of the UI, then we will.

Of course all this is just going to delay getting the new interface up and running so. Great. Just great.

March is the part of the year where I wake up from the seemingly infinite possibilities of January/February and realize I’m probably not getting this thing done when I want it done.

Update 3 is complete, but we haven’t completed a test without a crash to really write a test report yet. So this week you get a blog post about personal habits relating to productivity! The Internet doesn’t have enough of those.

So this week I’ve started to focus on removing microbreaks from my workflow. Which are basically quick things (as in a few seconds to a few minutes) that aren’t work, like reloading a website to check for updates, that you do while working. I think proper 15+ minute breaks are a legitimate great strategy for refreshing yourself to help get things done, but these microbreaks have dogged me for awhile now and I think they’re way more bad than good. Here’s why:

 

1. Multi-tasking takes a mental toll. It’s bad for staying in the flow.

Some scientists said that, I think. And I believe it. It seems like I generally feel way more tired from the constant switching than I do from the actual work. Sometimes it feels like they fit into the flow in a nice way (distract self for a few seconds to think about a problem), but if I stop to think about it they likely just make it impossible to get into the flow in the first place. That critical period where you just need to push through to get into flow in the first place.

2. They don’t actually refresh you.

Because you’re spending so much energy going back and forth you never really get your brain to go into a cooldown state of focusing on something else for awhile. So you’re taking break time without really getting anything out of it. I bet some scientist said something like that.

3. Feeble human minds don’t accurately measure them.

If you asked me how much time I spent of microbreaks prior to installing ProcrastiTracker I would have given you a time that is nowhere near as large as reality. Since they’re sandwitched so tightly between actual work I just…don’t realize how much time they’re actually taking. As a person who doesn’t watch a lot of movies because it’s super easy to measure how much time they’re going to take and that amount of time is way too long for my tastes, I don’t like this at all.

4. Boredom is good.

I’ve probably gotten most of my best work done out of boredom. Boredom is great for getting work done because it makes doing work funner than being bored. When you have a non stop buffet of distractions you don’t really get bored per se. And that’s bad for business.

 

In conclusion I have no idea what I’m talking about, don’t listen to me. So far results have been decent, but not amazing. We’ll see how long I can keep this up.

Took this week off! See you next week.

So much for getting that update done this week eh? Not really from underestimation, something else came up. Progress was made but not enough to wrap it up.

Not a ton to talk about this week, but I will say that it’s notable that skills with turn cooldowns are a bit more interesting than skills that use MP as the cost. Mostly just in the PvP context since it basically lets the other player know “he won’t be using that until so many turns!”. But even in the PvE context it’s a little bit interesting to have to choose the best time to pop it. Odds are that time will be “immediately when applicable” for things that don’t have long map cooldowns but eh. Not much else to say. Hopefully with a few days away from the game I’ll be able to come back with a fresh perspective.

So this update is rapidly degenerating into atoning for sins of the past. Long story short while working on new classes that use status effects, I decided to make one a passive on the map. I then very quickly realized I had never actually gotten around to making map passives work. And then while I was in the guts of the code I realized that most of the ability targeting code was in desperate need of an update. For instance, it hadn’t been updated to use nodes instead of tiles yet. While I was in there I added bunch of other missing features, cleaned it up, etc. It’s about done now, mostly just getting the kinks out and fixing up the interface. So! Hopefully we’ll get to test update 3 this week.

Meanwhile Sew proposed the idea of moving to having one bigger map instead of our current model of having effectively 3 small maps connected together. It has some advantages towards solving our “maps are boring” problem: It allows the layout to be more important since it stays around all game (instead of being disposable like they are now), it allows a greater sense of world, it potentially allows a greater amount of long-term emergent strategies, and it allows re-usable subnodes to be more critical to the flavor of the map.

On the downside it completely tears a hole through battle balance and pacing. How do you make a higher level player be forced to trudge through a low level area anything other than busy work that wastes critical time? A persistent problem has been with a time scale so short it’s hard to make it readable as to what difficulty level a player belongs in at any given time (in a traditional rpg it’s not a major time waste to fight a battle in an area and see how you do. not so much in this game). Right now we’ve duct taped the problem by just not letting people in an area until they’re roughly around it, but opening the map rips that apart. There’s some ideas on the table to make this stuff work. Stuff like having the map get more dangerous as the main quest is progressed. But it requires some drastic changes and doesn’t necessarily solve everything.

Right now it feels a little like a conflict of interest by being programmer and designer: I don’t want to do it because it will add a lot of programming work, and we don’t have that much time left to waste on it. So for now I’m plowing through with my planned changes and seeing if they can improve the game enough. If not, it may be time to see if we can make the open map work. It won’t be a waste of time because all of the changes will be just as relevant (if not more) in an open map anyway. In the meantime I’ll be thinking about how I can make the open map thing work if it comes down to it.