Update 5 Test Report


  • Added a co-op mode, including a new main quest for it.
  • Implemented new Lane battle system to keep damage output steady between 1v1 and 4v4 battles as well as updated monsters to cope with it.
  • Created all new co-op classes designed around playing specific roles.
  • Switched to new class system where players choose only one class that progresses across the entire game, instead of mixing 3 classes.
  • Limited party movement to be roughly comparable to a single player, randomized turn order for each round.
  • A multitude of functionality improvements (Sharing shop access with party members, expanded battle ability lists, displaying possible enemy attack types, monster encounters scale to party size, monster transformation/spawning, controlling more than one character on a single computer, etc)

Test Results

Early results seem to indicate testers being largely positive about the changes so far. In particular engagement seems to be higher in co-op due to the fact that every player gets to participate in every battle most of the time, and every map turn is directly related to them (so there are few opportunities to wander off and lose focus while waiting for your turn). Some small issues with the rock-paper-scissors system being harder to follow with 8 characters being involved (and not so important that you will die by ignoring it), and potential power issues with debuffs given the current battle speed. Nothing to act on until further testing, though.

On my part I’m worried that the game length is possibly way longer than an hour in co-op and may need to be trimmed down further (Either by reducing the number of battles or the progression length). But this, too, requires further testing to be sure.


At this point combat is about as good as it’s going to get. To help out PVP I’ll probably add a limited number of quest objectives that force cooperation (as well as PVP), to make sure it doesn’t stagnate with just 1v1. I have a number of 1v1 enhancing features for the lane system (slot traps/effects etc) I’d like to implement, but they won’t be a priority for the time being since there are bigger issues. Likewise allowing players to control monsters may add a degree of “always playing the game” to PVP as well, but just isn’t high enough priority to add any time soon.

The remaining Big Problem is simply getting the map game up to snuff. The new monster den system sets up a reasonable foundation, but I need to put meat on those bones already. My long-established guideline for it has been “the map should play like a dungeon” and that’s basically the angle I intend on build on though I don’t have any solid plans for it yet. In addition to the map itself, I want to finally implement player abilities that interact with the map (place down healing stations, put up traps for other players, warp themselves around the map, etc allows for interesting classes and more interesting map play).

I still want to get the fiddly RPG bits (more interesting equipment choices, more customization class progression, etc) to be more satisfying as well, but the map comes first. It may also turn out that these fiddly bits end up being part of the map as well.

Aside from that I also need to get PVP operating again since the co-op changes pretty much broke it. I mostly just need to rebuild the PVP classes to work in a single class system, but there are a few other improvements to the basic PVP formula that I want to add (mostly just killing other players to clear monster dens). Getting PVP up and running again will likely be the background task I work on while designing how the new map needs to work.

As you can tell by this laundry list, finalization certainly isn’t happening by year’s end. But I also don’t think it’s unattainable by February or March, as long as improving the map doesn’t require too drastic of changes. At any rate, I’m just glad that the game is visibly improving with each update.

November 23rd, 2014

This week saw the completion of implementing new monsters and the wrap up of planning the prototype version of the co-op quest. So we will almost certainly test it out this week. That’s about 2 months from start to finish to implement co-op mode. At this point it’s blatantly obvious that I probably won’t be able to hit finalization this year, most likely I’ll go well into March with it. Not ideal, but not much I can do about it.

On the bright side I am pretty excited about testing this update with other people. I don’t like to say too much about my personal feelings about an update to the testers since it likely influences their opinion, but so far the lane system is on par with the monster den system in terms of “this was a good idea that is turning this project around”. My initial personal testing was basically the first time it felt like I was actually playing an RPG with this game. It’s also incredibly confusing to test by playing as all 4 players yourself since there’s no visual indication of what each class everyone is in-battle yet (and names are just numbered). That won’t be as big of a deal in multiplayer since everyone will be familiar with their own class and will associate the other players as needed (though even then we’re going to need to add some visual indication).

If this test works it will then be a matter of fixing up PVP to use the new systems from co-op (mostly just new classes), and then doing my best to improve the map aspect of the game. I feel rather silly spending 2 months mostly just fixing up the battle system when the world map is the most in need of attention, but it had to be done.

November 16th, 2014

Implementation of the sample co-op classes was wrapped up this week. It was a bit slower than expected because I actually managed to produce quite a few old battle system bugs thanks to the more intricate class abilities, so I had to stop and fix them. I’m starting to notice that any time I have to rebuild content is basically the biggest time sink in the project at this point. The big content hogs at this point are now building the new monsters and the new co-op quest. There’s a few tweaks I want to do before the next test as well, but they’re easy enough to do in between.

