Blog Catch Up: March 2020 – December 2020

Reading the previous catch up before writing this was pretty rough. In that it felt like most of what I got done this year had actually been done the previous year? Let’s sort through this mess and see if I actually got anything done.

March – May 2020

The battles for Sealers, Insomnia, and Ruins were designed, implemented, and tested throughout these months. These were the final main scenarios. Along the way a few new classes got added, healers were rebalanced relative to tanks again, I took week off for a break game, etc.

I also managed to write and implement the entirety of the tutorial/prologue scenario by the end of May. While I had dabbled with sketches of it over the years, most of the final form come together here. I took an approach of just throwing extremely narrow options at the players with low-stake monsters in hopes of getting players to bumble into the solutions rather than spelling out the mechanics directly. Might be good (is certainly in line with how the game expects you to learn), might be a disaster. Haven’t put it in front of a new player yet, so we’ll find out.

You might be thinking, “well that’s most of the game done. Time to coast to content complete well before the end of the year!”. You’d be wrong.

June 2020

This month was spent populating the game’s lobby- the player’s boat. This required actually defining who our protagonists are (originally intended to be silent for sake of dialog brevity, I relented and gave them a minor voice), writing dialog between them and the Ferryman character, populating it with characters/items from other scenarios, etc. The biggest piece of work here was adding support for persistent cross-scenario flags in order to carry over progress to the lobby (including saving it to disk, sharing it over the network, and unlocking classes based on it). Considering I spent half the month on another side project, looking back I’m surprised I got all of this done in the other half of the month. Taking breaks can really work, I guess.

July-August 2020

Designed/implemented the final batch of new classes (difficult with most the battles done), designed/implemented Challenges (optional battles) 6-9, added pixel perfect collisions, and the biggest thing is that I overhauled our data system. This involved switching from storing data in SQLite to just dumping them to JSON (partially to make it more palatable for git, partially to allow loading data from multiple files to be more multi-user friendly, and partially to pave the way for better mod support). I also discovered Dear ImGui which allowed me to rewrite the UI for editing data instead of our old clunky wxpython version, which will make modding much easier but also allowed me to add a lot of features for data editing I’ve wanted for a long time. Additionally, using Dear ImGui has let me churn out a lot more small tools for working with the game so I kind of highly recommend it if you find yourself wanting to make tool UI for your game but don’t want to deal with the weight of your full UI system (though it certainly does not scale up past a certain size of tool).

This month also saw the sole improvement to our interface in this batch of updates: indicating RPS distribution with pie charts, and having the characters use rods to create battle lanes (they also indicate role, agility, and are story-relevant):

It’s a reasonable UI clutter reduction.

September – November 2020

So it was finally time to make the final boss scenario. This is also where everything came to a crash, for a multitude of reasons.

  • While I did most of the previous scenarios in batches (designed/wrote all, then map scripted all, then designed/implemented battles for each) I only did a rough writing pass on the final boss. So I had to do most of all 3 phases of the final boss back-to-back.
  • It also required more new features than the other scenarios: I had to add mid-battle class changes, one big treasure container based on previous scenario choices, disabling lanes for a battle, and generally just coping with the extra variability involved. None of these are that big, but the weight of my previous code sins were starting to crush me harder than I expected while designing it.
  • Just deciding the gimmick for the final boss took awhile (endings are stressful in general), and also ended up being an idea that took more work to design/build. I’m probably happy with the direction it took, though?
  • I was just kind of miserable during these months in general. Maybe because the art side of production ceased (earlier months were actually quite productive), maybe because it took so much longer than I expected, maybe I should have taken another break project. Who knows.

December 2020

While it was entirely possible to wrap up the remaining content this month (only 1 challenge- though an impossibly large list of backlogged tweaks probably not), I decided I needed a break from design and dived head first into optimization. I had a really good time, and finally bothered to hook up a proper per-frame profiler for the C++ side, and overhauled the Python side to make it easy to see what happened on the same frame for both.

Digging unfortunately also turned up more problems. The first is just learning that Python doesn’t really support threading, which made it impossible to allow the game to smoothly load (I used a junky workaround of checking every so often during, but it isn’t perfect and kind of bothered me with its existence).

That alone wasn’t really a deal breaker, since there isn’t that much loading in the game and load screens don’t need to be smooth anyway. The next hit to my confidence was just learning that the cost of switching from Python2 to 3 was maybe higher than anticipated? Or possibly just that Python in general is slower than I thought. Creating new map entities was just slower than expected. Partially from my own janky C++ loading functions (likely plenty optimizable), but it also seemed like even removing them wouldn’t be enough- I was just using too many bulky objects together to make them up? This also wasn’t an impossible roadblock- just space out loading them more when switching maps, maybe delay parts of creating them when doing it on the current map, etc. I may have even been misreading the profiler. But it was starting to be quite a bit more drastic work for optimization.

The larger hit was just starting to see that SFML was taking surprisingly long to draw certain unremarkable sprites at random a very small part of the time. These slowdowns weren’t necessarily visually obvious, but the fact that tracking them down would probably be impossible bothered me a lot: was it something entirely in SFML, was my janky C++ code doing something wrong, or is this totally normal and not actually a problem? Honestly, I don’t know and I don’t want to spend the time to find out.

At this point I finally started considering something terrible: rewriting the game in another engine. This would be a stupid amount of work that I really don’t want to do, the case for it was starting to build up:

  • SFML has gone largely unmaintained in the time it took to build the game. While it isn’t causing any problems right now, it makes me kind of uncomfortable to still be using it (porting to SDL2 would also be an excessive amount of work)
  • Python is such that I have no confidence in ever porting this game outside of PC. Entirely by accident the game is quite well designed for tablets, so it would be beneficial to have more platforms available (console ports are also a benefit, but I have no illusion of being successful enough to do so).
  • This was my first big C++ project, and while only a small part of the game actually uses it, I really don’t trust my own C++ code for not being awful (learning it was still worthwhile, though).
  • I have lost confidence in being able to optimize this mess properly without quite a few significant changes. It’s still probably less work than rewriting it, but if I’m messing with the guts anyway…?
  • Years of hard genre shifts means the code in general is in a terrible state. There’s also poor test coverage due to me not appreciating tests until the project reached a certain size/age. A total rewrite would probably do wonders for stability. (Of course, every programmer thinks this. I try to avoid the siren song of redoing everything for the sake of getting things done, but…)
  • The game was heavily built around the idea of separating its data (including making a light scripting system with said data), which means it’s fairly easy to just export that data to a new engine and just build the game around using it. This makes the cost of a rewrite… slightly less intimidating.
  • The main remaining task is polishing the game up. Rewriting it would allow adding that polish as I go. The new engine I have in mind would also probably make polishing easier for everyone involved.

That’s a pretty long list, but I still don’t really trust my own logic here given the amount of work involved. There isn’t actually an impossible problem that requires doing this, but all these issues have been weighing on me for so many years that I’m finally starting to give in. I’ve rewritten things before and while it takes a lot of raw work, it’s generally much faster and mostly just a matter of pouring hours into it. I’ve started preliminary work on the rewrite already, but whether we go through with it or not remains to be seen. Here’s hoping this ends well?

