Tag Archives: design

Monster Roller is a monster strategy game with a hybrid slot machine combat system for mobile by Boomzap Entertainment. Hatch, raise and train monsters to fight against your friends in online PVP or explore solo adventures offline!

Communicating Progression


We’ve spent a lot of posts talking about the battle mechanic and the refinement of it from an unstructured mess to a set of actions that can be built on for strategy. We’ll be going what features are implemented for progression, and importantly, how this is communicated to the player.


Instant game loop, just skin it a thousand ways.

What Features Are Involved?

Each battle brings the player closer to understanding the way their fellow players strategize or expands on their knowledge of slots (abilities). This is knowledge (metagame) progression. The Player is also rewarded with gold, which allows them to buy more monsters – progression in their collection.

For Monster Roller, the following features work together in the loop:

  • Battle. This is the start of the loop.
  • Stages (for Offline Play). The player progresses each time s/he completes a level. This appeals to players who want to complete every level. Offline play also builds confidence for online play, because the player is learning about the monsters and their different abilities.
  • Leaderboards (for PVP). The player can see how they stack up against their fellow players.
  • Level Up System. The monster levels up based on role, with additional bonuses.
  • Evolution System. Monsters can evolve, and adult monsters can help gain more monsters through egg-laying rather than relying on the store. Evolutions have different stats & different abilities.
  • Store & Incubation. Earning gold gets spent here.

Some Examples!


(1) It has to be obvious.

mr 2015-08-27 15-21-28-38

A basic example: indicators show which level difficulties the player has beaten.


There are also clear indicators showing how hard a stage will be.

(2) It has to be rewarding.


People like seeing bars fill up.

(3) Player control is good.

LevelupBonusesPlayers get to choose in what way additional bonuses are distributed to a monster. While these bonuses are not large enough to turn a defensive tank into an offensive tank, the reward is in the addition of the points themselves and  getting to choose where those bonus points are spent.



Monster Roles and Strategy

Monster Roller was conceived during a pitch meeting. After seeing a couple of suggestions for games, the boss made his choice and said:

“We’re making a slot machine game.”

I was about to make this face:


But quickly remembered I was a mature adult and so slapped on a smile. A professional smile.


“Yeah, sure,” I said.

I too had my ideas during that pitch meeting, which were all tossed in the bin. That was fine. The bigger problem, to me, was that I was making a slot machine game. ‘What the fuck,’ I thought. ‘A slot machine game. I was not put on this god damned planet to make a slot machine game.’

A more elegant way to phrase it:

Where was the user agency?

That was my number one, eloquent, professional concern.

The boss kept on saying ‘make it random.’ No. Fucking. Way. I tried that. It was a mess. How the hell can anyone play a random game? Why would anyone play a random game? I preferred skill and strategy with a side of RNG. Not RNG with a side of skill and strategy. Obviously I was not building this game for me but for others (games are product, guys) but I could not see how anyone would play… something… entirely… random.

That being said, after my initial shock wore off (and I tried most of the ideas that turned out not to work), I started to see the logic behind the choice of a slot machine game.

Number One: No one had ever successfully made a slot machine game with a strategy element.

Design is about solving problems of interaction, communication, and game mechanics. This was, from a certain point of view, a fascinating exercise in making the mechanics associated with slot machines (such as jackpots, holding, etc.) work within a battle framework.

Number Two: Everyone gets the idea of a slot machine and the additional depth keeps them hooked.

I could treat the simplicity of the game as a gateway drug to the heavier gameplay aspects of deck building, targeting, betting, elemental strengths and weaknesses, and so on.

Number three: People love monsters, which was the chosen theme.

For today, the reason why I brought up my bitching over the lack of player agency is because I want to show one part of the solution to mixing strategy with the slot machine.


Building Plays

Each monster in the game has a role. In a role-playing game, you wouldn’t use an all-fighter party, especially if none of them could heal. Naturally they’d all be dead at some point without a healer. The same principle applies to Monster Roller. The idea here is that pairing monsters produces better results. This party building, according to how the monsters synergize is called building a play.

We have four basic types of roles:


