August 2013

A day in the life of a bug fix or: the escalating ramifications of underestimation

August 25, 2013 Hawk

The Bug: Clearing a “defeat monster” solo/party-exclusive quest objective during someone else’s turn who is not in your party ends up not crediting the kill.

A solo objective basically specifies that only the quest owner can fulfill it. The battle system doesn’t restrict players based on its originating quest. So the possible solutions:

If someone completes someone else’s solo objective on their turn, it still gives credit exclusively to the quest owner.
If someone completes someone else’s solo objective, it counts as progress for the owner but the reward goes to the person who completed it
Just don’t let people into a battle if they don’t own it or aren’t in the party of the owner.

1 opens an exploit for players to deliberately not finish their solo quest battles in hopes of forcing some other sap to do it for them. 2 defeats the entire point of having player-exclusive quests. So 3 was clearly the solution to go for.

But it opened up a new problem: if the quest owner of a party quest (a quest restricted to the owner and other players in his party) died in combat, the remaining party members would be able to kill the monster without actually owning the quest. The solution to this problem is to boot out the remaining players from the battle should the quest owner of the battle perish. A little excessive in current builds, but will be plenty manageable in the future when the bleed out system of having X turns to use a revival item on a dead player is added.

A relatively simple addition from this issue was that if a player tried to engage in a solo battle with a party, the party needed to be disbanded before starting the battle.

The original design was to strictly have one battle per tile- largely to allow NPCs to be effective roadblocks even mid-combat. But with fairly radically changes to the way maps function that purpose had largely become irrelevant. With battles now having quest restrictions on them it became quite clear that there needs to be multiple battles per tile simply to prevent multiple quest battles from overriding each other. Adding such support was fairly extensive, including revising the battle join menus to ask the player which battle they even want to join. Along the way usability enhancements were made that didn’t exist before: listing the battles happening on a tile when hovering over it, identifying what quest a given NPC is associated with, and directly indicating whether a quest is solo, party, or global restricted.

It was quite the bug. Though it was less bug and more insufficient consideration of the implications of certain systems interacting together.

Dependency

August 18, 2013 Hawk

This week’s big issue revolved around zone pathways. Last week I showed off this theoretical image of how to place zones in a grid, but offset the position of the node to create an illusion of breaking up the grid:

(it’s worth noting that the top middle witch hut isn’t actually a valid position in this image)

As it turns out, actually competently generating this is something of a chore.

Red lines represent the different points that roads can come from.

In this system locations are composed of 3×3 tile squares, with a single tile buffer between them (4×4 and up aren’t really viable due to tile size relative to screen size). Being a grid, there can be one roadway coming in on each side. Our road system isn’t sophisticated: the presence of a two road tiles next to each automatically connects them- no independent roads that are adjacent but going in different directions. The ultimate goal is to place the node (a town, a dungeon, etc) in a location such that every roadway uses it as the crossroads so that the pathways between zones are visually clear to the player: therefore each roadway must not touch another or it will create a second crossroads. With only one or two roadways, the position of the node can be anywhere within the grid. Once you hit 3 roadways, certain node positions are impossible relative to the roadway positions. At 4, every roadway needs to directly intersect.

The problem this creates is interdependence between every zone. A zone with only 2 connections, one of which has 4 connections, must place one of its roadways based on what the 4 connection wants. With enough 3/4 connection zones present, it ends up with a fairly uniform placement despite the effort to do otherwise. It’s also a pain to process when altering one zone can have ramifications on all of the others.

So I dropped it. Because it’s not that important relative to the amount of work it was going to take. And went for total uniformity:

It looks alright. It’s also slightly more readable than the version with offsets. There may come a time to improve the look of it. That time isn’t now.

Map Readability

August 11, 2013 Hawk

So this week we got to do a play test for the first time in several months. Play tests are probably one of the few morale boosts this team has, one of the big advantages of making a multiplayer game. I also noted that my productivity went up like crazy the day before the test because I wanted to fix up various things before hand. It’s always hard to artificially make dead lines for yourself that feel real, but scheduled weekly tests are surprisingly effective at it. The core focus of this test was to see how the new zone movement felt in action. I was a little worried about doing it before the new quest systems were added since the old system is pretty incongruent with the new zone movement. Nonetheless I think we got some important feedback on the movement itself.