Blog Catch Up: December 2018-February 2020

December 2018

It had become quite clear the new horizontal status sheets at the top of the screen basically made player status virtually invisible, so we took another swing at them (using something pretty close to older mockups with portraits):

This in turn necessitated re-arranging the hotbars as well, which was fortunate anyway since classes were getting more abilities than could comfortably fit in the old single hotbar:

While I think this is way better than the virtually-invisible-top-of-screen version, here in 2020 I still personally struggle to notice the information contained within. But we’re kind of just… living with it, for now. A knock-on effect of this change is that we couldn’t find a great place to put the turn order in this layout. Emboldened by “just remove it” having been some of my best calls in the past, I decided just to throw it away entirely by making turn order decided by lane order (bottom lanes actting first, then next lanes, etc). This change was pretty much immediately a huge improvement to the game (pairing well with the ability to swap lanes without taking a turn), and also getting rid of UI clutter. This layout would also go on to enable a new hotbar layout later in the year.

January 2019

This month saw another two scenarios completely planned out: Insomnia and Ruins. Insomnia got done at a shockingly fast rate of only 4 days accordingly to my records (though probably involved a lot of prior stewing), while Ruins took the rest of the month to get done. It’s pretty clear that I waited too long to write this blog because I honestly don’t remember much about the creation process of these anymore.

I can say that Insomnia is probably one of the few scenarios that feels like it has an actual middle- most the others skew towards intro, gameplay stuff with minor build up, climax. In this one the mystery actually deepens a little bit for the middle phase of the quest.

Ruins meanwhile acts as the dumping ground for the originally intended ending of dealing with a world-spanning human threat rather than the Chaos Eater. The original version had the antagonist character with pure intentions, while in this one she’s getting islands eaten for her own selfish gain. In a lot of ways this might still be a better ending scenario than actually killing the Eater, as it turns player expectations on their head, subtly references past scenarios, and has the antagonist actively mock the players she’s been watching this whole time.

February 2019

This month saw the completion of planning for the Trapped and Kill Eater, essentially ending the planning phase (though leaving the intro and lobby stuff mostly unplanned). I also filled in how to do progression (beating scenarios gives new classes), and decided the scenario order which was a surprisingly difficult task since I didn’t do that great of a job of balancing overarching story progression (in terms of players understanding the world) and scenario play styles. Even now I’m still kind of “should I re-arrange these?”.

The actual design process of these scenarios is also hazy to me at this point. That said, here in 2020 Trapped has probably had the best tester response of any scenario? After designing like 14 of these things I finally figured out the formula, I guess. If I have one regret it’s that I wish I could have designed 30 scenarios and then just picked the 10 best ones to actually put in the game. Just for the sake of getting practice?

March-May 2019

Jumped straight into implementing all of the map portions of every scenario (except Kill Eater). This part of the process is actually pretty boring work of just taking the plans and putting them in the game. Lots of inserting text from the script, data entry for rooms, scripting the puzzles/behaviour, etc. Having to add various minor new features to the engine (dynamically adding rooms, randomizing rooms, neutral monsters, real time timers in battle, etc) actually gave this process the right amount of variety to not become totally tedious. In general it was really satisfying because the only thing required to make progress faster was just putting more hours in. And that shows, because it only took 3 months to finish- rather faster than my expectations.

June 2019-August 2019

I kicked off by taking one last look at the battle system and wrote some documents detailing any major changes to do before this last push, and guidelines for class design. Some good changes fell out of this:

  • Ultimate System: Rather than a damage bonus for winning Rock Paper Scissors, characters charge their Ultimate ability (usually related to their role- so healers might get a heal all while damage dealers do more damage). This makes the RPS system feel much better for non-damage dealers, and stabilizes monster damage.
  • Armor becomes a universal damage reduction rather than a damage bonus when losing RPS / reduction when winning RPS. Certain Tanks/Healers gain armor reduction abilities, while many monsters get 100% Armor- basically making damage dealers depend on the other classes and adding a wrinkle to party composition.
  • Revised lane system to allow for vacant lanes where characters are untargetable and can target any lane. This makes monster behavior more consistently readable rather than adding uncomfortable randomness where you’re not sure who a monster is going to hit in a 2v1 (it also adds some strategy of hiding weak players and freeing lanes so damage dealers can focus fire).
  • Monsters with multiple points to target can share HP, so boss battles don’t devolve entirely into knocking out the weakest part to get a lane advantage.

These ended up being some really good changes (looking back it’s crazy to think this was only 6 months ago, because they feel like they always belonged).

So I was feeling pretty good at this point: I had over 6 months to simply design/implement classes/battles, and I would finally be on the precipice of content complete. Having already made plenty of classes/battles for previous iterations, I felt pretty confident that this would be a smooth process. It wasn’t.

I started off by just designing all of the classes at once. The new RPS system required re-designs of all the existing classes, but I wasn’t planning on throwing away the existing classes- just tweaking them for the new format. By mid-August I had less than half the classes done on paper, and realized that this might be the dumbest idea for a process I have ever had.

I decided to start designing and implementing classes/battles in parallel instead. I started off by revising a few existing scenarios with new battles, and it became very clear I was correct since several of the classes weren’t really playing out as intended in practice. The whole process started to finally move forward.

September-November 2019

Just a blur of design, implement, test, repeat for battles/classes. Slow. Very slow. At this point maybe half the scenarios/challenges are finished, but the testing is rough. Lots of classes being underpicked by testers, making their balance questionable. Lots of testers being stuck on battles/scenarios and it being unclear whether something isn’t correctly hinted at, the UI isn’t making how mechanics work clear enough, there’s too much time between tests so players are forgetting things, or the testers are just dumb and not paying attention. These tests have probably been some of the most stressful/frustrating because piecing together the puzzle of the tester’s internal logic feels impossible.

This is also amplified by the first wave testers not being as RPG apt as the second wave of testers, so I fully expect the game to get absolutely shredded after lowering the difficulty to match the first group of testers. It stresses me out a lot since the battles make up the majority of the game. Getting this right is the most important thing.

Along the way we squeezed in some important improvements such as displaying status effects as a separate window from the main ability, cutscene skipping, and Sew’s new display for character stats:

It was honestly kind of shocking how big a difference this makes in terms of readability. The old display made it feel like there were hundreds of stats in the game, while the new one makes it feel like the actually small number of them:

One major new mechanic got added as well: the Rage system. If players don’t kill a monster within a certain number of turns (varying on the monster), then it starts to get a rage buff every turn that doubles its attack power. I’d been toying with such a system ever since allowing any combination of roles in a party, but I finally went through with it after a bunch of tweaks to the Tank role. The main thing that made me feel okay about it was that it’s a soft timer that gives players a few turns to deal with it rather than instantly ending the battle. It certainly makes balancing the game less stressful knowing that it’s much harder to create a “win in 50 turns by never dying” party now.

December 2019

The grind of pumping out battles had finally taken its toll and I basically felt incapable of keeping it going. So I went ahead and took a week off, and spent it working on a different game. And it was wonderful? I spent the whole time mostly just learning a new engine ,and the entire experience basically rekindled actually enjoying making games again. I had done little break games for awhile, but around 2016 I stopped entirely for the sake of “getting it done faster”. In retrospect I think this was a huge mistake. Sometimes you need to work on a different problem.

I ended up spending the rest of the month converting how our UI is defined to something similar to HTML rather than directly in code. When originally making the UI system I considered this, but dismissed it as too much work. What made me change my mind was the fact that Sew has mostly just been doing new UI mockups all year rather than any other art, but I just don’t have the time to implement them in a timely manner. Exposing them in a way he can change directly will streamline things a lot more. Fresh off the break I got the system done this month, but actually converting existing UI is an ongoing project.

January-February 2020

Still fresh off the break, I cranked out two more scenarios worth of battles and a few new classes in record time. But the rough edges of the game that I had been ignoring were really starting to get to me. Moving between rooms took forever, battle animations took forever, Sew had a new hotbar idea months ago that I wanted to try, etc. So I finally decided to take the time to just make the game feel better for the first time in ages.

Here’s the new vertical hotbar style. By organizing abilities by RPS type, it makes it easier to control when you already know what type you want to use. The vertical nature also makes it more noticeable when you get a new ability. Tweaks like making passive abilities have stars instead of normal backgrounds makes things easier as well. The one downside is there’s no great way to assign hotkeys to abilities anymore, so to compensate I added hotkeys for targeting (not ideal, but better than nothing).

Additionally, we sped up battles by having characters merely walk forward a few steps instead of walking all the way to the target and then walking all the way back (which also made casting abilities more noticeable since they step forwards now too). Along the same lines, I sped up the room transition animation to always be around 1 second rather than waiting for the player sprite to walk all the way to the exit. The game feels much better as a whole now, and should make testing more pleasant. As always, we make the best improvements by just removing things.

A random spark of inspiration also led to me rewriting the ending of the game. I feel way better about it now- both because the new one takes less work, and is also a way better conclusion.

The Future

The first half of 2019 was amazing, and the second half has been kind of miserable and way behind schedule (though I kind of expected as much). Wasting 2.5 months designing classes entirely on paper was a big, stupid mistake. I literally have a functioning game right here that makes it semi-easy to add new classes/monsters to it. WHY DIDN’T I JUST USE IT?! I’m still not sure what I was thinking.

There are still 3 scenarios of battles to do, 5 challenges, and over half the classes. While I have pretty good sketches for the remaining battles, getting the remaining classes done is haunting me. It’s mostly a matter of admitting to myself that there isn’t a need for too many new archetypes, and I should just be making variant classes now. This is a good thing, but it’s hard for my brain to wrap around it. I skew towards wanting to make new, weird things. So working within an existing framework is strange.

The other thing that haunts me is that once battles/classes are done, there’s still some additional work to do with making the tutorial and lobby content. It isn’t that much more work, but it makes it hard to enjoy getting to the end of battles. It’s like knowing you have to spend part of your summer at school. Can’t look forward to it.

Either way it’s basically dead certain the game will hit content complete this year (provided I stop myself from making any cataclysmic changes). I don’t even know how to process that fact. Mostly just worried about the remaining work, and uncertain of how long it will take to get the art/music done after this.

Tanks: A Journey

Probably the first defining element of our battle system was lanes: a character can mostly only target the enemy directly across from them. It was created to solve the problem of how to balance battles having any number of players in them at a given time, when the game was a board game with players dropping in and out of battles. It solved the problem, but even after PVP was dropped we kept the lane system because it’s pretty interesting on its own (turn based RPGs often fall into the boring trap of exclusively focus firing one monster at a time, lanes make that strategy much trickier to execute- adds an interesting spatial flavor without dragging the game down with full tactical map bloat).

When making the co-op mode I had a pretty strong pull towards having extremely strict roles to give players a sense of teamwork. I ended up gravitating towards the MMO trinity since, well, it’s the most obviously/strictly defined. The problem was: what the heck does a tank do in the lane system that explicitly prohibits focus fire, when a tank’s entire job is to absorb most/all incoming damage? The easy way out would have been to redefine the lane system to allow a tank to be in multiple lanes or whatever, but I liked the lane system way too much to water it down like that. So I started trying alternatives.

Version 1

My first attempt was to make healers about damage recovery, while tanks would be about damage mitigation. A combination of above average self survival while also boosting the survival of their allies: boosting their HP, reducing the monster’s attack, etc. While that kind of stuff would typically belong to more of a healer/support role, it made sense to split it out into its own thing to create a role with a specific job.

This version wasn’t completely broken, but they were role with the biggest issues:

  • Stacking a party entirely with Tanks could potentially allow compositions that can never die, but also take forever to win- basically incentivizing players to bore themselves to victory.
  • Damage rates in the game were uncomfortably sky high in order to force battles into ending quickly (the kind of high that in most RPGs would make you think you ran into a monster way too high level and should run away) , which in turn made most tanks feel pretty weak since I didn’t want them able to give much more than a 1-2 hit advantage.

Version 2

When changes to other systems necessitated redesigning every class, I took a stab at fixing the paradoxical dilemma that tanks were both too strong AND too weak:

  1. I gave tanks massive self-buffs of +100 HP, with the caveat of it only lasting a finite number of turns per battle. Now they had a major edge, but couldn’t create infinite stalemates (especially when these buffs occur regardless of player input, so they can’t cycle tanks)
  2. I gave most every battle a monster that could deal 60+ damage, when non-tanks only have 30-50 HP. Thus, tanks were required to even survive.

This solution achieved its stated goals, but when trying to develop more than a few tanks I quickly realized how hard it was to give the role any variety. If I wanted to make a tank that also gave other players HP, I still needed to give them their own personal HP buff to survive the massive damage monsters- so why even pick the tanks without the party wide buff? If I wanted to make a tank that operated off of dodge luck or self-healing, they’d still need a major HP pool to survive the big damage. It just ended up being way too narrow of a role, and that included playing it.

Version 3

I briefly considered just removing roles altogether, but settled on a much less drastic option: turn timers. By limiting the total number of turns players can spend in a battle, the worry of sloggy tank battles goes away. I had considered this as an option pretty much the entire time, but constantly rejected it as too artificial. After changing it into a “soft” timer where monsters just constantly get their attack buffed when over the limit (preventing the edge case where players get defeated by a single 1hp monster from the timer), I finally grew to accept it. I still feel like a hack for needing it, but considering what a convoluted mess Version 2’s attempt at doing it “naturally” with tank HP timers.. I’ll take it.

In general the role of tank will shift a bit: healers will get fewer revivals, tanks will get more- making them more of a “recovery” role. While speed runners will almost certainly use 4 damage class parties, the new RPS system adds enough damage spikes from mistakes into the mix to make such a role very useful for normal play (as well as buying time for the slower charging damage dealers that need more turns). Yet, the average damage rate won’t be as uncomfortable as earlier versions.

