Skip to content
Evan Quan edited this page Jul 19, 2018 · 5 revisions

Here is the list of central goals I have for Agrippa's Trilemma, and some insight on my intentions in the game's development.

Maintainability and Scalability

After "completing" Cheese Quest in Python, there came a point where continuing development become too much of a pain to be worth it. I thought rewriting the game from scratch in an object-oriented manner would help solve some of the problems I had in maintaining and improving the codebase.

Game Mechanics and Balance

Cheese Quest was never really constrained mechanically from the programming side of things. From all the short to medium term goals I had in adding content, I already had ideas on how I would go about solving them. However, practically implementing these features with the spaghetti-code state of the program, it would become a nightmare to do.

With Agrippa's Trilemma, there were a list of features and balance changes I had wanted to implement:

Day and night cycle

This would change the description of outdoor areas (meaning there would have to be a mechanical distinction between indoor and outdoor locations). Depending on if there is a light source, the visual information available may be different.

Combat

This was something I went back and forth on, mainly due to a conflict of two possible ways this could be implemented.

Inventory weight

While there was one inventory management puzzle in Cheese Quest, I wanted to expand upon it further by introducing a inventory weight limit. Having unlimited inventory space meant that the player could simply pick up everything they could without thinking and without consequence and would have no reason to drop anything.

Expand player stats

Cheese Quest had two stats, health and hunger. I want to improve how those two were handled, and introduce a third stat, corruption.

Health

With the bleeding mechanic, health wasn't really a stat as much as it was a timer for the player to apply a bandage of cast a healing spell before they died. This was back by the fact that many instances in which the player was in danger, health was irrelevant anyways since they would simply be killed.

With the introduction of combat, the total health pool needs to be greatly increased and the "bleed to death" mechanic needs to be either changed or removed entirely.

Hunger

I thought it would be cool to add a survival element to the game by having the player need to carry and eat food to prevent themselves from dying. It also prevented the player from stalling indefinitely as there was a finite source of gold to buy food (although it was quite generous), meaning that progress needed to be made in order to win.

In practice though, hunger was more annoying to track than anything. The amount of times the player needed to eat food across a full play-through was too much, especially when other more important problems were being dealt with at the same time, such as solving a puzzle or fleeing from the cave monster. I still think hunger as a role in the game, but I think it would be best to heavily increase both the player's turn count between eating and the total max fullness limit.

Corruption

Similar to how radiation/rads reduce maximum health in the Fallout series, corruption would be applied to the player from either enemy attacks, consuming certain items, or being in certain locations. It of course could be removed by certain items or other sources. Reaching certain thresholds of corruption may also unlock certain story or gameplay paths, or how certain NPCs react.

Loading and Saving

This may actually one if not the central goals I had since the beginning of the game's development. Figuring out how I could serialize and deserialize Java objects in text files was actually one of the very first things I started working on because I knew that this was central to how the rest of the game was to be designed. I already designed Cheese Quest to work around the inability to save and I didn't want to continue having to work with that limitation.