DEV Community: Nenad Nikolić

I Built a Multiplayer Card Game to Test My Own Game Backend SaaS

Nenad Nikolić — Tue, 21 Jul 2026 13:56:00 +0000

I recently released Meksiko, an Android version of a traditional multiplayer card game.

The game itself was not the only goal.

I built it as a real production client for TurnKit, my backend SaaS for multiplayer and connected games. Instead of testing the platform only through isolated demos, I wanted to build a complete game and discover which parts of the SDK worked well, which parts were awkward, and which features were still missing.

Google Play:
https://play.google.com/store/apps/details?id=com.turnkit.meksiko

Why build a complete game?

Small technical demos are useful, but they usually follow the ideal path.

A real game introduces problems that are easy to miss:

players disconnect
server events arrive while animations are running
turns time out
lists change remotely
UI state becomes stale
users close and reopen the application
authentication behaves differently in production
game rules require features the original API did not anticipate

Meksiko became both a game and an integration test for the platform.

The game architecture

The server is authoritative over the multiplayer session.

It controls important state such as:

connected players
player order
the current turn
game phase
submitted actions
votes and decisions
timeout handling
reconnection state

The Unity client receives updates and presents them through the UI, animations and local game objects.

In theory, this sounds straightforward:

Receive server state.
Update the local model.
Refresh the UI.
Play the appropriate animation.

In practice, coordinating these steps was one of the more difficult parts of the project.

AI was useful, but struggled with event-driven state

I used AI-assisted development during parts of the project.

It worked well for relatively isolated tasks:

writing asynchronous functions
generating request and response models
creating utility methods
reducing repetitive integration code
implementing clearly defined transformations
suggesting error-handling paths

It was much less reliable when reasoning about state that changed through server events.

A common incorrect assumption was that receiving a response or updating one object would instantly update every related collection and UI element.

For example, when the server changed the player list, the client still needed to:

receive the relevant event
deserialize the new state
replace or mutate the local collection
notify the presentation layer
rebuild or update the UI
handle removed and newly added players
avoid updating objects that were currently being animated

AI-generated code often skipped one or more of these steps.

It understood an asynchronous function such as:

PlayerList players = await client.GetPlayersAsync();

more reliably than a distributed event flow where several systems needed to react to the same update.

The difficult part was not writing async code. The difficult part was defining ownership of the state and deciding exactly which system was responsible for applying each update.

Server events should not directly control the UI

One important lesson was to avoid letting network callbacks manipulate the UI directly.

A tempting implementation looks like this:

client.PlayerJoined += player =>
{
    playerListView.AddPlayer(player);
};

This works initially, but becomes fragile once the game has animations, reconnects, scene changes and multiple event types.

A better flow is:

Server event
    ↓
Network adapter
    ↓
Local game state
    ↓
State-change notification
    ↓
Presenter
    ↓
View

The event updates the local model first. The UI then renders the resulting state.

This creates a single source of truth and makes it easier to handle reconnects or rebuild the entire interface from a server snapshot.

Async operations were easier to reason about

Request-response operations were generally much easier to implement and test.

For example:

MoveResult result = await gameClient.SubmitMoveAsync(move, cancellationToken);

if (!result.Success)
{
    view.ShowError(result.ErrorMessage);
    return;
}

ApplyServerState(result.GameState);

This code has a clear beginning and end.

The caller knows:

when the operation started
when it completed
whether it failed
which state was returned
when the UI may continue

Events are different. They can arrive at any point, may be duplicated, and may refer to state that has already changed.

That does not mean events should be avoided. Multiplayer games need them. But event-driven systems require stricter rules around ordering, ownership and idempotency.

Features I discovered were missing

Building Meksiko exposed several features that were either missing or not flexible enough.

Passing turns

The original turn system assumed that a player would perform an action before the next player became active.

Meksiko needed a proper pass action.

Passing is not merely an empty move. It can affect:

whether the player may act again
when a bidding phase ends
which player wins the current decision
what happens when every player passes
whether the server should immediately advance the turn

This required more explicit support in the turn API.

Better Google Play integration

Authentication worked, but the complete Google Play experience required more than signing in.

A production Android game also needs to consider:

silent sign-in
account linking
guest-account upgrades
restoring an existing account
profile names and avatars
Play Games Services behavior after reinstalling
login cancellation and failure states
keeping the game usable without Google sign-in

This showed me that authentication should be treated as a complete user flow, not simply an SDK method.

Reconnection and state recovery

A reconnecting client should not try to replay every event it missed.

It should request or receive an authoritative snapshot and rebuild the local state.

The important distinction is:

Events describe changes.
Snapshots describe truth.

Events are useful while the client is connected. Snapshots are safer after reconnecting or when the client suspects its local state is inconsistent.

What worked well

The project also validated several parts of the platform.

The asynchronous API was generally straightforward to consume from Unity.

The backend could manage:

multiplayer sessions
turn order
server-side game state
player replacement with bots
timeouts
reconnection
remote actions

Using a real game also helped simplify parts of the SDK that had previously been designed too generically.

A feature may appear flexible when designed in isolation but still feel awkward when used repeatedly inside gameplay code.

The biggest lesson

The most important lesson was that a multiplayer SDK should not only expose network operations.

It should help developers maintain a consistent local representation of server state.

The difficult questions are usually not:

How do I send this request?
How do I deserialize this response?

They are:

Who owns this state?
Can this event arrive twice?
Can it arrive out of order?
What happens if the scene changes before it completes?
Should the client apply a delta or replace the state?
Can the same operation be safely repeated?
What happens when an animation is still using the previous state?

Those questions determine whether the client remains stable.

I may open-source the game

I am considering open-sourcing the Unity client later.

The project could serve as:

a complete multiplayer Unity example
a reference integration for TurnKit
an example of server-authoritative turn-based architecture
a practical demonstration of reconnects, events and async operations
a starting point for developers building card or board games

Before releasing it, I would likely separate game-specific code from reusable SDK integration and remove production configuration and credentials.

Final thoughts

Building a complete game was much more valuable than creating another isolated SDK demo.

It exposed missing features, unclear abstractions and assumptions that only became visible under real gameplay conditions.

AI-assisted development helped with local and well-defined asynchronous tasks. It was less effective at reasoning about distributed event-driven state, especially when server updates needed to propagate through several client systems.

The result is not only a released Android game. It is also a much better understanding of what the backend platform needs to provide.

I plan to continue improving both the game and the SDK, and I am interested in eventually publishing the client as an open-source reference project.

Whisper on Mobile Is Better Than I Expected, So I Built an Offline Notes App

Nenad Nikolić — Sat, 18 Jul 2026 13:54:50 +0000

I expected offline speech to text on mobile to be too slow, too heavy, or too unreliable for a real app.

After testing Whisper locally on Android, I changed my mind.

For long meetings or perfect transcription, small models still have limits. But for short voice notes, they are already practical.

That led me to build Hands Free Notes, an Android app for saving notes by voice with speech processed on device.

Why offline matters

Voice notes can contain private thoughts, tasks, work details, names, reminders, and personal information.

So the product promise is simple:

No account. No server. Speech processed on your phone.

That is easier for users to understand than a generic “AI powered notes app” pitch.

It also avoids backend cost, API keys, rate limits, and internet dependency.

Why Whisper fits this use case

For mobile notes, I do not need perfect transcription of a two hour recording.

I need useful transcription for short clips like:

Buy eggs and milk tomorrow
Remember to send invoice to Mark
Idea for cooking app: add voice controlled timers
Call dentist about appointment

This is where small Whisper models make sense.

The input is short. The context is simple. The user can edit the result if needed.

Core app flow

User speaks
Audio is recorded locally
Whisper transcribes it on device
Text note is saved locally
User can edit, search, copy, share, favorite, or delete it

