Phantom Protocol - Indie GameDev

Phantom Protocol - Indie Game Dev

2D cyberpunk action game with one-hit combat.
Self-taught development, design, and profiling.

Overview

For 1.5 year, I developed a video game on my own, through self-teaching of coding, designing, or profiling.

The game includes 3 levels, each with different gameplay, and a single narrative set in a retro-futuristic, cyberpunk, dystopian city.

Watch the video of the case study down below - or scroll down to read it below.

My role:

Indie Game Dev

Game Designer

UX Research

Skills

C#
Game Design
Level Design
Narrative Design
Graphic Design
Playtesting
Profiling

Time frame:

From September 2024

To March 2026

Have you ever had a dream project or idea that seemed just out of reach?
A movie you want to shoot, but you know nothing about lenses or cameras? Or a book you want to write, but don’t know where to start?

Well, that’s exactly where I found myself a few years back.

I had this idea for a video game I wanted to develop—a 2D platformer, metroidvania-style, set in a cyberpunk retro-futuristic city.

“Katana Zero", by Askiisoft

“Hotline Miami", by Dennaton Games, Abstraction

But I didn’t know how to code. I knew nothing about game engines, or even how to design levels.

Fast forward a year and a half later—the game is now finished and available online. It includes three playable levels with different gameplay loops, as well as cutscenes and dialogues for narrative design.

The game may not be perfect or revolutionary, but it’s the one I’ve always dreamed of making—and I built it entirely through self-teaching.

So in this video, I’m going to share how I managed to do it, along with a few tips to help you turn your own dream project into reality.

Let’s get started.

Part 1 - Why Making A Game?

To understand how I came up with this idea—and why it wasn’t a guaranteed success from the start—it helps to look at my background.

My background is not in game development. I’m currently a user researcher at Alibaba, one of China’s tech giants. My job is to help teams understand user behavior through interviews and surveys, so they can improve the experience of our apps—and I specifically work on games.

In Chinese e-commerce, gamification is extremely advanced. Entire games are embedded directly into the shopping experience. During my time at Alibaba, I worked on these systems, which are developed in ways very similar to traditional game studios.

Through this experience, I realized something: based on my UX background and my understanding of how games are made, with the right tools, I could probably build one myself.

I’ve always been passionate about games. Not necessarily a heavy player—I often don’t have the time—but I love understanding how games are made: the creative direction, the lore, the narrative, the music.

I love collecting official artbooks from my favorite games - here from Horizon: Zero Dawn, by Guerilla Games

So when I saw the possibility of creating a game myself, I started immediately.

Part 2 - Making the Game Step-by-step

Section 1 — Concept & Direction

Before touching any engine or code, I defined the creative direction.

I combined two main influences:

On one side: retro 80s visual culture and pixel art, 80s–90s Japanese anime style, arcade-era gameplay: platformer, hack-and-slash, metroidvania, synthwave music
On the other side: cyberpunk, retro-futuristic worlds, high-tech, low-life societies, megacities, neon ads, brutalist structures, cybernetics, drones, flying vehicles

“Akira” by Katsuhiro Otomo (1988)

“Blade Runner" by Ridley Scott (1982)

From this, the concept came naturally:

A hack-and-slash platformer set in a cyberpunk dystopian city, with a synthwave atmosphere.
Fast, lethal combat inspired by arcade games, and a 2D pixel-art visual style.

I also defined the level structure early on:

Level 1: Metroidvania-style exploration in a dystopian city
Level 2: Close-quarters combat arena in an underground rave club
Level 3: High-speed highway chase with flying vehicles

Gameplay for each level is different on purpose: I wanted to explore different gameplay loops to understand how they differ from a development perspective.

These three levels are tied together by a simple narrative:

You play as a cybernetically enhanced mercenary tasked with eliminating a mafia boss—making you an anti-hero, bringing justice through violence.

Section 1 — Concept & Direction

Section 2 — Self-Teaching & Training Pipeline

Before starting the project, I learned Unity and C# basics by building two small games:
a Snake clone and a Flappy Bird clone.

Once I felt confident, I moved on to my main project.

So I started with a solid free Unity course on YouTube focused on 2D platformers.

Why choosing Unity for the game engine?

I did some research at the time, and it seemed that this engine would provide good performance for a 2D platformer.
It is also one of the most common game engines, and many tutorials are available. So if I needed help, I could find it more easily than for Godot or GameMaker Studio.