Whatever role a monster has, all monsters have two modes. The first mode, by default, is the attack mode. Then the second mode is the ability mode. Different roles have different abilities.

  1. Fighters
    1. Mode 1: Attacking
    2. Mode 2: Defending / some self-healing
  2. Healers
    1. Mode 1: Attacking
    2. Mode 2: Healing / Shielding / Protecting / Removing Debuffs for other party members
  3. Disruptors
    1. Mode 1: Attacking / Inflicting Status Effects
    2. Mode 2: Mostly defending itself, similar to Fighters
  4. Modifiers
    1. Mode 1: Attacking
    2. Mode 2: Various Buffs (affects an ally’s next move)

We’ll go over them in the next section.



Fighters usually have a high attack and low HP, though sub-types (that we won’t get into this time) vary in the degree of attack/hp and in slot (ability) composition. They can only attack in varying methods and defend. You won’t win a fight fast without these guys.

The very first fighter we made was Magmus, and he has a low HP/high ATK combination (this sub-type is known as a Glass Cannon.)


His low HP makes him heavily dependent on healers or supporters. Below are his slots:

Attack Mode:


The top row is simply different art for the same basic attack value. (Get 3 of a kind for a huge jackpot!) Then the other slots are the weak attack, critical, and special ability (2x attack). Lastly, they can also mug for gold.

 Defend Mode:


Various kinds of defense: immunity (with wings) means no damage taken at all. There’s a long shield (with the 2), a short shield (plain shield), a shield that also nets money, and a resist shield (with the paw) — it resists negative status effects.

Then there’s also a self-heal, though that happens rarely.

Other fighters, like Snapplant, have a higher HP but lower ATK, but sometimes have very cool abilities. Snapplant in particular, is somewhat harder to get than Magmus because of its Party Drain ability.

mr 2015-07-30 14-52-56-77


The half-full heart means a party drain attack. It’s pretty powerful.


Supporters and Healers

These guys usually have the ability to attack and heal, shield or protect. Protecting is separate from shielding — it’s a skill where the monster protecting takes the damage instead. The shield is your typical defense up spell.

Some supporters can also remove bad status effects (debuffs), give the regenerate buff, and even attack well (at the expense of HP).

Totoduck is an example of a monster with a decent attack stat, low HP, and useful abilities (though it cannot defend itself.)


Totoducks can shield the party, heal the party, or heal an ally (icons, top to bottom). Their attack stat grows similar to that of a Fighter.



Monsters that cause various status effects. Their abilities aren’t so great (it’s hard to make jackpot combinations with them) and they can’t heal themselves. However, all debuff abilities stack. If you get stunned twice, the values of both stun abilities are counted — which means a world of pain when you get stunned for four turns twice.

A good example of a monster in this class is Flurriken. Flurriken can stun the entire party for a single turn, or shrink other monsters, halving their stats.


To counter these, Totoducks are usually added to a team to provide support. Another tactic is to wait it out and counter with buffs like regen.



Modifiers are fascinating, high-HP, low-ATK support-types. Their abilities are subdivided into rate, duration, and area of effect modifiers. Basically: they buff the person next in line.


All the slots on the far right affect the monster next in line.

A rate modifier, like Nattilus, makes adds a bonus range from 1.5 to 3x on whatever is rolled by the next monster.

In this example, Nattilus is adding 1.75x to Pyropup’s party attack. If Pyropup’s attack value is 8, that means it will deal 14 damage to EVERYONE. 

Some Common Plays We’ve Noticed:

Hoopip + Any Low HP Character (typically Magmus)

mr 2015-07-30 17-04-28-49

Hoopip can regenerate itself and protect other monsters; that way you don’t have to heal anyone and it just soaks up damage.

Zenzird + Gillbane

All of Zenzird’s abilities either turn single-target abilities into PARTY attacks or lengthen the duration of a debuff (by 1, 2, or 3 turns).

Nearly all of Gillbane’s abilities are single-target debuffs (stunning, poisoning, or both).

Combining them results in either party-wide stuns or poisons or poisons / stuns that don’t end.


Five of Gillbane’s attacks deal a debuff.