Sew was confused about zone movement throughout the test (actually, pretty much everyone was, including myself). So much so that he actually created metaphor of country borders for zones so that he could understand them more easily (which is actually a pretty great way to explain concept):

And really, who wouldn’t be just look at this mess:

For awhile we assumed that it was largely an art issue- a big ol’ jumble of objects not intended for this purpose. Sew had even mocked up an example of a better way to display them:

But Sew found that even with a simple mock up of color coded zones the layouts were still a jumbled mess to interpret. Even besides being messy he also had a feeling of exploration not being as satisfying as it was in the old system (even though the discovery system of not revealing a zone’s connections should have improved it over all). The only thing he could point to on the feeling was that maybe the zone walls made it feel claustrophobic. I suspected that the readability was actually the problem- it’s hardly satisfying to grope around a space that you don’t really understand the physicality of. He then suggested perhaps moving to a node/road system:

Back during the zone planning I had considered switching to such a system. In fact, the zone system was even going to be retrofit to adopt it. But that turned out to be unfeasible due to the nature of 4 directional roads contradicting zones supporting many more connections than just 4. The zone system would either have to be awkwardly forced to stick to certain connection limits, or (for better results) scrapped entirely with a new style of generator. So I went with the existing zone system, figuring that adjacent blobs would be more readable than having to trace complicated roadways anyway.

I told Sew that I thought such a system still had readability problems from the complicated roads with multiple crossroads with a cost of 1. He then inquired about how I felt about board game style movement, which the node/road system is very similar to. My thought that such games might look complicated to read, but are actually very simple to navigate since there’s only a hand full of points where the player make an actual movement choice, and most of the time they’re forced down a specific route. It was at that point when I realized where the actual problem was at: most board games either use very limited choose-a-branch movement or a direct grid. And the reason for that is readability: in either case players can take a quick look at the map and infer the distance between points without ever having to trace pathways- with a pure grid it’s as simple as the distance between points.

So it has become clear that I’ve been trying too hard with the idea of naturalistic map generation (that largely looks the same in execution anyway- a big mess). The solution I’ve come up to address the problem is to effectively snap zones to a grid of squares. So while in essence the game map is just a tile based grid (with zones acting as very big “jumbo” tiles), the tiles within the zone allow for some internal variety to create an illusion that it isn’t as much of a grid as it looks. Here’s an example of a map operating off of a 3×3 grid:

The graveyard is at the center of the grid, even though it may not look like it is since it’s placed at a far right offset within its zone. With this set up we hopefully combine the readability of a grid with the visual allure of a landscape. Sew’s happy that it doesn’t rely on walls or biome tiles. I’m happy that it’s the simplest thing to convert the existing generator into. We’ll find out whether it actually works next week!

Queues

August 4, 2013 Hawk

This week continued the revisions on existing systems to support zone based movement. There were two “big things” this week. The first was revising the movement system itself to better support traps and battles. The old system worked on a tile-by-tile basis. The new system works on a point-to-point basis (Starting Zone->Point Between Zones->Point Between Zones->Ending zones), so step-by-step triggers didn’t really apply so much. I had to alter it fairly dramatically by giving it a master movement controller that directed the entities to stop on zone transitions when further processing is required (ie, for traps), and to cancel queued movement and stop at the nearest zone (for random battles). In general the system is better built now, even if I have to revert to tile-by-tile movement later. (Such is the code mantra of this project: it’s easier to spot bad code after the fact, so improve it the next time you have to touch it.)

The other big thing was that the central turn processor had devolved into a messy 200 line function glob of gunk (a single function was valid design choice when it started, but much less so after its responsibilities had grown), which made it rather difficult to add multiple moves per turn into. It was chopped up into distinct states, and I found several spots where bugs I hadn’t yet tracked down were almost certainly stemming from and were fixed just from the new design itself.

The next big thing on the horizon is adjusting the quest system for the new zone based movement. Tile walking distance no longer holds much meaning, so it’s mostly just the location finder that needs alteration, as well as the design of a few quests that called for multiple towns. Hopefully next week we can resume regular play testing.