Course:CPSC312-2023/Pokedex

Course title
Course title
Instructor:
Email:
Office:
Office Hours:
Class Schedule:
Important Course Pages

Authors: Michael Cheung, Angela Li, Justin Jao

What is the problem?

The popular game franchise, Pokemon, comprises a set of games where players collect monsters (Pokemon) with various attributes and characteristics. These monsters can be used in various contexts such as battles, contests, and more. Throughout the game, the unique combinations of characteristics of the Pokemon the player possesses can significantly affect the gameplay in these scenarios.

With a total of 721 and counting unique species of Pokemon across many generations of the franchise, it is difficult to keep track of the details and characteristics that each possess. In the Pokemon series video games, a Pokedex is provided to help with this task. However, it tends to fall short when it comes to the number of options available to filter the results and find what you’re looking for.

Thus, we set out to develop a text-based Pokedex using Prolog: build a natural language processing system that allows for users to build queries as simple questions in natural English, alongside a database that associates the corresponding characteristics to their respective species.

What is the something extra?

Alongside the main functionality of the program, identifying Pokemon that match a given filtering from the user, we plan to incorporate a functionality similar to a recommendation system, which gives users the ability to include the name of a Pokemon within their natural English query, asking for examples as to candidate Pokemon to which it would be strong or weak against.

For example, “What is a Pokemon that is strong against Pikachu?” In this scenario, the recommender could evaluate for Pokemon that have type advantages against the one in question.

Further queries could be made for more general questions that seek to find a suitable Pokemon for planning team compositions, which might be useful for more competitive players in tournament preparations.

In addition, our program simulates having an "offline" and "online" mode. In online mode, we allow users to query the primary type of Pokemon using an external database. Our program makes an external REST API call to PokeAPI to extract type information for a user-specified Pokemon. This allows users to get access to data beyond what is stored in the local knowledge base. To accomplish this, we will use the built-in HTTP and JSON packages to make an HTTP GET call, which returns a JSON object that is subsequently parsed to find the primary type of the Pokemon.

What did we learn from doing this?

While working on this project, our group was able to learn more about working with Prolog syntax, including how to use modules (importing and referencing direct from modules) as well as gaining familiarization with using recursive behaviours to successively prove facts and statements. We also learned about using input/output predicates that are built into the language on installation. Lastly, we investigated into web-related functionality using Prolog.

We found that working with Prolog on this task was a natural fit due to how Prolog, and logic programming in general, is heavily reliant on working from a fact that is already known to be true, and discovering new truths by inference and substitution. Leveraging this alongside recursive behaviours between the head and body of a clause, this becomes a very natural way of developing constraints lists, as we can recursively build the facts that need to be true of a candidate entity from the inside out. This project further proves how Prolog and logic programming is well-suited towards database-like programs, as the rows of a table in a database are directly likened to observations or facts that are considered true, where we can also split the variables of an observation across multiple facts.

However, Prolog has both advantages and disadvantages with respect to natural language processing and variable usage.

Using recursive behaviour to traverse a list of tokenized strings from user input makes Prolog very readily available to parse prior-specified patterns of sentence structures. For example, we can define that a sentence consists of multiple components, where adjectives come before nouns. Prolog will be able to take a certain section of the sentence and parse it as adjectives, before moving onto the next section of the sentence, where we expect there to be a noun. The disadvantage comes due to how Prolog calls predicates in the body of a clause as per the "box model", which effectively locks in a certain sentence structure that cannot be deviated from. So while a particular pattern of sentence is easily parse-able by Prolog, it does not fare well with variations in the order of components. In cases where a developer may want to have multiple orderings of the sentence that are semantically equivalent, all variations of the orderings would have to be anticipated and created as clauses during development. We also have to be careful to include any filler words in the sentence as part of some predicate that Prolog can match it to during parsing and calling predicates (as was the case in having to specify several variations of the "conj" predicate which linked parts of a question together in our project).

Concerning variables and constant assignments, Prolog forces developers to create additional placeholder predicates whose return values can be matched to the arguments of another. For example, when creating the URL for the API call, Prolog requires that the concatenation of the string components be build in the context of another predicate outside "http_open". This would be simpler in an imperative language, where calls to functions can be nested inside others, and resolved at runtime.

Links to code etc.

https://github.com/MichaelTC5525/Text-2-Pokedex

Guidelines

Create Your Wiki Page

Past Projects

Help and Resources

Add a content here. You can also copy and paste content for each tabs from below: