Course:CPSC312-2024/Sorry!

From UBC Wiki

Authors: Annika, Joshua, James

What is the problem?

Our team will build a Sorry! Game engine in Haskell and have an AI opponent for the players. It will be a 2 person game where one is the player and the other is the AI opponent. The game will have a GUI where players can interact and make moves using their cursor.

Here are the basic rules of the game:

The objective is to be the first player to get all four of their coloured pawns from their start space, around the board to their "home" space. The pawns are normally moved in a clockwise direction but can be moved backward if directed. Movement of pawns is directed by the rolling of the dice.

We will be modifying the game from a 4 person game to a 2 person game.

What is the something extra?

We will be implementing a GUI using the Gloss library as well as creating a simple AI that will act as the opponent.  

What did we learn from doing this?

(This should be written after you have done the work.) What is the bottom-line? Is functional programming suitable for (part-of) the task? Make sure you include the evidence for your claims.


James - I (re)learned how to use Git/GitHub as version control. Also, I learned how to use libraries (both importing and exporting) and GUI components (like setting up the grid and the various text objects) in Haskell. I think functional programming made some of the backend work easier, although I don't know if it did much for the front end. Overall I think functional programming like Haskell for games is quite suitable as the predictability of everything due to only having functions is helpful. I don't have another language to use as a baseline, but because of lazy evaluation, the program runs quite fast.

Joshua - I learned how to handle manipulation of data particularly arrays as that was what stored most of out states and I did the game logic. I feel that functional programming made it really complicated to some things that would be simple to do in regular programming languages. But there are certainly upsides, mainly being performance. However utilizing lazy evaluation and other optimizations that the Haskell compiler does is quite hard to wrap my head around, and in some simpler programs like the one we did here is not necessary. And some of the functions I wrote for the arrays that handle the state are definitely not efficient probably because I'm just not used to working in Haskell. For example for updating the value in an array whose index is a certain number took O(n) time the way I wrote it. I think overall for games with simple rules like board games, Haskell is suitable and perhaps preferred if parts of that game are computationally heavy (ie: minimax), but for more complex games with more complex graphics it is hard to grasp where to start.

Work division

How was the workload divided? Who did what? (This can be in a private communication to the TA if you do not want it to be public).


James - GUI / front end, Joshua - Game Logic, Annika - Opponent Game Component

References:

GitHub Repo Link:

https://github.com/gengucan/Sorry-