DEV Community: Ricardo Sanchez

I built a private MMORPG stack for a 3D farming game (Godot + Go)

Ricardo Sanchez — Wed, 05 Aug 2026 22:55:39 +0000

Farm World started as a simple idea: a 3D multiplayer farm where you build, plant, drive machines, and meet people in town. I did not want to rent someone else's netcode forever. I wanted a stack I could own for years.

So I built one.

This is not a "look at my landing page" post. It is the messy middle: protocol design, Blender without being a 3D artist, SQLite under a live world loop, and the bugs that only show up when real players join.

What Farm World is

A multiplayer 3D farming game:

Own a plot, grow crops, raise animals, store harvest.
Buy vehicles, hitch field tools, work the land like a small farm sim.
Walk into town, sell, craft, take quests, hang out with other players.
Play in the browser or download a desktop build.

Client: Godot 4.6 (GL Compatibility, so web export stays realistic).

Server: Go, plain WebSocket JSON, SQLite persistence.

No Unity Netcode. No Photon. No "MMORPG framework" bought off a shelf.

Rough size today: about 29k lines of Go on the server (without tests), hundreds of GLB props and crops in the asset tree, plus a Next.js site for play and downloads.

Why a private framework

I kept hitting the same wall with ready-made multiplayer kits:

Great for shooters or tiny lobbies, awkward for persistent farms.
Your economy, plots, animals, and world events still need custom authority.
Once the kit fights your game design, you pay twice: once in money, once in rewrites.

Farm World needs server authority on almost everything that matters: gold, inventory, crop growth, market prices, vehicle cargo, plot power. The client is a view. The server is the truth.

That decision became the spine of the project. The "framework" is not a product I sell. It is the habit of building:

A small JSON op protocol over WebSocket.
A single Go process that owns game rules and DB writes.
A Godot autoload (game_net.gd) that speaks that protocol and nothing else.
Migrations that grow with the live world instead of a big bang rewrite.

I plan to keep this shape for years. New systems plug into ops, handlers, and tables. That is the private stack.

The protocol is boring on purpose

Every message is basically:

{ "op": "action_sow", "slot_id": 12, "cell_x": 3, "cell_y": 7, "seed_type": "wheat" }

Login, resume session, sow, harvest, place buildings, spawn vehicles, chat, friends… same envelope. On the Go side, it lands in one Message struct with many optional fields. On Godot, it is send_op({ "op": "..." }).

Boring is a feature. When a new system arrives (pets, craft pots, world events, voice signals), you add an op and a handler. You do not invent a second networking universe.

Client-side, it looks like this:

func request_sync() -> void:
    send_op({"op": "sync"})

func request_sow(slot_id: int, cell_x: int, cell_y: int, seed_type: String) -> void:
    send_op({
        "op": "action_sow",
        "slot_id": slot_id,
        "cell_x": cell_x,
        "cell_y": cell_y,
        "seed_type": seed_type,
    })

Hard problem 1: an MMORPG server from zero

"From zero" means: accept sockets, authenticate, rate limit login, keep session tokens, load plot state, tick growth, broadcast presence, and never trust the client with gold.

A few lessons that cost real nights:

Full sync is a trap.

sync that rebuilds the whole player profile feels safe early on. It is also how you melt FPS. We once shipped a client loop that asked for full sync tens of times per second after restoring farm machines. The HUD ping lied. The real cost was JSON parsing on the main thread. Fix: stop the loop, prefer deltas, treat full sync as a rare reconnect tool.

The world loop is a product feature.

Crops do not grow because the client animates. Rain, market multipliers, and harvest yield live on the server clock. That makes events fair across players and keeps cheaters bored.

SQLite can carry an early MMO if you respect it.

One file DB, WAL, careful transactions, indexes on hot paths, and migrations that do not lock the world for minutes. I did not start with a cluster. I started with correctness and measurable queries. When something is slow, it is usually an N+1 load of tiles or a sync that got fat again.

Custom admin analytics dashboard built to monitor server health (Goroutines, Heap, SQL latency) and player onboarding friction.

Authority boundaries stay sacred.

If the client could invent a harvest, the economy dies. Every meaningful action is validated server side against inventory, plot ownership, and cooldowns.

