Course:CPSC312-2017-StarCraft2BattleSimulator

Title

StarCraft2BattleSimulator (https://github.com/Mopok/StarCraft2BattleSim)

What is the Problem?

StarCraft2 is a Military Sci-fi Real Time Strategy with 3 races that all have different units. An aspect of the game is choosing what units to use in your army. The player has to make decisions about what units to use in their army based on information they know about their enemies army, resources they have available and what units they have available to them. This is often left to instinct of the player because their is so many variables to keep track of. Our program will give some numerical evidence behind army composition decisions.

Our project will have a config file of stats of units in the game that is customizable. The user can input one enemy unit, how many of that unit, minerals available to user, gas available to user, user's race and user's value of gas to minerals.

The program will build the maximum number of each unit available to your race. Then simulate a battle between the enemies inputted units and each one of the units your race can build. The program will output a list of units that were built and show their results from the battle simulation. The program will give a summary of what it thinks is the best unit for you in this scenario

The program will need to take into account many different stats for each unit; HP, Armour, Shield, Attributes, Ground Damage per Second(DPS), Bonus damage modifiers, Attack Cool-down, range of attack, and movement speed. There are other aspects of the game that our program won't take into account, such as splash damage, and unit collision limiting the damage done by melee units. We decided to not include air units to keep the scope of the project small enough.

What is something extra?

The editable config file will make our program go the extra step. Not only will the program help players playing the original game, but it will also allow for customizable scenarios to be made.. This could be useful for balancing the game. The program also does battle simulation using a tick function.

What did we learn from doing this?

We learned that prolog isn't the best suited tool for a simulator. This is because our simulator had to keep track of a lot of state variables for the simulation, this made the code overwhelming because all the state variables had to be passed as parameters. Also, we weren't able to run multiple tests with different inputs simultaneously. We had to test each function with a specific input each time. This made it difficult to keep track of what you were testing for. Prolog code is also delicate because of the fact that it depends on the order the cases are defined. This made it easy to accidentally break something.

However prolog had an easy way to log results from the simulation due to pattern matching printing. Prolog also has an easy way to define and access information from our Knowledge Base using triples. This allows users to easily change the knowledge base. Also by using triples and Prolog, we also have flexibility in the future to add a natural language interface to allow the user to modify the KB more intuitively. Prolog also had a faster fun time than expected.

If we were to continue to work on this project with prolog I believe it would be a fine tool, as we could simply define more relationships in prolog. However, we risk having our code getting overwhelmed by a large amount of arguments for each function as the simulation gets more complicated.