Primortal

Now you can select where you want to deploy your Animech, from your space ship! I’m really happy with the vibes in the cockpit with the stars. I was able to refactor my Xenolog screen utilities in order to build out the navigation computer pretty easily. It’s all coming together :)

Now my shadow mobs leave little cute footsteps. Running into these guys starts a battle, this was my take on the more random “tall grass encounters”. I plan to alter the shadow mobs to hint at what creature they might be: color of the shadow, size/shape of the shadow, size/color/pattern of the footsteps, etc.

I made a new font! I wanted something italic for my “internal dialogue” boxes, styled differently than actual spoken dialogue. Fun fact, did you know there are over 2,000 unique two-letter character sequences? This font required ~450 unique kerning rules for custom letter spacing. My first (non-italic) font only required 2 or 3…

I call it FF57I (very creatively, for Fisher’s Font, 5x7, Italic)

It’s been a while - ARC Raiders has taken up more of my free time than I’d like to admit… But! I’ve been working on some combat improvements.

Statuses: I tried to convey more details about status conditions. I’m worried it’s too much currently - but I’d rather add too much up front and then only keep what’s important later. That said, I was able to create visual feedback for all the parts of a status:

• Statuses are applied with “stacks” which are removed over time. This is shown with the status background, it’s kind of like a vertical progress bar.
• Based on thresholds of how many stacks are applied, the status is in level 1, 2, or 3 - indicated by the dots below it. As the level changes, a “upwards” or “downwards” animation is shown on top of it.
• Statuses trigger their effects every 4 combat ticks (starting from the time they are applied). This is indicated by the “rotating” and flashing border.

Move “Animations”: Not to be confused with actually animating my sprites, hehe - I added a flexible system for adding sprite transformations as skills are triggered. This was a relatively cheap way to add some much needed visual feedback for combat.

Tempo: Combat doesn’t have to be real time, but if you queue moves fast enough, it is. If you’re able to keep moves queued you increase your tempo, which adds a damage bonus. This used to be a tick counter, but I’ve changed it to a more abstract gauge.

Overall, I’m trying to focus on adding some more feedback elements (animations/sounds) to help the player understand if their actions are doing what they want. Combat is a tricky thing to balance and tune. I’m eager to get sounds working - and then I think I’ll be at the point where I’d be happy to get some play testing and feedback on it.

Sounds! I’ve been working on my sound engine - something that has barely existed until now. There are two big updates shown in this video:

• Dialogue Sound: I emulated the Golden Sun dialogue sounds, I’m quite happy with it. It’s still a little squeakier than I want it - but I’ve made it possible to tweak energy, pitch, speed, “worble”, etc. to get different voices for different characters.
• Spatial Audio: Entities can now emit sounds, and respect fall off configurations based on their distance from the camera. You can hear the energy shield door get quieter the further I walk away from it; you can also here the footsteps of the NPCs in the hallways as they walk by

I just grabbed some royalty free sound for now to work on the audio system, but I need to start putting my Foley Engineer hat on soon to start figuring our the “sound identity” of my game. Having realistic sounds doesn’t fit the visual aesthetic, so I need to lean into heavily compressed/bit crushed GBA-esque sounds.

This bug has been haunting me since day one…

My camera follows a targeted entity, lagging slightly behind and speeding up as the entity gets further away. There’s an equilibrium met where the speed of the entity matches the speed of the camera as it tries to catch up. This creates nice, fluid camera movements when the character starts or stops moving.

The problem is that slight differences in frame timings cause the camera movement jitter between two pixel coordinates, making the entity’s render position flicker by a single pixel. The effect is subtle, it just makes the animation feel “off”…

The fix wasn’t obvious. I started tracking the standard deviation of camera-to-entity deltas over N frames. When the deviation’s low (steady motion), I lock the camera delta to a fixed threshold to stop per-frame jitter. Once it rises above that threshold, normal logic resumes.

The result? Smooth motion at last - no more phantom jitter, and I can finally sleep at night.

Today marks the first time that my custom game engine was used to actually create a game-like over-world experience! I’m working on building out the initial game loop for my first play-test build, and I can only do that thanks to the recent work I’ve done on my entity control system.

I loved being able to add dynamic dialogue fairly easily (e.g. tracking if you try to take other people’s papers, how many times you try to enter a private area) - and design some decently complex world state sequences.

Here are some screen shots of the Tiled map for this scene:

I spent a lot of this weekend working on the startup sequence of my game. Primortal is a love story to the GameBoy Advanced and my childhood playing on it: it’s rendered in 240x160, and your inputs are limited to A/B/Start/Select/D-Pad.

So when a player starts my game I want them to know, in their bones, that they’re getting into a GBA game.

This is what I came up with :) I’m very happy with the visuals, I want to keep working on the audio, but today is honestly the first time I’ve touched music editing software in almost 20 years… So it will take some practice.

I’m a little concerned about flying too close to the sun with some of the mimicry/homage that there’s some copyright infringement? I hope not… What do you think?

Just a small update on my NPC path finding. I was fighting some bugs that I’ve worked through:

• They were sometimes taking slightly non-noptimal paths (like, overshooting a turn).
• They were getting stuck for longer than I wanted.
• They weren’t adjusting their plans as things change in front of them, only once they ran into stuff…

To help understand the issues, I added some debugging logic to render their path ahead of them, it helped A LOT in identifying the actual issues. Plus it’s really cool being able to see their plans and how they change based on your impact.

The only thing left that I want to do is adding the walk-back fail safe, but at this point I think I can just design my world to avoid it as a problem. I’ll come back to it another time.

Adding/deleting entities & path-finding improvements

Up until today, entities could only be added to the world when the Tiled map was loaded. But I’ve added dynamic system events for registering and deleting entities. In this demo video, I added a button to spawn a new entity, who will try to walk across the map before triggering their own deletion.

I’ve also improved my NPC path-finding algorithm immensely.

• Cached paths: A scripted behavior used to just run an A* algorithm every time an entity was idle. Now it caches the last path calculated for a few seconds, reducing CPU load. It will still re-calculate its path if it runs into an issue. I exponentially backs off those retries if they are continuously stuck to avoid using up too much CPU when an NPC is stuck.
• Dynamic impedance: Originally, the algorithm only supported binary “blocked” or “not blocked” tiles. Now tiles and entities have a dynamic impedance, a weighted value of how much of an obstacle something is. A wall has an infinitely high impedance, while an NPC that walks around has a low one. This allows NPCs to identify paths that go through closed doors or other NPCs (if there’s no other way). I eventually want to add controls to my map file that create “encouraged” paths, which would just be a series of tiles with lower than normal impedance values.

There are still two improvements I want to make before moving to my next focus:

1. Predict future (non-)impediments: if an entity that is in an NPCs way is actively moving (out of their way), we should ignore their impedance. As of right now, all NPCs think all other (moving) NPCs are just static obstacles. They all try to walk around each other, even though they’re all going to the same place. It’s more like a stampede than a queue.
2. Backtracking when stuck: If two NPCs get in each other’s ways such that there’s no way to get around each other - they’ll just get stuck forever. I want to add a mechanism to walk backwards a few tiles on a random rare occasion, letting the other NPC through. This would be more of a failsafe than a feature - to prevent a game sequence from getting permanently stuck.

I can’t believe it’s been over 10 years since I first learned of A* in school… It was honestly one of the most magical home work assignments I did - just a few dozen lines of code and, ✨ta-da✨, magic, you’ve got something “intelligently” moving around your world…

I’ve decided on a title for my game (which I have been calling Project F). Introducing… Primortal: Soul Remains

And with it, I came up with a title card and simple animation sequence at game startup 😎

In the game, a “Primortal” is the physical and metaphysical essence of a creature. It is comprised of everything from the anatomy of a creature, to it’s DNA, to the fingerprint of its soul… With it, your Animech can learn that creature’s abilities. The name comes from these roots:

• Similar to “primordial”: existing at or from the beginning of time.
• Primal: relating to the most essential or powerful forces in nature or behavior.
• Mortal suffix: a life that is subject to death

“Soul Remains” is a play on words in a few ways:

• The game explores what a life is, and what happens when you die - does your soul remain?
• You are the last remaining person in your circle - all your friends and family have died. You are the soul remaining person in your life.
• As a result of this trauma, the character disassociates - what remains in the world is their soul - wandering through life (until you find a new family and come to terms with the past)
• As you capture Primortals in the game, there’s a moral and ethical question around the practice. Does their soul remain? Trapped in some prison?

Here’s a snapshot of the title card, in all its glory:

Scripted entity behaviors! Here’s an example of the player remotely controlling another entity by pressing buttons. Once the NPC steps on one of the end-spots, the NPC walks itself back to the start.

Since my XenoLog posts a week ago, I’ve been busy re-writing my entire entity control system for the over world game state. It’s taken 5,000+ lines of code over 100+ files, but it’s been worth it! Entities no longer implement a single interface, and they no longer interact directly with the dozen or so sub-systems that make up the over-world state.

The entity system was revamped, and now maintains 5 independent components for each entity:

• Position: Where they are, and how they’re moving
• Behavior: Automatic updates the entity state every tick: player controls, NPC wandering “AI”, scripted motion, etc.
• Renderer: What sprites/lights/animations to render
• Occupation: Which tiles they are “in”, important during movement
• Presence: How they engage with other entities (i.e. can the be interacted with? do they block ingress into an occupied tile?)

On top of that, all changes to entities and other game state components go through a new Event & Effect dispatcher, decoupling triggers and side effects. This allowed me to implement a Plan system with which I can queue up combinations of serial and parallel effects in whatever sequence I want. At the moment, the system supports:

• 10+ events (entity enters a zone, player interacted, scripted movement completed, etc.), and
• 25+ effects (trigger dialogue, mutate entity, change camera, swap out entity behavior, etc.)

This all culminates to parameterized, generic entity creation. I can register bespoke (or reusable) entity constructors and event handlers and reference them within Tiled (my map editor) when creating entities. These can be used to create flexible NPC interactions, dialogue sequences, teleportation, basically anything you need to do to control a game entity.

I feel like at this point, I’m close to completing the “build the game engine” milestone and I can start focusing on actually working on the “true game”.

A lot of this stuff I’ve built is already available in something like Unity or Godot - but part of this project has been about proving to myself I could program a game without. It’s been a lifelong dream to build a game from scratch - seriously, since middle school when I first played with HTML. So I’m super proud of this specific update.

Another one of those “doesn’t look big, but is massive” updates… 😅

I added a full event & effect system to my engine, replacing a dozen smaller systems I had built to facilitate all of the other game mechanics in the over world.

That meant re-implementing: interactions, dialogue/chatter triggers, timers/delays, movement restrictions, zones, combat triggers, teleportation, state transitions, camera adjustments, and more…

But, hey! We got there! :) It just took 3-4 full evenings of effort… The only thing not working is dashing across gaps, that was a problem for another day…

On top of that, I added support for JavaScript event handlers, allowing me to embed JS directly into my entity definition in Tiled. This will hopefully make it easier to create more interactive worlds directly in the map editor, without having to hop around between my code and map editors. Event handlers can be written in Go, along side the rest of my code, in JS files (edited in my IDE) and referenced by entities, or inline directly in Tiled.

The default property editor is gross in Tiled for code snippets (see the video…), but I’m working on a fork of Tiled to support basic JS editing with autocomplete and linting based on a types file! Here’s a little look at that:

Oh, I also added some actual settings in the menu, allowing me to more easily tune of knobs to debug rendering issues. Nothing for real players though…

Another seemingly small, but large world editing update - dynamic ambient lighting! Up until now, my lighting layer had a single base color. I added functionality to my map loaded and scene renderer to change the ambient light based on the map default, or a dynamic ambient lighting area, defined with rectangle objects in Tiled. This will allow me to alter the base lighting room by room, or area by area.

In the screen shot below, you can see the rectangles around the temporary dungeon demo areas and the island area.

That’s enough menus and UI work for me for a little bit..

I’m really happy with my skill tree, and skill inspector - especially since the skill definitions are nuanced and technical. I think the Animech level-up screens will change the most in the future, I have some ideas for additional stats to boost around damage.

