Last week’s entry ended in me trying to decide whether to go with a row system or a threat system for mitigating damage in team battles. But neither solution really felt right. In the case of a row system you end up with characters with stats built for team situations being completely overpowered in non-team situations, and in the case of the threat system you also ended up with abilities that are useless in 1v1 situations. And that core problem is what the solution was born from: the need to make a primarily 1v1 system still work in 4v4 situations.

This is the lane system. It’s quite simple. When two combatants are opposite each other, they form a lane (the lines in the diagram). Most attacks can only target enemies in a character’s lane. So in this case 1 can only attack 5, 2 can only attack 6, etc. Effectively a 4v4 becomes more like 4 1v1s occurring at the same time, so the possible damage range for each character remains about the same as it would be in a 1v1. Naturally allies can still target one another freely, and the extremely valuable attack-all abilities will still target all enemies regardless of lane.

In the case of unbalanced teams, multiple lanes get formed:

Most lane attacks are still single target, so the disadvantaged player gets to choose which enemy they want to attack. There were ideas to still only create one lane in cases like these (making the second character on the 2 side just be support), but it was decided the majority deserves an advantage in these situations. In some rare circumstances this can actually be advantageous to the minority side by exposing a weaker character to them, but the double damage they end up receiving still makes this a minor advantage.

With this much positioning being introduced to the system it only made sense to introduce multi-target attacks that are directional. For instance, “attack all enemies left of your lane”:

This creates situations where the far left and far right slots become more valuable than other slots. Since position is now important, I had to start introducing abilities to let characters move around. There’s a whole lot of flavors available: move left/right of my current slot, move to the slot of a certain enemy, move an enemy into my lane, swap my slot with a specific ally, etc.

From this roles start to emerge in battle. Tanks want to keep damage dealing characters aligned with them instead of fragile allies. Fragile healers want to keep their slot away from the damage dealing characters. Damage dealers want high maneuverability so they can align themselves with weaker characters. Attack all characters want the highly valuable far left or far right slots, the enemy team wants to keep them away from those slots, etc.

For the most part I think this is awesome and adds just the right amount of depth that the game was missing. It doesn’t really slow down pacing since position changing abilities will have the same rule as everything else in the game: “you can do something special, but always deal damage at the same time!”. What I worry about is how the battle system’s turns operate: everyone picks their action, and then the turn happens. This can create some extremely hard to follow position changing depending on the turn order and the enemy team’s influence. Changing the turn order to be one player at a time would fix this problem, but it would also cripple the game’s pacing so it’s not really a viable option. For the time being I plan on going full-tilt with the system and seeing how confusing it gets in testing. If it becomes too much, there are probably rules that can be imposed to make it less confusing (no moving enemies, only 1 move per turn, etc)

 

---

You might recall the threat system having the problem of introducing mechanics for team battles that become irrelevant in solo combat. On the surface the positional system sounds like it has the same problem. Who cares where you are when there’s only one enemy? But there’s actually lots of cool stuff that can be done with it. We could place bombs on the battlefield, if you swap a bomb directly opposite an enemy’s slot, then it would explode on them. Another option that is also beneficial to team battles would be to have status effects that are bound to specific slots. Suddenly being able to move to the right becomes very important when it means getting out of poison or into a defense bonus! So as it turns out the positional system can add just as much to 1v1 as it does to 4v4.

---

 

I was reluctant to add another system to the game this late in development. But the reality is that this fixes the problem. Not only does it fix the problem, but it also adds exactly the right amount of extra depth that I was looking to add to battles. So I think it’s worth it. In that general vein, I’ve started to go into more of a crunch schedule so I can get this thing done already. The first fruit of this schedule is that I’ve already implemented the system I just outlined above in the same week that I came up with the design of it. The 1v1 enhancing features I described haven’t been implemented yet, but my current plan is to build co-op classes and battle encounters around the new system in order to test it out. If it works well in co-op, then I’ll add the 1v1 features and rebuild PVP around it. So that’s my goal for this week. See you then!

This week went pretty well. Everything needed to support a single client controlling multiple characters wrapped up without a hitch. All the stuff needed to support multiple scenarios was also finished, including globally enabling/disabling PVP (and all the related stuff of having pve/pvp-specific classes). It’s now all about actually building the first co-op scenario itself.

