Engineering Hamieverse: From Prototype to a Scalable Card Game

Engineering Hamieverse:
From Prototype to a Scalable
Card Game

Hamieverse is a competitive turn-based card game with wallet-based player identity, an in-game economy, AI opponents, leaderboards, and online multiplayer. Each of these features had to be built under tight deadlines, with frequently changing requirements or priorities. The whole system had to scale from Alpha & Beta testing groups to an active player base running tournaments without going offline, and without each change breaking any of the systems. What we were provided with: the concept, artwork, and narrative.

The engineering described here, from the architecture to scaling decisions, to the way the system absorbed constant change, is Algoryte’s.

The Journey at a Glance

● Pre-Alpha: Proven the game with a complete loop but minimal features.

● Alpha: Turned the prototype into a game; introduced the first scaling and environment
discipline.

● Beta: The major hardening: most systems reach production form, the backend is
re-architected for scale, and the UI is fully decoupled.

● Tournament #1: Milestone event to test out real-time PvP built out for competitive play.

Approaching the Initial Architecture

The Hamieverse team came to us with a request to create a prototype they needed as soon as possible, and pre-alpha was about delivering exactly that: a complete, playable game loop.Players created accounts via an Abstract Wallet SDK and were admitted via whitelisting, with an OpenSea integration allowing Genesis NFT holders to bypass the whitelist. The collection and deck tools were basic but real, letting players view their full collection, archive cards, and apply a collection strategy across minted and non-minted cards. There was a simple store with a working transaction system and an introductory lootbox-buying flow, an all-time leaderboard reading from a single table, and a player profile showing in-game currency, CD balance, total cards, username, and matches played and won. Matches carried no rewards, the AI played its move with no awareness of the game state, and a single shared UI served every player regardless of faction.

Underneath all that, we were doing our homework. We expected Hamieverse to grow well beyond its first version – more players, more cards, more systems, and a steady stream of new requirements, so the real investment went into the parts that don’t show on screen. We adopted a simple, clean architecture for the whole system from the get-go so that it could scale, and we spent particular time on the database schema: defining and normalizing it around not only the elements already in the game, but the ones we could see coming.

The aim was a data model that could absorb new systems and features later without being torn
up and rebuilt. On the surface, much of Pre-Alpha stayed simple because it needed to go out
very quickly – the UI was tightly coupled to game logic, the backend was a prototype, there
was no caching, APIs used basic auth, data was read directly from the database, there was no
CI/CD, and a single environment handled build, test, deploy, and play. The depth went into the
foundation beneath it so that when it was time to scale, we were ready.

We moved quickly through all of it, because the priority was simple: get a real, playable game into players’ hands and let them vet the idea.

Unity: Building the Front-End & Game Architecture

The game is built in Unity for WebGL. In the Pre-Alpha and Alpha phases, our primary goal was simply to prove the game concept worked. To get playable builds into testers’ hands as fast as possible, we made a calculated decision to link the UI directly to the gameplay logic. While this meant any small change to the game rules would require rework around other elements of the game, it gave us the immediate development speed and user feedback we needed to validate the game at the beginning.

Once that early validation was complete, the introduction of real-time PvP matches in the Beta required a massive shift toward stability and performance. For robustness, we implemented the Clean Architecture, which included breaking down everything into smaller, manageable layers to optimize and organize the whole game code in Unity. This also supported the upcoming features and other anticipated changes.

We rebuilt our front-end framework with three key upgrades:

● We Separated the Visuals from the Core Logic: We updated our architecture to completely isolate the UI using controller interfaces. These act as an abstract boundary wall between the UI and the core systems, successfully removing the hard references that previously locked the frontend UI to the backend logic.

● Implementing State Machine Mechanics: We implemented state machine mechanics to enforce strict client-server state synchronization. This ensures that live match states remain perfectly synchronized and accurate on both players’ screens simultaneously.

● We Cleared Memory Bottlenecks: For our early prototypes, packing graphics and sound effects directly into the initial build allowed for rapid testing. However, as our card catalog and feature set expanded into a massive library, keeping everything in a single package would have bloated the download size. To support this growth, we migrated to Unity Addressables, allowing us to move our heaviest assets to cloud storage, keeping the initial game file lightweight and highly optimized.

Database & Caching: How We Evolved the Database and Caching Pipeline

When we first built the Pre-Alpha, our main goal was speed. To get a working version out quickly, the game simply read data directly from the database without any caching.