The important part is that the app should not feel like a transcription demo.

It should feel like a normal notes app where voice is the fastest input method.

Product decisions that mattered

Short recordings work best

The app is designed for quick capture, not long interviews.

Short clips keep processing predictable and make retry painless.

Failure needs a simple path

Speech recognition will fail sometimes.

Bad UX:

Transcription failed

Better UX:

Could not understand clearly. Try again or type the note manually.

For notes, failure is acceptable if editing and retry are easy.

Keep the AI boundary small

Whisper only does speech to text.

Everything else is normal app logic:

Recording state
Silence detection
Countdown
Transcription status
Local storage
Search
Editing
Sharing
Monetization

This makes the app easier to debug and less dependent on AI behaving perfectly.

Privacy is a real feature

Offline transcription is not just a technical detail.

It is a product feature users understand immediately:

Your voice stays on your phone.

For a notes app, that matters more than adding another cloud sync feature too early.

Architecture

The architecture is intentionally boring:

Flutter UI
Native audio recording
Local WAV file
Whisper native layer
Transcription result
SQLite/local storage
Notes UI

The model converts audio to text. The app handles everything around it.

Monetization

I kept monetization simple:

Free daily notes
Rewarded ad unlock
One time unlimited purchase

For a small utility app, a subscription felt wrong. A permanent unlock fits better.

Where Whisper on mobile makes sense

Good fits:

Voice notes
Quick reminders
Personal logs
Hands free checklists
Cooking notes
Field worker notes
Offline forms
Simple journaling

Weak fits:

Long meetings
Noisy multi speaker audio
Perfect legal or medical transcription
Instant command systems that need very low latency

The best use cases are short, focused, and tolerant of small mistakes.

Final thought

Whisper on mobile is already good enough for useful offline apps if the workflow is narrow.

For voice notes, the value is simple:

Speak for a few seconds
Get local transcription
Save the note
Edit if needed

No account. No server. No complicated workflow.

Just faster note capture when typing is inconvenient.

Hands Free Notes Offline: Voice to Notes App Triggered by “Pickle”

Nenad Nikolić — Fri, 29 May 2026 13:19:00 +0000

Built an offline, privacy-focused Android app that lets you capture ideas instantly by saying one word — no phone in hand.

The Problem
I kept losing good ideas while driving, cooking, or multitasking because existing voice note apps required too many steps.

The Solution
Hands Free Notes Offline lets you activate once, say “Pickle” (or “Pico”), speak naturally, and it instantly saves both transcribed text and the full audio recording.

Key Features

One-word wake word activation
Fully offline & private (no forced cloud)
Lightweight and battery efficient
Free with rewarded ads + $4.99 one-time lifetime unlock

Technical Approach
I used sherpa onnx for KWS detection and whisper.cpp for local transcription. The main challenges were reliable background listening, minimizing false positives, and handling battery optimizations.

Try it for free on: https://play.google.com/store/apps/details?id=com.handsfree.notes

Kill the 'Double Coding Tax': A Hybrid Approach to Authoritative Multiplayer Turn-Based Games

Nenad Nikolić — Fri, 29 May 2026 01:08:02 +0000

Making a multiplayer turn based game means making client side code (Unity, Godot, or whatever engine you use) and the server side. This leads to remaking same systems for all turn based games, turn enforcment and for most games some hand hiding system, in addition to networking, authentication and other must have features. Also validating every function on server side, so doubling the work.

Using Mirror, FishNet or similar frameworks helps reusing code, but it forces you into one game server for every game and that becomes expensive fast. Turn based server could handle thousands of games if its well optimised.

Using Relay servers can speed up development, but you still implement turn enforcment, hand hiding and they leave you open to hacking and players ruining your games.

A Hybrid Approach That Cuts the Workload

Here’s how it works:

