📝 This article reads more like a note to my future self than a polished product summary. I wanted to keep the excitement, doubt, reframing, and small turns in thinking that shaped CreateCombat while it was being built.


CreateCombat key visual


Introduction


This article is a more personal record of how I built CreateCombat. The current CreateCombat project page in my portfolio is more product-facing, but this post keeps the less polished side of the story: where the idea came from, why I made certain choices, and how the project changed while I was still trying to understand what it should become.

For me, CreateCombat is not only about finishing a game. It became a place where daily life, family interaction, technical decision-making, and AI-assisted development all met in the same project. By the time it became playable, it was already different from the simple fighting game idea I first had in mind, and that difference is exactly why this article matters to me.



Where the Idea Came From


The starting point of this project was actually very ordinary.

During the Lunar New Year in 2026, while spending time with family and kids, I suddenly had the thought: I want to make a fighting game. It was not born from a formal product plan. It was just a direct creative impulse to build something I would personally want to play.

I have always liked fighting games, so my first instinct was simple: instead of making another project with a fixed cast, why not make a fighting game where players can build their own characters?

That idea was also connected to a frustration I already had. Many fighting games lock players into fixed rosters, and a lot of content arrives through paid DLC. If players want the full experience, the cost and the barrier to entry can become quite high. I wanted to explore a direction that felt more open and more approachable.



Turning the Idea into a First Design Brief


Once the idea appeared, I wrote down the rough shape of the gameplay in text and used the Gemini web app to help me turn it into a clearer design brief. The early direction was very direct:

  • a simple front-end web fighting game
  • two characters
  • CPU battles and local multiplayer
  • split keyboard controls
  • no networking at first, with more features added later

Looking back, this was a very practical way to begin. It was not fancy, but it forced me to state what the project should be before writing too much code.



Why I Ended Up Choosing Canvas


The next step was choosing the technical path.

I am most familiar with the .NET ecosystem, including ASP.NET, WPF, and Blazor, but I knew this project was supposed to feel like something you could play just by opening a URL. In that situation, the tools I knew best were not necessarily the tools that fit best.

Unity and Unreal are both powerful, but for a smaller 2D fighting project, they also bring a lot of weight and overhead. I wanted something lighter.

So I ended up choosing native Canvas. The reasons were straightforward:

  • I wanted a minimal but playable project
  • I wanted to use the project to practice core JavaScript and TypeScript skills more deeply
  • I wanted the game entry point to stay as light as possible in the browser

Among options like Phaser.js, Pixi.js, and vanilla Canvas, I chose to work directly with the Canvas API. That meant more systems had to be built by hand, but it also meant I understood the battle flow, collisions, animation states, and rendering pipeline much more clearly.



How AI Collaboration Changed the Pace of Development


Once the technical direction was set, the next layer was the toolchain.

At the time, I was using Google's Antigravity and also had GitHub Copilot. What stood out to me was how quickly the project could reach a playable state under this kind of AI-assisted workflow.

A lot of the early time was not spent typing every implementation detail manually. Instead, it went into refining requirements, clarifying behavior, and rewriting prompts until the output aligned with what I actually wanted. In other words, the slower part was often not coding itself, but expressing the design clearly enough.

That experience made one thing very clear to me: AI tools do not replace development judgment. They amplify it. If the direction is vague, they stay vague with you. If the direction is clear, they can move a project into a testable and playable state much faster than I originally expected.



After the First Playable Version, I Felt Strangely Empty


To be honest, after the first version was playable, I felt a little empty for a while.

If you compare pure visuals or existing popularity, the market already has many mature fighting game classics. Even after I had added the ability for players to import their own character assets, I still felt that something was missing.

The problem was not whether I could keep building. The question was whether the project had a reason to exist beyond being another small fighting game experiment.



The Moment I Reframed the Game's Value


Later, while watching how the kids at home interacted, I started rethinking the direction of the project.

What if the game were not only about fighting each other? What if it could become something that adults and children could play, learn, and cooperate through together?

That question changed the design.

First, I pulled a quiz mechanic directly into the combat loop. The idea was to encourage answering, attach a cost to wrong answers, and make not answering even more costly, so players would actually engage with the questions instead of treating them as decorative UI. That gave the game another layer beyond simple combat.

Then I noticed something else: traditional fighting games naturally create winners and losers. For adults, that can be part of the appeal. For children, it can also become the starting point of conflict. So I added a two-player co-op boss mode with hostage rescue, giving players a shared goal instead of only a reason to defeat one another.

In that mode, I deliberately wanted the boss to feel threatening. Players should not be able to rely only on basic offense and defense. They should have to combine the quiz system with the combat system. That is when the quiz mechanic stopped feeling secondary and started becoming part of the actual strategy.



What I Really Cared About in the End


I also kept the quiz bank flexible, allowing players to use built-in question sets or import custom ones with different difficulty levels.

That part mattered to me because it made the same game usable across different age groups and situations:

  • adults can bring more challenging questions
  • children can use friendlier ones
  • families, teaching settings, and interactive sessions can all tune the experience differently

That was important to me because I did not want CreateCombat to become a technical toy that only a small group of people could appreciate. I wanted it to become something people could actually use to play, laugh, and learn together.



Looking Back, What Did CreateCombat Become?


From a product point of view, CreateCombat eventually became a TypeScript + HTML5 Canvas 2D fighting game with a wider set of capabilities:

  • custom characters and custom assets
  • local PvP, CPU battles, PvE, tournaments, and online play
  • quiz-driven battle interaction
  • bilingual UI
  • BattleServer-based online synchronization
  • room to extend toward Windows EXE builds and a mobile version

But from a creative point of view, it became something else too: a way for me to practice how a very direct idea can grow into a project with its own design position and its own real usage context.

That is why I wanted to preserve this article. A project page can tell you what the game does. This post records why I made it, how I chose its direction, and what I gradually learned to care about while building it.



Closing Thoughts


For me, CreateCombat is not just about making a game. It is a development journey where impulse, family context, technical experimentation, and AI collaboration were all folded into one project.

If you are interested in fighting games, custom characters, or hybrid play-and-learn experiences, I hope you will continue to the project page next. That page is where the feature set and product framing are clearer. This article, on the other hand, is where I wanted to leave the human side of the work intact.


👉 Try CreateCombat