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!

Monster Roller @ ESGS Indie Arena


Hey rollers!

This weekend (October 24 – 25), we will be at the E-Sports and Gaming Summit (ESGS) at the SMX Convention Center, Philippines as one of the finalists at the Indie Arena Showcase.


We’ll be doing a demo of Monster Roller, as well as other Boomzap games such as Super Awesome RPG and Legends of Fire & Steel.

Hope we can count on your support! Please vote for us through this app:

We’re also giving away Monster Roller posters so please drop by if you’re around. See ya!

P. S. Sorry for the hiatus on weekly dev progress updates. We’re busy working on our beta build, which you can sign up for here.

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.



What is Monster Roller, Anyway?


I just realized the other day that while this blog has shown a lot of the features, I haven’t really talked about what the game is, or how it’s played (from the point of view of those playtest users).

Monster Roller is a battle strategy game, fought with real-time PVP. Players choose a mode for each active monster, then roll to see what move the monster performs. Strategies might be attacking (the reel will have a small number of critical hits, weak hits, normal hits and maybe a party attack), defending, healing, and so on.


It uses a slot machine mechanic to visualize randomness in how powerful an ability is, similar to how RPG players might use a dice (or die, most likely). In most games, the chance to get a critical hit is usually buried in a page of stats. Meanwhile, Monster Roller puts this information to the front because being aware of these probabilities factors into strategy. The flip side to showing stats like that means that there’s a bigger cognitive load when a player has to remember them all in his/her head, which is why Monster Roller uses a simplified system (everyone can attack, but different monsters can do only one other thing — some of them can defend, others can heal, and others can buff or debuff an enemy).

In addition, Monster Roller makes use of all the usual features expected in a monster battling game:

  • there are element strengths and weaknesses,
  • status effects,
  • the ability to switch out an active team with a substitute,
  • buffs/debuffs,

and so on. The game also features jackpots (there’s a big bonus if you get a three of a kind) — which is why you’d pay attention (hopefully) to your team, your deck composition.

For the past eight months, we’ve been focusing on balancing all the variables we’ve just mentioned above, making each mechanic shine just enough such that winning depends on strategy and meta game. (Yes, we did this along with the crazy idea of using a slot machine with a limited range of randomness.) Although Monster Roller looks like a JRPG, that’s just the appearance of it; it’s balanced closer to a card game. Each battle is roughly ten minutes where deciding all these tiny things like order and mode and targeting really matters.

What’s a battle like?

All battles start with a coin flip:


If the player goes first, the enemy shields itself. The player is also forbidden to switch out, since the common meta tactic would be to use tanks in front (and most of the tanks in Monster Roller are defensive tanks, not offensive ones). On the other hand, the enemy is allowed to switch out as soon as their first turn comes around.

Here are some of the possible things to do in battle:

Here’s a single (common) attack:


Most monsters will have 3 or 4 of these (or more even), which allows them to synergize with other monsters for a 3 of a kind jackpot combo.

Here are some stronger attacks, such as a critical hit and a party drain attack:


Critical hit!


Party drain attack! It’s not yet noticeable, but Snapplant (the green monster) gets 10HP!

Here’s what a 3-of-a-kind jackpot looks like:


And the lights go wild…

There are two ways to get a jackpot. You can get a jackpot either with 3-of-a-kind or by having the same jackpot. Here’s a smaller defensive jackpot:


Here’s what healing looks like:


A big group heal from Fernadon.

A single heal this time.

Lastly, we can set up ‘combo plays’ by pairing buff-givers (called Modifiers) with other monsters. Below, the Nattilus  (on the far left) adds a 2.5x attack buff to the monster next-in-line. Sadly the buff is wasted on a 7HP monster. Lack of attack optimization hurts like a bitch in Monster Roller, which is why ordering and targeting matter.


Wew, that’s quite a lot to digest! We’re hoping that the midcore crowd cottons onto the idea. As always, feedback is appreciated! Let us know what you think in the comments.

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.






Improved Art Icons


We recently had a playtest and are working on changes to improve the game. The bossman mentioned that the icons look “boring” so we’ve been working on that.


Here’s how the battle screen looked before:

mr 2015-07-02 16-42-07-35


Here’s what it looks like now:

ScreenHunter_239 Jul. 02 15.36


It’s a pretty big change. It’s lost its more ‘iconlike’ properties and now looks like a cross between icon and illustration.

Here’s how the icons evolved:



Some points of interest:

  • We’ve made the background bigger.
  • We’ve simplified the colors and the patterns. Note how the Poison is now green and black whereas it used to have purple. The Stun (blue swirly at the end) also changed following this principle.
  • The top four icons (Wingslap, Tailthrash, Bite, and Claw) changed from being abstract and two-color to having less lines, a simple gradient background, and fewer colors overall.

There’s a lone outlier here — we’re still thinking about the Single Target Heal, which has three wolf-like monsters with a heart on only one. We’re not sold (well, I’m not sold quite yet) on whether the wolf-like look is a good idea or not.  Also, there are some differences in rendering style, which we will be refining as development rolls on.

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!



Production Buffet

This week’s post delves a little into the technical challenges needed to make a game and the kind of problem solving that goes behind the scenes.

Monster Roller is made to be a game under fifty megabytes with no additional downloads. It’s also supposed to be made fast, but the game industry is secretly made of timelords. We’ll take a short look at both.

For build size, there are several variables that we try to control.

There’s our compression method, for one, and also how frequently we reuse assets. In a way it’s like balancing an equation. There are aspects we could polish in, or invest resources in, and the ‘mix’ of where to splurge on polish or cut corners is what makes the game a viable product given its requirements. I know that sounded really heavy. Just think of it as being in a banquet. Eventually you will get full. So you have to choose what food you’re gonna focus on with the right amount of variety.


Your writer is just hungry. That’s the real reason I talked about a buffet.

For today we’ll be going over our rigging template. And although the previous paragraph went over compression and build size, the actual subject of today is about managing time. Rigging is not an issue for compression — we compress vertex animation data very well. But what I’d like to point out this week is that any feature requires integration and testing. You have to code it right, script it right, and test it right. The more unique animations for unique rigs, the more code, script, and testing resources comes in — and these are all part of the ‘weight of assets’ — the issue isn’t just build size, but time.

So in Monster Roller, we sometimes share ‘rigs’ so that we save time in making a new rig. This makes it easier to SCRIPT and TEST for.

The end effect looks something like this:


You might be wondering how we know to have these kinds of templates.

The process goes something like this:

  1. Sketch out monsters.
  2. Arrange those similar in form.
  3. Construct a rough block shape.
  4. As you make the rough art into final, be aware of the correct pose and adjust your art to fit the rig.
  5. Save time and energy!

Here’s a segment of our rigging template list:





Overall, Monster Roller actually has a lot more templates than these. We’re just showing these for reference.

Till next time :)

New FX on Monster Roller

Check out some of these new FX we are adding to Monster Roller! Let us know what you think in the comments.

[Claw and Bite]

[Pillar of light]



Collect cute and cool monsters to dominate the battlefield!