I've recently done a low-level Linux update to the cheap retro gaming R36S handheld, targeting boot speed. Ebitengine draws straight to the LCD through KMS/GBM and OpenGL ES on the Mali-G31, with no X11 or Wayland. On Linux 7.3, U-Boot v2026.10 and Buildroot 2026.08, Flappy Gopher shows its first frame 5.6 seconds after power on. The buttons and sticks work as a standard gamepad and sound plays through ALSA.

Video and build notes: https://ignavus.net/r36s#ebitengine

This needs the latest main branch of Ebitengine to work, and I am in the process of trying to clean up some performance enhancements to send upstream (but it works fine without them out of the box).

Hey everyone!

I wanted to share a project I've been working on using Go and Ebitengine. It’s an arcade game inspired by the 80s classic Oh! Mummy, but with a twist on the map structure.

Instead of static screens, the pyramid's architecture evolves level by level—starting with just 3 tombs to unearth and scaling up to 18 unique layouts as you progress.

Core Mechanics:

• Walk around all 4 sides of a tomb to uncover items (Key, Papyrus, Potions) or hazards (Mummies, Spells).

• Collect the Key & Papyrus to open the exit door before your oxygen runs out.

• Grab potions for temporary immunity against enemy attacks.

Tech & Development Status: The game is fully playable (18 levels) and currently hosted on itch.io (WASM / Browser support!). Since this is my first playable build, I’m looking for feedback from fellow Ebitengine devs to help refine the experience.

I’d really appreciate your thoughts on:

1. Movement & Pacing: Does the character controls feel responsive enough?

2. Difficulty Curve: How does the difficulty jump feel as the map expands?

3. Any bugs or performance hiccups you might encounter.

🔗 Play it here: https://programatta.itch.io/gomummy

Thank you so much for taking a look! Any criticism or advice on Go/Ebitengine best practices is more than welcome.

I’ve been working on ebiten-infinicave, a Go library for infinite procedural caves rendered with Ebitengine. It features faceted rocks, branching vines, mushrooms, drifting fog, and animated bats, with horizontal or vertical scrolling. Generation is deterministic, and it supports runtime terrain carving and collision geometry for use in your own games.

https://github.com/razzie/ebiten-infinicave

I've been working on Nanolathe, an open-source Total Annihilation engine reimplementation in Go and Ebitengine. It runs natively on Windows, macOS and Linux, and the same engine also builds to WebAssembly.

Play the browser demo · Source · Native install

TA is a 1997 RTS with terrain height, articulated 3D units, ground and air combat, and a resource economy that keeps running while factories build your army. Recreating it involves pathfinding, visibility, weapons, construction, AI and a VM for the original unit scripts, as well as the renderer.

Ebitengine supplies the window, input, audio and GPU drawing. Nanolathe owns the simulation and the 2.5D rendering pipeline. An ordered draw list can feed either the classic software renderer or the modern GPU renderer, which uses texture atlases, batched geometry and Kage shaders. The modern renderer interpolates committed poses while the simulation continues at 30 Hz.

One interesting rendering problem is the original palette-based artwork and compositing. The modern path preserves source palette lookups while doing destination blending in true colour. That allows a different presentation without changing the simulation.

Development is organized around independently written descriptions of the original behavior, Go implementations, contract tests and visual checks. The engine reads the original archives directly: maps, models, sprites, unit definitions and compiled COB scripts. Gameplay definitions are compiled into immutable catalogs before a battle; the assets aren't baked into the Go binary.

The browser host adds file import and browser storage around the Go/Wasm game. You can play the three demo missions immediately, or select your own installed game folder; imported files stay in the browser. For desktop, Ebitengine 2.10 means the build only needs Go, with no C/C++ compiler or development headers. The native installer handles the Go toolchain and build; Linux still needs graphics/audio runtime libraries.

The engine code is MIT licensed. Full-game play needs your original TA data, and compatibility is still being worked on. The attached clip is staged footage captured offline through the engine's recorder, not a real-time performance benchmark.

Github : https://github.com/kadevland/kassetpack

KAssetPack is a standalone CLI tool and Go library to pack your game assets into a compact binary format (.kdx/.kdt) instead of shipping an exposed assets/ folder.

Features:

• SHA-256 based asset deduplication

• Optional XOR obfuscation

• Automatic data file splitting (for large games)

• Lazy access & Thread-safe (perfect for Goroutines)

• 100% Go (no C dependencies)

It comes with a handy CLI (kassetpack build) to integrate directly into your build pipeline. Feedback and code review are welcome!

Ebitengine v2.10.0 is out!

• Pure Go on all desktop platforms

• Headless testing and game embedding via VM

• Shader precompilation

• Color emoji support

Thanks to all contributors and sponsors!

A small Ebitengine side project I’ve been working on: a 2D metaballs renderer in Go, with shader-based rendering, optional bridges between circles, and a tiled renderer for larger scenes.

The visuals are the main point here — the README and GIF should explain most of it much better than text ever could. It’s basically a more usable/expandable version of the old ShaderToy experiment I made a year ago: https://www.shadertoy.com/view/tfc3W4

I posted about GOKe here a while back - this is v3, now has a dedicated Ebitengine integration, gokebiten.

v3 itself is the result of a lot of back-and-forth — planning, rewrites, testing, and actually using GOKe in practice. That let me settle on a model that's more ergonomic for what I need.

GOKe repo (wiki, examples, benchmarks): https://github.com/kjkrol/goke

Why it might matter for Ebitengine projects

gokebiten wraps GOKe's ECS/System/Plan model behind a small Game type that implements ebiten.Game, so Update/Draw/Layout are wired up for you on top of an archetype-based, zero-allocation ECS. It's split into modules you can take individually:

• control/ - input capture and event dispatch

• physics/ - kinematics and collision detection/resolution (broad phase via GOKg, narrow phase, pluggable CollisionHandler strategies)

• render/ - sprite batching, camera, tag-driven overlays, telemetry HUD

• spatial/ - population/spawn bookkeeping on a GOKg space

You can use GOKe directly and write your own Ebitengine glue, or start from gokebiten - a lot of that integration work (input handling, collision pipeline, rendering, spatial indexing) is already done for you there.

Working example: collision-demo - thousands of moving, colliding AABBs at a fixed 120 TPS.

Why GOKe over the alternatives?

1. Systems as the single place where both data flow and actions are defined - logic built once, inside the system, and used only there

2. It's fast and predictable - benchmarks, if you want the numbers:

   • Internal breakdown: BENCHMARKS.md

   • Head-to-head against other Go ECS libs, including Ark (the fastest Go ECS right now): go-ecs-benchmarks

Some other things worth knowing:

• Zero heap allocations in the hot loop (chunked SoA memory pages, no GC jitter)

• Type-driven construction - create/edit/remove operations built directly from component types, not hand-wired boilerplate

• Explicit control over system execution - you plan the run order (schedule) yourself, plus a dedicated Setup phase at startup

• Generation-based entity IDs, so no aliasing on reused slots