Lampyre

Lampyre development journal (1)

Here comes the first development journal post regarding Lampyre on the new (and adorable) Bear blog. This transition is both exciting and a bit frightening for me.

The plan

My previous (french) development blog is hosted on blogspot. It holds the big coding summaries written once every few months - each time I was completing a major coding segment on my game.

I am still unsure whether Bear will be the adequate support for my development updates. But after the last holidays, I decided to merge the tiny, daily twitter demos (which are cute but sometimes felt lacking if I had nothing tangible to show) with the too occasional large update. Each week will try to be a self-contained sprint - I'll aim small and simply post more regularly if needed.

The posts' design will certainly be refined with time, but I'll try to cover the following key points:

The first weeks probably won't have any other visual media than a twitter post to demonstrate our work, but that's okay. I'll upgrade the blog for hosting pictures once I'll be sure Bear is the right place to post about Lampyre.

🗃️ What the ending sprint was about

Last coding sessions on Lampyre happened at the start of January (just before we foolishly decided to spend a week coding a time timer). Its objectives were the following:

Of course, all these objectives were not supposed to be completed in a one week span, but this is a useful reminder of where we stopped.

🪴 Sprint conclusions

Difficulty (how complex the sprint was): 3/5 🟡
Progress made (how much of the desired functionalities were developed): 4/5 🟢
Sprint time accuracy (did it take the time we thought it would take): 2/5 🟠

My progress was fine. The buff/debuff system works perfectly and we can now do some of the most important basic actions required for the game to play out (mostly, how the first few minutes of the game are starting out and what's the basic game loop).

What threw me off is overthinking the crafting menu prototype. Which by the way, at this point, has nothing inherently wrong (yeah, getting anxious when everything is going well - great job). The campfire is the most basic crafting UI you can get in Lampyre. All other crafting places will share the same recipe system, except they'll sometimes have their own mini-game attached (cooking superior dishes or assembling medicine and dyes should prove fun). And all other crafting places with a fire source will be fueled this exact same way as our first hearth.

The cooking fire know fully recognize its pyre as its own, and you can properly ignite it with either a lighted torch, or by spending a few seconds snapping two small stones (forest hiker or caveman style, pick your ideal survival model).

I was about to code how the fire gets refueled, and with what. And since the cooking light source functionally works as any other flame in the game, this amounts to deciding how every lantern, fire ou pyre gets refueled too. Quite the crucial design step, for a game called LamPYRE where the whole point is fighting off shadowy creatures.

Building UI is notoriously time consuming, even when properly optimized for inherited menus that will pop out later - and even when as I try to keep it at its bare minimum for prototyping. So this mixture of "slowing down to make menus functional" and "not knowing if my basic systems were properly fun and intuitive" pushed my inner rambling levels over the roof.

It is now time to stop fooling around and smash this prototype.

🕯️ Notes and insights

As I driveled about in my time timer post, UI and game design hiccups have not been my only problems. I also realized that :

  1. My iterations cycles were far too long and too imprecise (not letting me test each mechanic independently to check if they're fun enough on their own).
  2. Since the load and save coding sprint, my testing workflow has become inappropriate - I'm booting up the game starting menu and map generation each time I want to control the game behaviour. That's five to ten seconds uselessly lost on each execution. Repeated ten, twenty or thirty times an hour. Plus, it prevents me from properly isolating game objects from the overall world managers (a campfire should work on its own without any global building or gamestate manager).

A short clean up of my testing scene(s) is overdue.

On the bright side, upgrading to GODOT 4.5.1 brought massive performance improvement on the game starting and loading processes. I don't know if it's specific to the DEBUG mode or also applies to the exported version of the software, but holy moly - I've never gained so much speed through a simple executable download. The developers community does an amazing job and I'm eager to start applying "real" visuals to Lampyre, especially since the GODOT Shader Bible is soon to be available (hardcover version, I'm dearly waiting for you).

Engineers did warn us for decades long: keep your software updated.

Unless it's Adobe.

🔭 Next sprint overview

Sprint end target: 18th January.

Objectives

  1. Isolated and object standalone arena.
  2. Game world with normal management nodes but without any procedural resource generation (everpresent nodes are the GUI, the game map manager, the world items manager, etc...)
  3. Game world with management nodes and a random, average resource generation.
  4. Game menu navigation and map generation interface (current).

Bonus

⚖️: balancing / 🪲: bug fixing / 🩹: gameplay change / 🛠️: major feature / 📝 : game design

My time estimates are probably going to be a little off for the first few development updates, so I'm betting on a soft (but efficient) start with speeding up the testing environments. Then, back into the fray with the game lights fuel management.

If I complete my objectives way too quickly, the next sprint will simply start sooner. And if I'm late, I'll still update our progress next monday no matter what, to reflect on my coding week and see what went wrong.

Let's get Lampyre's development rolling again full speed through this new year.

#GDScript #GODOT #gamedev #lampyre