This year, I’m finally starting the RPG project that’s been sitting in my brain for close to a decade. Over the past 3 months I’ve made some good progress on the base engine and gameplay code, so this week I put together a demo video to show off where I’m at:

The stuff in the demo is just placeholders right now, but I think it does a good job at highlighting what’s already possible. This is going to be a long road, and I’ll try to share more screenshots, videos, and design notes periodically as the production process continues!

If you’re a fan of retro JRPGs, don’t miss this one :)

May’s just about over, so it’s time for another update. Like April, this was another month of laying foundations. But unlike April, I have a little bit more to show this time.

Game Flow

One slightly boring but very important addition is all of the scaffolding needed for the main menu. This includes letting the game track and adjust its state, which means that getting a ‘game over’ can actually take the user back to the menu to try again (or load a save, once I have those)… before then, losing would simply close the game!

Sprites and better Movement

A more interesting addition is sprite animations. I added a basic animation system that makes it very simple to animate existing elements in the game. It’s not applied everywhere yet (there’s no combat animations yet, for instance), but walking around is a lot nicer now that you can actually see characters walk. Even with placeholder sprites, it definitely adds something:

Another detail you may or may not have noticed, movement is a lot smoother than it was in my first demo. I reworked the movement and collision code a bit to allow sliding off solid surfaces instead of just stopping, and that makes the controls feel a lot better!

Cutscene Scripting

One last important addition to the code is a system for cutscenes! This is definitely needed for an RPG like this, and the new system is pretty nice. By giving it a relatively simple script like this:

context:show_dialogue("course/entry.lua")
local player = context:get_player()
context:fade_out(0.2):await(false)
context:move_to(player, 1, 0, true)
context:change_map("course.lua", 10, 29)

local npc = context:get_actor("dude")
context:fade_in(0.2):await(false)
context:move_to(player, 0, -1, true)
context:show_dialogue("course/welcome_sign.lua")
context:move_to(npc, 1, 0, true)
context:wait(0.20)
context:turn_towards(npc, 180)

…we get a cutscene:

That’s all for this month! Things are really starting to come together on the tech side, I don’t think it’ll be too much longer before I can start on real game content instead of test data and placeholders.

It’s been about a month, so I think it’s time for another update! Unfortunately I didn’t get as much done as I wanted this month, because I developed carpal tunnel syndrome early on and went on hiatus for few weeks in order to recover. I’m starting to feel better so development has resumed at a very slow pace, but obviously I didn’t finish everything I was planning on. For now I’m just taking my time, better to work slowly for a while than to jump back in and have to stop entirely.

However, before all that happened I did get some things done. let’s take a look!

A Big AI Revamp

In the original demo video at this start of this thread, the enemies don’t have AI so much as a list of moves that they randomly select from. That may be enough for a very simple encounters, but for boss fights and more complex enemies there needs to be something more complex. So, I added 3 new features to accommodate that:

Behavior Trees

The first thing I added was a simple behavior tree system. It supports a small set of useful patterns, like conditional branches and performing actions in sequence over the course of multiple turns. I don’t want to load this post with too many details, so instead here are a few examples showcasing the kind of flexibility I have:

Attack pattern: Alternate between attacking and using a random special attack

ai.sequence {
    "fight.lua",
    ai.shuffle {
        "special_attack_1.lua",
        "special_attack_2.lua",
    },
}

Attack pattern: Perform special attacks in order, randomly interspersing the pattern with regular attacks

ai.shuffle {
    "fight.lua",
    ai.sequence {
        "special_attack_1.lua",
        "special_attack_2.lua",
    },
}

Attack pattern: Randomly select a regular or special attack. When health gets low, change to a different special attack

ai.shuffle {
    "fight.lua",
    ai.condition (low_hp,
        "special_attack_1.lua",
        "special_attack_2.lua",
    ),
}

This is a good start, but what if we want monsters to use attacks in response to what the player’s doing?