Super high HP tanks and super high damage monsters will return, but only as gimmicks for a few scenarios rather than the gold standard for every battle. In general it’s a shift towards making players have to make party composition choices that balance between recovery and damage. It’s still going to be a delicate situation to avoid full damage parties being the absolute best choice, but I definitely prefer that being the optimal composition rather than players making themselves miserable with 40 turn defensive parties. So even if it’s easily breakable, this is the way I want it to break.

Blog Catch Up: December 2017 – November 2018

December 2017

Entire month was spent on on developing the entirety of the “Sacrifice” scenario (concept, layout, dialog, monsters, implementation, testing). In retrospect I don’t know why this one took so long since it was the first fully linear scenario, making it mostly less demanding than the previous. Probably lots of doubting that we could do linear scenarios and concern about having to do a lot more storytelling with this one. In that regard it is the first scenario with particularly fleshed out cutscenes- more emoting animations, a guy pushes a rock down, etc. This would also be the last scenario that I developed all at once, switching to a new format for scenario planning that I’ll talk about later. For reference this would be the fourth developed scenario, but since one of the other scenarios has been canceled it is more like the third.

January 2018

Old class selection menu.

New class selection menu. You can tell an artist touched this one.

A smattering of changes:

  • A new class selection UI, designed by Sew, was added. Huge improvement over the previous one.
  • Gave up on hidden HP and just flat out show HP bars under characters when they take damage or healed. Makes the impact of things far clearer.
  • Added a patcher for tester convenience. Had looked for one for years before finally finding one, there is an odd dearth of free game patchers (which is probably why even professional ones tend to suck). I actually spent an entire week fixing the patcher due to an obscure bug in Window’s C++ libraries in the next month. Not a great use of time, but it sure is less painful to get tests running.
  • Bug fixes, new classes designed/added (Chef and Wraith), rebalancing older classes, etc.
  • Around this time a big group test occurred.

February 2018 – March 2018

The older vertical status sheets.

Newer horizontal status sheets

After the test we started tweaking things in response to tester feedback. One of the big things was moving the status sheets from a Final Fantasyish vertical layout to a horizontal one. A couple testers much prefer the turn order in the corner there, but I’ve personally found it harder to pay attention to turns now. Likewise I feel like everyone pays almost no attention to the HP/MP/etc status sheets anymore either, tending to depend on the HP bars that appear under characters when receiving damage. This is still the layout we’re using in December 2018 and I still don’t totally love it, though I think some newer designed-for-horizontal layouts that sew has concepted might end up being a better direction. 

Some more successful changes in response to feedback around this time:

  • Players can start camping by using a camp object in every map instead of using a super missable hotbar button
  • Status effect icons showing up on characters when hovering over them (in general the previous month’s addition of HP bars that show up on hover or damage ended up being a tremendously effective “only show extended UI when hovering on something” pattern)
  • Status effect animations finally show up on top of characters as an effect, too.
  • It was decided enemies that randomly change their battle lane just feels terribly luck based, so we moved to having them always move in predictable patterns instead.
  • Numerous smaller fixes

April 2018 – May 2018

Even though producing content was supposed to be the driving factor for this year, apparently the last update’s tester feedback was still haunting me. So I launched into simultaneous map turns: a system where every player can move around the map, interact with npcs, etc on a first come first serve basis rather than alternating turns after each move. In some ways I liked the older system better, but simultaneous has huge pacing advantages in terms of letting people buy equipment or spend points simultaneously instead of watching other players do it. The downside is proactive players can dominate map decisions now, which is something we’ll probably continue to tweak by requiring a majority before moving or something. If nothing else, the game definitely plays smoother now.

This was a pretty huge change since the original networking was made entirely around only one player having authority at a time.There were two approaches I could take: rollback where the local client immediately executes an action and rolls it back later on if the server rejects it, and blocking where the local client waits to continue the game until the server approves an action. I ended up going with blocking since the original design was very much not designed to deal with rolling back events. Fortunately with the fairly laid back pacing of the game, we haven’t really noticed any issues with it.

Along the way I had to add a few new features to accommodate it:

  • Players can now ping on the map to direct other player’s attention to certain spots. Mostly just annoying! I love it.
  • Thinking icons appear over player heads to indicate what they’re doing: spending points, highlighting a certain npc, targeting an ability, etc.
  • The ability to cycle which player the local client is controlling by just hitting tab- a huge improvement for single player usability.

June 2018 

This month I decided to make a change with how I produce scenarios. Rather than doing the entire thing in one go, I would plan, do the map layout, and write the dialog for every scenario before doing the rest of production (battle design, implementation, testing). There are a few reasons for this:

  • Scenario ordering can’t really happen until every scenario is planned (I want linear scenarios as breathers between puzzle-heavy open scenarios, I want lighter story scenarios after more emotional scenarios, etc). As a result, when I do battle planning with the rest of the scenario I can’t really do proper difficulty/mechanical escalation because I have no idea WHEN the scenario is going to happen in the progression! This also applies to designing required battle classes when I have no idea what the unlock order will be yet.
  • Writing and designing a scenario is the most unpredictable work in this game. It isn’t like code where you can kind of just keep cranking it out, it requires inspiration and lots of consideration. Implementing a scenario is mindless in comparison, so it’s far more efficient if I do all of the implementation at once. Meanwhile, I can continuously do scenario planning one after another until I hit a dry spell and switch to something else.

Regardless, this month was a return to scenario work. I finished the “Sealers” scenario (about restoring a lost island, learning about their lost culture of dealing with chaos, and ultimately revolving around two characters who are still dealing with the aftermath of it). This scenario was actually a really big turning point in how I write the scenarios. Previous scenarios primarily revolved around a single character or culture, and exploring the world they created to deal with chaos. This is the first scenario that was explicitly written to deal with a character duo that gets to interact together throughout the whole thing.

The preceding “Sacrifice” scenario was technically similar, but was also far more centered on one of the characters and was mostly an unconscious accident. This time it was deliberate. I think it’s a very strong formula for the game’s format of minimal dialog and mostly silent player characters. Two characters is about all the restrictions allow, but having them interact together for a whole scenario allows for a lot more growth/progression than one-off characters reflecting off a single central character.

Of course the next scenario (“Crime Town”) immediately ignored all this since its concept had been lying around for awhile. It revolves around a town of thieves who are lost without their missing leader bringing them together in order. It was a lot of fun to write, and came together ridiculously quickly since it mostly consisted of scraping a pile of ideas from the IRC dev channel into a scenario. Mostly just a sad reminder that I am a terrible solo developer, but work smoothly when I have someone else to bounce off of.

Still! Two scenarios done this month, up to a total 5 of 10.

July 2018 – August 2018

I tried to keep up the scenario production, but was tapped out. So I moved on to the next required feature: the options menu. It actually came together in a breezy 2 weeks because the concept of an option is actually really easy to generalize compared to most things in a game. It also adds a tremendous amount of “real game” feel.

