Core Lua

Read it. Build it. Make it yours.

A growing field guide to Lua and game development. Start with a practical tutorial, or look up the API you need for your next feature.

A miniature game developer desk with a code editor, keyboard, and orange lamp
YOUR LEARNING PATH

Understand the language. Then connect it to your engine. Tutorials use core Lua; engine-dependent reference pages are labeled separately.

Start with tables ↗

6 tutorials · 6 API references

Learn by building Small examples. Useful habits. Something to try next.

6 TUTORIALS

The reference shelf Syntax, safe examples, and practical scenarios.

6 REFERENCES

Engine-host APIs are extensions supplied by a compatible runtime. They are not standard Lua functions. Check your host documentation before adapting these examples.

Use tutorials and references for different questions

A tutorial is useful when you need to understand how several decisions fit together. The inventory walkthrough, for example, connects data shape, validation, ownership, and a practical exercise. A reference is useful when you want to check one operation's syntax, expected role, and integration limitations. Move between the two as needed instead of expecting either format to cover the entire project. The library labels core Lua separately from engine-host APIs because those contracts come from different places. A language example can run without scene objects, while an engine method requires a compatible host and the dependencies described on its page.

Build a small learning project

Choose a tiny project that can absorb several topics without growing into a complete game. A command-driven inventory prototype can use tables for quantities, functions for updates, a module for the public interface, and assertions for expected behavior. Add features one at a time and preserve a working version before changing the design. When an example depends on an engine service, keep the host integration separate from the ordinary Lua logic where practical. This makes it easier to identify whether a failure comes from the language model, your state assumptions, or the external runtime. A smaller project also gives you room to test rejected inputs instead of only demonstrating a successful path.

Keep a question log as you practice

Record the part of an example you could not explain before trying it. After implementing the exercise, describe what changed in your understanding and what remains uncertain. Useful questions include who owns a mutable table, what can happen between two yield points, and whether a failed operation already changed state. Return to the relevant reference when a contract is unclear. Check the version and libraries available in your actual runtime before adopting a pattern wholesale. Progress in scripting is easier to see when it is measured by the decisions you can explain and test, rather than by how many pages you have opened or how elaborate your folder structure has become.

Find your next tool or idea

Search tools, guides, and Lua resources.

↑ ↓ Browse resultsESC to close

Choose a tool