Zenzird is a duration / Area of Effect modifier.

There you have it! Hope this guide explained how to build plays and teams.

If you are interested in fighting a live PVP match against the designer, get in touch!

Design Log: Functional Requirements

Hey guys, today’s post is about making games, prioritizing features, and breaking down functional requirements.


Industry Identity Crisis

Quick question: are you in the software industry if you make games?

The short answer is no. (The longer answer is ‘sort of.’) More accurately, the games industry is in the business of entertainment. Your job, as a game maker, is to entertain people. Make them feel better about themselves. Reduce the complexities of the world into a pixel-perfect, enjoyable experience. Games have objectives that have tangible rewards (story progression, beautiful art, nice cutscenes.)

Meanwhile, if you look at a word-processing software, like Microsoft Word, it has a bunch of functions that allow you to type in something, say, a book report – and functions that (1) save the data you input into a file and (2) transmit the data into an output device, like a printer.


Software development is about building something that fulfills a definite purpose. Nor do you need to create data for the software, unless it’s a help document. The end-user creates the data – book reports, inventories, invoices, user accounts, digital art, and so on.

The point here is that video games have a really abstract function: fun. And to fulfill this elusive human desire, we have to make some software as tools, and make the content of the game for the person to play with.

  1.  You need the tools (software) to craft an interactive experience
  2. You need the data – player classes, enemies, the story – that the user manipulates for fun
  3. You need to make sure the data and the software it uses is optimized so that people can play it

ScreenHunter_298 Jul. 16 03.41

A very, very simplified chart of what we do.

Today’s design log is about functional requirements in games. While it sounds pretty straightforward to have a list of features and the parts needed to fulfill that feature, it can get hairy pretty fast.


Making games is a mess

Functional requirements change all the time. You start out with one feature – say, a battle feature – and pretty soon you may have an item system, maybe the battle has changing environments, maybe the environment modifies the abilities of some player character type, and so on. See those old mockups for Monster Roller, the game we’re currently developing? The game would have been balanced vastly differently had we included items. Or trainers on our monsters.

The knee-jerk reaction at first for a game with an RPG looking battle system is ‘of course your game needs an item system, power ups, a store, and so on.’


“Why didn’t you figure out you’d need all this?”


“Why didn’t you figure out that you DIDN’T need all of this?”

Making games is a mess, because true innovation is a mess. The other kind of innovation is ‘iterative’ — building on known formulas. Games are made of a combination of both, in varying degrees. While developers may get tied to certain formulas (a racing game needs these kinds of tracks, these kinds of powerups, and so on), at the end of the day, you can’t serve a mojito like everyone else’s mojito in an industry where so many are willing to give eight or usually more hours at NO PAY into finding the holy grail of fun.

Making games is a humbling experience. You start out thinking you know what this game is going to be.

ScreenHunter_306 Jul. 17 17.32

It’s a tower on the verge of being unbalanced, all the time. Maybe it turns out that it’s too derivative, or the mechanics were too different to be meshed together, or it is hard to get into, but fun. A certain degree of experience mitigates this, of course, and a veteran will likely have a better idea of the pitfalls, but the true creation of something is always… unexpected. That’s what being new and innovative is about.


How functional requirements evolve:

We prioritize based on how core the feature is to the game. Then we make layouts based on what we think we’ll be putting into the game, with sample data. For this last part of the article, we’ll go over the battle system’s components. We had several functions we wanted to do, at the very beginning:

  • We would have the slot machine reel, of course
  • Which would net bonuses based on jackpots (4 of a kind back then)
  • We considered bet multipliers
  • Holding’ — keeping a slot from spinning (you would have to pay to do this)
  • Switching out monsters during your turn
  • Using items on monsters (that was the ‘obvious’ thing to do, wasn’t it?)

That is not a list of functional requirements. That’s just a wishlist. Functional requirements may include things like a proper description of what’s going to be in it (the data), how it’s going to be presented (UI), and success criteria if it’s working the way it should be working.