Hard problem 2: hundreds of GLBs without being a Blender expert

I am not a professional 3D artist. I still needed a town, crops at multiple growth stages, kitchen props, vehicles, hitch tools, and vegetation.

The workflow that actually worked:

Source packs and kitbash where the art direction allows it.
Blender only for the boring jobs: scale, origin, export GLB, fix materials that Godot hates.
Naming discipline so crops and props map cleanly to item IDs.
Accept that "pretty enough and consistent" beats "perfect and never shipping".

The surprise cost was not sculpting. It was pipeline: import settings, LODs later, collision, and keeping the web build from drowning in megabytes. Art is a systems problem once you have hundreds of files.

Hard problem 3: a 16 km² map that has to run in the browser

The world is about 16 square kilometers. That sounds cool in a trailer. On the web, it is a constant fight: Terrain3D regions, props, vehicles, town collision, audio, and a WASM build that cannot pretend it is a fat desktop install.

Making that map playable in the browser has been one of the hardest product constraints of the whole project. GL Compatibility is not a preference; it is survival. Streaming attention, draw distance, and "do not load the entire planet at once" thinking matter more than fancy lighting.

With a small player count so far, the result is already good enough to ship and keep iterating: people drive, farm, and explore without the tab melting. The open question is scale. More concurrent players means more presence traffic, more vehicles in view, more pressure on the same web budget. The map size stays. The stack has to earn it.

Hard problem 4: 100 plots, 784 cells each, and ping spikes

We have 100 farm plots. Each one is a 28×28 grid, so 784 cells per plot. That is not a cute number on a whiteboard. It is tiles, soil, crops, trees, buildings, paint, and power state that can all want to travel over the wire.

The pain showed up when a plot got "real": something like 200 harvest cells plus a dense tree layer. Full property payloads got fat. The client spent frames merging and spawning. The server spent time building profiles and broadcasting to people who did not even need the detail. Ping spikes were not mysterious network weather. They were us shipping too much world to the wrong people.

I spent hours reworking both sides:

Interest/distance. Nearby players and the plot owner get full detail. Far players get a thin stub: skyline bits you can see from the road, without the crop and tree arrays that would wipe or bloat their local cache.
Fetch on approach. When you walk closer, the client asks for the real plot (fetch_plot style flow) instead of assuming every slot arrives complete on welcome.
Deltas over dumps. Growth and harvest prefer tile patches and targeted property_updates. Re-sending 784 cells because one tomato ripened is how you invent lag.
Presence is local too. Movement does not fan out to every connected socket on a 16 km² map. If you are far away, you should not pay for my tractor position every tick.
Client LOD to match. Plot interiors, fences, and foliage already think in distance bands. Network stubs and scene LODs have to agree, or you optimize one layer, and the other still melts the frame.

This was not one clever PR. It was a loop of measure, cut payload, fix a merge bug, watch the spike come back under a busier plot, repeat. The goal was boring: keep ping peaks low even when farms look alive.

Things that moved the needle beyond plots and the big map:

Stop chatty sync loops (the farm machine bug was a teacher).
Send growth patches instead of re-sending the whole plot when possible.
Treat export audio, caching, and pack size as first-class bugs on web.
Measure. A "50 ms ping" HUD can hide a 70 ms JSON parse.

There is also the human side of shipping: version modals when server and client disagree, production bugs like crops that show in inventory but refuse to sell, audio that works in the editor and vanishes on web export. That is the real curriculum.

What I would tell myself on day one

Design the op list before the UI screens.
Assume full state sync will betray you.
Put economy math on the server on day one, even if the formulas are naive.
Learn just enough Blender to unblock export, then stop cosplaying as a studio.
Write down pitfalls. Future you will step on the same rake.

The long game

Farm World is the game players see. Under it sits a private multiplayer habit I expect to reuse: Godot client, Go authority server, SQLite until proven otherwise, JSON ops, ruthless server validation.

I am still adding systems (crafting and town businesses, pets, mobile/export paths, better audio spaces). The stack is meant to survive that.

Try it

If the development side caught your attention, you can play the free demo in the browser at farms-world.com/play, grab a desktop build from the site, or join the Discord and tell me what broke.