During the end of July I did the “desert” scenario. I knew for a long time that I wanted to do a desert scenario as a tribute to the RPGs with horrifying difficulty spike/confusing deserts, and that it would lend itself to a lot of unique mechanics. But after weeks of trying to figure out one that wouldn’t turn the scenario into more of a minigame than anything, I had to give it up. The one that came closest to production involved tracking down a monster in a massive desert map, using scents, footprints, bait, and a bunch of other stuff to isolate its position. It was just too much. While the game revolves around making every scenario slightly mechanically unique, the map mechanics would require throwing away battles entirely. While I’m not against having a “breather” scenario like that, the depth of mechanics was just too dangerous- we would likely spend months just polishing the darn thing to not be confusing.

What I ended up doing was looting the story concept of one of my unfinished games that happened to also feature a desert. A reckless king wants to turn his kingdom into a 24/7 party, and his concerned daughter recruits you to help avert looming disaster. As you might notice, another character duo scenario. This one ended up being my favorite scenario story so far, though it ends far differently (but better) than the original game I took it from.

At the start of August I took the bold step of writing the first part of the planned trilogy ending scenarios, hoping to finally get the ending nailed down. I liked this scenario a lot since it had to set up a trilogy, it needed to be exciting and big. Titled “duel” it revolves around a single, long boss fight against a woman who is sick of you preventing chaos. The main thing I liked about this one is that it has a progression of reveals: first you think she’s fighting you because you’re being forced to help a tyrant, then it turns out that she has been causing all the scenarios you’ve been preventing all game, then it turns out that she considers -you- evil and letting the Chaos Eater feed is actually vital to saving the world. It’s a whole lot of plot reveals sandwiched in an exciting new timer mechanic that forces you to rush through the map and battles, before finally climaxing in you failing to save an island for the first time- revealing the true villain to be a worthy foe.

Of course only a few months later I would decide the rest of the plan for the ending was completely untenable, resulting in this completed scenario being thrown away (I might recycle parts of it into a new standalone scenario, but it will never have the originally intended effect).

One scenario done, up to a total 6 of 10.

August 2018 – September 2018

At the end of August I needed another break from writing, so I started the next big features: replays and saves. Since the game is network event based to begin with (transmitting mostly only input), adding replays was a pretty straightforward process of just recording and playing back those events. They’re also very useful: replays can reproduce bugs or find new ones after doing changes, without having to play the entire game. Of course there’s also a third use for them: saves. By playing back a replay as fast as possible they’re indistinguishable from a proper save. Lots of drawbacks to this: saves become less backwards compatible, adds a ton of unnecessary load time, and particularly slow players could generate replays that will just break the game or take forever. Unfortunately going so long without planning for save support resulted in a game where adding it would be quite painful (the first time where I’ve hit this situation) so I took the easy out here. If I have more time I’d like to add real saves, but saving is limited enough in this game that I don’t think it is worth the time investment at this point.

A few other great features as a result of finally having saves (testing the game for so long without these was REALLY PAINFUL):

  • Clients can hotjoin a game in progress- the server simply sends them the save over the wire.
  • The server can reassign players midgame- replace someone who quit, or boot someone who’s causing trouble.
  • The ability to return to the lobby and start a new scenario without having to restart the whole game.

October 2018

The first “for fun” update in ages, I made the sprites 3d to allow us to tilt them when going up/down, or flop over as part of a death animation. It is an effect I’ve wanted to do for ages, but could never get around to doing.

After spending a few days on that, I launched into trying to get the rest of the ending done. When I finally starting digging into the long-planned ending written it, well, unraveled on me. This spiraled into probably having half-planned concepts for like 15 different possible ending situations. It started as realizing that trying to create the Empire as an alternative antagonist for the ending of the game just wasn’t satisfying (at the time I didn’t want to kill the Chaos Eater, since that felt like killing the setting itself). It felt like the kind of thing that games planned as trilogies do. And games planned as trilogies often fail largely because they always have unsatisfying endings because they’re too focused on teasing the future to realize the first game players play REALLY, REALLY needs to end satisfyingly. But even when I planned for killing the Chaos Eater I still kept running into a hole (largely revolving around having a character reveal themselves as creating chaos intentionally so they could finally break the Eater’s defenses and kill it, then forcing the players to choose between stopping them or killing the eater and letting them get away with things without the Chaos Eater to stop them). This went on and on for the whole month because I REALLY wanted to get the ending solidified since everything else hinges on it to a degree. I even had ideas like introducing a whole new set of protagonists who actually get to kill the Chaos Eater, while the original Chaos Chaser protagonists try to stop them because they’re part of it. I really went everywhere on this one.

It all finally came to an end a few days into November when I just randomly had the idea when waking up that morning: players could attack the Chaos Eater from the beginning of the game (as a simple 3-phase boss battle), but the more scenarios they beat would result in more characters showing up to help them fight it. Making different choices might result in different characters showing up. And that was it. It was immediately obviously the right idea.

November 2018

After blowing a whole month on just an ending concept, I really wanted to move forward. So I cranked out the “War” scenario within slightly over a week. Most of the concept had already been planned from earlier months, it just happened to “click” in a way where I could rapidly wrap it up. Not a lot to talk about it, but I like how it ended up though the mechanic is probably going to take some refining during implementation. I started on another promising scenario concept too, but with all the ending stuff I had been drained of writing energy.

So I moved on to a battle system change that I had planned months ago: Let players change lanes without using a battle turn. In testing, changing your lane just wasn’t quite valuable enough to validate wasting an entire turn. Some classes had additional actions after moving, but that also made figuring out what would happen in a turn take quite a lot of mental energy from players. Just removing the turn cost should solve a lot of problems. It’d also give tank classes a lot more value now that they can easily do their job of “clogging up” damage in a lane as needed.

Originally I planned this so monsters would do their movement, then players, then the normal battle turn. This would make monster movement minimally confusing even if random, but to make monster movement have meaning required having a cost on player movement. I went through a number of ways to do this before deciding everything felt overly complicated and simplified it heavily: players could swap lanes at no cost, monsters would move AFTER players, thereby requiring players to predict monster movement patterns. This is much more in line with the rest of the battle system, and doesn’t make the game feel even more convoluted with another resource to deal with.

The end result has been pretty great so far. A lot of things I hadn’t entirely considered immediately fell out of it: Damage players can strategically swap lanes with “my high damage attack is paper…so I really want to be in your lane with that rock enemy to use it!”. This just plain makes the game feel better in terms of giving players more opportunities to do things that make them feel smart, making the RPS and Lane system feel far better together than they had in the past. Testing is still early, but this was almost certainly a good change.

All that only took a week. Still burned out on writing, I went ahead and made it so the lobby can exist on a map. This required some changes to how the game work, but the end result is an area players can mess around in between scenarios. Lots of stuff will fall out of this in terms of having NPCs come and go between scenarios, foreshadow future scenarios, let players engage in dumb minigames while waiting for their friends to connect, etc.