But I think I’ve hit all of the upgrade screens I want to support for my first play-test demo. Something about them looking good - even for early testing - makes it feel nice to play.

I think next up, I’m going to tackle my dynamic entity scripting system. I’m going with goja and Typescript, at least, that’s the plan!

I thought I’d add a transition effect between menu screen - I tried to emulate older CRT screens, tube TVs changing the channel, and the classic pip boy. There are some mocing scan lines, vignetteing, “flashing”, pixel row dithering, and some other small thing. I like where I ended up, but I’m concern it’s too much? Is it distracting? Or “nice! keep it!”?

From working menus, to pretty menus 😎

A nice, animated, scrolly list for the creaures, and a fancy dynamic skill tree for the creature skills you can unlock. I spent way more time than I want to admit on this stuff… I also really like the simple threshold shader I applied to my normal sprites to align with the “lo-fi screen” aesthetic of this menu.

Working menus! Now you can…

• Upgrade your Animech’s Sync and Shield stats using experience
• Unlock skills from Primortals using research points

In addition to these game updates, I also spent a lot of time on hashing out my story, and the tutorial sequence. Next up, I want to add the ability to change load-outs, so you can choose which skills you have in combat.

I’m really pleased with this update. Now that I can battle and collect experience and research point, I need a way to spend those things to upgrade the player’s abilities. Since this game has some catch-em-all elements, I couldn’t help but emulate the Pokedex a little bit… Introducing the “Xenolog” - a little PDA that will show your current game progress; and while in HQ, be able to upgrade your player. I’m really happy with this little sub-device menu look and feel. Now I can start on the actual functionality of the menu…

Not a whole lot to show - I’ve mostly been working on refactoring and clean up. I’ve been refining my player load out design and “Primortal” archetypes. I originally wanted:

• A party system, where you would “load in” 1 of your 4-6 Primortals in your team
• Damage Types, Body Types, and Type Affinities with strengths and weaknesses amongst each other

Ultimately - it was too complex and not fun. I’ve decided to simplify it quite a bite. I went from 8 body types & 8 damage types, to 5 Primortal “Flavors”. Each flavor has general patterns for the types of skills they use an and how they behave in combat. But it’s not like rock, paper scissors - more like the colors in Magic the Gathering - it’s behavioral theming - no strict rules.

Instead of party members, defeating and optionally capturing Primortals reward you with research points to unlock the skills that creature uses. Before deploying on your next adventure, you can change your skill loadout with skills you’ve unlocked from all Primortals.

This shift has made it much easier to focus in on a tighter combat experience - focused more on building fun and interesting skill sets, and the puzzle solving of applying those skills in an efficient sequence to maximize outgoing damage and minimize incoming damage in real time - and less about swapping party members to play against type weaknesses.

I decided to focus on 5 core creatures to start - one for each type:

• Kinetic: focuses on direct hits and defending one-self
• Thermal: Sustained burning status damage
• Voltaic: Glass cannon, weak - but string hits
• Corrosive: Low passive damage + low damage small hits
• Mutagenic: Self healing while chipping away the opponent

Plus a 6th creature - a dummy robot to start building out the combat tutorial.

Small update to statuses - internally, they are tracked with “stacks”, but visually they are represented with level, 1-3. It simplifies the effects a bit. Burning now does more damage the more “exposure” the (longer, and strong the effect is) - Poisoning deals flat damage, but the higher the level, the slow the stacks decrease. I think it looks much cleaner

I also implemented “Interrupt”, which is when you get hit while in a vulnerable stance. It nullifies the remaining ticks in your current skill. I also want to add a skill that stuns a player after, essentially making them “sleep” for a few ticks after their current skill.

I feel like this is a bigger update than most. I mocked up the core game play loop I’m looking for: travel to a planet, battle mobs to get research points, then gather enough elythium to escape back. Once back at HQ, use your research points to upgrade your character. At first, to get to a rough demo to have people try it out and offer feedback on the general idea, I want to trade research points in for new combat skills.

