Unity on Nullshow's Tech Blog

【Unity】Learning Commercial-Grade Coding from a Beginner Mini Game

Sat, 31 Jan 2026 08:43:30 +0800

Course Reference and Asset Source：Youtube-Code Monkey

Project Overview

“Lua Lander” is a 2D physics-based mini game inspired by the classic arcade game Lunar Lander. The core gameplay revolves around carefully piloting a small spacecraft to land safely on an alien surface.

Key mechanics of the original Lunar Lander include:

Using thrust and rotation to control the ship’s direction and velocity
Avoiding crashes caused by excessive speed or steep landing angles
Gently touching down on designated landing pads to earn higher scores
Managing limited resources: speed, angle, and fuel

“Lua Lander” is a faithful recreation and expansion by Code Monkey, a well-known game development creator on YouTube. While preserving the original mechanics, the project introduces several enhanced gameplay features:

More nuanced landing validation based on both velocity and angle
Multiple landing platforms with score multipliers
Fuel consumption system that adds flight cost management
Coin collection for bonus points
Thruster visual effects powered by a particle system and event-driven logic

Beyond gameplay, the project also includes system-level improvements:

A complete UI system
A game state machine (Start → Playing → Game Over)
Multi-level design using prefabs rather than separate scenes
Level preview with Cinemachine and a custom 2D zoom solution
Multi-input support (keyboard, gamepad, and touchscreen)
Dedicated screens for main menu, pause menu, and game over
Integrated sound effects and background music system

Learning Goals

Code Monkey tends to build games with complex systems, large-scale projects, and high maintainability requirements. Consequently, his tutorials—regardless of difficulty level—consistently adopt professional-grade structures that demonstrate how to integrate clean code principles and industry best practices into real-world Unity projects.

From this project, I aim not only to understand his problem-solving approaches and techniques for writing clean, readable code, but also to learn how to properly architect a game project and cultivate genuine game engineer thinking—laying a solid foundation for building my own complex projects in the future.

Therefore, I’ll closely follow along with his development process, carefully documenting his methods and design decisions so I can apply them to my own work later.

Development Breakdown

The game was developed roughly in the following sequence:

Post-processing effects (can be added at any stage)
Lander implementation
- Physics-based movement
- Visual effects for thrusters
Terrain creation
- Using Sprite Shape
Camera follow system
- Implemented with Cinemachine
Background setup
Landing logic
- Landing validation (based on speed and angle)
- Landing detection on platforms
Landing pad prefabs
- Prefab Variants (platforms with different sizes and score multipliers)
- Dynamic visual indicator for score multiplier
Fuel system
- Fuel capacity management
- Lander collecting fuel pickups
- Coin collection (implemented similarly to fuel)
GameManager
UI system
- Stats panel (fuel, score, etc.)
- Thrust direction indicator
- Fuel progress bar
- Game Over UI
  - Final score and stats summary
  - Restart button
Game state management
- Start
- Restart
- Game Over
Explosion VFX
New levels
- Built using prefabs (not separate scenes)
Minimap / overview map
Input System
- Keyboard/button input
- Touch input
- Joystick/gamepad support
Main Menu Scene
Pause UI
- Triggered by UI button or Esc key
Game Over Scene
- Displays total score
- Button to return to main menu
SoundManager & MusicManager
- Persistent background music across level transitions
- Volume control buttons
Polish (final touches, tuning, and refinement)

Key Insights and Critical Steps

PostProcessing

Visual enhancements like Bloom and Vignette were applied using Unity’s Volume → Global Volume → Add Override system. This affects both the in-game view and the Scene/Game window background. While only two effects were used here, Unity’s post-processing stack offers many more parameters—exposure, color grading, depth of field, etc.—that can be explored later as needed for mood, polish, or visual clarity.

Separation of Visuals and Logic

A powerful architectural pattern used in this project:

Create an empty root GameObject to hold all logic scripts (movement, physics, state, input handling, etc.).
Attach the Sprite Renderer (or any visual element) as a child object, solely responsible for rendering.
Additional visual elements—like particle effects, trails, or decals—are also added as separate child objects.

This approach, though simple, delivers significant benefits:

Decoupled logic and presentation Logic scripts no longer depend on visual components (e.g., SpriteRenderer, Animator). They operate purely on data and state, making code cleaner, more testable, and easier to debug.
Effortless visual iteration Swapping sprites for animations, 2D art for 3D models, or changing visual styles becomes trivial—just replace or modify child objects. No need to touch core logic.
Independent visual transformations The visual child can rotate, scale, shake, or animate without affecting the parent’s stable transform—critical for effects like screen shake, hit reactions, or spinning thrusters while maintaining consistent physics behavior.
Precise control over collision and logic origin The root object’s transform serves as the true “center” for physics, AI, or gameplay logic, unaffected by artistic offsets in sprite pivots or mesh origins.
Prefab flexibility and reuse The same logic prefab can be paired with different visual variants (e.g., themed skins, difficulty-based appearances) simply by swapping child prefabs—ideal for scalable, maintainable projects.

Code Clarity Matters

Even when optional, explicitly declare access modifiers (e.g., private, public, protected). While C# defaults class members to private and interface methods to public, writing them out improves readability—especially in team environments or when reviewing code months later. Clear intent = fewer bugs and faster onboarding.

Input Handling in Unity

As of Unity 6, both input systems remain available:

The legacy Input Manager (Input.GetKey, etc.)
The newer, more robust Input System package (with support for keyboard, gamepad, touch, and custom devices)

This project uses the new Input System, which enables:

Unified handling of multiple input devices (keyboard, controller, touchscreen)
Clean separation of input actions from gameplay logic
Runtime rebinding and better platform portability

For future projects targeting multiple platforms (especially mobile + desktop + console), adopting the new Input System is strongly recommended—it aligns with modern Unity best practices and scales far better than the legacy approach.

private void Update()
{
    // Previous version
    if(Input.GetKey(KeyCode.UpArrow))
    {
        Debug.Log("Up");
    }
    // Unity6
    if(Keyboard.current.UpArrowKey.isPressed)
    {
         Debug.Log("Up");
    }
}

Input Placement

Generally, input should be placed in Update(), because Update checks every frame for input. However, in this project, input can be directly placed in FixedUpdate() because we’re using isPressed—meaning that as long as a key is held down (isPressed / GetKey), it will still be detected even when checked at the fixed timestep of FixedUpdate.

However, if you’re using APIs that detect the exact moment a key is pressed or released (GetKeyDown / GetKeyUp), it’s recommended to place them in Update(), as they might be missed in FixedUpdate.

Additionally, any physics-related updates must always be placed in FixedUpdate().

If you must put movement logic in Update(), always multiply by Time.deltaTime to ensure consistent speed across computers with different framerates. Although you don’t need to multiply by Time.fixedDeltaTime in FixedUpdate, adding it doesn’t hurt.

Coordinate System Setup

Because we’ve adopted the visual/logic separation approach, we must set the gizmo coordinate system to Pivot and Local.

If set to Center, the pivot point becomes the center between the parent and child objects. Setting it to Pivot ensures each object uses its own origin as the center.

In this project, we want the lander to move upward relative to its own orientation when the up arrow key is pressed. Therefore, the coordinate reference must be set to Local. If set to Global, pressing the up arrow would always move the lander toward the screen’s top, regardless of its current rotation.

Landing Implementation Logic

Landing validation has two aspects:

The ship must be nearly upright upon landing.
The ship must land gently (at low speed).

For landing softness, we use Collision.relativeVelocity—a read-only property of the Collision class that represents the relative linear velocity between the two colliding objects.

For landing angle validation, we use the dot product between two vectors: the object’s local up vector (transform.up) and the world’s up vector (Vector2.up).

//============ Lander.cs ===========
private void OnCollisionEnter2D(Collision2D other)
{
    float softLandingVelocityMagnitude = 3f;	//  Set based on in-game performance metrics
    if (other.relativeVelocity.magnitude > softLandingVelocityMagnitude)
    {
        print("Landing too hard!");
        return;
    }

    float minDotVector = 0.92f;	//  Set based on in-game performance metrics
    float dotVector = Vector2.Dot(Vector2.up, transform.up);
    print(dotVector);
    if (dotVector < minDotVector)
    {
        print("landing angle too steep!");
        return;
    }
    print("Safe landing!");
}

How to determine appropriate threshold values? If you’re unsure what value to use for a certain condition, print it out in the console and observe the actual values during gameplay under different scenarios. In this project, the landing/crash thresholds were determined exactly this way.

Don’t Use Strings to Identify Game Objects

Strings should only be used for display text—never for finding objects or relying on Unity’s built-in Tags. It’s extremely error-prone: a typo, incorrect capitalization, or an accidental trailing space will cause the lookup to fail silently.

Use component-based queries instead.

// Identify whether it's a landing pad
if (other.gameObject.TryGetComponent<LandingPad>(out LandingPad landingPad))
{
    print("landing pad");
}

Thruster Visual Effect Implementation

Again, for the sake of decoupling, Lander.cs should contain no visual-related code. Therefore, events are used to trigger effects.

Additionally, the Particle System—like transform.position—is read-only, meaning you cannot modify it directly. Instead, you must access and adjust it indirectly through its EmissionModule:

1
2

ParticleSystem.EmissionModule emissionModule = leftThrusterParticalSystem.emission;
emissionModule.enabled = false;

`Time.deltaTime` and `Time.fixedDeltaTime`

Using `deltaTime` in `Update()`

Purpose: Compensate for variable frame rates
Update() is called at a frequency dependent on the current frame rate (e.g., 30fps, 60fps, 144fps)
deltaTime records the actual time elapsed since the last frame
Multiplying movement by deltaTime ensures consistent real-world speed across different frame rates

Using `Time.fixedDeltaTime` in `FixedUpdate()`

Purpose: Enable physics simulation with a fixed timestep
FixedUpdate() is called at fixed intervals (default: 0.02 seconds, i.e., 50 times per second), independent of frame rate
Time.fixedDeltaTime holds this fixed interval value (usually constant)
The physics engine requires a fixed timestep to ensure stable and predictable simulations

Key Differences

	`Update()` + `deltaTime`	`FixedUpdate()` + `fixedDeltaTime`
Time Interval	Variable (frame-rate dependent)	Fixed (default 0.02 seconds)
Purpose	Compensate for frame-rate differences	Ensure stable physics simulation
Use Case	Rendering, input, non-physics logic	Physics calculations, Rigidbody operations

`EventHandler`

Because this project is relatively small, and GameManager centrally manages all game data while Lander is the core gameplay object, directly referencing GameManager as a singleton from Lander.cs would be acceptable (tight coupling between Lander and GameManager).

However, an alternative—and more decoupled—approach is to use event listening: GameManager reacts to events raised by Lander.cs via EventHandler. This project adopts the latter strategy.

//=============== Lander.cs ===============
private void OnTriggerEnter2D(Collider2D other)
{
    // ...

    if (other.gameObject.TryGetComponent(out CoinPickup coinPickup))
    {
        OnCoinPickup?.Invoke(this, EventArgs.Empty);
        coinPickup.DestroySelf();
    }
}

//============== GameManager.cs =============
public class GameManager : MonoBehaviour
{
    private int score;

    [SerializeField] private Lander lander; 

    private void Start()
    {
        lander = lander.GetComponent<Lander>(); // Since we're getting a component from another unrelated GameObject, do it in Start()
        lander.OnCoinPickup += Lander_PickupCoin;
    }

    private void Lander_PickupCoin(object sender, EventArgs e)
    {
        AddScore(500);
    }

    private void AddScore(int addScoreAmount)
    {
        score += addScoreAmount;
        print(score);
    }
}

Even though the parameters object sender and EventArgs e aren’t used inside Lander_PickupCoin, they must remain in the method signature because:

