BUILDING systems THAT WORK

Introduction

I built a complete game engine for Bagchal, the traditional Nepali board game, and developed AI agents using Negamax and Monte Carlo Tree Search (MCTS). What started as a final year project for college, turned into a deep dive into game playing AI, search algorithms, and performance optimization.

Purpose and Goal

Bagchal is a unique, asymmetric game with very little resources for AI development. I wanted to see if I could build an agent that could outplay me and hopefully other existing agents. I had to figure out many of the core concepts — from how to represent the board and moves, to how to design agents for a skewed game.

Spotlight

The biggest challenge was that standard approaches didn't work cleanly with Bagchal. I read through what sparse resources were available. One old paper published in the editorial collection Games of No Chance (Vol.3), was very helpful in understanding the game theory side of things, but it didn't provide any specific guidelines for building AI agents.

• Alpha-Beta Search Optimization: I started out with a simple Alpha-Beta Search (Negamax variant) and progressively added optimizations like Iterative Deepening, Transposition Tables, Principal Variation Search (PVS), Move Ordering with Killer and History Heuristics and so on.
• Free 8x Performance Gain: I implemented canonicalization of states based on symmetry (Bagchal's unique board has the same symmetry group as that of a square). This allowed me to reduce the overall search space by almost 8x with very little overhead.
• Monte Carlo Tree Search (MCTS) Enhancements: Standard MCTS rollouts are random, which failed here because the game's asymmetry heavily biased random play toward the Tigers. I solved this by swapping the random rollout for a shallow Alpha-Beta search, providing a much cleaner signal for the agent's decision-making.
• Numba JIT Compilation: Since MCTS performance depends on the number of simulations and that of Alpha-Beta Search on the depth, I used Numba (JIT compilation) to speed up slowest parts of the code. This allowed me to reach a reasonable number of simulations and search depth within a 1-second decision window.

A lot of the work involved experimenting, failing, and rethinking assumptions.

Current Status

The project is Open Source and freely available on GitHub for everyone.

Lessons Learned

This project forced me to go beyond toy projects and understand:

• How search algorithms behave in practice
• Trade-offs between different AI approaches
• How to optimize systems under constraints
• How to work through problems without clear guidance

It was the first time I built something that required both theory and engineering depth.

Introduction

Built for game nights and such. Guests join a room, vote on the queue, and playback stays in sync across devices on the same network.

Purpose and Goal

This was born out of a personal pain point: whenever friends gathered, we’d have three different phones trying to play music at once. I wanted to solve the "aux cord battle" in a democratic fashion, where the room acts as a single synchronized player that everyone can influence.

Spotlight

• Sync Challenge: Ensuring that player controls (play/pause/seek) and volume remained perfectly aligned across diverse devices was a core hurdle. I built a WebSocket-driven system that treats the server as the source of truth while relaying events between devices.
• State Persistence: I implemented a session management system that retains Room IDs and caches YouTube search results, ensuring that if a user’s browser refreshes or they temporarily lose signal, they step right back into the live experience without friction.

Current Status

I still use it every now and then, whenever I can. I've recognized a few issues which I'm planning to solve in a mini-refactor.

Lessons Learned

I learnt that real-time UX is less about raw throughput and more about graceful recovery. Making sure that the app behaves exactly how the users expect despite network issues is important for a seamless UX.

Introduction

Looking to understand Django Channels and real-time asynchronous communication better, I took over a project one of my friends had stalled and transformed it into a feature-rich messaging platform.

Purpose and Goal

The objective was to move beyond simple tutorial-level app and build a system that handled complex social features — like group permissions, file sharing, and real-time presence.

Spotlight

• Real-Time Layer: I utilized Redis (which Django made very easy to use) as a channel layer to facilitate instantaneous message delivery and status updates. This allowed for features like Typing Indicators and Read Receipts that feel snappy and responsive.
• Architecture & Deployment: To ensure the app was truly portable, I containerized the entire stack (Django, Redis, Postgres) using Docker. This handled the complexity of managing different environments for the WSGI (Django) and ASGI (Channels/Daphne) servers.

Lessons Learned

Chat is a stress test for data modeling. I learned how to manage complex relationships between users, private rooms, and groups, and the importance of Read Status tracking to maintain a consistent UI across different user sessions. It solidified my understanding of how to bridge the gap between traditional request-response web apps and persistent socket-based systems.