Course:CPSC312-2024/League-Of-Legends-Champion-Reccomender
Authors: Joshua, James Lee, Annika
What is the problem?
For people new to the League of Legends game, it might be hard for players to pick out the best champion to play. There are many different aspects to a champion and it is very time-consuming to learn about each one. We want to create a champion selector based on the player’s preference, playing style, and skill.
What is the something extra?
We will be looking at the League of Legends API or U.GG API to get all the champion data. We will also be parsing data. (We have this file linked in the GitHub repo below)
We also used the PCE library built in to Prolog to make a simple GUI to make the app more legible and intuitive.
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 thought this was the perfect use of functional programming. While maybe a couple of the functions could be more easily written in an another language, adding facts for the 150+ champions in the dataset was made a lot easier due to functional programming. Combined with the ability to easily pattern match and search for recommendations based off of user input, overall Prolog was well suited for this project. With more time, we could even take full advantage of Prolog's ability to continue a search for more matching outputs, which would further add to the project. From this experience, I got to work with Prolog in a realistic project setting and see the full advantages of functional programming, which is very suited for a recommendation app like this. My one other takeaway would be that the UI capabilities of Prolog are not as good as some other languages though.
Joshua - I think for a recommendation system, prolog works extremely well. It is seems like it is super simple to write code for recommending objects based on certain criteria, there is not a lot of thinking you need to do to implement it. For things with a small dataset and not as complex algorithms for recommendations it works very well in this aspect. However I think as you go up in complexity and size the issue of running time may become more and more of an issue, if for example you have a million books you are tryin to recommend based on their criteria, you can't just simply look at all of the possible books, you will need some overhead to optimize it. I think that with this added overhead it becomes less reasonable to do this in prolog. The reason why we were able to write the structure for the code so easily was that we didn't have to think about the running time and how the pattern matching would would contribute to it, many of our statements have pretty bad running time. But if we had to take that into consideration I believe that writing it in a regular object oriented language that we are more comfortable with would be much easier. It would take a lot more experience in logic programming to make it more feasible.
Annika - Eventhough functional programming uses higher-order functions and it enable concise coding and better code optimization, it has its down side. As the dataset size increases, Prolog's runtime efficiency becomes a concern. With large datasets, Prolog may not be practical due to the need for optimization to improve runtime performance. Overall I think for recommendation algorithms, C language is a better choice. While C may require more programming experience compared to Prolog, its flexibility allows for fine-tuning and more scalable recommendation systems.
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 - Worked on the main file GUI components, including updating the values selected by the user.
Joshua - Worked on GUI components, Getting the champion data from the League of Legends API and external sites, and parsed them into the champion facts. Worked on how the recommendation was calculated for the selected fields.
Annika - Developed the GUI and my teammates helped me fine-tune it. Worked on the first draft of the base logic of the recommender. Gathered information from OP.GG.
Links to code etc.