Pokemin
Authors: Evan Wang, Jeremy Ten Sing
What is the problem?'
Pokemin is a story-focused interactive adventure about a boy named Min who sets off an adventure to become the very best. It's an extremely abstract reason to leave home at the age of 12 to be honest...his parents wanted him to be a doctor.
- Branching storylines, with the user entering natural language to select choices along the way
- Access and update resources available to Min as he goes along his adventure
- Access save states, with Min's previous location and status
Below is an overview of different areas of things to be made:
1. Trainers:
- Contains a name associated with each trainer
- Associated with an id, mapping each id to a unique mon with stats and levels
- A list of static trainers can be kept in the base,
and encountered based on which route is taken
2. Mons:
- Each mon should be associated with an ID, name, and type
- An instance of a mon should be based on an original template
with all of its associated base stats
- Stats should scale with level
- Each mon should have the following stat fields:
- Max hp
- Attack
- Defense
- There should be 4 moves associated with each mon
3. Moves:
- Each move should have a type
- Each move should have a base atk, which will directly feed
into calculations for damage
4. Story:
- Can model entire map as an interconnected database
- Can be a relatively short maze like place
- Navigating to locations will result in encounters with trainers
- Elite something, idk, could happen at the end
What is the something extra?
The project will include dynamic changing of sections of the knowledge base, updated as Min goes through his adventure. This will update things such as Min's unique statistics when compared to the world, his resources etc. In addition, we will look to update a file containing updated information, such that a person engaging with the program might be able to access their previous save state.
- Story and geographical map will be representative of a graph
We abstracted the details of the game world into a knowledge base that we can then manipulate. The different areas in the game are integrated as a graph so the character can move back and forth along paths set in the knowledge base. Dynamically changing the knowledge base worked great in Prolog to detect events associated with each area, which can then be turned off for when the player returns to that area.
The implementation of the battle sequence as a turn-based system also made extensive use of the abstraction of monsters and their stats. Type advantage was simple to implement by simply writing the knowledge base. Prolog allows us to grab the stats directly to calculate damage and dynamically allow monsters to grow after each battle. By pattern matching, we can easily set monsters for trainers and wild encounters, as well as resetting the party for the next battle.
What did we learn from doing this?
What did we learn from doing this:
- Abstraction of a relatively complex world and elements into a set of facts that represent the world simply, as well as a set of predicates that can generally manipulate those facts
- Iteratively adjusting our program as it grew so that the accessible facts were limited to what we strictly needed, and refactored with less redundancy or potential redundant access in mind
- Defined and maintained clear relationships between elements, such as how areas were connected, as well as trainers and their pokemon were maintained in a simple database
Overall, logic programming was especially useful in quickly creating a large set of facts to manipulate, without some of the hassle that comes with needing to define new classes that may or may not be used down the line. This quick “prototyping” of relationships within our knowledge base allowed us to test how we might want to represent the overall system.