A specialized turn-based server handles the generic but critical parts that every game needs. Your client can simply react to clean events like “your turn started” or “turn changed”.
Hand hiding (and other hidden data) is solved in a generic way: you define lists and visibility rules via client-side configuration. The server automatically creates and filters those lists so each player only sees what they’re allowed to see.
Reconnecting players and other core features are handled reliably by the server.

This leaves you with only the specific game rules, which some simple games might not even need on the server. For more complex rules, you can use client voting consensus:

Every client validates moves in the background (players don’t have to click anything). When a move arrives as an event, other clients check if it’s legal based on the game rules you already wrote for the client. The server accepts the move if enough clients agree.

I haven’t seen any solution that supports this hybrid pattern, so I built my own. It’s probably too niche for big companies, but it fits indie and solo developers really well.

You can try it yourself with the live demo:
https://turnkit.dev/live-demo

Or check the docs at: https://turnkit.dev/docs

This aproach, like any, does have its trade offs. Multiple client can hack together and outvote an honest player, but a match with multiple hackers is rare and already ruined usually. In a 1x1 match hacker can vote fail at end of the game when he is about to lose, so some reputation tracking system would be needed in this case.

How I Built a Lightweight Turn-Based Relay Server with Java 25 Virtual Threads And Reconnect Handling

Nenad Nikolić — Sun, 19 Apr 2026 22:54:27 +0000

Turn-based multiplayer is deceptively hard. Here's how I designed a simple, fast, and cost-effective relay backend that auto reconnects dropped clients and keeps egress + resource usage low.

Building reliable turn-based multiplayer is painful. Enforcing turns, hiding hands/decks, handling votes, and especially managing disconnects and crashes can eat weeks of dev time.
I wanted something lean that "just works" for Unity and other clients without massive infrastructure costs. So I built TurnKit Relay around a few core principles:

Forward-only design (no complex state rollback)
Java 25 virtual threads for massive concurrency with low overhead
Move-based delta reconnects instead of full resyncs
Aggressive egress and memory optimization

The result? A relay that handles temporary drops and full game crashes gracefully while staying extremely cheap to run at scale.

Most real-time servers struggle with reconnects because they either

Resend the entire game state (high bandwidth)
Or require complex session management

I chose a simpler path: everything is forward-only. The server only replays missed moves since the client's last acknowledged move number.

Core Technical Choices

Java 25 Virtual Threads
Virtual threads made it possible to handle thousands of concurrent matches with near native thread per connection simplicity, without the overhead of traditional thread pools or reactive complexity. This keeps the code readable while scaling horizontally very cheaply.
Forward Only + Move-Based Deltas
On reconnect, the client sends RECONNECT { lastMoveNumber }. The server replays only the missed OnMoveMade events. No full state snapshots, no diffing engines — just sequential moves. This dramatically cuts egress costs and simplifies the backend.
Other Optimizations for Low Egress & High Density
Server managed lists with data masking (hands/decks stay hidden server side). Minimal JSON payloads. Early termination of stale matches.

These choices let a single modest instance support many more simultaneous matches than a typical WebSocket heavy setup.

If you're building a turn-based game and tired of wrestling with matchmaking, turns, hidden state, and reconnect logic, TurnKit handles the hard parts out of the box.

The biggest win wasn't just the performance, it was how much simpler the client code became. Developers only need to handle a single callback and save two small values for crash recovery if app crashed, if connection dropped it automatically reconnects and resyncs.

For full client implementation details (Unity + generic clients), check the official docs: https://turnkit.dev/docs/client-reconnection

I'm actively improving TurnKit and feedback is always welcome.

Turn-Based Game Server Options in 2026: An Honest Comparison for Indie Developers

Nenad Nikolić — Wed, 15 Apr 2026 21:32:47 +0000

Full disclosure: I'm the creator of TurnKit, a purpose-built authoritative relay for turn-based games. I've tried to keep this objective based on real development experience and public pricing (as of April 2026), let me know if I got something wrong or missed something.

