C++ on Nullshow's Tech Blog

【C++ Syntax】Smart Pointer

Fri, 17 Oct 2025 20:42:14 +0200

Table of Contents

Reference Resource: BiteTech C++ Course

Why Do We Need Smart Pointers?

Let’s start with an example:

int div()
{
    int a, b;
    cin >> a >> b;
    if (b == 0)
        throw invalid_argument("Error: Divident is 0");

    return a / b;
}

void func()
{
    int* p = new int();
    cout << div() << endl;
    delete p;
}

int main()
{
    // Catching Exceptions
    try
    {
        func();
    }
    catch(exception& e)
    {
        cout << e.what() << endl;
    }
    return 0;
}

Since the div function may throw an exception, the normal execution flow of the program can be interrupted. As a result, div might not complete, and the pointer p won’t be released. Typically, exceptions are caught at the outermost level, but in this case—without using smart pointers—you would have to add another try-catch block inside func to ensure that p gets properly deleted and memory isn’t leaked.

int div()
{
    int a, b;
    cin >> a >> b;
    if (b == 0)
        throw invalid_argument("Error: Divident is 0");

    return a / b;
}

void func()
{
    int* p = new int();
    try	// Add exception handling in func to ensure p is properly released
    {
        cout << div() << endl;
    }
    catch (exception& e)	// Alternatively, catch all exceptions using: catch (...)
    {
        delete p;
        p = nullptr;
        throw e;
    }
    
    delete p;
    p = nullptr;
}

int main()
{
    // Catching Exceptions
    try
    {
        func();
    }
    catch(exception& e)
    {
        cout << e.what() << endl;
    }
    return 0;
}

When working with code that involves multiple raw pointers, preventing memory leaks often requires adding nested layers of exception-handling logic. To address this complexity in a cleaner and more elegant way, seasoned developers came up with a better solution: smart pointers.

Fundamental Principles of Smart Pointers

The implementation principle of smart pointers is quite straightforward: store the raw pointer in the constructor, and release it in the destructor.

template<class T>
class SmartPtr
{
public:
    SmartPtr(T* ptr)
        :_ptr(ptr)
    {}     
    
    ~SmartPtr()
    {
        if (_ptr)
        {
             delete _ptr;
            _ptr = nullptr;
        }
    }
    
private:
    T*_ptr;
};

So, the messy and exception-sensitive code above can be simplified by using smart pointers:

int div()
{
    int a, b;
    cin >> a >> b;
    if (b == 0)
        throw invalid_argument("Error: Divident is 0");

    return a / b;
}

void func()
{
    int* p = new int();
   
    // No need for exception handling—use smart pointers instead
    SmartPtr<int> sp(p);
    cout << div() << endl;
}

int main()
{
    // Catching Exceptions
    try
    {
        func();
    }
    catch(exception& e)
    {
        cout << e.what() << endl;
    }
    return 0;
}

Regardless of whether an exception is thrown, the pointer p will be properly released. This is because the SmartPtr object’s lifecycle ensures that the resource is cleaned up even if the function exits prematurely due to an exception. In short, SmartPtr takes care of resource management for us. Whether the function completes normally or is interrupted by an exception, the sp object will go out of scope, triggering its destructor and releasing the memory held by p. Essentially, we are delegating resource ownership to the smart pointer, which stores the resource in its constructor and releases it in its destructor.

RAII

RAII (Resource Acquisition Is Initialization) is a technique that uses object lifetimes to manage program resources such as memory, file handles, network connections, mutexes, and more.

In other words, a resource is acquired during object construction, remains valid throughout the object’s lifetime, and is released when the object is destroyed. This approach effectively delegates resource management to an object.

RAII offers two major benefits:

No need to manually release resources
Resources remain valid throughout the object’s lifetime

This technique indirectly addresses the lack of a garbage collection mechanism in C++.

RAII is a resource management paradigm. In addition to smart pointers, constructs like unique_lock and lock_guard are also built upon this idea.

Smart pointers are designed as RAII-based classes.

Using Smart Pointers Effectively

The SmartPtr implementation above can’t yet be considered a true smart pointer, because it doesn’t behave like a regular pointer. To make it functionally complete, we need to add some code that enables standard pointer operations.

template<class T>
class SmartPtr 
{
public:
	SmartPtr(T* ptr = nullptr)
		: _ptr(ptr)
	{}
	~SmartPtr()
	{
		if(_ptr)
        {
            delete _ptr;
            _ptr = nullptr;
        }	
	}
    
    // Overload operators & and * to give SmartPtr pointer-like behavior
	T& operator*() {return *_ptr;}
	T* operator->() {return _ptr;}
    
private:
	T* _ptr;
};

Potential Pitfalls of Smart Pointers

Let’s start with an example:

int main()
{
    SmartPtr<int> sp1(new int());
    SmartPtr<int> sp2 = sp1;
    
    return 0;
}

Here, both sp1 and sp2 point to the same memory location. When the program exits, both objects invoke their destructors, resulting in the same resource being deleted twice—a classic case of double deletion.

To address this issue, smart pointers evolved into three distinct strategies:

Ownership transfer: auto_ptr
Copy prevention: unique_ptr
Shared ownership via reference counting: shared_ptr
- Which can lead to circular references, resolved by introducing weak_ptr

`auto_ptr`

Overall, auto_ptr is considered a flawed design. It breaks the intuitive behavior of pointers, and many companies explicitly forbid its use.

How `auto_ptr` Works

// C++98 ownership transfer with auto_ptr
namespace my_smart_pointer
{
    template<class T>
    class auto_ptr
    {
    public:
    	auto_ptr(T* ptr)
   		 :_ptr(ptr)
    	{}
        
    	auto_ptr(auto_ptr<T>& sp)
    	:_ptr(sp._ptr)
    	{
            // Transfer ownership
            sp._ptr = nullptr;
        }
        
        auto_ptr<T>& operator=(auto_ptr<T>& ap)
        {
            // Check for self-assignment
            if (this != &ap)
            {
                // Release the resource held by this object
                if (_ptr)
                {
                    delete _ptr;
                    _ptr = nullptr;
                }        	
                
                // Transfer the resource from ap to this object
                _ptr = ap._ptr;
                ap._ptr = nullptr;
            }
            return *this;
        }
        
    	~auto_ptr()
        {
            if (_ptr)
            {
                cout << "delete:" << _ptr << endl;
                delete _ptr;
                _ptr = nullptr;
         	}
        }
        
        // Use like a regular pointer
        T& operator*()
        {
        	return *_ptr;
        }
        
        T* operator->()
        {
       		return _ptr;
        }
        
    private:
        T* _ptr;
    };
}

It may cause a null pointer error:

// main.cpp
int main()
{
    std::auto_ptr<int> sp1(new int());
    std::auto_ptr<int> sp2(sp1); // Ownership transfer

    // sp1 is dangling and can no longer be assigned
    //*sp1 = 10; 
    *sp2 = 10;
    cout << *sp2 << endl;
    cout << *sp1 << endl;
    return 0;
}

`unique_ptr`

A straightforward and aggressive solution is to simply prevent copying. This is the recommended approach, but it becomes unusable in scenarios where copying is actually required.

How `unique_ptr` Works

namespace my_smart_pointer
{
    template<class T>
    class unique_ptr
    {
    public:
        unique_ptr(T* ptr)
         :_ptr(ptr)
        {}
        ~unique_ptr()
        {
            if (_ptr)
            {
                cout << "delete:" << _ptr << endl;
                delete _ptr;
                _ptr = nullptr;
            }
        }

        T& operator*()
        {
            return *_ptr;
        }
        T* operator->()
        {
            return _ptr;
        }
        
        unique_ptr(const unique_ptr<T>& sp) = delete;
        unique_ptr<T>& operator=(const unique_ptr<T>& sp) = delete;
        
    private:
        T* _ptr;
    };
}

`shared_ptr`

Shared ownership among multiple shared_ptr instances is achieved through reference counting.

How `shared_ptr` Works

Four key points:

Internally, shared_ptr maintains a reference count for each resource to track how many objects share it.
When a shared_ptr is destroyed (i.e., its destructor is called), it signals that the object no longer uses the resource, and the reference count is decremented by one.
If the reference count reaches zero, it means this was the last owner of the resource, and the resource must be released.
If the reference count is not zero, it means other objects are still using the resource, so it must not be released—otherwise, they would be left with dangling pointers.

namespace my_smart_pointer
{
    template<class T>
    class shared_ptr
    {
    public:
        shared_ptr(T* ptr = nullptr)
            :_ptr(ptr)
            , _pRefCount(new int(1))
            {}

        shared_ptr(const shared_ptr<T>& sp)
            :_ptr(sp._ptr)
            , _pRefCount(sp._pRefCount)
            {
                ++(*_pRefCount);
            }
        
         ~shared_ptr()
        {
            Release();
        }

        shared_ptr<T>& operator=(const shared_ptr<T>& sp)
        {
            //if (this != &sp)
            if (_ptr != sp._ptr) 
            {
                Release();	// First release the resource previously managed by this object
                _ptr = sp._ptr;
                _pRefCount = sp._pRefCount;
                ++(*_pRefCount);
            }
            return *this;
        }
        
        void Release()
        {
            if (--(*_pRefCount) == 0 && _ptr)
            {
                cout << "delete:" << _ptr << endl;
                delete _ptr;
                _ptr = nullptr;
                 
                delete _pRefCount;
                _pRefCount = nullptr;
            }
        }
        
        T& operator*()
        {
            return *_ptr;
        }
        T* operator->()
        {
            return _ptr;
        }

    private:
        T* _ptr;
        int* _pRefCount;
    };
}

Thread Safety Issues with `shared_ptr` During Copy Assignment

Since the reference count is stored on the heap, problems can arise when two threads—say, t1 and t2—each hold a smart pointer and simultaneously perform copy assignment from the same shared_ptr instance sp. This can lead to both threads trying to increment or decrement the reference count at the same time, resulting in incorrect behavior.

Here’s a simplified illustration of the issue:

We can examine the thread safety of shared_ptr from two perspectives:

The reference count is shared among multiple shared_ptr instances. If two threads simultaneously increment or decrement the count (e.g., ++ or --), these operations are not atomic. For example, if the count starts at 1 and both threads increment it, the result might still be 2—leading to inconsistencies. This can cause resources to be leaked or prematurely destroyed, resulting in crashes. Therefore, reference count operations must be synchronized. In other words, shared_ptr ensures thread safety for reference counting.
The actual object managed by the smart pointer resides on the heap. If two threads access it concurrently, thread safety issues may arise depending on how the object itself is used.

Here’s the revised version of the code that addresses these concerns:

namespace my_smart_pointer
{
    template<class T>
    class shared_ptr
    {
    public:
        shared_ptr(T* ptr = nullptr)
            :_ptr(ptr)
        , _pRefCount(new int(1))
        , _pmtx(new mutex)
        {}

        shared_ptr(const shared_ptr<T>& sp)
        :_ptr(sp._ptr)
        , _pRefCount(sp._pRefCount)
        , _pmtx(sp._pmtx)
        {
            AddRef();
        }

        void Release()	// Decrementing the reference count requires lock protection
        {
            _pmtx->lock();
            bool flag = false;
            if (--(*_pRefCount) == 0 && _ptr)
            {
                cout << "delete:" << _ptr << endl;
                delete _ptr;
                _ptr = nullptr;
                
                delete _pRefCount;
                _pRefCount = nullptr;
                flag = true;
            }

            _pmtx->unlock();

            if (flag == true)	
            {
                delete _pmtx;
                _pmtx = nullptr;
            }    
        }

        void AddRef()	// Incrementing the reference count also requires lock protection
        {
            _pmtx->lock();
            ++(*_pRefCount);
            _pmtx->unlock();
        }

        shared_ptr<T>& operator=(const shared_ptr<T>& sp)
        {
            //if (this != &sp)
            if (_ptr != sp._ptr)
            {
                Release();

                _ptr = sp._ptr;
                _pRefCount = sp._pRefCount;
                _pmtx = sp._pmtx;
                AddRef();
            }
            return *this;
        }

        int use_count()
        {
            return *_pRefCount;
        }

        ~shared_ptr()
        {
            Release();
        }

        T& operator*()
        {
            return *_ptr;
        }
        T* operator->()
        {
            return _ptr;
        }
        T* get() const
        {
            return _ptr;
        }
    private:
        T* _ptr;
        int* _pRefCount;
        mutex* _pmtx;
    };
}

Smart pointer implementations in the C++ standard library are thread-safe by design.

Limitation of `shared_ptr`: Circular References

What Is a Circular Reference?

Let’s look at a typical scenario:

struct ListNode
{
    int _data;
    shared_ptr<ListNode> _prev;
    shared_ptr<ListNode> _next;
    ~ListNode(){ cout << "~ListNode()" << endl; }
};

int main()
{
    shared_ptr<ListNode> node1(new ListNode);
    shared_ptr<ListNode> node2(new ListNode);
    cout << node1.use_count() << endl;
    cout << node2.use_count() << endl;
   
    // Circular reference prevents resource from being released
    node1->_next = node2;
    node2->_prev = node1;
    
    cout << node1.use_count() << endl;
    cout << node2.use_count() << endl;
    return 0;
}

In this scenario, the following situation occurs:

node1 and node2 are two smart pointer objects pointing to two separate nodes. Their reference counts are both 1, so there’s no need to manually call delete.
node1’s _next points to node2, and node2’s _prev points back to node1. As a result, both reference counts become 2.
When node1 and node2 are destroyed, their reference counts drop to 1. However, node1 still holds _next, which points to node2, and node2 still holds _prev, which points to node1. In theory, if _next were destroyed, node2 would be released; if _prev were destroyed, node1 would be released.
But _next is a member of node1, and node1 is managed by node2’s _prev. _prev is a member of node2, which is managed by node1’s _next. This creates a circular reference, where each object indirectly keeps the other alive. As a result, neither object is ever released.

This is essentially a “chicken-and-egg” problem in memory management.

How to Solve It: `weak_ptr`

Strictly speaking, weak_ptr is not a smart pointer in the traditional sense, because it doesn’t follow the RAII (Resource Acquisition Is Initialization) principle. It behaves like a pointer, but it doesn’t manage or release resources. Instead, it was specifically designed to break circular references caused by shared_ptr.

Based on the earlier implementation of shared_ptr, a simplified version of weak_ptr might look like this (the actual implementation in the C++ standard library is much more complex):

namespace my_smart_pointer
{
    template<class T>
    class weak_ptr
    {
    public:
        weak_ptr()
        :_ptr(nullptr)
        {}

        weak_ptr(const shared_ptr<T>& sp)
        :_ptr(sp.get())
        {}

        weak_ptr<T>& operator=(const shared_ptr<T>& sp)
        {
            _ptr = sp.get();
            return *this;
        }

        T& operator*()
        {
            return *_ptr;
        }

        T* operator->()
        {
            return _ptr;
        }

    private:
        T* _ptr;
    };
}

So, in the previous example, we can refactor the code to use weak_ptr. This way, when we assign node1->_next = node2; and node2->_prev = node1;, the _next and _prev members—now implemented as weak_ptr—won’t increase the reference counts of node1 and node2. As a result, we avoid the circular reference problem entirely.

struct ListNode
{
    int _data;
    weak_ptr<ListNode> _prev;	// Replace shared_ptr with weak_ptr here to avoid circular reference
    weak_ptr<ListNode> _next;
    ~ListNode(){ cout << "~ListNode()" << endl; }
};

int main()
{
    shared_ptr<ListNode> node1(new ListNode);
    shared_ptr<ListNode> node2(new ListNode);
    cout << node1.use_count() << endl;
    cout << node2.use_count() << endl;
    node1->_next = node2;
    node2->_prev = node1;
    cout << node1.use_count() << endl;
    cout << node2.use_count() << endl;
    
	return 0;
}

Evolution of Smart Pointers in C++

C++ does not have a built-in garbage collection (GC) mechanism. This means that manually releasing allocated resources is a persistent challenge—especially when dealing with exception safety. A small oversight can easily lead to memory leaks. Such leaks gradually consume available memory, and since many operations in a program depend on memory, it’s crucial to avoid them as much as possible.

To address this, smart pointers were introduced based on the RAII (Resource Acquisition Is Initialization) principle.

Phase One:

C++98 introduced auto_ptr for the first time. However, its design had serious flaws and is no longer recommended for use.

Phase Two:

For the next decade, the C++ standard made little progress in this area. In response, a group of experts created an unofficial community project known as Boost, which included a wide range of utilities. Within Boost, they redesigned smart pointers:

scoped_ptr / scoped_array (non-copyable versions)
shared_ptr / shared_array (reference-counted versions)
weak_ptr (designed to solve circular reference issues)

scoped_ptr is intended for managing single objects allocated with new, and releases them using delete in its destructor.

scoped_array is for managing arrays allocated with new[], and releases them using delete[]. It also overloads the operator[] for array access.

Phase Three:

C++11 officially introduced smart pointers into the standard library, drawing inspiration from Boost’s implementation with some refinements. Features like rvalue references and move semantics in C++11 were also heavily influenced by Boost.

Custom Deleters

The official C++ standard library did not adopt the scoped_array and shared_array implementations from the Boost library. So how does it handle situations where multiple objects are allocated with new[]? We can solve this by writing a custom functor-based deleter.

// Functor-based custom deleter
template<class T>
struct FreeFunc 
{
    void operator()(T* ptr)
    {
        cout << "free:" << ptr << endl;
        free(ptr);
	}
};

template<class T>
struct DeleteArrayFunc 
{
    void operator()(T* ptr)
    {
        cout << "delete[]" << ptr << endl;
        delete[] ptr;
    }
};

int main()
{
    FreeFunc<int> freeFunc;
    std::shared_ptr<int> sp1((int*)malloc(4), freeFunc);
    DeleteArrayFunc<int> deleteArrayFunc;
    std::shared_ptr<int> sp2((int*)malloc(4), deleteArrayFunc);
    std::shared_ptr<A> sp4(new A[10], [](A* p){delete[] p; });

    std::shared_ptr<FILE> sp5(fopen("test.txt", "w"), [](FILE* p)
    	{
        	fclose(p); 
        });
    
    return 0;
}

Essentially, we pass a functor object to the smart pointer that defines how the resource should be released. Since the default deletion behavior in the C++ standard library’s smart pointers is delete for single objects, we can handle other cases—such as arrays or custom cleanup logic—by writing our own functor-based deleters.

Supplement 1: RAII in Practice – Lock Guards

Throwing exceptions can not only lead to memory leaks, but also cause deadlocks in certain scenarios. For example:

#include <mutex>

int div()
{
    int a, b;
    cin >> a >> b;
    if (b == 0)
        throw invalid_argument("Error: Divident is 0");

    return a / b;
}

void func()
{
    mutex mtx;
    
    mtx.lock();
    cout << div() << endl;	// If div throws an exception, the following unlock won't be executed — leading to a deadlock
	mtx.unlock();
}

int main()
{
    try
    {
        func();
    }
    catch(exception& e)
    {
        cout << e.what() << endl;
    }
    return 0;
}

By applying the RAII principle, we can encapsulate the locking and unlocking logic within a class constructor and destructor. This effectively solves the problem mentioned above.

template<class Lock>
class LockGuard
{
public:
    LockGuard(Lock& lock)
        :_lock(lock)
    {
        _lock.lock();	// Place the locking logic inside the constructor
    }
    
    ~LockGuard()
    {
        cout << "unlock" << endl;
        _lock.unlock();	// Place the unlocking logic inside the destructor
    }
    
