Game Jam Day 3

Tag: [day-3]

Thinking about game state vs. UI state

Continuing with the model–view–controller thinking, we moved the state.running variable into a separate mutable variable. The state.running flag had been used as a signal for the main loop to exit. The :QUIT execution handler would change it from true to false.

The thinking here is that a running or quit flag is not part of the "game state" as such. The game state tracks things like the player inventory and the contents of rooms. Setting a flag to make the program exit is more of a UI concern, not part of the game logic—even though it is controlled via an in-game command. (I guess this would be a case of the "controller" (the text I/O loop) affecting the "view" (the user interface) rather than the "model" (the game state).)

Following this same line of thinking, when we added a new :DEBUG command (which controls whether to verbosely display how each command is parsed), we made the state flag a mutable global variable, not part of the state table.

The current rule-of-thumb thinking is: would it make sense to save and restore this variable as part of the game state, if the game had a save feature? A running flag doesn't make sense in this light. A debug-flag arguably does not. Think of this: if you are playing for a while, you set the debug flag, then load an earlier save that did not have the debug flag set, would you expect the debug flag to be turned off after loading the old file, or would you expect it to continue to be set? It seems more natural to make a debug flag a property of the gameplay session (the view), not of the game itself (the model).

To some extent all this is splitting hairs: it wouldn't get in the way of making the game if we were to handle all these state variables one way or all the other. But that's part of the reason behind doing the game jam, to get exercise thinking about things like this.

Look commands and long room descriptions

We started by printing the current room name and full room description each time the main game loop executed, which meant that the full description was typed after every user input command. Ideally, we'd like to print the long room description only once: when we haven't visited the room before. We added a list of visited rooms to the game state table, which is updated each time we visit a room for the first time. The second and subsequent times you enter a room, only its short title is shown. We also added a :LOOK command that prints the long room description again:

>n

Tar Pit
>look

Tar Pit
Before you is an odiferous pool of bubbling tar. You can see warm sunlight in an opening to the south.

The question naturally arises: should the visited table count as part of the game state? Maybe, when you reload a saved game, you do want the long room descriptions to be repeated again. Better not to overthink it!

Brainstorming game objectives

The ideas for a theme and goal for the game are becoming a little more solid. We know we want a clock tower as a central location. Maybe there are puzzles that let you advance up the tower, and the ending is at the top?

Parser

We started work on an LPeg-based command parser to replace our ad-hoc parser, but did not commit anything yet. One unexpected discovery is that LPeg is not a pure Lua module, but compiled C code, which has the potential to complicate distribution of the game, as we'll need to compile the module for every platform.

Fossil repository files

Copying the autumn-lisp-game-jam-2025.fossil to another computer and trying to open it by default tries to autosync with an HTTP remote and username that evidently are embedded in the repository:

$ fossil open ../autumn-lisp-game-jam-2025.fossil 
Pull from ht‌tp://flutter@10.7.7.1/autumn-lisp-game-jam-2025

You can avoid that with --nosync:

$ fossil open --nosync ../autumn-lisp-game-jam-2025.fossil 
CREDITS
conf.lua
fennel.lua
game.fnl
main.fnl
main.lua
sounds/21singers.mp3
sounds/BG_FROGS.ogg
project-name: Autumn Lisp Game Jam 2025
repository:   /home/user/autumn-lisp-game-jam-2025.fossil
local-root:   /home/user/autumn-lisp-game-jam-2025/
config-db:    /home/user/.config/fossil.db
project-code: 92908f4c0e79e2247f0727969093109be3e72e51
checkout:     0428a125f53c5c7adb8461c86b7679dbb3bf489e 2025-11-02 16:36:57 UTC
parent:       c5fdddf8ab04375a9ba61a21c8c40e531166008c 2025-11-02 01:01:02 UTC
tags:         trunk
comment:      Move state.running in a global quit variable. (user: flutter)
check-ins:    43

But it shows that something more is needed than just copying the .fossil file when you want to publish your repository. It's not like a Git bundle.

The Fossil quick start page says:

A Fossil repository is a single disk file. Instead of cloning, you can just make a copy of the repository file (for example, using "scp"). Note, however, that the repository file contains auxiliary information above and beyond the versioned files, including some sensitive information such as password hashes and email addresses. If you want to share Fossil repositories directly by copying, consider running the fossil scrub command to remove sensitive information before transmitting the file.