Let’s look at the items system for example:

  1. What would be an item’s scope? Would they be used on the player’s party, or enemy party, or both? Can they have a duration? What variables can these items act upon? HP? Attack? Heal value? In percents or wholes? And so on.
  2. Could they be reused after the battle, or are they consumable per battle?
  3. Do they have a cost to use them? How is this cost implemented? Is it the number of turns in a battle (time cost) or some other metric? Do you have to buy them in a store? Hardccy or softccy?
  4. How would it look?

… And so on. The document that answers those questions will then be the functional requirements doc.

Now, as to the evolution of all those systems and functions, let’s take a look at battle.


The left mockup was made by yours truly almost half a year ago. The one on the right was made by a real artist, and is how battle looks now. Let’s go over what we see on the screen to find out how the functional requirements changed between then and now.

Top Row Old:


Top Row New:



They both have a gold indicator and a settings button. The prototype’s Autoplay moved to the bottom row in the latest version (see below.)

The biggest change is the addition of lights around the frame that change based on what’s happening, and the timer. We added the timer because the game is PVP — it would suck to be waiting for a long time for your enemy from around the world to decide how to attack.

Battle Screen Old:


Battle Screen New:

ScreenHunter_307 Jul. 17 17.40

You’ll notice the original mockup failed to account for selection indicators (the arrows on top on the left), or showing things like negative/positive status effects (look at the super tiny monster!) There’s also the difference of seeing your monsters in battle. The other major change was simplifying from 4 monsters to 3 monsters. We did this to speed up the pace of battle and to make it easier to gain a jackpot.

Rollers and Avatars, Old & New:


Lots of changes here. Let’s look at the cherry bar first. The cherries were to be earned for every round in battle, filling up slowly. The other way to gain them was to roll them. These cherry points could be spent to use an item, or switch out characters, analogous to mana or energy in card games. However, the item system and the cherry points were both later removed.

We didn’t add in the cherry points because “it was what everyone was doing,” either. We added them in because having that choice made the game less about luck and more about strategy — choosing the ‘right’ action. Do I use THIS item or switch out THIS monster? We had a definite reason for having items and costs.

Why then was the system scrapped?

If you look at the variables of a battle game, there are plenty of factors that can be controlled without adding another system:

  1. Targeting — Will you auto-target or focus on one?
  2. Abilities — Attacking, De/buffing, Defending, Healing, Elemental strengths and weaknesses
  3. Combos — Three of a kind jackpots, monsters that can ‘buff’ other monsters’ abilities
  4. Lineups — This affects the chance to get combos
  5. Time Limit — you have this much time to decide what your strategy will be

It’s tempting to add in a feature at the beginning of development. This is because it’s difficult to visualize how features interact with each other and how it impacts the gameplay. It’s easy to think ‘this is not enough’ because we haven’t yet created content. Prototyping helps greatly in killing that feature bloat temptation. Considering all of the above variables, the item system would have been another thing to balance — not only for the devs, but for the player as well. The idea is to make each of those variables above relevant to winning the game, not to add another feature.

Amazingly enough, there are two other variables we could spend all day talking about, compressed in this section of the UI: how the roller behaves and what goes into the reels. (Does the slot machine have a ‘hold’ function? How does it process a jackpot? If a monster is stunned, how does the roller react? How are slot compositions made? Do all slots have some kind of 3 of a kind jackpot? Etc.) For now, a passing mention of all these variables is enough to illustrate the evolution of the function.

The last change in this segment is the Let’s Roll button. Although originally we were thinking it would be fun to flick the reels, quite a few playtesters looked for a button (playtesting is an excellent way to determine functional requirements) so we added one in to make the game more intuitive — just press the damn button!

Bottom Menu: Old

adfasdfBottom Menu: New


And now we get to the last segment: the bottom menu. You’ll see the price for the items and the switch out action available in the old version, which was simplified down to autoplay and switch out. Another reason for careful pruning of systems, apart from the great number of things the user has to keep in his or her head, is real estate on the screen. The language in Monster Roller is already quite dense with the icons, jackpots, elements, and targeting. Adding another visual language is another set of things for the user to memorize.

Phew. That was a pretty long post.