    // Copying and assignment are not allowed
    LockGuard(LockGuard<Lock>&) = delete;
    LockGuard<Lock>& operator=(LockGuard<Lock>&) = delete;
    
private:
    Lock& _lock;	// Locks are non-copyable — this example uses a reference member to ensure the same lock is used
}

Apply the LockGuard class within the func function:

void func()
{
    mutex mtx;
    LockGuard<mutex> lock_guard(mtx);	// Use LockGuard to manage locking and unlocking automatically

    cout << div() << endl;	
}

Supplement 2: Understanding Memory Leaks

What Is a Memory Leak?

A memory leak occurs when a program fails to release memory or resources that are no longer in use—often due to negligence, coding errors, or poor exception safety. It doesn’t mean the memory physically disappears; rather, the application allocates a block of memory but, due to flawed design, loses control over it, resulting in wasted memory.

If the process terminates normally, the operating system will reclaim the memory. So in many cases, restarting the program can temporarily resolve the issue.

Why Memory Leaks Are Harmful

Memory leaks can have serious consequences for long-running programs—such as operating systems or backend services that cannot be restarted casually. Over time, leaks cause available memory to shrink, leading to slower response times, system freezes, or failures in operations that require memory (e.g., storing data in containers, opening files, creating sockets, sending data).

How to Prevent Memory Leaks

Be cautious when writing C/C++ code.
Use smart pointers to manage resources in complex or error-prone areas (preventive strategy).
If you suspect a memory leak, use diagnostic tools to detect and resolve it (reactive strategy).
- Recommended tool: Valgrind — a powerful memory analysis tool for Linux.

【C++ Game Dev from Scratch】Plant Star Brawl - Gameplay Layer

Sun, 12 Oct 2025 09:17:30 +0200

Table of Contents

This article dives into the implementation of the gameplay layer in detail and concludes with a link to the full project source code. If you’d like to revisit the overall project structure and framework design, check out the companion post: Plant Star Brawl - Framework Design.

Development Workflow - Gameplay Layer

Main Menu and Character Selection Screens
- Challenge 1: Where should the main camera be placed, given that the project uses a camera class?
  - Solution: Pass the camera as a parameter to rendering functions.
- Challenge 2: How can we give text a 3D or embossed effect?
  - Solution: Render the text twice—once in white at the original position, and once in gray slightly offset downward and to the right.
- Challenge 3: How can we create a scrolling silhouette effect on the selection screen background
  - Solution: Draw the same image twice with offset positions to simulate motion.
In-Game Scene Setup and Physics Simulation
- Challenge 1: How do we simulate gravity?
  - Solution: Gravity is represented by falling and stopping. Encapsulate platform logic in a dedicated class.
- Challenge 2: How can we visually inspect collision data?
  - Solution: Implement a simple debug mode to visualize hitboxes and physics boundaries.
- Issue 1: Why does the player sometimes teleport upward during a fall?
  - Solution: Use the player’s foot position from the previous frame to determine whether to correct their position in the current frame.
- Issue 2: How do we prevent repeated jumping (multi-jump bugs)?
  - Solution: Ensure the player can only jump when their vertical velocity is zero.
Bullet Base Class Implementation
- Core Gameplay Mechanic: Players deal damage using projectile-like bullets.
  - Solution: Create a base Bullet class, with specific bullet types inheriting from it.
- Challenge: How should bullets disappear after collision?
  - Solution: Use callback functions, similar to how death animations are handled for players.
- Bullet Deletion Optimization
Pea Bullet Subclass Implementation
Sun Bullet Subclass, Sun Bullet Ex Subclass Implementation
- Note: Adjust sprite offsets during explosion animations for accurate visual alignment.
Attack Skill System
- Use timers to track cooldown durations for special abilities
Invincibility Frames
- Solution: During certain animations, alternate between normal sprites and pure white silhouettes to indicate invulnerability.
Player Status Bar (Health and energy levels)
Particle System
Win/Loss Detection and Endgame Effects

Key Steps and Solutions - Gameplay Layer

Handling the Camera

Where should the main camera be placed?

Since this project includes a dedicated Camera class, each scene must be able to access the camera object during rendering to draw the game world relative to its position. There are three possible approaches:

Option 1:

Define the camera as a member variable inside each scene class. However, this makes it difficult to share camera data across scenes.

Option 2:

Define the camera as a global variable, similar to how image resources are handled. We could use the extern keyword to access it. But global variables tend to clutter the design and conflict with our goal of encapsulating data and minimizing global state.

Option 3:

Take inspiration from how delta (elapsed time) is passed into update functions like void on_update(int delta). We apply the same idea to rendering: pass the camera as a parameter using void on_draw(const Camera& camera).

Once the camera handling strategy is decided, here’s the full implementation of the main menu scene:

extern IMAGE img_menu_background;
extern SceneManager scene_manager;

class MenuScene : public Scene
{
public:
	MenuScene() = default;
	~MenuScene() = default;

	// Override necessary virtual functions from the base Scene class
	void on_enter()
	{
		mciSendString(_T("play bgm_menu repeat from 0"), NULL, 0, NULL);
	}
	void on_update(int delta)
	{
	
	}
	void on_draw(const Camera& camera)
	{
		putimage(0, 0, &img_menu_background);
	}
	void on_input(const ExMessage& msg)
	{
		if (msg.message == WM_KEYUP)
		{
			mciSendString(_T("play ui_confirm from 0"), NULL, 0, NULL);
			scene_manager.switch_to(SceneManager::SceneType::Selector);
		}
	}
	void on_exit()
	{

	}

private:

};

Implementing the Selector Scene

Character Type Design Tip

We start by defining an enumeration for the available player character types. Why include an “Invalid” character type? It acts as a safeguard to ensure that selection logic doesn’t go out of bounds. This helps prevent bugs when navigating the character list and makes the system more robust.

enum class PlayerType
{
    Peashooter = 0,
    Sunflower,
    Invalid
};

Example: Switching Player 1’s Character to the Left

To implement leftward character selection for Player 1, we follow a safe and bounded approach using the PlayerType enumeration:

Convert the current enum value to an int and subtract 1 This moves the selection one step to the left.
Add the int value of PlayerType::Invalid This ensures the result is non-negative, even if the original value was 0.
Take the result modulo PlayerType::Invalid This wraps the value around if it goes below the first valid type, keeping it within bounds.
Cast the final result back to PlayerType This gives us a valid enum value within the range [Peashooter, Invalid)—a half-open interval that excludes the Invalid sentinel.

This technique guarantees that the selected character type always stays within the valid range, and avoids out-of-bounds errors when navigating the character list.

case WM_KEYUP:
	switch (msg.vkcode)
	{
	case 0x41: // 'A'
		is_btn_1P_left_down = false;
		player_type_1 = (PlayerType)(((int)PlayerType::Invalid + (int)player_type_1 - 1) % (int)PlayerType::Invalid);
		mciSendString(_T("play ui_switch from 0"), NULL, 0, NULL);
		break;
     // ......
    }

Integrating the Camera into the `Animation` Class

Since every animation needs to access the camera’s position during rendering, and this logic is repeated across all animation draws, we apply object-oriented encapsulation to streamline it.

Instead of calculating world position - camera position externally, we move this logic into the Animation class itself. As a result, the on_draw method is updated to: void on_draw(const Camera& camera, int x, int y) const . This allows each animation to handle its own coordinate transformation internally, keeping rendering logic clean and consistent.

Implementing the Scrolling Silhouette Background Effect

A simple way to create a scrolling background is to render the same image twice. Imagine a vertical reference line moving from the left edge of the screen to the right. When it reaches the far edge, it jumps back to the start.

We draw one copy of the image to the left of the line, and another to the right. This creates a seamless scrolling loop.

Update Logic:

void on_update(int delta) 
{
	animation_peashooter.on_update(delta);
	animation_sunflower.on_update(delta);

	// Scroll background horizontally
	selector_background_scroll_offset_x += 5;
	if (selector_background_scroll_offset_x >= img_peashooter_selector_background_left.getwidth())
    {
        selector_background_scroll_offset_x = 0;
    }
}

To render cropped sections of an image with alpha blending, we overload putimage_alpha:

inline void putimage_alpha(int dst_x, int dst_y, int width, int height, IMAGE* img, int src_x, int src_y)
{
	int w = width > 0 ? width : img->getwidth();
	int h = height > 0 ? height : img->getheight();

	AlphaBlend(GetImageHDC(GetWorkingImage()), dst_x, dst_y, w, h,
		GetImageHDC(img), src_x, src_y, w, h, { AC_SRC_OVER, 0 , 255, AC_SRC_ALPHA });
}

We scroll Player 2’s silhouette across Player 1’s background, and vice versa:

void on_draw(const Camera& camera) 
{
	IMAGE* img_P1_selector_background = nullptr;
	IMAGE* img_P2_selector_background = nullptr;
	
	// Assign scrolling backgrounds based on opponent's character
	switch (player_type_2)
	{
	case PlayerType::Peashooter:
		img_P1_selector_background = &img_peashooter_selector_background_right;
		break;
	case PlayerType::Sunflower:
		img_P1_selector_background = &img_sunflower_selector_background_right;
		break;
	default:
		img_P1_selector_background = &img_peashooter_selector_background_right;
		break;
	}

	switch (player_type_1)
	{
	case PlayerType::Peashooter:
		img_P2_selector_background = &img_peashooter_selector_background_left;
		break;
	case PlayerType::Sunflower:
		img_P2_selector_background = &img_sunflower_selector_background_left;
		break;
	default:
		img_P2_selector_background = &img_peashooter_selector_background_left;
		break;
	}


	putimage(0, 0, &img_selector_background);  // Draw static background	

	// Draw dynamic scrolling silhouettes
	putimage_alpha(getwidth() - selector_background_scroll_offset_x, 0, img_P2_selector_background);
	putimage_alpha(getwidth() - img_P2_selector_background->getwidth(), 0, img_P2_selector_background->getwidth() - selector_background_scroll_offset_x,
		0, img_P2_selector_background, selector_background_scroll_offset_x, 0);
	putimage_alpha(selector_background_scroll_offset_x - img_P1_selector_background->getwidth(), 0, img_P1_selector_background);
	putimage_alpha(selector_background_scroll_offset_x, 0, img_P1_selector_background->getwidth() - selector_background_scroll_offset_x,
		0, img_P1_selector_background, 0, 0);

	putimage_alpha(pos_img_VS.x, pos_img_VS.y, &img_VS); // Draw "VS" graphic
    
    // ......
}

Physics Engine Implementation

Platform Class Design

We start by designing the platform collider based on its functional role. In most 2D platformer games, platforms are typically one-way colliders—players can land on them from above, but jump through them from below. This means we only need to determine where the player can “stand,” so we abstract the platform collider as a single horizontal line.

It’s important to note that while the platform’s position is stored in the collider structure, we still need to separately track its rendering position. This is because the platform image has thickness, and its top edge may not align with the collision line. Typically, the collision line is slightly above the visible top of the platform image, which better matches player expectations visually.

This design also aligns with our broader architectural principle of separating data logic from rendering. During collision detection, we only care about the CollisionShape data. During rendering, we only care about the image and its draw position. This reinforces decoupling and keeps the code clean.

To support debugging, we add a simple debug mode that draws the collision line when enabled. Here’s the full implementation of the Platform class:

extern bool is_debug;

class Platform
{
public: 
	struct CollisionShape // Describes the collider shape
	{
		float y; 
		float x_left;
		float x_right;
	};

public:
	CollisionShape shape;
	// Decoupled logic and rendering
	IMAGE* img = nullptr;
	POINT render_position = { 0 };

public:
	Platform() = default;
	~Platform() = default;

	void on_draw(const Camera& camera) const
	{
		putimage_alpha(camera, render_position.x, render_position.y, img);

		// Draw collision line if debug mode is enabled
		if (is_debug)
		{
			setlinecolor(RGB(255, 0, 0));
			line(camera, (int)shape.x_left, (int)shape.y, (int)shape.x_right, (int)shape.y);
		}
	}
		
private:

};

Player Base Class Design

All shared data and logic for players are encapsulated in a base Player class. Specific characters like Peashooter and Sunflower inherit from this base and implement their own behavior.

How are player objects instantiated?

Since there are two player types, the actual class to instantiate depends on the character selected during the character selection phase. This logic belongs in the selector scene, but the instantiated player objects are also needed in the gameplay scene. The simplest solution is to define them globally, just like other cross-scene resources.

Here’s how the instantiation logic looks in the selector scene:

// SelectorScene.h
class SelectorScene : public Scene
{
public:
    // ......
    void on_exit() 
    {
        // Instantiate player objects based on selected character types
        switch (player_type_1)
        {
        case PlayerType::Peashooter:
            player_1 = new PeashooterPlayer();
            break;
        case PlayerType::Sunflower:
            player_1 = new SunflowerPlayer();
            break;
        }

        switch (player_type_2)
        {
        case PlayerType::Peashooter:
            player_2 = new PeashooterPlayer();
            break;
        case PlayerType::Sunflower:
            player_2 = new SunflowerPlayer();
            break;
        }
    }
    // ......
}

In addition, each player needs to store their position in world coordinates using Vector2 position;. Animation definitions should also be included, with each subclass specifying which atlas to use for rendering.

Handling player input and mapping key events to gameplay logic should be implemented in the base class. To differentiate controls between Player 1 and Player 2, we assign a player index as a member variable. This allows input handling logic to branch based on the player’s identity.

One-Way Platform Collision and Gravity Simulation

Gravity Simulation

In a free-fall scenario, two key values govern motion: gravitational acceleration and the object’s current velocity. Throughout the simulation, objects in the scene are constantly pulled downward by gravity, accelerating vertically over time.

To model this, we define a gravity constant in the Player class: const float gravity = 1.6e-3f; . This value may seem arbitrary, but in game development, gravity is often tuned to suit the game world’s scale, visual proportions, and player feel. It doesn’t need to match real-world physics—it just needs to produce the right gameplay effect.

All physics-related logic is placed in the move_and_collide(int delta) method. Gravity simulation itself only requires two lines:

// Player.h
// ......
protected:
	void move_and_collide(int delta)
    {
		velocity.y += gravity * delta;
		position += velocity * (float)delta;
    }
// ......

One-Way Platform Collision Detection

To detect collisions between the player and platforms, we check for horizontal overlap between a rectangle (the player) and a line (the platform). Specifically:

Calculate the difference between the rightmost and leftmost edges of both shapes.
If this difference is less than the sum of their widths, they overlap horizontally.

Vertical collision is simpler: check whether the platform’s Y-coordinate lies between the player’s top and bottom edges. Only when both horizontal and vertical conditions are met do we consider a collision.

Position Correction Logic

Once a collision is detected, we need to adjust the player’s position so they land on the platform. However, naïvely snapping the player’s feet to the platform can cause visual glitches—especially when the player jumps upward and only partially intersects the platform before falling.

To fix this, we ensure that the player’s entire body has passed through the platform before snapping them onto it. We calculate the player’s foot position from the previous frame and only apply correction if it was above the platform.

Here’s the refined collision logic:

void move_and_collide(int delta)
{
    velocity.y += gravity * delta;
    position += velocity * (float)delta;

    // Collision detection
    if (velocity.y > 0)
    {
        for (const Platform& platform : platform_list)
        {
            const Platform::CollisionShape& shape = platform.shape;
            bool is_collide_x = (max(position.x + size.x, shape.x_right) - min(position.x, shape.x_left) <= size.x + (shape.x_right - shape.x_left));
            bool is_collide_y = (shape.y >= position.y && shape.y <= position.y + size.y);

            if (is_collide_x && is_collide_y)
            {
                //  Check previous frame’s foot position to avoid snapping mid-jump
                float delta_pos_y = velocity.y * delta;
                float last_tick_foot_pos_y = position.y + size.y - delta_pos_y;
                if (last_tick_foot_pos_y <= shape.y)
                {
                    position.y = shape.y - size.y;
                    velocity.y = 0;

                    break;
                }
            }
        }
    }
}

Character Skill System

Functional Requirements

This project features two playable characters: Peashooter and Sunflower. Each has a basic attack and a special skill.

Peashooter: Fires pea bullets in the direction they’re facing. Hitting the opponent builds energy. Once full, Peashooter unleashes a rapid burst of pea bullets as a special attack.
Sunflower: Throws sun bombs diagonally upward. These projectiles are affected by gravity, making them harder to aim but more rewarding. When energy is full, Sunflower summons a giant sun bomb above the opponent’s head, dealing massive area damage and granting high energy returns.

From a design perspective, both characters rely on projectile-based combat. This allows us to unify all projectile logic under a single base class: Bullet.

Each projectile type—pea bullet, sun bomb, super sun bomb—can inherit from Bullet and implement its own update and rendering logic. Differences like animation, damage radius, and behavior are handled in the subclasses.

Bullet Deactivation and Removal Logic

Just like how we handle player death animations in the Animation class, bullets should be marked as invalid immediately upon hitting an enemy. This prevents them from colliding multiple times in subsequent frames. However, since we want to play destruction animations—like the pea bullet shattering or the sun bomb exploding—we can’t remove the bullet object from the scene right away.

Instead, each bullet goes through three distinct states:

Active: The bullet is moving and checking for collisions.
Inactive: The bullet has collided and is playing its destruction animation. Collision checks are disabled.
Removable: The animation has finished, and the bullet can now be deleted from the scene.

This state logic is reflected in the bullet’s member variables:

// Bullet.h
protected:
	Vector2 size;						// Bullet collider size
	Vector2 position;					// Bullet position
	Vector2 velocity;					// Bullet velocity
	int damage = 10;					// Damage value

	bool valid = true;					// Whether the bullet is still active
	bool can_remove = false;			//  Whether the bullet can be deleted

	function<void()> callback;			// Collision callback

	PlayerID target_id = PlayerID::P1;	// Target player ID

Optimizing Bullet Removal

If bullets are only removed upon collision, those that miss will remain in memory indefinitely—leading to memory leaks. To prevent this, we also check whether a bullet has moved off-screen. This logic is common to all bullet types, so we define a helper method in the base class:

bool check_if_exceeds_screen()
{
    return (position.x + size.x <= 0 || position.x >= getwidth()
        || position.y + size.y <= 0 || position.y >= getheight());
}

Full Bullet Base Class

extern bool is_debug;

// Bullet Base Class
class Bullet
{
public:
	Bullet() = default;
	~Bullet() = default;

	virtual void on_collide()
	{
		if (callback)
			callback();
	}

	virtual bool check_collision(const Vector2& position, const Vector2& size)
	{
         // Check if bullet center is inside the target's bounding box
		return this->position.x + this->size.x / 2 >= position.x
			&& this->position.x + this->size.x / 2 <= position.x + size.x
			&& this->position.y + this->size.y / 2 >= position.y
			&& this->position.y + this->size.y / 2 <= position.y + size.y;
	}

	virtual void on_update(int delta)
	{

	}

	virtual void on_draw(const Camera& camera) const
	{
		if (is_debug)
		{
			setfillcolor(RGB(255, 255, 255));
			setlinecolor(RGB(255, 255, 255));
			rectangle((int)position.x, (int)position.y,
				(int)(position.x + size.x), (int)(position.y + size.y));
			solidcircle((int)(position.x + size.x / 2), (int)(position.y + size.y / 2), 5);
		}
	}

     // Setters and getters
	void set_damage(int val)
	{
		damage = val;
	}

	int get_damage()
	{
		return damage;
	}

