LÖVE

This is really cool! And I had a similar realization when I was working on my very simple (old school, Dragon Quest 1 style) JRPG called Catacomb Kitties- I can run test scripts on combat in the command line to improve the speed of development. I also realized I could create a simple scripting system for doing the combat animations and spell effects (damage/etc) by using a table of commands. It ended up working really well, and I tested it first on the command line, and then put it into my game engine.

Lua is really handy like that. (I also did that with Bad Writer, too. I tested the game mechanics separately from the game itself, with scripting on the command line)

Lua has been versatile and pretty intuatitive for me as well...and I'm terrible at computer logic and coding. What makes Lua so much fun is that the table structure is relatively easy to organize and reference. As for damage/stat algorithms and so on...whew, math is hard. I commend you for sticking to it, because I'd probably just rip off Zelda's "heart" system or something and call it a day. It's great to see that you are hanging in there with this, I really want to see more of it. And I know that the graphics are just a place-holder...but I keep wondering if maybe "Legs" actually has an entire back story. Perhaps his job is to stand in for future sprites the way a stunt man would for a movie star, and he (or she?) has a whole family of abstract shapes in a city that's comprised entirely of ascii symbols, with each district being a seperate text file...Anyway, stay healthy, keep up the good work, and please post some more previews of your progress when you get the chance.

Thank you for the kind words! People really like the legs-man, I've had folks in other places make jokes about him... I may have to leave a copy of him in a dev room or something

I must admit I haven't made much progress lately though, as my health improves further I finally have to catch up on the things that I've been putting off for 9 months... hopefully the bulk of that will be done before the end of the month though, and then I can focus back on the game.

It’s been awhile since I did one of these, as you might guess from the intervening posts a lot of other things have been keeping me busy as my wrists continue to heal.