Quick recap:

  1. Game development is closer to the entertainment industry.
  2. Ditch the mentality of ‘clinging’ to a certain set of functional requirements. They change, a lot, in ways that will surprise you.
  3. Games are made of true and iterative innovation.
  4. Defining functional requirements is more complicated than just writing down a wishlist. Ask yourself how this feature interacts with other features, and list down all possible ways of implementing this feature.
  5. Prototype the core feature based on the functional requirement and prepare to tune/tweak as needed.
  6. You’re not done until it’s fun.

Congratulations for making it this far. Here is a picture of bacon.






Upcoming Features

Hey everyone,

Things have been busy for these past two weeks.  In this week’s update, we’ll be showing some upcoming features that build on the core loop of the game. So here’s your first ‘top level’ view of what the rest of the game’s features are, apart from battle:

It looks like Dragon Ball, somehow. This is our ‘egg capsule’ dispenser.  We’re still working on how we want it to look like and how the egg will be animated.

pvp_arena select

This is what our PVP tab looks like. We’ll have leaderboards and daily challenges where users can win more gold.


A small new feature: you can find out skill the enemy bopped you with! We recently had a playtest, and most people wanted to know what the enemy did to them. So now we have a tap hold feature where they can see what the last rolled ability was.


Incremental change: Monsters now have roles to make it easier to figure out what they’re doing. It helps people make teams and decide which enemy monster to kill first (Do I hit the healer first? Or the glass cannon?)


New feature: Teambuilder now shows monsters, which can be filtered based on the icons above. Currently the red icons show roles such as Fighters, Healers, Modifiers, and Disruptors.  It can also be sorted by HP and attack.

You’ll be seeing these in action, through a video, in a few weeks.

Till next time!



Design Log 2: The Compellingness of Battle

Hey rollers!

This is Sara writing another post about design. There’s a lot going on in development. We recently had a major meeting to figure out how we would close the game loop, and also discuss the compellingness of the game.

We’ll skip over the game loop stuff for now and focus on the problem of being compelling.

The problem of Monster Roller is that it isn’t compelling enough. When people test the game, they give it back after a few minutes. Initially we were thinking that it was because we hadn’t closed the loop and that there was no sense of a larger progression beyond battle. But that’s because we keep thinking of MR as an RPG-like game. It looks like one, so there is that expectation.

But it’s not like an RPG at all. There are plenty of games that survive on the core mechanic of doing something well, where progression is simply measured in high scores. While MR will have eggs to collect and leaderboards for PVP, the case for games which are purely played for the core proves that compellingness isn’t really about ADDING a feature (like a Quest System). Tetris doesn’t need to unlock additional blocks after winning each stage to be interesting. It’s interesting in its core puzzle mechanic. Same thing with Flappy Bird.

Tetris-VeryFirstVersionSimple and addicting because its core mechanic shines. Image © Aleksej Patinov, as Fair Use.

The same case can be applied to Monster Roller. The point is to make battle fun. The way it was a few weeks ago was… not that fun. (It wasn’t the author that pointed this out, incidentally. Credit goes to the Creative Director.) If the core mechanic is not that great, people won’t bother to get as far as collecting eggs, anyway.

The fascinating part here is that this is the designer writing this post — and I’m more concerned about keeping balanced stats, making the UI clear — but even I have to put my head out of the sand and realize that different games have different killer features. And battle is this game’s killer feature.

Currently we’re working on making battle feel faster and snappier.

This involves playing with several variables: effects, rigs, timing, and the information that has to be displayed. For now, instead of going in depth on all those variables, I’ll leave you guys with two gifs showing different ways we’re thinking of approaching the problem. When battle is sorted out, I’ll go over these same variables and explain how they work.

4 blogpost

4 blog post 2

PS: A disclaimer — what I’m writing here reflect my thoughts as a designer. Actually the team itself has different opinions on what makes the game compelling. We’ll be seeing how those hunches develop too as the game is developed.



Late Post Is Late, Also Heavy: Design Log 1

Quick contextual note: Everything written about ‘game designers’ here is not uniform to all companies. We all have different ways of working.


“We need more things.”

Design: The job everyone thinks they can do. Whether you’re a game designer, a product designer, a UX/UI designer — it’s all the same.