	void set_position(float x, float y)
	{
		position.x = x;
		position.y = y;
	}

	const Vector2& get_position() const
	{
		return position;
	}

	const Vector2& get_size() const
	{
		return size;
	}

	void set_velocity(float x, float y)
	{
		velocity.x = x;
		velocity.y = y;
	}

	void set_collide_target(PlayerID target)
	{
		target_id = target;
	}

	PlayerID get_collide_target() const
	{
		return target_id;
	}

	void set_callback(function<void()> callback)
	{
		this->callback = callback;
	}

	void set_valid(bool flag)
	{
		valid = flag;
	}

	bool get_valid() const
	{
		return valid;
	}

	bool check_can_remove() const
	{
		return can_remove;
	}

protected:
	bool check_if_exceeds_screen()
	{
		return (position.x + size.x <= 0 || position.x >= getwidth()
			|| position.y + size.y <= 0 || position.y >= getheight());
	}

protected:
	Vector2 size;						
	Vector2 position;
	Vector2 velocity;
	int damage = 10;					

	bool valid = true;				
	bool can_remove = false;			

	function<void()> callback;		

	PlayerID target_id = PlayerID::P1;	
};

Note:

In practice, it’s rare to design a game object class completely top-down from the start. Class design is often an iterative process—built and refined as the project evolves. We typically start with a rough structure and improve it through trial, error, and usage. Top-down design requires experience and foresight, but with continued practice, you’ll become more comfortable and confident in applying this approach.

Pea Bullet Class Design

The Peashooter character fires only one type of bullet. The difference between normal and special attacks lies in the firing rate. To make the game feel more dynamic, we use three different sound effects and randomly play one when a pea bullet hits its target. This technique is common in game development—for example, footsteps or gunshots often use varied audio clips to make the experience feel more natural and lively.

To implement this, we override the on_collide method in the PeaBullet subclass and add randomized sound playback. Importantly, when overriding a method but still needing to execute the base class logic, we must explicitly call the parent method.

Here’s the complete implementation of the PeaBullet subclass:

// PeaBullet.h

extern IMAGE img_pea;
extern Atlas atlas_pea_break;

class PeaBullet : public Bullet
{
public:
	PeaBullet()
	{
		size.x = 64, size.y = 64;	// Set bullet size

		damage = 10;

		animation_break.set_atlas(&atlas_pea_break);
		animation_break.set_interval(100);
		animation_break.set_loop(false);
		animation_break.set_callback([&]() { can_remove = true; });
	}

	~PeaBullet() = default;

	void on_update(int delta)
	{
		position += velocity * (float)delta;	 // Move bullet

		if (!valid)
			animation_break.on_update(delta);	// Play destruction animation

		if (check_if_exceeds_screen())
			can_remove = true;
	}

	void on_draw(const Camera& camera) const
	{
		if (valid)
			putimage_alpha(camera, (int)position.x, (int)position.y, &img_pea);
		else
			animation_break.on_draw(camera, (int)position.x, (int)position.y);

		Bullet::on_draw(camera);

	}

	void on_collide()
	{
		Bullet::on_collide();	// Call base class logic

		switch (rand() % 3)
		{
		case 0:
			mciSendString(_T("play pea_break_1 from 0"), NULL, 0, NULL);
			break;
		case 1:
			mciSendString(_T("play pea_break_2 from 0"), NULL, 0, NULL);
			break;
		case 3:
			mciSendString(_T("play pea_break_3 from 0"), NULL, 0, NULL);
			break;
		}
	}

private:
	Animation animation_break;	// Destruction animation
};

Building on the Bullet base class, the PeaBullet subclass only needs to extend a few unique behaviors to deliver a complete projectile implementation. This elegantly demonstrates the power of inheritance in object-oriented design: shared logic lives in the base class, while specialized behavior is layered on top with minimal duplication. It’s a clean, maintainable approach that scales well as new projectile types are introduced.

Sun Bullet Class Implementation

One important detail when implementing the sun bomb is that its explosion animation frames are slightly larger than its idle animation frames. To ensure the explosion renders correctly, we need to align the centers of both animation rectangles. Since EasyX uses the top-left corner as the origin for rendering, we apply a small positional offset during the explosion animation to visually center it.

Unlike the pea bullet, which continues flying after impact to simulate a splash effect, the sun bomb should remain stationary once it explodes. It’s affected by gravity while active, but its explosion animation plays in place.

Here’s the full implementation of the SunBullet class:

// SunBullet.h

extern Atlas atlas_sun;
extern Atlas atlas_sun_explode;

extern Camera main_camera;

class SunBullet : public Bullet
{
public:
	SunBullet()
	{
		size.x = 96, size.y = 96;
		
		damage = 20;

		animation_idle.set_atlas(&atlas_sun);
		animation_idle.set_interval(50);

		animation_explode.set_atlas(&atlas_sun_explode);
		animation_explode.set_interval(50);
		animation_explode.set_loop(false);
		animation_explode.set_callback([&]() { can_remove = true; });

		//  Calculate offset to center explosion animation
		IMAGE* frame_idle = animation_idle.get_frame();
		IMAGE* frame_explode = animation_explode.get_frame();
		explode_render_offset.x = (frame_idle->getwidth() - frame_explode->getwidth()) / 2.0f;
		explode_render_offset.y = (frame_idle->getheight() - frame_explode->getheight()) / 2.0f;
		
	}

	~SunBullet() = default;

	void on_update(int delta)
	{
		if (valid)
		{
			velocity.y += gravity * delta;
			position += velocity * (float)delta;
		}

		if (!valid)
			animation_explode.on_update(delta);
		else
			animation_idle.on_update(delta);

		if (check_if_exceeds_screen())
			can_remove = true;
	}

	void on_draw(const Camera& camera) const
	{
		if (valid)
			animation_idle.on_draw(camera, (int)position.x, (int)position.y);
		else
		{
			animation_explode.on_draw(camera, (int)(position.x + explode_render_offset.x),
				(int)(position.y + explode_render_offset.y));
		}

		Bullet::on_draw(camera);
	}

	void on_collide()
	{
		Bullet::on_collide();

		main_camera.shake(5, 250);	// Camera shake effect

		mciSendString(_T("play sun_explode from 0"), NULL, 0, NULL);
	}

private:
	const float gravity = 1e-3f;	

private:
	Animation animation_idle;		
	Animation animation_explode;	
	Vector2 explode_render_offset;	
};

Sun Bullet Ex Class Implementation

Sunflower’s special skill summons a massive sun bomb from off-screen. Unlike the standard sun bomb, this projectile is larger, stronger, and unaffected by gravity. It descends slowly, acting as a zoning tool to restrict enemy movement and make smaller bombs easier to land.

To give it a broader hitbox, we override the check_collision method to use rectangle-based collision detection instead of a single center point.

Here’s the full implementation of the SunBulletEx class:

// SunBulletEx.h
extern Atlas atlas_sun_ex;
extern Atlas atlas_sun_ex_explode;

extern Camera main_camera;

class SunBulletEx : public Bullet
{
public:
	SunBulletEx()
	{
		size.x = 288, size.y = 288;

		damage = 20;

		animation_idle.set_atlas(&atlas_sun_ex);
		animation_idle.set_interval(50);

		animation_explode.set_atlas(&atlas_sun_ex_explode);
		animation_explode.set_interval(50);
		animation_explode.set_loop(false);
		animation_explode.set_callback([&]() { can_remove = true; });

		// Calculate offset to center explosion animation
		IMAGE* frame_idle = animation_idle.get_frame();
		IMAGE* frame_explode = animation_explode.get_frame();
		explode_render_offset.x = (frame_idle->getwidth() - frame_explode->getwidth()) / 2.0f;
		explode_render_offset.y = (frame_idle->getheight() - frame_explode->getheight()) / 2.0f;
	}

	~SunBulletEx() = default;

	void on_update(int delta)
	{
		if (valid)
		{
			position += velocity * (float)delta;
		}

		if (!valid)
			animation_explode.on_update(delta);
		else
			animation_idle.on_update(delta);

		if (check_if_exceeds_screen())
			can_remove = true;
	}

	void on_draw(const Camera& camera) const
	{
		if (valid)
			animation_idle.on_draw(camera, (int)position.x, (int)position.y);
		else
		{
			animation_explode.on_draw(camera, (int)(position.x + explode_render_offset.x),
				(int)(position.y + explode_render_offset.y));
		}

		Bullet::on_draw(camera);
	}

	void on_collide()
	{
		Bullet::on_collide();

		main_camera.shake(20, 350);	
		mciSendString(_T("play sun_explode_ex from 0"), NULL, 0, NULL);
	}

	bool check_collision(const Vector2& position, const Vector2& size)
	{
		bool is_collide_x = (max(this->position.x + this->size.x, position.x + size.x)
			- min(this->position.x, position.x) <= this->size.x + size.x);
		bool is_collide_y = (max(this->position.y + this->size.y, position.y + size.y)
			- min(this->position.y, position.y) <= this->size.y + size.y);

		return is_collide_x && is_collide_y;
	}

private:
	Animation animation_idle;
	Animation animation_explode;
	Vector2 explode_render_offset;
};

From a design perspective, the super sun bomb could inherit from the standard sun bomb to reduce duplication. However, this project opts for a flatter inheritance structure to keep the codebase easier to read and maintain.

Skill System

To implement character skills, we define two virtual methods in the Player base class: virtual void on_attack and virtual void on_attack_ex. Each player subclass overrides these methods to implement its own normal and special attack logic. This keeps the skill system extensible and cleanly separated across character types.

Attack Cooldown Implementation

Most characters in action games have a cooldown period between normal attacks. During this time, pressing the attack key has no effect. To implement this, we define a boolean flag can_attack to indicate whether the character is currently allowed to perform a normal attack. We also use a timer to track the cooldown duration, represented by an int value in milliseconds.

The logic is simple:

When an attack input is received, check if can_attack is true.
If so, flip the flag to false and start the cooldown timer.
Once the timer completes, reset can_attack to true.

This ensures that attacks can only be triggered after the cooldown period has passed.

Invulnerability State Implementation

To implement temporary invincibility (often triggered after taking damage), we use two boolean flags:

bool is_invulnerable = false; — indicates whether the character is currently invincible.
bool is_showing_sketch_frame = false; — controls whether the character should render as a white silhouette for visual feedback.

We use two timers to manage the invulnerability logic:

timer_invulnerable — controls the duration of invincibility.
timer_invulnerable_blink — toggles between normal and sketch-frame rendering to create a blinking effect.

Here’s how these timers are initialized in the Player constructor:

// Player.h
Player()
{
	current_animation = is_facing_right;

	// Initialize attack cooldown timer
	timer_attack_cd.set_wait_time(attack_cd);
	timer_attack_cd.set_one_shot(true);
	timer_attack_cd.set_callback([&]()
		{
			can_attack = true;
		});

	// Initialize invulnerability timer
	timer_invulnerable.set_wait_time(750);
	timer_invulnerable.set_one_shot(true);
	timer_invulnerable.set_callback([&]()
		{
			is_invulnerable = false;
			is_showing_sketch_frame = false; // Ensure sketch frame is disabled when invulnerability ends
    });
		});

	// Initialize blink timer for invulnerability animation
	timer_invulnerable_blink.set_wait_time(75);
	timer_invulnerable_blink.set_callback([&]()
		{
			is_showing_sketch_frame = !is_showing_sketch_frame;
		});
	
    // ......
}

To render the character as a white silhouette during invulnerability, we add a utility function in Util.h. This function processes the image’s pixel buffer and sets all pixels to white. For a detailed explanation, refer to the bonus section of the article Teyvat Survivors.

// Util.h
inline void sketch_image(IMAGE* src, IMAGE* dst)
{
	int w = src->getwidth();
	int h = src->getheight();

	Resize(dst, w, h);
	DWORD* src_buffer = GetImageBuffer(src);
	DWORD* dst_buffer = GetImageBuffer(dst);
	for (int y = 0; y < h; y++)
	{
		for (int x = 0; x < w; x++)
		{
			int idx = y * w + x;
			dst_buffer[idx] = BGR(RGB(255, 255, 255)) | (src_buffer[idx] & 0xFF000000);
		}
	}
}

In the on_update method, we update all timers accordingly.

// Player.h
virtual void on_update(int delta)
{
    // ......
    
    // Whether to render the sketch (silhouette) image
	// Only generate the sketch frame when the player is invulnerable and blinking
	if (is_showing_sketch_frame)
		sketch_image(current_animation->get_frame(), &img_sketch);
    
    // ......
}

We apply the sketch rendering logic inside the on_draw method:

// Player.h
virtual void on_draw(const Camera& camera)
{
    // ......
    if (hp > 0 && is_invulnerable && is_showing_sketch_frame)
		putimage_alpha(camera, (int)position.x, (int)position.y, &img_sketch);
	else
		current_animation->on_draw(camera, (int)position.x, (int)position.y);
    
    // ......
}

To activate invulnerability after taking damage, we add a dedicated method to the Player class:

// Player.h
void make_invulnerable()
{
    is_invulnerable = true;
    timer_invulnerable.restart();

    is_showing_sketch_frame = true;    // Immediately enter sketch frame mode
    timer_invulnerable_blink.restart(); // Start blinking effect
}

Then, inside the move_and_collide method, we update the bullet collision logic to trigger invulnerability when the player is hit:

