New Release + Patreon

A new release of ARPGManager was pushed out to early access players last night. The release notes follow.

How does one get early access, you ask? Well, I'm happy to announce that I've set up a Patreon to support development of this totally free game, which is being funded entirely out of my own pocketbook thus far. Check out some of the rewards and early goals, as well as a little video about my story :-)

=Release Notes=

  • A basic Windows client is now available. It only runs at 1600x1200 fixed, currently. All controls are identical to the Android client. You can use either or both, interchangeably.
  • Crafting is now performed by you, the invisible sim overlord, rather than by your habitat co-resident explorers. Crafting uses items from your stash, and the result is deposited there. Recipes are unlocked using your player level and all recipe difficulties have been updated accordingly. Unlocking new recipes provides player xp and is a significant boost to leveling in the early levels.
  • Portals now have a fixed encounter sequence, rather than %-based encounter RNG. This is a significant balance change based on your feedback. Explorers were dying too often to unlucky 4+ enemy encounter sequences and players had no real control over this outcome. Explorer death is part of the game, but explorer death is now less random and more controllable through keeping up with gear upgrades and making smart portal cube risk/reward decisions. You will need to discover for yourself what encounter profile each portal cube has.
  • As a result of this change, enemies and traps have been buffed significantly.
  • As a result of this change, reliquaries are much more common. Their rarity table has been adjusted to compensate.
  • The level cap has been increased from 10 to 15. Adventures are now clamped--e.g. using a +2 level portal cube on a level 14 explorer will restrict the level to 15.
  • Items scale through levels 11-13 depending on the type, allowing a range of gear options at the top levels.
  • Enemy tiers increase every 3 levels. Enemy difficulty still scales with each explorer level.
  • Some weapons now deal multiple damage types. This is displayed in the item info and calculated into the average damage. Critical hit bonuses only apply to the primary damage mode (almost always the MUCH larger number). Strength scaling for melee weapons applies to each mode.
  • The orientation quest has been modified and expanded.
  • Daily quest xp now scales with your player level.
  • Portal cubes no longer drop prior to level 3.
  • Portal cubes now have an xp multiplier. More difficult explorations now, in addition to the opportunity for higher level loot, also give more explorer xp.
  • Color indicators have been added to the adventure log for damage text and loot rarity.
  • The level up overlay is less intrusive now.
  • Several perks that influenced encounter RNG have been replaced with explorer buff perks.
  • The return time from explorations at level 1 is significantly faster, to speed up the intro portion of the game.
  • A cancel action menu option has been added to the context menu for an explorer acting on a command.
  • Messages now persist across scene transitions.
  • The following enemies now have their own sprites:
  • Malfunctioning Polished
  • Albino Ranid
  • Scourge Embryo
  • Drone (note: all drones currently perform a kinetic bolt projectile attack regardles of their damage type)
  • Larval Crantis
  • Fixed a bug where stashing an item at level 3+ would show the LIST option, but it wouldn't work until you closed and re-opened the stash.
  • Fixed a bug where intuition was not properly increasing base psychic resistance. Every 3 points (starting with the first point allocated) will now add .01 psychic resistance. Death to the Scourge!
  • An Angel explorer skin has been added with unique animations. This will be available as a patronage reward (see below). The MTX system is not in place yet, so players who have access to the skin will need to ask me to swap it on to their explorer of choice, which I will do quite happily (and repeat if you kill them off, you bad manager, you).

=Known Bugs=

  • Damage pop-up text displays inconsistently.
  • The lowest price check in the market does not work for portal cubes.
  • On Windows, mouse wheel scrolling currently scrolls one pixel at a time. I suggest using either the slider or the click n' drag method.

Scaling Stats in Role-Playing Games (RPGs)

Your character has 1,000 hit points. Your flaming sword does an average of 100 damage. Your enemy has 3,000 hit points, does an average damage of 125 damage with their claws and has a 25% negative resistance to fire damage.

Q: Are you boned?

About Scaling

Scaling and, by extension, balance are a key challenge for RPGs. If you're off in either direction, your game could be either too easy or frustratingly difficult-to-impossible. You want to hit a sweet spot: players consistently challenged, but consistently able to overcome those challenges (see optional post-rant, below, for more on this topic).

I've been wrestling with scaling lately as part of my sim/RPG hybrid game project which is currently in development. Based on recent Twitter feedback and suggestions that I blog about my strategy, I'm not alone in this. So, I'll outline how I tackled initial scaling design for my game in hopes that it might help you, budding game maker, find your way forward a bit faster than I did.

Step 1 - Pacing

At the core of my game, the player is responsible for hiring, equipping and ordering around vict... explorers. These explorers venture into increasingly dangerous portals to unknown and unpredictable locations and encounter traps, enemies and the occassional piece of sweet loot. The game expects your explorers to die periodically--small bumps in your linear progression through the game. Therefore, the pace of my game is dictated almost entirely by the exploration mechanic and mortality rate.

