“Pompeii MMXXIII” by Bastille with Hans Zimmer from Bad Blood X (10th Anniversary Edition) 🎵
The first thing you design will almost always be too hard.
Take this screenshot for example – this was World 2 of PrinceNapped, an unblock game to rescue a handsome prince. PrinceNapped had 75 levels at launch on both Facebook Web and on mobile all World 1. We never released World 2 (and we should have launched with 300 due to our D7). Why? World 2 was way too freaking hard…and players ate the good content up, all 75 levels, in 7 days.
Here is an almost 10 year old screenshot of a 360p video of me losing at my own level because I forgot how to solve the puzzle (at that point we had built ~150 of them). Each of those cute blue circles with yellow dots was called a “bon-bomb.” Players could only move the piece 3 times before it exploded and they lost a level. Those moves also counted against total moves for the level, in this case only 15 and I had moved twice. Unblock games are already hard before you start doing innovative mechanics with the individual blocks.
If you asked my advisory board, they would have told you that, actually, the hardest levels were 14, 22, and 40. I still remember that…but because game designers are classically evil, of course those levels started as 4, 10, and 15 respectively. We had already learned in World 1, and frankly in many games before that, that you have to incrementally increase difficulty and define what ‘incremental is’ in a puzzle.
However, it was World 2 that made me question how scalable piece mechanics are with unblock core gameplay loops. There is such a thing as maniacal gameplay, and we had hit it.
There were other games too that were just a bit too hard out the gate. For example, 21 potions, which launched while I was at AWS but was one of my last games under Ker-Chunk with Drowning Monkeys (Hi, Chud!), was about the right amount of hard. It started off as “Merge Blackjack” – but what helped us avoid a lot of difficulty was paper prototyping that game. We made so many prototypes – you can see in the screenshots below how it evolved from card prototype, to wireframes, to first art pass (final art was also different that the third image – we hired the amazing IGUANAMOUTH ART & DESIGN to do backgrounds, famous for their dragon hoarding art).
In the game players merged “cards” to make 21 on a 3×4 space grid. It sounds simple but it’s not – there were so many rules to figure out. What happens when players hit 21 on a square? What core mechanic draws another card? Does 21 block the space? Can you bust? How do you make it interesting beginning, middle, and end? How do we handle Aces? These were problems that didn’t care about the narrative or the art. These were problems that could be figured out with a card deck.
Fast, iterative loops is what made us get from prototype to done in 6-8 months in a remote team. More importantly ‘Keep it stupid simple’ was something by then I had started to really understand with regards to building anything.
The same can be said for Nimblitz which was a hypercasual matching game we developed under Ker-Chunk Games. These screenshots sum up the entire game with many core loops lasting less than 3 minutes.
Merge two shapes in < 15 seconds. As you do the board expands. That simple. You would think that players could get to a point where they didn’t lose except that most people can’t maintain focus that long. Our brains struggle to keep up and start seeing things that aren’t there (there’s a metaphor coming I promise).
The game itself took advantage of this – by the time players reached the 4th panel expansion the game no longer actually needed to expand (another metaphor). We knew people wouldn’t be able to keep up a routine of 3 matches, 15 seconds and there was no way to pause. The game was developed from fast feedback loops and ironically was also itself one.
How Game Design Applies to Management: Don’t Make It So Hard Your Players Quit Before They Reach the End of the Loop
I think about these issues today, though I am no where near the client or game design anymore. Often well-meaning people institute processes for engineers with positive intent, but instead, actually, make it too hard for them to do their jobs.
They don’t “keep it simple,” they don’t define incremental goals that are achievable and fair, and they don’t really work at fast iteration and fast feedback loops. They care about “keeping it safe” and let that consume their culture to the core losing the business entirely in the process – safety over learning. Some leaders don’t give teams autonomy and instead turn inclusivity into a weapon by forcing themselves onto projects that already have 10-15-20 people on them even for really simple changes or maintenance activities.
Some leaders may say they want efficiency, but actions will always be louder than words. And when the actions are “Add 4 more documents to write” or “add more approvers to this document” to prevent code changes ready to go out the door, check the metaphorical D30 and hope it has a percent.
Don’t model a junior game designer who made the game too hard.
Start listening. Start deleting the creep of process
everywhere you see it instead of encouraging it to continue.
Start actioning by letting things happen instead
of scared of wishing they never happened[11].
So people can truly learn.
Ask for less. Want less.
Lead by wanting less.
Want to truly learn through our vibrant differences and choices as actioned
instead of thousands of words wishing we had done anything yesterday when it’s too late.
Instead of wanting people to do things always in a straight line. Be okay with your people coloring outside them until they learn, until we learn, where we want the new lines to be.
You’d be surprised how much more influence we all have,
how much more accurate we will eventually be,
how much better our businesses could be,
if the people who can’t let go of their “levels”… finally do so to see anything different and new – because they loved their players (people) a whole lot more than the game (process) they had designed.
The actual impact when we prevent teams from truly learning in real time, and make it hard to make sure their changes get out the door, is that those who are most driven by learning look for their next game along with their customers. Or as Charity Majors says:
“I’ve never seen the happiness of your engineering team and the happiness of your users significantly diverge. I’ve never seen a team of absolutely miserable engineers creating a product that delights their users. And I’ve never seen a company with absolutely miserable users, where their engineers enjoyed their work.” — Charity Majors, Honeycomb
Charity Majors, Honeycomb “Recipe for High-Performing Teams” from The New Stack
Header Image by the blowup from Unsplash.
–
[11] This is the eleventh clue to the puzzle.