For indie turn-based multiplayer, the core trade-off is development speed versus authority (cheat protection, turn enforcement, hidden data handling). The practical paths break down into four distinct approaches:

Custom Backend: Build full authority from scratch (e.g., Node.js/Go + database + WebSockets).
Per-Match Servers: Spawn headless game instances per match (Unity Netcode, Mirror, Godot equivalents).
Basic Relays: Pure message forwarding (Unity Relay, Photon PUN).
Authoritative Relay: Lightweight server that enforces turns and filters data without running the full game engine (TurnKit is currently the dedicated implementation in this niche).

General tools like Nakama or Colyseus require you to implement turn validation, hidden state, and signed results manually.

Pricing comparisson:

Basic relays tend to be the cheapest option at low scale, but they can become less attractive as player numbers grow or when cheating risk increases. An authoritative relay approach adds built-in protections while aiming to keep operational costs and complexity relatively low.

Like any solution, this approach has limitations. In 1v1 matches, client voting systems can allow griefing where a losing player falsely votes to end the match. Similar risks of collusion exist in games with three or more players. Because of these trust boundaries, this type of lightweight authoritative relay is generally not recommended for games involving real money

What backend or approach are you using (or considering) for your turn-based game? What has been your biggest pain point so far? Feel free to share in the comments. Did I get any of the pricings wrong or missed some option?

How to Add a Leaderboard to Your Unity Game for Free (No Monthly Fees)

Nenad Nikolić — Mon, 09 Mar 2026 13:41:14 +0000

How to Add a Leaderboard to Your Unity Game for Free (No Monthly Fees)

Every game is better with a leaderboard. But the moment you go looking for a leaderboard backend, you hit a wall.

The Problem With Existing Options

The popular choices all have tradeoffs that don't suit indie developers well.

**Firebase now has dedicated leaderboard support, but you're still on Google's infrastructure with Google's pricing — and no control over what changes next.

LootLocker has a genuinely generous free tier and is worth looking at. But you're still trusting a third party with your player data, and you have no control over pricing changes down the road.

Nakama is open source and free to self-host — but it's a full game server platform. If all you need is a leaderboard, the setup complexity is significant. It's a serious piece of infrastructure built for serious use cases.

The underlying frustration is simple: a leaderboard is not a complicated thing. It's a sorted list of scores. Why does setting one up take an afternoon?

What If You Just Hosted It Yourself?

Self-hosting sounds scary but the actual requirements for a leaderboard backend are modest:

A small server to run the API
A PostgreSQL database to store scores
A way to query rankings efficiently

That's it. No real-time sync, no complex state, no websockets. A leaderboard is fundamentally a read-heavy REST API backed by a database with a good index.

The total hosting cost for this on free infrastructure: $0/month.

Introducing RankDrop

RankDrop is an open source, self-hosted leaderboard backend built specifically for this use case.

Free forever — Apache 2.0, no licensing fees, no usage limits
Production ready — caching, connection pooling, atomic writes, health checks
Tiny footprint — GraalVM native image, ~118MB Docker image, ~50ms startup
Works with any HTTP client — Unity, Godot, mobile, web, desktop
Multiple leaderboard types — all-time, daily, weekly, monthly with automatic resets
Flexible scoring — high score wins, lowest time wins, or cumulative totals
Player moderation — ban players, remove individual scores
Webhook notifications — Discord or Slack alerts when top scores are beaten

You deploy it once, you own it forever.

How Long Does This Actually Take?

Here's an honest comparison:

Path	Deploy	Unity integration	Total
Manual self-host (this tutorial)	~20 min	60 min	~1.5 hours
RankDrop Unity Asset	included	included	60 seconds

This tutorial covers the manual path — it's straightforward and completely free. If you'd rather skip the hour entirely, the RankDrop Unity Asset handles both deploy and Unity integration in 60 seconds. Or use hosted one with free 20 CCU at turnkit.dev.

Deploying for Free on Koyeb + Aiven

