Overview:
Climbing Tartarus is a 2D point-and-click adventure game developed in Decker, a low-code creative toolkit for interactive art making. The game was developed in a week-long game jam with the theme "Freedom, but at what cost?" Additionally, there was an added restriction to limit the color palette to exactly three colors.
Achievements:
Designed and developed a full adventure game with 4 areas, 5 characters, and 27 story nodes using Twine.
Gathered 90 players on itch.io, with 9 leaving comments of praise on the game's jam submission and main pages.
Gathered 90 players on itch.io, with 9 leaving comments of praise on the game's jam submission and main pages.
Design Process
Opening Scene
Original Image vs Compositing in game
A scene in editor vs while playing
Working Within Limitations
I went into developing Climbing Tartarus knowing I would be limited by many things. Firstly, there was a hard deadline to complete the project by: the game was made for a one-week long game jam so I had to plan a project reasonable to complete in that amount of time. Of course, a game jam comes with a theme that defines one's design ("Freedom, but at what cost?" in this case). But this particular jam had an additional rule: we were only allowed to use three colors in our final builds. No more. No less. The rules on this were strict: one hexcode for each color, no fading or gradients, etc.
As an answer to this limitation, I decided to make a monochrome color palette consisting of an off-white, an off-black, and a midtone. In fact, I was also able to use this limitation to my advantage in order to better accommodate for the time limitation. By compositing open access images (using Aseprite to scale, dither, and restrict their color space), I was able to make assets quickly, while developing a distinct and pleasing visual design.
There was one last, self-imposed, limitation in the form of the "game engine" I used: Decker. I use quotes, because Decker is not a game engine in the way Unity, Unreal, and Godot are. Instead, it's self-described as a "holistic medium and toolkit for digital arts and crafts." The tool does feature a number of interactivity features built-in and through official libraries, making basic interaction super easy. However, other things that would be trivial in a traditional game engine are overly complex. As a result, I designed around the tool's strengths.
For example, Decker has built-in UI buttons that can be customized and clicked on. Therefore, a point-and-click adventure game that could leverage the tool's emphasis on mouse interaction was the best choice. The tool also has a number of official libraries, two of which that make dialogue boxes and animated character sprites simple to implement. With these libraries in-hand, I decided to develop some visual-novel inspired mechanics.
Narrative Design (and the Cost of Freedom)
While making the point-and-click and visual novel mechanics of the game were technically relatively simple, these genres inherently rely on narrative to engage players (Reading dialogue boxes is only fun if the dialogue is interesting). I used Twine to develop a graph of story nodes, allowing for branching paths in the narrative and dialogue.
I tied the theme in from both a narrative and gameplay design perspective with the introduction of coins and The Homunculus. A few coins can be found around the map, allowing players to pay for upgrades and healing for their character. But, the player can also find a character known as The Homunculus, that allows the player to kill NPCs and turn them into coins. But most NPCs provide some sort of service to the player, forcing them to make not just a moral, narrative judgement call, but a mechanical tradeoff between the services that character provides and the worth of coins.
This sort of synchronous narrative-mechanical tradeoff is a reoccurring theme in the game. One such example is The Watcher NPC. The creature sits out of reach of the player's Homunculus, and when interacted with will call down to the player's character, commanding they humiliate and degrade themselves for the creature's entertainment. Should they succeed on a die roll, they can earn coins by doing this, but failing nets them taking damage. This example poses two questions to the player at once: narratively, "Is it worth it to submit to this rude, oppressive figure in order to get something that benefits you?" and mechanically, "Is it worth risking your limited life supply in order to gamble for some coins?"
Twine Graph
Homunculus in Action
The Watcher Interaction
The Morgue
Postmortem (and What I Would Change via Necromancy)
Unfortunately, there are a few things holding the game back currently that I would change if given the chance to redesign and work on the game some more. Namely, the BODY/stats system doesn't have as much impact as intended due to a lack of content.
With how short the game is (and how forgiving it's "loss" state is), there isn't much of an incentive to spend coins other than to save a bit of time. And due to the limited time constraint, the narrative ended up being about as half as long as I had hoped. Aside from lengthening the narrative, I would revisit the dice rolling system. I'd like to test out a "Difficulty Class" based system and ramp up the number needed to pass as opposed to the Powered By the Apocalypse style system currently in the game. This way, as the game progresses, it becomes harder and harder (and potentially impossible in some cases) to get by without upgrades.
Speaking of, if some paths are impossible to get past without upgrades, other paths should exist that don't require them. This is another thing hindering the effectiveness of the BODY and die-rolling system. In the jam game, I had wished for there to be multiple ways to reach the ending, some requiring dice rolls, and others requiring more exploration, but again the time restraint made this not feasible.