Skip to content

July 19th, 2015

July 19th, 2015 published on

At some level my design work comes down to stripping down a perceived problem to its simplest form before any real progress can be made on fixing it. In some cases this means untangling connected problems to find the origin. In this case the tangled mess was thinking of lacking progression and lacking maps being separate problems, when in reality the lacking maps were much of the source of the lacking progression. Now that the connection is clearer it’s easier to solve: the maps lack any form of “conquering” progression to them, which in turn makes any progression system, no matter how sophisticated, feel lacking in the accomplishment that makes progression feel good. Stupid simple on paper, but took awhile to boil it down to this. Now that I have it’s mostly a matter of reformulating the map around it. The leading contender right now is the “critical path” system:

critical_path_system

It’s pretty obviously designed around solving the problem. By segmenting it into chunks with defined end goals, it’s easy to instill a feeling of “conquering”/”creating order” in players. It also allows for creating longer chunks within the dungeons without ballooning the critical path’s backtracking. This allows for a greater feeling of endurance without creating as many dead space turns getting back to place (the backtracking itself is still important to create that feeling of endurance because if there is no cost for retreating then players will always retreat at the slightest sign of danger). Another factor is that building around more linear pathways will allow me to create more well-defined areas, as opposed to the current system of creating an indistinct mush world since it’s trivial for players to sidestep danger rather than having to deal with it. In that regard it also creates more choices for players in terms of having to decide what challenge to undertake.

There are downsides to it. Having several longer tracks without connections makes it easier for players to distance themselves from each other by each going into different dungeons, diminishing player interactions. It’s also more difficult to explain the structure to players: how many dungeons before it’s safe to take on the next boss? On paper it should be “at least one dungeon makes it possible but risky, all dungeons makes it trivial”. But communicating that to players is tricky, especially when class advantages/disadvantages, luck, and player parties can make the extreme ends invalid.

So I’m not totally satisfied with this variant quite yet. Still exploring other options. It’s closer, though.

———————–

Probably the best thing to come out of this design phase so far was a suggestion to make the battle group on a tile static instead of random each time. It’s an idea I’ve been dancing around with in terms of less random ways of picking battles. Flat out making them static was something my brain was avoiding for some reason, but actually makes way more sense: areas become more distinct (that’s the tile with karate chimp!), class advantages/disadvantages play out consistently for each player (that tile was rough with my build, but easy for that other guy!) instead of players lucking out by getting an enemy they’re good at, and player engagement is increased because you can figure out the next enemy’s pattern by observing the guy ahead of you. It’s something so simple that it’s easy to miss, but probably going to be one of the biggest improvements of this design phase.