Posted On: 2026-09-07
I recently picked up and (briefly) played an old game, and while doing so got a bit of a shock at how (frankly) bad the game was. I remembered it quite fondly, but as I look back at those memories now I see that it was the ideas that I remembered and not the actual implementation. While this is runs a bit contrary to conventional wisdom ("ideas are cheap, execution is what matters"), it's not all that surprising (it is the nature of nostalgia.) As the ideas are still interesting (and some of them underexplored to this day), I thought I'd dedicate today's post to exploring two of them - both to explain why they are interesting as well as point out how a particular implementation can subvert that.
The first interesting idea is the one I remembered most vividly, and it's focused on an area of game design that's been much better explored in recent years. While most games (both at the time and even now) allow the player character to die without exploring anything about that death itself, a small number of games directly address what happens after that death. While there are a lot of ways to explore that concept, the particular one I found so interesting was the idea that dying condemned the player character to the underworld - which they could explore like any other world. With the right mix of (player) skill and (in-game) strength, the player could potentially find a way out - but every failure would result in another death, sending them somewhere else in the underworld (and losing all their progress towards escaping.)
When done right, "escape the underworld" could be an excellent way to both raise the stakes of failure (not just a "Game Over" screen) and also give the player a challenge that they can (potentially) overcome to overturn that failure. When done poorly, however, it can become a tedious (or outright painful) minigame that trivializes failure and reduces all in-game challenges to a simple measure of "how many times will I have to die before I win?"
Looking at the specific failed implementation: dying refills the player's health and moves them into a randomized maze, with four exits (one at each corner) and a guard on top of each exit. Only one of those four is "open" - that is, connected so that the maze will lead there, and the player must wander around until they reach it. The guard atop the open exit will wander around using simplistic behavior: generally trying to walk directly towards the player, regardless of any obstacles in the way. Thus, to escape the underworld, the player must navigate the maze and trick the guard into moving to a position so that the player can run past. The guard has predefined stats (health and damage), so how dangerous they are varies based on how far the player is in the game. Once it becomes too weak, however, simply walking past while taking hits from the guard becomes a trivially simple solution and the whole thing falls apart.*
It took replaying the game to remember this one, but it's a neat idea that is pretty underexplored. Many games use a "stamina" resource that the player can spend on actions (ie. running, climbing, fighting, etc.) that would become too powerful if used continuously*. What is much more rare is the use of a wide variety of different stamina resources. Since the use (or abstenence) from stamina-consuming actions creates an ebb and flow to the kinds of actions the player performs, having multiple resources could (when done right) create a more complex flow across widely varying kinds of actions - incentivizing a diversified playstyle and exploring the full space of available play actions. When done poorly, however, multiple stamina resources collapse to a de-facto single resource with the player outright ignoring any of the others.
Looking at the specific failed implementation, there were six different resources that could be spent. Different weapons spent different resources at different rates, so (for example) a heavy weapon might deplete a lot of strength but a small amount of agility, while a light weapon would do the reverse. The player could choose to "rest", which recovered a small amount of all stamina resources, and encounters were tuned so the player would be forced to rest multiple times in a single fight. Switching between weapons took time, and the differences in weapon performance were pronounced, so a "good" weapon was much better than a mediocre one.
Although all the pieces were there for a system that incentivized using a wide variety of weapons (to make the most of various kinds of stamina), the opportunity cost of swapping to, and using, a sub-optimal weapon was higher than simply performing the "rest" action. Therefore, although which stamina resource a player used varied based on their best weapon, the player's options were entirely controlled by only one resource at a time*.
At the risk of prescribing a particular implementation, I think that a designer looking to use diverse stamina resources would do well to rethink how "resting" and resource regeneration works. With one resource it's binary (use it or don't) but with multiple it's multi-faceted, and there's probably a lot to be gained from thinking about how actions can fuel/recharge each other (rather than relying on resting/inaction as a universal recovery mechanism.)
While it might be tough to execute better than the game that inspired this post (particularly that second one - I'm not completely sure it's even possible to fully live up to its promise), I hope reading through this exploration of the ideas has been interesting. If this inspires you to make something that explores either of these ideas, I'd love to hear about it.