Creating something from scratch is one of the best ways to learn—and that's precisely what I did when I decided to build Dakon Clash, a digital board game. Inspired by an Indonesian traditional game using beads and fused with elements of Reversi, this project wasn’t just a fun way to engage with friends but also an ambitious playground for learning React Router v7 (aka Remix).

Here’s a peek into my journey—the triumphs, mistakes, and lessons I learned along the way.

Why React and Remix?

React has been my go-to framework at work, so sticking with it felt natural. When Remix (React Router v7) came out, I saw this as the perfect opportunity to kill two birds with one stone: learn Remix and build something I genuinely cared about. There’s no better way to learn than by diving into a project, especially when it’s challenging and fun. Spoiler alert: it was both.

What’s New in Remix (React Router v7)?

Remix merged into React Router, becoming React Router v7—a full-fledged framework. One standout feature that benefited my project was the routing. This allowed me to separate the board and controls into independent files, rendering them independently. The modular design improved maintainability and made the project easier to work with as it grew. It’s these little changes that made Remix such a joy to use.

Wrestling with State Management

State management is the heart of any interactive application, but I underestimated just how tricky it could get. Here’s how my state management journey evolved:

Monolithic Chaos

I started by throwing everything into zustand. I thought, "Hey, why not use a centralized store for everything?" At first, this approach worked, but as the game grew, so did the complexity. Debugging became a nightmare—it was harder to debug than to add features, which says a lot.

The All-in-One Engine

Next, I refactored everything into an EngineClass. This represented the entire game: board state, game logic, player interactions, everything. While it worked better than the previous version, the class became enormous and unwieldy. When I tried to set the state for other objects, recursion issues crept in, creating a tangled web of dependencies.

Breaking It Down

Finally, I took a step back and broke the engine into smaller, more manageable pieces. I separated the logic into distinct classes: Board, Player, GameMaster, and Engine. The zustand store was now only responsible for holding the board state. This modular approach brought clarity and opened the door for future features like multiplayer, playback, and a bot engine.

The Lesson:

Don’t overcomplicate things. I made the mistake of focusing too much on details without seeing the bigger picture. Simplicity isn’t just elegant—it’s practical. Refactoring may feel like starting over, but it’s an essential part of the process.

Designing the Game

UI/UX design wasn’t something I’d done much of before, so I kept it simple. My brainstorming tool of choice? MS Paint. Yes, really.

I drafted version 0 of the UI in Paint and used it as a rough blueprint. To refine this further, I used Vercel's v0.dev to improve the design and structure. But, Writing the actual code from these drafts was where the learning really happened. It wasn’t perfect, but it was mine, and the process was rewarding.

Here's the first version

Game Logic: Turning Ideas into Code

Creating the game logic was my favorite part. I started by drafting pseudo-code for the game’s rules. The core idea revolves around placing beads into cells, triggering chain reactions when cells reach a certain threshold, and flipping opponent cells to your color. The challenge lay in converting these mechanics into code while keeping it efficient.

One highlight was implementing the logic for analyzing the board and making weighted decisions. While it’s not perfect yet (and the AI is still a work in progress), I’m proud of how far it’s come. Converting a mental picture into working code was a satisfying challenge.

Lessons Learned

  1. Dive into a project to learn new tech. Remix became much more approachable because I had a real project to build with it. Learning through doing always wins.
  2. Think bigger but keep it simple. I overcomplicated things early on, which led to headaches. Sometimes, the simplest solution is the best.
  3. Refactor without fear. It’s easy to get attached to your first attempt, but don’t hesitate to rewrite if it’ll make your code better.
  4. Enjoy the process. Even with blockers and setbacks, I had fun creating Dakon Clash. That’s what matters most.

What’s Next?

Dakon Clash is far from finished. My modular engine opens up possibilities for multiplayer, playback, and a smarter bot engine. There’s always room for improvement, but I’m happy with what I’ve learned and built so far.

Conclusion

Building Dakon Clash wasn’t just about creating a game—it was about growing as a developer. If you’re thinking of tackling a side project, do it. You’ll learn, struggle, and grow. And who knows? You might end up with something you’re proud to share with the world.

Feel free to share your thoughts, feedback, or similar experiences in the comments. And if you want to check out the code, I’ll leave a link below. Thanks for reading!

The Game:
DakonClash Game

The Code:
DakonClash on Github

Author Of article : Muhammad Fahmi Rasyid Read full article