Each portal exploration in my game involves a number of encounters. A short exploration might have 5 encounters, while a long one has 10. An additional variable paces exploration by determining the length of time between these encounters.

Explorers wear "frames" which protect them from damage--basically, their health pool. Traps and monsters deal damage. The explorers have a limited inventory capacity and can carrry, among other things, items to recharge their frame capacity. If they sustain enough damage to deplete their frame and they have no way to recharge it, RIP. They have to survive all the encounters before they can portal back to the ship. There are no random supply stores on an alien star. Space is a harsh mistress.

Therefore, if I want to kill a reasonable % of explorers, I need to ensure that traps and enemies do enough cumulative damage for an average number of encounters to exhaust a full inventory of frame rechargers. This is a simplified view, of course, ignoring other mechanics. But this interaction forms the core of scaling in my game:

  • If the explorers do too much damage, they won't take enough hits to ever die.
  • If frames have too much capacity, monsters won't do enough damage to exhaust an explorer's power cell supply.
  • If explorer inventory is too large, power cells will make them pseudo-invulnerable.

That is an abbreviated list just to give you a taste of the knobs and levers. Most are variations on those, above.

Step 2 - Health Pool

The next question I had to answer was, at each level, how much of a health pool should an explorer have? I decided on the following baseline:

  • Level 1 = 100 (minimum)
  • Level 40 (max) = 9999 (capped)


Short answer: I like those numbers.

Long answer: The difference between those numbers is significant enough that a level 40 character looks and feels godlike compared to a level 1 character. Additionally, I want to create a David and Goliath situation where the monsters have much more hit points than the explorers. The monsters have a max of 999,999.

That looks unfair, but if you have good weapons, you'll punch above your weight and if you have a good frame with high resistances, you'll mitigate a % of the damage up front. The fights are just as fair, mathematically, as if max health pools were even. But I want them to feel epic. The explorer should feel like a human fighting an alien hegemony or a hypertrophic organism the size of a small star. But they should be able to pull it off thanks to their insane loot. Most of the time.

Step 3 - Math O_O'

WARNING: I'm about to mangle some sacred mathematical terms. Please forgive me. Hopefully the end justifies the medians. Means? Whatever.

Now that you have your health pool range, you need to pick a scaling model. How much "reference" health should an explorer in average gear have at any given level? If only it were as simple as 100 + 9999 / 40. Sadly, it's not.

I went with a linear scale. And because I'm bad at math and decent at Python, I tweaked a script until I got a scale I liked:

>>> curve(110, 1.12)

The "curve" function I wrote just starts at the first parameter for level 1 and then scales it by the second parameter each level for 40 levels. I simply tweaked the second paramemter until I got a curve that arrived near my desired cap of 9999 (a bit under, which is perfect because "average" level 40 gear should leave significant room for above average gear to shine). I rounded everything to the nearest 5, for aesthetics. So an "average" level 10 frame should have about 305 capacity. A better frame will have more than reference, whereas a crappy frame (or one with a gimmick, such as low capacity but regeneration) might have a lower capacity than reference for that level.

As you can see from reading the curve, this sticks with my goal of having the difference between each level feel progressively more meaningful, numerically. AKA, linear.

Is this the only model you can use? Definitely not. There are other formulas you can use that will achieve different results.

An exponential function might be appropriate for a Gurren Lagan-themed game where each level is increasingly, massively more powerful than the last. It comes with some downsides, though. First, you're going to be spending performance on stupidly large numbers. Second, the difference between gear by level becomes so severe, so quickly, that it's functionally impossible for a character to survive an encounter one level above their own. That fact alone would eat a ton of design space for breakfast.

You might want to create a game which is fast in the beginning, slow in the middle and then fast again towards the end. There are models for that. You could even go with a cosine wave or something. I would recommend avoiding being too creative here--there's generally a reason linear progression has been the defacto since I got hooked on 8-bit RPGs. Put the slow part at the end, when players are bought in enough to not require constant achievements to keep them motivated.

Step 3 - MOAR Math X_X

So, I know the average encounter length, I know the health pool for a given level, and I know my desired mortality rate (muahahaha), I know my power cell limits. The next thing I need to figure out is how hard an average monster or trap needs to hit the explorer to force them to use a power cell at a rate that runs the risk of killing them.

I'll spare you the deets on this one. I created a big, but simple spreadsheet that calculates hits-to-kill from the player's health pool at each level. I can adjust the reference damage-per-attack until I arrive near the desired number of whacks an explorer can take before having to recharge. It also factors in resistances, based on a reference of "how much average resistance should gear have at this level?" Then I turned it around and did the same thing for monster health and player damage.

Now I just have to make like a bajillion pieces of gear...

Will it Blend?

This is my first game. I cannot guarantee that this approach will work, although the fundamentals are sound. Of course, I'm not going to invest tons of money into promoting a game that might not work. How do I test it? Preferably before I subject vic... supporters to the beta?

