How I Built a Hyper-Casual Mobile Game Faster with UnityTools

by

Building a hyper-casual mobile game can look simple from the outside. The gameplay may involve only a few mechanics, simple controls, and short sessions, but building a production-ready mobile game requires much more than implementing the core mechanic.

You also need to think about scene management, player data, UI, settings, advertisements, reusable scripts, animations, project organization, and deployment.

To speed up this process, I built and used my own Unity development toolkit, UnityTools, as a reusable foundation for hyper-casual and small mobile game projects.

View UnityTools on GitHub

The Problem With Starting Every Unity Game From Scratch

When starting a new Unity project, I found myself repeatedly doing the same setup work:

  • Creating project folders
  • Setting up scripts
  • Creating UI systems
  • Adding scene-management code
  • Setting up player data
  • Preparing advertisements
  • Adding common packages
  • Creating settings panels
  • Preparing reusable templates
  • Configuring Git
  • Creating project documentation

None of these tasks are particularly difficult, but they consume time.

For a hyper-casual game, this becomes even more important because the goal is usually to prototype, test, iterate, and publish quickly.

Instead of rebuilding the same foundation for every game, I started putting reusable systems into a single Unity toolkit.

What Is UnityTools?

UnityTools is a collection of Unity development utilities and project setup tools designed to reduce repetitive work when starting and developing Unity projects.

The repository currently contains areas such as:

UnityTools
│
├── Ads
├── Animation
├── IL
├── PlayerData
├── Scene
├── Template
│
├── ScriptDownloaderEditor.cs
├── SettingPanel.prefab
├── UIPackage.unitypackage
├── FSMCustomScript.unitypackage
├── UnityTemplate.unitypackage
└── UnityTemplateProject.unitypackage

The repository also includes a Unity Editor setup tool that can automate parts of the initial project configuration.

Why This Is Useful for Hyper-Casual Games

Hyper-casual games are often built around a simple loop:

Launch
   ↓
Main Menu
   ↓
Gameplay
   ↓
Win / Lose
   ↓
Reward / Advertisement
   ↓
Next Level

The actual gameplay mechanic may be completely different from one game to another.

But many supporting systems remain similar.

For example:

Game A
 ├── Game Manager
 ├── Ads
 ├── Player Data
 ├── Scene Management
 ├── UI
 └── Settings

Game B
 ├── Game Manager
 ├── Ads
 ├── Player Data
 ├── Scene Management
 ├── UI
 └── Settings

Instead of rebuilding those systems every time, a reusable foundation allows the developer to concentrate on the gameplay itself.

1. Faster Unity Project Setup

One of the main features of UnityTools is the project setup automation.

The included editor script can create commonly required folders such as:

  • Scripts
  • Materials
  • Music
  • Prefabs
  • Models
  • Textures
  • Editor

The repository describes this as a one-click approach to creating essential project directories.

This might seem like a small feature, but it becomes valuable when creating multiple prototypes.

Instead of manually creating:

Assets/
├── Scripts/
├── Prefabs/
├── Materials/
├── Textures/
├── Models/
├── Music/
└── Editor/

the setup tool can handle the repetitive part.

2. Reusable Templates

Another important part of the workflow is reusable code.

UnityTools includes template-related files and packages that can be used as a starting point for new projects.

The goal isn’t to create a giant framework that dictates how every game must be built.

Instead, the idea is:

Start with a useful foundation and customize it for the game.

This is particularly useful during hyper-casual prototyping.

3. Player Data

A game needs to remember things.

For example:

Coins
Best Score
Current Level
Sound Enabled
Music Enabled
Unlocked Items
Tutorial Completed

A reusable PlayerData system makes it easier to keep these values organized.

Rather than scattering data throughout different scripts:

PlayerPrefs.SetInt("Coins", coins);
PlayerPrefs.SetInt("Level", level);
PlayerPrefs.SetInt("BestScore", bestScore);

you can build a more structured data layer around the game’s requirements.

This becomes especially useful when moving from a prototype to a publishable mobile game.

4. Scene Management

A hyper-casual game typically moves through several scenes or game states.

For example:

Bootstrap
   ↓
Main Menu
   ↓
Game
   ↓
Result
   ↓
Game

A reusable scene-management system can reduce the amount of boilerplate code required for these transitions.

Instead of writing scene-loading logic repeatedly, the common functionality can be centralized and reused.

This also makes it easier to maintain consistent loading behavior across multiple games.

5. UI and Settings

A mobile game needs more than gameplay.

Even a small hyper-casual game normally needs UI for:

  • Main menu
  • Gameplay HUD
  • Pause
  • Settings
  • Results
  • Rewards
  • Loading
  • Tutorial

UnityTools includes a reusable SettingPanel.prefab along with UI-related packages.

This means the foundation for common interface functionality doesn’t have to be recreated from scratch for every project.

A typical flow can look like:

             Main Menu
                 │
       ┌─────────┴─────────┐
       ↓                   ↓
    Play Game            Settings
       │                   │
       ↓              ┌────┴────┐
   Gameplay           │         │
       │            Music     Sound
       ↓
   Result

The visual design can then be customized for each game.

6. Advertisement Integration

Monetization is an important part of mobile game development.

UnityTools also contains an Ads area and includes a Google Mobile Ads package in the repository.