Regardless of that, I have been making progress on the game. Let’s take a look!
(Apologies in advance, this one's just a big wall of text)

Combat Moves Along
Most of the past months have been spent on the game’s formulas. Technically speaking, I’m not completely done with that yet! However, I’ve reached a point where I can move to the next step: Testing and prototyping the ‘final’ combat mechanics directly.

I’m too early in that process to share any screenshots or dive too deep into it this time. Instead, let’s look at some of the game’s planned weapon types. Working out the relationships between different weapons, stats, and classes was a big part of the formula work, so while I can’t guarantee this information reflects what the final game will be like I think it’ll be pretty close.

There are currently nine major weapon types, but today we’ll look at six of them.

But First, Some Background
Even if the combat is still being prototyped, I do have to discuss where it’s going just a little bit in order for the weapons talk to actually be useful. This isn’t really a deep dive, just enough to introduce a couple relevant mechanics.

As I’ve mentioned before, one of my main inspirations for the game is Final Fantasy V. That doesn’t mean I’m recreating the game’s mechanics exactly, but some of them will invariably end up in here. Of particular relevance to the weapon types:

• Since this game uses something like ATB, different weapons/moves/etc can have action economy considerations–a weapon that does 100 damage once a second and a weapon that does 200 damage once every 2 seconds are not necessarily the same.
• In combat, units are divided into rows: The front row is ‘normal’, but the back row takes and deals half damage in melee. This game diverges a little bit from FFV here: I’m currently prototyping a third row, that I’m internally calling ‘overextended’, which takes and deals double damage, for more aggressive plays (and any build that can creatively redirect damage away from that row).

There are also some larger departures from the formula:

• Some enemies have tags that dramatically impact the damage they take from certain types of attacks. Most notably here, the term armored refers to enemies that largely shrug off physical damage, cutting it by 90% in current builds of the game.
• On the other hand, the game also has an additional system to boost damage output: combos. The attack formulas take some cues from older FFs with attacks producing not just raw damage but the number of successful hits as well. These accumulate into a combo meter that adds a small amount of defense-piercing chip damage onto regular attacks, and are consumed when using attacks tagged with finisher for a dramatic damage boost. This often means attack spells, but there will be some jobs with melee outlets for the meter as well.

The idea behind the combo system is to represent pressure. Throwing a lot of attacks at enemies, even if the attacks are weak, still has an overwhelming effect that leaves them more vulnerable when the real damage comes out. This is not too far off from FF13’s stagger mechanic, but I wanted something more free-form that was powerful but not strictly necessary–for a game that wants to support many builds and strategies, I think that’s the direction most mechanics should go. Another key difference is that the meter builds up for the party landing the hits, not the target. This means that you can use one easy-to-hit target for combo building, then redirect the finisher into a higher-priority target. Another difference is that the enemies will use this on you too

But of course, this is all still being worked on. Some of it may change as testing continues, this is just the current state of the design.

Now we can talk about weapons.

Light Blades
We start our tour with the Mario of the group. Light Blades are not necessarily blades, but the category represents relatively ‘standard’ 1-handed weapons such as swords. Their damage is fine, they can land a few hits per attack, and that’s basically it.

Heavy Blades
If we have light blades, then surely there must be heavy blades too! These fill a similar role as axes and hammers in FFV, a much more damaging alternative that comes with the downside of being slower and noticeably less accurate. These weapons do a poor job of contributing to combos, but they should serve as an excellent source of finishers since most melee finishers will come in the form of activated skills that might not necessarily use their weapon’s accuracy but will use their damage values. Having a much larger base stat line to multiply, especially if you can keep the user way out in the front for a second multiplier to stack, will hopefully give these a good tactical niche.

Polearms
For a different kind of build, there are also polearms. These are similar to swords in terms of stats, but trade a little bit of damage for the benefit of Ignoring the row system entirely–you can hit a back row enemy, from your back row, with no penalties! On the other hand, you also can’t put a unit with a polearm up front for more damage.

Knives
Now we’re getting into the less directly effective weapon types. Knives have low damage and hit-count, but make up for that with the ability to pierce an enemy’s defense. This means that while other weapons struggle to put a dent in an armored opponent’s health, knives & daggers will cut right into them just fine. The in-universe explanation is simple: if you’re close enough to stab a dude, you’re probably close enough to aim for the gaps in their armor. With a slower and heavier weapon, getting that kind of precise hit may be much harder.

Staffs
Staffs are an abysmal way to deal melee damage. Which makes sense, if I had to pick between a really nice stick and a large metal blade, I think I’d pick the latter. But that’s fine, because staffs have another important function–boosting the output of magic. Giving a staff to a caster is effectively going all in on their spells, at the cost of giving them a viable melee option.

Between staffs, there may also be some trade-offs to make between higher magic stats and secondary effects. The main melee ‘function’ of a staff is not to deal damage, but to do something else–applying a debuff, healing an ally by bonking them over the head, stealing a small amount of mp to keep your wizard topped off… Basically, you get to pick between raw stats and having access to a cantrip.

Fists
And lastly, we have the all-natural weapon known as punching a guy in the face. Like staffs, unarmed combat is not terribly effective for doing damage. However, as you may have guessed it’s fantastic for building combos. Unarmed fighters tend to act quickly and hit a lot of times–2-3x more than standard weapons. They also have much higher damage growth off of chip damage, if you don’t have a source of finishers your team’s martial artist will start growing very quickly. This also offers another option for casters, since you don’t need raw strength to contribute to a combo. Having a healer spend their off turns boosting their peers’ next spell could potentially be a better option than taking a mediocre swing with a better weapon or sitting idle.

What Am I Up To Now?
Alongside the combat system prototyping, I’ve finally returned to the demo proper. I started working on building the enemies (and the boss) for the dungeon from last year, and hopefully as I get deeper into this process I’ll be able to start doing some internal playtesting with folks I know, rather than just testing everything myself.

Another promising development is that I’m finally well enough to paint with my tablet again. I haven’t put any of that newfound energy in the game’s direction yet, but hopefully this will lead to more concept art this summer, and with it another step on path to some real in-game assets.

Summer's almost over, and with probably a sizable portion of my productivity. Since I haven't fully recovered yet, the cold months will probably cut my ability to work down like they did last year. Nevertheless, I have some plans to stay productive thanks to last year's experience. We'll see how that goes!

The main focus of my work was, as I mentioned last time, implementing a more final version of the combat system. Some of this is the mechanics I've explained already, but I also added a few more things.

First off, it turns out that fleeing just...didn't exist at all. I need to spend more time testing the new implementation, but the way it works is pretty straightforward:

1. The player holds down a dedicated button
2. While a character's turn is up, they attempt to flee. Rather than rolling random values, they instead idle while contributing to a 'flee meter'. How long the meter is will probably depend on the encounter.
3. Once the meter fills all the way, you escape!

I like this concept in general, because it avoids the question of "can I actually escape?" by offering visual feedback (once the visuals are in) on both if and when you'll do so. It also creates a small extra strategic layer: You don't have to flee with your entire party, you can sacrifice escape speed in order to have some characters handle healing and defense while others try to run. I don't know if this will be a meaningful decision in the final game or not, that's one of those things I'll have to test for sure.

I also spent a lot of time thinking about...

ATB
Aside from a casual mention, my use of mechanics similar to the Final Fantasy ATB (Active Time Battle) system hasn't really gotten much talk thus far. Over the past few months, a streamer I follow has been plowing through the Final Fantasy series--and obviously, I'm taking this as a golden opportunity for 'research'. He talks a fair bit about the mechanics he does and doesn't like in the games, and one thing that comes up sometimes is his dislike for ATB in most games. As someone who enjoys it, hearing contrary opinions is awesome because it's forcing me to consider why I like it and what parts I could improve on in my own game.

---

Lets dig into some pros and cons. The biggest complaint I've heard is that in many games, ATB winds up being largely pointless. Characters still essentially take turns, just on a delay, and the timing aspects rarely come up because so many of the mechanics are tied to turn-based gameplay. There is a more timing-y way to play, the so-called "active mode" where time doesn't pause in menus, but it also imposes a sort of 'menuing tax'. If you memorize where every option is and are good at mashing out the inputs, you get a noticeable turn economy advantage vs the player who doesn't. This also doubles as a disability tax--your turn-based-ish game is now tangibly harder for people with poor memory or difficulty making rapid inputs!

I find it hard to dispute those points, so why do I like ATB (and active mode in particular)? The answer is stress.

When you play a typical turn-based game, there's no pressure to make your move. You can spend minutes plotting out the strategy for a turn, go back and change your mind multiple times, and explore every possible option before committing to the perfect turn. I think that's a little bit boring, and it also puts the designer in an awkward place--the only way to offer a real challenge is to either make the enemy is so overwhelmingly big or so complex that the player has to really stop and ponder their moves. This often fails leading to the player just repeating the same actions over and over, and when it succeeds it leads to very tightly-tuned fights that are fun but probably too much for more casual players.

In other words, it's hard to make a turn-based RPG that's both engaging and easy to get into without resorting to input gimmicks (like the action commands of Paper Mario) or a more complex strategy layer (as you see in the 'SRPG' genre and the modern rash of deckbuilders).

This brings us back to ATB. I think ATB resolves this issue brilliantly by not giving the player time to think deeply about their decisions. They have some time but not enough to play perfectly, and all the while there's the threat of enemies taking extra turns to spur a quick decision. With quick and imperfect decisions comes mistakes, forcing the player to improvise on the fly to claw the fight back into a state of equilibrium. In my opinion, it brings an aspect of suspense that's often lacking in the genre. Which me to the question:

Is it possible to maintain that feeling without introducing the problems? I'm still actively working on this one, but I think the answer is yes.

Speed-Chess Combat
My first attempt at revising the combat was to take inspiration from speed-chess (and to a lesser extent, the turn timers used in online card games like Magic). Rather than letting time constantly pass, the fight briefly pauses (3-5 seconds in my test builds) when a character's turn comes up to let the player input a command. Combat resumes when the timer runs out, regardless of whether the player has finished or not, but the character's turn doesn't end either. In practice, this means that simple commands that only take a few seconds to input are never penalized, but you're still pressured to make fast decisions. A system like this would also be better for accessibility, since the timer could be cranked up as needed or even made indefinite until the user chooses to end it.

...this didn't really pan out. The biggest issue came from 'close races', where two characters' turns came up around the same time. I would regularly wind up in situations where a character I wanted to command was about to move, but another character's turn came up first--forcing me to resume time and switch...which immediately re-pauses time. It feels extremely jarring in practice, but without a better option I kept it for a pretty long time while testing.

Refunds
My next (and recent) crack at this problem was a little more complicated. Rather than stopping time altogether, I had the idea to slow the combat speed while in menus and refund some of the lost time after a character's action is selected. This approach isn't as robust since enemies can still take their turns from the moment your turn starts, but I thought it could serve as a less intrusive way to reduce the penalty of menu navigation while still solving the 'close race' problem. I'm still deciding how I like this approach, I suspect it'll take a few more iterations to get the flow of combat right.

Some Good News
I also did a design pass on all of the enemies in the demo dungeon, including the boss! At this stage, I'd say half of the enemies are 'done' on a mechanical level, and the rest are at least present in-game with some portion of their stats and mechanics in place. I was really hoping to have the whole thing done before this update (hence how long I held off from posting), but after 7 months I'm finally starting to lose steam on the combat train. I've decided it's better to switch gears for now than to push myself to the point of burnout, but I'm still very happy with my progress. We started the year with almost nothing, and now most of the basic mechanics are in alongside a bunch of monsters and skills!

And Now, Art
Another small milestone: I didn't just do a design pass on monster mechanics... I drew some more concept pieces too! Here's a lil collage with all of them:



As you can see, there's a lot of stylistic drift happening. It's to be expected, I've been doing pixel art for a pretty long time now but digital painting a skill that I'm still developing. I'm not entirely happy with these as a unit, but they've helped me think about the creatures and their vibe. It's much harder to figure out appearances without sitting down to actually draw for a while, and even if I'm not well enough to iterate properly this is still a step in the right direction. With these I'm finally able to think about design and art styles a little more clearly!

Speaking of things that I'm not entirely happy with, I also took a first crack at the dungeon itself:



It's too 'generic sewer level'. That's not the vibe I'm going for, so I've gotta brainstorm how I really want things to look and try some more ideas out.

As you can see, it was a productive--if not fruitful--couple of months on the art front! I'm not sure if I can keep it up once winter hits, but I'll try to do a little here and there.



Anyway, I think that's enough for one devlog. I've actually done a bit more than the above, but we're running long and I'd like to get back to working on the game itself!

With my decision to switch off of combat for a while, it may be a bit of a grab-bag for a while. My first order of business is improving the project structure. I'd like to be a little more open with my code, but at the same time I don't want spoilers running out in the wild. To that end, I'm planning to isolate the 'engine' and 'game' parts to some extent. Hopefully that doesn't take too long!

The art style is interesting...kind of a vibrant, digital oil painting vibe. I like it.

There are so many options and methods for turn-based combat that it may be difficult to settle on just one.

The main issue is that you can never really predict the behavior or temperament of the player...so, if possible, you may want to offer an option for whether or not the flow of combat is "active" or "waits" (or something in-between, like the developers of Chrono Trigger implemented.)

It's good that you've made as much progress as you have. Admittedly, real life has all but halted any motivation I've had for my own project as of late...although, now I'm really leaning towards a classic side-scroller, just to get my feet wet in game creation. Something along the lines of a "metroidvania"...but, who knows.

Hope you are feeling better these days. As far as anything looking "generic"...I'd say you should decide on a more concrete "theme" overall (if you haven't already)...such as a typical "high" fantasy, or something darker/grittier, or perhaps more "steam punk-ish"...there are any number of possibilities. That said, maybe you could spice up the usual locales (including the compulsory "sewer level" found in just about every rpg in existence) with more creative or unexpected elements (such as a few mobster alligators playing a game of cards, etc.)