Once the number of players (and testers) began to increase, we were ready to upgrade the backend and database management approach with certain optimization techniques, so by stage Alpha, we used table partitioning to split the workload into a hot/cold table strategy. We routed constant, live match data to a narrow, high-speed “hot table,” while archiving older completed matches into separate “cold tables” that were rarely queried.

This sufficiently freed up the system and kept active gameplay smooth, allowing us to safely add longer match loops and more cards without causing lag. This strategy was later optimized even further by introducing Redis by the Beta stage. We moved our match, menus, store inventory, and leaderboard APIs into Redis cache with set schedules to flush data into the database.

Another useful introduction was read/write replicas of the database, which routed players checking profiles or claiming rewards to the corresponding replica based on the read/write action, reducing the overall load on the database and improving optimization and security. Here’s how Core Infrastructure Swaps Never Crashed the Game:

Normalized Data Design: We meticulously normalized our database schema further, with the addition of new features and other optimization requirements, across the missions, items, rewards, and store systems to allow for clean data reuse, allowing us to manage redundant data and improve data integrity.

Prisma & Stored Procedures: We built our data pipeline using Prisma on the backend, but rather than letting it generate queries on the fly, we used it as a secure pipeline to trigger optimized stored procedures inside the database.

How We Transformed Leaderboards into a Universal Ranking System

In the Pre-Alpha, we shipped a single scope, single metric leaderboard that read directly from one table. Simple, but loading every player’s history at once.

With the increasing number of players, we capped the leaderboard display to the top 100 players by Alpha, bounding our query costs significantly.

By the time we were reaching the Beta stage, we were ready to transform the leaderboard to a multi-metric (this allowed us to keep a record of wins, score, number of matches played, and total damage done) and multi-scope (to sort based on any given time range, current or historical), making it a super-dynamic system that was infinitely effective, but needed a well-rounded optimization approach. Here are the techniques we implemented:

Partitioned Tables & Redis Caching: For the Beta, an upgraded leaderboard UI and automated rewards were supported by a major backend overhaul to deliver instant load times. We did this by doing two things:
a. Time Partitioning for Tables: Routing live queries to a small, active partition while historical reads on archived ones
b. Top-N Caching: We cached the most frequently read slices (the top-N players) directly in Redis.

Generalized Schema: Rather than building separate systems for different competitive features, we designed a single, generalized schema from day one. The architecture tracked abstract entity IDs and metrics instead of limiting it to individual players. We built the core infrastructure just once and reused it to power multi-metric and multi-scope leaderboard and guild rankings without writing a single line of new backend code.

Server-Side Resets: Automated server routines trigger scheduled season resets, archiving active data partitions and clearing the Redis cache simultaneously.

Faction Wars Sync System

Factions serve as the massive, two-army global tug-of-war that players represent from day one.With several matches being played simultaneously, if a player had finished a hard-fought match and returned to the menu to find a stagnant scoreboard representing their faction, their personal contribution would not have felt impactful. The scoreboard needed to refresh continuously in real-time.

Here’s how we made this a satisfying, zero-latency experience in Alpha: the player’s score is added instantly to the accumulated faction score in Redis instead of the main database. The Main Menu UI reads directly from Redis to show real-time scores without any lag. Every 30 seconds, a background script saves these combined totals to the database, keeping it protected from constant traffic spikes.

How We Built a System for Dynamic Missions & Rewards Distribution

During the Pre-Alpha, rewards and progression mechanics had not been introduced yet; players simply played basic matches to test core functionality. To introduce progression for the Alpha, we launched a temporary, fixed set of daily and weekly missions that paid out rewards using the game’s two core currencies. However, because we hardcoded these transaction triggers directly into the backend to save time, any minor modification to a mission or reward payout required a manual code change and a full server redeployment.

As part of our scaling roadmap, we re-engineered this infrastructure for the Beta:

Automated Mission Creation: We decoupled missions from our application code entirely. To make things easier, an administrative dashboard was built to instantly deploy hundreds of mission variants without any code rewrites. By turning missions into database rows and moving their behavioural triggers into cached lookup tables, we shifted the workflow from manual code changes to simple database inserts.
Securing the Reward System: To protect the game economy from “double-grants” caused by transaction lag or button-mashing, we upgraded the Beta with a resilient, three-layered security pipeline. We implemented strict server-side entitlement checks to verify completion, backed by idempotency keys, making sure that the database processed the reward exactly once, no matter how many times a player resubmitted a claim request.