Event signature matching: The lander.OnCoinPickup event expects a handler with this exact signature
C# event pattern: This follows the standard .NET EventHandler delegate convention

Removing these parameters would cause a compilation error.

Purpose of the parameters:

object sender: Identifies which object triggered the event (here, the lander instance)
EventArgs e: Carries event-specific data (e.g., coin value)

If you explicitly want to indicate these parameters are unused, you can use discard syntax:

private void Lander_PickupCoin(object _, EventArgs _)
{
    AddScore(500);
}

Example of using parameters in EventHandler

For instance, when implementing “award different scores based on landing quality”:

//========== Lander.cs ==========
public event EventHandler<OnLandedEventArgs> OnLanded;     // / Different landing outcomes yield different scores, so pass score via EventArgs
public class OnLandedEventArgs : EventArgs
{
    public int score;
}

// Landing on a platform
private void OnCollisionEnter2D(Collision2D other)
{
	// ...

    int score = Mathf.RoundToInt(landingSpeedScore + landingAngleScore) * landingPad.GetScoreMultiplier();
    print("score: " + score);
    OnLanded?.Invoke(this, new OnLandedEventArgs	// Pass score when invoking
    {
        score = score,
    });
}

//============ GameManager.cs ===========
public class GameManager : MonoBehaviour
{
    // ...

    // Actually use the score parameter
    private void Lander_OnLanded(object sender, Lander.OnLandedEventArgs e)
    {
        AddScore(e.score);
    }
}

Temporarily Adding Color to Text

`1`	`titleTxtMesh.text = "<color=#ff0000>CRUSH!</color>";`

Using a State Machine to Manage Game States

Define game states using an enum, then link them to input. This is implemented directly in the Lander/Player script and remains quite straightforward.

//============ Lander.cs ============
public enum State
{
    WaitingToStart,
    Normal,
    Gameover
}

 private void FixedUpdate()
 {
     switch(state)
     {
         default:
         case State.WaitingToStart:
             if (Keyboard.current.upArrowKey.isPressed ||
                Keyboard.current.rightArrowKey.isPressed ||
                Keyboard.current.leftArrowKey.isPressed)
             {
                 // Start game on any key press
                 landerRigidbody2D.gravityScale = GRAVITY_NORMAL;
                 SetState(State.Normal);
             }
             break;

         case State.Normal:
             if (fuelAmount <= 0)
                 return;

             if (Keyboard.current.upArrowKey.isPressed ||
                Keyboard.current.rightArrowKey.isPressed ||
                Keyboard.current.leftArrowKey.isPressed)
             {
                 ConsumeFuel();
             }

             if (Keyboard.current.upArrowKey.isPressed)
             {
                 landerRigidbody2D.AddForce(force * transform.up * Time.fixedDeltaTime);
                 // Broadcast event
                 OnUpForce?.Invoke(this, EventArgs.Empty);
             }

             if (Keyboard.current.leftArrowKey.isPressed)
             {
                 landerRigidbody2D.AddTorque(turnSpeed * Time.fixedDeltaTime);
                 OnLeftForce?.Invoke(this, EventArgs.Empty);
             }

             if (Keyboard.current.rightArrowKey.isPressed)
             {
                 landerRigidbody2D.AddTorque(-turnSpeed * Time.fixedDeltaTime);
                 OnRightForce?.Invoke(this, EventArgs.Empty);
             }
             break;
         case State.Gameover:
             break;
     }      
 }

Explosion Effect Implementation:

This is also handled via events. However, note that the subscription to OnLanded (which triggers the explosion) is registered in Start(), not in Awake() like the thruster effects—due to three reasons:

One-time event: It only fires once during the entire game
Potential dependencies: Explosion effects or game state systems may rely on other objects initialized in their own Awake()
No immediate need: Landing doesn’t occur instantly at game start

Summary: Benefits of registering the explosion event in Start():

Code organization: Separates initialization of frequent events (Awake) from one-off game logic (Start)
Avoids potential issues: Ensures more predictable subscription order if other scripts also listen to OnLanded in their Awake()

Button Click Handling

The project doesn’t use Unity’s “bind button in the Inspector” approach. Instead, button callbacks are registered directly in code:

[SerializeField] private Button nextBtn;

private void Awake()
{
    nextBtn.onClick.AddListener(() =>	// Lambda syntax is used here since there are no parameters or return values—this is the most concise way
    {
    	SceneManager.LoadScene(0);
    });
}

After adding multiple levels, a callback function determines whether clicking the button loads the next level or restarts the current one. An Action delegate is used to store the function reference—not for its event capabilities, but for its flexibility in assignment.

//=========== LandedUI.cs ============
public class LandedUI : MonoBehaviour
{
    // ...
    
    [SerializeField] private Button nextBtn;

    private Action nextBtnClickAction;

    private void Awake()
    {
        nextBtn.onClick.AddListener(() =>
        {
            nextBtnClickAction();
        });
    }

    private void Start()
    {
        Lander.Instance.OnLanded += Lander_OnLanded;

        Hide();
    }

    private void Lander_OnLanded(object sender, Lander.OnLandedEventArgs e)
    {
        if(e.landingType == Lander.LandingType.Success)
        {
            titleTxtMesh.text = "SUCCESSFUL LANDING!";
            nextBtnClickAction = GameManager.Instance.GoToNextLevel;	// Assign different callback based on landing outcome
        }
        else
        {
            titleTxtMesh.text = "<color=#ff0000>CRUSH!</color>";
            nextBtnClickAction = GameManager.Instance.RetryLevel;
        }

       // ...
    }
}

Handling Unchanging Level Number

The levelNumber was initially a regular instance variable. However, since GameManager gets destroyed when a scene reloads, the variable resets to its default value (e.g., 1), preventing progression to the next level.

The solution used in the tutorial is to declare levelNumber as static. This keeps it alive in memory across scene reloads. When the new GameManager instance is created in the reloaded scene, it reads the preserved static value and correctly loads the next level.

Showing a Full-Map Preview at Level Start

Since each level has a different map layout, this script must be attached to every level scene. It controls the CinemachineCamera to switch the follow target between the pre-game overview state and the in-game lander-following state.

Unity’s 2D Cinemachine setup (CinemachineVirtualCamera + Framing Transposer 2D) does not include built-in zoom functionality. Therefore, a custom script is required to implement zoom behavior.

In contrast, in 3D mode, CinemachineVirtualCamera provides built-in zoom via the Lens → Field of View (FOV) or Orthographic Size properties, which can be directly adjusted for zoom effects.

Create an empty GameObject named `CinemachineCamera2D` and attach the custom zoom script to it

//============== CinemachineCameraZoom2D.cs ===============
public class CinemachineCameraZoom2D : MonoBehaviour
{
    private const int NORMAL_ORTHOGRAPHIC_SIZE = 10;

    public static CinemachineCameraZoom2D Instance { get; private set; }

    [SerializeField] private CinemachineCamera cinemachineCamera;

    private float targetOrthographicSize = 10f;

    private void Awake()
    {
        Instance = this;
    }

    private void Update()
    {
        cinemachineCamera.Lens.OrthographicSize = targetOrthographicSize;
    }

    public void SetTargetOrthographicSize(float targetOrthographicSize)
    {
        this.targetOrthographicSize = targetOrthographicSize;
    }

    public void SetNormalOrthographicSize()
    {
        SetTargetOrthographicSize(NORMAL_ORTHOGRAPHIC_SIZE);
    }
}

Set the zoom-out value in GameLevel so each level can be configured flexibly

//============== GameLevel.cs ===============
public class GameLevel : MonoBehaviour
{
    [SerializeField] private float zoomedOutOrthographicSize;   // Put this value in GameLevel so each level can set it freely

    public float GetZoomOutOrthographicSize()
    {
        return zoomedOutOrthographicSize;
    }
    
    // ...
}

Configure it in GameManager

When the level is loaded and the player has not started yet, let Cinemachine zoom out to show the full view. When the player presses a key to start, reset the Cinemachine camera range back to normal.

//============== GameManager.cs ==============
public class GameManager : MonoBehaviour
{
 	// ...

    private void LoadCurrentLevel()
    {
        foreach (GameLevel level in gameLevelList)
        {
            if (level.GetLevelNumber() == levelNumber)
            {
                GameLevel spawnedLevel = Instantiate(level, Vector3.zero, Quaternion.identity);
                Lander.Instance.transform.position = spawnedLevel.GetLanderStartingPos();

                // Use Cinemachine to show the map 
                // Essentially set Cinemachine’s tracking target to the map center 
                // instead of following the lander right away
                cinemachineCamera.Target.TrackingTarget = spawnedLevel.GetCameraStartTargetTransform();
                // zoom out
                CinemachineCameraZoom2D.Instance.SetTargetOrthographicSize(spawnedLevel.GetZoomOutOrthographicSize());
            }
        }
    }

    private void Lander_OnStateChange(object sender, Lander.OnStateChangeEventArgs e)
    {
        // ...

        // After the game starts, Cinemachine follows the lander
        cinemachineCamera.Target.TrackingTarget = Lander.Instance.transform;
        // Cancel zoom out, restore normal camera settings
        CinemachineCameraZoom2D.Instance.SetNormalOrthographicSize();
    }
}

Smooth transition when switching camera

//============== CinemachineCameraZoom2D.cs ===============
private void Update()
{
    // Smooth camera transition using Lerp
    float zoomSpeed = 2f;

    cinemachineCamera.Lens.OrthographicSize = 
        Mathf.Lerp(cinemachineCamera.Lens.OrthographicSize, targetOrthographicSize, Time.deltaTime * zoomSpeed);
}

Input improvement (support multiple input systems)

Create your own InputActions => Edit Asset => Action Maps. In Action Maps, add inputs for Player, and bind keys for the three player actions (up / left / right).

Then check the box to create a C# class. This way you can control it directly through scripts. This is the method recommended by Code Monkey, instead of using strings. As a result, the InputActions we created generate their own C# script.

Create your own GameInput script

Create an empty GameObject and attach a new script to it. This script acts as a middle layer, so other scripts don’t directly depend on InputActions.cs (tight coupling). The benefits are:

Decoupling – Game logic does not directly depend on InputActions implementation
Single entry point – All input is managed in one place
Easy testing – Input can be easily mocked (Mock GameInput)
Flexible extension – Future features like input recording or replay only require changes in GameInput

Extension

Drawbacks of the old Input System

Unity’s old input system (Input.GetKey(), Input.GetAxis(), etc.) has these problems:

Hard-coded input checks – Keys are fixed in code (e.g., Input.GetKey(KeyCode.W))
Difficult to rebind – Players cannot customize key bindings
Poor multi-device support – Handling controllers, touch screens, etc. is complicated
Lack of flexibility – Input logic is scattered everywhere, hard to maintain

Advantages of the new Input System

InputActions provide:

Config-driven – Configure input via the visual editor, no code changes needed
Device-independent – One Action can support keyboard, controller, and touch at the same time
Easy rebinding – Change key bindings dynamically at runtime
Better performance – Event-driven instead of frame-by-frame polling

Good practice

Since input is also a kind of resource, you need to call Enable and Disable properly:

When calling Enable, internally it will:

Register listeners with Unity’s input system
Start receiving input events from hardware (keyboard, controller, etc.)
Consume system resources and memory

When calling Disable, internally it will:

Unregister all listeners
Stop processing input events
Release related resources

Touch input

GamePad binding and keyboard binding are the same. Touch input is slightly different.

Create an empty GameObject TouchUI under Canvas
Create three UIImage circles under TouchUI
Add On-Screen Button components to the three circles
Use the simulator to preview effects on different touch devices

JoyStick Input

Unlike button input, the Action type for joystick needs to be set to Value => Vector2.

