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

Changes

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

Next

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.

 

Update 10 Test Report

Introduction to Rooms

Since I haven’t been posting regularly, I’ll do a quick catch up on the biggest change to the game. After the success of the previous test having a more traditional co-op format, it became clear that the old board game style map view no longer fit the game. A lot of alternate approaches were considered such as just making each node on the board game map its own much bigger space space and stitching them together as one huge map. But that would generate a great deal of artist work (transitioning between areas), and our map engine was struggling to deal with large maps and I didn’t want to take any more time to optimize it. So we came upon a much more efficient solution: the room system.

The first concept sketch for the room system.

The basic idea was that we’d move the overworld into a simple minimap, and make the battle display a permanent fixture even when outside of combat. As such, every space on the old game board became its own room. From there it became obvious that we could fill rooms with objects with various interactions- talking, opening, etc. This added a lot of missing context from the previous builds where it was often unclear who was talking or where the treasure just came from.

The final result (for now, anyway)

The end result is far more suitable to the more traditional RPG format that the game has mutated into, letting players explore and interact with an actual world.

Changes

  • Map style shifted from linear sequence of events with optional sequences on a zoomed out overworld to freely moving between connected rooms.
  • Objects in rooms are interactive with specific actions related to them (use, break, unlock, talk, etc), and NPCs can move around in patterns.
  • Text boxes now stem from their speaker’s sprite.
  • Basic cutscene support with NPCs moving around and animating in response to events.
  • Created a new scenario involving a haunted castle.
  • Various usability improvements (a more prominent turn indicator, shifted UI elements around, etc).
  • Various balance improvements.
  • Built an entire tile map editor (unimportant to players, but a required time-consuming step due to the system shift)

Test Results

Due to tester availability, testing wasn’t as extensive this go around- using fewer groups and only progressing part way through the scenario in some cases. As such data is pretty limited: people seemed to like the new map system, some old UI failures still haunt us, some UI improvements worked perfectly (players rarely fail to notice it was their turn now). It kind of doesn’t even matter. It’s painfully obvious this is the correct direction even without external validation, we just need to keep going.

Next

There’s one major feature left on the table: simultaneous turns (along with several larger features like saving/options). It’s tempting to get the last of these system-level tasks out of the way first, but in the interest of laying the foundation for graphics production (and giving myself a break from system code) I am instead moving on to content production and furthering our mechanics along. Update 11 likely just looks like a new scenario or two, a larger plan for the story as a whole, improving how our classes play, cleaning up status effects, giving a final pass on how our stats look, etc. A real hodgepodge of finalizing things to make content production smoother.

It’s terrifying to be committed to a system (what if people don’t like it?), but also relieving that we’re finally moving on.

Update 9 Test Report

Changes

  • Shift from board gamey roll-to-move and heavily random events to a more static, dungeony, linear approach to map design (including removing the deck based event system). New map style features days that get drained by resting/dying rather than turn timers.
  • Completely dropped support for a PVP mode to focus entirely on co-op.
  • Switched back to a diverse set of classes that fill very specific roles (partially based on previous versions of co-op classes)
  • Complete redesign of user interface more in line with PC-style hotbars rather than vaguely console-styled submenus, as well as including information menus accessible even when it isn’t your turn. Switched types to Rock Paper Scissors and a more visual display of types breaking other types during attack animations.
  • Equipment Point progression system changed to primarily feature upgraded versions of core class abilities rather than entirely new abilities.
  • New equipment with more synergistic abilities for the classes.
  • Completely new art style (including new map tile style).
  • Honestly since this update took over a year, probably things I’m forgetting.

Test Results

It’s hard to even process the response at this point, I guess. Testers who play rarely were still initially confused. Some of them seemed to get over it far quicker than they used to (whether from new UI or experience is another question). That said, I’m not drawing too many conclusions from it since part of the problem was the test scenario’s difficulty being cranked up fairly high since I wasn’t originally planning on wider testing, which makes the learning curve frustrating. Most confusion problems can really be placed into one of 3 categories: UI needs an artist pass to be pretty and also emphasize what’s actually important, missing effects (sounds, visuals, etc) create confusion, and no learning curve in the game’s content. These are all things that just need done, rather than requiring an overhaul.

While the response wasn’t overwhelming, the smaller details of how testers played were far more encouraging than previous tests. Players discussing the equipment they wanted, actively seeking out EP abilities without prompting, refining party builds between playthroughs, hunting for secrets in the choices, reacting to some of the bigger surprises, wanting to play again until they beat the demo, etc. It was a lot like watching people play a game. It’s pretty clear the co-op focus was the right choice. Timing wise the games consistently hit 1hr 20mins for experienced players, which is still higher than the target time of an hour. Additions like simultaneous turns will probably speed it up, and beyond that I don’t care quite care as much about perfect lengths now that co-op is the focus.

Next

Reading the last update report’s next section is distressingly like looking in a mirror. A year later we’re still miles away from finished, yet still purporting a “get it done” strategy. The reality is that 80% of 2016 was spent on the UI overhaul. That remaining 20% has been frantically spent changing our course to get the game finished.

What has changed is that we’ve fully dumped the PVP mode in the name of focusing on what the game is doing best right now (which is pretty much combat). From there we’ve vastly simplified the map to create a more traditional RPG experience. For all the years spent trying to make the map work, the reality is that it had too much going on which made it vie with the also complex battles. One had to die for the other to live, and we chose the one that’s already good.

What’s next, then, now that we have a working prototype with Update 9 is to change the map presentation to fit its new systems. A change I loathe doing when we need to get the game done, but necessary. It fits alongside the other major architecture change of making the map support simultaneous turns. From there, it’s a matter of finalizing the mechanics, planning the complete content of the game, and then implementing it. Once the foundation is rock solid we can finally start full production on the assets, add missing features (saves, settings, etc), and generally just GET IT DONE.

We’re not in a good state, but it’s better than it was.