Building a Marketplace & Collectibles Management System

In the Pre-Alpha, our store was as minimal as it gets: a single page featuring a loot box. This setup was basic by design, built purely as a proof of concept to safely test our financial integration and transaction systems before scaling up the wider game economy.

Once we validated that, we completely overhauled the infrastructure for the Beta to support a full-fledged marketplace. We reinforced the backend with a secure, three-layered logging and verification pipeline to track purchases safely.

Alongside this security upgrade, we built a centralized collectible management system. By unifying all game assets under one master catalog, the same item can now be dynamically distributed as a mission reward, sold directly in the storefront, or tracked in a player’s inventory – all without requiring custom code for each new product.

Building a Flexible, Multichain Wallet Architecture

In the Pre-Alpha, we focused on a closed ecosystem for exclusive testers, relying strictly on the Abstract Wallet SDK for basic onboarding. We implemented a custom OpenSea integration that scanned for genesis NFTs, allowing verified holders to bypass early whitelisting requirements.

As we prepared to open the game to a broader player base for the Beta, we needed an architecture that could quickly integrate new wallets. We achieved that by decoupling the blockchain network requirements from our backend systems. Specifically, we built a frontend abstraction layer – a single frontend interface that standardizes the wallet data before sending it to the server. This way, integration of any new wallet becomes a frontend update.

This architectural shift successfully laid the technical foundation for the game’s upcoming
multi-chain evolution.

Upgrading the Gameplay AI System

As we expanded the game from early testing to a broader audience, our AI needed to evolve alongside it. In the Pre-Alpha, we kept things simple, using a basic script to verify that the core game rules and turn mechanics worked smoothly.

Once that foundation was solid, we used the Alpha phase to introduce context-aware rules so the AI could react to specific game situations.

Preparing for Beta meant it was time to create a genuinely competitive opponent. We shifted the AI from reactive logic to a predictive outcome-evaluation loop for every possible move the player could make. It predicts future turns and selects the strongest one, depending on the difficulty tier (easy, mid, and hard) selected by the player.

A few optimization techniques that came into play:

We Isolated the AI from the Live Match: To protect game performance during heavy calculations, we separated the decision-making pipeline from the active match. The live match never hitches, stutters, or experiences performance lag while the AI is calculating its next move.
We Shifted Controls to the Server: We moved all AI calculations and difficulty settings from the client application to our backend. This allows us to tune difficulty profiles or personalize them for individual players on the go.
We Formed the Foundation for LLM Integration: Centralizing this pipeline on the server gives us the exact framework needed for our upcoming version of AI; this would allow us to scale the AI’s strategic depth while using server-side validation to eliminate game-breaking errors.

The Introduction of Online Multiplayer by Beta Stage

This is where the game (and the development) got even more fun, because we had saved multiplayer specifically for Beta! We started simple: basic 1v1 random matchmaking with the regional locks removed so anyone, anywhere could be matched.

As we geared up for Tournament #1, we needed to evolve that into a fully featured competitive environment. We expanded the PvP surface area entirely, giving players the ability to host and join custom rooms, spectate matches, send and receive real-time invites, and maintain multiple card decks to switch up their playstyles against different opponents. This was made possible by two things:

● Custom Websockets Upgrade: During the Pre-Alpha phase, our WebSocket infrastructure was limited to basic player session tracking and connection monitoring. As we transitioned to the Beta phase, we upgraded this setup to handle dynamic, real-time signaling. This allowed the system to instantly route custom room invites and process player accept/decline responses with sub-millisecond latency.

● Performance Optimization via Redis: We wanted a live player directory that showed exactly who was idle, online, in a lobby, or mid-match – but we couldn’t let it hammer the database. We solved this by storing player statuses as a Redis hash keyed by player ID – ensuring that the online-list query is a single, instant read.

Gameplay & Feature Evolution

During the Alpha, we focused on making the gameplay more strategic and rewarding: we introduced new hero HP depletion and shield logic to extend matches into longer, more tactical exchanges. We also doubled the deck size from 10 cards to 20, giving players the freedom to add or remove cards dynamically.

To support these expanding features, we introduced a basic onboarding tutorial, added “under-construction” card previews to identify future content, and updated the main menu with a mini-leaderboard and an upcoming-missions panel alongside a detailed UI/UX revamp.