One scenario done, up to a total 7 of 10.

The Future

I fell into a pattern of “do scenario work, do code work, do scenario work” this year which honestly felt really great- whenever I got burned out on one type of work, I could do the other. My productivity was probably much higher than average as a result. Unfortunately, I also completely failed to reach my goal of having the game content complete by the end of the year. That’s bad for art efficiency.

I’m basically out of major features to add to the game now. We just… have  the bare minimum required to ship a product now. It feels weird, like we could conceivably finish this thing. But there are still hundreds of smaller code tasks that need to be done, in addition to whatever extra features new classes/scenarios will require adding.

In short: This game will almost definitely be done next year. Whether it has the graphics/music to make selling it viable by that time is anyone’s guess. This will make for a development period of only 3 years if we only count when the game became finalized around January 2017. Not too terrible for an RPG? Definitely too terrible if we count the full development time.

All The Reasons This Game Will Probably Fail

I’ve made a lot of weird games over the years, but this is the only time I’ve been worried about it (ironically this is simultaneously one of the least weird games I’ve made). Partially it’s the commercial nature of this thing, but mostly it’s because the oddness is more about taking things away than it is about giving new things. Flagrantly defying genre conventions by removing things is just far more likely to make players think a game is missing something or unfinished, than it is to make them think it’s cool. So without further ado, here is the list of some of the things that worry me about this game that have nothing to do with development (that maybe also doubles as the pitch for this thing I guess):

1. Constant Party Building

Most RPGs with party customization lock you into that same party for the rest of the game. Even the hand full of dungeon crawlers that don’t, make it a hassle to change up your party composition by demanding you level up new characters from scratch, and have heavy penalties for respeccing characters. This game demands you build a new party every hour or so, sometimes even mid-game. It wants you to experiment and find ways to overcome challenges with smart party synergy. This is a direct and blatant contradiction to most RPGs that lean incredibly hard towards commitment. Most people want to marry a class and never try anything else (until perhaps a replay), this game is designed to not even let you do that.

This is dangerous both because it defies player expectations, and because balancing the game to require different classes for each scenario is hard to do right: people might just always pick the latest classes, guessing that they’ll be the ticket. And some combinations will inevitably just be so good that they overpower intended strategies (but hey good for you- now go beat the final boss early as a reward for breaking the game)

2. Horizontal Progression

Most RPGs lean incredibly hard towards rewarding players with exponential power gains. You start as a peasant and work your way up to a god slayer. People love the sense of progression. That’s fun and all, but it also means most RPGs become jokes difficulty wise by the end because you have to balance towards players who do the minimum effort, and players simply have too many options to ever blindside them. We don’t have that: you have to start from scratch at level 1 with every scenario.

Considering how many people play these things just to grind, that’s probably going to be a real turn off. To make up for it, players unlock new classes as the reward for beating scenarios and challenges. These aren’t direct upgrades, but they do give new options for dealing with things. Will it be enough? Probably not, people are resistant to learning new things.

3. No Map Scrolling

Every map in the game is a single screen. You don’t walk within it, either. There are still NPCs, objects, and monsters to interact with, but this is an incredibly limited setup to do in 2019 (or 2011). It’ll probably make a lot of people write off the game immediately. But it isn’t a technical limitation: by focusing everything on a single screen, everyone stays on the same page in multiplayer instead of scattering in 4 different directions and having no idea what’s even going on. A whole lot of people like that sense of freedom to mess around without others, and will hate this game.

It also benefits people playing by themselves, though. The focus of this game is to be a streamlined RPG. By limiting exploration so tightly, players won’t waste time just walking around vast spaces, or interacting with every box, or fighting the same monsters 10 times. This is, frankly, one of the most bloated genres in existence with every other game boasting about its 100hrs of playtime. I think that sucks, but considering every time a 20hr RPG gets released and genre fans lose their collective minds about it I’m not entirely certain that anyone else agrees.

4. “Episodic”

In that same vein, the game is broken up into scenarios with no connected overworld whatsoever. I want players to be able to start up the game and have a complete experience, including a short story, in just 1-2hrs. Considering how popular wandering around vast, empty worlds collecting garbage for hours on end is these days, it’s another serious risk factor. The disconnected narrative with silent protagonists and minimal dialogue will also make a lot of people run away.

5. Turn Based Multiplayer

Turn based RPGs you can play with your friends online were basically unicorns when we started this thing in 2011. A few other games have cropped up since then where this is looking less like a risk, but it’s still likely to be something only a fraction of players touch. For whatever reason, the mere idea of playing a turn based RPG multiplayer was seen as absurd for a very long time. Which it shouldn’t be: being able to discuss the next turn or overarching strategies with each other is a fantastic social experience that you don’t really get out of action games where everyone can kind of just do whatever most of the time. But it still isn’t something most people care about.

6. Lives in an RPG

The game operates by giving players a certain number of “lives” for each scenario: die in battle, and you lose a life. Lose all of them and you have to replay the scenario from the beginning. This is a system that I expect to be wildly unpopular considering most people want a checkpoint before each and every battle these days. And frankly, I am so afraid of this reality that I will probably just include an easy mode that lets people do this. But the tension of losing progress, and the satisfaction of replaying a scenario with far more efficiency are elements that I genuinely think add something to the game and that I hope people will give it a chance. It’s honestly a pretty novel system for an RPG. But people are going to hate it, and possibly rage quit before even noticing the easy mode.

Update 11 Test Report


  • Added 3 new scenarios, totaling 4 (out of a goal of 10).
  • Several new classes, many balance changes, removed classes, etc.
  • Changed role system: players can now have any combination of roles instead of being locked into 1 tank/damage/heal/support per player.
  • Designed traps to fit in the new map style (triggering when moving away from them, providing a disarm opportunity).
  • The RPS(RockPaperScissors) that an enemy is using is now usually visible, though some enemies hide it.
  • Monster HP is now visible.
  • Streamlined quest scripting conditionals to be consistently used everywhere in the data instead of separate ones for quests/battle.
  • Stabilized data editor to no longer crash every 20 minutes (after ignoring this for years it ended up being a trivial error).
  • Added an autopatcher for tester convenience.
  • Continuing UI layout tweaks.

Test Results

Testers seem to be actively enjoying the game at this point. One who hasn’t tested in several years was surprised by it, even. Various UI nuisances are still a major hindrance, though. There are also balancing factors that are starting to crop up. One factor is the move from fixed role counts to free roles makes battles far more challenging to balance- all-damage parties need to be hindered by no recovery, all-tank parties need to die fast enough to deter players from getting into miserable battles of attrition, etc. This is pretty solvable problem, though the game is harder to balance in this regard since the system is deliberately built around avoiding focus fire (whether through aggro build up or front/back lines).

My bigger concern when it comes to quality at this point is the writing. Testers don’t give much direct feedback on it, and my own gut says it probably sucks. It won’t kill the game, but I wish I could find a means of getting feedback on it so I could improve.

