Skip to content

The Continuing Adventures of Maps

The Continuing Adventures of Maps published on

So I’m sitting here with a fresh finalized version of the map design. Let’s take a look at some of the harder decisions of the week.

 

Movement

By the end of last week’s entry, it had become apparent that our current system of grid based movement just wasn’t going to work out if we wanted to hit our goal of 1 hour long games. It allows for too many empty turns, and lets players get too far away from each other. Some tighter map design would fix this to a degree, but more drastic measures were needed.

movement

This was probably my biggest mental block on designing this game. When simplifying things down for the sake of time, it’s very hard to find the right balance of not destroying the original feel by going too far. I was resistant to admitting the change was necessary, last week wasn’t the first time I made a rough turn time calculation. Once I finally started to flesh out the available alternatives, I finally felt comfortable about this project for the first time in a long time. I’m pretty sure I’ve finally found what we were looking for.

nodesEach dot represents a node, each line a pathway between them.

The new method is that players move solely between points of interest “nodes” (towns, dungeons, wilderness,etc), rather than individual tiles. I then started at pretty much the opposite extreme of the previous system: players could move to any known node on the map in a single turn. This was a bit much since it basically destroyed any semblance of danger on the map and allowed players to attack each other from anywhere. But going down to a single node hop in a single turn really wouldn’t be a significant improvement from the old system, either.

What I’ve settled on as a solution is the stamina system. Players have a stamina meter with a cap on it. Each point of stamina allows them to do a single node move, and they gain 2 stamina each turn. This adds a certain layer of strategy to the proceedings since players can decide whether they want to use every drop of stamina as they get it, or to save up for a single massive movement when the situation calls for it. With this in place players have significantly more mobility than before, while still allowing some importance to how deep they decide to tread. The exact numbers will probably call for a lot of tweaking, but I think the fundamental system strikes the right notes.

Endurance

The old system used empty tiles for random battles and traps, creating endurance costs for moving around. Since there are no more empty tiles, something else had to exist to create danger in the world. The obvious substitute was made, with every node hop increasing a battle gauge which triggers a random battle once filled. Traps exist as an explicit percent chance on node paths. Perhaps the most notable thing is that random battles don’t necessarily damage mobility since players still gain stamina during them, which makes them more of a battle capacity check than a dead stop. Overall these are pretty limp wristed endurance dangers (by necessity), but they may still work out in the end.

Player vs Player

Player vs player has continually been the feature most likely to get cut. There are a lot of factors for this: online players are jerks and will exploit any fragile system to annoy other players even at the cost of winning the game, the nature of RPGs requires a battle system with enough room for strategy to give significant edge over numerical brute force, and being free-for-all requires some means of balancing unbalanced scenarios such as 3 versus 1.

The solution to these issues was surprisingly simple: it costs gold to attack players, the base cost goes up after each attack, and there is a multiplier to the cost when it’s imbalanced. PVP becomes another resource to use only when advantageous. Pure trolls will be wasting so many resources that they quickly become harmless, and eventually incapable of even initiating an attack.

Actions

Previously when players landed on an object, a random event would trigger. If they had a quest objective there, that would trigger instead. A simple and elegant system for moving turns along quickly. So I’m not entirely confident in this new system as being a good thing.

Under the new system, when ending their turn on an object players get a choice of what action they want to do there. Common actions include hunting for a battle, gathering an item native to the object type, and so on. This interface also extends to allowing players to opt-in to more random events placed on the object, selecting which quest objectives to complete (players often got confused when two quest objectives ended up on the same object in the old system, or locked into multiple unrelated battles, etc), and allow a generic object to contain more esoteric repeat functionality (ie, allow for repeat trading of one item for another).

It’s a great system for being able to expand upon the game easily, to allow a wider range of object functions with a smaller number of objects, and to make global quests more explicit. But it could also turn into a big ol’ mess of player indecision, reduction of uniqueness for individual objects, and a whole bunch of other varying effects. The primary goal of this system was to give players reason to form an ideal node route in their head. And it achieves that, but it could just as easily harm it with nodes having too much. It may end up being better to give each node type a very specific purpose instead, but even so making quests more explicit will still have some gains so it’s worth pursuing regardless of how it ends up.

 

This week I need to write up some plans for how to generate maps under this system, and then break up the whole thing down into a more digestible todo list and get to work on proper implementation. The whole thing basically amounts to a ton of small changes, so it’s hard to estimate how long it’ll take.