Skip to main content
Ephergent Devlog

Why I Chose Godot 4 for The Ephergent Games

5 min read

I’ve been writing Python professionally for over a decade. When I started thinking seriously about building games for The Ephergent universe, I had three requirements:

  1. Export to HTML5 so games play in the browser — no download
  2. Free and open source — no per-seat licensing I’ll regret later
  3. A scripting language that doesn’t make me want to retire

Godot 4 hits all three. But that’s the boring answer. Here’s the honest one.

GDScript Feels Like Python Did in 2010

The first time I read GDScript, I thought someone had taken Python, added type hints, made them fast, and wired the whole thing to a scene tree. That’s basically what it is.

extends Node2D

@export var dialogue_text: String = ""
@onready var label := $Label

func _ready() -> void:
    label.text = dialogue_text

Compare that to the equivalent Python + some UI framework and the ceremony involved. GDScript is concise. The @export decorator is clever — it exposes variables to the editor inspector, which means designers (future me) can tweak values without touching code. That’s good game dev practice baked into the language.

The Scene Tree Is the Right Mental Model for Games

Coming from web development (Astro, React), I’m used to component trees. Godot’s scene tree is a similar idea but with physics, animation, and lifecycle methods built in. Every game object is a scene. Scenes can contain other scenes. A “player” is a scene. A “dialogue bubble” is a scene. A “frequency wave” is a scene.

For narrative games especially, this composability is powerful. The Laughing Funeral (a 30-min dialogue game) can be structured as a root scene with child scenes for each location, each NPC, each dialogue runner. No monolithic game manager required.

The HTML5 Export Constraint Is Real

Here’s the honest part: Godot 4’s HTML5 export is genuinely good, but the baseline export size is 4–6MB before any assets. My hard cap is 15MB compressed per game. That leaves room for art, audio, and code — but not a lot of room.

This isn’t a dealbreaker. It’s a design constraint. Constraints are useful. Knowing I can’t throw 200MB of assets at a game forces me to think harder about what each scene actually needs.

The pipeline I’m building:

  1. Godot project → HTML5 export
  2. Compress with Brotli/gzip
  3. Measure against the 15MB cap
  4. If over budget, audit assets before cutting features

I’ll document the exact numbers when Meatball’s Big Walk hits the export stage.

What Godot Is Not Great At

No honest review skips this.

Audio in browsers is finicky. Web browsers require user interaction before playing audio. Godot handles this but you have to architect around it consciously — you can’t assume audio starts on load. I’m planning a “tap to start” screen for every game partly for this reason.

The Godot 4 export templates change frequently. The HTML5 export pipeline in 4.x has been evolving rapidly. What worked in 4.0 might need a flag change in 4.3. Keep your Godot version pinned per project.

Debugging in the browser is harder. print() statements go to the browser console, which is fine, but you lose the Godot debugger. Get things working in the editor first, then export.

The Verdict

For cozy, narrative, and 2D games that need to live in a browser and be built by one person with a Python background — Godot 4 is the right tool. Not perfect. Right.

Next post: building the Godot HTML5 pipeline from scratch and measuring the first export.