With this test, “is this game good?” is no longer the driving concern (for the first time). It is finally just, “can we get this done fast enough?” (with a side of “can we make it polished enough in that time?”). This should be a relief, but it doesn’t feel like one. If anything there’s more pressure now because we’ll be wasting potential if we don’t pull this off.


While my original plan was to focus entirely on content until all of it was complete (for art production efficiency), I seem to be making a pit stop of cleaning up the UI further since we have a boatload of tester feedback on it now (I honestly didn’t plan on running a test this early but, uh, the testers wanted to play some more). In some ways this is good because we’ll have more time for testers to give us feedback on the UI than if we waited longer (and get more feedback focused on the content instead of the UI). But it also feels really bad in terms of slowing down production. No way to win.

There’s also a content question that I’m a little worried about. As it stands I can either make the average scenario length 1hr or 2hrs. The issue is that the number of battles in a 1hr scenario are so few that it pretty much has to be linear to work. While testers haven’t complained about the 2hr scenarios, the limited lives nature of the game makes me reluctant to ship it with scenarios where you can lose 2hrs worth of progress. Given our incredibly limited amount of time I’m inclined just to have a mixture of both scenario types rather than having to edit down existing scenarios (plus the brisk linear scenarios are good palette cleansers between beefy nonlinear ones). Things like simultaneous turns may reduce length as well.

Blog Catch Up: October 2016 – November 2017

With the UI changes being done enough for the time being, and the map readability partially complete I needed to get back to getting something done on the game itself in 2016 just for my own sanity.

October 2016

When we started the project the main goal was always just for a PVP RPG where players competed to beat the main quest before anyone else (occasionally teaming up when necessary, usually to back stab someone else), but when floating wild ideas for other things we could do with the board game setup the idea of a co-op was the one that always hung around. When the game was finally playable enough to try it years later, the response was almost universally more positive than the PVP experience. If I wasn’t an idiot I would have canceled the PVP mode then and there, and we’d be done with this game right now in 2017. Instead we maintained the two as separate modes for years to come (under the idea that we’d have a better chance of appeal with two distinct styles of play), with PVP always getting more attention since it was always the worse (battle lanes and rock paper scissors both stemmed from trying to improve it).

In October I was finally at the end of my rope for trying to improve PVP, and decided to start to combine the two in an effort to improve it. The idea was to make PVP a team based 2v2 affair rather than a free for all with fluid alliances. To that end I had to start building the game in a way that would actively chain teams together, with dead players still tagging along with their party rather than returning to town (in the original co-op modes there were actually some encounters where players would have to split up to fight different monsters simultaneously. It was super cool in concept, but hard to build class team compositions around). My favorite thing about this change is that we still allowed dead players a limited number of abilities in battle- a critical move for a multiplayer game to let players always be engaged.

November 2016

With the push towards making the two modes closer together, November was spent making co-op and PVP share the same classes. It was still pretty tricky making team compositions relevant in both 2-man and 4-man team sizes, but efforts were made to give every class unique PVP abilities to balance out their gaps. The class list as a whole was heavily based on previous co-op classes rather than the old PVP classes, since the new emphasis was on team work for the 2v2 format. Some important design strategies started to fall out of this process, the biggest being the move that saved our progression system by letting players buy upgrades/sidegrades to their core abilities rather than just stat upgrades or entire new abilities- players started feeling stronger rather than accumulating new niche abilities they didn’t have a place to use.

December 2016

The 2v2 mode was finally playable and the result was still underwhelming. Emboldened by my experience of cutting things earlier in the year with the UI, I finally made the hard call. It’s tempting to call it the hardest decision of the project, but maybe it was just the first time I actually made a real decision. I decided to completely cut PVP from the game, leaving only the vague option of a dungeon master mode after release (more to make myself feel better about sunk costs than anything).

I still had to figure out what a fuller co-op mode actually looked like in the new map system, though. We went through a lot of possible options before committing to one that had the lowest immediate cost: the trap and treasure decks would be merged into a single deck, and players would draw a card with each step instead of just once. Layered on top of this we started letting player choose how many steps to move each turn, but also put pressure against them with a turn timer that only let them take so many turns. As such, players had balance moving at a decent speed against the timer without having to draw too many sequential cards at once (enough traps could prove fatal).

The final touch was giving each player “map roles” alongside their battle roles to help them offset the luck of the deck: Leaders who decided how far to move and where to place their limited shortcut warps, support with limited card deck viewing/manipulation abilities, builders who could alter the spaces on the map, and healers who were a mix of support/builders with strictly healing.

January 2017

December’s map system wasn’t terrible. There was a lot of tension in trying to survive a dungeon (probably one of the hardest versions of the game), and it actually did feel a lot like a game. There were two major problems with it: having to do so many bland events in a row (“Got gold!”, “Got damaged!”, “Got Experience!”, etc. made up the bulk) made the game feel like it moved at a snail’s pace, and most of the thematic adventure feel had been drained from the game- it was more like watching your character step on rakes for two hours than a grand adventure.

The more obvious solutions didn’t seem great- reducing the number of events made it harder to create risk/reward decision making, more flavorful events would slow down the pacing further. We eventually settled on one of the more extreme solutions because it solved both problems at once: we’d drop the card system entirely, and instead make each space a unique event related to the scenario. The pressure to randomize the map each game wasn’t really needed for co-op since players would only play each map a few times (compared to a competitive game you’d play over and over with different opponents), and our battle system didn’t really lend itself for replay against the same AI to begin with. With such a system the game would finally start to feel like an adventure again as players had to make choices for each new event, and the pacing would feel much better with fewer events each turn.

February 2017

The static event map system wasn’t necessarily a rip roaring success from tester feedback (bear in mind everything was pretty much textual since we’re talking about a prototype that was stitched together in less than a month), but it hit an important, subtler metric that none of the other tests had done: testers were starting to engage with it as a game instead of an oddity. They’d discuss what equipment they wanted, spend points to advance their characters without prompting, hunted for secrets, and wanted to keep playing until they beat the scenario and saw the ending. For the first time it truly felt like we were on to something we could build on.

The first concept image of the room system.

With a successful prototype the question moved to “how do we actually present the world to players?”. The answer was the room system which you can read about here.

March-July 2017

While a basic prototype of the room system was tested in February (successful, but limited to the same map for every room and many other limitation), it would take until June for every system to actually mesh with it correctly. June-July were then spent building a map editor to actually construct maps for it (something that was never necessary before since maps were always randomly generated).

Because we’re old dogs the game uses psuedo 3d instead of actual 3d. As such, tiles are placed one z-axis at a time. This is a terrible choice because we can’t really pull off the lighting effects you’d be able to do in a real 3d engine. Had we started with the room system and didn’t start the game in 2011 we might have done otherwise. On the plus side we don’t have to pay licensing, and it’s kind of a unique look?

August-November 2017

At this point the game’s systems are solidified to the point where there really isn’t a ton to talk about. Smaller changes are still getting made parallel to content development, but not enough to warrant blog posts. While I could discuss the ups and downs of content development, that really seems more appropriate for a postmortem rather than doing it live (not that most players will ever find this blog before playing it anyway). I might change my mind, but don’t expect much more than occasional Update Test Report posts from here on out.