Questions welcome in the comments: protocol design, Godot web export, or "why SQLite for an MMO" are all fair game.

Gameplay Screenshots

Godot AI? Here is the solution: What is Golem-AI?

Ricardo Sanchez — Thu, 04 Jun 2026 18:31:20 +0000

Enlace a post en Español Click

If you are developing games in Godot and using AI to help you code, you are probably tired of constantly switching tabs between your editor and the browser. Copying code, pasting it, explaining your scene context over and over again... it is a massive workflow killer.

To solve this, I built Golem-AI (named after the Godot Engine logo because let's face it, it looks like a tiny, friendly mechanical golem). It is a "Cursor-style" AI assistant extension integrated directly into a dock right inside your Godot 4.2+ editor.

Today, I am opening the repository to the community as a completely open-source project. It is currently in Beta and has some bugs, but it is fully functional, and I want to share it so we can improve it together.

  / ____/___  / /__  ____ ___        /   |  /  _/
 / / __/ __ \/ / _ \/ __ `__ \______/ /| |  / /  
/ /_/ / /_/ / /  __/ / / / / /_____/ ___ |_/ /   
\____/\____/_/\___/_/ /_/ /_/     /_/  |_/___/

🎮 How it Looks Inside the Editor
Here is a glimpse of the integrated dock interface, its session history, and the context autocomplete system in action:

🔥 Key Features
🦙 Local & Cloud Providers: Connect it to Ollama or LM Studio for a 100% free, offline local workflow, or hook it up to OpenAI, Anthropic, Gemini, or Cursor proxies.

🧠 Cursor-Style UX & Context (@ Mentions): Type @ in the chat composer to automatically attach open scenes, specific project files, or custom skills directly into the prompt.

🛠️ Editor Tool Calling: It features an optional multi-step verification loop. The AI can actually interact with native Godot editor tools to help you iterate and fix things faster.

📚 Markdown Skills System: Feed the assistant specific workflows, style guides, or documentation using standard markdown files (/skill or @skill:id).

💬 Advanced Chat UI: Built-in "thinking blocks", agent step progress tracking, searchable history sessions, and a native bilingual UI (English / Spanish).

🛠️ The Current State: "It works, but..." (Looking for Beta Testers!)
Let's be completely transparent: This is a Beta release.

You will encounter bugs. The tool-calling loop might stumble occasionally, or a lightweight local model might hallucinate your scene tree structure. But that is exactly why I am sharing it today! I want to test it against different gamedev workflows, see how it handles massive projects, and figure out what the Godot community actually needs from an in-editor AI teammate.

🚀 Quick Start Guide
Testing it or breaking it takes less than two minutes.

Installation Clone the repository directly into your project's addons folder:

git clone [https://github.com/sancheznot/Godot-AI-Assistant.git](https://github.com/sancheznot/Godot-AI-Assistant.git) addons/ai_assistant_plugin

Enable the Plugin
Open your project in Godot, navigate to Project -> Project Settings -> Plugins, and check the Enable box next to AI Assistant Plugin.
Configure Your Model
Click the Config button in the new dock toolbar, enable your preferred provider (like Ollama), click the refresh icon ↻ to fetch your models, and you are ready to chat!

🤝 Code with Me (Contribute!)
The project structure is quite modular and straightforward:

/harness handles the system prompt layers.

/scenes and /scripts separate the dock UI layout from the plugin logic.

/skills hosts the pre-built markdown behaviors.

If you are a GDScript wrangler, an AI architecture enthusiast, or someone who just loves polishing UI/UX layout details, Pull Requests and Issues are incredibly welcome.

👉 Check out the GitHub Repository here: https://github.com/sancheznot/Godot-AI-Assistant

If you test it out, let me know in the comments below! What provider are you running it with? What broke first? Let's make the Godot Golem smarter together.

Godot AI? Traigo esta solución: ¿Qué es Golem-AI?

Ricardo Sanchez — Thu, 04 Jun 2026 18:25:53 +0000

Link to post in English Click

Si estás desarrollando juegos en Godot y usas inteligencia artificial para programar, seguro estás harto de cambiar de ventana entre tu editor y el navegador web. Copiar código, pegarlo, explicar el contexto de tus escenas una y otra vez... es molesto.

Para solucionar esto, creé Golem-AI (llamado así porque el logo de Godot parece un pequeño golem mecánico). Es un asistente de IA tipo "Cursor" integrado directamente en un dock dentro de tu editor de Godot 4.2+.

Hoy abro el repositorio como un proyecto completamente open-source. Está en Beta y tiene bugs, pero ya es totalmente funcional y quiero compartirlo con la comunidad para mejorarlo juntos.

  / ____/___  / /__  ____ ___        /   |  /  _/
 / / __/ __ \/ / _ \/ __ `__ \______/ /| |  / /  
/ /_/ / /_/ / /  __/ / / / / /_____/ ___ |_/ /   
\____/\____/_/\___/_/ /_/ /_/     /_/  |_/___/

🔥 Características Principales
🦙 Modelos Locales y Cloud: Conéctalo a Ollama o LM Studio para un flujo de trabajo 100% gratuito y desconectado, o configúralo con OpenAI, Anthropic, Gemini o proxies de Cursor.

🧠 Contexto con @ Mentions (Estilo Cursor): Escribe @ en el chat para adjuntar automáticamente escenas abiertas, archivos específicos del proyecto o habilidades personalizadas directamente en el prompt.

🛠️ Llamado de Herramientas del Editor (Tool Calling): Cuenta con un bucle opcional de verificación de múltiples pasos donde la IA puede interactuar con las herramientas nativas de Godot para ayudarte a iterar más rápido.

📚 Sistema de Habilidades en Markdown: Entrena al asistente con flujos de trabajo específicos usando archivos markdown estándar (/skill o @skill:id).

💬 UI de Chat Avanzada: Incluye bloques de pensamiento ("thinking blocks"), progreso de pasos del agente, historial de sesiones con buscador y una interfaz bilingüe nativa (Español / Inglés).

🛠️ El Estado Actual: "Funciona, pero..." (¡Llamado a Beta Testers!)
Seamos transparentes: Esto es una versión Beta.

Vas a encontrar errores. El bucle de ejecución de herramientas puede fallar a veces o un modelo local pequeño podría alucinar con la estructura de tus nodos. Pero precisamente por eso lo comparto hoy de forma abierta. Quiero ver cómo se comporta en diferentes flujos, cómo maneja proyectos masivos y qué es lo que la comunidad de Godot realmente busca en un compañero de IA integrado.

🚀 Guía de Inicio Rápido
Probarlo o empezar a romperlo toma menos de dos minutos.

Instalación Clona el repositorio directamente dentro de la carpeta de addons de tu proyecto de Godot:

git clone [https://github.com/sancheznot/Godot-AI-Assistant.git](https://github.com/sancheznot/Godot-AI-Assistant.git) addons/ai_assistant_plugin

Activar el Plugin
Abre tu proyecto en Godot, ve a Proyecto -> Ajustes del Proyecto -> Plugins y marca la casilla de Activar al lado de AI Assistant Plugin.
Configurar tu Modelo
Haz clic en el botón Config en la barra de herramientas del nuevo panel (dock), activa tu proveedor preferido (como Ollama), presiona el icono de actualizar ↻ para cargar tus modelos guardados locales o en la nube, ¡y listo!

🤝 Colabora Conmigo (Contribuir)
La estructura del código es bastante limpia y modular:

/harness maneja las capas del sistema de prompts.

/scenes y /scripts separan la interfaz del dock de la lógica del plugin.

/skills contiene los comportamientos preestablecidos en Markdown.

Si eres un desarrollador de GDScript, un entusiasta de la arquitectura de IA o simplemente te encanta pulir interfaces visuales, los Pull Requests y los Issues son más que bienvenidos.

👉 Enlace al repositorio en GitHub: https://github.com/sancheznot/Godot-AI-Assistant

Si lo pruebas, ¡cuéntame en los comentarios de abajo qué tal te funcionó! ¿Qué proveedor estás usando? ¿Qué fue lo primero que se rompió? Vamos a hacer al Golem de Godot más inteligente entre todos.