Just like button input, you simply add it in the corresponding script.

Using SceneLoader to manage scenes

To avoid using “magic numbers” like SceneManager.LoadScene(0); when loading scenes, we use a script to control scene loading.

Since it will exist globally, we set it as a static class that does not inherit from MonoBehaviour. Note that in this case, all members inside the class must also be static.

In addition, the tutorial avoids using magic numbers or direct strings by setting scenes as an enum.

//============ MainMenuUI.cs ============
public class MainMenuUI : MonoBehaviour
{
    [SerializeField] private Button playBtn;
    [SerializeField] private Button quitBtn;

    private void Awake()
    {
        playBtn.onClick.AddListener(() =>
        {
            SceneLoader.LoadScene(SceneLoader.Scene.GameScene);
        });

        quitBtn.onClick.AddListener(() =>
        {
            Application.Quit();
        });
    }
}

//============== SceneLoader.cs ===============
public static class SceneLoader 
{
    public enum Scene
    {
        MainMenuScene,
        GameScene
    }

    public static void LoadScene(Scene scene)
    {
        SceneManager.LoadScene(scene.ToString());
    }
}

Keep background music from restarting when switching levels

You can handle this by making the music playback time static. (In this tutorial, any data that needs to stay consistent across levels is solved by setting it as static.)

public class MusicManager : MonoBehaviour
{
    private AudioSource musicAudioSource;
    private static float musicTime = 0f;

    private void Awake()
    {
        musicAudioSource = GetComponent<AudioSource>();
        musicAudioSource.time = musicTime;
    }
    private void Update()
    {
        musicTime = musicAudioSource.time;
    }
}

Extension

About event unregistration

In this project, events are used in many places to achieve decoupling. However, in most cases there is no unregistration. This is not best practice.

It is temporarily safe not to unregister in the following situations:

Same lifecycle: LanderVisual and Lander components are on the same GameObject

`1`	`lander = GetComponent<Lander>(); // same object`

Destroyed together: when the lander explodes, the whole GameObject is disabled

`1`	`gameObject.SetActive(false); // LanderVisual and Lander are disabled together`

Unity automatically cleans up these references when the object is destroyed

Best practice is to unregister events when the object is destroyed:

private void OnDestroy()
{
    if (lander != null)
    {
        lander.OnUpForce -= Lander_OnUpForce;
        lander.OnLeftForce -= Lander_OnLeftForce;
        lander.OnRightForce -= Lander_OnRightForce;
        lander.OnBeforeForce -= Lander_OnBeforeForce;
        lander.OnLanded -= Lander_OnLanded;
    }
}

Cases where event unregistration is required

The subscriber’s lifecycle is shorter than the publisher’s
The subscriber may be created/destroyed multiple times (without unregistration, it will cause duplicate subscriptions)
Cross-scene events

Making a habit of unregistering events is safer. It helps avoid:

Memory leaks

Duplicate triggers

Hard-to-track bugs

Always follow this rule: Unregister in the corresponding cleanup method where you registered.

Where to unregister

Unregistration usually happens in Destroy or Disable. Which one to choose? It depends on the timing of event unregistration.

Core principle: pairing

Event registration and unregistration should be paired in the corresponding lifecycle methods:

Registration	Unregistration	Usage scenario
Awake() / Start()	OnDestroy()	Register once during object lifecycle
OnEnable()	OnDisable()	Object may be enabled/disabled repeatedly

Separating visual and logic

In this project, Code Monkey attaches all visual scripts to the main GameObject, while the sprite is just a clean image. This approach is suitable for:

Small projects
Simple visuals
No skin system
No complex animations
No multi-layer visual components
Low coupling between logic and visuals

Another approach is to put visual scripts on child objects of the sprite. This is common in larger projects, suitable for:

Characters with multi-layer visuals
Skin systems
Animation state machines
UI bindings
Particles, effects, lighting
Multiplayer sync (visuals not involved in sync)

Advantages:

Complete decoupling
Visuals can be replaced
Logic can be reused
Prefabs are more modular
Better suited for large projects

Polish

Code Monkey repeatedly emphasizes the importance of polish, and I agree. However, my main purpose in taking this course is to see how professional indie developers use clean code and modular design to build loosely coupled, scalable games. So for now, I will skip the polish part.

I plan to take a dedicated course later to learn polish techniques.

Here I note the plugins Code Monkey used in the course, so I can reference them when needed:

Feel（Code Monkey有review视频）
All in 1 Sprite Shader （Code Monkey有review视频）
Text Animatior
Hot Reload
Code Monkey Toolkit

Review and Next Steps

Even though this is just an entry-level course, I still learned a lot. The main points include:

Separation of visual and logic

For a project of this size, no scripts are attached to the sprite; everything is placed in an empty GameObject
Single Responsibility Principle

Each class and function is relatively small, responsible for only one thing
Observer Pattern

Used extensively for decoupling, including UI, sound effects, etc
Advantages of using C# standard EventHandler

Besides proper naming, it allows adding parameters, which is sometimes very useful
Input System usage

Compared to the old input system, the new one requires almost no code changes when connecting different input devices, which is very convenient

Using prefabs to add levels

This is the first time I learned this method. Summary comparison between using Scene and Prefab for level design:

Item	Scene for levels	Prefab for levels
Best suited for	Large scenes, story levels, worlds	Multi-level, repeated structures, procedural, roguelike
Loading method	Switch scenes (LoadScene)	Instantiate Prefab in the same scene
Editing experience	Intuitive, what you see is what you get	Modular, composable
Performance	Scene switching has overhead	Prefab instantiation is faster
Reusability	Low (each Scene is independent)	High (Prefabs can be reused)
Dynamic generation	Not convenient	Very convenient
Team collaboration	Scenes prone to conflicts	Prefabs less likely to conflict
Number of levels	Few levels	Many levels

Next Steps:

The original course also includes some bonus game mechanics:

Cargo transport
Key switches
Wind zones
Dynamic meteors
Turret shooting

I plan to set these aside for now and try implementing them myself after more study and practice.

In addition, Code Monkey is the first professional game developer I’ve followed. I will study courses from two more professional developers, learn their coding styles and overall game architecture, and then try to form my own style.

【SOLID】SOLID Principles in Project Practice

Mon, 19 Jan 2026 09:54:30 +0800

Course Reference：Udemy-Niraj Vishwakarma

Asset Sources：

Unity Asset Store-HobiSoLoved（Background）
Unity Asset Store-Hippo （Tanks）
Unity Asset Store-Crehera（Drones）
Unity Asset Store-kΩsmaragd（UI）

Introduction of SOLID Principles

Spaghetti Code

This kind of code is basically a tangled mess where everything is tightly coupled. For example, in a script like PlayerController.cs, you might see the player’s Move(), Attack(), Jump()… all crammed together, along with extra functions like PlayAudio.

Code written this way is fragile and hard to extend. It’s like spaghetti — once everything is tangled up, pulling on one strand can easily cause multiple bugs to appear.

Solution:

Ditch the spaghetti‑style structure and switch to a modular design.

Spaghetti code can be fine when you’re quickly prototyping a demo or building a small game to test ideas. But if you expect the project to grow, with more game objects and features being added, setting up a solid architecture and modular design early on becomes crucial.

What Are the SOLID Principles?

In short, there are five main principles:

Single Responsibility Principle (SRP)
Open-Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)

Single Responsibility Principle (SRP)

Core Idea

One script, one function. SRP breaks down big classes into smaller ones, each with its own independent responsibility. These small classes can be reused and don’t interfere with each other. Think of them like Lego bricks — you can combine them to build all kinds of larger models.

Benefits

When every script has a clear responsibility, you can swap things out freely without worrying about breaking other parts of the game.

Open/Closed Principle (OCP)

Core Idea

Classes, modules, and functions should be open for extension but closed for modification.

Benefits

You can add new features by creating new classes, without messing with the independence of existing ones. This makes your code more modular and easier to maintain.

How to Apply

Create new classes for new features.
Define interfaces or abstract classes, then implement them in your feature classes.
Interact with features through abstract methods instead of calling them directly.
Make good use of polymorphism.

Liskov Substitution Principle (LSP)

Core Idea

A superclass (or parent class) should be replaceable by its subclasses without breaking functionality.

Benefits

This allows you to use subclasses in place of the parent class without directly referencing each one. It ensures flexibility and scalability when new variables or behaviors are introduced.

How to Apply

Create a base class and declare all the methods.
Build subclasses for objects with similar behaviors.
In other scripts, reference the parent class instead of the subclasses directly.

Interface Segregation Principle (ISP)

Core Idea

A class shouldn’t depend on methods it doesn’t use.

Summary

Write only what’s needed, and keep it relevant.

Dependency Inversion Principle (DIP)

Core Idea

High‑level modules shouldn’t be coupled to low‑level modules. Both should depend on abstractions.

Summary

Depend on abstract functions, not concrete implementations.

How to Apply

Use interfaces to define abstract functions.
Implement those interfaces in concrete classes.
Interact with concrete classes through the interfaces.

Practice Project

We’ll use a 2D Tank vs. Drone War game to show how the SOLID principles can be applied in Unity game development.

Core Gameplay:：

On the left side of the screen, there are two tanks:
- A light tank, controlled by pressing L
- A heavy tank, controlled by pressing H
The light tank can move left and right, rotate its cannon, and fire light shells.
The heavy tank cannot move, but it can rotate its cannon and fire heavy shells.
On the right side of the screen, drones move leftward. Hitting them increases the score.
Lose condition: If a drone collides with a tank, that tank is destroyed and becomes unresponsive to player input. When both of the tanks are unresponsive, the player loses.

Game / Feature Breakdown

Content

Background image
Tanks (light and heavy)
Bullets (light and heavy)
Drones
UI (score, start screen, gameplay screen, end screen)
Sound effects (firing, drone hit, tank hit)

Logic

When the game starts, pressing L activates the light tank (move, rotate, fire shells).
Pressing H activates the heavy tank (rotate, fire shells).
Drones fly from right to left — entering from the right side of the screen and exiting on the left.
If a tank is hit by a drone, it becomes inactive.
If both tanks are inactive, the game ends.

Module Organization

Development Steps

Scene Setup
Tank Development
- Movement and rotation
- Firing
- Switching between light and heavy tanks
- Health system
Drone Development
- Drone prefab
- Drone spawning
- Health system
Game Management
- Configure game events
- AudioManager
- UIManager
- GameManager

Feature Implementation and Principles Followed

1. Tank Movement

In the tank design, we follow ISP (Interface Segregation Principle) and DIP (Dependency Inversion Principle).

2. Tank Firing

When designing the firing system, the two types of projectile follow the Open/Closed Principle (OCP). Each time we add a new type of projectile, we should extend the system rather than modify TankFire.cs. Inside TankFire.cs, the firing logic should interact through an interface instead of directly calling the specific shell prefab.

It’s important to note that both types of projectiles interact with TankFire.cs through an interface. However, since the interface does not inherit from MonoBehaviour, it cannot be instantiated directly. To solve this, you need to implicitly cast it to a Component.

public class TankFire : MonoBehaviour
{
    [SerializeField] private IProjectile iProjectile;
    [SerializeField] private Component projectileComponent;
    [SerializeField] private Transform firePos;

    private void Start()
    {
        iProjectile = projectileComponent as IProjectile;
    }

