How to Make a Casual Mobile Game: Uprising - Project Structure

SplashScene - this scene obviously contains some splash screens and performs initial game initialization tasks, such as profile loading/creation/network updates and synchronization. It also contains all persistent objects (i.e. DoNotDestroyOnLoad instances). Once initialization is complete and players are bugged enough with splash screens, the menu scene is loaded.

MenuScene - as the title suggests, this scene contains all screens, that are related to the menu workflow. Its main content is a canvas with about 40 panels for different screens (though menu screens themselves are pretty unique, some panels are reused (those are counted as one). In addition to canvases, this scene contains a reduced copy of game scene 3D elements - this is a design decision - different objects are added to game location as players progress. These objects also appear in the menu scene as well.

LevelPlayScene - this is the actual scene in the game that does all that gameplay magic. Aside from obvious gameplay-related objects, it contains canvas with all UI, necessary for a game scene (HUD, pause screen, trimmed version of a shop, etc) 

The primary data file, which contains all the necessary parameters for enemies, weapons, in-app-purchases, etc. We call it God Data class.

Dialogues data file - a file, where all speech lines are stored.

Hints data file - a file that stores game hints, shown during the loading process. 

Managers - are basically singleton objects, which we assign to separate game objects on the scene.

Controllers - are classes, that can’t be singletons (i.e. bullet, enemy controllers). Those only exist as components of other objects (i.e. EnemyController that is attached to an Enemy game object).

ProfileManager - well, this one is simple, this is a persistent class that handles all transaction work, related to PlayerProfile (this is necessary, so all parts of the game don’t work directly with the profile, because it might change a lot over the product lifetime.

MainMenuManager - this class is responsible for displaying the Main Menu Panel. Actually, all menu screens are controlled by singleton objects (since they exist only in a single quantity, which falls right under a concept, mentioned above). Again, some might argue, that singleton objects for the menu are bad, but I see no reason creating new objects each time you open a certain screen or write additional code to maintain references to already created objects.

Universe Manager - this is a gameplay class and it can be called a Supervisor (or Overmind, if you like). It tracks the world state - what is the current stage, which objects are available, what player has earned, etc. This class starts and correctly finished the game by sending the “GameOver” event to all other entities that should receive it. This is arguably the largest class in the project, totaling 700 lines of code. Why arguably? Well, because analytic and statistic events are captured here, which just do 150 lines alone, so, if you remove them, it’ll compete with SpawnManager. 

LevelPlay Manager. Normally, game levels have multiple conditions and parameters, used to switch these conditions:

Spawn Manager. This is the second-largest source code file in the project and one of the most important because it does make the game fun. This file contains all logic used to spawn enemies on the field, so their power, type, speed and quantity are defined here. This file is 600 lines of pure logic, which maintains enemy waves.

Sound Manager - well, this class obviously controls sound playback in the game. It is engineered so that it keeps references to all existing sound controllers (in order to maintain sound sanity, the sounds are divided into objects they belong to.), which are derived from base SoundController Class. It looks like this in Inspector:

EnemyController - this class controls the behavior of every enemy on the field, This includes not only logic but also visuals (i.e. movement animations, pfx). Some might argue that visuals and logic should be separated and I generally agree with that. If it was 300-400 lines of code more, I’d requested a refactor, but the class is 300 lines of code long, so it wasn’t a big deal (again, best judgment gents)

RocketAmmoController - this is the only bullet controller we have in the game, because rockets are flying slowly and should hit on impact. Gun and rifle shots are instant in the game, because there’s really no point of calculating bullets that hit enemies quite quickly. This controller manages rocket bullet flight and plays explosion effects once a rocket has hit the ground or enemy.