This video is part 2 of a series:

1. Lua Style Guide
   1. Formatting with StyLua
2. Lua Scripting Best Practices ← You Are Here
3. Organizing Lua Code With Modules
4. ‣

Setting up VS Code Environment

Writing Lua for Dream Editor Projects

Our game engine uses Lua to build game logic. Lua is a widely-used lightweight scripting system focused on speed and ease-of-use. Lua is widely documented and googling “How do I do X in Lua” usually returns useful results.

Install VS Code

To write lua scripts you should first install Visual Studio Code, an excellent, free, cross-platform code editor. When installing VS Code, be sure to check the “Add ‘Open with Code’ to Windows Explorer” option, as it will make your life easier in the future.

You may have a preferred code editor; but we only support our DreamEditor extension for VS Code.

1. Download and install VS Code.
2. Next, install the Funovus Lua extension. (See: Lua Plugin Setup)
3. Finally, install and set up the StyLua extension. (See: Formatting with StyLua)

We also recommend Code Spell Checker (or a similar alternative).

There are several ways of implementing classes and tutorials for object-oriented Lua programming. This can help you write cleaner code that is easier to read and maintain. Note that we use Lua 5.3.

Style

Be sure to follow our style guide: Lua Style Guide

Coding Guidelines

This guide aims to standardize the coding practices of all our of game designers across the design team under the same principles, styling, and conventions. These principles are to encourage good coding practices for readable, scalable code.

Code Best Practices

• Optimizing code for reading, not for writing. Your code is written once but will be read many times–by reviewers, by your teammates, and by you months or years later
  • Similarly, optimize commits for readability/reversibility. A commit should do just one thing
• Keep functions short and simple
  • Ideally a function only does one thing that’s easily described by its name
  • Functions with more than 3 levels of indentation usually means it should be broken down
  • Similarly functions over 100 lines are usually too long. Ideally a function fits entirely in one page view, without needing to scroll
• Avoid global variables when possible. Since global variables can be written or read from anywhere in the code, it can be difficult to remember every potential use