The interesting thing about being a hypercasual game developer is that you always have a small project. A small project means a small commitment. You start to think in a small time frame. After a project is done you jump on to the next. It's a good mindset to not get too attached to a prototype. But for programmers, it might not be the best one.

As a programmer myself I always think that when developing a hypercasual prototype I'm not really developing one prototype. Rather I am developing a large-scale project with many small parts. I even don't create a new project file when starting a prototype. I copy the previous one and go from there. I delete what I don't need and keep stuff that I might need at a later point. And no, it doesn't get too messy.

I want to share today the concept of the framework that I always use in my games that makes the workflow much faster. Let's call the framework HC-Core

Except for arcade idles, almost all hypercasual games are level-based. And in each level, there are a few checkpoints that are interesting.

1. Level loaded

2. User command to Level Start

3. Level Fail/ Success

4. User command to Load Next Level or Restart Current Level

Now, if we make an event system that fires during these checkpoints and listens to these where needed, we can automate a lot of stuff. Let's imagine we have set up a centralized event system where at the above checkpoints the events get fired. As it's a centralized event system, we can listen to these events from any script whatsoever.

Now is the best time to automate UI. We create the following UI panels

1. Loading screen

2. The screen that waits for user input to start the game

3. Level win/fail screen with buttons to restart/ load the next level

We hook the behaviors of these panels to the events above. Done!

Now every time we start a new project, we can use the same UI. All we need to do is to make sure that we fire the Level Fail/Success events at the right time, depending on our game.

We can go on to create managers that hook onto the events and change behaviors accordingly and we will not touch those managers ever again. Some examples:

1. Analytics Manager:
Hook and fire the analytics events following the events above

2. LevelLoadManager:
Hook onto the events and load the next scene as required. Keep track of the level number

3. StorageManager:
Keep track of the game score. On Level win event, covert the game score to the available currency of the game

.....

and so on.

Following this general idea, a lot of things can be automated and it can automatically force clean code at least for the managers as that will be reused later. Separate frameworks can also be made for arcade idle using the general idea.