Development has been moving along steadily with Sad Land this month. In last month’s newsletter I shared my new vision for the demo, a prologue chapter taking place in the protagonist’s dream. I spent some more time this month building those rooms out and am nearly finished with coding all of the pieces that need to connect to make it all work. Since this vertical slice of the game has a clearly defined framework and straightforward logic, I won’t move on to any sort of polish until the experience is playable from beginning to end. Although I always find it enticing to polish assets that are incomplete in the build, I have been working hard against that habit. I need the demo’s framework set in stone and playable from beginning to end first and will take time to refine and polish it all once the time comes.

The above code block is an example of the logic I’m coding for the main hub room. This type of logic work has been a priority for weeks now and I want to at least share a brief view into how I’m approaching these problems and how they are solved. Some code is set to cycle continuously or repeatedly as the game runs (the code for the character’s movement, for example, runs constantly) while other blocks of code run at certain designated times. This sample code is used infrequently, set to run only whenever this hub room is entered or refreshed.

Much of the game is always going to be presented to the player the same way every time but there are some aspects that might need to be added or removed depending on where the player is in the game or what the player has accomplished. There are a few game objects that are set to appear when you first enter the hub room on startup but should not appear any other time the player reenters this room.

Like a table set for dinner, many items are to be laid out the same every time with certain variables that will alter the layout. Maybe the table is always prepped with four chairs, four plates, and four napkins, salt and pepper shakers, and a candle in the center. The variables that change every time might include the guests seated at the table, what meals they’ve ordered, what drinks they’ve ordered, and what cutlery might be needed for each meal. Would you like desert? That will require a reset of the table with a new platter and new cutlery but, unless someone spilled wine, the tablecloth will remain a constant throughout the evening.

In the demo, once the player talks to the first NPC, the “spirit skull,” the variable area_0_completed is switched over from FALSE to TRUE. Then each time this room reloads, the game will first check if area_0_completed is set to TRUE (line 2) and if so will destroy that instance of the “spirit skull” (line 4-6), the special game object of the player character that only appears at the start of the game (line 8-10), and the visuals for the fence along with its collision object (line 12 and 13). I don’t know if this is the most efficient way to code the game, but it’s simple, it’s legible, and if I come back to this in a month or so, I’ll know exactly what it does.

The map I shared of this same area last month included a fifth access point to an area to the north but has since been removed. Of the five areas, there were two I was having trouble pinning down. Both had some identity but no clear direction. My solution was to merge the two ideas and trim the number of areas to explore from five to four. Not only did this cut down on the overall work I’d need to do for the demo but helps the player easily construct a mental map of a large square room with four corners. This is the type of design problem solving that I relish. Any time I can add by subtracting, sharpening the piece while cutting down on the potential workload, is a wonderful discovery.

I’ve also added four flower box objects to the center of the map that track your progress as you go. Each time you complete an area, a corresponding flower box is added, communicating to the player what zones have already been explored. In the image above, the flower box in the top-left corner is absent, signifying that this area has not yet been explored.

One smaller project I’ve been slowly working on in the background alongside my game and this newsletter is my website. In an effort to keep ongoing costs low and have complete control over the design elements of the website, I rented some cheap server space on Digital Ocean and have been handling everything else myself. It’s been a slow process, especially to get it looking decent on mobile devices, but I’ve learned a lot and now have a public archive of all my newsletters to date.

I hope you enjoyed this little buffet of production updates! Week by week, I’ve been laying the groundwork for the demo’s release with my sights set on having it available in Q1 of 2026. Hope you had a lovely and relaxing Thanksgiving.

Sincerely,
Neil