March 29th, 2015

Somehow this week turned into even more extended testing. We’re at the point now where the testers have nearly run out of things to break. Was probably for the best, I have a firmer grasp on the current feel of the game.

The other big thing has been changing up how I store my notes/todos, largely because my current format ceased to be useful Let’s take a brief tour of the history of my planning practices:

Design Docs

The start of my using documentation for work was with game design docs. Something I started doing very early on, probably because I read about it somewhere. My design docs essentially act as overviews that describe what a game is, both to clarify it for myself and to easily get team members up to date on what a game is. I rarely get into specific details or numbers in these overviews, as those are better suited for separate, dedicated documents. I imagine if you had a larger team maintaining the overview on a constant basis would be necessary to keep everyone on the same page, but at my scale I tend to discard them once the game is fully functional.


At some point future ideas, responses to tester feedback, bugs to fix, and just generally detailing and ordering future work became too much for me to store in my head anymore, and I started writing simple text documents that consisted of long lists of things to do. Eventually one document became too small, and I started making multiple (generally for different subsets of a project).

Work Notes

From the todos evolved work notes. Essentially documents where I type the process I use to get something done. In many ways these things act the same as talking out a problem to another person: if you have to describe your current problem outside of your head you often find ways to solve it in the process of describing it. Another common component of these is listing all the solutions for a problem and comparatively deciding the best course of action.

There are many other benefits besides problem solving, though. It becomes extremely easy to get back to work after a break because it just requires re-reading where you left off in your thought process. If something fails later on and I need to find out why something is the way it is, my old notes often have the answer (admittedly this shouldn’t be necessary most of the time, but it’s a good back up). It’s a habit I picked up specifically for this project, and it’s incredibly helpful.

Wiki / Trello

For awhile we tried to maintain a living design doc in the form of a wiki. It really didn’t work out. It generated a lot of maintenance overhead (any time you changed something, you needed to restate it in the wiki). It also didn’t serve much purpose when there’s just the two of us. I probably underestimate how useful some of that maintenance work can be in the long run, though.

Later on we adopted Trello as a shared todo list to keep us up to date on what the other was doing. In retrospect this is a dumb idea for two people who can just as easily tell each other what they’re doing. Nonetheless, I converted my old todo entries into the task format. There were some real benefits to being able to assign hefty work notes to each task, and seeing percents creep up while working was pretty neat. That said, it’s honestly not made for the bulk of tasks I have since you can only really see 5 or so tasks in a list clearly with it. I have over 80 tasks registered to it right now, so casually browsing the list became impossible. Older tasks just ended up sinking further and further into the background since the nature of the list encouraged keeping the most recent items more visible. It resulted in me creating a lot of duplicate tasks later on, ignoring my old notes on each subject.

What I needed was something with similar organizational capacity for notes, but with a better large overview so that I could see all of the tasks by casually skimming. I basically decided something with a tree view would be appropriate.


There aren’t actually a ton of note taking programs with tree views out there. I eventually settled on wikid which is basically a personal wiki that displays the links in the wiki in tree format. Not quite as easy to manipulate the tree as I’d like, but it has benefits like being able to link related tasks together and the ability to tag tasks (ie, based on priority) and then view the list that way.

I’m still in the process of converting all my old notes to this new format, but so far it seems immediately apparent that this is a much better way to organize this stuff. Since it’s basically just a text editor, I can effectively store my work notes using it as well which will make back referencing them easier later on.


This whole process serves a second purpose which is that my main goal here is to decide what still needs to go in the game, and what doesn’t need to go in the game anymore. I also need to come up with any unplanned additions that need to happen. It’s a long process, but this is the best time to sort all this stuff out before making the final push.

Carlos’ Art Spotlight 1

When working on something intensely over a long period of time you can easily lose perspective on the quality of your own work. There’s a lot of ways to get past it, and everyone has their own. Sometimes just taking a break is enough, but often getting feedback from other professionals you trust can help. The spotlight series is an attempt to show what that feedback looks like, and to highlight some of the cooler parts of the game that get buried under the weekly grind.

I was searching through the loads of work Sew has done and these great tree monster designs really caught my eye; I thought they should be showcased. They are unique because most artists make the decision to focus on the bark when working on treeish creatures. Instead he successfully uses the leaves to give the creature a formidable mass. This decision also makes it easy to create more creatures of the same type with a lot of variation.

Tree Monsters Mar 23 2015

Additionally, I think including elements of skeletal design makes the creature look more menacing without shoving the evilness down our throats. This is just one design of many. I’ll be posting more of his stuff to showcase some of these lovely designs.

You can see how this and other pieces get made over at Sew’s Blog.


March 22nd, 2015

This week was pretty much just more bug fixing and showing the game to a couple new testers. Got some interesting feedback. Starting to feel more comfortable with what the game ended up being. Not a whole lot to actually talk about, though. Upcoming goals are pretty much the same as I discussed last week. I don’t have a whole lot of prioritization in place. I’ll likely be jumping between polishing a few things, and finishing off the remaining loose ends of the game design. The basic idea is to make the game more playable for testers while also finishing off the game part before starting on content (as well as to make it possible to start improving the interface).

March 15th, 2015

Last week there were two elements of the new map system that made it seem a bit off. One, selecting a branch to move to diluted the dice power a bit since players could manipulate where they land to be a positive space. Two, gates fully interrupted movement meaning high dice rolls were frequently cut off- reducing dice power and kind of making game flow feel weird.

