FireRam

Anatomy of a Golem

You choose your Golem, your attack, and your target: Tap, Tap, Click, BOOM. It’s fast and fun but what’s really going on behind the scenes? Golem Arcana is a complex hybrid of multiple gaming disciplines. Here’s a glimpse into how we mix our particular miniatures chocolate with delicious digital peanut butter. NERD WARNING: In this blog post I’ll bandy about a few code related terms, but nothing too serious.

The Golem Arcana app is a rulebook and referee, and to that end contains a lot of custom logic around what makes a Golem Arcana game tick. There are a set of hard and fast rules that include things like how Golems move around, how cover works, what happens when you initiate a charge, and a lot more. These rules are well defined in code and easy to understand. If I want to see what it takes to hit a Golem with a particular attack, I can look at one function and see how it works. Showing the entire function would take a lot of space, so here’s a look at the declaration:

GetToHit_Layer 1

 

This is fine for steadfast rules that don’t change very often, but to really make Golem Arcana work, we need to be more flexible than that. To achieve this, we start with a few definitions.

  • Abilities are anything that can affect immediate change on the state of a game including Golem Attacks, Knight Abilities, Ancient One Powers and even Golem Movement.
  • Status Effects include damage over time effects, Blessings, Curses, Miracles, and even simple buffs and debuffs to Golem statistics like Dodge or Armor. Damage itself is just a negative status effect to a Golem’s Health, and we record the full history of that damage as it occurs.
  • Finally, any object that can be involved in a game state altering outcome shares a common identity, called an Interface. This includes Golems, Knights, Ancient Ones, Constructs, Relic, Regions (the sub-section of a tile), Abilities themselves, and even our Game Model, which is the object in charge of managing the state of the game.

These definitions will provide a solid base we can build on. Designers are ultimately responsible for creating everything you see in the game, but they need a toolkit to work with. This toolkit is includes all of the digital legos that the engineers create. To create a lego out of a piece of code, we use a code technique called reflection. Reflection is very powerful and allows us to define meta-data that describes our code to itself. It does this using a code tag called an Attribute.  Any action that an Ability can execute has to exist somewhere in our code.

In order to find that piece of code and turn it into a lego piece, we tag it with the ‘ActionCapture’ Attribute.

DamageGolem_Layer 1

 

Once we’ve chosen which code to tag, we push that meta-data to our cloud design tool for our Designers to use when they create an individual ability for a Golem. For you engineers, we’re rolling through every type in every assembly in our domain, looking for our custom attributes. We do this again at run-time, as you’ll see in a moment.

We have simple methods:

SimpleCompares_Layer 1

 

Very specific game actions:

GolemSpecificActions_Layer 1

And higher level actions:

Popups_Layer 1

 

We also use this method to expose actions that return some value. These can used as conditionals on an ability or status effect…

conditionals_Layer 1

Or to check the state of a particular item in the game.

accessors_Layer 1

We use one other custom Attribute, ‘ActionExposed’. This Attribute actually exposes the entire contents of an object definition, dissecting and revealing all the parts that make something tick, like a Golem.

GolemDef_Layer 1

When this Attribute is placed on an object, it gives designers access to all of its component parts. For a Golem, that includes current and last location, health and all basic statistics, their Class, all of their abilities, and even whether or not they’ve been activated this round; plus much, much more.

All told, we have 187 direct code captures and 33 fully exposed object. That turns into a lot of options! The combining of those options is likely another blog post, but let’s look at what we do once a Golem has been lovingly built (and tested, and rebuilt, and balanced….).

Once a Golem (or any other game item) has been designed, we need to get that data back into the app so that the player can TAP, CLICK, BOOM their way to victory. Once all data has been entered into our cloud tool, our build server pulls it down in csv format. That csv is converted into a unique definition per object. So even if a Golem uses a little bit of all types of exposed data, at the end of the day, they are an entity unto themselves. We store this data in a format called JSON.

There is the definition of what makes that Golem up:

bramblehorn 1_Layer 1

And definitions for each of their abilities. Some simple:

bramblehorn 2_Layer 1

And others complex:

bramblehorn 3_Layer 1

When the app runs, it reproduces that same meta-data step we ran earlier, cataloging every exposed piece of code, so that it knows where to look for things. Then when a Golem is loaded, that JSON is read and Reflection is again used to hook all of those disparate parts into a single whole. A whole deadly engine of magical destruction, awaiting your command.

Thanks for taking a peek behind the technical curtain of Golem Arcana, and I hope you all enjoy the game!

-CA