Progress wise we’re up to 3 scenarios out of the target 10. I had really hoped to crank out all 10 in the part of the year dedicated to content so 2018 could focus on polish, but that was hopelessly naive.

A Look Back

What I liked about writing this post is that it became very obvious that from November to February the game was pretty much a different game every month. While this thing has been mutating for years, that was probably the most rapid set of changes in its history. It was all leading up to its final form, and when you look at this post there was an obvious throughline of each version being a reaction to the previous.

I’d like to say that through these 6 years of development with 7-8 massively different versions of the game were all leading up to this final version of the game. But that would be a lie. The reality is that any one of these versions could have been spun out into a full game. The newly discovered fear of commercial failure kept me re-inventing the game instead of committing to a direction. The main issue with most of the versions is just that the map and battle systems conflicted with each other: had I just simplified the battle system I could have fleshed out most of these versions into full games. And frankly most of those RPG-flavored board games probably would have had a much bigger market than the co-op turn based RPG we’ve ended up with after going the other direction and cutting the map systems in favor of the long-refined battle system.

So the next time you know you need to cut something, but don’t want to do it: just cut it.

Blog Catch Up: August-September 2016

August 2016

This month was largely spent on wrapping up map terrain generation for the new tile style. In retrospect it seems like I mostly spent it burned out, though.

September 2016

At this point me and Sew had got together and started trying to solve a lot of the issues with information presentation in the new map style for the past several months (by which I mean I told Sew how the map worked and he had to sort out my mess). At this point I was finally starting to implement much of it. The main thing was just to start introducing a consistent visual language to the map:

The spaces themselves would be used to indicate what happens when players end their movement on them. The bulk of spaces would be simple blue/red colors to give the map a cleaner look, while the rarer special spaces would have imagery to indicate what they do.


Objects that “intercept/interrupt” movement would appear between spaces. Objects that trigger when passing by would appear above spaces.

We used bubbles to give detailed information about a specific object. The “!” signs indicated something that would happen to you, while the fist signs were attacks you could do to other players.


I’m actually still pretty happy with most of the work we did for this map style. If we ever revisit the board game format in a different game we can probably reuse a lot of the work we did here. That’s how I convince myself to sleep at night, anyway.

Blog Catch Up: April-July 2016

April 2016

After spending two months struggling with the UI, I was at an impasse. At the same time, a game called Stardew Valley had recently come out. While being heavily based on the console game Harvest Moon, it still used a hotbar UI common in PC games for its interface rather than strictly adhering to its inspiration. It took awhile before it really sunk in, but I finally realized I was getting way ahead of myself. Our initial release was always going to be on the PC. It was idiotic to try to build a console-style experience first and foremost (even if shared screen multiplayer had become a minor phenomenon on PC). And while I always wanted to make this game feel like a console-styled RPG, you can capture that feel without crippling your interface for your primary audience.

One of the earlier concept pieces for the new PC focused interface.

The new interface completely gave up on the concept of simultaneous hotseat multiplayer and focused squarely on the online experience (though turn based hotseat remained as an option). The most obvious change is using an MMO-style hotbar for common actions (moving, attacking, ending turn, etc) and abilities. This was to address the common issue of testers getting a new ability and completing forgetting it as an option- it’s much easier to remember when it’s always in your face. The other major introduction was an “offline info” tab panel that let players look at stats, equipment, shops, and other information even when it isn’t their turn (addressing another major tester complaint that they couldn’t access anything when it wasn’t their turn). The implementation for the new system proceeded immediately and took up the rest of the month and then some.

May-July 2016

These months were a mixture of doing long outstanding improvements to the UI (properly splitting up long chat text), continuing engine improvements (using a proper sprite atlas generator instead of cobbling them together by hand, supporting flipping specific frames), continuing the new UI (updating targeting systems for clicking on targets instead of the gamepad-focused list of targets, improving hotbars), building the new battle turn order display, etc. In short: lots of bland, but necessary work.

One of the few novel changes at this time was displaying possible attack types directly on the characters (with larger icons when they have more of that type), and then transforming them into weapons/shields that react to each other to inform players of how the system worked. While visually bloated, this seemed to fix most tester confusion.

Blog Catch Up: February-March 2016

Unfortunately, I’ve put this off for so long that it’s going to start being difficult to accurately remember the process at this point, even with a reasonable amount of internal documentation. I don’t want to completely give up on documenting this thing, though, so better late than never.

For context, the UI circa 2015 looked like the above. Most menus were similarly list based in hopes of making it easily translate between mouse and gamepad. It was a confusing, bloated mess that testers hated. Most prominent was that people constantly forgot what abilities they even had since they were buried in awkward sub-menus.

After a great deal of UI concept work in 2015 (some of which made it into the game, but still wasn’t good enough for testers) it became obvious to me that just shipping the entirety of UI work over to artists with basic specifications of what I wanted was actually a really stupid way to build a UI. Don’t get me wrong, game designer UI shouldn’t make it into the final product, but you should absolutely try to do your own rough drafts of UI before telling other people what to do. Why? Because if you don’t you end up being an idiot asking for the impossible. You need to understand the basic problem space created by your designs, and where to cut things back to accommodate reality. Once you get to that point you can let the artists take it the rest of the way, both functionally and aesthetically.

In general the theme of this year would be the year we finally started to accept the limitations of reality and started to cut things back. When I started the UI overhaul I was still committed to a few things: the game should be playable with a gamepad, and players should be able to play simultaneous multiplayer on the same computer/console. So the first design that made it to production (after many, many attempts) heavily reflected this in the form of the “4 corner” system:

This was one of the last concept versions of 4 corners, but there were dozens of variations (including Lufia-style input)

The idea was to give each player their own dedicated menu in a corner, giving us a balanced symmetrical look. It had a variety of advantages: online you could always snoop on what other players were doing, it allowed simultaneous input even on the same device (giving testers the long-desired ability to do things when it isn’t their turn), and it was much better optimized for gamepads. But it had a major problem: the game really wasn’t designed for such small menus.

I churned out pages of documentation on how I could crunch down the existing menus into the tiny little window. It just wasn’t working. PC players would especially hate it since they can’t even stand games designed for gamepads, letalone cramped interfaces made for shared screen play.

All the way through March I was stymied on how to make it work and just kept churning out attempts. On a positive note unrelated to the 4 corner design itself I had finally learned to cut down the character status information to only what players need at a given moment (just HP and potions in battle, gold when it’s your turn on the map, etc), I started presenting the turn order in a legible iconic format instead of the quick hack of numbered ordering we had been using for years, and I finally gave in and used icons instead of cheaper text menus for the sake of being able to compress things down visually. These are the elements that I had to get my own hands dirty in order to accept: if an artist told me to have fewer stats on screen my response was “that’s really annoying when RPGs hide stuff!”, but when having to play UI Tetris yourself the problem becomes undeniable.