Course:CPSC312-2023-Haskellvaders
Haskellvaders
Authors: Brian, Daniel
What is the problem?
Our goal is to implement a "Space Invaders"-esque game in Haskell. However, instead of the user progressing through levels like the game does, there will be 1 level where the user can shoot as many enemies as possible to achieve a high score. The player will be movable horizontally, shooting lasers at each key press. After the enemies are cleared from the board, the board is reset for a high score to be achieved. The game is highly customizable for the user.
What is the something extra?
Firstly, this project will use the UI library "Gloss" to handle the Input-Output as well as the interface with OpenGL to produce visuals. Secondly, this project was built with customization and developers in mind – every single major feature of this game is customizable in a settings file. The Haskell code has been built to adapt to the user preferences. For instance, the code automatically generates and scales enemies in the game based on the specific padding, the number of rows, the number of columns, and the position of automatically-assigned separation boxes. This was possible by modelling the enemy territory using matrices to build a coherent and simple model of enemies within the game. With other features such as modifying the frame rate, laser speed, and kill thresholds, the user is able to learn more about Haskell, Gloss, and the fundamentals of game design while having fun in a "Space-invaders"-like environment.
What did we learn from doing this?
What became immediately obvious was the importance of early-planning with data types to create a scalable program in Haskell. About a third of the time spent building this project was purely theoretical: debating the advantages and disadvantages of certain data types, and what consequences arise in the use of any of the given data types. As the project grew, it became clear that due to Haskell's "no side effect" rule, it is extremely difficult (or impossible) to add additional functionality to your program without completely re-rooting and re-defining your data types from scratch. Unfortunately, this had happened during the design process and required a complete rewrite of the code. But alas–we completed it!
We believe still that Haskell is a great platform for simple 2D game design. The Gloss library makes creating visual objects incredibly simple, and the functions provided by Gloss fit very well into the broader essence of functional programming that Haskell provides. With that said, Haskell demands significant system resources in order to render 2D objects. We believe that this is a result of a lack of abstraction (i.e. lack of dedicated game engines) to create games that are resource efficient. Such abstractions have already been developed in more popular languages like Python, and even Java. Some game engines do exist, but overall community support seems sparse. Perhaps this is a condition resulting from the relative popularity of Haskell as a programming language.
Overall, there was a lot that we learned in this process. We will conclude by saying that what makes Haskell most difficult (in the context of game design) is the idea that data type must be well-planned in advance. However, we believe that also gives Haskell its biggest strength. Once a coherent and well-planned data type is created, you can watch the rest of your program unfold in front of your eyes. That is a beauty Haskell possess, that no other language alike can take claim to.