← All posts

First Defold Project Setup — Folder Structure and Web Export Size

Defold client — week one of actually touching the engine.

Last post ended with a promise: before I design a town, before I argue about Nakama, I need a Defold project that builds to HTML5 and a number I can defend. Not "Defold is smaller" from a blog post — my zip size, on my machine, for this game.

So the first real task wasn't gameplay. It was scaffolding: create the project, pick a folder layout I won't regret in three months, set display options for pixel art, run an HTML5 bundle, and weigh the output.

The problem it solves

UptownZero is 480×270 logical pixels, scaled up crisply in the browser — same discipline I use in Godot. If I get display settings wrong on day one, every sprite and UI layout inherits the mistake. And if I don't measure export size now, I won't notice when a casual addition doubles the download.

Godot taught me to lock resolution and stretch mode early. Defold's equivalent lives in game.project under Display and in how the render script handles the window. I wanted those locked before a single LimeZu tile goes in.

What I set up

Fresh project from the Defold editor (no template). Top-level layout I'm starting with:

In Godot I'd lean on autoloads. In Defold I'm using a small lib/bootstrap.lua required from a script on a persistent "game" game object, plus Defold's built-in messaging. I don't know yet if that's the idiomatic long-term pattern — it's readable on day one, which is enough.

Display settings (the ones that matter for pixel art):

First HTML5 bundle: Project → Bundle → HTML5 → Create Bundle. Open the output folder, zip the contents (or note the total of *.wasm + *.data + loader JS). My empty project — one collection, grey background, a 16×16 placeholder sprite, no audio — landed around 1.1 MB zipped. That's the baseline. Post #1 wasn't exaggerating for an empty build.

For comparison I re-exported a minimal Godot 4 HTML5 template from another repo: ~9 MB zipped before I'd added a single game asset. Different projects, different defaults — but the order of magnitude is the reason I'm here.

Where UptownZero stands right now

Defold project exists locally. You can walk a placeholder sprite around an empty scene in the editor. HTML5 build runs in a browser tab from index.html in the bundle output. No tilemap, no job loop, no save file, no server. The engine decision now has a number behind it.

What I don't know yet

How fast the zip grows once LimeZu tilesets and UI skins land — that's the next measurement I care about. Defold strips unused assets at bundle time, but atlases add up fast if I'm sloppy about duplicate textures.

Lua module patterns at scale still feel foreign. In Godot I'd reach for signals and autoloads without thinking. Here I'm relearning where state should live — script locals, game object properties, or a dedicated controller object. Expect some refactors once the downtown slice gets real.

I also haven't wired CI. Right now builds are manual from the editor. A bob / GitHub Action pipeline is on the list before the repo goes public.

What's next

Networking spike: two browser tabs, same room, acceptable latency. Nakama is still the leading candidate for persistent multiplayer, but the first test might be dumber — even a hosted WebSocket echo — just to see how Defold's HTML5 runtime behaves with live sockets. That'll be post #3.

Links from this post