    private void Update()
    {
        if (Input.GetKeyDown(KeyCode.Space))
        {
            if (iProjectile != null)
                iProjectile.Fire(firePos);
        }
    }

3. Tank Selector Implementation

This part is designed following the Liskov Substitution Principle (LSP).

For smaller projects, you don’t necessarily need separate LightEngine.cs and HeavyEngine.cs files — you can simply put everything inside the TankEngine class.

4. Tank Health Implementation

Following the Dependency Inversion Principle (DIP), we use an IDamageable interface to interact with concrete classes. These concrete classes could be drones or other colliding objects such as bullets, missiles, and so on.

5. Airplane Movement

This part reuses the ImoveUp.cs code in the same way as tank movement. It’s also implemented through an interface, leaving room for adding new types of drones in the future.

6. Automatic Destroy of Drones and Projectiles

Here I use a single script, DestroyByTime.cs, following the Single Responsibility Principle (SRP). Unlike the course approach of handling each case separately, this unified script keeps the design simpler and cleaner.

7. Collision Detection and Health System Integration (Tanks, Projectiles, Drones)

This is the final application of the Dependency Inversion Principle (DIP) mentioned earlier. Since both projectiles and drones are destroyed upon collision, they don’t directly implement the IDamageable interface. Instead, the tank’s health system implements the interface. This way, even if new projectile types are added in the future with different damage values, they can be easily integrated. For drones or other enemy types, if different damage behaviors are needed, they can also be flexibly designed by inheriting from the interface.

//========== IDamageable Interface ==========
public interface IDamageable
{
    public void TakeDamage(float damageValue);
}

//================ Health System of Tank ===============
public class HealthSystem : MonoBehaviour, IDamageable
{
    private float _health = 100f;
    [SerializeField] private Image healthProgressBar;
    [SerializeField] private TankEngineBase currentTankEngine;

    public void TakeDamage(float damageValue)
    {
        _health -= damageValue;
        if (_health <= 0)
        {
            _health = 0;
            currentTankEngine.StopEngine();
        }

        float progressBarValue = _health / 100;
        healthProgressBar.fillAmount = progressBarValue;
    }
}

//================ Projectile Health =================
public class ShellHealth : MonoBehaviour
{
    [SerializeField] private float damage = 100f;

    private void OnCollisionEnter2D(Collision2D other)
    {
        IDamageable damageable = other.gameObject.GetComponent<IDamageable>();
        if(damageable != null)
        {
            damageable.TakeDamage(damage);
        }
        Destroy(gameObject);
    }
}

//============= Drone Health ==============
public class DroneHealth : MonoBehaviour
{
    [SerializeField] private float damage = 20f;
    private void OnCollisionEnter2D(Collision2D other)
    {
        // Call TakeDamage by Interface
        IDamageable damageable = other.gameObject.GetComponent<IDamageable>();
        if (damageable != null)
        {
            damageable.TakeDamage(damage);
        }
        Destroy(gameObject);
    }
}

8. Managing UI, Audio, and Game State with the Observer Pattern

Register the following events so that, through a unified update interface, observers can be notified and respond whenever changes occur. At its core, this is a listen‑and‑respond system.

By following the Single Responsibility Principle (SRP), scripts like AudioManager.cs and UIManager.cs only handle their specific tasks — playing sounds or managing the UI — without mixing in unrelated logic.

Suggestions on Applying SOLID Principles

Start with the easier solution
Never force yourself to use SOLID principles — apply them only when needed (this is my takeaway)
Avoid over‑designing, especially when your design goes beyond the scope of the project itself
Always try to use a modular approach, so each independent module can be reused like LEGO blocks (this is one of the most useful methods I’ve learned from other courses — it really saves time and effort)
At first, applying SOLID principles in code design will definitely take more time, but for projects with long‑term scalability, the investment is absolutely worth it
Apply → Fail → Learn → Apply → and you’ll be surprised by the results!

Project Expansion & Retrospective

Expansion

The following features were added based on the original project:

Added Medium Tank
- Controlled by pressing the “M” key
- Can move up and down, but slower and with a smaller range than the Light Tank
Different Bullet Types Based on Tank Type: Laser, Bullet, Bomb
- Light Tank: Fires lasers (shortest cooldown), deals the least damage, shoots 5 beams in a fan shape
- Medium Tank: Fires bullets (medium cooldown), deals moderate damage
- Heavy Tank: Fires rockets (longest cooldown), deals the highest damage
Added Heavy Drone
- Moves slightly up and down randomly while flying
Adjusted Drone Spawn Rules to Increase Difficulty Over Time
- At the start, heavy drone have a low spawn rate, which increases as time goes on
Different Tanks Take Different Amounts of Damage
- Heavy tanks are the most durable

Project Architecture Overview

The project uses a hybrid design combining Component-Based Architecture + Event-Driven Programming + Strategy Pattern.

Folder Structure

Assets/
├── Audio/              # Sound effects (shooting, explosions, damage)
├── Fonts/              # Font assets
├── OtherResources/     # Third-party art assets
├── Prefabs/            # Prefabs
│   ├── Drone/          # Drone prefabs (Light, Heavy)
│   ├── Projectile/     # Projectile prefabs (3 types)
│   └── Tank/           # Tank prefabs (Light, Medium, Heavy)
├── Scenes/             # Scene files
├── Scripts/            # Core scripts
│   ├── Drone/          # Drone logic
│   ├── GameUtil/       # Game event system
│   ├── Mgr/            # Managers (Game, Audio, UI)
│   ├── Projectile/     # Projectile logic
│   └── Tank/           # Tank logic
│       ├── Engine/     # Engine/selection system
│       ├── Fire/       # Firing system
│       ├── Health/     # Health system
│       └── Move/       # Movement system
└── Sprites/            # Sprite assets

Architecture Overview

Module	Responsibility	Core Classes
Tank/Engine	Tank engine switching system; player can switch tank types using L/M/H keys	`TankEngineBase` → `TankEngineLight/Medium/Heavy`, `TankEngineSelector`
Tank/Move	Tank movement system; each tank type has its own movement logic	`TankMoveBase` → `LightTankMove/MediumTankMove/HeavyTankMove`, `IMoveY`, `TankRotate`
Tank/Fire	Firing system; different projectile types implemented via `IProjectile` interface	`TankFire`, `IProjectile` → `LightShell/MediumShell/RocketShell/LaserShellProjectile`
Tank/Health	Health system; unified damage handling via `IDamageable` interface	`HealthSystem`, `IDamageable`
Drone	Enemy drone system, including spawning, movement, and damage handling	`DroneMoveBase` → `LightDroneMove/HeavyDroneMove`, `DroneHealth`, `DroneSpawner`
Mgr	Global managers	`GameMgr` (game flow), `UIMgr` (UI panels/score), `AudioMgr` (sound effects)
GameUtil	Global event bus	`GameEvents` (static event class)

Architecture diagram

Code Reuse

Observer Pattern

The Observer pattern usually follows the same routine. Take AudioManager as an example:

//======== 1. Register events =========
//========= GameEvents.cs =========
public static class GameEvents
{
    public static Action OnGameStarted;
    public static Action OnGameOver;
    public static Action OnTankFired;
    public static Action OnTankDamaged;
    public static Action OnDroneDestroy;
}

//========= 2. Listen to events wherever they are needed =========
//========= TankFire.cs =========
private void Update()
{
    if (Input.GetKeyDown(KeyCode.Space))
    {
        GameEvents.OnTankFired?.Invoke();
        if (projectile != null)
        {
            projectile.Fire(firePos);
        }
    }
}

//========== HealthSystem.cs ==========
public void TakeDamage(int damageValue)
{
    GameEvents.OnTankDamaged?.Invoke();
    _health -= damageValue;
    if (_health <= 0)
    {
        _health = 0;
        currentTankEngine.StopEngine();
    }

    float progressBarValue = _health / 100;
    healthProgressBar.fillAmount = progressBarValue;
}

//========== DroneHealth.cs ===========
public void TakeDamage(int damageValue)
{
    GameEvents.OnDroneDestroy?.Invoke();    // The sound effect only plays when a drone is hit by a projectile
    Destroy(gameObject);
}

//========== 3. Centralize responses in AudioManager based on the events being listened to ==========
//========== AudioMgr.cs =========
public class AudioMgr : MonoBehaviour
{
    [SerializeField] private AudioClip droneDestroyClip;
    [SerializeField] private AudioClip tankFiredClip;
    [SerializeField] private AudioClip tankDamagedClip;
    [SerializeField] private AudioSource audiosource;

    private void PlayDroneDetroyAudio()
    {
        audiosource.PlayOneShot(droneDestroyClip);
    }
    
    private void PlayTankFiredAudio()
    {
        audiosource.PlayOneShot(tankFiredClip);
    }
    
    private void PlayTankDamagedAudio()
    {
        audiosource.PlayOneShot(tankDamagedClip);
    }
    
    private void OnEnable()
    {
        SubscribeEvents();
    }

    private void OnDisable()
    {
        UnSubscribeEvents();
    }

    private void SubscribeEvents()
    {
        GameEvents.OnDroneDestroy += PlayDroneDetroyAudio;
        GameEvents.OnTankFired += PlayTankFiredAudio;
        GameEvents.OnTankDamaged += PlayTankDamagedAudio;
    }
    
