Well the core functionality for NodeActions is done. Nodes, SubNodes, all that jazz. It took way longer than my initial estimates, but on the flip side the next task- Node Generation- seems like it’s going to take way less time than my estimates feared! What I’m trying to say here is that the mounting evidence that programmers are incapable of producing accurate estimates is undeniable.

Let’s talk about the simple things in life. Initially I was thinking about having all SubNodes being generated equally- ie, just pulled randomly from the entire pool. This obviously sucks for some higher logic stuff of balancing out the placement of different types of SubNodes. The solution was mercifully simple, though. I already had a SubNode classification system in place for doing stuff like “Don’t place healing fountains too close to town” and suchlike. All I had to do was hijack the classification system to be where generation starts from, allow it to have its own generation constraints (you remember those from a few weeks back? they say stuff like “only spawn 5 of these”), and as a result we get a beautiful and elegant little system arising out from a small gap in my earlier thought process. It looks like this:

1. You have a category of “Utility” SubNodes. These SubNodes provide beneficial services to players.
2. We can then have GenerationConstraints that apply to the “Utility” category:
3. • Don’t spawn too close to a town (hardly beneficial when the player is already next to an existing healing spot)
   • Don’t spawn too close to a dungeon (because too much convenience)
   • Spawn 1-2 in each difficulty rank (provides some variance, don’t want too many or it’ll dilute their positional value)
   • Don’t spawn too close to another “Utility” SubNode.
4. From there an individual SubNode can have its own GenerationConstraints. For example let us consider a quest SubNode that will end up spawning a healing fountain upon completion:

• Spawn it in the “Easy/Medium” areas of a given rank (so the players have plenty of time to do the quest while the fountain will still be useful)
• Spawn only one per game

Simple, but allows for a great deal of stacking complexity.

Once again there’s not a whole lot to talk about. I could talk about wanting to add a certain feature ended up in forcing me to revise the way something worked in a significantly better way which then made it totally trivial to implement the feature. I could talk about how once you get down to implementing things you start to realize little details you hadn’t considered, like whether players should be allowed to use a node action again when they still haven’t finished its associated quest (the answer is: it depends!). But there’s not a whole lot of room for any significant discourse on this stuff. It’s all about filling in the blanks, like so much of programming after you’ve gained your legs. And I don’t have a whole lot of battle design to talk about. So I guess I’m just rambling this week?

As I’ve worked on these NodeActions I’ve started to get more hopeful that this is the right direction for the game to go in. Won’t know for sure until there’s pudding to get proof from. But the other day I rambled about roguelikes to someone. A roguelike’s random terrain actually isn’t that interesting- the only thing that matters most of the time are choke points. What matters about roguelike random generation are the objects placed within. The raw variety of each type, the variance in how a given object can react to different things, the increasing number of options an object gives to a player, etc. Ideally each object adds several new choices to a situation, and the resulting mixture of objects adds even more permutations of choice to the mix.

This game isn’t really a roguelike, but I’m hoping a similar principle applies to our maps. By giving each node more options we’re creating a more interesting play field, especially if we can get the options to interact together in interesting ways.

Much of this week was spent transplanting the planning for node actions from text to the format that our graphical editor works with. Not a difficult task. From there I’ve begun to put meat on those bones, make the data mean something. But nothing is all that functional just yet.

We seem to have inadvertently fallen into themes for each year of working on this. The first year was thematically, “to get all of the basic systems working together”. The second year (this year) has been thematically, “to make the game good”. The third year will likely look like, “to finish the game, and to try to sell it”.

We’ve been holding off on any publicity for a number of reasons. The game just isn’t there visually, there’s still all kinds of temporary art floating around. Significant portions of it still don’t even have mock ups. Much fun as it is to blame Sew’s limited available time, another factor is our slightly excessive perfectionism. We’re on, what, the fifth version of the walking sprites? It might all pay off in the end. It might be irrelevant.

