Adventures In Haskhell
Adventures In Haskhell
Authors: Patrick, Pardis
What is the problem?
We will try and create a terminal-based text adventure game engine in Haskell with modular components that supports being able to easily create more text adventures without having to worry about underlying game logic. It will borrow ideas from Laurence Emm's functional programming blog series What The Functional, but we hope to extend his ideas in our implementation, with the ability to have character health bars, abilities, etc.
What is the something extra?
Having looked over a text-based adventure game developed in last year's CPSC 312 course (Course:CPSC312-2018-Text-Based-Dungeon-Adventure), we thought that their implementation of a text-based adventure game involving simply pressing number keys was a bit limiting and not exactly in keeping with the spirit of traditional text adventure games. Thus, we sought to implement both a natural language lexer and parser that was capable of understanding and processing sentences that the user themselves would input, rather than simply handing the user a series of predefined choices that they had to select from using numerical inputs to create a greater sense of game immersion. This also meant threading a notion of state throughout the program, something that while challenging from a design perspective, allowed for a very expressive project after we had completed the
What did we learn from doing this?
What is the bottom-line? Is functional programming suitable for (part-of) the task? Make sure you include the evidence for your claims.
Writing natural language lexers and parsers proved a challenging component, and it was oftentimes difficult to make the appropriate design decisions, so a lot of trial-and-error was involved, however, once it was up and running, we found the expressiveness and power of it to be very impressing, considering it was only about 200 lines of code each for the lexer and the parser, which would then be able to parse well over that number of sentences from a human user. Functional programming's recursive paradigms lent themselves well to creating concise code that would have been much more difficult to implement if we were working with loops or other constructs.
After finishing the terminal-based implementation, we sought to implement a graphical component to our game, with sprite animations or possibly a terminal-based GUI that would display help options or the current items in a player character's inventory. However, after long, extended forays into gloss, brick, wxHaskell, and gtk2Hs, none of them proved very user-friendly and intuitive to use. Most required the understanding of use of a myriad number of Haskell packages such as the microlens package, that proved too challenging to integrate into our already preexisting program. If we were to redevelop our project, we would likely start with a GUI in mind, as development would then be able to wrap the GUI and game logic together, instead of trying to port the game code into a GUI, as this was very difficult to do.