// Player.h
void move_and_collide(int delta)
{

    // ......
        
    if(!is_invulnerable)
	{
		for (Bullet* bullet : bullet_list)
		{
			if (!bullet->get_valid() || bullet->get_collide_target() != id)
				continue;

			if (bullet->check_collision(position, size))
			{
				make_invulnerable();		// Activate invulnerability

				bullet->on_collide();
				bullet->set_valid(false);
				hp -= bullet->get_damage();

			// ......
		}
	}
    // ......
}

Particle System Implementation

A particle system is a technique that uses large numbers of small graphical elements (particles) to simulate complex visual effects like smoke, fire, rain, or explosions. When designing a particle system, we typically break it down into two components:

Particle objects: Represent individual particles, each with properties like animation, physics, and lifespan.
Particle emitters: Control how particles are generated—frequency, direction, initial velocity, etc.

In this project, we implement a lightweight particle system. Each particle behaves like a specialized animated object. Unlike characters or bullets, particles remain fixed in world space once emitted. After their animation finishes, they expire and are removed from the scene.

Here’s the complete Particle class:

class Particle
{
public:
	Particle() = default;

	Particle(const Vector2& position, Atlas* atlas, int lifespan)
		: position(position), atlas(atlas), lifespan(lifespan)
	{ }

	~Particle() = default;

	void on_update(int delta)
	{
		timer += delta;
		if (timer >= lifespan)
		{
			timer = 0;
			idx_frame++;
			if (idx_frame >= atlas->get_size())
			{
				idx_frame = atlas->get_size() - 1;
				valid = false;
			}
		}
	}

	void on_draw(const Camera& camera) const
	{
		putimage_alpha(camera, (int)position.x, (int)position.y, atlas->get_image(idx_frame));
	}

	void set_atlas(Atlas* new_atlas)
	{
		atlas = new_atlas;
	}

	void set_position(const Vector2& new_position)
	{
		position = new_position;
	}

	void set_lifespan(int ms)
	{
		lifespan = ms;
	}

	bool check_valid() const
	{
		return valid;
	}

private:
	int timer = 0;			// Frame timer
	int lifespan = 0;		// Duration per frame in milliseconds
	int idx_frame = 0;		// Current animation frame index
	Vector2 position;		// World-space position
	bool valid = true;		// Whether the particle is still active
	Atlas* atlas = nullptr;	// Animation atlas
};

Overall Code Review and Source Code

Scene Base Class

This project introduces the concept of scene management for the first time. Each stage or interface in the game corresponds to a distinct scene. In the base class Scene.h, the on_enter and on_exit methods handle scene initialization and teardown respectively. The on_input, on_update, and on_draw methods correspond to the input, update, and rendering phases of the main loop, each receiving the necessary parameters. Subclasses only need to override these methods to implement their own logic.

The scene manager controls which scene is currently active. When switching scenes, we use an enum to abstract away direct scene pointers. The manager itself also exposes on_input, on_update, and on_draw methods that delegate to the current scene instance.

Main Function

In main.cpp, we implement two core responsibilities: resource loading and game entry point. First, we load pixel fonts and animation assets, including mirrored versions for directional rendering. Then we load background music and sound effects. In the entry function, we initialize resources, instantiate the initial scene, and invoke the scene manager’s lifecycle methods within the main game loop.

Atlas Class

For animation handling, we encapsulate an Atlas class that acts as a container for loading and storing image sequences. The Animation class is a lightweight manager that tracks playback progress. It doesn’t store image data directly—instead, it queries the atlas for the current frame. The animation class also handles frame intervals, looping, and end-of-playback callbacks.

Camera Class

Rendering uses a custom Camera class that serves as an anchor for relative positioning. By randomly jittering the camera’s position within a small range, we simulate a screen shake effect. To simplify camera-based rendering, we overload utility functions in Util.h for alpha blending, image flipping, and generating white silhouette effects.

Timer and Vector2 Classes

Two foundational utility classes support the framework: Timer and Vector2. The Timer class tracks elapsed time and triggers callbacks when a preset duration is reached. The Vector2 class handles 2D vector math, including overloaded arithmetic operators, length calculation, and normalization.

Scene Subclasses: MenuScene, SelectorScene, GameScene

The game starts in the menu scene, which simply plays music and handles scene transitions. The character selection scene uses hardcoded layout logic to render UI elements, dynamically draws character previews based on player choices, and handles input for both players using separate key mappings. Upon exiting the selection scene, we instantiate the chosen characters and assign their avatars and player IDs, which are defined in PlayerID.h.

The in-game scene handles three main areas:

World elements like background and platforms
Player-related elements like characters and bullets
Game state elements like health tracking and victory conditions

Debug mode toggling is also managed within the game scene.

Player Base Class

The Player base class encapsulates shared logic for all characters. Visually, players have animations for idle, running, attacking, and dying, along with particle effects for jumping, landing, and running. Logically, normal and special attacks are controlled via cooldown timers and energy values. Movement actions like jumping and landing are wrapped in dedicated methods for easy triggering and animation updates.

Damage triggers a brief invulnerability period with a blinking visual effect, managed by timers. Physics simulation is handled in the move_and_collide method, which updates position based on gravity and velocity, and performs collision checks with platforms and bullets.

Peashooter and Sunflower Subclasses

With the base class in place, implementing the Peashooter is straightforward—just configure its animations and define bullet spawning logic. We also use randomized sound effects to enhance feedback.

Sunflower follows a similar pattern, but its special attack includes an extra “sun” animation above the character’s head, requiring a custom rendering override.

Bullet Base Class

Bullets are abstracted via the Bullet base class. Like players, bullets move through the scene and may be affected by gravity. We track velocity and update position accordingly. Bullets also store damage values, target IDs, and collision callbacks.

PeaBullet, SunBullet, and SunBulletEx Subclasses

The PeaBullet subclass overrides the collision method to play randomized sound effects and switches rendering logic based on whether the bullet has shattered. The SunBullet simulates gravity until impact, then plays an explosion animation with center alignment adjustments. The SunBulletEx is larger and stronger, descending at a constant speed rather than accelerating under gravity.

Particle Class

Particles are treated as lightweight animated objects. Once their animation finishes, they expire and are removed from the scene. Their update logic closely resembles that of the Animation class.

Platform Class

Platforms are represented as horizontal lines in world space. For rendering, we use image assets and optionally draw debug overlays depending on the debug mode.

StatusBar Class

Each player’s status bar consists of three components: avatar, health bar, and energy bar. During gameplay, we continuously read these values from the player object and render them in the UI.

With that, this project’s notes are complete.

Full Source Code

on GitHub

Reflection and Summary

This was my first time studying how a complete game project is designed from the top down. At the beginning, the framework felt abstract and hard to grasp—especially without something like the gameplay layer to test things frequently and intuitively. I often felt unsure of whether I was on the right track. But once the foundational structure was in place, building out the gameplay layer became a smooth and satisfying process. Everything started to click into place.

Even with the experience I gained from the previous Teyvat Survivor project, this one was filled with intricate implementation details. A single oversight could easily lead to unexpected bugs. Some of the design ideas would have been difficult—or even impossible—for me to come up with on my own without falling into common pitfalls. Thankfully, the instructor’s explanations were clear, and the code was clean and easy to follow, which made the learning process much more approachable.

This project made me realize once again where I currently stand in my programming journey: just when I feel like I’ve understood something, I discover how much more there is that I don’t know. And that’s okay. It’s a reminder to keep sharpening my skills and stay committed to continuous learning.

【C++ Game Dev from Scratch】Plant Star Brawl - Framework Design

Sat, 11 Oct 2025 09:47:30 +0200

Table of Contents

This project spans over 2,000 lines of code and covers a wide range of concepts, so I’ve split the write-up into two parts. This first post provides an overview of the entire project, with a focus on the design and implementation of the framework-related components.

Overview

Tech Stack: C++ + EasyX

Project Goal: The project is organized using multiple header files, with a modular structure that introduces the concept of “scenes” to separate different stages of gameplay and decouple core functionalities. It explores basic physics simulation techniques and implements one-way collision platforms. Popular game development features like the camera, timer, and particle system are encapsulated to enhance the project’s level of polish and professionalism. Additionally, smoother animations and richer sound effects are integrated to improve the overall completeness of the game.

Course Source：Bilibili-Voidmatrix

Core Gameplay

Two players can choose different characters for local multiplayer battles. They jump and move between platforms, using a variety of normal and special attacks to damage their opponent and earn energy rewards. Once enough energy is accumulated, players can unleash unique skills. A player is defeated either by falling off the platform or when their health reaches zero.

Design Approach

Using Multiple Header Files

As the project grows in size, keeping all the code in main.cpp quickly becomes unwieldy. It leads to messy namespaces and tangled dependencies, making debugging and maintenance difficult. To manage complexity, this project organizes code by encapsulating different game stages into separate classes, each placed in its own header file.

Common Pitfall – Duplicate Includes：

When we use #include to bring in a header file, the compiler performs a literal copy-paste of that file’s contents at the include location. For example, if A.h includes B.h, and main.cpp includes both A.h and B.h, then B.h ends up being included twice. If B.h contains class definitions or other declarations, this can lead to duplicate definitions and compilation errors.

How to Avoid This：

Use the preprocessor directive #pragma once: This tells the compiler to include the contents of a header file only once, no matter how many times it’s referenced.
Alternatively, use include guards with #ifndef: This checks whether a macro (usually based on the filename) has already been defined. If not, it defines the macro and includes the file; otherwise, it skips it.

Example syntax:
1 2 3 4

#ifndef _SCENE_H_ #define _SCENE_H_ #endlif // !_SCENE_H_

Both methods are widely used and generally interchangeable in most cases.

Differences Between the Two Approaches：

Feature	`#ifndef` / `#define`	`#pragma once`
Compatibility	Supported by all standard C/C++ compilers	Supported by most modern compilers, but not standardized
Mechanism	Uses macro definitions to check for duplicates	Compiler internally tracks whether the file has been processed
Filename Dependency	Independent of file name; relies on macro name	Depends on file path; may be affected by hard or symbolic links
Conflict Risk	Macro names must be unique; naming conflicts may cause issues	No naming required; avoids conflicts
Compilation Speed	Slightly slower (macro parsing required)	Faster (direct skip on repeat includes)

Designing the Game Framework

Creating the window, setting up the main game loop, and stabilizing the frame rate—this structure is essentially a standard pattern in game development frameworks:

int main()
{
    //========= Initialize data ==========
	initgraph(1280, 720);
	
    bool is_running = true;
    const int FPS = 60;
	
	ExMessage msg;
	
	BeginBatchDraw();
   
	while (is_running)	// Main game loop
	{
		DWORD start_time = GetTickCount();
        
        //========= Handle input =========
		while (peekmessage(&msg))
		{
			
		}	
        
        //======== Handle update =========

		cleardevice();

		//======== Handle rendering =========
		
		FlushBatchDraw();

        //========= Stabilize frame rate =========
		DWORD end_time = GetTickCount();
		DWORD delta_time = end_time - start_time;
		if (delta_time < 1000 / FPS)
		{
			Sleep(1000 / FPS - delta_time);
		}
	}

	EndBatchDraw();
	return 0;
}

Object/Class Design

This project introduces architectural concepts by analyzing core functionalities and designing a well-structured program layout. The goal is to improve scalability and make debugging during development more manageable.

Scene Base Class
- Menu Scene Class
- Selector Scene Class
- Game Scene Class
Scene Manager Class
Atlas Class
Animation Class
Vector2 Class
Camera Class
Timer Class
Platform Class
Player Base Class
- Peashooter Class
- Sunflower Class
Player ID Enumeration Class
Bullet Base Class
- Pea Bullet Class
- Sun Bullet Class
- Sun Bullet Ex Class
Status Bar Class
Particle Class

Development Workflow - Framework

Game Framework Design
Scene System Architecture
- Solution: Use inheritance, with each game stage implemented as a subclass of the base Scene class, allowing for more flexible scene management.
- Challenge: How to switch between scenes?
  - Solution: Introduce a Scene Manager to handle transitions.
Resource Loading
- Challenge 1： How to manage animations efficiently and enable resource reuse?
  - Solution: Implement Atlas and Animation classes.
- Challenge 2: How to trigger death animations when an enemy is defeated?
  - Solution: Use callback functions to handle animation logic.
Improving Visual Flexibility
- Solution: Implement a Camera class to control the viewport.
- Challenge 1: How to track camera position more precisely?
  - Solution: Avoid using EasyX’s built-in POINT class (which uses integers); instead, create a custom Vector2 class with floating-point coordinates.
- Challenge 2: How to express impact effects visually?
  - Solution: Add camera shake effects for hit feedback.
Timer Usage Across Gameplay
- Challenge: Beyond animations and camera shake, many features (e.g. special skills, attack cooldowns) require timing control.
  - Solution: Encapsulate a reusable Timer class to provide unified management for time-sensitive features.

Key Steps and Solutions - Framework

Scene System Design

If we think of a scene as a stage in a play, then each scene has its own “script” logic and a unique cast of characters. These characters are what game developers commonly refer to as GameObjects—players, enemies, bullets, items, and so on. Conceptually, they all fall under the GameObject category, each performing different logic under the direction of the scene’s script.

From a programming perspective, a game can be divided into several stages: the main menu, the character selection screen, and the in-game scene. Based on this, we define a base Scene class. The main menu, character selection, and gameplay scenes can each inherit from this base class to implement their own event handling and rendering logic.

`Scene` Base Class

All member functions are defined as virtual, allowing each specific scene class to override them with its own logic. The Scene base class serves as a template for all concrete scene subclasses.

class Scene
{
public:
	Scene() = default;
	~Scene() = default;
    
	virtual void on_enter() {}; 					// Enter the scene
	virtual void on_update(int delta) {};			// Handle updates
	virtual void on_draw() {};						// Handle rendering
	virtual void on_input(const ExMessage& msg) {};	// Handle player input
	virtual void on_exit() {}; 						// Exit the scene

private:
};

`MenuScene` Class (Main Menu Scene)

You can override the necessary member functions:

class MenuScene : public Scene
{
public:
	MenuScene() = default;
	~MenuScene() = default;

	// Override required virtual functions from the base Scene class
	void on_enter()
	{
		cout << "Entered Main Menu" << endl;
	}
	void on_update(int delta)
	{
		cout << "Main Menu is running......" << endl;
	}
	void on_draw()
	{
		outtxtxy(10, 10, _T("Drawing Main Menu content"))；
	}
	void on_input(const ExMessage& msg)
	{
         // Handle input if needed
	}
	void on_exit()
	{
		cout << "Exiting Main Menu" << endl;
	}

private:

};

Instantiating in main.cpp

int main()
{
	initgraph(1280, 720, EW_SHOWCONSOLE);	// Keep the console window visible 

	BeginBatchDraw();
    Scene* scene = new MenuScene();	// Instantiate before entering the main loop
    
	while (running) 
	{
		DWORD frame_start_time = GetTickCount(); 
		while (peekmessage(&msg))
		{
			scene->on_input(msg); // Handle input
		} 

		// Update game logic
		scene->on_update();

		cleardevice();
        
		// Render game screen
		scene->on_draw(); 
		FlushBatchDraw();

		DWORD frame_end_time = GetTickCount();
		DWORD frame_delta_time = frame_end_time - frame_start_time;
		if (frame_delta_time < 1000 / FPS) 
		{
			Sleep(1000 / FPS - frame_delta_time); 
		}

	}
	EndBatchDraw();

	return 0;
}

All scene subclasses follow the same design pattern.

Implementing the Scene Manager

A game program is essentially a massive loop—and also a massive state machine. Each game scene represents a distinct state, and the system that manages these states is commonly referred to in game development as the Scene Manager.

class SceneManager
{
public:
	enum class SceneType	// Marks the current scene state
	{
		Menu,
		Game,
		Selector

	};

public:
	SceneManager() = default;
	~SceneManager() = default;

	// Set the current scene
	void set_current_scene(Scene* scene)
	{
		current_scene = scene;
		current_scene->on_enter();	// Ensure the scene lifecycle is properly triggered
	}

	// Switch scenes (exit the current scene, then select and enter the new one)
	void switch_to(SceneType type)
	{
		current_scene->on_exit();	// Exit the current scene
		switch (type)
		{
		case SceneType::Menu:
			current_scene = menu_scene;
			break;
		case SceneType::Game:
			current_scene = game_scene;
			break;
		case SceneType::Selector:
			current_scene = selector_scene;
			break;
		default:
			break;
		}
		current_scene->on_enter();	// Enter the newly selected scene
	}

	void on_update(int delta)
	{
		current_scene->on_update(delta);
	}
	void on_draw()
	{
		current_scene->on_draw();
	}
	void on_input(const ExMessage& msg)
	{
		current_scene->on_input(msg);
	}

private:
	Scene* current_scene = nullptr;
};

The on_enter and on_exit methods serve similar purposes to constructors and destructors—they’re used to initialize and release resources. So why not just use constructors and destructors directly?

The reason is that constructors and destructors control the memory lifecycle of scene objects. If we rely on them to handle all enter/exit logic, we’d need to constantly create and destroy scene objects during transitions, which is not performance-friendly. As game logic grows more complex, some resources may be shared across scenes. In other words, objects within a scene may need to outlive the scene itself, which introduces additional memory management challenges.

This design offers a cleaner and more flexible approach: scene objects live as long as the game itself. All scenes are created during game initialization and destroyed when the game exits. During runtime, we avoid calling constructors and destructors for scene transitions, and instead use clearly defined on_enter and on_exit methods. These methods should avoid creating or destroying internal members—instead, they reset internal state.

Example: Suppose the game scene contains a player object. When the player’s health reaches zero, the game transitions to the main menu. If we use constructors/destructors, we’d need to delete the game scene and new the menu scene. Then, when returning to the game scene, we’d have to recreate everything just to reset the player’s health.

With on_enter and on_exit, we avoid this overhead. Instead, we simply reset the player’s health variable when re-entering the game scene—achieving the same “fresh start” effect without costly object reconstruction.

Why use a pointer for setting the current scene, but an enum for switching scenes?

This design choice reflects usage context:

set_current_scene is typically called during game initialization, when scenes are being instantiated—so passing a pointer is straightforward.
switch_to is usually called during runtime from within scene logic. If scenes hold references to each other, passing pointers directly can lead to memory issues. Using an enum abstracts away internal pointer management and keeps transitions safe and clean.

With this setup, the scene-related logic in main can be fully delegated to the Scene Manager:

menu_scene = new MenuScene();
game_scene = new GameScene();
selector_scene = new SelectorScene();

scene_manager.set_current_scene(menu_scene);

BeginBatchDraw();
while (running) 
{
	DWORD frame_start_time = GetTickCount(); 
	while (peekmessage(&msg)) 
	{
		scene_manager.on_input(msg);
	} 

	scene_manager.on_update();

	cleardevice();

	scene_manager.on_draw(main_camera);
	FlushBatchDraw();

Scene transitions are handled within each scene’s on_input method.

// MenuScene.h
void on_input(const ExMessage& msg)
{
	if (msg.message == WM_KEYUP)
	{
		scene_manager.switch_to(SceneManager::SceneType::Selector);
	}
}

Resource Loading Design

Implementing the `Atlas` Class

The Atlas class serves as a container for a series of related image resources:

class Atlas
{
public:
	Atlas() = default;
	~Atlas() = default;

	void load_from_file(LPCTSTR path_template, int num)
	{
        // Important: Clear the image list before loading
        // and resize it to the expected number of frames.
        // This prevents mismatches when load_from_file is called multiple times.
		img_list.clear();		
		img_list.resize(num);

		TCHAR path_file[256];
		for (int i = 0; i < num; i++)
		{
			_stprintf_s(path_file, path_template, i + 1);
			loadimage(&img_list[i], path_file);
		}
	}

	void clear()	// Clear all loaded images in the atlas
	{
		img_list.clear();
	}

	size_t get_size()	// Get the number of images in the atlas
	{
		return img_list.size();
	}

	IMAGE* get_image(int idx)	// Retrieve a specific animation frame
	{
		if (idx < 0 || idx >= img_list.size())
			return nullptr;

		return &img_list[idx];	// Return the address of the image at the given index
	}

    // Add an existing image to the atlas
    // This may seem redundant with file loading,
    // but it's useful for generating horizontally flipped atlases
    void add_image(const IMAGE& img)	
	{
		img_list.push_back(img);
	}

private:
	vector<IMAGE> img_list;
};

Resource Loading Strategy

Before implementing the Animation class, we need a way to horizontally flip animation frames. This avoids the need for duplicate assets. Since pixel-level flipping is computationally expensive, it should be done during game initialization, not during frame updates.

This flipping function is a utility and should be placed in util.h for easy access across the project. A detailed explanation is available in another post: Teyvat Survivor.

In main.cpp, we define flip_atlas as a global function so it can be called before the main loop:

// main.cpp

void flip_atlas(Atlas& src, Atlas& dst)
{
	dst.clear(); // Prevent issues from reusing the same container
	for (int i = 0; i < src.get_size(); i++)
	{
		IMAGE img_flipped;
		flip_image(src.get_image(i), &img_flipped);
		dst.add_image(img_flipped);
	}
}

For now, all resources are loaded via a global function in main.cpp. It’s important to use meaningful and consistent naming for assets. A recommended format is type_character_direction, such as Atlas atlas_peashooter_idle_left;. While verbose, this naming convention improves editor searchability and debugging efficiency.

The resource loading logic includes three parts:

Loading game fonts
Loading and processing image assets
Loading sound effects

Sound effects are handled using mciSendString, so don’t forget to include the appropriate library.

Implementing the `Animation` Class

The Animation class acts as a lightweight controller for rendering atlases. It builds on top of the Atlas class and is designed around two components:

Member variables: define the data structure
Member functions: provide external interfaces for querying and modifying state

Since frame progression is automatic during playback, there’s no need for external set methods. Instead, only get_idx_frame and get_frame are exposed for frame access.

The two most important methods—on_update and on_draw—are explained in detail in the Teyvat Survivor article.

How should we handle disappearing animations for objects like enemies or bullets when their lifecycle ends?

We shouldn’t delete the Enemy object immediately upon death. Instead, we delay deletion until the death animation finishes. This requires the animation system to signal when playback is complete.

A common solution: use callback functions.

Callback Functions

A callback is a function object passed as a parameter and stored for later execution. This allows logic to be triggered at the “right moment.”

For example, when an enemy dies, we define the deletion logic as a function and store it in the animation object. Once the death animation finishes, the callback is invoked to remove the enemy.

Be sure to write #include <functional> at the top. Here’s a sample implementation:

class Animation
{
public:
	......

	void on_update(int delta)
	{
		timer += delta;
		if (timer > interval)
		{
			timer = 0;
			idx_frame++;
			if (idx_frame >= atlas->get_size())
			{
				idx_frame = is_loop ? 0 : atlas->get_size() - 1;

				if (!is_loop && callback) // If animation is non-looping and callback exists, invoke it
				{
					callback();
				}
			}
		}
	}

	void set_callback(function<void()> callback)
	{
		this->callback = callback;
	}

private:
	......

	function<void()> callback; // Callback to trigger object removal after animation finishes
};

Here’s the full implementation of the Animation class:

class Animation
{
public:
	Animation() = default;
	~Animation() = default;

	void reset()
	{
		timer = 0;
		idx_frame = 0;
	}

	void set_atlas(Atlas* new_atlas)
	{
		reset();
		atlas = new_atlas;
	}

	void set_loop(bool flag)
	{
		is_loop = flag;
	}

	void set_interval(int ms)
	{
		interval = ms;
	}

	int get_idx_frame()
	{
		return idx_frame;
	}

	IMAGE* get_frame()
	{
		return atlas->get_image(idx_frame);
	} 

	bool check_finished()
	{
		if (is_loop)
			return false;

		return (idx_frame == atlas->get_size() - 1);
	}

	void on_update(int delta)
	{
		timer += delta;
		if (timer > interval)
		{
			timer = 0;
			idx_frame++;
			if (idx_frame >= atlas->get_size())
			{
				idx_frame = is_loop ? 0 : atlas->get_size() - 1;

				if (!is_loop && callback) // If animation is non-looping and callback exists, invoke it
				{
					callback();
				}
			}
		}
	}

	void on_draw(const Camera& camera, int x, int y) const
	{
		putimage_alpha(camera, x, y, atlas->get_image(idx_frame));
	}

	void set_callback(function<void()> callback)
	{
		this->callback = callback;
	}

private:
	Atlas* atlas = nullptr;
	bool is_loop = true; // Whether the animation loops

	int timer = 0;		 // Frame timer
	int interval = 0;	 // Frame interval in milliseconds
	int idx_frame = 0;	 // Current frame index

	function<void()> callback; // Callback to trigger object removal after animation finishes
};

Camera System Design

Window Coordinates vs. World Coordinates

In EasyX, the origin of the window coordinate system is at the top-left corner of the screen:

EasyX Window Coordinates

In contrast, the world coordinate system represents a much larger virtual space. Think of it as the entire game world where all objects—players, enemies, bullets, items—are placed and interact. Player movement, collisions, triggers, and all game logic operate within this world space. Only when rendering the game do we need to convert world coordinates into window coordinates.

The camera acts as a bridge between these two systems. This aligns with the game development principle of separating data from rendering.

When we ignore zooming (i.e., the camera’s width and height match the window’s), we can treat the camera as a single point in the world. In a side-scrolling game, for example, the camera simply follows the player’s position. To render other objects, we subtract the camera’s world position from each object’s world position to get their window coordinates.

Key concept:

Window Coordinate = World Coordinate - Camera Coordinate

Implementing the `Vector2` Class

To allow precise control of the camera’s position using floating-point values, we define a commonly used 2D vector class. Operator overloading makes it easier to perform arithmetic operations similar to built-in types:

class Vector2
{
public:
	Vector2() = default;
	~Vector2() = default;

	Vector2(float x, float y) // Constructor for direct initialization
		: x(x),y(y){ }

	//======== Operator Overloads ========
	// Enables intuitive vector arithmetic
	Vector2 operator+(const Vector2& vec) const
	{
		return Vector2(x + vec.x, y + vec.y);
	}

	void operator+=(const Vector2& vec)
	{
		x += vec.x, y += vec.y;
	}

	Vector2 operator-(const Vector2& vec) const
	{
		return Vector2(x - vec.x, y - vec.y);
	}

	void operator-=(const Vector2& vec)
	{
		x -= vec.x, y -= vec.y;
	}

	Vector2 operator*(const Vector2& vec) const
	{
		return Vector2(x * vec.x, y * vec.y);
	}

	Vector2 operator*(float val) const
	{
		return Vector2(x * val, y * val);
	}

	void operator*=(float val) 
	{
		x *= val, y *= val;
	}

	float length()
	{
		return sqrt(x * x + y * y);
	}

	Vector2 normalize()
	{
		float len = length();

		if (len == 0)
		{
			return Vector2(0, 0);
		}

		return Vector2(x / len, y / len);
	}

public:
	float x = 0.0f;
	float y = 0.0f;
};

Implementing the Camera Class

Camera Shake Effect

This is a common visual effect in games. When firing a weapon or triggering an explosion, the screen shakes briefly to convey impact. It’s simple to implement but highly effective.

Implementation Strategy

Since the shake only lasts for a short time, we need a way to start and stop it. Like animations, this is best handled with a timer.

Implementing a General-Purpose Timer

There are two main design approaches:

Inheritance-based
Callback-based

Inheritance Approach

Define a base Timer class with an on_update method. Subclasses override the callback method to define custom behavior:

class Timer
{
public:
	Timer() = default;
    ~Timer() = default;
    
    void on_update(int delta)
    {
        // ......
        callback();
    }
    
protected:
    virtual void callback()
    {
        // Timer logic
    }
}；

To use it:

class MyTimer : public Timer
{
 public:
    MyTimer() = default;
    ~MyTimer() = default;
    
 protected:
    void callback() override
    {
        // Custom timer logic
    }
}；
    
Timer* my_timer = new MyTimer();

Callback Approach

Similar to the Animation class, we store a function and invoke it when the timer completes:

class Timer
{
public:
    Timer() = default;
    ~Timer() = default;
    
    void on_update(int delta)
    {
        // ......
        callback();
    }
    
    void set_callback(function<void()> callback)
    {
        this->callback = callback;
    }
 
protected:
    function<void()> callback;
}

Usage:

Timer my_timer;
mu_timer.set_back([]()
    {
        // Custom timer logic           
    })；

Comparison

The callback-based approach is more concise and flexible. If you need multiple timers with different behaviors, inheritance requires creating multiple subclasses. With callbacks, you just write a lambda function.

For general-purpose timers that only differ in behavior—not data—it’s better to use callbacks. This reduces boilerplate and improves clarity.

Full Timer Class Implementation

// General-purpose timer class
// Uses callbacks to define behavior on timeout
class Timer
{
public:
	Timer() = default;
	~Timer() = default;

	void restart() // Reset the timer
	{
		pass_time = 0;
		shotted = false;
	}

	void set_wait_time(int val)
	{
		wait_time = val;
	}

	void set_one_shot(bool flag)
	{
		one_shot = flag;
	}

	void set_callback(function<void()> callback)
	{
		this->callback = callback;
	}

	void pause()
	{
		paused = true;
	}

	void resume()
	{
		paused = false;
	}

	void on_update(int delta)
	{
		if (paused)
			return;

		pass_time += delta;
		if (pass_time >= wait_time)
		{
			if (!one_shot || (one_shot && !shotted) && callback)
				callback();

			shotted = true;
			pass_time = 0;
		}
	}

private:
	int pass_time = 0;			// Elapsed time
	int wait_time = 0;			// Wait duration
	bool paused = false;		// Pause flag
	bool shotted = false;		// Triggered flag
	bool one_shot = false;		// One-time trigger
	function<void()> callback;	// Callback function
};

Camera Class with Integrated Timer

Design Approach for Camera Shake Effect

To make the entire screen appear to shake, we simply need to shake the camera’s position. In other words, the shake effect is achieved by rapidly changing the coordinates of the Camera object.

A straightforward approach is to randomly reposition the camera within a circle whose radius equals the shake intensity. Since frame updates happen frequently, this randomness creates a convincing shake effect at runtime.

For smoother and more natural motion—especially with stronger shake effects—noise algorithms like Perlin noise can be used instead of pure randomness. However, for the subtle shake used in this project, the visual improvement is minimal, so we stick with the simpler random-based implementation.

Full Camera Class Implementation:

class Camera
{
public:
	Camera()
	{
		timer_shake.set_one_shot(true);
		timer_shake.set_callback([&]()
			{
				is_shaking = false;
				reset();
			}
		);
	}

	~Camera() = default;

	const Vector2& get_position() const // First const: returns a read-only reference; second const: ensures this method doesn't modify the object
	{
		return position;
	}

	void reset() // Reset camera position to origin
	{
		position.x = 0;
		position.y = 0;
	}

	void on_update(int delta)
	{
		timer_shake.on_update(delta);

		if (is_shaking)
		{
			position.x = (-50 + rand() % 101) / 50.0f * shaking_strength;
			position.y = (-50 + rand() % 101) / 50.0f * shaking_strength;
		}
	}

    // Start camera shake effect
    // Parameters: strength = shake intensity, duration = shake duration in milliseconds
    void shake(float strength, int duration)
	void shake(float strength, int duration)
	{
		is_shaking = true;
		shaking_strength = strength;

		timer_shake.set_wait_time(duration);
		timer_shake.restart();
	}

private:
	Vector2 position;			// Camera position

	// Shake effect implementation
	Timer timer_shake;			// Timer controlling shake duration
	bool is_shaking = false;
	float shaking_strength = 0; // Shake intensity
};

In the on_update method, the camera’s position is randomly set within a circle defined by the shake intensity. The random coefficient before shaking_strength represents a value in the range of -1.0 to 1.0, simulating a unit circle.

With this, the core game framework is complete. For the second half of this project, covering gameplay implementation, continue reading the companion article: Plant Star Brawl - Gameplay Layer.

【C++ Game Dev from Scratch】Teyvat Survivors

Wed, 08 Oct 2025 10:47:30 +0200

Table of Contents

Overview

Tech Stack：C++ + EasyX

Project Goal：Design an animation framework for the game, integrate keyboard input, and create more interactive gameplay. On the data and logic level, implement basic 2D collision detection, random enemy spawning, and enemy tracking behavior. Add music and sound effects to enhance the overall polish. Include a main menu interface. Use the Flyweight pattern to optimize program performance.

Course Source：Bilibili-Voidmatrix

Core Gameplay

The player clicks the Start button to enter the game and uses the Arrow Keys (Up, Down, Left, Right) to control character movement. A ring of bullets surrounds the player, while wild boar enemies continuously rush in from off-screen. When a bullet hits an enemy, the enemy is defeated and the player’s score increases. If an enemy touches the player, the game ends.

Main Development Process

Design Approach

Designing the Core Game Framework

Setting up the game window, creating the main loop, and stabilizing the frame rate follow a standard structure commonly used in game development. Since these steps are explained in detail in Episode 0: Fundamentals of the tutorial series, they won’t be repeated here.Setting up the game window, creating the main loop, and stabilizing the frame rate follow a standard structure commonly used in game development. Since these steps are explained in detail in Episode 0: Fundamentals of the tutorial series, they won’t be repeated here.

int main()
{
    //========= Initialize data ==========
	initgraph(1280, 720);
	
    bool is_running = true;
    const int FPS = 60;
	
	ExMessage msg;
	
	BeginBatchDraw();
   
	while (is_running)	// Main game loop
	{
		DWORD start_time = GetTickCount();
        
        //========= Handle input =========
		while (peekmessage(&msg))
		{
			
		}	
        
        //======== Handle update =========

		cleardevice();

		//======== Handle rendering =========
		
		FlushBatchDraw();

        //========= Stabilize frame rate =========
		DWORD end_time = GetTickCount();
		DWORD delta_time = end_time - start_time;
		if (delta_time < 1000 / FPS)
		{
			Sleep(1000 / FPS - delta_time);
		}
	}

	EndBatchDraw();
	return 0;
}

Object and Class Design

This project does not use polymorphism to abstract higher-level objects. Instead, each game element is implemented as a separate class, following a one-object-per-class approach. To make the structure intuitive for beginners, all code is written in main.cpp, using many global variables.

Player class
Bullet class (bullets orbiting the player
Enemy class
Animation and Atlas classes (for animation effects and optimization)
Button base class
- StartGameButton
- ExitGameButton

Development Workflow

Game Framework Setup
Image Loading and Rendering
- Solution: Use EasyX functions loadimage and putimage
- Issue: PNG images show black edges
  - Solution: Override putimage with a version that supports transparency
  - Note: Include the library #pragma comment(lib, "MSIMG32.LIB")
Animation Implementation
- Challenge1: How to animate images?
  - Solution: Use a counter → optimize with a timer
- Challenge2: Repetitive animation code
  - Solution: Encapsulate logic in an Animation class
Player Movement
- Issue 1: Movement feels choppy
  - Solution: Use boolean flags to track key press/release and control movement indirectly
- Issue 2: Diagonal movement is faster than horizontal/vertical
  - Solution: Normalize movement vectors to ensure consistent speed
Animation Data Mixing Issue
- Issue: Enemy and player data get mixed in the Animation class
- Solution: Use object-oriented design to separate logic and data into distinct classes
Implementing Player, Bullet, and Enemy Classes
Enemy Behavior
- Challenge 1: Enemy spawn logic
  - Solution: Randomly spawn enemies along one edge of the screen
- Note: When passing other class objects into functions, use references. If the object won’t be modified, add const.
- Challenge 2: Enemy auto-tracking logic
  - Solution: Calculate the unit vector from enemy to player and move in that direction
2D Collision Detection
- Challenge 1: Bullet vs. Enemy
  - Solution: Treat enemies as rectangles and bullets as points
- Challenge 2: Player vs. Enemy
  - Solution: Use the enemy’s center point for collision detection against the player’s rectangle
Bullet Updates and Visual Effects
- Challenge: Make bullet movement more dynamic
  - Solution: Add tangential and radial velocity components
Removing Defeated Enemies
- Solution: Use swap to move the enemy to the end of the vector, then pop_back and delete to free memory.
  - This is efficient when element order doesn’t matter.
Displaying Player Score
Adding Sound Effects
- Solution: Use Windows API function mciSendString
- Note: Include the library #pragma comment(lib, "Winmm.lib")
Performance Optimization
- Solution: Use the Flyweight Pattern to optimize resource loading
- Note: Do not release the shared Atlas inside the Animation class—control it from a higher level
Main Menu UI and Button Class Design

Key Steps and Implementation Ideas

Image Loading and Rendering

Loading Images

According to the documentation, EasyX provides a function called loadimage to load images. It has several overloads, but here we’ll use the simplest version: loading an image directly from a file.

// Load image from file (supports bmp/gif/jpg/png/tif/emf/wmf/ico)
int loadimage(
	IMAGE* pDstImg,			// Pointer to the IMAGE object that stores the image
	LPCTSTR pImgFile,		// File path of the image
	int nWidth = 0,			// Optional: stretch width度
	int nHeight = 0,		// Optional: stretch height
	bool bResize = false	// Optional: resize IMAGE to fit image size
);

A few things to note:

The first parameter must be a non-null pointer to an IMAGE object. We load the image into memory first, not directly onto the screen.
The second parameter is the file path as a string.
The last three parameters are optional and control image scaling. We won’t use them in this project.

To load an image named test.jpg from the project directory:

1
2

IMAGE img;
loadimage(&img, _T("test.jpg"));

Rendering Images

To draw the image on screen, EasyX provides the putimage function:

// 绘制图像
void putimage(
	int dstX,				// X coordinate on screen
	int dstY,				// Y coordinate on screen
	IMAGE *pSrcImg,			// Pointer to the IMAGE object to draw
	DWORD dwRop = SRCCOPY	// Raster operation code (usually ignored)
);

The first two parameters specify the position on screen.
The last parameter is a raster operation code, which we’ll ignore for this project.

To render the image we just loaded:

// Load image
IMAGE img;
loadimage(&img, _T("test.jpg"));

// Draw image
putimage(100, 200, &img);

If the image is 300 * 300 pixels, it will appear at position (100, 200) on the game screen like this:

Handling PNG Transparency

PNG images may show black edges when rendered. To fix this, we need to create a custom putimage_alpha function that supports transparency using AlphaBlend.

#pragma comment(lib, "MSIMG32.LIB") 

void putimage_alpha(int x, int y, IMAGE* img)
{
	int w = img->getwidth();
	int h = img->getheight();
	AlphaBlend(GetImageHDC(NULL), x, y, w, h, GetImageHDC(img),
		0, 0, w, h, { AC_SRC_OVER,0,255,AC_SRC_ALPHA });
}

Make sure to include the required library at the top of your file: #pragma comment(lib, "MSIMG32.LIB") .

Implementing Animation and Rendering

How to Make the Scene Move?

In game development, character animation is typically implemented in two main ways: frame-by-frame animation and keyframe animation.

Frame-by-frame animation uses a sequence of images. By displaying these images one after another over time, we create the illusion of motion through visual persistence.
Keyframe animation, such as skeletal animation, involves more advanced graphics techniques and won’t be covered here.

It’s important to note that we should not use the Sleep() function to control animation timing. Calling Sleep() causes the program to pause, which is a blocking operation. In our game framework, rendering and updates should happen continuously within the game loop, with each loop cycle completing within 1/60 of a second (i.e., 60 FPS). Animation frame switching should be spread across multiple frames—not completed in a single loop. This reflects a core principle in game programming: Avoid blocking operations or heavy tasks inside the main loop.

To switch animation frames at fixed intervals, we use a timer-based counter:

int idx_current_anim = 0;	// 1. Index of the current animation frame

const int PLAYER_ANIM_NUM = 6;	// Total number of animation frames

int main()
{
    .....
        
    while (is_running)
    {
        while (peekmessage(&msg))
  	    {
        
        }
    
        static int counter = 0;	// 2. Counts how many game frames have passed
                                // 'static' ensures it's initialized only once
        // Switch animation frame every 5 game frames
        if (++counter % 5 == 0)
            idx_current_anim++;

        if（idx_current_anim % PLAYER_ANIM_NUM == 0)
            idx_current_anim = 0;
        }  

        ......
}

Rendering Animation Frames

To render animation, we simply draw images from an array in sequence. First, load the frames:

const int PLAYER_ANIM_NUM = 6;	// Total number of animation frames

IMAGE img_player_left[PLAYER_ANIM_NUM];
IMAGE img_player_right[PLAYER_ANIM_NUM];

void load_animation()
{
    for (size_t i = 0; i < PLAYER_ANIM_NUM; i++)
    {
        std::wstring path = L"img/player_left_" + std::to_wstring(i) + L".png";
        loadimage(&img_player_left[i], path.c_str());
    }
    
    for (size_t i = 0; i < PLAYER_ANIM_NUM; i++)
    {
        std::wstring path = L"img/player_right_" + std::to_wstring(i) + L".png";
        loadimage(&img_player_right[i], path.c_str());
    }
}

Then, inside the main loop, draw the current frame:

int main()
{
    ......
   
	while (is_running)	// Main game loop
	{
		DWORD start_time = GetTickCount();
        
        //========= Handle Input =========
		while (peekmessage(&msg))
		{
			
		}	
        
        //======== Update =========

		cleardevice();

		//======== Render =========
		putimage_alpha(500, 500, &img_player_left[idx_current_anim]);
        
		FlushBatchDraw();

       ......
    }
}

This setup ensures smooth animation playback by cycling through frames at a consistent rate.

Encapsulating Animation into a Class

From a data structure perspective, we use a vector<IMAGE*> to store pointers to the images needed for the animation. In the constructor, we load the image resources and allocate memory for each frame. Correspondingly, the destructor is responsible for releasing that memory to avoid leaks.

When playing the animation, we pass not only the position where the animation should be rendered, but also an int delta parameter that represents the time elapsed since the last call to Play(). This replaces the earlier “frame counter” approach with a timer-based system.

Why this change? Because animation speed—defined by the frame interval—should depend on actual time, not the game’s frame rate. We want the animation to play at a consistent speed regardless of how fast the game loop runs. Using a time-based timer ensures smoother and more predictable playback than simply incrementing a counter every frame.

Here’s the implementation:

class Animation
{
public:
	Animation(LPCTSTR path, int num, int interval)	// Load animation frames
    {
        interval_ms = interval;
        
        TCHAR path_file[256];
        for (size_t i = 0; i < num; i++)
        {
            _sprintf_s(path_file, path, i);
            
            IMAGE* frame = new IMAGE();
            loadimage(frame, path_file);
            frame_list.push_bacl(frame);
        }
    }
    
    void Play(int x, int y, int delta)	// Play animation
    {
        timer += delta;
        if (timer >= interval_ms)
        {
            idx_frame = (idx_frame + 1) % frame_list.size();
            timer =0;
        }
        
        //  Render current frame
        pitimage_alpha(x, y, frame_list[idx_frame]);
    }
    
    ~Animation()	// Release resources
    {
        for (size_t i = 0; i < frame_list.size(); i++)
        {
            delete frame_list[i];
        }
    }
private:
    vector<IMAGE*> frame_list;	// List of animation frames
    int interval_ms = 0;		// Time between frames (in milliseconds)
    int timer = 0;              // Time accumulator
    int idx_frame = 0;          // Current frame index
}

Implementing Player Movement

If we control player movement by directly adding displacement to the position when a key is pressed, it can result in a choppy or inconsistent feel. This happens because WM_KEYDOWN messages are generated asynchronously from the main game loop, and their frequency depends on the operating system and hardware. As a result, some frames may process multiple WM_KEYDOWN messages, while others may receive few or none—causing the player to move unevenly across frames and creating a stuttering effect.

Additionally, when a directional key is pressed, the first WM_KEYDOWN message enters the event queue immediately. However, continuous WM_KEYDOWN messages only begin after a short delay if the key remains held down. This behavior contributes further to inconsistent movement.

To ensure smooth and consistent movement across all frames, we treat movement as a state:

When a key is pressed (WM_KEYDOWN), the player starts moving.
When the key is released (WM_KEYUP), the player stops moving.

We use four boolean flags to represent movement directions. These flags are updated based on key press and release events, and the player’s position is updated accordingly in each frame:

void ProcessEvent(const ExMessage& msg)
{
	if (msg.message == WM_KEYDOWN)
	{
		switch (msg.vkcode)
		{
		case VK_UP:
			is_moving_up = true;
			break;
		case VK_DOWN:
			is_moving_down = true;
			break;
		case VK_LEFT:
			is_moving_left = true;
			break;
		case VK_RIGHT:
			is_moving_right = true;
			break;
		}
	}

	if (msg.message == WM_KEYUP)
	{
		switch (msg.vkcode)
		{
		case VK_UP:
			is_moving_up = false;
			break;
		case VK_DOWN:
			is_moving_down = false;
			break;
		case VK_LEFT:
			is_moving_left = false;
			break;
		case VK_RIGHT:
			is_moving_right = false;
			break;
		}
	}		
}

void Move()
{
    if (is_moving_up)
        position.y -= SPEED;
    if (is_moving_down)
        position.y += SPEED;
    if (is_moving_left)
        position.x -= SPEED;
    if (is_moving_right)
        position.x += SPEED;
}

To prevent the player from moving faster diagonally than horizontally or vertically, we normalize the movement vector. This ensures consistent speed in all directions:

int dir_x = is_move_right - is_move_left;
int dir_y = is_move_down - is_move_up;
double len_dir = sqrt(dir_x * dir_x + dir_y + dir_y);
if(len_dir != 0)
{
    double normalized_x = dir_x / len_dir;
    double normalized_y = dir_y / len_dir;
    player_pos.x += (int)(PLAYER_SPEED * normalized_x);
    player_pos.y += (int)(PLAYER_SPEED * normalized_y);
}

Class Encapsulation

To prevent data and logic from being scattered across the project, each object’s behavior and data are encapsulated into dedicated classes. For example, the Player class is structured roughly as follows:

class Player
{
public:
    Player()
    {
          // Initialize resources: animation frames, image assets, etc.
    }
    ~Player()
    {
        // Release resources
    }
    void ProcessEvent(const ExMessage& msg)
    {
        // Handle player input
    }
    void Move()
    {
        // Handle player movement
    }
    void Draw(int delta)
    {
        // Render the player
    }   
private:
    // Internal data members
    ......
}

Enemy Class Implementation Details

Random Enemy Spawning

// Define spawn edges
enum class SpawnEdge
{
	Up = 0,
	Down,
	Left,
	Right
};

// Randomly select one edge
SpawnEdge edge = (SpawnEdge)(rand() % 4);
// Assign spawn coordinates based on selected edge
switch (edge)
{
case SpawnEdge::Up:
	position.x = rand() % WINDOW_WIDTH;
	position.y = -FRAME_HEIGHT;
	break;
case SpawnEdge::Down:
	position.x = rand() % WINDOW_WIDTH;
	position.y = WINDOW_HEIGHT;
	break;
case SpawnEdge::Left:
	position.x = -FRAME_WIDTH;
	position.y = rand() % WINDOW_HEIGHT;
	break;
case SpawnEdge::Right:
	position.x = WINDOW_WIDTH;
	position.y = rand () % WINDOW_HEIGHT;
	break;
default:
	break;
}

Enemy Pathfinding Logic

Each enemy automatically moves toward the player by calculating the direction vector between their positions and normalizing it. This ensures consistent movement speed regardless of distance:

void Move(const Player& player)
{
    const POINT& player_position = player.GetPosition();
    int dir_x = player_position.x - position.x;
    int dir_y = player_position.y - position.y;
    double dir_len = sqrt(dir_x * dir_x + dir_y * dir_y);
    if (dir_len != 0)
    {
        double normalized_x = dir_x / dir_len;
        double normalized_y = dir_y / dir_len;
        position.x += (int)(normalized_x * SPEED);
        position.y += (int)(normalized_y * SPEED);
    }

    // Update facing direction based on horizontal movement
    if (dir_x > 0)
        facing_left = false;
    else if (dir_x < 0)
        facing_left = true;
}

Implementing 2D Collision Detection

All collision logic is implemented within the Enemy class. To avoid unnecessary copying, the Player and Bullet objects are passed by reference.

Enemy vs. Bullet

bool CheckBulletCollision(const Bullet& bullet) // 'const' ensures the bullet won't be modified
{
    // Treat the bullet as a point and check if it's inside the enemy's rectangle
    bool is_overlap_x = bullet.position.x >= position.x && bullet.position.x <= position.x + FRAME_WIDTH;
    bool is_overlap_y = bullet.position.y >= position.y && bullet.position.y <= position.y + FRAME_HEIGHT;
		
    return is_overlap_x && is_overlap_y;
}

Enemy vs. Player

In most games, collision detection isn’t overly strict. If both the enemy and player are treated as rectangles, it’s possible for only a corner to overlap visually without feeling like a real collision—leading to confusion. To improve the experience, hitboxes are often smaller than the actual image size.

Here, we treat the enemy’s center point as the collision point and check if it overlaps with the player’s rectangle:

bool CheckPlayerCollision(const Player& player)
{
	// Use the enemy's center point as the collision point
	POINT check_position = { position.x + FRAME_WIDTH / 2, position.y + FRAME_HEIGHT / 2 };
	bool is_overlap_x = check_position.x >= player.GetPosition().x && check_position.x <= player.GetPosition().x + player.FRAME_WIDTH;
	bool is_overlap_y = check_position.y >= player.GetPosition().y && check_position.y <= player.GetPosition().y + player.FRAME_HEIGHT;
	
	return is_overlap_x && is_overlap_y;
}

Bullet Updates and Visual Effects

The bullets orbiting the player are handled as a group of three and updated using a global function.

To create a dynamic visual effect, we animate the bullets by adjusting their angle (α) over time. All angles are calculated in radians for simplicity:

Here’s the corresponding code:

//  Update bullet positions
void UpdateBullets(vector<Bullet>& bullet_list, const Player& player)
{
	// Create a pulsating effect for visual flair
	const double RADIAL_SPEED = 0.0045; // Speed of radial oscillation
	const double TANGENT_SPEED = 0.0055; // Speed of tangential rotation

	double radian_interval = 2 * PI / bullet_list.size(); // Angular spacing between bullets

	// Update each bullet's position based on the player's location
	POINT player_position = player.GetPosition();
	double radius = BULLET_BASE_RADIUS + BULLET_RADIUS_CHANGE_RANGE * sin(GetTickCount() * RADIAL_SPEED);
	for (size_t i = 0; i < bullet_list.size(); i++)
	{
		double radian = GetTickCount() * TANGENT_SPEED + radian_interval * i;
		bullet_list[i].position.x = player_position.x + player.FRAME_WIDTH / 2 + (int)(radius * sin(radian));
		bullet_list[i].position.y = player_position.y + player.FRAME_HEIGHT / 2 + (int)(radius * cos(radian));
	}
}

Removing Defeated Enemies

// Iterate through the enemy list and remove defeated enemies
for (size_t i = 0; i < enemy_list.size(); i++) // Avoid using iterators since the 												// container is modified during iteration
{
	Enemy* enemy = enemy_list[i];
	if (!enemy->CheckAlive())
	{
		// Swap with the last element and remove it
		// * This is an efficient deletion method when element order doesn't matter
		swap(enemy_list[i], enemy_list.back());
		enemy_list.pop_back();
		delete enemy;
	}
}

Playing Sound Effects

This project uses Windows API functions to play sound. Here’s how to do it:

// Open the bgm.mp3 file located in the mus folder and assign it the alias "bgm"
mciSendString(_T("open mus/bgm.mp3 alias bgm"), NULL, 0, NULL);	// Load sound

// Play the sound with alias "bgm" in a loop starting from the beginning
mciSendString(_T("play bgm repeat from 0"), NULL, 0, NULL);		// Remove 'repeat' if looping is not needed

Performance Optimization: Using the Flyweight Pattern

Game assets like models and textures often consume significant disk space and increase loading time. The Flyweight pattern is commonly used in game development to optimize resource usage.

Here’s a comparison between a typical implementation and a Flyweight-based one:

//========= Typical Implementation =========
struct Tree
{
    Model model;	// Tree model
    Texture texture;// Tree texture
    int x, y, z;	// Tree position
}

//======= Flyweight Implementation =======

// Shared asset structure
// All trees use the same TreeAsset instance for model and texture
struct TreeAsset
{
    Model model;	// Tree model
    Texture texture;// Tree texture
}

// Tree instance structure
struct Tree
{
    TreeAsset* asset;	// Pointer to shared asset
    int x, y, z;		// Tree position
}

In this project, we refactor the Animation class to separate shared and instance-specific data. The shared data—std::vector<IMAGE*> frame_list—is stored in an Atlas class, while each enemy instance maintains its own animation state.

Shared image data is managed by the Atlas class:

// Optimized resource loading
class Atlas
{
public:
	Atlas(LPCTSTR path, int num)
	{
		// Load image frames
		TCHAR path_file[256];
		for (int i = 0; i < num; i++)
		{
			_stprintf_s(path_file, path, i);

			IMAGE* frame = new IMAGE();
			loadimage(frame, path_file);
			frame_list.push_back(frame);
		}
	}

	~Atlas()
	{
		for (int i = 0; i < frame_list.size(); i++)
		{
			delete frame_list[i];
		}
	}

public:
	vector<IMAGE*> frame_list;
};

Instance-specific animation logic is encapsulated in the Animation class:

class Animation
{
public: 
	Animation(Atlas* atlas, int interval)
	{
		anim_atlas = atlas;
		interval_ms = interval;
	}

	~Animation() = default; // The atlas is shared, so we don't delete it here
							// It should be released at a higher level (e.g., in main)
							// Also, we didn't allocate it with 'new' here

	// Play animation
	void Play(int x, int y, int delta_time)
	{
		timer += delta_time;
		if (timer >= interval_ms)
		{
			idx_frame = (idx_frame + 1) % anim_atlas->frame_list.size();
			timer = 0;
		}

		putimage_alpha(x, y, anim_atlas->frame_list[idx_frame]);
	}

private:
	int interval_ms = 0;// Frame interval
    int timer = 0;		// Animation timer
	int idx_frame = 0; 	// Current frame index

private:
	Atlas* anim_atlas; 	// Pointer to shared atlas
};

Button Class Design

A button can have three states: Idle, Hovered, and Pushed. Understanding the transitions between these states is key to implementing input logic:

Accordingly, we need to handle three types of input events: mouse movement, left mouse button press, and left mouse button release.

void ProcessEvent(const ExMessage& msg)
{
	switch (msg.message)
	{
	case WM_MOUSEMOVE:
		if (status == Status::Idle && CheckCursorHit(msg.x, msg.y))
			status = Status::Hovered;
		else if (status == Status::Idle && !CheckCursorHit(msg.x, msg.y))
			status = Status::Idle;
		else if (status == Status::Hovered && !CheckCursorHit(msg.x, msg.y))
			status = Status::Idle;
		break;
	case WM_LBUTTONDOWN:
		if (CheckCursorHit(msg.x, msg.y))
			status = Status::Pushed;
		break;
	case WM_LBUTTONUP:
		if (status == Status::Pushed)
			OnClick();
		break;
	default:
		break;
	}
}

Extras: Animation Effects & Pixel Buffers

Color Basics

An image is made up of pixels, and each pixel’s color is determined by the three primary colors: Red, Green, and Blue—commonly referred to as RGB. These components are mixed at varying intensities to produce different colors. A simple Color structure can be defined as:

struct Color
{
    int r;
    int g;
    int b;
};

Essentially, an image is a 2D array of pixels. For example, a ``100*100 image can be represented asColor image[100][100]`. Rendering an image to the window involves copying this smaller array into the larger pixel buffer of the window. The drawing coordinates determine the pixel index.

In EasyX, the IMAGE class contains a pointer DWORD* m_pBuffer that points to the image’s pixel buffer. Internally, the pixel data is stored in memory from left to right, top to bottom. To access the color of a pixel at (x, y), you would use:

In array form: Color pix_color = image[y][x]
In EasyX: DWORD pix_color = buffer[y * width + x] (where width is the image width)

You can retrieve the pixel buffer using EasyX’s API: DWORD* buffer = GetImageBuffer(&image). Each DWORD element occupies 4 bytes and stores RGBA data (Red, Green, Blue, Alpha).

Implementing Image Flip Effects

Start by loading the original animation frames for the player facing left. Then define a new array for the flipped (right-facing) frames. Each left-facing image is horizontally flipped to create its right-facing counterpart.

Before flipping, we use Resize to allocate memory and set the size of the right-facing IMAGE objects. If an IMAGE object is not created via copy constructor or loadimage, its pixel buffer is uninitialized—so Resize also handles memory allocation.

Next, we retrieve the pixel buffers of both the left and right images and copy each pixel row by row. The horizontal flip is achieved by reversing the x-axis index: width - 1 - x.

Loading left-facing animation frames:

IMAGE img_player_left[6];

// Load player left-facing animation
for (int i = 0; i < 6; i++)
{
    static TCHAR img_path[256];
    _stprintf_s(img_path, _T("img/paimon_left_&d.png"), i);
    loadimage(&img_player_left[i], img_path);
}

Creating right-facing flipped frames:

IMAGE img_player_right[6];

for (int i = 0; i < 6; i++)
{
    int width = img_player_left[i].getwidth();
    int height = img_player_left[i].getheight();
    Resize(&img_player_right[i], width, height);	// Resize and allocate memory for right-facing image
    
    // Flip each row horizontally
    DWORD* color_buffer_left_img = GetImageBuffer(&img_player_left[i]);
    DWORD* color_buffer_right_img = GetImageBuffer(&img_player_right[i]);
    for (int y = 0; y < height; y++)
    {
        for (int x = 0; x < width; x++)
        {
            int idx_left_img = y * width + x;					// Source pixel index
            int idx_right_img = y * width + (width - 1 - x);	// Target pixel index
            color_buffer_right_img[idx_right_img] = color_buffer_left_img[idx_left_img];
        }
    }
}

Extracting RGB Components from Each Pixel

EasyX provides three macros—GetGValue, GetRValue, and GetBValue—to extract the individual RGB components from a pixel. However, note that the commonly used COLORREF type (a 32-bit integer representing color) is stored in memory as 0xbbggrr, meaning the red and blue channels are swapped. So when using EasyX macros, you need to reverse the R and B components:

DWORD pix_color = buffer[y * width + x];
BYTE r = GetBValue(pix_color);
BYTE g = GetGValue(pix_color);
BYTE b = GetRValue(pix_color);

Implementing Image Flicker Effect

The flicker effect is essentially a switch between the normal animation frames and a set of pure white silhouette frames. These silhouette frames can be dynamically generated by manipulating the pixel buffer.

To set a pixel to pure white, you can use the RGB macro to create a COLORREF value, then swap the red and blue channels using BGR, and finally add an alpha channel:

// RGB(255, 255, 255) gives 0x00FFFFFF
// Adding full opacity: (BYTE)(255) << 24 = 0xFF000000
// Combined: 0xFFFFFFFF = fully opaque white
DWORD white_pix = BGR(RGB(255, 255, 255)) | (((DWORD)(BYTE)(255)) << 24);

To implement the image flicker effect, the basic idea is to first define an array of silhouette animation frames. Then, for each original image frame, use Resize to match its size and allocate memory for the silhouette frame. After that, retrieve the color buffers of both the original and silhouette images. In a nested loop, check the color of each pixel—if the pixel is not already white, set it to pure white：

IMAGE img_player_left_sketch[6];

// Generate silhouette frames for left-facing animation
for (int i = 0; i < 6; i++)
{
    int width = img_player_left[i].getwidth();
    int height = img_player_left[i].getheight();
    Resize(&img_player_left_sketch[i], width, height);	// Allocate memory and set size
    
    DWORD* color_buffer_raw_img = GetImageBuffer(&img_player_left[i]);
    DWORD* color_buffer_sketch_img = GetImageBuffer(&img_player_left_sketch[i]);
    
   	for (int y = 0; y < height; y++)
    {
        for (int x = 0; x < width; x++)
        {
            int idx = y * width + x;
            if ((color_buffer_raw_img[idx] & 0xFF000000) >> 24)	// If pixel is not fully transparent
                color_buffer_sketch_img[idx] = BGR(RGB(255, 255, 255)) | (((DWORD)(BYTE)(255)) << 24);
        }
    }
}

Implementing Freeze Effect

Principle of Alpha Blending

EasyX doesn’t automatically handle transparency. When alpha blending is applied, the final pixel color is calculated as: Final Color = Source Color * Alpha + Destination Color * （1 - Alpha）. Here, Alpha is a float between 0 and 1. For example, overlaying a green image on a red background would blend the colors based on this formula:

Image Overlay Without Alpha Blending

Image Overlay With Alpha Blending and the Formula

To simulate a freeze effect, overlay a semi-transparent icy image on top of the current animation frame.

Implementation

// Copy current frame for processing
IMAGE img_current_frame(img_player_left[counter]);
int width = img_curent_frame.getwidth();
int height = img_curent_frame.getheight();

DWORD* color_buffer_ice_img = GetImageBuffer(&img_ice);
DWORD* color_buffer_frame_img = GetImageBuffer(&img_current_frame);

// Traverse the color buffer of the current frame and blend the non-transparent regions
for (int y = 0; y < height; y++)
{
    for (int x = 0; x < width; x++)
    {
        int idx = y * width + x;
        static const float RATIO = 0.25f;	// Blend ratio
        DWORD color_ice_img = color_buffer_ice_img[idx];
        DWORD color_frame_img = color_buffer_frame_img[idx];
        if ((color_frame_img & 0xFF000000) >> 24)	// 0xFF000000: Alpha channel
        {
            // Note: The color buffer stores pixel data in BGR order, so you need to swap the red and blue channels when retrieving color values.
            BYTE r = (BYTE)(GetBValue(color_frame_img) * RATIO + GetBValue(color_ice_img) * (1 - RATIO));
            BYTE g = (BYTE)(GetGValue(color_frame_img) * RATIO + GetGValue(color_ice_img) * (1 - RATIO));
            BYTE b = (BYTE)(GetRValue(color_frame_img) * RATIO + GetRValue(color_ice_img) * (1 - RATIO));
            // Blend with the Alpha channel
            color_buffer_frame_img[idx] = (BGR(RGB(r, g, b)) | (((DWORD)(BYTE)(255)) << 24);
        }
    }
}

Enhancement: Adding Highlight to Frozen State

To make the freeze effect more vivid, add a white scanning line from top to bottom. Only pixels with brightness above a threshold will be highlighted.

void RenderFrozenPlayer()
{
    static const POINT position = { 1075, 345};
    
    static int counter = 0;			// Animation frame index
    static int anim_timer = 0;		// Animation timer
    static int frozen_timer = 0;	// Freeze state timer
    static const int THICKNESS = 5;	// Scanline thickness
    static int hightlight_pos_y = 0;// Vertical position of the scanline
    static bool is_frozen = false;	// Whether the player is currently frozen
    
    // If not frozen, update animation timer
    if ((!is_frozen) && (++anim_timer % 3 == 0))
        counter = (counter + 1) % 6;
    // Update freeze timer and reset scanline position
    if (++frozen_timer % 100 == 0)
    {
        is_frozen = !is_frozen;
        highlight_pos_y = -THICKNESS;
    }
    
    // Draw shadow beneath the player
    putimage_alpha(position.x + (80 - 32) / 2, position.y + 80, &img_shadow);
    
    // Render different animation frames depending on freeze state
    if (is_frozen)
    {
        // Copy current frame for further processing
        IMAGE img_current_frame(img_player_left[counter]);
        int width = img_curent_frame.getwidth();
        int height = img_curent_frame.getheight();

        // Update vertical position of the highlight scanline
        highlight_pos_y = (highlight_pos_y + 2) % height;
        
        //  Get color buffers of the current frame and the ice overlay
		DWORD* color_buffer_ice_img = GetImageBuffer(&img_ice);
		DWORD* color_buffer_frame_img = GetImageBuffer(&img_current_frame);
        
        for (int y = 0; y < height; y++)
        {
            for (int x = 0; x < width; x++)
            {
                int idx = y * width + x;
                static const float RATIO = 0.25f;		// Blending ratio
                static const float THRESHOLD = 0.84f;	// Highlight brightness threshold
                DWORD color_ice_img = color_buffer_ice_img[idx];
                DWORD color_frame_img = color_buffer_frame_img[idx];
                if ((color_frame_img & 0xFF000000) >> 24)	// Check alpha channel (non-transparent)
                {
                    // Note: Color buffer stores pixels in BGR order, so swap red and blue when extracting
                    BYTE r = (BYTE)(GetBValue(color_frame_img) 
                                    * RATIO + GetBValue(color_ice_img) * (1 - RATIO));
                    BYTE g = (BYTE)(GetGValue(color_frame_img) 
                                    * RATIO + GetGValue(color_ice_img) * (1 - RATIO));
                    BYTE b = (BYTE)(GetRValue(color_frame_img) 
                                    * RATIO + GetRValue(color_ice_img) * (1 - RATIO));

                    // If pixel brightness at scanline exceeds threshold, set it to pure white
                    if ((y >= hightlight_pos_y && y < = highlight_pos_y + THICKNESS)
                       && ((r / 255.0f) * 0.2126f + (g / 255.0f) * 0.7152f + (b / 255.0f) * 0.0722f 
                           >= TRESHOLD))
                    {
                    	color_buffer_frame_img[idx] 
                            = (BGR(RGB(255, 255, 255)) | (((DWORD)(BYTE)(255)) << 24);
                        continue;
                    }
                    color_buffer_frame_img[idx] = (BGR(RGB(r, g, b)) | (((DWORD)(BYTE)(255)) << 24);
                }
            }
        }
        putimage_alpha(position.x, position.y, &img_current_frame);	
    }
	else
        putimage_alpha(position.x, position.y, &img_player_left[counter]);
}

The brightness coefficients (0.2126, 0.7152, 0.0722) are based on a standard formula for perceived luminance.

Full Source Code

#include <graphics.h>
#include <string>
#include <vector>
using namespace std;

/* =============== Key Concepts ===============
* 1. Avoid blocking operations or heavy, time-consuming tasks inside the main game loop.
* 2. Difference between using a frame counter and a timer to control animation updates:
*    - Counter-based: Frame updates speed up on faster machines with higher refresh rates.
*    - Timer-based: Frame updates stay consistent across all machines, tied to real elapsed time.
* 3. Use the Flyweight pattern to optimize resource loading.
*/

const int WINDOW_WIDTH = 1280;
const int WINDOW_HEIGHT = 720;

const int FPS = 60;

const double PI = 3.14159;

const int BULLET_BASE_RADIUS = 100;
const int BULLET_RADIUS_CHANGE_RANGE = 25;

const int PLAYER_ANIM_NUM = 6;
const int ENEMY_ANIM_NUM = 6;

const int BUTTON_WIDTH = 192;
const int BUTTON_HEIGHT = 75;

bool is_game_started = false;
bool is_running = true;

#pragma comment(lib, "MSIMG32.LIB") // Links the Windows GDI+ library for advanced image operations
#pragma comment(lib, "Winmm.lib") // Links the Windows multimedia library

// Custom Transparent Image Rendering
void putimage_alpha(int x, int y, IMAGE* img);

// Optimize resources loading
class Atlas
{
public:
	Atlas(LPCTSTR path, int num)
	{
		// Load image frames
		TCHAR path_file[256];
		for (int i = 0; i < num; i++)
		{
			_stprintf_s(path_file, path, i);

			IMAGE* frame = new IMAGE();
			loadimage(frame, path_file);
			frame_list.push_back(frame);
		}
	}

	~Atlas()
	{
		for (int i = 0; i < frame_list.size(); i++)
		{
			delete frame_list[i];
		}
	}

public:
	vector<IMAGE*> frame_list;
};

Atlas* atlas_player_left; // Initialize in main()
Atlas* atlas_player_right;
Atlas* atlas_enemy_left;
Atlas* atlas_enemy_right;

class Animation
{
public: 
	Animation(Atlas* atlas, int interval)
	{
		anim_atlas = atlas;
		interval_ms = interval;
	}

	~Animation() = default;	// The atlas is shared, so we don't delete it here 
							// It should be released at a higher level (e.g., in main)
	// Play animation
	void Play(int x, int y, int delta_time)
	{
		timer += delta_time;
		if (timer >= interval_ms)
		{
			idx_frame = (idx_frame + 1) % anim_atlas->frame_list.size();
			timer = 0;
		}

		putimage_alpha(x, y, anim_atlas->frame_list[idx_frame]);
	}

private:
	int interval_ms = 0; // Frame interval
    int timer = 0; 		// Animation timer
	int idx_frame = 0; 	// Current frame index

private:
    Atlas* anim_atlas;	// Pointer to shared atlas
};

class Player
{
public:
	Player()
	{
		loadimage(&img_shadow, _T("img/shadow_player.png"));
		anim_left = new Animation(atlas_player_left, 45);
		anim_right = new Animation(atlas_player_right, 45);
	}

	~Player()
	{
		delete anim_left;
		delete anim_right;
	}

	void ProcessEvent(const ExMessage& msg)
	{
		if (msg.message == WM_KEYDOWN)
		{
			switch (msg.vkcode)
			{
			case VK_UP:
				is_moving_up = true;
				break;
			case VK_DOWN:
				is_moving_down = true;
				break;
			case VK_LEFT:
				is_moving_left = true;
				break;
			case VK_RIGHT:
				is_moving_right = true;
				break;
			}
		}

		if (msg.message == WM_KEYUP)
		{
			switch (msg.vkcode)
			{
			case VK_UP:
				is_moving_up = false;
				break;
			case VK_DOWN:
				is_moving_down = false;
				break;
			case VK_LEFT:
				is_moving_left = false;
				break;
			case VK_RIGHT:
				is_moving_right = false;
				break;
			}
		}		
	}

	void Move()
	{
		if (is_moving_up)
			position.y -= SPEED;
		if (is_moving_down)
			position.y += SPEED;
		if (is_moving_left)
			position.x -= SPEED;
		if (is_moving_right)
			position.x += SPEED;

		// Fix diagonal movement being faster than horizontal/vertical
		int dir_x = is_moving_right - is_moving_left; // Right is positive X direction
		int dir_y = is_moving_down - is_moving_up; // Down is positive Y direction
		double len_dir = sqrt(dir_x * dir_x + dir_y * dir_y);
		if (len_dir != 0)
		{
			double normalized_x = dir_x / len_dir;
			double normalized_y = dir_y / len_dir;
			position.x += (int)(SPEED * normalized_x);
			position.y += (int)(SPEED * normalized_y);
		}

		//  Clamp player movement within window boundaries
		if (position.x < 0) position.x = 0;
		if (position.y < 0) position.y = 0;
		if (position.x + FRAME_WIDTH > WINDOW_WIDTH) position.x = WINDOW_WIDTH - FRAME_WIDTH;
		if (position.y + FRAME_HEIGHT > WINDOW_HEIGHT) position.y = WINDOW_HEIGHT - FRAME_HEIGHT;
	}

	void Draw(int delta_time)
	{
		// Draw shadow before rendering the player
		int shadow_pos_x = position.x + (FRAME_WIDTH / 2 - SHADOW_WIDTH / 2);
		int shadow_pos_y = position.y + FRAME_HEIGHT - 8;
		putimage_alpha(shadow_pos_x, shadow_pos_y, &img_shadow);

		static bool facing_left = false;
		int dir_x = is_moving_right - is_moving_left;
		if (dir_x < 0)
			facing_left = true;
		else if (dir_x > 0)
			facing_left = false;

		if (facing_left)
			anim_left->Play(position.x, position.y, delta_time);
		else
			anim_right->Play(position.x, position.y, delta_time);
	}

	const POINT& GetPosition() const
	{
		return position;
	}

public:
	const int FRAME_WIDTH = 80;
	const int FRAME_HEIGHT = 80;

private:
	const int SPEED = 3; // Player movement speed
	const int SHADOW_WIDTH = 32;	

private:	
	IMAGE img_shadow; // Shadow beneath the player
	Animation* anim_left;
	Animation* anim_right;
	POINT position = { 500, 500 }; // Player position

	// Fix stuttering caused by asynchronous message handling and key input
	bool is_moving_up = false;
	bool is_moving_down = false;
	bool is_moving_left = false;
	bool is_moving_right = false;
};

class Bullet
{
public:
	Bullet() = default;
	~Bullet() = default;

	void Draw() const // Add 'const' after the member function: this method does not modify any member variables
	{
		setlinecolor(RGB(255, 155, 50));
		setfillcolor(RGB(200, 75, 10));
		fillcircle(position.x, position.y, RADIUS);
	}

public:
	POINT position = { 0, 0 };

private:
	const int RADIUS = 10;
};

class Enemy
{
public:
	Enemy()
	{
		loadimage(&img_shadow, _T("img/shadow_enemy.png"));
		anim_left = new Animation(atlas_enemy_left, 45);
		anim_right = new Animation(atlas_enemy_right, 45);

		// Spawn boundaries for the enemy
		enum class SpawnEdge
		{
			Up = 0,
			Down,
			Left,
			Right
		};

		// Randomly spawn the enemy on one of the four edges
		SpawnEdge edge = (SpawnEdge)(rand() % 4);
		// Generate specific random coordinates
		switch (edge)
		{
		case SpawnEdge::Up:
			position.x = rand() % WINDOW_WIDTH;
			position.y = -FRAME_HEIGHT;
			break;
		case SpawnEdge::Down:
			position.x = rand() % WINDOW_WIDTH;
			position.y = WINDOW_HEIGHT;
			break;
		case SpawnEdge::Left:
			position.x = -FRAME_WIDTH;
			position.y = rand() % WINDOW_HEIGHT;
			break;
		case SpawnEdge::Right:
			position.x = WINDOW_WIDTH;
			position.y = rand () % WINDOW_HEIGHT;
			break;
		default:
			break;
		}
	}

	~Enemy()
	{
		delete anim_left;
		delete anim_right;
	}

	bool CheckBulletCollision(const Bullet& bullet) // Add 'const' before the parameter: this argument will not be modified inside the function
	{
		// Treat the bullet as a point and check if it lies within the enemy's rectangle
		bool is_overlap_x = bullet.position.x >= position.x && bullet.position.x <= position.x + FRAME_WIDTH;
		bool is_overlap_y = bullet.position.y >= position.y && bullet.position.y <= position.y + FRAME_HEIGHT;
		
		return is_overlap_x && is_overlap_y;
	}

	bool CheckPlayerCollision(const Player& player)
	{
		// Use the center point of the enemy as the collision point
		POINT check_position = { position.x + FRAME_WIDTH / 2, position.y + FRAME_HEIGHT / 2 };
		bool is_overlap_x = check_position.x >= player.GetPosition().x && check_position.x <= player.GetPosition().x + player.FRAME_WIDTH;
		bool is_overlap_y = check_position.y >= player.GetPosition().y && check_position.y <= player.GetPosition().y + player.FRAME_HEIGHT;
		
		return is_overlap_x && is_overlap_y;
	}

	void Move(const Player& player)
	{
		const POINT& player_position = player.GetPosition();
		int dir_x = player_position.x - position.x;
		int dir_y = player_position.y - position.y;
		double dir_len = sqrt(dir_x * dir_x + dir_y * dir_y);
		if (dir_len != 0)
		{
			double normalized_x = dir_x / dir_len;
			double normalized_y = dir_y / dir_len;
			position.x += (int)(normalized_x * SPEED);
			position.y += (int)(normalized_y * SPEED);
		}

		if (dir_x > 0)
			facing_left = false;
		else if (dir_x < 0)
			facing_left = true;
	}

	void Draw(int delta_time)
	{
		int shadow_pos_x = position.x + (FRAME_WIDTH / 2 - SHADOW_WIDTH / 2);
		int shadow_pos_y = position.y + FRAME_HEIGHT - 35;
		putimage_alpha(shadow_pos_x, shadow_pos_y, &img_shadow);

		if (facing_left)
			anim_left->Play(position.x, position.y, delta_time);
		else
			anim_right->Play(position.x, position.y, delta_time);
	}

	void Hurt()
	{
		alive = false;
	}

	bool CheckAlive()
	{
		return alive;
	}

private: 
	const int SPEED = 2; 
	const int FRAME_WIDTH = 80;
	const int FRAME_HEIGHT = 80;
	const int SHADOW_WIDTH = 48;	

private:
	IMAGE img_shadow; 
	Animation* anim_left;
	Animation* anim_right;
	POINT position = { 0, 0 }; 
	bool facing_left = false;
	bool alive = true;
}; 

// Button base class
class Button
{
public:
	Button(RECT rect, LPCTSTR path_imag_idle, LPCTSTR path_imag_hovered, LPCTSTR path_imag_pushed) // load images
	{
		region = rect;
		loadimage(&img_idle, path_imag_idle);
		loadimage(&img_hovered, path_imag_hovered);
		loadimage(&img_pushed, path_imag_pushed);
	}

	~Button() = default;

	void Draw()
	{
		switch (status)
		{
		case Status::Idle:
			putimage(region.left, region.top, &img_idle);
			break;
		case Status::Hovered:
			putimage(region.left, region.top, &img_hovered);
			break;
		case Status::Pushed:
			putimage(region.left, region.top, &img_pushed);
			break;
		}
	}

	void ProcessEvent(const ExMessage& msg)
	{
		switch (msg.message)
		{
		case WM_MOUSEMOVE:
			if (status == Status::Idle && CheckCursorHit(msg.x, msg.y))
				status = Status::Hovered;
			else if (status == Status::Idle && !CheckCursorHit(msg.x, msg.y))
				status = Status::Idle;
			else if (status == Status::Hovered && !CheckCursorHit(msg.x, msg.y))
				status = Status::Idle;
			break;
		case WM_LBUTTONDOWN:
			if (CheckCursorHit(msg.x, msg.y))
				status = Status::Pushed;
			break;
		case WM_LBUTTONUP:
			if (status == Status::Pushed)
				OnClick();
			break;
		default:
			break;
		}
	}

protected:
	virtual void OnClick() = 0;

private:
	bool CheckCursorHit(int x, int y)
	{
		return x >= region.left && x <= region.right && y >= region.top && y <= region.bottom;
	}

private:
	enum class Status
	{
		Idle = 0,
		Hovered,
		Pushed
	};

private:
	RECT region;
	IMAGE img_idle;
	IMAGE img_hovered;
	IMAGE img_pushed;
	Status status = Status::Idle;
};

class StartGameButton : public Button
{
public:
	StartGameButton(RECT rect, LPCTSTR path_imag_idle, LPCTSTR path_imag_hovered, LPCTSTR path_imag_pushed)
		: Button(rect, path_imag_idle, path_imag_hovered, path_imag_pushed) {}
	~StartGameButton() = default;

protected:
	void OnClick()
	{
		is_game_started = true;
		mciSendString(_T("play bgm repeat from 0"), NULL, 0, NULL); // Play bgm repeatly
	}
};

class QuitGameButton : public Button
{
public:
	QuitGameButton(RECT rect, LPCTSTR path_imag_idle, LPCTSTR path_imag_hovered, LPCTSTR path_imag_pushed)
		: Button(rect, path_imag_idle, path_imag_hovered, path_imag_pushed) {}
	~QuitGameButton() = default;
protected:
	void OnClick()
	{
		is_running = false;
	}
};

void TryGenerateEnemy(vector<Enemy*>& enemy_list);
void UpdateBullets(vector<Bullet>& bullet_list, const Player& player);
void DrawPlayerScore(int score);

int main()
{
	initgraph(WINDOW_WIDTH, WINDOW_HEIGHT);
	mciSendString(_T("open mus/bgm.mp3 alias bgm"), NULL, 0, NULL); // load audio
	mciSendString(_T("open mus/hit.wav alias hit"), NULL, 0, NULL); 

	// Both the player and enemy constructors require atlas resources,
	// so atlas objects must be initialized before creating player and enemy instances.
	atlas_player_left = new Atlas(_T("img/player_left_%d.png"), PLAYER_ANIM_NUM);
	atlas_player_right = new Atlas(_T("img/player_right_%d.png"), PLAYER_ANIM_NUM);
	atlas_enemy_left = new Atlas(_T("img/enemy_left_%d.png"), ENEMY_ANIM_NUM);
	atlas_enemy_right = new Atlas(_T("img/enemy_right_%d.png"), ENEMY_ANIM_NUM);

	Player player; 
	vector<Enemy*> enemy_list;
	vector<Bullet> bullet_list(3); // Only three bullets are needed, so raw pointers are avoided to prevent memory leaks	
	
	ExMessage msg;
	IMAGE img_menu;	
	IMAGE img_background;	

	int score = 0;

	RECT region_btn_start_game, region_btn_quit_game;
	// ================ UI ================
	region_btn_start_game.left = (WINDOW_WIDTH - BUTTON_WIDTH) / 2;
	region_btn_start_game.right = region_btn_start_game.left + BUTTON_WIDTH;
	region_btn_start_game.top = 430;
	region_btn_start_game.bottom = region_btn_start_game.top + BUTTON_HEIGHT;

	region_btn_quit_game.left = (WINDOW_WIDTH - BUTTON_WIDTH) / 2;
	region_btn_quit_game.right = region_btn_quit_game.left + BUTTON_WIDTH;
	region_btn_quit_game.top = 550;
	region_btn_quit_game.bottom = region_btn_quit_game.top + BUTTON_HEIGHT;

	StartGameButton btn_start_game = StartGameButton(region_btn_start_game,
		_T("img/ui_start_idle.png"), _T("img/ui_start_hovered.png"), _T("img/ui_start_pushed.png"));

	QuitGameButton btn_quit_game = QuitGameButton(region_btn_quit_game,
		_T("img/ui_quit_idle.png"), _T("img/ui_quit_hovered.png"), _T("img/ui_quit_pushed.png"));
	
	loadimage(&img_menu, _T("img/menu.png"));
	loadimage(&img_background, _T("img/background.png"));
	
	BeginBatchDraw();
	while (is_running)
	{
		DWORD start_time = GetTickCount();
		while (peekmessage(&msg))
		{
			if (is_game_started)
			{
				player.ProcessEvent(msg);
			}
			else
			{
				btn_start_game.ProcessEvent(msg);
				btn_quit_game.ProcessEvent(msg);
			}
		}	

		if (is_game_started)
		{
			player.Move();
			UpdateBullets(bullet_list, player);

			TryGenerateEnemy(enemy_list);
			for (Enemy* enemy : enemy_list)
				enemy->Move(player);

            // Collision detection: enemies vs. player
			for (Enemy* enemy : enemy_list)
			{
				if (enemy->CheckPlayerCollision(player))
				{
					static TCHAR text[128];
					_stprintf_s(text, _T("最终得分：%d！"), score);
					MessageBox(GetHWnd(), text, _T("游戏结束"), MB_OK);
					is_running = false;
					break;
				}
			}

			// Collision detection: enemies vs. bullets
			for (Enemy* enemy : enemy_list)
			{
				for (const Bullet& bullet : bullet_list)
				{
					if (enemy->CheckBulletCollision(bullet))
					{
						mciSendString(_T("play hit from 0"), NULL, 0, NULL);
						enemy->Hurt();
						score++;
					}
				}
			}

			//  Iterate through the enemy list and remove defeated enemies
			for (size_t i = 0; i < enemy_list.size(); i++) // Avoid using iterators since the container is modified during iteration
			{
				Enemy* enemy = enemy_list[i];
				if (!enemy->CheckAlive())
				{
					 // Swap with the last element and remove it
                    // * This is an efficient deletion method when element order doesn't matter
					swap(enemy_list[i], enemy_list.back());
					enemy_list.pop_back();
					delete enemy;
				}
			}
		}

		cleardevice();

		// ======= Draw  =======
		if (is_game_started)
		{
			putimage(0, 0, &img_background);
			player.Draw(1000 / FPS);
			for (Enemy* enemy : enemy_list)
				enemy->Draw(1000 / FPS);
			for (Bullet& bullet : bullet_list)
				bullet.Draw();

			DrawPlayerScore(score);
		}
		else
		{
			putimage(0, 0, &img_menu);
			btn_start_game.Draw();
			btn_quit_game.Draw();
		}

		FlushBatchDraw();

		DWORD end_time = GetTickCount();
		DWORD delta_time = end_time - start_time;
		if (delta_time < 1000 / FPS)
		{
			Sleep(1000 / FPS - delta_time);
		}
	}

    // Release atlas pointers after the main loop
	delete atlas_player_left;
	delete atlas_player_right;
	delete atlas_enemy_left;
	delete atlas_enemy_right;

	EndBatchDraw();
	return 0;
}

void putimage_alpha(int x, int y, IMAGE* img)
{
	int w = img->getwidth();
	int h = img->getheight();
	AlphaBlend(GetImageHDC(NULL), x, y, w, h, GetImageHDC(img),
		0, 0, w, h, { AC_SRC_OVER,0,255,AC_SRC_ALPHA });
}

void TryGenerateEnemy(vector<Enemy*>& enemy_list)
{
	const int INTERVAL = 100;
	static int counter = 0;
	if (++counter % INTERVAL == 0)
	{
		enemy_list.push_back(new Enemy());
	}
}

// Update bullet postions
void UpdateBullets(vector<Bullet>& bullet_list, const Player& player)
{
	// Create a pulsating effect for visual flair
	const double RADIAL_SPEED = 0.0045; // Speed of radial oscillation
	const double TANGENT_SPEED = 0.0055; // Speed of tangential rotation

	double radian_interval = 2 * PI / bullet_list.size(); // Angular spacing between bullets

	// Update each bullet's position based on the player's location
	POINT player_position = player.GetPosition();
	double radius = BULLET_BASE_RADIUS + BULLET_RADIUS_CHANGE_RANGE * sin(GetTickCount() * RADIAL_SPEED);
	for (size_t i = 0; i < bullet_list.size(); i++)
	{
		double radian = GetTickCount() * TANGENT_SPEED + radian_interval * i;
		bullet_list[i].position.x = player_position.x + player.FRAME_WIDTH / 2 + (int)(radius * sin(radian));
		bullet_list[i].position.y = player_position.y + player.FRAME_HEIGHT / 2 + (int)(radius * cos(radian));
	}
}

void DrawPlayerScore(int score)
{
	static TCHAR text[64];
	_stprintf_s(text, _T("当前玩家得分：%d"), score);

	setbkmode(TRANSPARENT);
	settextcolor(RGB(255, 85, 185));
	outtextxy(10, 10, text);
}

Reflection and Summary

Although this project was developed largely based on beginner-level intuition without much architectural planning, I still learned a great deal. The instructor started with the overall game framework and gradually refined each module, clearly demonstrating the problems encountered in each part and the thought process behind solving them. This was highly valuable for my own development practice.

I also gained a deeper understanding of how animations work at the pixel level, supplemented my knowledge of color and image buffers, and reviewed key concepts like vector motion and 2D collision detection. Through a simple yet hands-on example, I finally grasped the purpose of the Flyweight pattern and design patterns in general. It often felt like a moment of sudden clarity—like fog lifting to reveal the sky.

Looking ahead, there are two areas I need to explore further. First is 3D collision detection and related topics. Although I studied them in school through traditional textbook exercises, I didn’t encounter any real development examples, so my memory is vague and I feel like I’ve forgotten most of it. Second is design patterns in game development. Back then, I read the books and answered questions in a very mechanical way, often feeling lost and confused. I plan to continue learning from this instructor’s design pattern courses to gain a more practical and intuitive understanding through real-world application.

【C++ Game Dev from Scratch】Fundamental

Thu, 18 Sep 2025 09:11:30 +0200

Table of Contents

Overview

Tech Stack：C++ + EasyX

Project Goal: Set up the EasyX environment and complete two small demos (a circle that follows the mouse, and a tic-tac-toe game). Understand the basic structure of a game loop.

Course Source：Bilibili-Voidmatrix

Environment Setup

EasyX: Just search for “EasyX” and download it directly from the official site.

To use EasyX functions, include <graphics.h> in your header file.

Demo1 - Circle Follows Mouse

Design Approach

Create a window and set up the main game loop
Draw a circle that follows the mouse
Optimize rendering using double buffering

Development Steps

Initialize Window and Main Loop

Use initgraph() to initialize the window, and a while (true) loop to prevent it from closing instantly:

int main()
{
    initgraph(1280, 720);
    while (true)
    {
        
    }
    return 0;
}

This infinite loop is the basic framework for all games. Input handling and screen updates happen inside it:

while (true)
{
    // Handle player input
    // Update screen
}

Draw the Circle

Use solidcircle() to draw the circle.

Handle Input

Use peekmessage() to process input.

In EasyX, mouse movement, clicks, and keyboard input are all considered “messages.” These messages are stored in a queue. Each time peekmessage() is called, EasyX tries to pull one message from the queue. If successful, it returns true; otherwise, false. So we use another loop to keep pulling messages until the queue is empty.

According to the docs, peekmessage() requires a parameter msg, which is a pointer to an ExMessage struct. One of its members, message, indicates the type of input (mouse, keyboard, etc.). So the input handling looks like this:

while (true)
{
    ExMessage msg; 
    while (peekmessage(&msg))
    {
        if (msg == WM_MOUSEMOVE)
        {
            // Handle mouse movement
        }
    }
}

Clear Screen

If you don’t clear the screen, the ball will leave a trail as it follows the mouse. Use cleardevice() before each draw.

Optimize Drawing with Double Buffering

Use BeginBatchDraw(), FlushBatchDraw(), and EndBatchDraw():

BeginBatchDraw();

while (true) // Main game loop
{
    // Handle input
    // Update game state
    
    cleardevice(); // Clear screen
    // Draw
    FlushBatchDraw();   
}

EndBatchDraw();

Key Functions

initgraph() – initialize graphics window
peekmessage() – get mouse movement messages
cleardevice() – clear screen
solidcircle(x, y, r) – draw circle
BeginBatchDraw(), FlushBatchDraw(), EndBatchDraw() – double buffering

Concepts

EasyX Coordinate System

Origin is at the top-left of the screen. X increases to the right, Y increases downward.

Render Buffer

Think of the render buffer as a giant canvas. Drawing functions paint on it. Earlier drawings can be covered by later ones. cleardevice() fills the canvas with the current background color (default is black).

BeginBatchDraw() creates a new invisible canvas. All drawing happens on this canvas until FlushBatchDraw() and EndBatchDraw() swap it with the visible one. This prevents flickering caused by frequent redraws.

Game Loop

A typical game loop repeatedly performs:

while (true)
{
    // Read input
    // Process data    
    // Render screen
}

Initialize game data before the loop (before BeginBatchDraw()), and release resources after the loop ends.

Demo2 - Tic-Tac-Toe Game

Game Description

Players take turns placing X or O on a 3 * 3 grid. If one player gets three in a row (horizontal, vertical, or diagonal), they win. If all nine cells are filled with no winner, it’s a draw. This demo supports local two-player mode only.

Design Approach

Three Core Elements in the Game Loop

Input: Handle mouse left-clicks. If a blank cell is clicked, place a piece.

Data Processing: Check for game-over conditions: three matching pieces in a line or full board. If the game ends, show a popup and exit the loop.

Rendering: Use line() to draw the grid and X pieces (diagonal lines), and circle() for O pieces. Display the current piece type in the top-left corner.

Data Structures

Board and Pieces: Use a 2D array char board_data[3][3] for the board. Use 'X' and 'O' for pieces, and '-' for empty cells.

Game Over Conditions

Win: Check all 8 possible winning combinations for both X and O.

Draw: If no '-' remains and no winner, it’s a draw.

Development Steps

Top-Down Approach

Start with the framework, then fill in details.

Game Loop Skeleton

Use bool running to control the loop. Use CheckWin() and CheckDraw() to determine game status.

bool running = true;
ExMessage msg;

BeginBatchDraw(); 
while (running) // Main game loop
{

    while (peekmessage(&msg)) 
    {
        // Input
    }
    // Data processing
    if (CheckWin('X'))
    {
        // Pop up message and end the game
        MessageBox(GetHWnd(), _T("X Player wins"), _T("Game over"), MB_OK);
        running = false;
    }
    else if (CheckWin('O'))
    {
        // Similar logic to the above
    }
    else if (CheckDraw())
    {
        // Similar logic to the above
    }
    
    cleardevice(); 
    // Draw all the objects
    DrawBoard(); 
    DrawPiece(); 
    DrawPrompt(); 
    
    FlushBatchDraw(); 
}
EndBatchDraw();

Input Logic

Mouse coordinates are in pixels. Convert them to grid indices:

int x = msg.x; // Pixel indices of mouse
int y = msg.y;

int index_x = x / 200; // Grid indices of mouse
int index_y = y / 200;

Then place the piece and switch to the other type.

Data Processing Logic

CheckWin() uses brute-force to check 8 patterns.

CheckDraw() loops through all cells to check for '-'.

for (int col = 0; col < 3; col++)
{
    for (int row = 0; row < 3; row++)
    {
        if (board[row][col] == '-')
        {
            
        }
    }
}

Rendering Logic

Board: Use line() with pixel coordinates.

X Pieces: Use diagonal line() calls.

O Pieces: Use circle() with center offset by +100 pixels.

Drawing the prompt message: To make it work in more general coding environments, used some less common types and functions – but they work similarly to C’s printf().

1
2

static TCHAR str[64];
_stprintf_s(str, _T("Current piece type：%c"), current_piece);

Some font styling functions：

1
2

settextcolor(RGB(225, 175, 45)); // Set the text color to orange for better visual 									 //	emphasis;
outtextxy(0, 0, str); // Display the string at a specified position

Optimization

Last Piece Not Drawn: If win-check happens before drawing, the popup blocks rendering. So draw first, then check.

High CPU Usage: When a computer runs a while loop, it executes extremely fast—our main game loop can complete thousands of iterations in an instant, consuming a large amount of CPU time. For most displays with a physical refresh rate of only 60Hz, this leads to unnecessary performance waste. A quick and crude solution is to use sleep(15) to force the program to pause for 15 milliseconds after each loop. However, this isn’t recommended. As the game grows in complexity, the amount of computation per loop can vary, depending on how the operating system allocates CPU resources. This means the actual time spent per loop may differ. So instead, we should calculate how long each frame takes to process and dynamically adjust the sleep time afterward. The recommended approach is to set a fixed frame rate manually. To do this, we use the GetTickCount() function, which returns the number of milliseconds since the program started running.

while (running)
{
    DWORD start_time = GetTickCount(); // Get the start time of the current loop
    
    // Read input
    // Process data    
    // Render screen
  
	DWORD end_time = GetTickCount(); // Get the end time of the current loop
    
	DWORD delta_time = end_time - start_time; // Calculate the time interval
    // Dynamically assign sleep time based on the interval
    // Refresh the screen at 60 frames per second
	if (delta_time < 1000 / 60) // If the interval is less than the time for one frame, 								// sleep; Otherwise, no need to sleep
	{
		Sleep(1000 / 60 - delta_time);
	}
}
// Release resources
}

Full source code

#include <graphics.h>

char board_data[3][3] =
{
	{'-', '-', '-'},
	{'-', '-', '-'},
	{'-', '-', '-'}
};

char current_piece = 'O';

bool CheckWin(char c);
bool CheckDraw();
void DrawBoard();
void DrawPiece();
void DrawPrompt();

int main()
{
    //======= Initialization =======
	initgraph(600, 600);

	ExMessage msg;
	bool running = true;
		
	// Double buffering to prevent screen flickering
	BeginBatchDraw();
	
    //======= Main game loop =======
	while (running)
	{
		DWORD start_time = GetTickCount();

		while (peekmessage(&msg))
		{
            //======= Handle input =======
			// Detect mouse left-click messages
			if (msg.message == WM_LBUTTONDOWN)
			{
				// Calculate click position
				int x = msg.x;
				int y = msg.y;
				
				int index_x = y / 200;
				int index_y = x / 200;

                //========= Handle data processing =========
				// Place piece
				if (board_data[index_y][index_x] == '-')
				{
					board_data[index_y][index_x] = current_piece;	

					// Switch piece type
					if (current_piece == 'O')
					{
						current_piece = 'X';
					}
					else if (current_piece == 'X')
					{
						current_piece = 'O';
					}
				}
			}
		}		
		
		cleardevice();

		//===== Handle rendering =====
		DrawBoard();		
		DrawPiece();
		DrawPrompt();

		FlushBatchDraw();
		
        // Check for win condition -- placed after rendering to ensure the last piece 		  // is drawn
		if (CheckWin('X'))
		{
			MessageBox(GetHWnd(), _T("X player wins"), _T("Game over"), MB_OK);
			running = false;
		}
		else if (CheckWin('O'))
		{
			MessageBox(GetHWnd(), _T("O player wins"), _T("Game over"), MB_OK);
			running = false;
		}
		else if (CheckDraw())
		{
			MessageBox(GetHWnd(), _T("Draw"), _T("Game over"), MB_OK);
			running = false;
		}

        //======= Set frame rate（Optimization）=======
		DWORD end_time = GetTickCount();
		DWORD delta_time = end_time - start_time;
		if (delta_time < 1000 / 60)
		{
			Sleep(1000 / 60 - delta_time); // Optimize performance by capping frame 										   // rate at 60 FPS -- avoid running too fast
		}
	}
	EndBatchDraw();
	return 0;
}

bool CheckWin(char c)
{
	if (board_data[0][0] == c && board_data[0][1] == c && board_data[0][2] == c)
		return true;
	if (board_data[1][0] == c && board_data[1][1] == c && board_data[1][2] == c)
		return true;
	if (board_data[2][0] == c && board_data[2][1] == c && board_data[2][2] == c)
		return true;
	if (board_data[0][0] == c && board_data[1][0] == c && board_data[2][0] == c)
		return true;
	if (board_data[0][1] == c && board_data[1][1] == c && board_data[2][1] == c)
		return true;
	if (board_data[0][2] == c && board_data[1][2] == c && board_data[2][2] == c)
		return true;
	if (board_data[2][0] == c && board_data[1][1] == c && board_data[0][2] == c)
		return true;
	if (board_data[0][0] == c && board_data[1][1] == c && board_data[2][2] == c)
		return true;

	return false;
}

bool CheckDraw()
{
	for (int col = 0; col < 3; col++)
	{
		for (int row = 0; row < 3; row++)
		{
			if (board_data[row][col] == '-')
			{
				return false;
			}
		}
	}
	return true;
}

void DrawBoard()
{
	line(0, 200, 600, 200);
	line(0, 400, 600, 400);
	line(200, 0, 200, 600);
	line(400, 0, 400, 600);
}

void DrawPiece()
{
	for (int col = 0; col < 3; col++) 
	{
		for (int row = 0; row < 3; row++) 
		{
			switch (board_data[row][col])
			{
			case '-':
				break;
			case 'O':
				circle(200 * row + 100, 200 * col + 100, 100);
				break;
			case 'X':
				line(200 * row, 200 * col, 200 * (row + 1), 200 * (col + 1));
				line(200 * (row + 1), 200 * col, 200 * row, 200 * (col + 1));
			}
		}
	}	
}

void DrawPrompt()
{
	static TCHAR str[64];
	_stprintf_s(str, _T("Current piece type：%c"), current_piece);

	settextcolor(RGB(225, 175, 45));
	outtextxy(0, 0, str);
}

Reflection and Summary

This was my first time truly understanding the game loop, double buffering, coordinate systems, and frame rate control. I’ve used C++ and raylib before, but mostly by copying code without fully grasping it. This time, I followed the tutorial step by step, focusing on fast and simple implementation rather than object-oriented design. I used a top-down approach: build the framework first, then solve each problem one by one.

I plan to finish all of VoidMatrix’s tutorials to improve my coding skills and deepen my understanding of game development. I also want to align my coding style with industry standards.

C++ on Nullshow's Tech Blog

【C++ Syntax】Smart Pointer

Why Do We Need Smart Pointers?

Fundamental Principles of Smart Pointers

RAII

Using Smart Pointers Effectively

Potential Pitfalls of Smart Pointers

auto_ptr

How auto_ptr Works

unique_ptr

How unique_ptr Works

shared_ptr

How shared_ptr Works

Thread Safety Issues with shared_ptr During Copy Assignment

Limitation of shared_ptr: Circular References

What Is a Circular Reference?

How to Solve It: weak_ptr

Evolution of Smart Pointers in C++

Custom Deleters

Supplement 1: RAII in Practice – Lock Guards

Supplement 2: Understanding Memory Leaks

【C++ Game Dev from Scratch】Plant Star Brawl - Gameplay Layer

Development Workflow - Gameplay Layer

Key Steps and Solutions - Gameplay Layer

Building the Main Menu Scene and Character Selection Scene

Handling the Camera

Option 1:

Option 2:

Option 3:

Implementing the Main Menu Scene

Implementing the Selector Scene

Character Type Design Tip

Integrating the Camera into the Animation Class

Implementing the Scrolling Silhouette Background Effect

Physics Engine Implementation

Platform Class Design

Player Base Class Design

One-Way Platform Collision and Gravity Simulation

Gravity Simulation

One-Way Platform Collision Detection

Character Skill System

Functional Requirements

Bullet Deactivation and Removal Logic

Optimizing Bullet Removal

Full Bullet Base Class

Pea Bullet Class Design

Sun Bullet Class Implementation

Sun Bullet Ex Class Implementation

Skill System

Attack Cooldown Implementation

Invulnerability State Implementation

Particle System Implementation

Overall Code Review and Source Code

Scene Base Class

Main Function

Atlas Class

Camera Class

Timer and Vector2 Classes

Scene Subclasses: MenuScene, SelectorScene, GameScene

Player Base Class

Peashooter and Sunflower Subclasses

Bullet Base Class

PeaBullet, SunBullet, and SunBulletEx Subclasses

Particle Class

Platform Class

StatusBar Class

Full Source Code

Reflection and Summary

【C++ Game Dev from Scratch】Plant Star Brawl - Framework Design

Overview

Core Gameplay

Design Approach

Using Multiple Header Files

Designing the Game Framework

Object/Class Design

Development Workflow - Framework

Key Steps and Solutions - Framework

Scene System Design

Scene Base Class

MenuScene Class (Main Menu Scene)

`auto_ptr`

How `auto_ptr` Works

`unique_ptr`

How `unique_ptr` Works

`shared_ptr`

How `shared_ptr` Works

Thread Safety Issues with `shared_ptr` During Copy Assignment

Limitation of `shared_ptr`: Circular References

How to Solve It: `weak_ptr`

Integrating the Camera into the `Animation` Class

`Scene` Base Class

`MenuScene` Class (Main Menu Scene)

Implementing the `Atlas` Class

Implementing the `Animation` Class

Implementing the `Vector2` Class