# Rocket Plumber: A rocket engine and spaceship building game I'm making with Julia!

**URL:** <https://discourse.julialang.org/t/rocket-plumber-a-rocket-engine-and-spaceship-building-game-im-making-with-julia/140135>\
**Category:** Community\
**Tags:** games\
**Created:** [October 21, 2026, 1:12pm UTC](https://discourse.julialang.org/t/rocket-plumber-a-rocket-engine-and-spaceship-building-game-im-making-with-julia/140135 "2026-10-21T13:12:38Z")\
**Posts on this page:** 1\
**Showing post:** 12

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [November 2, 2026, 11:57pm UTC](https://discourse.julialang.org/t/rocket-plumber-a-rocket-engine-and-spaceship-building-game-im-making-with-julia/140135/12 "2026-11-02T23:57:19Z")

</div>

> [@Crispy](#):
>
> As of v0.1.0 Rocket Plumber has moved from just a tech-demo to an early but playable game with a few hours of satisfying learning and progression. It’s far from finished

It looks great! And sounds intriguing, any game with Julia.

> [@Crispy](#):
>
> The overall GC overhead isn’t really a problem, ..
> 
> I wouldn’t recommend trying to write all your code to be non-allocating. In my opinion you lose a lot of the implementation speed and dynamism

It’s a trade-off, but does it need to be? Your workaround is pre-allocating, great. Did you know of Bumper.jl? It’s also opt-in but I understand simpler. And brand-new (like the Goose language it’s based on and discussed under here offtopic, a very intriguing language; for games) and might also help you: [GitHub - yolhan83/GooseArrays.jl · GitHub](https://github.com/yolhan83/GooseArrays.jl) See also AllocCheck.jl.

It’s a bit unclear what Julie is and how it achieves this:

> [@MDSW](#):
>
> | | JuliaC (v0.1.0, from main) | Jule 0.7.3 |
> | --- | --- | --- |
> | Build time | 11.4 min\* | 5.1 min clean; 28–51 s using caches |
> | .. | | |
> | Render-loop allocations per frame (sprites) | ~80 KiB | ~9 KiB |
> | — | — | — |
> | Simulation step | 1.54 ms | 1.39 / 2.32 ms |

1.39 ms is better, but can you explain 2.32 ms? And why all that is better is better? Or conversely?

I haven’t seen it announced, is some Jule.jl forthcoming? I looked and only found here, maybe a false-alarm (in screen-shot filename):

> [@Anyone crazy enough to develop a pure Julia GUI toolbox?](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002/220):
>
> Indeed… (WIP) The same Julia code running on Linux, Mac and Windows. The UIs are native on each (GTK for Linux) and generated declaratively from the same TOML. The demo visualization is running on CairoMakie, GLMakie, and ModernGL,jl; the latter two are directly wired to Makie/Julia (it’s drawing to the native OS context provided by the declared UI, not image copying). They are wired to the native controls on the left for real…

So is this a competitor to JuliaC (and/or PackageCompiler), or some GUI/game tool?

> [@Crispy](#):
>
> Trim gets a lot of attention as it’s pretty cool, but I think it’s worth remembering JuliaC works just fine without trimming .. For games I actually think having a full fledged Julia environment around could be quite a powerful feature if you think about modding support.

Still does `--trim` work for you?

---

_[View the full topic](https://discourse.julialang.org/t/rocket-plumber-a-rocket-engine-and-spaceship-building-game-im-making-with-julia/140135)._