Making Games at Crackerjack!
By Tom Abrahams |August 22, 2015
This post is about how we make games at Crackerjack and what processes we go through when designing games.
First off, these principles and beliefs are for a particular set of games: free-to-play and casual games for mobile devices. Our design principles have changed hugely from when we first started making games to where we are now.
I graduated with the idea that before making a game, everything had to be planned out and designed and documented like I was planning a mission to mars. Now, make sure that every decision we make is driven by our players and data.
If we were going to start designing a new game tomorrow, where would we start?
Before start making just any game, a little bit of research can go a long way. App Annie is a good place to see how saturated the market is or if there is a gap in the market for a potential game. It would be a shame if you built a game and executed it correctly, only to find that that there are a bunch of other titles just like yours, that play the same, have the same theme etc.
Once you have decided what type of game you are going to make, it’s time to draw up / design a whole bunch of fun basic gameplay mechanics: like a catapult launcher or, pong. Those that we thought were fun enough would be prototyped.
A big change that we have made at Crackerjack is getting feedback from actual players, not just testers. When we made Bar Nuts, all the gameplay and features were all built on assumptions.
We thought: “Yep, players will love playing this feature and we added another feature on top of that (makes stacking hand movements) and then this feature will feed into this and it will be awesome!”
However, the end product was this huge game that we had developed and put our hearts and souls into but NONE of the features had ever been tested and we ended up with ultimately a cool idea when talking about it to people, but a poorly executed game.
What we should have done was prototype every feature, get those features into players hands and get their feedback. If everyone hates it, that’s good! You won’t waste your time building a game that’s doomed for failure.
What you should do is keep on prototyping small game mechanics that have crap art and look bad. You want to get accurate data on the game mechanic without dressing it up to looks awesome. So, say we release 10 simple gameplay mechanics, we would then look at our data across key metrics to determine which ones people like and bin the rest.
I would like to mention that early testing could be done under a different company name to avoid brand damage, because the reality is that the quality is going to be garbage.
After finding a mechanic that people are enjoying playing, it’s to think about how you can dress the idea up. If it is a fighting game, the prototype might have started off with stick figures and now it’s time to decide if it’s going to be robots fighting or maybe it’s monsters or ninjas.
Google Surveys is a cheap and efficient way to get data that gives you a rough idea for what people like. You could also use facebook to run several mock advertisements that bring would-be players to a facebook page to determine which theme has the highest CTR and like conversion.
Again, always making data driven decisions.
Pick themes that you will be able to extrapolate on and give continuity with features inside the game. For example, if we continue with our fighting game, part of the mechanic might be breaking off character’s limbs to win the fight.
You also want a broad target audience so using robots over actual people would make sense for a few reasons: If a robot loses an arm or a leg in a fight it kind of makes sense, plus there also is no blood and guts, so it’s unlikely to have a restricted age rating. This means your game will reach more people.
Minimal Viable Product!
Initially, what you are looking to make is the absolute bare bones of your game. You have the core mechanic, the theme and now you want to get it into players hands ASAP.
When we were testing the barebones of Mutt Runners, we first created “Mutt Runners: Origins” (which could hardly have been called a game) and later, we released “Mutt Runners” after more depth was added. Note: we only starting building the entire game once we had feedback and data from real players so we could prove that we could build a game around its core.
Pivot or Persevere!
So, we have our fun mechanic and we have picked a theme and art style, so what next?
We need to add some depth to the game so it’s not just a single mechanic. What can they do in the game outside of fighting? Can they train and become stronger? Do they need to rest after each fight?
There are a few things that you should keep in mind when designing the next feature, firstly: the core loop. The core loop needs to motivate the player to come back to the game after the player has finished each session. It also divides up the player’s game sessions to create anticipation and avoid fatigue. So as an example, the core loop might be:
Fight → Train → Wait for energy → Fight again. The gameplay is in the fighting, the player has some progression when training but they need to wait to fight again. So, in theory players are excited to come back and fight because they are all buff from their training and they are going to kick some arse. This is a very basic example and there are tons of different core loops.
Once you have designed a loop, it’s time to test your new feature and see if people like it!
So again test to see if people are liking the feature: is it working? Are people returning to your game and playing it as you intended? If it’s not working, then “pivot” and try something different – work out a different loop and then again test to see if players are liking that more.
It’s good practice to get every feature tested by real players, then you know 100% it’s going to work and it’s not just some assumption where you and the team think it’s a really cool idea.
This cycle of designing incrementally and getting feedback is, in my opinion, THE single most important aspect of game development. So, for every feature you make – test it. When it’s working move onto the next feature and then the next until you have built a game with tested features, a fun mechanic and an art style that fits!
There are a few core rules that we believe are very important when making free-to-play games. One of them is avoiding pay-to-win. Although this might work in the short term, it’s not sustainable. Once players figure out that being the best is nothing but the person who pays the most, it will alienate players and they will just stop playing your game.
Another challenge is designing an end game or endless play without it being completely reliant on new content. So, designing in a way that people who reach the end of the game still have a compelling reason for playing. If you find a way to do endgame well, people won’t have an excuse to stop playing your game!
I would also like to touch on target audience. When we created Bar Nuts it had a very niche theme (building your own bar and serving customers) and it was difficult for us to find players in the right demographic to play and enjoy the game. With Mutt runners, we went very broad: dogs as the main theme and we decided on a very “Disney” art style so we can appeal to a large audience.
If you have made it this far thanks for reading the design blog! I hope that gives some insight into game design and how we do things at Crackerjack!