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

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

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.