    private void UnSubscribeEvents()
    {
        GameEvents.OnDroneDestroy -= PlayDroneDetroyAudio;
        GameEvents.OnTankFired -= PlayTankFiredAudio;
        GameEvents.OnTankDamaged -= PlayTankDamagedAudio;
    }
}

Event Bus System — `GameEvents`

Create a similar static event class in any project to enable decoupled communication between modules. Simply update the event names to adapt it to different games.

public static class GameEvents
{
    public static Action OnGameStarted;
    public static Action OnGameOver;
    public static Action OnTankFired;
    public static Action OnTankDamaged;
    public static Action OnDroneDestroy;
}

Interface-Driven Damage System — `IDamageable`

All objects that can take damage (players, enemies, destructibles) implement this interface. Attackers simply call GetComponent<IDamageable>()?.TakeDamage(), achieving complete decoupling.

public interface IDamageable
{
    void TakeDamage(int damage);
}

Analysis of SOLID Principles in the Project

S — Single Responsibility Principle (SRP)

Tank functionalities like movement, shooting, rotation, and health are split into independent components instead of being lumped into a massive “Tank” class. This is a classic example of SRP in practice.

Class	Responsibility
`TankMoveBase`	Solely responsible for movement logic
`TankFire`	Solely responsible for triggering shots
`TankRotate`	Solely responsible for rotation and aiming
`HealthSystem`	Solely responsible for health management
`AudioMgr`	Solely responsible for playing sound effects
`UIMgr`	Solely responsible for UI display and scoring
`GameMgr`	Solely responsible for game flow logic
`DroneSpawner`	Solely responsible for spawning drones
`DroneHealth`	Solely responsible for drone damage logic

O — Open/Closed Principle (OCP)

Ammo System: The IProjectile interface allows adding new ammo types (e.g., LaserShellProjectile, RocketShellProjectile) without modifying TankFire. You simply create a new class implementing IProjectile.
Movement System: The combination of the IMoveY interface and TankMoveBase enables adding new tank movement styles without altering the base class.
Drone Movement: DroneMoveBase allows extending new flight behaviors via inheritance (e.g., HeavyDroneMove with random offset movements).

L — Liskov Substitution Principle (LSP)

The three subclasses of TankEngineBase (TankEngineLight, TankEngineMedium, TankEngineHeavy) can be used interchangeably within TankEngineSelector and GameMgr.
GameMgr.CheckEngine() iterates through a List<TankEngineBase> and calls GetStatus(), remaining unaware of the specific engine type.
Similarly, subclasses of DroneMoveBase can be swapped wherever a DroneMoveBase is required.

I — Interface Segregation Principle (ISP)

IMoveY: Defines only a single method, MoveY(float), forcing implementers to ignore unrelated functions like rotation or shooting.
IProjectile: Defines only Fire(Transform), allowing each ammo type to focus solely on “how to fire.”
IDamageable: Defines only TakeDamage(int), enabling any object capable of taking damage to implement it easily.

The interfaces are extremely granular, each containing just one method, perfectly adhering to ISP.

D — Dependency Inversion Principle (DIP)

Damage handling in DroneHealth relies on the IDamageable interface rather than the concrete HealthSystem class:

1
2

IDamageable damageable = other.gameObject.GetComponent<IDamageable>();
damageable?.TakeDamage(damage);

TankFire depends on the IProjectile interface to launch ammo, not on specific ammo classes.
TankMoveBase casts itself to an interface (this as IMoveY) for calls, ensuring high-level logic depends on abstractions rather than concrete implementations.

Retrospective

While SOLID principles greatly enhance scalability, they also significantly increase the number of scripts. For instance, implementing the Observer Pattern for the UI took nearly a full day, and debugging a single issue consumed an entire afternoon. For beginners, pitfalls often arise from where listener code is placed and the order of execution, which requires careful attention.

Additionally, this was my first systematic dive into game architecture. At times, the concepts felt quite abstract and difficult to grasp immediately. However, the most tangible takeaway from this project is its excellent extensibility: adding new features requires writing new scripts without touching old ones, effectively avoiding the scenario where one new feature introduces three new bugs. This is crucial for large-scale projects or online mobile games.

I hope that as my skills grow, my exposure to excellent complex/large-scale projects increases, and the complexity of my personal projects rises, my understanding and practical application of software architecture will continue to improve.

【Practice Log】Unity Mini Game Collection 1

Sat, 10 Jan 2026 09:19:30 +0800

[Merge Big Watermelon](#Merge Big Watermelon)
[Space Shooter](#Space Shooter)
[Flappy Bird](#Flappy Bird)
Pong
Asteroids

The games in this practice series are all intentionally small. The goal is to get comfortable with Unity’s APIs, sharpen my problem-solving mindset, and explore different ways of thinking. The top priority is to quickly build working prototypes or extract reusable code snippets. Things like overall architecture or long-term scalability aren’t the focus here.

Merge Big Watermelon

Tutorial Reference and Assets Source：Bilibili-YouChiHui

Source Code： on Gitee

Game Overview

Merge Big Watermelon is a casual browser game released by Weisun Games in early 2021. It quickly went viral thanks to its easy-to-learn mechanics, addictive gameplay, and strong social sharing appeal.

Core Gameplay:

Players tap the screen to drop random fruits from the top—grapes, oranges, apples, and so on.
When two identical fruits collide, they merge into a larger one: two grapes become a cherry, two cherries become an orange, and so on. The ultimate goal is to create the biggest fruit—the watermelon.
The game blends mechanics from Tetris and 2048: fruits fall and stack under gravity, and the game ends if the pile crosses the top of the screen.

Game Breakdown

Content

Background image
Walls and floor
Fruits (active and standby)
Game-over line
UI (score display)
Sound effects (landing, merging)

Core Logic

The standby fruit follows the mouse along the X-axis while the mouse is held down, and drops when released
Fruits bounce and collide with each other when they land. If two identical fruits touch, they merge into a bigger one
If any fruit crosses the game-over line, the game ends and the scene reloads
The current score is displayed on screen.

Development Steps

Set up the scene layout
Add gravity, collision, and bounce physics to fruits and other objects
Turn fruits into prefabs
Make the standby fruit follow the mouse
Drop the fruit when the mouse is released
Handle fruit merging logic
Detect when fruits hit or cross the game-over line
Display the score in the UI
Add sound effects

Problems & Solutions

1. No Clear Plan

When I got stuck, I used the classic “How do you put an elephant in a fridge?” mindset—break things down into the tiniest possible steps. For example, Step 4 in the development plan (“make the standby fruit follow the mouse”) can be broken down like this:

Create an array of standby fruits (types 1–4)
Define a spawn point for the standby fruit
Randomly pick a fruit from the array to spawn
On mouse down, get the mouse’s position and apply it to the fruit (only update the X-axis; keep Y and Z unchanged)
Add boundary checks so the fruit doesn’t move past the left/right walls

2. Converting Screen Coordinates to World Coordinates

// Screen Coordinates -> World Coordinates
Vector3 screenPoint = Input.mousePosition; // eg. The position of the mouse
Vector3 worldPoint = Camera.main.ScreenToWorldPoint(screenPoint);

// World Coordinates -> Screen Coordinates
Vector3 worldPos = player.transform.position;
Vector3 screenPos = Camera.main.WorldToScreenPoint(worldPos);

One thing to watch out for: since the main camera in Unity is positioned at Z = -10 in world space, you need to manually set the Z value to 0 when converting screen coordinates to world coordinates for 2D objects. Otherwise, the object might not be visible—it’ll be behind the camera.

In Unity, the origin of screen coordinates is at the bottom-left corner

3. Delayed Execution

`1`	`Invoke("funcName", second);`

4. Assigning the Singleton Instance

// After marking a class as a singleton, don’t forget to assign the instance in Awake()
public class PlayerManager : MonoBehaviour
{
    public static PlayerManager Instance;
    
    public GameObject[] fruits;
    public Transform createPoint;
    [HideInInspector]
    public GameObject waitingFruit;

    private void Awake()
    {
        Instance = this;
    }
    
    // Other codes
}

5. Fruit Merging Logic

Each fruit has a unique ID, so it can be used to identify individual objects. To avoid both fruits triggering a merge at the same time, only the one with the higher ID is allowed to spawn the next-level fruit.

6. Custom Font Scaling Issue

Custom fonts didn’t scale properly using the usual font size settings, it can be fixed by scaling the entire object instead.

7. Sound Effect Spam on Landing

To avoid messy audio from tiny movements, a velocity threshold can be set to help with this—only play the landing sound if the fruit’s velocity is above a certain value.

Reflection

This was my first hands-on Unity project. I tried to write all the code myself, only checking tutorials when I got stuck—then I’d go back and implement the logic on my own. Whenever I hit an unfamiliar API, I’d dig into my old notes or check the official docs. That really helped the knowledge stick.

The demo covers the core gameplay, though there are still a few bugs. For example, sometimes the game doesn’t restart even when fruits stack past the game-over line. Also, after merging into the final watermelon, I still need to add a victory screen and scene. I’ll revisit to polish those once I’ve finished a few more practice projects.

Code Reuse

1. Use Singleton Pattern for All “Manager” Classes

// Take PlayerManager for example
public class PlayerManager : MonoBehaviour
{
    public static PlayerManager Instance;

    private void Awake()
    {
        Instance = this;
    }
    // Other codes
}

2. Make the game object follow the mouse

private void PlaceFruit()
{
    // Get the mouse position in screen coordinates
    // Convert it to world coordinates
    Vector3 mousePos = Camera.main.ScreenToWorldPoint(Input.mousePosition);
    // When the left mouse button is held down, move the standby fruit with the mouse
    // In this case, the fruit only follows the mouse along the X-axis
    if (Input.GetMouseButton(0))	
    {
        waitingFruit.transform.position = new Vector3(mousePos.x, waitingFruit.transform.position.y, 0);
    }
}

Space Shooter

Tutorial Reference and Assets Source：Bilibili-QiQiKer-Plane

Source Code： on Gitee

Game Overview

Space Shooter is an official Unity 3D beginner tutorial project designed to help newcomers quickly grasp the basics of Unity development. It covers core concepts such as scene setup, player control, enemy spawning, collision detection, UI display, and audio integration. This version builds on the original tutorial by adding upgraded features—like enemies that can fire bullets.

Core Gameplay:

Genre: 2D space shooter (with a 3D top-down view)
Objective: Pilot your spaceship and survive as long as possible while destroying waves of enemies and asteroids.
Controls:
- Movement: Use WASD or arrow keys to move freely within the screen
- Shooting: Left mouse button fires bullets
Enemy Behavior:
- Asteroids and enemy ships spawn randomly from the top of the screen, falling at different speeds
- Enemies move side-to-side and shoot bullets at the player
- The player must dodge or destroy them to avoid collisions or being hit by enemy fire
Game Over: The game ends if the spaceship is hit by an asteroid or a bullet
Scoring System: Each destroyed enemy adds points, with the UI showing the score in real time

Game Breakdown

Content

Scene setup

Background slowly scrolling downward
Animations: enemy explosions, asteroid explosions, ship tilting when moving left/right, asteroid rotation
UI: score display
Audio: background music, shooting, hit effects

Core Logic

Player can move in all four directions and shoot bullets
Asteroids spawn randomly at the top of the screen and fall at a constant speed
Enemies spawn randomly at the top, move down faster, dodge left/right, and fire bullets
Current score is displayed in the UI
If the player is hit by enemy bullets or collides with asteroids/enemies, the ship is destroyed and the scene reloads

Development Steps

Background Setup
- Looping background movement
- Add starfield particle effects
- Add background music
Player Implementation
- Player movement controls
- Tilting effect when moving left/right (greater speed = larger tilt angle)
- Shooting mechanics
- Player bullets with sound effects
Enemies & Asteroids
- Random spawning of asteroids and enemies
- Random asteroid rotation effect
- Enemy shooting logic
- Enemy side-to-side dodging movement
Effects
- Attack and collision effects
UI
- Build the UI layout
- Implement score display logic

Problems & Solutions

1. Moving the Background

Should the background move, or should the camera move? In most cases, it’s easier to move the background. Since the scene contains asteroids, enemies, the player, and other objects, keeping the camera still simplifies everything.

One thing to keep in mind:

When doing any kind of back‑and‑forth or looping movement that needs to stay in sync with absolute time, use Time.time.
For regular movement, timers, or accumulative values that must stay frame‑rate independent, use Time.deltaTime.

// Movement calculation (usually handled with built‑in APIs)
this.transform.Translate(Vector3.forward * 1 * Time.deltaTime, space.World); // 如果是自己坐标系：Space.Self

// Looping background movement
private void ScrollBG()
{
    float distance = Mathf.Repeat(_scrollSpeed * Time.time, 30);
    transform.position = _startPos + distance * Vector3.forward * (-1);
}

2. Rigidbody calculations should be placed in

Since the time between frames in Update() can vary depending on device performance and workload, running physics or Rigidbody operations there may cause jitter or inconsistent behavior. Using FixedUpdate() ensures physics calculations run at a stable, fixed timestep.

// Control the player's movement by manipulating the Rigidbody
private void FixedUpdate()
{
    MovePlayer();
}

private void MovePlayer()
{
    float horizontalVel = Input.GetAxis("Horizontal"); // 0-1
    float verticalVel = Input.GetAxis("Vertical");
    Vector3 velocity = new Vector3(horizontalVel, 0, verticalVel);
    _playerRB.velocity = velocity * _speed;
    // Other codes
}

3. A Simple Way to Handle Boundary Checking

It’s often easier to visually adjust boundary positions in the Inspector rather than controlling everything purely through code. The idea is to create a struct inside the class, mark it as serializable, and then reference it in your logic. (Don’t forget to instantiate the Border class before using it.)

public class PlayerController : MonoBehaviour
{
    [Serializable]
    public struct Border
    {
        public float maxZ;
        public float minZ;
        public float minX;
        public float maxX;
    }
    
    [SerializeField] private Border _border;
    
    // Other codes
	private void MovePlayer()
    {
      	// Other codes
        
        // Border check
        float posX = Mathf.Clamp(_playerRB.position.x, _border.minX, _border.maxX);
        float posZ = Mathf.Clamp(_playerRB.position.z, _border.minZ, _border.maxZ);
        _playerRB.position = new Vector3(posX, 0, posZ);
    }
}

4. Apply tilt to the object through Rigidbody-based rotation

// Rotate the object 30° around the Y-axis
Quaternion rotation = Quaternion.Euler(0, 30, 0);

// You can directly use the Rigidbody's rotation property
_playerRb.rotation = Quaternion.Euler(0, 0, _playerRb.velocity.x * (-1) * tilt);

5. Component-Based (“Feature Hook”) Architecture

Break reusable functionality into small, focused components (e.g., MoveController), then let higher-level behavior scripts (e.g., PlayerController / EnemyController) compose and use them.

Pros: High reusability, clear responsibilities, easy to test, easy to maintain; follows composition over inheritance.

Cons: Some objects may end up with multiple small scripts attached, but this is normal for single‑responsibility design and has minimal performance impact.

Best Practices: Keep each component focused on a single responsibility, use interfaces/events for decoupling, use RequireComponent, store shared data in ScriptableObjects or config classes, and reuse behavior through Prefabs.

The “best practices” part is still a bit abstract for me. I’ve seen it once in the “2048” project, and I’ll need more hands‑on experience to fully internalize how to apply it.

6. When to Call `GetComponent`

A commonly recommended pattern is:

Use Awake() when retrieving and caching components on the same GameObject.
Use Start() when the component depends on other objects that also initialize in Awake()

// Get the Rigidbody component from the same GameObject as MoveController
public class MoveController : MonoBehaviour
{
    private Rigidbody rb;

    private void Awake()	// Retrieve the Rigidbody in Awake()
    {
        rb = GetComponent<Rigidbody>();
    }

    public void Move(Vector3 dir, float speed)
    {
        rb.velocity = dir.normalized * speed;
    }
}

// This script depends on values initialized by other objects in their Awake(), so use Start()
public class EnemyAI : MonoBehaviour
{
    private MoveController move;
    private Transform player; // Assume the Player finishes its setup in Awake()

    private void Start()
    {
        move = GetComponent<MoveController>();	// Another object (MoveController) gets the component in Start()
        player = GameObject.FindWithTag("Player")?.transform; // Waiting until all Awake() calls are done makes the lookup safer
    }

    private void Update()
    {
        if (player == null) return;
        Vector3 dir = (player.position - transform.position);
        dir.y = 0f;
        move.Move(dir, 3f);
    }
}

7. General Coroutine Usage

A few things to keep in mind:

Define a method that returns IEnumerator, and use yield return inside it to wait (e.g., null, new WaitForSeconds(...), WaitForEndOfFrame, etc.)
Start it with StartCoroutine(MyCoroutine()); you can stop it with StopCoroutine if needed
Never write a while(true) loop without any yield inside a main-thread method (like Start()), or it will freeze the entire game loop

// Use coroutines to spawn and destroy enemies
// Run the spawn loop inside a coroutine and use Instantiate to create enemies,
// then use another coroutine to destroy them after a delay
private void Start()
{
    StartCoroutine(SpawnEnemyWave());
}

private IEnumerator SpawnEnemyWave()
{
    yield return new WaitForSeconds(startSpawnTime);
    while (true)
    {
        for (int i = 0; i < enemyCount; i++)
        {
            GameObject prefab = enemies[Random.Range(0, enemies.Length)];
            GameObject newEnemy = Instantiate(prefab);
            newEnemy.transform.position = new Vector3(Random.Range(-4, 5), 2, 10);
        }
        yield return new WaitForSeconds(spawnWaitingTime);  
    }
}

// Enemies and their bullets are all destroyed the same way as the player's bullets, 
// using a unified KillBox system

8. Implementing Asteroid Self‑Rotation

Use the Random.insideUnitSphere API, which returns a random Vector3 whose direction and magnitude are uniformly distributed inside a unit sphere. Multiplying this vector by rotationSpeed scales it to the desired angular velocity. Finally, assign it to Rigidbody.angularVelocity: the vector’s direction represents the rotation axis, and its magnitude represents the angular speed (in radians per second). As a result, the asteroid rotates around a random axis at the given speed.

 private void Start()
 {
     _rb.angularVelocity = Random.insideUnitSphere * rotationSpeed;
 }

9. Two Ways to Implement Enemy Shooting

Method 1: Use the same approach as the player’s shooting logic—accumulate time and fire when the timer exceeds a threshold.

Method 2: Use the InvokeRepeating(string methodName, float time, float repeatRate) API. It calls methodName after time seconds, and then repeats the call every repeatRate seconds.

// Implementation of Method 1
private void Update()
{
    SpawnBullet();
}

private void SpawnBullet()
{
    _waitingTime += Time.deltaTime;
    if (_waitingTime > cooldown)
    {
        Instantiate(bullet, shootPos);
        AudioMgr.Instance.PlayAudio(AudioMgr.Instance.clips[1]);
        _waitingTime = 0;
    }
}

// Implementation of Method 2
private void Start()
{
    InvokeRepeating("SpawnBullet", startingTime, cooldown);
}

private void SpawnBullet()
{
    Instantiate(bullet, shootPos);
    AudioMgr.Instance.PlayAudio(AudioMgr.Instance.clips[1]);
}

10. Implementing Enemy Dodging Behavior

After an enemy has existed for a certain amount of time (a random value), it begins a dodge action. If the enemy spawns on the left half of the screen, it moves to the right; if it spawns on the right half, it moves to the left. After dodging for another random duration, it stops the horizontal movement, continues descending, and then repeats the dodge cycle until it is naturally destroyed.

Use a coroutine to perform the dodge for a period of time, then return to straight downward movement
To make the dodge motion smooth and natural, apply acceleration using Mathf.Lerp(float a, float b, float t), where a is the start value, b is the target value, and t is the interpolation factor between 0 and 1
Remember to perform boundary checks while the enemy is moving

The tutorial uses Mathf.MoveTowards(float current, float target, float maxDelta) instead. This API is conceptually similar to Lerp in that it moves current toward target smoothly. However, using this method requires a much larger acceleration value; otherwise, the enemy may appear to not dodge at all. The reason lies in the fundamental difference between the two:

Lerp uses proportional interpolation (t is a 0–1 ratio), which pulls the value toward the target proportionally—even if the target is on the opposite side, it still produces a small counter‑directional velocity
MoveTowards uses an absolute step size (maxDelta), moving only a fixed amount per frame. If maxDelta is too small (e.g., acceleration is low), the per‑frame velocity change is overshadowed by other factors (friction, resets, threshold checks), making it look like “no dodge happened”

private void Start()
{
    StartCoroutine(Dodge());
}

private void FixedUpdate()
{
    // float xVel = Mathf.MoveTowards(_rb.velocity.x, _targetDodgeSpeed, Time.fixedDeltaTime * acceleration);  // 100
    float xVel = Mathf.Lerp(_rb.velocity.x, _targetDodgeSpeed, Time.fixedDeltaTime * acceleration); // 20
    _rb.velocity = new Vector3(xVel, _rb.velocity.y, _rb.velocity.z);
}

private IEnumerator Dodge()
{
    while (true)
    {
        yield return new WaitForSeconds(Random.Range(startingTimeMin, startingTimeMax));

        _targetDodgeSpeed = Random.Range(dodgeSpeedMin, dodgeSpeedMax);
        // If the enemy spawns on the right half of the screen, dodge to the left 
        // If it spawns on the left side, its natural horizontal speed is already positive, 
        // so it will dodge left automatically and needs no adjustment
        if (_rb.position.x >= 0)   
        {
            _targetDodgeSpeed = -_targetDodgeSpeed;
        }

        float targetTime = Random.Range(movingTimeMin, movingTimeMax);

        yield return new WaitForSeconds(targetTime);
        _targetDodgeSpeed = 0;
    }
}

11. When to Use `OnTrigger` vs. `OnCollision`

Both can be used for collision detection.

OnCollision is used when actual physical interaction is required, such as collisions, bouncing, or applying forces. Since it calculates contact points and impulses, it has a higher performance cost and is suitable for real physics interactions.

OnTrigger only detects overlap and does not automatically produce physical responses. Because it usually doesn’t compute contact points or impulses, it’s cheaper than OnCollision. It’s ideal for area detection, trigger zones, pickups, damage areas, and similar cases.

12. How to Handle Effect Destruction (Separation of Concerns)

Effect destruction should be handled in a dedicated script rather than mixing it into the CollisionCheck script. This keeps responsibilities separated (CollisionCheck only handles triggering and detection), improves reusability, and makes it easier to switch to an object‑pooling system instead of destroying effects every time.

Reflection

The tutorial introduced several fresh ideas. In this project, I started writing my own coroutines and continued practicing the singleton pattern learned from the previous game. Whenever I had questions or felt the tutorial’s approach exceeded my current understanding, I asked AI for clarification—and the answers were generally satisfying. This project‑driven learning style feels very efficient, and the constant feedback helps prevent mental fatigue.

There are still concepts I don’t fully grasp yet, such as “single‑responsibility components” and “decoupling with interfaces/events.” I’ll need more hands‑on experience in future projects to internalize these ideas.

Another fun discovery: the Unity splash screen logo can be replaced! I immediately created a small custom logo, and it looks great.

Code Reuse

1. Scrolling Infinite Background

[SerializeField] private float _scrollSpeed;
private Vector3 _startPos;

private void Start()
{
	_startPos = transform.position;
}

private void Update()
{
	ScrollBG();
}

private void ScrollBG()
{
    float distance = Mathf.Repeat(_scrollSpeed * Time.time, 30);
    transform.position = _startPos + distance * Vector3.forward * (-1);
}

2. Rotation Effect

// Random rotation for the sphere
_rb.angularVelocity = Random.insideUnitSphere * rotationSpeed;

// The 3D object tilts according to its velocity on a specific axis (x‑axis here)
 _rb.rotation = Quaternion.Euler(0, 0, _rb.velocity.x * (-1) * tilt);
float posX = Mathf.Clamp(_rb.position.x, border.minX, border.maxX);
_rb.position = new(posX, _rb.position.y, _rb.position.z);

3. `MoveController`

Using a Rigidbody allows this logic to be reused for any object moving along the Z‑axis.

public class MoveController : MonoBehaviour
{
   [SerializeField] private float flySpeed;
   private Rigidbody _rb;
   private void Awake()
   {
      _rb = GetComponent<Rigidbody>();
   }

   private void FixedUpdate()
   {
      _rb.velocity = Vector3.forward * flySpeed;
   }
}

4. `DestroyByTime`

This logic can be reused for automatically destroying visual effects or other similar things.

public class DestroyByTime : MonoBehaviour
{
    [SerializeField] private float delay;

    private void Start()
    {
        Destroy(gameObject, delay);
    }
}

5. `AudioManager`

Reusable for managing and playing all sound effects.

public class AudioMgr : MonoBehaviour
{
    public static AudioMgr Instance;
    public AudioClip[] clips;
    private AudioSource _audioSource;

    private void Awake()
    {
        Instance = this;
        _audioSource = GetComponent<AudioSource>();
    }

    public void PlayAudio(AudioClip clip)
    {
        _audioSource.PlayOneShot(clip);
    }
}

Flappy Bird

Tutorial Reference and Assets Source：Youtube-Zigurous

Source Code： on Gitee

Game Overview

Flappy Bird is a simple 2D mobile game released in 2013 by Vietnamese developer Dong Nguyen. The game became a global phenomenon due to its extremely simple visuals, extremely high difficulty, and the uniquely “addictive frustration” it creates.

Core Gameplay:

Genre: Pixel‑style 2D game with a scrolling background; the player controls a small pixel bird
Goal: Guide the bird through pairs of pipes; the farther you fly, the higher you score
Controls:
- Tap the screen (or press any key) to make the bird flap upward briefly
- Without input, the bird continuously falls due to gravity
Obstacle System:
- Randomly generated green pipes of varying heights appear in the scene
- The bird must pass through the gap between each pair of pipes
- Touching a pipe or the ground results in an immediate game over
Failure Condition:
- The bird hits an obstacle or the ground
Scoring:
- Passing through each pair of pipes awards 1 point
- There is no upper limit to the score

Game Breakdown

Content

Scene layout (parallax background, infinite scrolling)
Animation (bird flapping)
UI (score display)
Sound effects (scoring, collision)

Core Logic

The bird moves forward automatically and falls naturally under gravity
The player can press W, the Up Arrow, or click the left mouse button to make the bird move upward
If the bird hits a pipe or the ground while moving forward, the game ends
Display the current score

Development Steps

Bird
- Bird movement
- Bird flapping animation
Background
- Background creation
- Parallax scrolling
Pipes
- Pipe prefab creation
- Pipe generation
- Pipe movement
Scoring
UI design / setup
Menu interaction implementation
Adding sound effects

Problems & Solutions

1. Implementing Touch Controls

// Example: controlling the bird's upward movement
// Touch input mode
if (Input.touchCount > 0)   // As long as a finger is touching the screen
{
    Touch touch = Input.GetTouch(0);    // Get the first touch
    if (touch.phase == TouchPhase.Began)     // When the touch just begins
    {
        _dir = Vector3.up * strength;
    }
}

2. Using `InvokeRepeating` to Implement a Simple Animation

It’s important to note that InvokeRepeating schedules a method to be called at fixed intervals within Unity’s main loop. Each invocation finishes and returns control to the engine, and the method is called again after the next interval. Although it is not an actual infinite loop, if you write a while(true) (or any non‑terminating loop) inside the invoked method, the method will never return, blocking the main thread and freezing the game/editor.

In addition, InvokeRepeating is typically placed in Start (or any one‑time initialization after Awake). You only need to call it once to schedule the repeated execution, and Unity will continue calling the method at the specified interval. If you place InvokeRepeating inside Update, it will register a new repeating call every frame, resulting in a huge number of concurrent scheduled calls. This leads to the method being executed multiple times, more frequently than intended, causing logic errors and performance issues.

Using InvokeRepeating to animate the bird’s flapping:

private void Start()
{
    InvokeRepeating(nameof(AnimateSprite), 0.15f, 0.15f);
}

private void AnimateSprite()
{
    _sr.sprite = sprites[_index];
    _index++;
    if (_index >= sprites.Length)
        _index = 0;
}

3. An Approach to Implementing Parallax + Infinite Background

In the tutorial, all background elements are created as 3D Quads, and the 2D images are turned into Materials using the Unlit/Texture shader. The movement effect is achieved by adjusting the built‑in Offset property of the material. This method is very simple and highly reusable.

public class Parallax : MonoBehaviour
{
    [SerializeField] private float speed;
    private MeshRenderer _meshRenderer;

    private void Awake()
    {
        _meshRenderer = GetComponent<MeshRenderer>();
    }

    private void Update()
    {
        _meshRenderer.material.mainTextureOffset += new Vector2(speed * Time.deltaTime, 0);
    }
}

4. An Alternative Approach to Destroying Pipes

The common approach is to place a trigger collider at the left edge of the screen, and when a pipe prefab enters that trigger, it gets destroyed. The tutorial uses a simpler method: destroying the pipe based on its pixel position.

private float _killEdge;

private void Start()
{
    _killEdge = Camera.main.ScreenToWorldPoint(Vector3.zero).x - 1;
}

private void Update()
{
    // Other codes

    if (transform.position.x < _killEdge)
    {
        Destroy(gameObject);
    }
}

5. Coordinate Systems in Unity

World Coordinates (World)

Unity’s world coordinates are based on the global origin (0,0,0), measured in Unity units (commonly treated as meters)
Axis directions: X to the right, Y upward, Z forward (positive Z points toward the front of the Scene view)
transform.position represents a GameObject’s world position; transform.localPosition is its position relative to its parent

Screen Coordinates (Screen)

Measured in pixels, with the origin at the bottom‑left corner (0,0); the top‑right corner is (Screen.width, Screen.height)
Legacy IMGUI (OnGUI) uses the top‑left corner as the origin; UI coordinate behavior also depends on the Canvas Render Mode (Screen Space / World Space)

Viewport Coordinates (Viewport)

Normalized coordinates in the range [0,1], with (0,0) at the bottom‑left and (1,1) at the top‑right
Conversion available via Camera.ViewportToWorldPoint and WorldToViewportPoint

In the pipe‑destruction example above, Camera.ScreenToWorldPoint(Vector3 screenPoint) is used to convert the screen‑space origin (0,0,0)—i.e., Vector3.zero—into world coordinates. This ensures that the value can be compared with transform.position.x inside Update, since both are then in the same coordinate system.

6. Restarting and Pausing the Game

The simplest approach is to use Time.timeScale.

Reflection

Because this is a 2D game, directions like Vector3.up and Vector3.left can be used directly, which greatly simplifies the code. The tutorial introduced several elegant and practical design ideas—for example, using 3D quads for the background and applying _meshRenderer.material.mainTextureOffset to achieve infinite scrolling and parallax; converting a point from screen coordinates to world coordinates to determine when an object should be destroyed, instead of relying on traditional collision detection; and implementing simple animations using InvokeRepeating combined with iterating through sprites, avoiding the need for Unity’s built‑in animation system.

In my own practice, I revisited the singleton pattern for both the GameManager and AudioManager, and refreshed my understanding of sound playback and UI interaction design. Even though this is a beginner‑level mini‑game, I still learned a lot from it.

Code Reuse

A Spawner Implementation

Using InvokeRepeating to spawn game objects at fixed intervals.

private void OnEnable()
{
    InvokeRepeating(nameof(Spawn), startSpawn, spawnRate);
}

private void OnDisable()
{
    CancelInvoke();
}

private void Spawn()
{
    GameObject pipe = Instantiate(prefab, transform.position, Quaternion.identity);
    pipe.transform.position += Vector3.up * Random.Range(minHeight, maxHeight);
}

Other reusable code snippets have already been covered in the “Problems & Solutions” section above, so they won’t be repeated here.

Pong

Tutorial Reference and Assets Source：Youtube-Zigurous

Source Code： on Gitee

Game Overview

Pong is one of the earliest and most influential arcade games in video game history, released by Atari in 1972. It simulates the real‑world sport of table tennis and is widely regarded as the first commercially successful video game.

Core Gameplay:

The game takes place on a 2D plane with a vertical paddle on each side and a moving ball in the center
The player controls one paddle, moving it up and down (typically via joystick or buttons) to bounce the ball back toward the opponent
If a player fails to return the ball, the opponent scores a point
The ball bounces off the top and bottom boundaries; hitting the left or right boundary results in a score
As the game progresses, the ball may gradually increase in speed, raising the difficulty

Game Breakdown

Content

Scene layout

Player paddle
Ball
AI paddle
UI (score display)

Core Logic

The player moves the paddle using W / Up Arrow and S / Down Arrow to hit the ball
The ball bounces off the top and bottom boundaries
If the ball enters the player’s side, the opponent scores a point, and vice versa
Display the current score

Development Steps

Scene layout
Player paddle movement
Ball movement implementation
AI paddle behavior
Gradual increase in ball speed after each bounce
Displaying the UI score

Problems & Solutions

1. `Angular Drag` and `Linear Drag`

In a Rigidbody, Angular Drag represents the angular damping coefficient. If you don’t want the object to rotate, you should manually set it to 0 (its default value is 0.05) and also disable rotation on the Z‑axis in the Constraints section. This is a common setup for 2D games like this one.

Linear Drag, on the other hand, applies to positional movement. A higher drag value causes the object to stop moving or rotating more quickly after being affected by collisions or forces.

2. Notes on Using `FixedUpdate`

Avoid reading input directly inside FixedUpdate. Since FixedUpdate runs at the physics timestep, input events may be missed or become inconsistent.

The correct approach is to read input inside Update(), store the result in a field, and then apply forces based on that field inside FixedUpdate().

private void Update()
{
    if (Input.GetKey(KeyCode.W) || Input.GetKey(KeyCode.UpArrow))
    {
        _dir = Vector2.up;
    }
    else if (Input.GetKey(KeyCode.S) || Input.GetKey(KeyCode.DownArrow))
    {
        _dir = Vector2.down;
    }
    else
    {
        _dir = Vector2.zero;
    }
}

private void FixedUpdate()
{
    if (_dir.sqrMagnitude != 0)
    {
        Rb.AddForce(_dir * strength);
    }
}

FixedUpdate is primarily used for updates that need to stay in sync with the physics system.

Tasks appropriate for FixedUpdate:

Applying forces/torque (Rb.AddForce / AddRelativeForce) or directly setting Rigidbody.velocity
Using Rigidbody.MovePosition / MoveRotation (for Kinematic Rigidbodies)
Timers, constraints, and solver logic that must match the physics timestep (deterministic simulation, server‑side physics steps)
Physics‑based queries (collision checks, overlap tests, raycasts performed within the physics step)
Physics prediction/interpolation/extrapolation logic (synchronized with the fixed timestep)

Tasks not appropriate for FixedUpdate (require per‑frame or lower‑latency handling):

Input reading
Rendering / camera follow
UI updates
Animation (typically handled in Update or LateUpdate)

3. Implementing Ball Bounce Behavior

Using code like this will not produce the correct effect. The issue is likely incorrect direction calculation: using -rb.velocity is not equivalent to reflecting the velocity based on the collision normal. As a result, the ball may be pushed in an unintended direction.

private void OnCollisionEnter2D(Collision2D other)
{
    if (other.transform.CompareTag("Ball"))
    {
        Rigidbody2D rb = other.gameObject.GetComponent<Rigidbody2D>();
        _dir = rb.velocity.normalized;

        rb.AddForce(-_dir * strength);
    }
}

It can be resolved by using the collision contact normal.

private void OnCollisionEnter2D(Collision2D other)
{
    if (other.transform.CompareTag("Ball"))
    {
        Rigidbody2D rb = other.gameObject.GetComponent<Rigidbody2D>();
        _dir = other.GetContact(0).normal;  // Normal of the collision contact point

        rb.AddForce(-_dir * strength);
    }
}

4. Using the `EventSystem` to Handle Player and AI Scoring

The implementation feels very similar to how UI buttons work.

Explanation of the code:

TriggerEvent is essentially an alias/subclass of UnityEvent<BaseEventData>, allowing callbacks that receive BaseEventData to be registered either in the Inspector or via code
A BaseEventData instance is created with the current EventSystem as its source; the callback can read this eventData to obtain context
Calling scoreTrigger.Invoke triggers all registered callbacks and passes in the eventData

public class ScoringArea : MonoBehaviour
{
    [SerializeField] private EventTrigger.TriggerEvent scoreTrigger;
    private void OnCollisionEnter2D(Collision2D other)
    {
        if (other.gameObject.CompareTag("Ball"))
        {
            BaseEventData eventData = new BaseEventData(EventSystem.current);
            scoreTrigger.Invoke(eventData); // Invoke all registered callbacks with the eventData
        }
    }
}

Reflection

The tutorial uses a base class Paddle along with two subclasses, PlayerPaddle and ComputerPaddle. Shared logic—such as component retrieval—is placed in the parent class, while each subclass implements its own behavior. In C++ projects, I frequently rely on inheritance, but when working in Unity I often forget to apply it. In future projects, I need to remind myself to use inheritance more often when it fits the design.

Code Reuse

Reusable code in this project has already been discussed in the “Problems and Solutions” section:

Implementation of ball bounce behavior
Using the EventSystem to flexibly trigger multiple callbacks

Asteroids

Tutorial Reference and Assets Source：Youtube-Zigurous

Source Code： on Gitee

Game Overview

Asteroids is a classic arcade shooter released by Atari in 1979. With its minimalist vector graphics and fast‑paced gameplay, it became a landmark title in video game history.

Core Gameplay:

The player controls a small spaceship that moves freely in zero‑gravity space (able to thrust, rotate, and shoot)
- Press W / Up Arrow or S / Down Arrow to rotate
- Press A / Left Arrow or D / Right Arrow to thrust left or right
- Press Space or click the left mouse button to fire bullets
Asteroids of various sizes continuously appear, drifting in from the edges of the screen
Objective: destroy all asteroids with laser shots
- Large and medium asteroids split into smaller fragments when hit (e.g., Large → Medium → Small → Disappear)
Failure:
- The spaceship is destroyed instantly upon colliding with an asteroid (typically with limited lives)
Additional Features:
- The ship has momentum; it continues drifting even after thrust stops, requiring reverse thrust to slow down

Game Breakdown1

Content

Scene layout
Player
Asteroids
Explosion effects

Core Logic

Player movement and shooting
Random asteroid spawning and movement
Asteroids split when hit by the player’s bullets, until they disappear
The round ends if the player collides with an asteroid
Display the current score
When all lives are used up, the game ends

Development Steps

Scene setup
Player implementation
- Movement
- Shooting
Asteroid implementation
- Asteroid prefabs (different shapes, sizes, masses, initial angles)
- Spawning asteroids
- Implementing split/destroy logic
Ending a round
- Player death and respawn
- Player explosion effect
Displaying the UI score and player’s lives
Ending the game when all lives are exhausted

Problems & Solutions

1. Configuring Collision Layers

Use Project Settings > Physics 2D to ignore collisions between the player and bullets, as well as between bullets themselves.

2. Setting Initial Asteroid States

Since the asteroids in this project have multiple variants—different sizes, sprites, masses, and initial angles—the strategy is to configure all these parameters directly in the asteroid prefabs. This allows the Spawner.cs script to simply instantiate the prefabs, keeping responsibilities clean and separated:

Asteroid.cs handles the asteroid’s own properties
Spawner.cs handles asteroid generation

public class Asteroid : MonoBehaviour
{
    [SerializeField] private Sprite[] sprites;
    [SerializeField] private float size = 1f;
    [SerializeField] private float speed = 1f;
    public float minSize = 0.5f;
    public float maxSize = 1.5f;
    private SpriteRenderer _sr;
    private Rigidbody2D _rb;

    private void Awake()
    {
        _sr = GetComponent<SpriteRenderer>();
        _rb = GetComponent<Rigidbody2D>();
    }

    private void Start()
    {
        _sr.sprite = sprites[Random.Range(0, sprites.Length)];
        transform.eulerAngles = new Vector3(0, 0, Random.value * 360);

        //size = Random.Range(minSize, maxSize);

        transform.localScale = Vector3.one * size;
        _rb.mass = size; // Adjust mass based on asteroid size

    }

    public void SetTrajectory(Vector2 dir)
    {
        _rb.AddForce(dir * speed);
    }

Initial Rotation of Asteroids:

Use Random.value, which returns a value between 0 and 1. Since the asteroid rotates around the Z‑axis, the rotation can be set simply as: transform.eulerAngles = new Vector3(0, 0, Random.value * 360);

Handling Asteroid Size:

This logic cannot be placed inside Asteroid.cs, because that script later handles the splitting behavior. If size is randomized inside Start(), it will break the splitting logic. The correct approach is to randomize the size inside Spawner.cs. This was a major pitfall I encountered during the project.

3. Approach to Asteroid Spawning and Movement

Asteroids are spawned within a circular area centered on the screen. They move toward the center. To introduce randomness, an offset angle is added to the direction toward the center. Since the offset is applied around the Z‑axis, Quaternion.AngleAxis(float angle, Vector3.forward) can be used.

For asteroid movement, the movement logic itself is handled by Asteroid.cs, while Spawner.cs instantiates the asteroid and calls its movement behavior.

 private void Start()
 {
     InvokeRepeating(nameof(Spawn), spawnInterval, spawnInterval);
 }

// Spawn the asteroid at a position within a certain radius from the spawner
private void Spawn()
{
    Vector2 spawnOffset = Random.insideUnitCircle * spawnRadius;
    Vector2 spawnPos = (Vector2)transform.position + spawnOffset;   // Pick a random point inside the radius centered on the spawner
    Vector2 dir = ((Vector2)transform.position - spawnPos).normalized;

    // Add an angular offset to the direction toward the center
    float variance = Random.Range(-trajectoryAngle, trajectoryAngle);
    Quaternion rotation = Quaternion.AngleAxis(variance, Vector3.forward);

    GameObject obj = Instantiate(asteroidPrefab, spawnPos, Quaternion.identity);
    Asteroid asteroid = obj.GetComponent<Asteroid>();
    asteroid.size = Random.Range(asteroid.minSize, asteroid.maxSize);	// Handle the random size assignment for the asteroid here
    asteroid.SetTrajectory(rotation * dir);
}

It’s important to note that the final movement direction of an asteroid is computed as rotation * dir. Since rotation is a quaternion, this operation applies the rotation to the vector:

Rotated Vector = Quaternion * Original Vector

The quaternion must be on the left side of the multiplication operator.

The underlying mathematical principles will be explored in more detail when studying the related math topics, so they won’t be expanded on here.

Additional Notes on Quaternions

Avoid modifying the x, y, z, or w components of a quaternion directly. These values do not represent angles; they are part of a complex mathematical structure. Directly editing them will lead to incorrect behavior.

Always use Unity’s built‑in API.

Commonly Used API Methods:

Scenario	Method
Rotate a vector	`rotatedVector = quaternion * vector;`
Make an object face a direction	`Quaternion.LookRotation(vector);`
Convert (0, 90, 0) to a quaternion	`Quaternion.Euler(0, 90, 0);`
Get the Euler angles of a quaternion	`quaternion.eulerAngles;`

4. Designing Player Invincibility Frames

This is implemented by changing the player’s physics collision layer using LayerMask.NameToLayer(layerName);. It’s straightforward, and Invoke is used to schedule the duration of the invincibility period.

5. Particle System Configuration

Since the UI logic uses Time.timeScale to control game start and end states, the particle system must not accidentally play at the moment a new round begins. To prevent this, set the particle system’s Delta Time to Unscaled in the Inspector.

Reflection

This project requires extensive use of rotation‑related methods, so becoming comfortable with the commonly used APIs is essential. It also highlights the need to strengthen the underlying math knowledge.

There are also two techniques in this project that are worth remembering and using more often:

Passing references to objects from other scripts through method parameters

//======= GameManager.cs =======
// The function is defined here because many of its parameters are managed centrally by the GameManager
public void AsteroidDestroyed(Asteroid asteroid)
{
    if (asteroid.size <= 0.75f)
    {
        score += 5;
    }
    else if (asteroid.size <= 1.3f)
    {
        score += 2;
    }
    else
    {
        score += 1;
    }

    Vector2 pos = asteroid.transform.position;
    explosion.transform.position = pos;
    explosion.Play();
}

//========== Asteroid.cs =========
// The method is invoked by the Asteroid class itself when a collision occurs
private void OnCollisionEnter2D(Collision2D other)
{
    if (other.gameObject.CompareTag("Bullet"))
    {
        if (size * 0.5f >= minSize)
        {
            CreateHalf();
            CreateHalf();
        }

        Destroy(other.gameObject);
        Destroy(gameObject);

        GameManager.Instance.AsteroidDestroyed(this);
    }
}

Calling a function from another script:

You can obtain the reference either through a GameObject or directly from the other script’s component attached to a game object:

//=========== Spawner.cs ============
// Call the SetTrajectory method by instantiating an Asteroid object
private void Spawn()
{
	// Other codes

    GameObject obj = Instantiate(asteroidPrefab, spawnPos, Quaternion.identity);
    Asteroid asteroid = obj.GetComponent<Asteroid>();
    asteroid.size = Random.Range(asteroid.minSize, asteroid.maxSize);   // Handle the random size assignment for the asteroid here
    asteroid.SetTrajectory(rotation * dir);
}

Code Reuse

1. Designing Player Invincibility Frames

This is implemented by changing the player’s physics collision layer, combined with the use of Invoke:

private void OnCollisionEnter2D(Collision2D other)
{
    if (other.gameObject.CompareTag("Asteroid"))
    {
        GameManager.Instance.lives--;
        gameObject.SetActive(false);

        Invoke(nameof(Respawn), respawnTime);
    }
}

private void Respawn()
{
    gameObject.SetActive(true);
    gameObject.transform.position = Vector3.zero;
    gameObject.layer = LayerMask.NameToLayer("No Collision");

    Invoke(nameof(ResetLayer), invulnerableTime);
}

private void ResetLayer()
{
    gameObject.layer = LayerMask.NameToLayer("Player");
}

2. Clearing All Objects in the Scene

Both Flappy Bird and Asteroids use the same approach when resetting the game: use FindObjectsOfType to retrieve all relevant objects in the scene, iterate through the resulting array, and destroy each one.

Asteroid[] asteroids = FindObjectsOfType<Asteroid>();
for (int i = 0; i < asteroids.Length; i++)
{
    Destroy(asteroids[i].gameObject);
}

Unity on Nullshow's Tech Blog

【Unity】Learning Commercial-Grade Coding from a Beginner Mini Game

Project Overview

Learning Goals

Development Breakdown

Key Insights and Critical Steps

PostProcessing

Separation of Visuals and Logic

Code Clarity Matters

Input Handling in Unity

Input Placement

Coordinate System Setup

Landing Implementation Logic

Don’t Use Strings to Identify Game Objects

Thruster Visual Effect Implementation

Time.deltaTime and Time.fixedDeltaTime

Using deltaTime in Update()

Using Time.fixedDeltaTime in FixedUpdate()

Key Differences

EventHandler

Temporarily Adding Color to Text

Using a State Machine to Manage Game States

Button Click Handling

Handling Unchanging Level Number

Showing a Full-Map Preview at Level Start

Create an empty GameObject named CinemachineCamera2D and attach the custom zoom script to it

Set the zoom-out value in GameLevel so each level can be configured flexibly

Configure it in GameManager

Smooth transition when switching camera

Input improvement (support multiple input systems)

Extension

Drawbacks of the old Input System

Advantages of the new Input System

Good practice

Touch input

JoyStick Input

Using SceneLoader to manage scenes

Keep background music from restarting when switching levels

Extension

About event unregistration

Same lifecycle: LanderVisual and Lander components are on the same GameObject

Destroyed together: when the lander explodes, the whole GameObject is disabled

Unity automatically cleans up these references when the object is destroyed

Cases where event unregistration is required

Where to unregister

Separating visual and logic

Polish

Review and Next Steps

【SOLID】SOLID Principles in Project Practice

Introduction of SOLID Principles

Spaghetti Code

What Are the SOLID Principles?

Single Responsibility Principle (SRP)

Core Idea

Benefits

Open/Closed Principle (OCP)

Core Idea

Benefits

How to Apply

Liskov Substitution Principle (LSP)

Core Idea

Benefits

How to Apply

Interface Segregation Principle (ISP)

Core Idea

Summary

Dependency Inversion Principle (DIP)

Core Idea

Summary

How to Apply

Practice Project

Game / Feature Breakdown

Content

Logic

Module Organization

Development Steps

Feature Implementation and Principles Followed

1. Tank Movement

2. Tank Firing

3. Tank Selector Implementation

`Time.deltaTime` and `Time.fixedDeltaTime`

Using `deltaTime` in `Update()`

Using `Time.fixedDeltaTime` in `FixedUpdate()`

`EventHandler`

Create an empty GameObject named `CinemachineCamera2D` and attach the custom zoom script to it

Event Bus System — `GameEvents`

Interface-Driven Damage System — `IDamageable`

6. When to Call `GetComponent`

11. When to Use `OnTrigger` vs. `OnCollision`

3. `MoveController`

4. `DestroyByTime`

5. `AudioManager`