People frequently do not know what a designer is, or the problems they really solve, or the value in what they do. Ironically this is the nature of the job: if someone notices something, it’s because it sucks. Good design is something people should take for granted, because it’s just supposed to work. Naturally this means that the only time designers get feedback is when it’s bad. This is why designers are drunk all the time. This is also why everyone thinks they can do the job.

We live in a world that is deliberately designed. Most people don’t notice it. But a chair built today is made of thousands of years of iterations — what if we added rollers? What if we added padding? Someone designed those, until we had office chairs and reclining chairs and so on.

In the vast swath of the design world, today we are going to focus on the question: what do designers do? Fair warning: this gets technical especially in part 2, which is about balancing.

Designers are implementation people, and sometimes idea people. Very rarely do I, personally, get my idea into the game. When you work with a team, you will find that everyone has ideas. Everyone shouts into the room, while you and the programmer watch. Occasionally you will be required to submit an idea, because people think you’re not doing your job if you don’t have any input. The truth is that the magic isn’t in the idea, it’s in the implementation. And the truth is that it is less about whose idea it is and more about what idea is just more suited to the function and context of the game (and company tech.)

Most of everyone’s ideas will lack actual body or planning. That is the nature of an idea. Your job will be to refine and define it. I call this process foretelling the future (ha, ha, you say). It’s very easy to suggest, ‘Let’s add another mechanic,” — a lot harder to know how much concrete effort it will entail. For example: “We need more slot types,” translates to “we need code, script, animation, art, music, testing, in the following X work units.”

The concrete output of a designer is this — blogs, tasking, and scripting. Lots of scripting (this is where level design, monster design, and the like come in.) We also explain stuff, coordinate stuff, make sure the team doesn’t kill each other, and we also train staff. Trivia: a new artist once asked me what a sprite was.

That seems like a lot of work! It is. Most of the day just goes into asking myself, “What am I doing? Where did my day go? Why am I drunk?” But in all seriousness, the other task of a designer is to build tools that automate script building and other tasks. A simple example of a design task that I am working on in Monster Roller at the moment:

Problem: Make me 100 monsters that are balanced according to rarity weight.

Let’s try to visualize in our heads a similar, simpler task: try to make fifty monsters in an excel sheet, with attack, defense, and heal values, and special abilities, and try to make a basic sheet where they are fighting 3 on 3 (just repeat the battle loop until they are dead.) Just try to imagine that — coming up with 50 unique monsters, with different but balanced stats and unique abilities.

The thing is, after all of that, that’s not even really the whole picture. The question is: to what end are we refining these stats for? What are we making 50 monsters for? I won’t answer the existential reason (it’s not in the scope of this piece), but the pragmatic objective is to give the player a set of concrete, clear choices in how they will win the game.

Game design is about player choice. Game design is all about presenting those choices to the user in clear interactive language, the whole gamut of graphics, text, and animation.

Games are all about interactions. Why interact with something if it’s the same old interaction all the time?  The big chunk of design answers how to present those choices to the player, to make people want to choose.

Anyway, I think that’s some pretty heavy stuff to digest.

The next part of this post (if you scroll down) is a simplified breakdown of how we balance monsters. It has pictures, at least!


A normal day at work, versus build submission for some milestone.

How We Make Monster Stats

For the first four years of my stay in Boomzap, I was building levels — you can think of level design as that part of development where you design mazes, blocks to jump over, and decide where to put enemies. Monster Roller is a huge disconnect from that. It is ridiculously simple to build a level: you just define the enemy monsters and your own.

The interesting problem here is making the values for the enemy monsters and your own, especially considering the balance of ‘mindlessly flicking around till you win’ vs adding ‘strategy’. My current thought is that PVP will take much longer than offline play, being the more ‘hardcore’ mode of the two.

As you can see — development is subject to change. A lot of change. Instead of me adding thousands of platforms and dungeons and enemies, I am instead recalibrating each enemy and each player character a lot, especially as mechanics for the game change. During the ‘recalibrating’, this mostly means testing in iterations, hand-editing a few monsters. However, when it is time to apply it system wide, obviously hand-editing each is a bad idea (especially without structure.)