Then I supplemented it with targeted tutorials for specific features: animation, UI, dialogue, enemy AI, camera systems, and input handling.

And when tutorials didn’t fully apply to my case, I used AI tools like ChatGPT and DeepSeek to adapt them.

For example, when I had to add new sounds on a new level, ChatGPT recommended adding a new AudioSource for each of them. It’s doable, and it allows strict control over volume and effects—but it wasn’t necessary for my relatively simple project.

Understanding your scripts, what’s inside them, and where the issue might be helps AI pinpoint problems more accurately.

To keep costs low, I used free resources:

Unity Asset Store, Itch.io, CraftPix for pixel art assets
Pixabay and Freesound for audio
Canva and MidJourney for AI-generated visuals
For pixel art editing, I used Piskel and Aseprite.
For simple animation, I sometimes used Hailuo AI.

Section 3 — Core Gameplay & Level Construction

I also included many elements inspired by East Asian cities.
There were two reasons:

First, cyberpunk draws heavily from 1980s Japan and East Asian aesthetics.
Second, I wanted to represent Hangzhou—the city I’ve lived in for nearly five years—which makes the project very personal.

Finally, two key cyberpunk elements were missing at first: rain and flying vehicles—both were later added to complete the atmosphere.

I started with Level 1: a cyberpunk Chinese city.

The environment was tile-based, using modular assets to build buildings and avoid repetition. I added props like vents, pipes, cables, and signage.

Section 4 — Character & Animation

For the player character, I used a sprite resembling a cyberpunk katana-wielding assassin, clearly inspired by anime like Ghost in the Shell.

This required a full animation set: idle, run, jump, fall, attack, hurt, and death.

For enemy design, I wanted different types with increasing difficulty so that players stay engaged. Even though difficulty increases, it remains manageable so players can learn quickly.

Enemies were designed as follows:

Melee enemies (street thugs) on the ground—low difficulty, easy to beat
Ranged enemies (police and drones) on upper platforms—able to detect from further away and shoot at players, making them more difficult. They are introduced progressively.

This also supports the narrative—security forces mainly control the upper layers of the city and ensure traffic flows, while ignoring what happens in the lower areas.

Combat is lethal: inspired by Katana Zero and Hotline Miami, both the player and enemies can die in one hit, resetting at checkpoints.

This creates tension and references classic arcade design.

Section 5 - Systems Scalability & Playtesting

As I expanded to Levels 2 and 3, I realized a mistake: my system of scripts was not scalable.

The player logic was reusable—but enemy variations required rewriting code.

This taught me the importance of thinking in systems—modular scripts that can be reused across levels.

So I redesigned my architecture with modular components:

Game state manager
Wave spawner
Dialogue manager
Audio manager
Boss systems
Input Manager
Camera controller
Menu Manager

This made the project more maintainable and reusable.

For example, Level 2 and Level 3 bosses use similar combat and health scripts. Their entrance logic is also similar: both appear after a wave is completed, starting as a simple animated object before being replaced by the full boss prefab.

However, Level 3 includes two entrance sequences and a unique destruction sequence, giving it a more cinematic feel.
Using a modular approach allowed me to reuse systems from level 2 to level 3, while still customizing behavior specific to Level 3.

Using a modular approach allowed me to reuse systems from level 2 to level 3, while still customizing behavior specific to Level 3.

This is also when I started playtesting the game regularly.

Using my background in user research, I organized internal playtests at my company with volunteers and gathered valuable feedback.

For example, players were having a hard time understanding what to do to unlock the next level. In truth, this information is given on the first introductory dialogue of the level, but let’s be honest: players rarely pay attention to those and want to jump straight into the action. But further in the level, they would be lost, and complain about it.

To solve this painpoint, I added an in-game pause menu with level’s objective to remind them what to do on this level. This significantly helped reduce their frustration, and would allow them to move into the second level.

In-game menu with level objective

UI for boss health, indicating which part of the boss to attack

Another example is on the level 3, players would not know which part of the car hit in order to inflict damage. So I changed the header on the health bar to “Car engine” clearly indicates that it is the engine of the car, and not the car itself that needs to be attacked.

Section 6 - Narrative, Audio, Cutscenes

This is where I started finalizing the narrative design of the game.

