Skip to content

July 12th, 2015: Return to blog

July 12th, 2015: Return to blog published on

It has been some since the last blog entry. The simple explanation is that these devblogs started as a means for keeping everyone on the team up to speed with one another. They failed at that purpose. Back in April we moved to a meeting format instead that has served us much better, but also invalidated weekly blogging somewhat. As such I didn’t bother to keep up with it, doubly so since the entirety of my work has been working on the UI systems further by converting the existing UI over to it. This has made for a cumulative 6 months just building the new UI system. I’m disgusted by that figure, but there really wasn’t an affordable alternative available to us. Don’t make a UI heavy game if you’re an indie, I guess? Or if you do use Unity or some other engine that gives you a free license for scaleform? That’s all I got for you. At any rate, it isn’t something worth blogging about (unless I was doing a 100% programmer blog)

With UI work starting to die down (though a third wave will be on the horizon) I’ve started to settle back down into digging into the remaining design issues. I honestly thought this work would get easier the closer we got to the end, but it really hasn’t yet.

1. Progression / Rewards / Pacing

The biggest issue on my plate right now. Players don’t enjoy the progression arc that much right now. By 1/3rd through the game starts to repeat itself instead of evolving as it goes. The weakest link is equipment- it doesn’t help that much, and it’s boring since all they’re just minor stat bonuses. Initially I grabbed for the simplest solution on the shelf- binding abilities to equipment. Before I even started working on that, though, I realized there was a much deeper issue here than that. The game is currently almost double its target length. If I just slap abilities onto equipment, that’s just going to make the game take even longer. Whatever changes I make to equipment, they need to be streamlined instead of bog down the pacing even further! I haven’t gained insight on how to actually accomplish this, though.

On the front of evolving the game across its phases I’ve decided that more escalation is needed in the game. Particularly player abilities in PVP need to get stronger. Especially abilities involving other players, to force tactics and alliances to change as the game goes on. Escalation has a secondary benefit of potentially speeding up the game as well. Ideally it should just raise the risk/reward stakes rather than simply making it faster to traverse, though.

I have certain backup options in mind to create a faster and more diverse progression if necessary. One idea is to basically make the middle part of the map a sort of minigame gimmick rather than the same as the rest. ie, players might have to compete in a battle arena rather than moving across the map. Or they might have to take on gambling games. Such gimmicks can take less time than the main game while also providing diversity (not to mention more ways for a player to snag the victory even if they’re doing poorly in the main game). Right now they’re more of a last resort.

2. Improving The Map

The basic format of the map is on course now. It does a great job of recreating the feel of a dungeon while taking minimal time: the endurance, the hesitation of going back to town, wariness with each roll, etc. But the detail work on it is miserable. Part of it is a matter of sameness: each track has very little distinguishing it from the others. A rank 1 track is much the same as a rank 3 track. An all-negative track has little incentive to go down it, so players will only traverse them once on accident.

Adding more variety to tracks sounds simple on paper, but I hesitate in practice. How much is too much? At what point will players have no idea what they’re looking at when they look at the map? That was an issue at the peak of the previous map style, and some of the others. Of course a big part of the problem is just that there isn’t any art design backing the game up right now which makes every new thing more confusing since its explanation is 90% buried in text. Some day there will be art backing it up, which is a fact I must remind myself of every day. A good start would probably be to just start adding 1 gimmick to every lane to distinguish them a little bit, and move on from there.

Another factor is that exploration is falling flat. Once you find a “good track” there’s no reason to poke around the others. It should probably be more competitive than that to explore the others. But for that to work I need actual rewards to put in them. The actual palette of rewards is incredibly lacking, as outlined above. My hope is that whatever form the equipment system takes will also be capable of being peppered around the map to give it some character, rather than a generic exp/gold machine.

3. Other Things

The above are kind of the major issues that I have no immediate solutions to. There are smaller things like the lack of variety in main quest objectives, the need to remove or rework the bland fetch side quests, figuring out what to do with meta progression, etc. But I have ideas for most of these things, or they’re just not that important compared to the core of the game being lacking at the moment.

————————–

I’ve played the current version of the game enough (and with enough distance since making it functional back in March) to know that it has a pretty dang good foundation now. There’s just a whole lot of detail work remaining to be done to make that goodness actually come out. My biggest regret is how much of my time has been spent on UI work. From the initial time spent integrating a library that ultimately didn’t work out (and which also probably took even more time to learn work with) to the 6 months that the new system has taken from me, to the remaining months of work that the final designs are going to take to integrate and polish. I should have brought an intern. Or second guessed my technology choices? I don’t know. It’s almost over.

March 29th, 2015

March 29th, 2015 published on

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.

Todos

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.

Wikid

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

Carlos’ Art Spotlight 1 published on

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

March 22nd, 2015 published on

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

March 15th, 2015 published on

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

Update 6 Test Report published on

Changes

  • 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?

Next

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

March 1st, 2015 published on

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.

 

February 22nd, 2015

February 22nd, 2015 published on

The generation is largely done at this point, still a few minor points of polish to do on it. Implementing it was painfully slow for reasons I can’t really articulate. Just one of those kinds of weeks. Hopefully I’ll be able to run a test of the new map system by the end of this month, but it might end up being more of an early March kind of test.