Here’s a screenshot of what data constitutes a monster:

Snap 2015-03-27 at 18.08.04You: Okayy… this is kind of intense.

Snap 2015-03-27 at 18.16.52You: So this is kind of awesome, but the writer hasn’t exactly provided context.Snap 2015-03-27 at 18.09.22You: Ok that’s it, three monsters is enough!

Let’s breathe in and out and scroll down to see a simpler, friendlier diagram explaining what all that stuff means.


Ok, I hear you say, this, I can sort of understand.

Each monster has 2 reels. One with more attack slots, another with more defense/heal slots. You can have N number of Attack Abilities or Defense Abilities. Obviously too high an N means potential frustration because you never know what you’re going to get. Too low an N is boring. Each monster has a certain amount of HP, ATK, and Heal. Lastly, they have a clan, and clans have certain weakness/specialty relationships.

I break down balancing according to slot composition (how powerful are the slots & what are my chances of getting them?), hp/atk/heal (how high are these values) and growth rates (not included in the scope of this piece, just mentioning it here for completeness.)

Returning to the previous tenet that choices must be CLEAR and CONCISE for the player, they have to assign some kind of role when they look at the monster, which encapsulates what that monster can do. Players then construct methods of play based on roles that work well together. For example, a Glass Cannon might benefit from having a Defensive Tank that has the Protect ability, because then the Defensive Tank will absorb damage aimed at the Glass Cannon. That is what we call ‘strategy’ — a very simple one, but a strategy nonetheless.

Quick note, this is what our battle screen looks like now:

Snap 2015-03-28 at 02.30.07

3on3 is now the norm.

Working with this in mind, this is how the ‘builds’ (the term used in my worksheet) are defined:


These are the Parent Builds, which control slot compositions. Attackers have 3 kinds of attacks available in their attack slots (slots 1-12, I’ve truncated it to spare your eyes). Supports have support slots EVEN in their attack slots that automatically replace depending on the situation). And Disruptors have a lot of slot types.


These are the build types. Notice that HP/ATK/HEAL are also normalized. Normalization means that duplicating values are placed in a separate table to be defined and referenced; that way, when a repeating value is changed, you only change ONE REFERENCE. What that means to say is that, by having only 1 column to reference, I can quickly change the ceiling, median and floor values. I hope that was clear.


Here are the current values for low, medium, and high.

If a battle is 3vs3, It takes 4-5 attacks to kill 1 monster; this translates to roughly 1-2 turns. With jackpot combinations, which is a mechanic that adds party damage for getting a three of a kind, the normal total duration of a 3vs3 battle  is around 4-5 turns. The complete battle cycle however allows for 6on6 — a much longer battle, which helps for strategy. Why is this so important?

Because turn length defines the pacing of the game.

You probably have some opinions on how the roles are defined: there may not be enough ‘definition’ between types, maybe, or they all look the same, or it is overwhelming.

It really is. But that is a problem for another day.

Moving on: with all that defined, you must be wondering, how do I automate the slot generator?

VBA Macro to the rescue!

Snap 2015-03-28 at 02.33.09

 I hope the programmers don’t see me programming. This is embarrassing.

Above is a tiny script that I am currently refining. Basically it accepts a range, and for each cell, gets the Build type, then references the ParentBuild from the Build sheet, then copies the slots and pastes them, then moves on to the next cell in the loop. There are some functions — getBuildSlots & copyPasteBuildSlots — that are not included in this shitty sample.

Also, you’re going to laugh, but this took me 2 days of breaking things to do. I haven’t coded in a very, very long time. For the record I was also coordinating my team! I was doing other stuff!

We’re almost done.

The slots that are copied can be seen in the first table up there (Parent Builds). They are not actually the slots of the game, but slot templates. See the table below if you’re not dead from all the lecturing:

Snap 2015-03-28 at 02.38.00

AOE means area of effect, in case you were wondering.

Anyway, hope you guys had fun with this post. I put a lot of effort into it!

A vlog with our changes is coming up next week. Apologies for the lateness of this one!