Hey, you can still play & rate my entry here!: https://ldjam.com/events/ludum-dare/59/sacred-bleorgan-artifacts
There's a timelapse of me coding here: https://www.youtube.com/watch?v=X2Jh97njZ6s
There's also a gameplay video here: https://www.youtube.com/watch?v=DsfZQCgSr2w

Sacred Bleorgan Artifacts Postmortem
It's a postmortem time! I try to write these type of posts after finishing a project because they allow me to reflect on things and grow. Or sometimes it's just funny to read how I make the same mistakes, all over again.
I always enjoy reading other postmortems as well, so be sure to write your own - and I'll be sure to watch out for it! This time I tried to be prepared even better, so I made notes for it during the compo. I used Obsidian which I use for everyday stuff and work, and this worked pretty well for me.
Theme
So the theme wasn't really my favorite, as you can see below. I had some ideas for "Side effects" and I thought "Leave something behind" and "The wrong tool for the job" were well, more "theme-y".

The event starts very late in CET (3 a.m.) so I managed to learn about the theme and went straight to sleep. In the morning I did some brainstorming and I explored couple of ideas, I'll basically paste them here:
As you can see, this brainstorming was quite productive. I knew I had to lock in so I decided on (this is an exact copy from my notes):
- player is a peaceful alien trying to get home
- enemies are humans who try to catch the alien for experiments
- top down (angled?) control to search for couple of parts per stage
- parts are visible only at the beginning, then disappear
- player must find parts based on signal
- audio & visual cue for signal strength
- enemies trying to catch the player
- player able to stop them for a while?
Not all of this is implemented in the final version, but I did manage to get some additional stuff (story!) instead.
Compo timeline
Unlike my previous attempt, I was able to define my entry as playable before the Compo deadline, and that was THE goal. Ten and a half years (!) have passed since my last successful Compo entry, and I am so very glad I was able to make it. I feel this is a massive success for me and what contributed the most was the preparation. Even just thinking about the event beforehand, having a "todo" list, cleaning up my desk - small things did contribute a lot.
I even managed to not spill my Saturday morning coffee (it's a reference to a previous accident):

The plan for the Compo timeline is generally kinda simpler than for Jam: you want to have the core mechanics done on the first day and deal with polishing stuff on the second day.
I mostly managed to achieve that, though there were some mechanics-related decisions that spilled into second day (opening up the ability for the player to transport on their own), and some initial polish was actually started on the first day (it did help though). I was able to finish like 2 hours before the deadline and decided to not pursue additional changes, which I think wasn't a bad decision, because I didn't have to struggle at the end.
What went well
Preparation
Whatever I managed to prepare the compo, was on point. Obviously, the code disclosed pre-compo with libraries, as well as having a base project ready, saved me some time. I actually had a large TODO "preparation" list - containing stuff like "prepare this and that library", out of which I managed to tick around half of things. I wish I had spent more time on actually completing that list, because during the Compo it turned out that:
- Having a clean desk actually contributes to my ability to focus
- Having a plan for non-coding things (timelapse, where to deploy, how to deploy) allowed me to spend more time actually focusing on the development
- I correctly identified areas of my previous code which could be improved (in fact, I should focus even more on this next time)
- My previously battle-tested code (as in, used in previous LD) was mostly just working - tweaks were needed around stuff which I had prepared, but not really tested
Preparation and how you do it (and what to prepare) matters a lot for Compo timeline, especially with code-first frameworks like PICO-8, because whatever you can decide to be the immutable (language, framework, even genre - if you're willing to decide on that upfront), allows you to make some preparations, even if it's just "thinking on how I'm gonna do this or that". With Lua, which is the language PICO relies on, even deciding on the type of OOP approach matters, and the impact is huge.
What also helped a lot (and what I didn't do last time) was taking a day off work on Monday. This allowed me to stay up late on Sunday, and to deal with the entry page on Monday, as well as finishing the timelapse and gameplay video.
Progression
My personal feel is that I have improved indeed, and that is usually my aim during LD. Even not really using Lua since the last LD, I was able to handle most of its quirks, though you can read on about all the stuff that went wrong down below.
To me - and maybe this is just a personal feeling - the game feels more complete than whatever I did previously. There's a difficulty progression, story (made in a very short time on the last day), animations, points. There are obviously problems related to these, but in my opinion I think I've gotten a little bit better with PICO-8.
Oh yeah, I mentioned this during last LD - the engine itself is great in its limitations. Worth every penny, and then some more. I mean, I don't really expect to win the jam or anything, because I understand that PICO aesthetic isn't for everyone and there's still room to improve on my side, but what works for me:
- while the system provides the basic tools (sprite editor, sfx editor, tracker), it really is programmer-focused
- the PICO limitations force me to reduce scope in general, but I'm betting that it's actually quite hard to actually e.g. hit the token limit for a Compo entry
- forced simplicity in the gfx/sfx area isn't limiting to me because I'm not even good using those simple tools, let alone something more complex
- it gives the illusion of developing on an old platform without the hassle of writing assembly (I might check that out though at some point though)
My physical setup was mostly similar to what I had the last time, with the addition of a better mechanical keyboard (NuPhy Gem 80), which I'm enjoying very much. I actually only used 1 screen - the other being reserved by OBS for the timelapse (see below) and Discord, which I didn't really use during the Compo.

Submission
As I write this it's still waay to early to say anything about the grades - maybe I'll do a separate post about these later - but in the end, what worked in terms of submission was
- deciding to stop development when I felt that additions would only add pressure to finish them but wouldn't improve quality that much
- putting a version on the LD page as well as on itch.io (I'm leaning towards going with just itch.io next time though)
- itch.io providing its own analytics as well as a way to wire into Google Analytics (it's really cool to see people from all over the world playing my game)
Design
There are many parts of the design that could have been improved - you can read about the problems below - but I'm also pretty happy with the initial design. I'm particularly glad that I added a cheat menu:

It's available in the compo build, just press enter. The implementation is hacky, but this allowed me to test without spending too much time on time-consuming task of searching the dig sites.
The second thing I'm really glad I did is the addition of those intermission scenes with the Bleorgan communication:

These allowed me to develop a story and I think it contributed to the overall feel of the game. I did it on Sunday evening, so fairly late in the process, and it was basically the last "feature" thing I added.
Timelapse
I have established a toolset for a timelapse last time, and it worked quite well again. Basically, used OBS to record everything with 2 FPS and then used ffmpeg to speed everything up - if you're interested in details then here's how (sharing because I've spent a while before the compo researching that):
ffmpeg -i "recording.mkv" -filter:v "setpts=PTS/240,fps=60" -an timelapse.mkv
I took timelapse music from https://ende.app.
https://www.youtube.com/watch?v=X2Jh97njZ6s
There's also a gameplay video, if for whatever reason someone just wants to view my game, not play it.
https://www.youtube.com/watch?v=DsfZQCgSr2w
What should be improved
You may have thought until now that everything went just great and I had no problems during the development. Well, no. I actually made sure to write down anything that bothered me during the event so I can actually think about how to improve there.
So here it is, grouped in categories.
Preparation time
I should have spent more time preparing libraries in particular. Classes/OOP worked great because I actually battle-tested them in previous 2 LDs. I actually had some code for everything - but for example:
- event system should have been re-reviewed and tested (I finally didn't really rely on it that much)
- same related to animations - which was probably more important than anything else (I had to re-do animation system and had to take serious shortcuts to have it working within my setup)
- complex multi-state animations, effects, particles and a lot of timed events were either skipped or built from scratch even though I should have a subsystem for each of those ready
- same related to collisions (I had a vector library, but I should have reviewed the methods inside)
- same related to camera (I ended up integrating quite well with PICO's camera, but I could have spent the time elsewhere)
What's probably most important is this: I really should have done Lua/PICO-8 mini projects. This should actually be my priority next time before the event. This would show me explicitly what kind of problems I might encounter and by the time Compo starts I might have an idea on how to solve them, instead of trying to do that during the event.
Technical problems
On Saturday I have spent over 1h 30m on a bug which was entirely my fault, and I couldn't figure out why it happened. It's entirely on me, because it was a concurrent list modification issue - not trivial in a system of containers containing containers where you're trying to remove something, but still my fault. When I found the issue, I was just mad at myself.
I think on Sunday I've found out first hand that calculating distance (vector length) with traditional (naive?) approach in PICO-8 will cause overflow problems - (see vector magnitude). It also took me a while to figure this out, because outside of PICO, I rarely have to really consider this kind of thing. I wasn't mad at myself because of this one though - I just didn't expect to see it.
And then there's code quality. I mean, I obviously don't expect much from a timed competition, but I feel that my code should be some sort of an example in books, to illustrate:
- what you shouldn't do 😅
- why hurrying too much leads to technical debt
- why we should keep classes/objects/functions in separate files (keeping them in single p8 file made searching for the correct object a chore)
I probably could have put some more polish on the last day, but because of the code quality, I struggled with managing animations, timed events, and graphical fluff. Really need to invest pre-event time into having a proper solution there.
Design issues
Even without the full feedback, I already noticed couple of issues. There was no time for playtesting the game during the Compo (also another thing to improve), but I've observed others playing after the event and this feedback would have impacted some of my design decisions.
For example, when generating enemies, I pick a random point on the ring within a constant distance from the player. This itself was just a hack to make sure that there's some constant pressure put on the player - and that works fairly well (would have been better with another animation to be honest). However, when the player is standing close to the edge, this becomes an issue, because anything generated outside the edge gets pushed in vertical or horizontal direction until it is inside the play area.

This means that whenever a player is very close to the border, they risk having the humans generated very close to them, which really isn't ideal. The situation is even worse close to corners. Unfortunately, dig sites also can generate close to the border, which forces the player to stand close to it when digging. There's an easy fix for that, but I missed that issue during the event.
Handling border was generally something I could have spent more time on, because when something is generated close to the bottom area, UI tends to obstruct the view:

I mean it's not the worst but the experience could be better. What I should have done is either remove the text when the player is there or move it elsewhere. A good alternative would be to just not generate dig sites so close to the border, but I already mentioned that.
I started truly playtesting (on my own) pretty late in the process, and I think that actually contributed to the final outcome the most. In fact, I'm pretty sure that finding someone to playtest my entry during the event would be something that would significantly improve the experience. AFAIK this is allowed by the Compo rules, though I cannot find a source for that statement. 😅
Also, I'm pretty sure that no one actually gets to see this pretty situation:

If you wait too long, the transport area shrinks to zero, and it's not possible to get extracted. Unfortunately for the player, humans probably will capture them and... well, best to think about something nice then.
On the "no AI" challenge
I made a post about the "no AI" challenge before the event, and I was able to complete my challenge fairly well (it would be quite weird if I didn't, haha).
I have my reasons to avoid AI usage (see below), especially during Compo, and I made significant effort to avoid anything AI touched. That included also things like Google searches with -ai (works quite well), my VSCode having everything AI-related turned off, etc.

Just to be clear: I don't want to bash anyone for using AI assistance. There are different views on this topic, and the LD rules do not forbid the usage of AI code.
And while I think that game jams generally benefit from having a separate category for entries with AI input, it's important to recognize that Ludum Dare rules do allow AI-assisted coding.
I'm sure there are some people who feel enabled to create their game because of that, and for that reason I'm going to stay unbiased. If it so happens that a good entry was made with AI-assisted coding (and I've already seen a couple of those) - well, maybe that's the reality of it.
As for my personal reasons for not using AI, I want to cite part of a comment provided by @skleembof in one of the recent posts, because it resonated with me:
I tried AI assisted programming a couple of years ago and while not as effective as today it was still good enough to produce usable code. I thought it would help me improve my programming and that I could just use it as a rubber duck with no downsides, but after moving on from the simple problems it was easily generating code for, I ran into the biggest issue with ai code assistance: it was literally making me dumb and lazy.
When it failed to generate code that worked or met my requirements, I found an extremely powerful urge to just keep prompting it instead of looking up documentation and trying to solve the problem myself. My eyes would glaze over when trying to read docs or explanations on stack overflow.
That experience made me realize how dangerous it is to offload thinking to an llm. Even if it can generate code for you, what then? You’re no better off than before except that now you have some code that you didn’t write. You’re not a better programmer, and your future relies entirely on the graces of our insolvent ai overlords. What happens when token prices inevitably skyrocket? Do you think you’ll be able to flip a switch and go back to learning the hard way? Will your cognitively impaired brain have anything to show for after these x years of experience as a game developer where you relied on an LLM? I for one do not want my ability to make games to be tethered to the whims of massive corporations (which is also why I’ve moved to fully open source software over the last few years).
This is totally true for me, because as a software engineer I see this everyday at work, but it became particularly important to me when it comes to my creativity. Your experience may be different, and I accept that. That being acknowledged, I'm pretty glad I did everything on my own, even though I'm pretty sure that some things would have been faster with the help from clankers. 😉
Summing up

As always, Ludum Dare is a wonderful experience to have. I mean, it requires pretty significant effort, as always - but the satisfaction is tremendous.
As always, I'm very glad I did this. It's really a great community and I'm so glad to be participating and to be able to play all your games. Thank you all. ❤️