My big worry at this point is basically players exploiting battle scaling in co-op (in PVP it’s not as big of a deal). It’s like this basically: If the 3rd monster in a certain random battle formation is the one that gives the players trouble, then it might be in their best interest to split up into 2 parties of 2 players in order to avoid having that particular monster spawn. I don’t think this is too big of an issue since co-op classes are designed to work best in larger groups, and there’s still a battle speed advantage in that big parties get more battle turns before causing a new round to happen. But it’s certainly something I have to be careful with because I really don’t want to provide incentive for obtuse player behavior .

November 9th, 2014

This week saw the completion of co-op class design. The design process was a little more arduous than last time due to single classes requiring a different touch from triple classing. There’s not a whole lot to talk about with the design process itself, though. The focus was to give each class an advantage in certain situations and to have more synergy with certain other classes. Not much mind was paid towards balancing absolute power levels between them just yet, right now I’m just trying to create interesting play styles. Balance will come later.

The other big issue of the week was balancing party movement. The old system was that, when partied, each player in the party could move on their turn and bring party members with them. The end result is great for pacing (everyone still gets a turn), but terrible for balance. In PVP this merely resulted in parties being hugely advantaged over solo players (being able to clear as many monster dens in a turn as their number of party members while having a battle advantage to boot), but in co-op it’s an even bigger problem. I want to have co-op objectives that require parties to split up in order to be more efficient with timers. If a full party has a near identical move rate combined with extra combat efficiency, then there’s no real reason for them to split up.

The most obvious solution to this problem was to cycle through each player in a party each round to decide who gets to move the party for the round. This was pretty unintuitive and also created issues (if player C leaves the party after A,B have already done their turn for the round, then the party ends up unable to move). Crazier solutions were considered like merging parties into a single turn taker. Lots of overhead.

I eventually settled on a much simpler solution. When moving in a party, every player has their stamina drained from the movement. To give every player an opportunity to move the party, I also added shuffling the turn order each round based on agility (more perfectly even ideas were considered like cycling the first turn player ie (A->B->C->D)->(B->C->D->A) but this results in one player having to wait 6 turns for their next turn every round which is terrible pacing). This actually has some pretty cool implications for PVP since it allows players to actually have a chance to catch up to other players that they’re chasing. As a last necessary tweak, I also made it so players can’t move after having initiated combat in a round (since parties were still technically capable of multiple battles in a round, albeit not as much as they had before).

This system still isn’t totally there since it creates many turns where party members have nothing to do but end their turn (which is especially terrible in single player). In a truly ideal world there will be an option to access other party member’s menus during the party leader’s turn, as well as leave a party even when it’s not your turn in order to avoid these “pointless” turns completely. But I want to get a feel for how a more constricted party plays before I clean it up.

November 2nd, 2014

This week was pretty much all about the slow climb of designing all the new stuff for co-op (classes, monsters, quests, etc), and building the new systems they depend on (scaling encounters to party size, adding spawn/transform battle actions for more gimmick heavy battles that co-op is better suited for, etc).

When I actually sat down to design new classes for co-op I finally had to admit an uncomfortable truth to myself: this game is just not that well suited to heavy character customization. On a mechanical level you need a certain level of fluidity to make the kind of customization I was pushing for work. But the game isn’t that fluid, it’s more rigid. So when I kept trying to inject such heavy customization into it, players were just ending up with generic characters built to compensate for each subclass’s shortcomings so they could do anything, rather than classes that pushed them into interesting advantages and disadvantages that require using different strategies to compensate. It wasn’t especially obvious in PVP, but it’s blindingly obvious in co-op where you’re trying to build very specific roles for each character.

I spent a lot of time trying to think of another class system that still offered limited customization. Nothing really seemed right. So I just went in the complete opposite direction: players pick one class, that class has a completely static progression. If this works well, I might go back and inject some mild customization into it. Or I might just leave it alone.

I’m still in the process of designing these classes. I did most of the necessary programming additions while deciding on what route to go with classes, so next week will primarily be focusing on design stuff. It’s a little harrowing. This is probably the third time I’ve built sample player abilities, and the fifth time I’ve had to redesign or heavily alter the monster encounters. It’s starting to feel like I’ve been remaking the same game over and over. Here’s to this hopefully being the last time, even though it’s probably not.