Course:CPSC312-2023-Text-Based-Game
Tetris
Authors: Benjamin, Guramrit
What is the problem?
We will be testing whether Haskell is suitable to create a text-based game where the user selects from different options and progresses accordingly. The game will also be keeping track of the user’s current state, such as the user’s health and the resources that the user currently has. This state will influence the user’s available choices in the game, and will affect the outcome.
What is the something extra?
We will be keeping track of the user's current state, such as their health and their available items/resources.
What did we learn from doing this?
Haskell was somewhat suitable for our task. We were able to successfully generate our tree and traverse it with proper resource tracking. Creating this tree was was somewhat messy though, especially because of Haskell's general immutability which meant our tree had to be generated from the leaves upwards. Additionally there was one feature we found we weren't able to successfully implement which was a node leading back to itself. This is because our constructor would be recursive without a base case, so we can easily create multiple nodes that connect downwards but creating a cycle is impossible.
I think the main thing we learned was about the structuring of trees with weighted edges in Haskell. Our story takes the form of a tree which we traverse as we move through the story. However, since our resources change and since we require different amounts of resources to take different paths we need to track this somehow. Since we can arrive at the same node through different paths that have different costs, we can't leave the cost and requirement up to the node, we had to implement a class for a weighted edge. Our tree is formed as a collection of StoryNodes and StoryLeaves which holds the current situation joined by StoryPaths which hold an option to traverse to as well as a required type/quantity as well as change type/quantity. As we implemented we constantly had to rethink our data structure as we would find things that didn't work when we added new pieces. Managing the resources independently of the tree was fairly trivial, but in the context of the tree properly filtering out unavailable options based on our current resources and redirecting us to our unconnected "lose" leaves when a player ran out of resources were both quite difficult.