For a hyper-casual game, advertisements may be placed around moments such as:

  • Between levels
  • After a game over
  • Rewarded bonuses
  • Extra lives
  • Double rewards

The important architectural idea is to keep advertising functionality separated from the actual gameplay logic.

For example:

Gameplay
   │
   ├── Player finishes level
   │
   ↓
Game Result
   │
   ├── Continue
   └── Reward
          │
          ↓
       Ads System

This makes it easier to change the monetization strategy without rewriting the gameplay system.

7. Animation Utilities

Small animations make a huge difference in hyper-casual games.

A button can:

Scale Up
   ↓
Scale Down
   ↓
Normal

A reward panel can:

Fade In
   ↓
Scale
   ↓
Bounce

A level-complete screen can:

Panel → Slide In
Text → Pop
Reward → Bounce
Coins → Count Up

Reusable animation functionality makes it easier to create these interactions consistently.

The repository has a dedicated Animation area for this type of reusable functionality.

8. Finite State Machine Support

Game logic frequently becomes easier to manage when it is separated into states.

For example:

Game
 │
 ├── Loading
 ├── Ready
 ├── Playing
 ├── Paused
 ├── Win
 └── GameOver

Instead of putting everything inside a giant Update() method, state-based architecture can make the code easier to understand.

UnityTools includes an FSM-related package/template as part of the repository.

This can be particularly useful when a simple prototype starts becoming a more complex game.

9. Automating Script Downloads

One of the more interesting utilities in the project is ScriptDownloaderEditor.cs.

The repository describes a workflow where scripts can be downloaded directly through a Unity Editor tool.

The intended workflow is:

Unity Editor
     ↓
Tools
     ↓
Setup
     ↓
Script Downloader
     ↓
Download Templates

This can be useful when maintaining a collection of reusable scripts independently from a specific game project.

10. Keeping Git Projects Clean

Unity projects generate a lot of files.

A good .gitignore configuration helps prevent unnecessary generated files from being committed.

UnityTools includes functionality for downloading a standard Unity .gitignore as part of the setup process.

A clean repository makes it easier to:

  • Work across multiple computers
  • Collaborate with developers
  • Review changes
  • Backup projects
  • Maintain different game versions

Building the Game on Top of the Foundation

The most important distinction is that UnityTools is not the game itself.

It provides reusable infrastructure.

The actual hyper-casual game still needs its own:

Game Mechanic
Level Design
Player Controller
Enemies
Obstacles
Scoring
Progression
Visuals
Audio
Tutorial
Balancing

The toolkit handles the repetitive foundation so more development time can go toward those game-specific elements.

Example Development Workflow

My preferred workflow can be thought of as:

              UNITYTOOLS
                  │
       ┌──────────┼──────────┐
       ↓          ↓          ↓
    Project      UI         Data
     Setup     Systems     Systems
       │          │          │
       └──────────┼──────────┘
                  ↓
           GAMEPLAY PROTOTYPE
                  ↓
            TEST & ITERATE
                  ↓
            MONETIZATION
                  ↓
           OPTIMIZATION
                  ↓
              RELEASE

Instead of spending the first part of every project rebuilding infrastructure, I can move toward a playable prototype much faster.

The Real Advantage: Faster Iteration

The biggest benefit isn’t simply saving a few minutes creating folders.

The real advantage is iteration speed.

Hyper-casual development often involves trying many ideas.

For example:

Idea 1 → Prototype → Test → Reject
                         ↓
Idea 2 → Prototype → Test → Improve
                         ↓
Idea 3 → Prototype → Test → Publish

If the foundation is already prepared, creating each prototype becomes less expensive.

That allows more time to be spent on the things that actually determine whether a game is fun:

  • Game feel
  • Controls
  • Difficulty
  • Feedback
  • Visual clarity
  • Retention
  • Monetization
  • Performance

Building Reusable Tools From Real Projects

One of the best ways to create a development toolkit is to build it while developing real games.

Instead of trying to predict every possible requirement, you encounter problems naturally.

For example:

“I have created this settings system three times.”

Turn it into a reusable component.

“I keep writing the same scene-loading code.”

Turn it into a utility.

“Every project needs the same folder structure.”

Automate it.

“I keep downloading the same scripts.”

Create a downloader.

Over time, a collection of small utilities becomes a development toolkit.

That’s essentially the philosophy behind UnityTools.

What I Would Improve Next

A development toolkit should evolve alongside the games that use it.

Some future improvements can include:

  • Better package management
  • More reusable UI components
  • Improved ad abstractions
  • More animation utilities
  • Level-management tools
  • Editor productivity tools
  • Better documentation
  • Project validation
  • Automated project initialization
  • PlantUML/code architecture generation

The repository already includes a PlantUML-related workflow and lists further setup automation among its planned improvements.

Conclusion

Building a hyper-casual game isn’t only about creating the core mechanic.

A production-ready game needs a foundation for UI, scenes, data, ads, animations, settings, project organization, and reusable code.

That’s where a toolkit like UnityTools becomes useful.

By creating reusable infrastructure once and using it across multiple projects, development can become faster and more consistent.

The goal isn’t to make every game identical.

The goal is to remove repetitive work so you can spend more time on what makes each game unique.

Build the foundation once. Experiment faster. Ship more games.

Explore the UnityTools repository on GitHub

Leave a Comment