Course:CPSC312-2021/Dota2HeroGuide
Authors: Zhihang (George) Zhang, Spencer Yao
What is the problem?
Dota 2 is a multiplayer online battle arena (MOBA) video game that is known for its steep learning curve and complex mecahnics. Part of its complexity comes from the sheer number of heros and their abilities. We want to implement a program that can help players pick heros based on certain criteria.
Examples:
- "What is a melee hero that counters ...?"
- "What is a strength ranged hero that synergizes with ...?"
- "Does meepo counter anti-mage?"
What is the something extra?
- In addition to hero attribute and attack type, we incorporated hero roles (disabler/nuker/support etc.) into the query.
- We extended the definition of modifying phrase to allow multiple modifying phrases connected with "and". This allows user to ask questions such as "What is a hero that counters anti-mage and synergizes with io?"
- We also wrote a python script that scrapes the hero info from Dota 2 Wiki and generates prolog files. This helps us obtain the raw data faster and keep it up-to-date.
What did we learn from doing this?
In comparison to Haskell, Prolog offered a wide variety of different approaches to tackling the same problems. For our particular project, we found that Prolog offered some unique abilities that worked better than Haskell in addition to some interesting, unforeseen challenges.
Firstly, in regards to parsing user inputs and language processing, Prolog was much easier to accommodate than Haskell. This was in part due to how Prolog doesn't require additional libraries, or, in the event that one tries to build their own implementation, doesn't require the developer to constantly worry about types, where noun and verb phrases are along with what the subject/object of a sentence is. We were able to quite easily build upon what we had learned in the lectures to extend our language processing model to accommodate more complex queries like "What is a hero that counters anti-mage and synergizes with io?" - something that would've been much more difficult in Haskell.
However, Prolog was not without its difficulties. For starters, we had to manually input around 2000 lines of properties to establish our database before we got any other work done (and ultimately decided to go to the python script). Between hero types, roles, attributes, counters, and synergies, one of the defining difficulties of working with language processing and Prolog in general is that every fact about the world must be predefined in order for any meaningful output to be produced. Secondly, debugging in Prolog was nothing short of a nightmare at times, as Prolog doesn't give the user the liberty of telling them what errors occurred unless one uses the stack trace (which can easily end up being hundreds to thousands of lines).
All in all, we found Prolog to be very suitable for modeling relationships between entities and querying them. Because Prolog works on the idea of the unification of variables, it handles multiple constraints in a query elegantly and does the searching "automatically" so we don't need to write any loops explicitly. Furthermore, by creating generalizable models of language processing, we were able to take syntactically tricky English sentences and parse them into easily processable, correct formats - all while producing every possible outcome (as opposed to the first one that returns true). This is, in our opinion, a huge advantage over a case where we had to do the same project in Haskell, leading us to ultimately conclude that Prolog is wonderful for tasks involving variable search with constraints like this one.