There was no clean solution to the first problem. Awkward things like having the game roll the dice behind the scenes, querying the user for a branch without telling them exactly how much they rolled were possible, but seemed wrong. Gates had a simpler solution: store how much a player rolled and resume their movement after combat.

The second problem’s solution was implemented and suddenly the game felt about right. Decided the first problem wasn’t worth worrying about anymore, if anything it’s beneficial in that it adds more choice layers to branch selection (ie you might deliberately walk on a negative space just to avoid another player with dangerous abilities).


At this point it can be said that we now have a definitive prototype version of the game. From here it’s a matter of fleshing out the core gameplay (not actually that much more needed), design and build the actual content/progression of the game (a harrowing proposition of finally having to settle on what the game’s world feel is), and finally polishing the presentation/interface.

It should be relieving, but instead a new tension is starting to arise. Now that we actually know what the game looks like, I have to worry about whether it’s enough. Is this going to have enough content / be replayable enough for people to feel the game is a good value? Are there enough people to build a community around this game to make the multiplayer element actually work? Who does this even appeal to? Can we effectively convey that scenarios are meant to be replayed to see the variations, and aren’t just the content recycling they seem to be?

All stupid questions to be asking this far into development. It is what it is, either it resonates or it doesn’t.

Update 6 Test Report


  • Completely changed the format of the map to be closer to a linear board game with a well defined end point goal.
  • In response to the new map format attacking players, joining battles, forming parties, etc became ranged abilities rather than requiring players to be on the same tile.
  • Created 6 new classes for PVP to fit the single class format, themed around multiplayer interactions.

Test Results

It’s a success, I guess? I’m burnt out in a way where I can’t really gauge the quality of my own product right now. Tester response was fairly muted, so it wasn’t as big of a leap as the jump to required battles. The pacing dragged in parts, but that was partially down to players getting used to the new format and other attention grabbing problems. I don’t think it was a step down or anything, at the least the racing nature of the game is much clearer to players now.

The main thing that feels off to me is that there are two things in the game that dilute the excitement of rolling the dice to move. Gates (basically, battles) interrupt movement entirely and by necessity have to occur at a regular interval. Branches where players have to pick their next route aren’t as disruptive, but are also necessary for the player positional games to really play out. Right now my thought is to merge the two interruptions into one thing- after clearing a gate, players can choose what lane to branch to with their remaining movement. It’s a good solution, it just has a lot of nasty details (ie you don’t want players transitioning lanes straight into another gate so gate positions become tricky, if a player lands with 0 moves remaining the branch has to give them an extra move point to transition to another branch, etc). The good thing is that this is probably the last fundamental system change that needs to happen.

One thing that I learned is that the new format for designing PVP classes finally seems like the right way to build classes. Each class gets a primary attack/defense type that their regular attack and most of their utility abilities use. For the other two types they end up getting abilities that tend to have MP costs or cooldowns associated with them, so they have to be careful with the application of them. This benefits PVP by adding a tension to predicting your opponent’s moves since your options will get smaller if you choose wrong as well as giving your opponent certain degree of predictable behavior, and it benefits PVE by adding an appropriate amount of resource management and a similar tension for prediction as in PVP.

Haven’t been able to get a group together to test Co-Op yet, so I have no idea how it fares in the new system yet. It’s probably fine?


The main thing right now is to clean up the gate problem I mentioned above, in addition to some other bugs that popped up. After that I’m probably going to do some tests with a slightly wider audience of testers to get a better read on the state of the game. At this point I think most of the fundamental issues are settled. It’ll finally be time to move on to the detail and polish work. A daunting proposition to be starting on it so late, but in a weird way I feel confident about it. Getting the fundamentals right has been a tedious process of throwing away piles of past work. The next phase isn’t likely to be such a wasteful process, so with enough effort it won’t be impossible to get it done in a relatively short time period.

March 1st, 2015

Mercifully map generation was wrapped up on Monday. Rest of the week has been spent on the many small tasks that need to be done. Bug fixes, implementing new gimmick areas, polish, etc. The most time consuming piece has been designing new PVP classes. In the process I realized that the main reason that class design is so time consuming right now is because so many parts of the battle system are still hazy. It ranges from small things like the fact that there aren’t any standardized status effects, which makes systems for removing them vague or the fact that there aren’t any limits to buffs so having too many different unchecked big buff status effects could end in players killing the final boss in one swing, to big things like the fact that the equipment system has long been scheduled for massive change ups. Now isn’t the time to go over that stuff with a comb, though. Need to find out how the new map system stacks up first.

It’s easy to get dismayed that all the design work is pointless when so much is in flux, but ultimately most of this is just details. The only system expansion I see happening from here on is perhaps having more defense/attack types than 3, and increasing the damage bonus for hitting a weak type. Even in this weird flux state you can learn a lot about how this stuff plays.

The key theme for this batch of classes was to emphasize interaction with other players, much like how the co-op classes emphasized playing a role in a team. I lumped classes into two broad alignments, “Good” and “Evil”. Good classes are capable of helping other nearby players. Evil classes profit off of hurting other nearby players. In both cases sometimes these things are triggered by the player, but are often just automated systems. The idea being that evil characters want to follow their opponents, while good characters want to avoid being followed by opponents. Additionally, evil characters are a pain to group with while good characters provide a boon to their group. I have hesitant feelings towards the division (ie, evil arguably has bigger benefits when following a good character), but I’m guessing the problems will manifest themselves quite quickly during testing. I do want to leverage the core theme of building every class around player interaction though. Previous versions never fully tapped into it, and a multiplayer game really needs to build itself around those interactions.