How to be a leaner, faster hyper-casual developer

Ever spend 3 years on a game just to see it fail? Well, Vinicius Pachá, Lead Game Developer at Supersonic, has - and he learned that taking a lean approach to game development is the best way to move forward. Instead of wasting months - or years - on a game, lean development minimizes waste by focusing on the most important features for proving the concept could be profitable. It’s an iterative process that reduces risk by focusing solely on marketability - rather than building out your game only to fail later, lean development confirms very quickly if your game has legs.   

Hyper-casual development lends itself to the lean approach because these games are simple and you can easily and quickly test their marketability. Here, Vini discusses how to apply the lean approach to marketability testing and shares his tips for what to do and what not to do to become a leaner, faster hyper-casual developer.

How to find the sweet spot that maximizes efficiency

Speed matters in the hyper-casual market - the top charts are changing all the time and competition is high. So learning to pick up your pace as a developer ensures you can test your concept and launch it before a clone appears. Shortening the testing timeline also means saving valuable resources, like time and money. 

The impact of your development speed can be described using a product-value curve for a hyper-casual game. Every game has a curve during the marketability phase that initially exponentially increases in value without using many resources (e.g. salary and time). But as the value curve tapers, you need to expend a lot of effort (more resources) for achieving even just a little value. As a developer, you’re seeking the sweet spot where your resources and costs are still significantly less than the value you’re getting. Here are a few tips for hitting that sweet spot.

Focus on CPI

CPI proves the marketability of your game and how affordably it can scale - if your CPI isn’t low enough, then it’s important to scrap your game before you get past the sweet spot and start spending too many resources on your prototype. Run the CPI test more quickly by taking a video-first approach to determine if a feature is worth including in your MVP or not. If the feature is understandable and translates well in your video, then it’s worth including - if not, scrap it.

Focus on the core gameplay shown in your video - it needs to be satisfying and clear enough that users know how your game works within three seconds.

Focus on the core gameplay shown in your video, too - it needs to be satisfying and clear enough that users know how your game works within three seconds of your video. Making sure your video is well-executed, too, helps you stand out from clones and lower CPI. 

For example, when we were running the CPI test for Cheerleader Run, we created a wishlist of features we wanted to include in the game, like:

  • Collecting mechanic
  • Tower formation
  • Losing cheerleaders
  • Fever mode
  • Final multipliers to give players more reason to collect cheerleaders
  • Upgrades to give sense of progression

But all of these features weren’t necessary for the first test, so we removed the multipliers, upgrades, and fever mode. We ended up with a video that featured the collecting mechanic, tower formation, and losing cheerleaders like ragdolls all within the first three seconds. Paring down the game to its essentials for the first CPI test confirmed it was marketable. Then we built it out further, and it went on to reach the top 10 on Android in the US.

Create your own templates based on genre

Designing a simple template for a part or feature of your game can save you a lot of time during testing. For example, I used SDK templates for the transition that goes from the menu to the gameplay to the victory screens, as well as the level counter that ticks up as users progress through the game. Focus on one genre at a time when building templates, too. If you’re designing runner games presently, create templates for 3 or 4 runner games and use them to build each additional prototype faster. I re-use templates for every relevant project I work on so I’m never starting from scratch - it saves me valuable time on designing these features in my next prototypes. 

Think ahead

Whatever you’re creating now for your prototype could be used in the future. Think ahead as you’re designing your MVP - what templates or assets could you use again? My first prototype took two months to design and now I can deliver one in two weeks, which is in big part due to the learnings I’ve applied to each subsequent prototype.

Avoid these mistakes that slow you down

Building hyper-casual games means experiencing a lot of failed concepts before landing a hit. From my own three years of experience in hyper-casual development, I’ve learned a lot about what NOT to do. Most of these mistakes are about doing too much before you’ve confirmed your game passes the CPI test - it’s important to focus on CPI as the sole benchmark of success.

Fear of buying assets on AssetStore

Your game needs to stand out on gameplay alone - assets just need to be visually appealing, and there’s no shame in buying them. Many hyper-casual hits use assets from AssetStore, and doing so can save you a lot of time. For example, if you want to save time on designing vibration scripts, you can buy them on AssetStore. Buying your assets brings a lot of value to your game  while saving time - remember the product-value curve!

Making many levels for the first iteration of the game

During prototyping, you don’t know if your game will pass the CPI test or not. So don’t waste your time and resources on building out 20 levels - even if you wanted to, you can’t showcase all of these levels in videos because it’d be too expensive. Start by building out 3-5 levels and make them a loop that users play through endlessly. Then, if your game shows promising CPI, you can start building out more levels and focusing on boosting in-game metrics, like retention.

Solving problems you don’t have

If you have a good idea but it’s not coming across well on mobile, you should still test it. If it has a good CPI, you can address the technical issues later. For example, hyper-casual games with lots of stickmen on the screen can lead to low FPS (frames per second) that causes the game to slow down. If this game has a high CPI, then it’s not worth your time to fix the FPS issues, because you should scrap the concept entirely - wait until you confirm the game has a low CPI before addressing the low FPS. 

Fixing bugs

There are some bugs that are really easy to fix and reproduce - you can change just one line of code. But there are others that are more difficult, like random crashes, that aren’t worth fixing in your first prototype. You can still test your game’s CPI even if it has a few bugs, and wait to see if it’s worth the resources to fix them.

Adding sound

Adding sound to a game requires time that you can’t afford to waste during prototyping. You need to find the right sound then balance and implement it, which can introduce a whole host of bugs. At prototyping, your game is only featured in a video, so if you think it needs sound, just add some music or sound effects on top of the video and see how it performs.

Making the game more complex

It’s very easy to get too excited when developing a hyper-casual game and to start adding complex features, like meta games and customization. I once waited two months to test a game because I kept adding more features - it ended up failing the CPI test and all that work was for nothing. We have an acronym we use around here: KISS - keep it simple, stupid. An MVP with just a few levels and simple design is best - at this stage, you’re only confirming that the core gameplay and concept is marketable; the rest you can build out later.

I once waited two months to test a game because I kept adding more features - it ended up failing the CPI test. An MVP with just a few levels and simple design is best.

Fail fast, fail often

It’s easy to fail during hyper-casual development, but it’s important to fail until you get a hit. You can learn from each failure and build templates based on what did work to help streamline your next prototype. Following a lean approach to development and only doing what’s necessary for running a CPI test can help you work faster while saving valuable resources.

This article is based on Vinicius’s presentation at SuperSession 2021 - you can find the full video from his talk below:


Let's put these tips to good use

Publish your game with Supersonic