At this point I have a pretty good idea of what the plot of the scenario is and how it’s going to function. The real troubling questions right now are how to deal with all the issues surrounding co-op itself. Primarily, making a game where large scale battles (4v4) and small scale (1v1) can co-exist in sane ways.

1. Scaling random battles

The current thought process is to make random encounters scale to the player party sized. So a party of 3 people will always be fighting groups of 3 monsters, part of 2 always fighting 2 monsters, etc. This should ideally create an effect of “Parties can move faster, but have to face riskier battles”.

But this effect is probably still a little too potent right now. A party of 4 people can effectively clear 4 tiles in 1 round, while a party of 1 person can only clear 1 tile in 1 round. This is quite troublesome since one of my goals with co-op is to create situations where people need to split up, but it’s hard to make that time efficient when a full party has such a major speed advantage. The other downside to scaling encounter size to parties means that players in parties will still be gaining the same amount of experience as  solo player would instead of gaining a reduced amount from the experience split.

So unless large group monsters are ridiculously risky, players still have far too big of an advantage when in a party. And we really don’t want large group monsters -that- risky since grouping should be a common occurrence in co-op.

2. Dealing with Focus Fire

A 4v4 battle introduces a big problem with focus fire. If you can freely target any character on the battlefield, then it’s entirely possible for the monsters to just focus fire a low hp target such as a mage and kill them in a single turn. You need some kind of target limiting mechanism to make this a little more strategic.

The traditional way for a turn based RPG to handle this sort of thing is to just introduce front and back rows. Only front rows can be damaged or deal damage with physical attacks, while ranged attacks can hit both rows. (In some variations the front/back row thing ends up just being a defense bonus instead of completely disabling targeting). There’s a lot of problems with using this solution directly though: our art isn’t really set up for it (though we can cheat by using offsets to imply it), it requires players to set up their rows every time they form a party, it’s very much built around heavily defined roles in combat which becomes difficult to support in a game where 4v4 and 1v1 battles are expected to co-exist, etc.

Alternately we could adopt a threat system that has become common place in real time RPGs (I’m actually not sure a turn based positionless RPG has ever used this type of system?). While typically a strictly AI system, I’d probably make it equally relevant in PVP (since this system is used largely in real time RPGs they usually substitute threat for position and being a nuisance, but since we have no positions the threat system would continue to act as a substitute). Lots of ways to build this- either only high threat sources can be targeted, or having low threat grants a heavy defense bonus. Makes more sense with our visuals. Potentially injects a lot of strategy into a game that is relatively low on that right now.

3. Dealing with Damage

Of course even when we implement one of the above systems to cope with focus fire, we still have problems going between 1v1 and 4v4. If we build a tank designed around withstanding the focus fire of 4 other characters, then they’ll be practically invincible in 1v1 (albeit take more turns to kill their enemy, and have a bunch of threat management abilities that are now useless in 1v1). In theory we could do stuff like multiply damage output by 4 for 1v1 to make up for it, but that doesn’t seem right. It’s something I need to think about. It’s a problem that MMOs encounter a lot when dealing with solo vs grouped content, and it usually results in solo content being extremely boring since enemies have to be flatlined to be defeatable by all roles. The solution may be to just have specialized classes exclusive to co-op (and expecting everyone in co-op to always be in a party of at least 2), while making everyone more of a generalist in PVP.

Work on the control-multiple-characters-with-a-single-client system carried on this week. When calculating the initial cost I failed to consider having to revamp the voting system that occurs simultaneously when players have to decide on things (ie quest branches or whether to join a party).

This became quite the task since I ended up having to redo the entirety of these menus with the newer system, since it was easier for it to deal with the changes rather than update code that is scheduled to be thrown away. Since the new UI system isn’t quite all there this led to a few problems relating to its current deficiencies, as well as stumbling into a bug that took quite awhile to work out.

At any rate, it’s finished now. So all that remains is updating the battle system for it and we should be good to go. I don’t expect the battle system changes to take that much time so I’m sure I’ll get up to something else later in the week.

I returned from the break pretty much where I left off: without much idea of where to take the final refinements. Left with no design goals, I decided the best course of action was to start developing a prototype version of a co-op scenario. It’s the best move in this situation for a whole lot of reasons:

1. Co-op creates a new set of problems