The Beta phase was all about adding the depth and polish necessary for competitive tournament play:

● Advanced Deck Customization: We integrated multi-filter deck editing within the collection window, allowing players to quickly sort through new cards.

● Dynamic Reward Systems: We introduced an entire ecosystem of perks, power-ups, and custom animations.

● Polished Match Lifecycle: We completely upgraded the post-match UI to better celebrate wins, dissect match rewards, and cleanly transition players back into the competitive lobby.

Live Operations & Admin Dashboard

As the game progressed with new players, we needed much deeper visibility into how people were interacting with the game compared to the basic analytics we tracked during the Alpha. By the Beta, we had built a suite of Admin Dashboard APIs that surfaced critical engagement metrics—like daily and monthly active users (DAU/MAU)—alongside real-time tracking for missions, leaderboard standings, store items, and match results.

To match this live data with professional operational control, we introduced a maintenance mode. This allowed our team to deploy system updates smoothly without causing unexpected user downtime.

Maturing Content Delivery & Deployment Pipelines

Our deployment strategy evolved naturally with the project. In the Pre-Alpha, we deliberately avoided rigid pipelines to keep our proof-of-concept flexible.

By the Alpha, we had split our environments into Dev, Staging, and Production to isolate each environment with stable testing builds at each stage. During the Beta, we had created the full CI/CD pipeline to automate our deployment and testing workflows, ensuring that all code changes could be safely verified and pushed across our isolated environments without disrupting the live game.

To achieve this seamless delivery, we optimized both our deployment pipeline and asset infrastructure:

● GitHub Actions: We integrated automated testing into our repository. Code is now automatically verified before any deployment, catching bugs early before they can reach a live environment.

● Isolated Environments on AWS EC2: We deployed dedicated virtual servers for each phase of the project. This structural separation ensures that heavy development work or testing spikes never interfere with production gameplay.

● Unity Addressables: Instead of forcing players to download a massive game file, we broke the assets down into versioned bundles. Now, updating a specific asset bundle only forces a download for that exact piece, drastically reducing patch sizes.

● S3 & CloudFront: We hosted our asset bundles on AWS S3 and paired it with the CloudFront CDN, ensuring incredibly low asset loading latency for players connecting from anywhere in the world.

● We Coordinated Client-Side Caching: We aligned the browser cache and the CDN to allow the game to download just once and run locally. When a new build goes live, automated invalidation rules trigger, updating only the files that actually changed.

How We Went from 4 Loading Screens to 1

Web games live or die by their first few minutes; every extra loading bar introduces massive player drop-off. To protect our onboarding funnel, we completely re-engineered how the game loads, cutting the number of distinct loading screens from four down to just one.

We did this by strategically sequencing how the game starts:

● We Overlapped the Login & Game Loading: We separated our architecture so the wallet connection and login screens run natively in React, while the core game runs with Unity WebGL. The moment a player opens the signup page, the Unity engine silently begins downloading assets in the background – completely absorbing the loading time while the user is simply typing in their credentials.

● We Streamlined the Tutorial Flow: The moment the login completes, the player instantly jumps into the tutorial. While they are playing through these early mechanics, the system uses that background time to quietly finish downloading the main menus, store items, and deep-game assets backstage.

The Optimization Principles, In Short

The same engineering patterns recur across this entire journey. We made deliberate architectural decisions at each phase to balance immediate speed against long-term scalability, ensuring every layer was decoupled to absorb higher loads with minimal friction.

By prioritizing loose coupling, database optimizations like Redis caching, table partitioning, and isolating our backend through stored procedures, we built a highly resilient foundation. The cumulative payoff is a system where new mechanics, wallets, store items, and missions can be added continuously – without requiring code rewrites, causing unexpected redeployments, or introducing visible regressions for the player.

What It Took as a Team & Where It Goes

None of these systems arrived in their final form on day one. Each started as the thinnest version that worked and was reshaped one layer at a time as load, scope, and design ambitions grew. The reason that was possible, and the reason the game stayed live throughout, is how we had anticipated its growth to a fully realized game with a large player base.

That same architectural direction shaped how the team worked. A lean engineering crew could simultaneously build new features and optimize existing systems in parallel on different layers without stepping on each other’s toes.

The project is currently in its Beta phase, with Tournament #2 and the on-chain portal ahead. Requirements like these will keep evolving, and both the architecture and the team are built to move with them.