Speaking of combat… I also added a status system! In this video, you can see burning and poison - a tad cliche, but easy examples to implement. I’m still feeling out how I want statuses to impact you exactly. I think burning will scale based on the number of applied stacks, poison will damage based on % of max health. I’m also considering adding exposed to increase incoming damage, stun to randomly prevent skills from triggering, and symbiotic which will cause you take damage if your opponent does. I guess there are tons more I want to try, but that’s too much for this post.

The last major combat mechanic I want to implement is “staggered” - a condition applied to opponent that forces a stance where they can’t make moves and are vulnerable to damage. Then I wan to work on the basic upgrade screen :)

Today: Mob Shadows..

I’ve been on the fence on how to handle combat encounters - Do monsters wonder around (expensive to animate/code)? Do I introduce tall grass a la Pokemon (limiting in different biomes)? Do certain zones just randomly trigger combat like FF (unpredictable and feels jarring)?

My current plan? Shadows! Here’s my first stab at a “Mob Shadow” that wanders around an area, but once you get close, speeds up and tracks towards you. If it comes in contact with you, combat is triggered! I like the idea of seeing the mobs and have control over the situation, as well as dodging if you wish.

Some pipe-dreams would be different shadow shapes/colors, footprints, sound effects, etc. to hint at what the mob might be. But for now - I think this is perfect for the initial game loop.

Introducing… Elythium! A mix of: “Elysium”, the ancient Greek mythological paradise/state of ideal happiness; and Lithium, the highly reactive and flammable element. On your adventures, you need to collect enough of this stuff to fuel the return flight home.

I’ve finally entered the phase of working towards an actual game loop - I finally feel like my combat and adventuring states are fleshed out enough to support it.

As part of this, I also spent a lot of time streamlining my sprite configurations - before I was mostly manually coding the frames and their timings - now I can just throw together some YAML next to the PNG and reference an animation name! These crystals subtly shift between different hues and sparkle!

This one will be hard to explain.. but this blog is for me in the end. I’ve added stances to the skill execution, represented by the black lines with an icon (shield = defending, !!! = vulnerable). Those stances will eventually impact how damage is calculated.

This adds a nice layer to the skill system where you need to time your skills’ stances with your opponents damage ticks (white dot with black border) to avoid taking extra damage or even reduce it.

Next steps will be to actually adjust damage calculation, not just render the stances. Then I want to add a stunned effect (getting hit while vulnerable) which will basically “parallelize” you for a few ticks (adding a dummy skill that does nothing). Then? Statuses! Always need burn…

Just showing off the tileset I’m working on - the initial part of the game, which will act as the tutorial, will be in a sci-fi lab of sorts, maybe in a large space ship, we’ll see…

I’ve never made my own assets before - and I’m very happy with how things are coming along. I’m definitely taking inspiration from other assets packs I’ve found online and trying to make it my own :)

Started work on my first art asset: a sci-fi space lab tilesheet! :) I love how the color bloom (LEDs) and lighting system already make it look so good.

In it’s current iteration, I’m still pulling a lot of inspiration from Cyber Monkey’s SciFi Spacial tilesheet, but I plan to adopt it more - changing the industrial striped tape out, and maybe going for a more black & white vibe and removing the greenish blue walls.

With shaders now working, I wanted to try out something funky. I really like playing my GBA games on emulators with simulated pixel grids - so I added a shader that adds scan lines, pixel grids, and sub pixel tinting. I want to add a settings menu to allow player to tune these or turn them off completely - maybe I’ll do that next :D

Here’s a zoomed in example without video compression of a white background:

Now, with shaders! I had to work on a custom pixel fork to allow me to bind samples to uniforms accessed by custom shaders. This let me implement “screen” and “overlay” compositions to build my light map. Lights are now an extension of entities and have their own update behaviors (such as flickering for a torch, or pulsing for the coin).

Time to make the game moody :) I was able to add some basic lighting. This is just the beginning. I still need to render the actual entities (animated torch sprites) that are emitting the lights, add light fluctuations/jitter, and more lighting variations, maybe let entities hold lights, consider supporting shadows… the list goes on…

Stairs! Doors! Every game needs you to enter and leave rooms!