It’s quite likely that what’s needed to improve co-op will be far more obvious than what’s needed to improve the competitive game. These changes then have a very good chance of feeding right back into improving the competitive game, or at least give it the depth that it’s missing. In short, I’m hoping that seeing what needs to be added in a pure co-op mode will also be what’s missing from the other mode. If nothing else, I’m a lot more confident in my ability to make a rad co-op game than I am in my ability to make a serious competitive game.

2. Co-op might end up being the main game mode

This one has been on my mind for awhile. The only reason I began development by focusing on PVP is because it needs the most attention to be functional. A completely traditional JRPG would be largely dysfunctional as a competitive game since they’re primarily built around surviving and discovering AI patterns. When foes of similar power face off, battles tend to be determined by superior stats. With this in mind I went about by building the system to work for PVP situations first.

But in reality the game itself probably lends itself to co-op the best, since the foundation genre is built for PVE. Not only that but one of the biggest struggles with this game has been making combat work when you control only one character. Co-op alleviates this by having a whole lot more battles with other participants, adding a dimension of team work to the game. Even the map gameplay lends itself well to cooperation by forcing players to think on their feet and coordinate wise tactics where they have to split up. Combine that with the fact that it’s a much gentler introduction to the game than a competitive mode where new players will be at a disadvantage, and the fact that most fans of the genre are probably looking for a PVE experience and there’s a very strong chance that co-op will be the premiere mode of the game. If it DOES end up being the better part of the game, PVP might turn into more of a side attraction than the core game. Ideally I’d like to do both well, but if co-op is a better game and is more easily improved then it may just end up becoming the game.

3. Co-op requires some long-desired features

From the start I thought it was really dumb that a turn based game wouldn’t have a hotseat mode. It was a time saving choice since adding it would require adding to the functionality of the battle UI to account for multiple characters. But when the time came to think about co-op mode a problem arose: how do you scale the game to work with different numbers of players? The problem compounded when you factored in that I wanted stuff where players would have to split up on the map to efficiently achieve goals.

Eventually I decided the only viable solution was just to make it so players can control multiple characters if desired. So it’s this nice case where I solve a problem and finally have an excuse to add hotseat play while I’m at it. Since I’m mucking around with that part of the code anyway, I’m adding observers to the game as well. The main reason is just so I can have people test them game without playing it myself, which will allow for less biased test results without having to write a full replay system.

4. Co-op is a simpler single player mode

By letting players control multiple characters we basically allow co-op to be played single player by letting all 4 characters be controlled by one person. This could either be really cool or a total disaster. But there probably won’t be time to add proper AI (co-op mode is too complex for AI anyway, and PVP probably wouldn’t be that interesting with bots even if we had them), so this is at least a chance to support some single player. It could even be -too- good where people don’t find the game as enjoyable when only controlling one character. But given the huge risk of a small game being multiplayer focused, I’m glad to have some potential single player support.

———————-

This week I started off by adding support for controlling multiple characters. Along the way I had to decide how to implement the UI side of it. This opened old wounds that our interface for battles still isn’t really intuitive. It boils down to this: most RPGs have you select a command and then a target. This game has you select a target and then a command. It’s this way because that’s the easiest way to minimize the amount of mouse movement required for an action (typical console RPG input becomes very painful with lots of repeat, excess movement if you directly translate an interface made for a gamepad to a mouse. To fix this I’ve taken great pains to reduce the amount of mouse movement required for input). This is an effective method for comfort, but it has created a great deal of confusion among testers expecting a more typical interface. It’s also worse for perception of abilities since only abilities that are relevant to the target are displayed and since the most common target is the enemy, it’s easy to forget that you even have ally targeted abilities.

Thinking about it from this angle, I came up with a new interface concept that’s fairly similar. The idea is to just use the typical RPG menu structure. We can still minimize mouse movement by having the newest selection window always be created in the same are as the previous select. So the “attack/defend/ability” menu would move out of the way for the ability selection window after the selection was made. Once an ability is selected, the turn order list would stretch further out to reach where the mouse was hovering. The downside is that players become less attached to the visual positioning of combatants since they don’t have to target using them, or (worse) they still click on the combatants directly and create unnecessary mouse movements for themselves. I’ll need to see it in practice to be sure, but it has potential to be more intuitive than the old method.