Reactions

Reactions are special behavior trees that sit separate from the monster’s main AI. These allow the monster to immediately respond when a hit with an attack or when the monster dies. It’s not uncommon to have counters and revenge moves in turn-based games, so I felt it would be useful to make the system available to any actor in a fight. In theory this can also work for party members, though right now it’s only being used for monsters.

Unlike regular moves, reactions are called immediately after the attack resolves and any attack that comes from them takes priority over anything that was already queued. They also only trigger if the original attack that caused them wasn’t a reaction… mostly to avoid the possibility of two actors reacting to each other forever.

Anyway, these are nice but you don’t usually want them all the time… Usually you want counters to come with characters changing their stance or form to indicate that attacking is a bad idea. This could be accomplished using status effects, but I elected not to do that because it could be a mess to manage. I also could’ve used the old-school RPG trick of replacing a character with a different one and copying over certain stats, but historically that trick has caused a lot of bugs in various games. So insteaaaad…

States

…I added states. States are very simple, they’re basically a set of overrides for character properties like their appearance, stats, AI, etc. When a state change is triggered, the actor refreshes its properties and takes any values in the state over those in the base stat-block. That way, the monster stays the same and only replaces the values that need to change. It also means that if I add new features to monsters, states can automatically take advantage of them.

With all that in place, I’m able to produce some fairly complex interactions and strategies for the AI. Nothing on the level of what you’d need to mimic a human opponent, but enough to present interesting and unique challenges to the player. And that’s exactly what I want!

The New FX System

One more thing that I started prior to my health issues was an FX system for the game. I want to accomplish more than what simple pre-rendered effects can give me, so I set up a more concrete system with various forms of animation, tweens, and particle effects. In the long term I also want the ability to assign customs shaders to parts of effects and fullscreen post-processing as well, but I’m not there yet!

Right now I’m only using the initial version of the system for attacks attack animations in combat, but eventually I’ll be using it on the map in cutscenes and pretty much anywhere I need it. I also want to add a way to integrate existing values and objects in a scene into FX to allow for things like a projectile that moves from one object to another, or a particle effect that accompanies a certain sprite animation. I also really need to make some kind of editor for these, as the animation data can get really complex and verbose. But again, health issues… we’ll get there eventually.

Putting it Together

To demonstrate of what I discussed above, here’s a little video:

This is the same mimic fight from the first post, but with AI adjustments and combat effects. It plays out a little bit like a typical 1st boss of a Final Fantasy game–it sometimes closes its box, and counters with a powerful attack if disturbed. You can also see a status effect in this video, poison. I don’t remember if I mentioned adding support for those in the past, but they exist.

I’m back, and this time I have some good news! I’ve decided that the base engine is in a “good enough” state to start work on real game content, so I’ve begun the development of my vertical slice demo. As a reminder, my goal for this demo is to produce 1 dungeon from the game at a close-to-final level of quality.

I’m still early in the production process, so I think I’ll hold off another month before giving a deeper explanation. But I can show one of the dungeon’s core mechanics: Water levels. Take a look!

By moving water between different basins, you’ll be able to open and close off various paths. I think it’s a pretty neat mechanic, though I’ll have to be careful about giving the player a better sense of depth. This will probably come down to a combination of level design and giving floating objects a drop shadow to indicate their real position.

To make up for the lack of detailed dungeon talk today, here’s one last treat. The first piece of concept art for this dungeon:

That little critter is one of several enemies you’ll find in here. Keeping with the theme of water, most of the monsters in this dungeon are forms of marine life. We’ll be seeing more of them as the demo’s development progresses.

Great progress so far.  Looking forward to seeing more.

Sometimes as a developer you want to carefully control how your game is viewed by the public, polishing every video and shooting multiple takes to avoid known bugs. But everyone loves a funny bug video, and this is a funny bug video:

Good luck with development!