SWTOR Simulator

[Salain]

Updated: 12/9/11

There are already a number of nice static character planning utilities being developed, so I decided to implement a simulator that tests character build questions that are harder to solve numerically. The project is being developed in Matlab and is reported to run fine in Octave (free download).

(I want to point out early on that the only resource mechanic I have currently implemented is heat for bounty hunters, however the system can/will be generalized to other resource mechanics)

In its current form the program simulates combat between a single player and a group of enemies. The user defines an Approach that the player will take in the situation. This Approach consists of a priority ranked list of skills/abilities along with a set of requirements for usage (e.g. player heat levels, mob status effects) and preference for different types of targets (e.g. lowest hp weak mob, nearest strong mob). The program's engine then simulates battles where the player uses the approach to fight a group of enemies. A summary of the results is then presented, including the % of victories/defeats, the average fight duration, the damage done per second, the frequency with which each skill was used, and various other performance metrics.

I've only been working on this for a couple of days, but I wanted to write down a list of the possible roles this framework could help fill when it its completed state:
1) Comparison between skill trees, Approaches, classes, equipment and skill/ability sets.
2) Quantification of average dps, burst dps, etc across classes
3) Refinement of player Approaches by simulating the removal or addition of new rules dictating which skills are used at what times (aka different Approach). Skill timing and usage can be refined by un-direct brute force simulation of many strategies.
4) Simulation of PVP bouts given two classes, skill trees and an approaches.
5) Determination of Raid Group effectiveness given members, skill trees, and approaches.

Limitations of the current build (aka things to do)
1) Only Bounty Hunter resource mechanic has been implemented
2) Skill trees are largely unimplemented.
3) Stats are only placeholders that aren't effecting damage calculation, mitigation, etc
4) AOE skills and stuns/disables are partially built out but not enabled and debugged
5) Basic graphic output, but no GUI for configuration
6) Enemies are all placeholders
7) No stand alone version.

What is working : You can add enemy types and configure groups of enemies as your opponent. You can use a set of pre-included skills or add your own. You can define an approach which dictates skill use preference, skill use requirements, and mob attack preference. (addition of skills with complex functions may require implementation of new features in the engine). The player and mobs both move across a map in a sensible pattern, if dictated by their preferred combat ranges.

Code is here -> Code

Basic instructions: download all five .m files in the main directory, run buildTest.m to perform a simulation. To alter which skills are used in which situations, alter loadApproach.m. The simplest modification is to change the priority of the existing skills. To add news skills, edit loadSkills.m, although note that the engine has to be modified to handle skills with distinct characteristics from the ones already in the loadSkills.m file. Edit loadEnemies.m to add new enemies, and edit loadBattlefield.m to control what opponents your player will face in combat.

Comments, suggestions, bug reports are absolutely appreciated. If you'd like to do any major revisions or contributions let me know so that we can coordinate our efforts.

12/8 Update Fixed several bugs related to skill usage. Added support for enemy creation, enemy group generation, player damage, and partial support for groups of mobs. Some groundwork was laid for realistic player models (hit points, stats, armor, skill trees, etc). Also improved simulation stat reporting from buildTest. All five .m files are now required. loadApproach contains the player's situational decision tree, loadSkills the available skill set, loadEnemy the available enemies, and loadBattlefield the actual opponent set to be faced by the player. To use run buildTest.m

12/11 Update Single groups of enemies are now implemented. You can add new enemy types (in loadEnemies.m), create groups of them to fight (loadBattlefield.m), choose your preferred target order for mobs and declare an order and condition set for skill use (loadApproach.m). This update is important since it allows for the implementation of stuns and similar effects. Next step is to implement player/mob locations, movement, and skill ranges which should wrap up basic functionality. New stuff probably has some bugs I haven't found yet.

12/12 Update Swapped in a large update including several new files. Players and enemy locations are implemented, along with a first gen and pretty effective move toward/move away system that naturally replicates optimal melee vs. ranged behavior such as kiting. Mob melee has not been included yet and a few player directives are still placeholders, but location and movement are largely working.


Screenshot showing the result of a single battle versus 3 placeholder enemies, 2 weak and one strong. Updates are every 1.5s, corresponding to the global cooldown finishing and a new skill being used. The bottom section shows the average results of 1000 trials @ ~14ms per trial. (note that the most recent version, which has added a map and movement, runs at about 150ms per trial for the same 3 group encounter pictured here.)

[Salain]

Just reserving this second post for examples, here's a brief one I wrote for the swtor.com forum :

Example 1)
For the first iteration I wanted to answer some fairly straightforward questions about the order of skill use in the Powertech BH's Pyrotech tree.

Specifically I was looking at the following situation: if you spec up the Pyrotech tree you will have a rail shot that vents 8 heat if it strikes a burning target and, separately, a chance to have rail shot's countdown refreshed and the next rail shot free following a lucky flame burst (%30 chance for refresh/free rail, provides the burning effect required to vent 8 heat %100 of the time) or lucky rocket punch (45% chance for refresh/free rail). So - how do you weight the refresh versus the 8 heat refund?

Say you are speced as listed above, and you run up to an enemy, immediately flame bursting them which puts combustible gas cylinder's DoT on them. 30% of the time, you will also proc a free rail shot - and will obviously take it within the next 6 seconds. But what if you don't proc the free rail? Is it better to take the rail shot for 8 heat (16 base and 8 refunded via venting) which also refreshes the combustion DoT or to try a rocket punch (a strong dps skill on a short timer) for 16 heat and a 45% chance at a -8 heat rail shot?

The simulation says that using a rail shot in that situation gives you an average Damage Per Second (DPS) of 696.6, while using a rocket punch gives a DPS of 698.7. So a very slight preference towards the rocket punch, but essentially a wash. Meanwhile doing something silly like always using rapid shots in this situation (regardless of heat level) brings your DPS all the way down to 392. 15,000 trials were run for each test.

[Salain]

Adding a new file to the project (mapZ.m) a little routine I wrote as a first step toward moving the player/mobs around. A visualization of its function is attached below. The red Xs are the locations of mobs and the brightness indicates the local "slope" of the map. When fleeing from mobs (tactically or otherwise), the player will typically go down the slope towards safety. That means heading towards the black parts of the map and away from the white parts.



Since Approaches support either a single or a set of preferred combat ranges, it needs to decide which way the player or mob will flee to avoid contact. The need to make that kind of decision would arise naturally when a melee mob is attacking a ranged player. The mob will violate the player's mimimum preferred distance, at which point the Approach can instruct the player to begin kiting and/or stun the mob.

It wouldn't be realistic to let characters/mobs run around on an infinite plane, so mapZ creates a 100m x 100m "room" in 0.1 increments. You can think of the edges of the room being sloped upwards, kind of like a bowl with a really flat middle. The player has a preference to go downhill, toward the center of the bowl. Since the player is fleeing from the mobs in this example, each mob is visualized as a local "bump" or increase in the elevation of the bowl near its location.

That means when the player is in the center of the room where the floor is relatively flat, then the presence of the mob's local distortion dominates the player's response and he/she heads straight away from them. However as the player nears a wall, the local slope due to the wall becomes non-negligible, and the player will veer off to one side or another.

The net effect should be a fairly natural looking fleeing/kiting response.

Update 12/13 Made a little video showing mob/player movement in action.