Subtitle: A framework for ambitious projectsI had never written a line of Gleam before deciding one day to build an entire game engine. I hadn’t even built a game on an existing engine. But I dove in, and along the way, I have uncovered lessons worth sharing.

In this talk, I’ll explain why I picked Gleam to build a game engine, and reflect on the most important takeaways I have found (or that found me).

## Why Gleam?

Gleam is a strongly typed, immutable language. When building a game engine there are two things that make Gleam a no brainer.

### Constant Loop of Updates

Strong types and immutability help avoid unexpected side effects that can quickly pile up in a game loop when building reusable systems (animation, rendering, camera & focus). Allowing you to safely operate on your game state in a constant loop.

### Full Power of Two Runtimes

Gleam compiles to both Erlang and Javascript. This means my server can leverage the full power of the BEAM, while I take advantage of the browser on the client for rendering the graphics.

## TakeawaysSome insights are technical—like how to navigate browser quirks and tackle performance challenges. Others are about mindset, such as breaking down impossible problems or starting before you have all the answers. I’ll even touch on why you don’t need the “perfect” data structure to get things done.

## Why this talk matters?

1.    We need more people to realize you don’t need special knowledge or permission to start building something awesome.

2.    Sharing practical techniques, lessons, and also failures will help them find success when they decide to take the leap.

Let's inspire more people to just dive in and chase ambitious ideas!

PS - I’ve been sharing my journey in my “Game Dev Logs” if you want to poke around:

•.   [Game Loop](https://wking.dev/logs/game-loop)

•.   [Update Loop](https://wking.dev/logs/update-loop…)

•.   [Render Loop](https://wking.dev/logs/render-loop…)