The easiest zero-cost path is Koyeb (free app hosting) + Aiven (free managed PostgreSQL). Both have permanent free tiers — not trials.

Step 1 — Create a free PostgreSQL database on Aiven

Sign up at aiven.io
Create a new PostgreSQL service — select the free tier
Once provisioned, copy the connection string from the service dashboard

It looks like:

postgres://user:password@host:port/defaultdb?sslmode=require

Step 2 — Deploy to Koyeb

Sign up at koyeb.com
Create a new app → select Docker → use the image ghcr.io/brainzy/rankdrop:latest
Add your environment variables from .env.example, substituting the Aiven connection string for the database URL
Deploy

Koyeb will give you a public URL like https://your-app.koyeb.app. That's your leaderboard API endpoint.

Note: Koyeb's free tier sleeps after 60 minutes of inactivity and wakes in about 3 seconds on the next request. For most indie games this is fine — your leaderboard loads on the main menu, which wakes it up before the player notices.

Step 3 — Verify it's running

Open your Koyeb URL + /swagger-ui/index.html in a browser. You'll see the full interactive API docs. Create a leaderboard, submit a test score, query the rankings — all from the browser before writing a single line of Unity code.

Calling the API From Unity

RankDrop exposes a standard REST API. From Unity you call it with UnityWebRequest — the same way you'd call any HTTP endpoint.

The key endpoints:

What you want	Endpoint
Submit a score	`POST /api/v1/leaderboards/{slug}/scores`
Get top N scores	`GET /api/v1/leaderboards/{slug}/top?limit=10`
Get a player's rank + neighbours	`GET /api/v1/leaderboards/{slug}/players/{alias}?surrounding=3`
Top scores + player context in one call	`GET /api/v1/leaderboards/{slug}/combined`

The combined endpoint is the one you'll use most — it returns both the top of the leaderboard and the current player's position in a single request, which is exactly what a leaderboard UI needs.

Full request/response schemas are in the Swagger UI once deployed.

This is also where the hour goes in the manual path — writing the UnityWebRequest wrappers, handling errors and timeouts, managing the game key, building a reusable service class. It's not hard, just time consuming. The Unity Asset ships all of this pre-built.

Multiple Leaderboard Types

One of the most useful features for games is automatic periodic resets. RankDrop supports:

All-time — scores persist forever
Daily — resets every day at midnight UTC
Weekly — resets every Monday
Monthly — resets on the 1st of each month

You can run multiple leaderboards simultaneously — one all-time, one weekly, one for a limited-time event — each with its own slug, scoring strategy, and reset schedule.

Scoring Strategies

Three modes out of the box:

Best only — only the player's highest score is kept. Perfect for high score games.

Multiple entries - Store every score submission as separate entries

Cumulative — scores add up over time. Perfect for daily challenge points or XP totals.

Define more parameters if you want

Sorting by lowest time or highest value

min and max scores

archive options and many others

If You Outgrow the Free Tier

Koyeb + Aiven handles the vast majority of indie games comfortably. If you do hit the free tier limits, the next step is any VPS with Docker — Hetzner, DigitalOcean, Fly.io. RankDrop is a single Docker container and runs anywhere.

For serious scale, Oracle Cloud's free tier gives you 4 OCPU and 24GB RAM permanently — but most indie games will never need it.

What's Next

RankDrop is the leaderboard foundation of TurnKit — a no-code multiplayer backend for turn-based games I'm building, including relay, matchmaking, and player economy. If you're making a card game, board game, or any turn-based multiplayer game, you can use authorative relay for matches and leaderboards automatically scored by the server, try it on turnkit.dev.

The RankDrop repo is at github.com/Brainzy/rankdrop. Stars, issues, and feedback all welcome.

If you run into any issues deploying, drop a comment below or join the TurnKit Discord — happy to help you get it running.

If you are interested in other options for leaderboards check out https://www.turnkit.dev/leaderboard-options .

Tags: #gamedev #unity #opensource #java