https://nanommo.nenuadrian.com/2026-10-18 https://nanommo.nenuadrian.com/about/ https://nanommo.nenuadrian.com/ep001-kickoff/2026-10-14https://i.ytimg.com/vi/P5wjX2rVakg/maxresdefault.jpghttps://i.ytimg.com/vi/P5wjX2rVakg/maxresdefault.jpgnanoMMO - A software engineering perspective | Building nanoMMO #1Episode 1 of a series about building an MMO from scratch, with the focus on the engineering around the game: Docker, CI, benchmarking, Prometheus and Grafana, MySQL, Redis, and profiling. We sketch the architecture and why it uses Protocol Buffers, then set up a C++20 project written to Google's C++ style guide, with Abseil's status for errors, CMake, GoogleTest, an Ubuntu Docker build, a server image we can run anywhere, Doxygen docs, and GitHub Actions checking the style with clang-format and cpplint.https://www.youtube.com/embed/P5wjX2rVakg28592026-10-14mmonanommoc++cmakegoogletestabseilgoogle c++ style guidecpplintclang-formatdockergithub actionsdoxygengame serverprotobufredismysql https://nanommo.nenuadrian.com/ep002-window/2026-10-14https://i.ytimg.com/vi/IW51oEeHf8w/maxresdefault.jpghttps://i.ytimg.com/vi/IW51oEeHf8w/maxresdefault.jpgC++ game client with raylib, ImGui and shaders | Building nanoMMO #2Episode 2 of a series about building an MMO from scratch, with the focus on the engineering around the game. We start the C++ client: why raylib, a window and a frame loop, Dear ImGui through rlImGui, and our own menu. We render frames into a texture to test the renderer. The test passes on the Mac and fails in Docker, as there's no display to open a window on, so we give it a virtual one with Xvfb, and render on the CPU with Mesa's llvmpipe. Then we set up a 3D camera, write our first shaders in GLSL to light a cube for our character, lay down a ground of tiles, and move the cube with the keyboard. A test for the ground catches the pixels we read back coming out upside down, and we go over why.https://www.youtube.com/embed/IW51oEeHf8w40202026-10-14mmoc++raylibdear imguiimguirlimguiopenglglslshaders3dcmakegoogletestdockerxvfbllvmpipegame client https://nanommo.nenuadrian.com/ep003-multiplayer/2026-10-14https://i.ytimg.com/vi/Y6tjktKS2mk/maxresdefault.jpghttps://i.ytimg.com/vi/Y6tjktKS2mk/maxresdefault.jpgMultiplayer with protobuf and Asio | Building nanoMMO #3Episode 3 of a series about building an MMO from scratch, with the focus on the engineering around the game. We start the server: a contract between client and server in protobuf, compiled by protoc in the build, on the Mac, in Docker and in CI. We frame messages for a TCP stream, write an authoritative world with tests, accept clients with Asio, and sync everyone's cube between several clients. We also go over why we start with TCP, when UDP is the better choice, and how Asio lets us switch later.https://www.youtube.com/embed/Y6tjktKS2mk41362026-10-14mmoc++protobufprotocasiotcpudpnetworkinggame servermultiplayercmakedocker https://nanommo.nenuadrian.com/ep004-monitoring/2026-10-15https://i.ytimg.com/vi/HOY06IcWkvc/maxresdefault.jpghttps://i.ytimg.com/vi/HOY06IcWkvc/maxresdefault.jpgPrometheus and Grafana for a C++ game server | Building nanoMMO #4Episode 4 of a series about building an MMO from scratch, with the focus on the engineering around the game. We add metrics to our C++ server with prometheus-cpp: players online as a gauge, tick duration as a histogram, and bytes and messages as counters, with a test that pins the histogram's buckets. We write a bot that plays like someone at the keys, and start a swarm of them. Then Docker Compose runs the server, Prometheus and Grafana together, with the dashboard and data source provisioned from files in the repo. With three hundred bots online, the dashboard shows the bytes we send growing much faster than the players, and we go over why.https://www.youtube.com/embed/HOY06IcWkvc29842026-10-15mmoc++prometheusgrafanadocker composemetricsmonitoringobservabilitypromqlhistogramload testingbotsasiogame serverdevops https://nanommo.nenuadrian.com/ep005-accounts/2026-10-15https://i.ytimg.com/vi/bMKzW1yIpUU/maxresdefault.jpghttps://i.ytimg.com/vi/bMKzW1yIpUU/maxresdefault.jpgC++ game accounts with MySQL and Argon2id | Building nanoMMO #5Episode 5 of a series about building an MMO from scratch, with the focus on the engineering around the game. Our players get accounts. We run MySQL in Docker Compose with the schema in the repo, hash passwords with Argon2id through libsodium, and talk to MySQL from C++ through its C API, with prepared statements. Along the way, we go over SQL or NoSQL, salts and slow hashes, SQL injection, and integration tests against MySQL in a container, in CI too.https://www.youtube.com/embed/bMKzW1yIpUU28102026-10-15mmoc++mysqlargon2password hashinglibsodiumprepared statementssql injectiondocker composegame serveraccountssql vs nosqlintegration tests https://nanommo.nenuadrian.com/ep006-login/2026-10-15https://i.ytimg.com/vi/E4GcIf_dmOs/maxresdefault.jpghttps://i.ytimg.com/vi/E4GcIf_dmOs/maxresdefault.jpgC++ login server with Redis tokens | Building nanoMMO #6Episode 6 of a series about building an MMO from scratch, with the focus on the engineering around the game. Our players log in, with the accounts from episode five. A new login server checks passwords away from the game server's tick, and hands each login over through Redis as a one-time token that expires after thirty seconds. The game server takes the token, loads the player and saves where they are, so you come back where you left off. The client gets a login screen and names over the players, and the bots log in too. Along the way, we go over why logins get a server of their own, tokens in Redis or signed ones, and integration tests against MySQL and Redis, in CI too.https://www.youtube.com/embed/E4GcIf_dmOs41342026-10-15mmoc++login serverredishiredistokensmysqlgame serverauthenticationdocker composeintegration testsdear imgui https://nanommo.nenuadrian.com/ep007-characters/2026-10-15https://i.ytimg.com/vi/aBYvpPtpvag/maxresdefault.jpghttps://i.ytimg.com/vi/aBYvpPtpvag/maxresdefault.jpgMixamo animations in raylib with glTF and C++ | Building nanoMMO #7Episode 7 of a series about building an MMO from scratch, with the focus on the engineering around the game. Our cubes become characters. We take Mixamo's X Bot and Y Bot with an idle, a walk and a run, keep the files out of our public repo as Mixamo's terms ask, and convert them from FBX to glTF with FBX2glTF, in Docker. Loading them into raylib as they come doesn't work, and we see why: a skin per mesh, bones matched by their place in a list, and walks that carry the hips forward. A small glTF-Transform tool fixes all of it, and cuts the triangles to a tenth. The server sends each player's facing and whether it walks or runs, at the speeds of the clips, and the client blends the clips, smooths the positions between ticks and skins the characters on the GPU. And the bots run too.https://www.youtube.com/embed/aBYvpPtpvag31022026-10-15mmoc++raylibmixamogltfglbfbxfbx2gltfgltf-transformskeletal animationgpu skinningglslprotobufgame serverdocker https://nanommo.nenuadrian.com/ep008-performance/2026-10-15https://i.ytimg.com/vi/HeUPamUI6rc/maxresdefault.jpghttps://i.ytimg.com/vi/HeUPamUI6rc/maxresdefault.jpgProfiling a C++ game server with perf and Tracy | Building nanoMMO #8Episode 8 of a series about building an MMO from scratch, with the focus on the engineering around the game. We find out how many players our C++ server can take, and why. A bash script steps the bots up and reads the server's own metrics from Prometheus at each step: ticks per second, the tick's p50 and p99, and the bytes sent. The server falls behind past a thousand players. Then we profile it under that load with perf, in Docker, with frame pointers, the capabilities perf needs, and Brendan Gregg's flame graphs, and with Tracy, which shows each tick on a timeline. Both point at the broadcast, which serialised the whole world once for each client. We serialise it once a tick instead, share the bytes between the sessions with a gathered write, and lean on how protobuf reads two messages back to back. Run again, the benchmark keeps twenty ticks a second with twice the players, and we look at what's left: the kernel sending bytes that still grow with the square of the players.https://www.youtube.com/embed/HeUPamUI6rc25302026-10-15mmoc++performanceprofilingperfflame graphtracybenchmarkload testingprometheusgrafanadocker composeprotobufasiogame server https://nanommo.nenuadrian.com/ep009-tcp-vs-udp/2026-10-15https://i.ytimg.com/vi/8b_wbmr7XVM/maxresdefault.jpghttps://i.ytimg.com/vi/8b_wbmr7XVM/maxresdefault.jpgTCP vs UDP for a game server, under packet loss | Building nanoMMO #9Episode 9 of a series about building an MMO from scratch, with the focus on the engineering around the game. In episode three we picked TCP for everything, and said we'd measure UDP once we could. Today we can. Each world the server sends carries the time it was sent, and our bots look at how old their newest world is sixty times a second, like a client drawing frames, for Prometheus to scrape. netem, from Linux's traffic control, delays the server's packets and drops a share of them, with segmentation offload turned off so that it drops packets one by one. A benchmark steps the loss from none to ten percent. Over TCP, head-of-line blocking makes the worlds wait for each lost packet, and past a few percent, the server can't send fast enough at all. Then we send the world over UDP: the client sends its token again in a datagram, which tells the server who it is, and the players go out in parts that each fit in a packet, so IP doesn't have to split a datagram up. We measure again, and the client and the bots get their worlds over UDP by default, with TCP as the fallback.https://www.youtube.com/embed/8b_wbmr7XVM31072026-10-15mmoc++tcpudpnetworkingpacket lossnetemtchead-of-line blockingip fragmentationnatasioprotobufprometheusgrafanadocker composebenchmarkgame server https://nanommo.nenuadrian.com/ep010-monsters/2026-10-15https://i.ytimg.com/vi/6qhX6Z-tKqY/maxresdefault.jpghttps://i.ytimg.com/vi/6qhX6Z-tKqY/maxresdefault.jpgC++ MMO monsters: AI, health and levels | Building nanoMMO #10Episode 10 of a series about building an MMO from scratch, with the focus on the engineering around the game. Our world gets its first monsters. The skeleton comes from Quaternius, on Poly Pizza, in the public domain, so unlike the Mixamo characters it goes into our repo as it was downloaded, and the client loads it as it is: scaled by its bounding box, its clips found by name, and a walk made from its run. The server owns the monsters, spawns them, and runs a wander AI for them each tick, with a random generator the tests can seed. Players and monsters get health and levels, which everyone sees, and players get experience, saved in MySQL and sent to their own client alone, in the part of each update that's theirs. The client draws health bars and levels over everyone, and a frame with your own.https://www.youtube.com/embed/6qhX6Z-tKqY29532026-10-15mmoc++game servermonstersgame airaylibgltfquaterniuscc0protobufmysqldear imguihealth barlevels https://nanommo.nenuadrian.com/ep011-combat/2026-10-18https://i.ytimg.com/vi/knOkRrwOiTQ/maxresdefault.jpghttps://i.ytimg.com/vi/knOkRrwOiTQ/maxresdefault.jpgC++ MMO combat: swords, hits and respawns | Building nanoMMO #11Episode 11 of a series about building an MMO from scratch, with the focus on the engineering around the game. We fight the monsters from episode ten. Each player holds Quaternius's sword, attached to the hand's bone in the client, with a slash and a death from Mixamo. The space bar swings it, and the server decides what it hits, for how much, and who gets the experience. The monsters spot players near their home, run at them and swing back, and the dead play their death animation and lie there before they respawn.https://www.youtube.com/embed/knOkRrwOiTQ20042026-10-18mmoc++game servercombatgame airaylibgltfmixamoquaterniuscc0animationrespawn https://nanommo.nenuadrian.com/ep012-website/2026-10-18https://i.ytimg.com/vi/0mouU_3PfIw/maxresdefault.jpghttps://i.ytimg.com/vi/0mouU_3PfIw/maxresdefault.jpgLaravel game website in Docker: login, rankings | Building nanoMMO #12Episode 12 of a series about building an MMO from scratch, with the focus on the engineering around the game. Our game gets a website. We make a Laravel app with Composer, in Docker, so PHP doesn't have to be installed on our machine, and run it on FrankenPHP, a web server with PHP built in, as one more service in our Docker Compose stack, with its sessions in Redis. The front page ranks the players by experience, from the tables the game server saves them in, with the levels worked out like the game server does. Pico CSS styles the plain HTML from a CDN, so there's no CSS of our own and no npm build. Then accounts: you can create one on the website, log in and log out, on the game's own accounts table, with Laravel's validation, CSRF protection and rate limiting. The website hashes passwords with Argon2id with the login server's libsodium settings, so an account made on the website logs into the game, and the other way round. We go over sharing a database between two programs, why the website gets no migrations of its own, and the hash string that carries its own settings. Tests pin the levels and the hashes, and CI runs them.https://www.youtube.com/embed/0mouU_3PfIw28132026-10-18mmolaravelphpwebsitedockerdocker composefrankenphpmysqlredispico cssloginregistrationrankingsargon2password hashinggame server https://nanommo.nenuadrian.com/ep013-redis/2026-10-18https://i.ytimg.com/vi/F1-B23Ifibg/maxresdefault.jpghttps://i.ytimg.com/vi/F1-B23Ifibg/maxresdefault.jpgRedis write-behind for a C++ game server | Building nanoMMO #13Episode 13 of a series about building an MMO from scratch, with the focus on the engineering around the game. When our game server crashes, the players lose what they did since they logged in, as it saves them when they leave. So first we try the obvious fix: after each tick, save the players who changed to MySQL. We measure it with our bots, and the server falls behind with fifty players, as each save is two round trips and a commit, on the tick's thread. Then we put Redis between the game server and MySQL. The game server writes each player into a Redis hash, all of them in a single round trip each tick, with a pipeline, and Redis keeps them on disk with its append-only file. A saver of our own takes the unsaved players on to MySQL on a five-second timer, five hundred to an INSERT, which is called write-behind. We measure it again, with up to 2,250 bots, and crash the server again, to see that the players come back where they were.https://www.youtube.com/embed/F1-B23Ifibg24822026-10-18mmoc++redismysqlwrite-behindcachingpipelininghiredisappend only filepersistencebenchmarkprometheusgrafanadocker composegame server https://nanommo.nenuadrian.com/ep014-tls/2026-10-18https://i.ytimg.com/vi/ymt8DlhhvrA/maxresdefault.jpghttps://i.ytimg.com/vi/ymt8DlhhvrA/maxresdefault.jpgTLS for a C++ game server with OpenSSL and Asio | Building nanoMMO #14Episode 14 of a series about building an MMO from scratch, with the focus on the engineering around the game. When you log in to our game, the password goes over the network as you typed it, and the token that lets you into the game comes back over the network too. We start by watching that with tcpdump. Then we go through what TLS gives us: encryption, integrity, and a server that proves who it is, with a certificate. We go through the TLS 1.3 handshake, and through certificates, and make a certificate authority of our own, which signs the certificate for our servers. Then we bring in OpenSSL, through Asio's SSL stream, and put TLS 1.3 on each of our TCP connections: the login server, the game server, the client and the bots. We watch the wire again, check the handshake with openssl s_client, see what it costs with openssl speed, and go through what stays unencrypted over UDP, and why.https://www.youtube.com/embed/ymt8DlhhvrA26722026-10-18mmoc++tlstls 1.3opensslasiosslcertificatescertificate authorityx509ecdsaencryptiontcpdumpdocker composegame servernetworking https://nanommo.nenuadrian.com/ep015-world/2026-10-18https://i.ytimg.com/vi/oeL-fyumD8k/maxresdefault.jpghttps://i.ytimg.com/vi/oeL-fyumD8k/maxresdefault.jpgProcedural terrain in C++ with noise and raylib | Building nanoMMO #15Episode 15 of a series about building an MMO from scratch, with the focus on the engineering around the game. Our board of tiles becomes an island, 512 metres across, from value noise and a seed, in a library that the server and the client both build, so only the seed goes over the network. Both have to compute the island to the last bit, and by default they don't, as compilers fuse multiplies and adds on some machines and not others, so we turn that off and pin a fingerprint of the island in a test. The client draws it as flat-shaded low-poly triangles, with a sea, fog and a camera that follows you, and the server lets you wade into the sea and slide along the coast, with camps of skeletons the seed puts around the island.https://www.youtube.com/embed/oeL-fyumD8k31342026-10-18mmoc++procedural generationterrainvalue noiserayliblow polyfoggame camerafloating pointdeterminismfmagame server https://nanommo.nenuadrian.com/ep016-trees/2026-10-18https://i.ytimg.com/vi/jzgKLt6Prgg/maxresdefault.jpghttps://i.ytimg.com/vi/jzgKLt6Prgg/maxresdefault.jpgTrees and frustum culling in C++ with raylib | Building nanoMMO #16Episode 16 of a series about building an MMO from scratch, with the focus on the engineering around the game. Trees grow on the island from episode fifteen, where the seed says, from a low-poly model by Poly by Google under CC BY, and the server makes their trunks solid. Then we measure how fast the client draws all of it, with a benchmark of its own that walks around the island, and make it a lot faster: the island goes into chunks, and each frame draws the ones in sight, culled against the camera's view, and skips the rest.https://www.youtube.com/embed/jzgKLt6Prgg19242026-10-18mmoc++raylibtreesfrustum cullingchunksbenchmarkrendering performancedraw callsllvmpipegame clientlow poly https://nanommo.nenuadrian.com/ep017-character-screen/2026-10-18https://i.ytimg.com/vi/oQwuej-UaHM/maxresdefault.jpghttps://i.ytimg.com/vi/oQwuej-UaHM/maxresdefault.jpgGame character screen in C++ with raylib, ImGui | Building nanoMMO #17Episode 17 of a series about building an MMO from scratch, with the focus on the engineering around the game. We build the character screen: your name, level, health, experience and position next to an idle model of your character, facing you. The client draws that model into a render texture, through a small camera of its own, and Dear ImGui shows the texture in the character window. Along the way, we pull the drawing of a single figure out of the world's renderer, test the preview on a hidden window, and make C and View, Character open the screen.https://www.youtube.com/embed/oQwuej-UaHM10492026-10-18mmoc++raylibdear imguicharacter screenrender texturerender targetoffscreen renderinggame UI3d preview https://nanommo.nenuadrian.com/ep018-migrations/2026-10-18https://i.ytimg.com/vi/Qyzva2b8lH4/maxresdefault.jpghttps://i.ytimg.com/vi/Qyzva2b8lH4/maxresdefault.jpgMySQL schema migrations with Flyway in Docker | Building nanoMMO #18Episode 18 of a series about building an MMO from scratch, with the focus on the engineering around the game. Changing a table in our database has meant deleting the database, and all the accounts in it. So we bring in Flyway, which keeps the tables in versioned migrations, SQL files in the repo, and records which ones each database has run. Docker Compose runs it before the servers, the saver, the website and the tests. Then we save the players' health, so that logging out no longer heals you. Its column first goes into the first migration, and Flyway refuses it with a checksum mismatch, so it gets a second migration of its own, an ALTER TABLE that MySQL makes in place, and the bots keep their accounts and their progress through the change.https://www.youtube.com/embed/Qyzva2b8lH411392026-10-18mmomysqlflywaydatabase migrationsschema migrationsversioned migrationsdocker composealter tableredisc++game serverdevops https://nanommo.nenuadrian.com/ep019-deployment/2026-10-18https://i.ytimg.com/vi/RLQY3-KLp18/maxresdefault.jpghttps://i.ytimg.com/vi/RLQY3-KLp18/maxresdefault.jpgDeploy a C++ game server to a VPS with Docker | Building nanoMMO #19Episode 19 of a series about building an MMO from scratch, with the focus on the engineering around the game. Our game goes onto a server on the internet. First, we load our server with bots on my machine, to see where it falls behind, and what to expect from a smaller one. Then we rent a VPS from DreamHost (the affiliate link is below), with two virtual CPUs, four gigabytes of memory and Docker, and decide what the internet gets to reach: the login and game ports and the website, and not MySQL, Redis or the metrics, as Docker publishes ports past the firewall. A production compose file and a deploy script send a commit and its certificates over SSH, build it on the server and start it. The certificate named the server's address as a domain, so it failed to verify, until it went on as an IP. Then we connect from home, and put the VPS under load too.https://www.youtube.com/embed/RLQY3-KLp1811732026-10-18mmodeploymentvpsdocker composesshdevopsgame serverc++tlscertificatesdreamhostufwfirewallproductionload testing https://nanommo.nenuadrian.com/ep020-interest/2026-10-18https://i.ytimg.com/vi/8bnfKqUPQb8/maxresdefault.jpghttps://i.ytimg.com/vi/8bnfKqUPQb8/maxresdefault.jpgMMO interest management: send each player less | Building nanoMMO #20Episode 20 of a series about building an MMO from scratch, with the focus on the engineering around the game. Our server sends each player the whole world twenty times a second, so what it sends grows with the square of the players, and the VPS from last episode fell behind past about four hundred. We send our bots on trips across the island, so that they spread out like players would, and then give the server interest management: the island in cells of 32 metres, and each player gets what's in the cells around them. We measure it, and a profile shows where the rest of the time goes, which is the kernel sending each packet. So we shorten the view to 64 metres, and send names and levels once a second instead of twenty times, and measure each change, on my machine and on the VPS.https://www.youtube.com/embed/8bnfKqUPQb819602026-10-18mmointerest managementarea of interestgame servernetworkingc++protobufudpbandwidthbenchmarkperfflame graphvpsgame development https://nanommo.nenuadrian.com/ep021-worlds/2026-10-18https://i.ytimg.com/vi/lTFtOuEIeZE/maxresdefault.jpghttps://i.ytimg.com/vi/lTFtOuEIeZE/maxresdefault.jpgMMO server discovery with Consul and Docker | Building nanoMMO #21Episode 21 of a series about building an MMO from scratch, with the focus on the engineering around the game. One world server keeps up with about twelve hundred players on my machine, so we run several worlds, each with its own name, island and players, the way most MMOs do. Each world registers with Consul, HashiCorp's service registry, through its HTTP API, with cpp-httplib and nlohmann/json, and sends a heartbeat from its tick loop, so a world that stops or crashes drops out of the list. The login server lists the worlds that pass their health checks, the client picks one before it logs in, and Prometheus finds the worlds through Consul too. A Flyway migration gives each world its own players, and a third world joins the list and the monitoring with a single command.https://www.youtube.com/embed/lTFtOuEIeZE29552026-10-18mmoservice discoveryconsuldockerdocker composehealth checksc++nlohmann jsoncpp-httplibprometheusflywaygame servergame development https://nanommo.nenuadrian.com/ep022-lands/2026-10-18https://i.ytimg.com/vi/m5B_W9fVRwY/maxresdefault.jpghttps://i.ytimg.com/vi/m5B_W9fVRwY/maxresdefault.jpgMMO zones and portals in C++ with raylib | Building nanoMMO #22Episode 22 of a series about building an MMO from scratch, with the focus on the engineering around the game. Each world gets a second land, the Ashlands, next to the island we had, which becomes the Meadows, with a gate between them, the way MMOs have zones. First, the look of the island goes into one place: the sky, the fog, the sun and the ambient light become an atmosphere that the shaders read each frame, and the settings window tries presets on the fly, which turns up a fog bug and settles a new light for the Meadows. Then the world server runs both lands in one process, each with its own island, players and monsters, a gate takes players from one to the other, a Flyway migration keeps the land a player is in, and the metrics and the bots learn about lands too.https://www.youtube.com/embed/m5B_W9fVRwY26742026-10-18mmogame zonesportalsc++raylibshadersglslfoglightinglow polygame serverflywayprometheusgrafanagame development https://nanommo.nenuadrian.com/ep023-chat/2026-10-18https://i.ytimg.com/vi/stXkyDWZdqI/maxresdefault.jpghttps://i.ytimg.com/vi/stXkyDWZdqI/maxresdefault.jpgMMO chat in C++: TCP, ImGui and rate limits | Building nanoMMO #23Episode 23 of a series about building an MMO from scratch, with the focus on the engineering around the game. Players get a chat, where a line goes to everyone in their world. The line travels to the server with the player's input, and the server sends what was said in each tick to each player in a single message, over TCP, even to the clients that get the world over UDP, as a line that's lost is gone. The client gets a chat window in ImGui, where typing a line first walks you around and swings your sword, until the game's keys give way to the text field. Then the server cleans each line, as anyone can write a client, and a token bucket for each player keeps anyone from flooding the chat. Last, our bots talk now and then, and the dashboard counts the lines.https://www.youtube.com/embed/stXkyDWZdqI17002026-10-18mmogame chatchat systemc++protobuftcpudpimguiraylibrate limitingtoken bucketgame serverprometheusgrafanagame development https://nanommo.nenuadrian.com/ep024-npcs/2026-10-18https://i.ytimg.com/vi/tcwvi2ktWKk/maxresdefault.jpghttps://i.ytimg.com/vi/tcwvi2ktWKk/maxresdefault.jpgMMO NPCs in C++: data-driven, low bandwidth | Building nanoMMO #24Episode 24 of a series about building an MMO from scratch, with the focus on the engineering around the game. Our world gets its first NPCs: a guard, a merchant and a healer around the middle of each land. First, our monsters become data, with a kind for the skeleton and tables of where monsters spawn, the way MMO servers keep their creatures. NPCs then get tables of their own, and a small type on the server, apart from the monsters, as they don't move or fight. Nothing about an NPC changes, so the server puts them into their interest cells once, and sends them once a second, while the client keeps each one for a few seconds, so that a lost UDP datagram doesn't make them blink out. Until they have models, the client draws each NPC as a coloured ball, with its name over it.https://www.youtube.com/embed/tcwvi2ktWKk17722026-10-18mmonpcnon-player charactersgame serverc++data-driven designprotobufudpinterest managementbandwidthraylibimguigame development https://nanommo.nenuadrian.com/ep025-storyteller/2026-10-18https://i.ytimg.com/vi/8ahH708PKvQ/maxresdefault.jpghttps://i.ytimg.com/vi/8ahH708PKvQ/maxresdefault.jpgMMO NPC with an LLM in C++: threads, batching | Building nanoMMO #25Episode 25 of a series about building an MMO from scratch, with the focus on the engineering around the game. One of our NPCs gets something to do: a storyteller that writes you a short story from a few words you give it, with mvGPT, the small language model built from scratch in my other series. mvGPT's own batching server goes into our repo and runs in Docker Compose next to the game. A player's words travel with their input, and the server checks how close they are, cleans the words and limits how often they ask, before it asks the model, from sixteen threads of its own, over HTTP with cpp-httplib, so that the tick doesn't wait for a story. On the client, a ray from the mouse picks the storyteller, and an ImGui window takes the words. The first story never arrives, until it's broken into lines of chat. Last, the dashboard counts the stories, and our bots ask for them too.https://www.youtube.com/embed/8ahH708PKvQ26322026-10-18mmonpcllmlanguage modelai npcstorytellergame serverc++httpcpp-httplibthreadsbatchingraylibray pickingimguiprometheusgrafanamvgptgame development https://nanommo.nenuadrian.com/ep026-items/2026-10-18https://i.ytimg.com/vi/QUBo0U3dWUE/maxresdefault.jpghttps://i.ytimg.com/vi/QUBo0U3dWUE/maxresdefault.jpgMMO items in C++ with protobuf text format | Building nanoMMO #26Episode 26 of a series about building an MMO from scratch, with the focus on the engineering around the game. Our game gets an item system, starting with the sword our players hold. Its reach and damage were constants on the server, and its model and grip were in the client's code, so the two could drift apart. The sword moves into one items file, in protobuf's text format, with a schema that both sides compile in, where the server reads how a weapon fights and the client reads how it looks. A parser refuses a misspelt field with its line, and our own checks catch what types can't. On the way, the server stops in Docker, as its image doesn't have the file. Then each player holds a weapon by its id, which goes out once a second, and into Redis and MySQL with a Flyway migration.https://www.youtube.com/embed/QUBo0U3dWUE18302026-10-18mmoitem systemgame itemsdata-driven designprotobuftext formattextprotoc++game serverdockerflywaymysqlredisraylibgame development https://nanommo.nenuadrian.com/ep027-content/2026-10-18https://i.ytimg.com/vi/pNLTgWXg5CU/maxresdefault.jpghttps://i.ytimg.com/vi/pNLTgWXg5CU/maxresdefault.jpgData-driven MMO content in C++ with protobuf | Building nanoMMO #27Episode 27 of a series about building an MMO from scratch, with the focus on the engineering around the game. Last time our sword became data, in a typed file that the server and the client both read. This time the rest of the game's content follows: the items folder becomes a content folder, with the kinds of monsters and NPCs and where they stand, in protobuf's text format, with checks for what types can't catch. Monsters and NPCs then go to the players by their kind's id, in place of their names and looks, which halves what the NPCs cost on the wire, and the compiler lists each piece of code that read the old fields. A hash of what the clients read goes into Consul with each world, so that a client stays off a world whose content it doesn't have. Last, a second kind of monster, the Ash Skeleton, joins the Ashlands without a line of code.https://www.youtube.com/embed/pNLTgWXg5CU29732026-10-18mmodata-driven designgame contentprotobuftext formatgame serverc++consulhashingfnv-1araylibgame development https://nanommo.nenuadrian.com/ep028-checks/2026-10-18https://i.ytimg.com/vi/00BaZgctnE4/maxresdefault.jpghttps://i.ytimg.com/vi/00BaZgctnE4/maxresdefault.jpgC++ sanitizers, fuzzing and coverage in Docker | Building nanoMMO #28Episode 28 of a series about building an MMO from scratch, with the focus on the engineering around the game. Our tests check what we thought to check. This time we look for the rest: we build the game with AddressSanitizer, UndefinedBehaviorSanitizer and LeakSanitizer, and then with ThreadSanitizer, and run the servers with them while two hundred bots play. LeakSanitizer finds a leak in raylib, ThreadSanitizer finds a data race in the web server that serves our metrics, once we keep it away from what it can't follow. A fuzzer finds stories that the storyteller NPC would lose, clang-tidy reads the code for bugs that compile, and a coverage report shows which code no test reaches. Each of them runs in Docker and in CI, and we fix what they find.https://www.youtube.com/embed/00BaZgctnE422972026-10-18c++addresssanitizerthreadsanitizerubsansanitizersfuzzinglibfuzzerclang-tidycode coveragellvm-covdockergithub actionsmmogame server https://nanommo.nenuadrian.com/ep029-server-test/2026-10-18https://i.ytimg.com/vi/GhF-X9H0zY4/maxresdefault.jpghttps://i.ytimg.com/vi/GhF-X9H0zY4/maxresdefault.jpgIntegration testing a C++ game server | Building nanoMMO #29Episode 29 of a series about building an MMO from scratch, with the focus on the engineering around the game. Last time, the coverage report showed that no test runs the world server's game loop or its sessions. This time we write the test that does: it starts a world server inside the test, on a port the system picks, against MySQL and Redis, and has players join it over TLS, the way the client does. They see each other until one of them leaves, and an account can't play twice at once. The server and the players run on the test's thread, so the test can wait for what it checks without sleeping, and give up when it doesn't happen. The sanitisers catch a bug in the test, which the plain build runs past, and the coverage report shows how much of the server the tests reach now.https://www.youtube.com/embed/GhF-X9H0zY412412026-10-18c++integration testinggoogletestasiotlscode coveragellvm-covubsanaddresssanitizerdockermmogame server