Thread by @xphere

As I started some projects over the years, be it gamejams or prototypes, I’ve thought it’d be helpful to have a #GodotEngine game template to speed up some steps. The fact is, I was working on that project already without knowing it. Want me to elaborate? 🧵👇🏻

It suddenly came to me as an idea while doing one of my first jams. And I’ve been reimplementing most of it on every project. Maybe because I didn’t know better. Maybe because I was comfy in that organization and wanted to make it grow. Iterating organically over it.

Here’s the deal. I’ll try to explain the idea here, for anyone who wants to hear it, but also to let it out. It’s been growing within me for a long time, but I need others’ opinions to make it better. Or to crush it under a rock.

Warning: This is going to be a long thread, I'll try not to be too dense or boring, nor go into too much unnecessary detail.

The idea is simple: A game is not unlike a movie or a play. You have scenes, characters, a story… And like movies and plays have been doing for all time, why not present our videogame in…

A Theater!

Obviously, I'm talking about an abstraction of the concept, oriented to structure your game. Everything in the game runs inside the theater, and it should provide encapsulation around scenes, characters, stories, and most of what you need around your game. It's a framework.

I’m a firm believer in the separation of concerns, and the theater abstraction helped me a lot to dive deep into making small decoupled pieces that interact between them without knowing each other. A single responsibility. Godot just made it possible and easy.

A theater requires some components and assistants to work. Some are core to any play, but most are optional. As always, YMMV, and that’s why I wanted to have a template as modular as possible.

So, it is the responsibility of the THEATER to put together all the components and connections between them. Its lifetime is that of the whole application, from the intro to the final credits. It wires everything and then starts the show: The main loop.

One of the big problems is to find words from the theater world matching the intents of our collaborators. Some might come easy peasy, but others might sound a bit odd. The challenge is to keep it in the theme without forcing it too much.

Now let’s go to the parts. I think we will agree on this: the main feature of any theater is the STAGE. This is where things happen and the story unfolds. Scenes and actors come and go, but the stage is always there.

In front of the stage, we have a classic: the CURTAIN. Between acts or changing scenery is nice to have the crowd distracted with something. Here in our case, we’re going to play our transitions: fade in, fade out, loading screens… you name it.

And framing the stage, there’s the PROSCENIUM, which is a fancy name for the stage frame. So any decorations come here: frames, columns, or full-screen shaders. Anything that needs to be in front at all times. I like to put here a palette look-up table shader, among others.

It is obvious that we can live with no curtain and no proscenium, and we might still have a great play. The theater's job is to make this transparent. So these two might be optional, although a great addition to our toolbelt.

I like to have many small pieces that focus on just one thing, but, if you feel like it, the following three elements could be merged into one, because they shape the choreography of scenes that will be shown to the player.

The DIRECTOR knows which scene is on stage right now, and listens to the cues in order to ask for scene changes according to the script.

The SCRIPT knows where to get information about all the scenes in the game and what cues are required to move from one to another. It’s the place where this knowledge is stored, be it a file or another resource.

And finally, the STAGEHAND knows how to load a scene into the stage. Sounds easy but it’s not a task you should take lightly or mix with other concerns.

As I said, I like to have all those pieces decoupled and simple, so the only class you have to change is the THEATER itself. In there you add the required components, connect them and offer helper methods for the scenes. It’s a façade.

This is a required element of any game that often doesn’t get modeled at all: The AUDIENCE. Here you might want to encapsulate your players’ profiles, saved games, custom input bindings, controllers… Anything related to the player so they can enjoy the ride.

And what would be a play without a CAST? Here you can keep information about all characters, stored for reference. For example, to get their names and portraits so we can show them in dialogs or other user interfaces.

We’ll also want to have some music in our game, and sure it’s easy to put sounds here and there in your scenes, but please delegate art to professionals. So we’ll have our own ORCHESTRA, which might also help with SFX, buses, and sound effects.

Trust me on this one: You’ll avoid lots of trouble with songs cut when changing scenes or sounds restarting when they shouldn’t. Keep it out of the stage and you'll be safe.

And finally, I like to put all settings at the BOOTH, where the player can change them during the pause or the title scene. Makes adding new configurations easy.

Pfew, what a wild ride! This is just an example, one of many, of how to structure your projects and split the pieces in your code so you can reuse them every time you start a new project. Most of them are easy to program and forget about them later.

I’m trying to make this work on Godot 4.0 latest beta, might share the code when I’m confident. In the meantime, I hope it helped you or make you think a bit more about structure, but I’m really open to feedback and criticism. Would love to discuss more this topic!

And if you find this thread interesting, remember to retweet the first tweet, share it with your gamedev peers, and click follow if you’re so inclined. Thank you!