This took a bit more than I expected - overall it touched my entity movement system, my tiled map loader, and I finally got to use my action queue system to handle the fading, player teleportation and camera adjustments.

Small iteration in the combat state. Health is now fluid - damage adjusts a target, but the actual health takes time to reach that target. This means the health bar updates smoothly and it technically allows you to recover from death. I want to add skills that change how quickly (or slowly) the effective health updates.

I also added a pending animation on the next skill, and some UI button hints for canceling the pending skill.

Next up, I want to show both the “target” and “current” health in the stats bar.

This update was a bit tedious, and less game focused - but hopefully it will let me iterate on my UIs quickly as I flesh out my combat state.

Text boxes are now fully configurable with width/height, render origin location, and vertical + horizontal alignment.

With those, plus the 9-box frames I added a while back, I created a generic collection of “badges” that can be used for small UI elements. In this example type badges, a la Pokemon - and button input tool tips!

I was struggling to find a 5px tall font I liked for some of my more detailed UI elements. So I made my own! It was way simpler than I expected thanks to the PixelForge tool I found. I love some of the more stylized letters, like A, C, G, O, P, S, and U (specifically the “lower” case letters).

This also opens up an awesome opportunity to create custom icons as part of the font that I can easily include in text :)

Sadly, it’s not easy to make special kern pairs (like for LT) with bitmap fonts. It kind of bugs me (look at ‘HEALTH’ above). But maybe some day I’ll circle back and see if I can make it work with glyph pair substitutes. It would require a much more feature rich tool to achieve.

I spent a lot of time recently on non-visual work recently, which is hard to demo.

I’ve revamped my asset & sprite atlas engine to allow states to filter/specify which assets they want to load into a shared sprite atlas. This shared atlas (a single giant image containing all the sprites I might want to draw) is used with a batch rendering engine to greatly reduce the amount of resources it takes to run the game. It’s currently sitting pretty at ~30MB of RAM. Most importantly, this work required me to fork the pixel v2 library to support this batching with the built-in text package.

After that, I did the work to render the opponent health in combat, and got rid of the debug text rendering. It looks much better now!

Next up, I want to continue to add UX features to combat to make it easier to see what’s happening (and what’s happened), and add the tempo counter.

This update is a mixed bag. I added the ability to render outlined text, shown in a text box here. I plan to use it in the combat state soon.

In the combat state, I added a skill selector component. I plan to add some iconography for buttons. I also want to highlight the active and queued up skill in some way. I rotated the active skill ticker, which visualizes what skills are currently being processed and stuck it in the middle. I plan to add a tempo counter that increases when you have a skill queued up when the current one ends, encouraging you to not “pause” combat.

My next goal will be to add the “combatant cards” with their names, and health bars, instead of the debug text I currently have rendered.

First, now you can run by holding down B :)

Second: Dashing (over gaps)! This is a mechanic I plan to have the player unlock down the road to make areas accessible that weren’t before.

The animation style isn’t my end goal, but was easy to make and fit well enough with my current stand-in tile sheets.

This video starts with me “showing off” my home-spun map editor. It did what I needed earlier on - had swap-able swatches, layer rendering controls, copy/paste abilities, entity property management, and more. Then, it shows me opening the same map in TIled, changing the position of some entities, and finally walking around in the edited map.

When I first started this project, my instinct was to use Tiled to map editing. But I really didn’t enjoy the libraries available, so I developed my own internal data format for maps, and also wrote my own map editor. That was fun, but ultimately stupid.

I still like the map data format I landed on, it integrates nicely with my rendering engine. But I finally bit the bullet and wrote a converter that can parse a Tiled map and convert it to my internal format. Now I can stop worrying about implementing quality-of-life improvements for my bespoke map editor, and instead focus on building the game itself…

PS: I also bought @snowhex’s tileset to use as a placeholder for my sprites - letting me focus on implementing the game engine instead of attempting to draw decent looking pixelart.

The first stab at combat. Player skills are on the bottom, opponent skills on on top. Each skill lasts a number of “ticks” - each tick can do something. Currently, the white dots are damage ticks, the black ticks are idle time. The color corresponds to the skill type.