Dialogues and UI would also support the overall world-building effort, by explicitly naming objects or giving context to the mission's objective.

For example, the transition between level 2 - the nightclub - and level 3 - the highway chase - has the player character being on a motorbike, chasing the target that is running away. It would have been a bit weird to transition from one to the other without contextualizing it.

So I added a final dialogue at the end of level 2, where the fixer urges the player to take a bike and run after the target. I also added a cutscene where the player character is on a motorbike and added a SFX of engine starting, showing that the transition to riding motorbike happened off scene.

At the end of the level 2 (picture on the left), player character is still fighting on foot ; while on the level 3 (on the right), it is on a motorbike. The picture of player character on a motorbike (middle) used during the cutscene between the two levels is completely optional and does not affect gameplay, but it allows to add context to the game.

Such small but meaningful choices definitely added context and helped cohesion of the whole game.

Audio played a major role in immersion for the game. That’s why, right from the start, I defined a clear direction, with variation per level:

Atmospheric synthwave for exploration
High-tempo tracks for combat
Intense loops for boss fights

Level 3 Design Choice

As I started working on level 3 - the final level of the game - I came face to face with an important decision.

The last level was supposed to be a highway chase, this was very clear for me from the start.

But I also wanted it to be a fight with the final boss, an epic way to finish the game.

However, I couldn’t find visual assets of a car with a passenger shooting, or slashing, which could have been very useful to combine both the final boss fight + the highway chase.

So I added an extra “level 3”, exclusively for the final boss fight.
The background and a few gameplay mechanics are the same as for the highway chase, but this time there is no parallax effect and the scene is static.

This boss fight is supposed to be the final one and the toughest one, so boss attacks are very strong and it has the ability to teleport. To make the fight more difficult and to last longer. I also added some mid-fight AOE attacks.

Now the final boss fight looks like a real one, and the game finishes on a high note.

This is a good example of how I managed to realize my vision for the game, with the assets at my disposal, but sometimes also making concessions.

From a player perspective, the level 3 seems to be split up in two phases: first, fighting the final boss's car ; second, fighting the boss itself.

At this stage of the project, I was pretty much done. I had:

Three complete levels
Music, cutscenes, UI
Menus and credits

I then focused on optimization, testing, and polishing—before publishing the game on Itch.io.

Download the game for free on Itch.io ✌️

Part 3 - Workflow & Discipline

If I had one piece of advice: plan ahead.

Think of your game like a real product. In the tech industry where I work, it is common to come up with a PRD, a Product Requirement Document before starting a project.

It’s the same here for your game: having such a document ready could help you greatly.
Break your project into clear steps and actionable tasks. Track everything with a to-do list—this helps you stay consistent, especially after breaks.

Overall, the project took me a year and a half

2–3 hour focused sessions
I would work every evening and weekend for some period
and on some other period, I would work 2-3 times a week only

I could also take a long break away from the game, because of other ongoing projects or job responsibilities.

Listing all tasks would also allow me to distinguish complicated, tedious tasks, from the easy ones. Why?

It would help me maximize my efficiency by doing hard tasks when energy is high, and simple tasks when tired.
Similarly, to reduce your chances to drop out of your project, avoid starting those complex tasks without time to finish.

Final pieces of advice:

Take it slow—but stay consistent.
Rest, take breaks, see friends—but always come back to your project at the time you fixed yourself. Stay disciplined.

Part 4 - What Did I Learn

To wrap up, here are the key lessons I’m taking away from this project — especially for anyone building their first serious game.

First: think in systems, not features.
It’s tempting to build mechanics one by one — a dialogue script here, an enemy script there — but if you don’t think about architecture early, you’ll pay for it later. Designing flexible, reusable scripts and separating responsibilities — combat, UI, dialogue, spawning, scene flow — saves a huge amount of refactoring time. Modular systems are easier to debug, extend, and reuse across levels.

Second: use AI and tutorials as accelerators — not substitutes for understanding.
They’re extremely effective when you validate, adapt, and integrate thoughtfully. Always verify whether a problem is code, configuration, or architecture.

And finally: keep scope controlled but vision and effort consistent.
A focused, coherent small game beats a sprawling unfinished one. Clear pillars — aesthetic, gameplay, mood — guide decisions and prevent feature drift.

That mindset — systems thinking/modular design, AI as an assistant, and self-discipline — is what turned this from an idea into a working game.