The remaining stuff is largely just tweaks. The gold/experience gain rate was never balanced for the new system which hands out gold/exp far more frequently, so that needs to be tweaked. PVP classes were never made for the new single class system, so I need to add some rough versions of them (the new map system benefits PVP more than co-op so I really want to test it this time). Quests need to be revised to deal with the new map structure. I need to do some personal testing to get map feel right, figure out what the ideal length is. Lots of minor stuff. I’d like to get it done this week, but I’m not going to bet on it either.

February 15th, 2015

February 15th, 2015 published on

As it turns out the solution to the new generation was to simply expand the existing system further. Much like how node tags have rules describing how they should be generated to create more interesting patterns, I added two new pieces of data to represent interesting patterns in the world shape as a whole. The first one is that of Area. Area basically describes the entirety of one difficulty rank (for reference there are currently 3 ranks in a single game). Doing it on a per rank basis makes it easy to set it up so that further ranks can have longer or more difficult patterns. It’s also important because certain world shapes are more interesting than what would tend to happen naturally (for instance I like the pattern where the map starts with several branches, then has a section with no branches, then returns to several branches- the middle section having no choice serves as an interesting melting pot of gathering the players together at the mid point)

2015_generation

Then comes segments. Segments represent the entirety of a single map branch. In a lot of ways segments are secretly just probability charts for the players to consider. Having partial control over the patterns allows for stuff like “make all of this section’s positive tiles gold gain”, and “front load all of the negative tiles at the beginning” etc. Segments rely on node tag categorization to make broad generalizations such as “positive tile” or “major negative tile”, rather than specifying exact nodes themselves. Naturally the final phase is the same as it was in the previous generation system (essentially just picking a random node within a tag set whose constraints are valid), just applied to a smaller space.

It’s all really simple now that I put it out here, but much of the week was spent dealing with thorny issues. One such issue was how to apply gradual difficulty transitions across the map. Doing a transition mid-segment would result in imbalances of how a segment was designed (ie the negative tiles might end up as lower difficulty than positive tiles, making that segment too good). Eventually I settled on making the length of segments directly correspond to the length of difficulties. Consequently any extra long segments have to be built with the knowledge of when their difficulty will transition, so they won’t be designed in ways that promote imbalance.

There’s a lot more complicated additions the new generation system will need for stuff like lock/key nodes, but right now I’m just trying to get a basic version up and running so we can tell if this style of map is even worth generating in the first place. I kind of have a bad feeling about writing a generator before being certain of what map structures play well, but in theory the system should be able to adapt to any changes (of course that’s also what I said about the single worst waste of time of this project that was one of the previous generators).

February 8th, 2015

February 8th, 2015 published on

At this point the conversion of game systems to the new format is finished. Lots of new systems (fancier gates, a warp system), lots of updated old ones (ranged attacks/parties/etc). What remains is implementing a map generator for the new map format. A skeleton of it is already in place for creating basic maps, but there are no brains behind it. The main stumbling block for me right now is deciding how much of the old system is applicable to the new map style.

I don’t remember if I actually documented the newest version of the generation system here. It’s pretty simple. Every type of node (that is, a location in the game with behaviors attached to it. ie, a trap node that hurts players who pass by it or a gold node that gives players gold when landing on it) has two special properties attached to it: Tags and constraints. Tags are for organizational purposes such as “healing nodes” or “negative nodes”. Constraints are requirements and limits: ie only spawn this on medium difficulty tiles or only spawn 3 of these. Tags also have constraints and are the organizational structure that the core generator uses to decide what things to spawn (it picks a random tag and then spawns it somewhere and then moves on until out of tags or slots to fill). It becomes very easy to create behaviors like “only spawn 1 healing node per rank” or “only spawn this near other trap nodes”, especially since multiple tags per node allows varying degrees of classification. It worked great when the world only consisted of about 9 nodes per rank, and the positions of other nodes was rarely of importance.

The new system has more considerations to take. Nodes have a lot more importance to each other based on the branch they’re within. It’s trivial to generate a branch with the concept of “there should be 4 positive nodes and 2 negative nodes”, but what each of those nodes is matters a lot. If we went purely random on these players will likely end up making a decision on “what has the least negatives / the least costly negatives” or “what has the easiest gates” because the composition of each branch would be a mish mash where anything could be possible. Now imagine if we made that same branch “4 gold nodes, 2 damage nodes”. At this point players now have a good idea that if they go down this branch they will probably get some gold. If gold is a desirable resource for them at the moment, then they will weigh it against the damage nodes and have to make an interesting choice of whether the risk is worth it. While it’s easy to take that example and say “well, then have whatever node you randomly pick be used for all nodes on a given branch”, it doesn’t take into account the bigger picture. ie, having most branches randomly happen to be gold diminishes the value of gold over time. The old system by itself just won’t be enough, and complicating the problem is the fact that I don’t fully understand all the important factors of the new map style yet. That is going to be the focus of this week: figuring out what matters on maps, deciding how much of the old system can be used to generate it, and then applying it all as needed.