To Craft a Sim – Part 5

In this series of posts, I’m talking about putting together a simulation I’ve built called CHsim. It’s designed to simulate the way Chain Heal will behave in Warlords of Draenor – including interactions with player positioning, talents, incoming damage, Riptide, and Mastery bonuses.

My first post in this series discussed why I’m developing CHsim, and I left off by pointing out some good reasons why I’m not using SimCraft to achieve my goals. The second post talked about raid positioning and how I’ve modelled a “realistic” raid. The third post discusses the way I’m making Chain Heal bounce from person to person, and was supposed to talk about what that means for High Tide modelling. However, I didn’t get as far as that and had to tackle it in Part 4.

Capture

For the fifth post in the series, I wanted start talking about the practical part of the simulation; how you go from a raid layout and a system for making Chain Heal jump between them to a fully-fledged simulation of a fight.

What’s Missing?

If I were to write out the essential steps in a simulation for looking at Chain Heal statistics, it would go something like this;

  1. Generate a raid’s positioning.
  2. Give each raid member some initial health.
  3. Set up some Riptides on the raid before the simulation starts.
  4. Simulate a length of time in which the Shaman makes decisions based on settings you have given.
  5. Each time a spell is cast, decide who Chain Heal heals.
  6. Once the spell has been cast, update player healthbars based on the Chain Heal healing formula.
  7. Include Mastery in the healing calculations.
  8. Repeat the simulation for several different positioning and initial health values.

I’ve put in italics the actions I’ve already detailed in this series, and in bold the point I want to elaborate on today. In future, I’ll start to put further blogs in this series into context using the same system.

(Aero?) Dynamic

Making an actual time simulation is the most tricky thing to set up and conceptualise, but is the most important in terms of the functionality of your simulation. If you don’t tie all your clever pieces of code together, you’ll never get it to really inform you of anything new or useful. (Actually, you’ll never get it to tell you what happens in a dynamic fight; you can look at static situations all day, but that’s not what’s interesting to me!)

So: what does the “dynamic” part of the simulation actually do? You can think of it like this; it splits up the fight into equally spaced segments of time. For an accurate simulation, they have to be small segments (think somewhere in the region of 100ms or less). For each time segment, the simulation needs to do these things;

  • Check whether a heal’s being cast.
  • Complete casts of Chain Heal by selecting targets for bounces.
  • Apply healing from Chain Heal.
  • Decide whether it should start casting a heal, and if so on who.
  • If so, ensure that it triggers things like cooldowns and the Global Cooldown (so you can’t cast Glyphed Riptide once every 100ms!).
  • Apply damage to the raid.
  • Ensure that dead people stay so, and that people don’t go above 100%.
  • Record relevant information like the number of Tide Pool targets or the number of Riptides active.
  • Move on to the next time step, repeating from the start.

It can be a lot easier to understand how this works with a flow chart, which happens to be one of my favourite things;

FlowChart1

 

When you put it down in this way, you can see the way the program has to flow, but you also see how much of a daunting challenge it is to get the thing working. Remember – if any part of this fails the entire simulation could give you results that don’t reflect reality!

To make it even more awkward, it’s rather difficult to think up a good way of testing whether your routine works correctly. Rather than being able to show you a pretty graph, you’ll have to take my word that a) all of the individual bits make sense and b) It doesn’t break. Sadly, such is the way of programming sometimes.

One interesting thing which I’ve been trying to do is to make an animation using the data produced by the simulation – at each time step I can get it to tell me what the health level of each raider was! So it should be reasonably straightforward to make an animation showing how players’ health changes over the course of a fight; you shouldn’t, for example, see anyone at above 100%. I had a go at it, and you can see the animation here. It’s one of those cute little things that I think makes simulations like this accessible.

Next time, I might follow up on my promise to talk about healthbars and damage.

Advertisements

About stoove

A physicist, researcher, and gamesman. Likes to think about the mathematics and mechanics behind all sorts of different things, and writing up the thoughts for you to read. A competent programmer, enjoys public speaking and mechanical keyboards. Has opinions which might even change from time to time.
This entry was posted in Alpha/Beta News, General Science, World of Warcraft and tagged , , , , , , , , . Bookmark the permalink.

2 Responses to To Craft a Sim – Part 5

  1. Thanks for the info, just started playing my shamans at cap level again, your information will be extremely helpful.

  2. Pingback: To cast, perchance to Chain (Heal) | UNconstant

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s