The other factor is that the game itself hasn’t all been there. Even now I’m still making fundamental changes to how it all works. We’ve had a rough draft for awhile now, but it isn’t good enough. The harsh realities of game overpopulation is that the scant few players you can get to try it the first time need to be blown away by the first few minutes of the game if you want any hope of them spreading the word. Marketing and game quality are a balance: the weaker one is, the more the other has to compensate.

So those are our goals for this year: to get it all together enough to start the Sisyphean journey that is marketing. To have enough art done that it doesn’t look incompetent. To have the game concrete enough that you can tell someone what it’s about in confidence that it won’t change the next day.

This week was largely about planning for the Node Action System. The nuts and bolts of it. Planning actually tends to be the most agitating parts of this project. The simple reality is that just stopping and making sure everything makes sense together can feel like a waste of time in a project that isn’t moving fast enough. In addition to that, having no other programmers around to bounce ideas off of makes the process take significantly longer. If there’s a single department where I feel the limitations of working solo hurt the most, it’s the planning. You just don’t get the wider perspective, or a second check for blind spots. Let’s take a look at how the planning thought process went.

We already know what Node Actions are: a list of actions the player chooses from when ending their turn on a node. We already know that they can come from the node itself, sub-nodes, and quest objectives. The question remained, what systems actually handle executing them. It just so happened that we have a system built entirely around executing an arbitrary number of actions with the capacity to freely branch as needed in the quest system. So sure enough, just run the relevant quest when a player selects an action. If it’s created by a quest objective, then it needs to merely mark that objective as a success.

While the quest system can do many things, counting the number of times it has been ran wasn’t really one of them. So elements like having an action only usable a finite number of times, or only usable every so many turns was best pushed into the NodeAction system itself. Through this process of considering “what can a NodeAction do?”, a new idea was born for passive NodeActions. Essentially sub-nodes that have a chance of occurring instead of the action the player selected. This allows for the idea of potential “traps” that can trigger when selecting actions on certain tiles to create a sense of risk in using certain nodes, as well as potential rewards for investing actions heavily on a given node.

With the NodeAction system fairly fleshed out, it came time to consider the consequences. Nodes, sub-nodes needed to be defined with what actions they bring to the table. When defining nodes a question arose: how does the generator know where to put these things? A pretty simple system came out of that: GenerationConstraints. Essentially each node would have a list of GenerationConstraints that specify where they could and could not be placed. GenerationConstraints come in a variety of flavors: stock constraints specify that only so many of a node type can be generated in each section (only one healing fountain per rank), distance constraints specify that nodes can only be generated when so far or so close from another node type (don’t put the healing fountain too close to town), etc. This system doesn’t quite solve everything since Warp, Blockade, Dungeon nodes and so on require very specific positioning in the world, but they’re easily enough hard coded into the terrain generation where they belong since they’re primarily part of the layout.

The last bit of consequences stem from the fact that the quest system now needs to be able to interact with the new node systems. You might want a quest to spawn a new subnode as a reward, decimate some forest nodes for the villain to make a point, and so forth. Nothing particularly interesting about the process though, just outlining the required new actions and how they work.

Most of the planning is complete, so we’ll see how the actual execution goes next week.

———————————————-

A nice little problem fell out of this planning: turn order. It’s a hot topic in board games, with authors adding all sorts of systems to try to mitigate first or last player advantages: shuffling turn order, letting players purchase a sooner order with various mechanics, giving certain advantages on last turns to mitigate first turn advantages, and so on. The problem arises here with node actions that have a timer before they can be used again. The natural inclination is to set such a timer to however many rounds- rounds being a full cycle of player turns. But doing so makes it so that the timer always refreshes on the turn of the player who last used it- making it trivial for them to “camp” an action. There’s a few possible solutions to this: Make it so that the timer ends exactly one turn after the player who used it last (but that’s kind of abusive), make the timer specific to each player (but that removes player interaction), don’t care and inherently give an advantage to “the first player who uses it”, and probably many others. I haven’t really decided yet. Will probably just experiment with them in action as the game progresses.

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:

1. If someone completes someone else’s solo objective on their turn, it still gives credit exclusively to the quest owner.
2. 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
3. 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.

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.