Anyhow, good luck. I'm looking forward to future updates of the soon to be epic Untitled Rpg Project . Stay healthy.

Thank you for the feedback! Things have actually been going much better than expected this fall, I've just been...not writing update posts

I'll try to throw together one more progress update sometime before the end of the year, since I really ought to at this point... but for now it suffices to say that I've been very busy working on stuff that's important but not too impressive to look at. If this were a professional project we'd still be in a pretty early stage of pre-production, so now is probably the right time to be making boring investments for the future as long as I can retain my interest in the project itself (so far, not an issue thankfully).

The combat will definitely have some settings for adjusting how the timing and such works, in fact it already does (just in code, it's not exposed in UI anywhere rn). I intend to let the player tweak a lot of the game's dials if they want to customize their experience, but I also want the 'default' to feel as good as possible so that's where a lot of my indecision comes in

I'm even considering letting the player go as far as turning combat off entirely if they're just playing for the story, though that's less of a concrete plan and more of a wishlist item--it might not actually happen.

As for the look, I agree. The core issue is a lack of clear direction, and a lot of that stems from not being to iterate and experiment much with ideas due to my health (during the summer I was still unable to draw for more than ~45-90min sessions and even these had to be spaced out over days). I have some plans to deal with that, but for now I've refocused on programming for a while. I have a pretty clear idea of the what themes and world are like and I think they're fairly well put-together--I just need to figure out how best to express them through the visuals, and the only way to do that is by taking the time to try stuff out.

I've been putting off this post for too long, but I haven't been resting idle either. On the contrary, I've been very busy hatching a plan, and I just didn't feel like I had a good opportunity to post any updates throughout that process. So today, allow me to weave you a tale about what I've been up to these past four months...

Tired-map Editor
Back in the summer of 2022, when I was actively doing level design work, I very quickly realized one thing: Tiled does not work well for producing this game's maps. This is mainly due to their somewhat unique structure, which allows me to render a visually 2D world that nevertheless contains 3D data--treating tilemaps as a sort of quasi-voxel structure where each layer represents a slice of the world. This is very effective for gameplay purposes, but I quickly discovered that Tiled's existing auto-tiling tools were woefully inadequate for this purpose. In the end, I found myself having to hand-place every tile variation...if you've ever done that, you know it really sucks.

Not content with such a fate, I started to shop around a bit. Sadly, there really isn't much established competition. I spent a few days digging through the level editors I could find, but most didn't even meet tiled's more basic features--and those that did didn't meet the features my game needed either. So I gave up! I have a history of projects dying from over-emphasis on tools dev, and as a professional tools programmer I know exactly how much work goes into a professional-quality level editor. Thus, I decided to hold off and just deal with the painful workflow for the time being.

Fast-forward a year or so, my health had taken a real turn for the worse and I was in the middle of a long and difficult recovery. In my efforts to continue supporting my hobbies, I'd spent the past 9 months or so assembling a rough voice-based art workflow using a significant amount of custom tech. Not knowing exactly how long recovery might take, I started thinking about doing the same for level design--building tools that not only improved my workflow, but could also provide a degree of accessibility that would enable me to work on the game no matter how things shook out.

A Slight Roadblock
This plan was all well and good, but there was a small problem... unlike my art tooling, this theoretical tilemap editor would need a hybrid interface. The reality of voice operation is that it's far slower and less natural than just using your hands--it's a fine fallback, but a poor default. That means the editor would also need a more traditional UI for times when my health was good and, well, my UI code up to this point has been a semi-hardcoded mess. It didn't need to be anything more up until that point!

And that's how I spent 3 months building a ui framework flexible enough to support both an editor interface and the game itself. And recreating the game's UI in it. Aaaaaand polishing that a little, because when you're this deep in the sauce why not go a little overboard just for good measure? It also served as a fine excuse for all the time spent--at the end of the day, even without an editor I could at least point at the incremental in-game progress:

I stopped short of putting in the effort to make a good ui, since I had other plans, but things are nevertheless a little better

Organization
It is at this point, in early November, that I remembered my original plan laid out in my last devlog. I was supposed to fix the project structure, wasn't I? I'd completely derailed things! It seemed foolish to try and fit in a brand-new map editor while planning to refactor the codebase, so I took a second detour and spent a couple weeks separating and re-organizing the code. In the end, I wound up with a structure that looks like this:



At the bottom, we have 'Hovel'. All of the code under that umbrella is kept completely separate from the game itself, and was split into a bunch of small generic libraries in their own git repositories. You could think of this as the beginnings of a more general framework, though I have no particular interest in actually following through--it's just more convenient to reuse this code if it's managed and developed separately. Anyway, everything moved to this level was deemed 'not specific to RPGs'.

The next level up, 'Core', is where all of the generic RPG-related code lives. In theory this could grow into a reusable RPG engine, but that's not really my main goal here. I've created a separation since it would be much harder to do so in the future, but I'm primarily here to make a game and I'm being very careful not to let that goal out of my sights.

On top is the game-specific code. Figuring out where exactly to draw that line was challenging, and I may wind up revisiting some of those decisions later. Anyway, this is mostly stuff like mechanics, UI code, game states, and hookups for things like asset loaders. There's nothing that would really spoil the game, so most likely this layer will be developed in the open as well. After that, there's the entry point for the game and....

The Editor
Now we can finally talk about the editor, or at least what's been done in the 2 weeks(!) remaining in the timeline. There was a part of my saying "Weeeeell, maybe you should wait until you've finished this too", but 4 months is a pretty long time to maintain radio silence--it was time to get back into the routine of writing updates.

Before I can truly call the restructuring finished, I need to figure out what to do with one last component--my auto-export tool for tiled. Knowing that I was on the cusp of writing a tool that would replace it altogether, I decided not to separate it from the project. Instead, I'm just going to delete it once the map editor is ready and delay the final repo setup steps until then.

On the editor front, I've got a pretty good foothold so far. If you refer back to the diagram up top, you'll notice that the 'Dev' layer is positioned above main.lua, but is actually referenced by main.lua. The reason for this is because it's essentially a hijacker: main.lua looks for a corresponding file in the dev layer, which wraps all of Love's previously-set callbacks with its own. This allows it to intercept all input and output, as well as control the flow of the game's code, while still being trivial to separate from it. If you remove the dev folder, the game simply runs as if it never existed. But when its present, the game runs inside of an integrated set of asset editing and debugging tools that have full control over it. It's a simple approach, but it works well. On top of that setup it's possible to build any number of tools, such as my WIP map editor.

As for that map editor, even two weeks in things are already going quite well! I'm focused 100% on producing the minimum set of tools needed to efficiently build maps, which means foregoing a lot of cool toys and polish but also leads to very fast results. I have a reasonably effective prototype for my 3D autotiles that already feels much faster to work with than any other workflow I've tried for this game:



The tile editing part is pretty close to 'good enough' already, so I'm now shifting my focus to actor and trigger zone placement. I suspect these will take a while longer as they're more complex, but at the rate things are moving I expect to be done and back to working on the game itself in a couple of months.

But that's it for now! It's been a slow couple of years starting this thing up, but I'm working on getting some more permanent solutions to my health situation in early 2024. This will introduce some breaks, but if all goes well it will result in speeding up development to a notable degree and making it more reliable in the medium to long-term. Stay tuned!

Thanks for the update! Sorry things have been crappy health-wise, but I'm awed and impressed with your persistence and the ways you've worked around everything! I've loved watching the development so far. Keep up the awesome!

It's fantastic that you are still working on this, in spite of setbacks. Real life and general lack of motivation have been getting in the way of my own project (which I'm still not fully decided on.)

I started making a "map editor" at one point in hopes of streamlining/automating the process as much as possible, but then realized that I could design areas/levels just as fast in an image editor using a few layers and a grid with marked coordinants, and then code all the actual data later.

I truly hope that your health improves, and that you can get all that tedious "technical" stuff out of the way so you can start on the more fun aspects of your game (whatever those may be.) Take care, and looking forward to seeing your progress in the new year.