This is where I turn to my friend Xzibit:

Xzibit Sims Meme

My plan is to code basic simulations. Pick an explorer level. Gear him/her up. Pit him/her against a random sequence of monsters at the same level. Clone 500 times. Repeat X adventures. How many died? How many power cells did the survivors have left? What happens if I make the adventure shorter or longer? What happens if I give them slightly better or worse gear?

I'm going to sim my sim. It's as sim-ple as that. Maybe I'll blog about how that goes!

Closed Beta Signup

At long last, the wait for the thing you didn't know you were waiting for is now over! This short video includes information about the closed beta, including signup instructions. If you're already here, you probably watched the video, so here's a quick reminder of what to do:

  1. Click the "Contact" link in the navbar up at the top of the page.
  2. Fill out the contact form.
  3. Note the device and either resolution/screen size or the model of the device you want to use for beta. REMINDER: Android only (though see the video for possible exceptions).
  4. Submit and wait for confirmation!

Here's the video that I just described to you. It's still worth a watch, though, as it has much more info:

Potentially Shippable Increments

If you've read my short bio on this site, you'll know that I come to the indie game industry from a global business background. At each of the last three tech companies I worked for, I was involved in a transition from a waterfall software development methodology to an incremental approach. If you've been involved in one of these projects, you know how "fun" they can be. There's usually a few people with a specific pain pushing the transformation, while everyone else involved has two goals:

  1. Pad their resume with a new certification.
  2. Ensure as little actual change as possible.

One thing I never got to really adopt, due to #2 above, was the concept of potentially-shippable increments. This means that every time you finish a development cycle, you should be checking in working code that does something meaningful/useful. This does not mean the roadmap is empty. It just means checking in something operational and valuable, however small. In my first game project with Crane Mountain Gaming, I really wanted to apply this discipline.

Now, I clearly don't produce a sellable game on a weekly basis right now or I would be selling it already and switch to blogging navel-gazing criticism about Silicon Valley or something. What I am trying to do instead is to add complete, working features each week which expand the amount of things you can do in the game and make it richer and more fun.

As an example, this week I'm working primarily on the quest module. The latest iteration of the game is fully playable. You can hire explorers, outfit them, send them on missions, buy and sell gear, level up, get stronger, etc. etc. However, there's no guidance as to what to do next coming from the game itself. There's no story progression, even if you can grind your way to epic gear and slay asteroid-sized tardigrades. Would you want to play this game? Maybe. Maybe not. But it's a playable game. With the quests module added, it should become somewhat more accessible and enjoyable.

What does this approach give me? Is it worth the effort? Consider this scenario: I get pancreatic cancer next week (please don't consider it too hard, just in case). I dissolve the business and spend the rest of my money backpacking around Europe and Southeast Asia. What do I have to show for my effort? I make the source code repository public and you can immediately download it and begin hacking your own game from a feature-complete, if not overly rich, baseline. Or, I spend a few weeks layering on the account management bits* and launch it as a free going away present.

Let's consider a scenario where I don't die shortly after doing this (you can consider this one slightly harder, if you must). Let's say I just run out of money due to incurring large but non-lethal medical bills and have to take up a salary again. In that case, I have a shiny resume in the form of a playable online game server and client that might land me a gig at a "real" game programming company. In fact, that has always been plan B anyway.

Thinking about a game you're familiar with in reverse is a good way to approach constructing a game out of potentially shippable increments. Pick a game you like, start removing features and ask yourself if you'd still like to play that game. Here are a few examples:

  • Super Mario Brothers 3 without Toad's card-alignment mini-game. Without Warp Whistles? What about without the Tanouki Suit and the zones designed for it? Would it still be fun without any water zones and the swimming mechanic?
  • Final Fantasy VII without the Golden Saucer, the Weapons (bosses, not swords, etc.). Would you still play it without summoning Materia? How many characters and their sub-plots could you remove before you wouldn't enjoy it at all?
  • League of Legends without pre-teens poorly typing ethnic slurs at you while they feed their... sorry. That's not really a feature.

the main whole in my premise has to do with account management--signing up users, creating and managing player accounts. This and a few other minor features are critical to a broadly playable game, versus a multiplayer game that only one person can play at a time. However, implementing them too early is a waste because they have zero value until commercial launch and would never be the features that made the game succeed or fail, in any case. As with all philosophies, if the high priced consultant tells you there are no exceptions to the rules, fire him/her/it.


Welcome to the Crane Mountain Gaming website! Our first game is in heavy development. Keep an eye on the games page. Once the name is trademarked and enough art is in place, there will be incremental teasers posted. In the meantime, here are few things you can check out on the site:

  • About - Meet the "team"
  • Services - Indie game developer? Check out available consulting services
  • Merch - Support CMG by purchasing and proudly wearing a CMG hoodie

Keep an eye on the blog or add us on Twitter or Facebook for announcements, spoilers or inside info on game progress.