namida's new RPG project

[namida]

(EDIT: I have closed this topic as this project ended up going nowhere. It's very likely I'll pick up the general "make a good RPG" goal again at some point, though. But I think a big part of this is I need to re-think how I approach the project overall.)

So, you all have seen (and if you're interested, most likely played) my RPG Maker VX Ace project, Legends of an Otherworld. As a quick recap, I started developing that game in 2011, completed about 60% of it, then it sat abandoned for years until I resumed work on it in 2017, ultimately releasing the first "complete" version near the end of 2017, with the last bugfix update bang-on new years' day 2018.

During the time the original project sat abandoned, as well as after its completion, I've spoken of making a remake of it in either a custom engine or the newer (and cross-platform) RPG Maker MV. On one occasion, I actually made enough progress on a remake engine that I had some screenshots to show off, but I eventually ended up getting frustrated with and abandoning this attempt for two reasons - firstly, that I was being way too ambitious in regards to how the engine worked, and secondly, that I was putting too high a standard on the placeholder graphics. This particular attempt was using Lazarus + FreePascal, together with the cross-platform GL-based Castle Game Engine library (which on a side note, seems like an excellent library for anyone wanting to do game design using Pascal - from what I could see, no other Pascal-based engine even came close).

Then, recently, I started to learn MonoGame and C#, and have put this new learning (which is still ongoing - I'm often finding better ways to do stuff and thus reworking older code to use it, for example, I only recently replaced a whole bunch of complex code with much simpler code using the Linq library) towards yet another remake attempt. Or at least, that's how it started off.

With this one, I deliberately put some limits on myself regarding graphics - any graphics I design, I must limit myself (except where there's specifically technical reasons not to - so far, the only case of this is the font) to a 16-color palette (the "16 colors" here does not include "transparent", so it's 17 if you include that). I've also made literal placeholders for cases where I haven't even made these graphics yet - so you might see in some WIP screenshots / videos that some NPCs, enemies or battle animations just show a graphic that says "Placeholder", or a blacked-out sprite resembling a human shape in the case of NPCs. I've also toned back the ambition a bit - while the battle system is still very complex, stuff outside of battles is not so fancy.

In what should have been completely predictable for me, knowing myself, the "Lemmings Plus DOS Project" effect quickly surfaced - you may remember that LPDOS (now known as Lemmings Plus I) started off as an effort to remake many of my Cheapo levels in the DOS game (or technically, rather, Lemmix), but I quickly ended up feeling more like making original content rather than remakes. Well, the same has more or less happened here - I've felt more like creating an entirely new game, rather than an improved remake of my original one.

So, what does that mean this project will be? It's going to be a new game, but in a sense, also a spiritual successor to my first one. While the gameplay will be fairly similar (of course, there will be many entirely new boss designs - though some general concepts will likely be reused, if maybe not exactly the same specific enemies), the setting, characters, story, etc will be completely new. At this stage, I'm not ready to reveal details about this beyond what's seen in preview content, but I'll say more in time.


(This is the original post where I split the topic off.

So, regarding the "remake" - I realised that I was being far too ambitious with it, especially with regards to having the pixel-perfect map movement combined with my somewhat limited graphical abilities, so I figured I was better off ditching much of this.

Another thing I've realised is that using an obscure framework like Pascal + CGE could come back to bite me later, so I've decided to start again (and indeed, I've made some good progress already) using something a bit more mainstream - specifically, MonoGame. While doing so, I'm of course taking into account things I learnt from previous test code - especially what things I was doing that might be complicating things more than necessary. (MonoGame also does a little bit better in regards to cross-platform. In particular, should I actually get this finished, MonoGame offers the possibility of publishing the game to console rather than just PC and smartphones.)

The new codebase, while not having all the behind-the-scenes stuff (support for attack data, enemy data, etc) that the old codebase had so far, already has some more-prominent features the old one never got around to, like warp points between maps (or within the same map). Probably because no more unnessecary fancy stuff this time - only putting in what's actually needed to make the game work; it doesn't have to be overly fancy.

As I do more of the planning (and coding, to some extent), I'm also getting more sure of my decision that this won't be a direct-but-improved remake, but more likely just an RPG with similar gameplay mechanics, perhaps re-using some ideas from this one (especially with regard to boss attack patterns / etc). I don't plan for the battle system (even outside of specific formulas) to be a one-to-one copy either; though it will be very similar. (One of the notable changes is that I intend to implement some form of summons, most likely an FF8 / FFX hybrid system.)

[namida]

A screenshot of the battle system in the MonoGame-based code.

It's not very functional yet, it pretty much just displays the battlers, HP / MP gauges and the upcoming turn order (which quite clearly needs reconsideration of where / how it's displayed, but the important thing is that it works).

For reference - this would be the initial turn order at the start of a battle. Red Girl has 100 Agility (I'm going to be setting the cap at 100 rather than 255 this time around, 100 is a nicer number and I also plan for the stat-increase system to be more fine-controllable by the player instead of abstracted into "levels", which means a high cap might get annoying), Blue Girl has 0 Agility, the swan has 50 Agility. I like this ratio - high agility does have a clear advantage, but not to the extent that low agility never gets turns whatsoever. Also, the first turn comes a bit quicker than the gap between turns, which means low-agility battlers also aren't waiting forever for their first turn (but the other side still might get a couple of attacks in first if there's a huge difference).

EDIT: And, furthest-right (also indicated by a slightly raised position) is current turn.

All art is my own, except the battle background which is a photo that I took.


So, how about Luck stat. It's never obvious what that one does in an RPG, is it?

Well, here, I'm making it actually influence how lucky you are. Specifically, your luck - or more commonly, the difference between an attacker's luck and a target's luck - will actually result in the RNG itself favoring or disfavoring you.

For example - let's suppose we have an attack that ordinarily has a 50% chance of inflicting a status effect, on an enemy that has no resistance. If the attacker and target's Luck are equal, it will indeed have a 50/50 chance of succeeding or failing. But if they're a bit further out, the chance will skew in the favor of the higher-luck battler.

I've attached a screenshot from running a test of this bias algorithm. These show (in order) the lowest, average and highest values obtained with various levels of bias (which can range from -1 to 1), when generating a random floating-point value between 0 and 1, over 10,000,000 trials per bias level. For the record - the formula used to calculate the bias factor is "attacker's luck minus target's luck, divided by 100". (Remember, the Luck stat is limited to the range 0 to 100.)

On a technical level, the algorithm is:

1. Generate a random floating point number between 0 and 1 via the native Random class
2. Generate a random floating point number between 0 and the bias factor (which may be negative, but should always be in the range -1 to 1), again via the native Random class
3. Add these two results together to get the final result

If the result is not in the range of 0 to 1, then the algorithm goes back to step 2 and tries again, until either the result is valid, or the cycle has been attempted four times. In the latter case, the result from step 1 is used unmodified as the final result. On a technical level, steps 2 and 3 are skipped if the bias factor is zero, although this is just an efficiency thing, since actually running the full formula with a bias factor of zero will quite obviously give a result of exactly the value from step 1.

If an integer is desired rather than a float, then it's handled in the same way random floats have been turned into random ints for the last few decades.

[namida]

I made some tweaks to positioning of characters, as well as the CTB bar. Also, character names are now right-aligned, which both looks neater and removes concern around how long the names are.

The info bar at the top isn't new, that was actually one of the first things that was implemented; it just wasn't in the last screenshot.

Fitting all this in with a side-view system in a 16:9 aspect ratio is a bit awkward. I might make the attack selection menu cover up a bit of the tail end of the CTB bar, and make it possible to hold a key to hide it. An alternative option might be to present the information on the left / right instead of at the bottom, but I dunno... I feel like that'd be really awkward. It doesn't need too much space, as I'm planning to limit how many skills a character can have at a time. (Keyword here is "at a time". You can learn more, but you can only select a few to have equipped at a time. Not sure yet if changing equipped skills will be outside-battle-only, or simply cost a turn.)


EDIT: So, I figured - once again, keep it simple! I just shortened the CTB bar altogether. Now, instead of displaying the order of the upcoming 25 turns, it only displays the order of the upcoming 17 turns. Probably still more than enough, between the original game and FFX challenge runs combined I don't think I've ever seen a case of needing to see more than, in extreme cases, 10 or so turns ahead.

That aside, attack selection menu is here! Item is listed twice just to fill out the list (I wanted to test the scrolling through the options). Not pictured, but MP costs can also be displayed next to attacks. This isn't properly tied to characters' turns yet - it's currently just hardcoded to automatically pop open an attack selection menu for Red Girl whenever one isn't already open.

Comment on latest commit: More attack data, fixes to selection wind ow when multi-col, scrolling on selection window, attack tips, battle scene changes, note to self that I need to commit more often. To be fair, this IS partly because my main goal here was "implement attack selection window and make it work well", and all these other things were done in the process of achieving that.

[namida]

Latest feature: The delay of the selected attack is now reflected in the upcoming turns display. Also, the order is now left to right. This feels more logical to me, even being used to the right-to-left order from the original game. (FFX didn't influence this decision, since FFX displays the upcoming turn order vertically.) The fact that the current turn is slightly raised above the others - and also now has a different colored border - should be enough to make this clear, I hope.

For the record - delays of different moves is a straightforward multiple. In these screenshots, Attack has 1x delay, Item has 0.75x delay, and Escape has 0.5x delay. These values are very much not final (I simply picked some for testing), except for Attack (since my intention is for it to be the standard that these delays are relative to - of course, on a technical level, that's purely a matter of "it definitely will have a 1x delay").

For now, my main focus is on getting the basics of the map and battle system in place (in the case of the maps, a significant portion of it already exists). Then from there, I'll most likely add further features as they're needed, rather than adding a whole bunch of stuff that "might be useful".

[nin10doadict]

Being able to see how the move affects the upcoming turns is quite nice. One thing that bugs me about Final Fantasy Opera Omnia is how moves that grant speed buffs or debuffs don't reflect the new status in the turn queue before the buff/debuff actually occurs. I've had instances where I was trying to plan my turns in a specific way, only to find the queue suddenly changing because one of my characters gave themselves a speed buff.
This might be hard to implement if buffs/debuffs are not guaranteed to work, however. Judging by the system you've made for the Luck stat, it would seem that there will be times when they are not sure things. Come to think of it, they aren't always guaranteed in Opera Omnia either (some enemies resist speed debuffs, etc.) so that might be the reason for it being how it is.

[namida]

Being able to see how the move affects the upcoming turns is quite nice. One thing that bugs me about Final Fantasy Opera Omnia is how moves that grant speed buffs or debuffs don't reflect the new status in the turn queue before the buff/debuff actually occurs. I've had instances where I was trying to plan my turns in a specific way, only to find the queue suddenly changing because one of my characters gave themselves a speed buff.
This might be hard to implement if buffs/debuffs are not guaranteed to work, however. Judging by the system you've made for the Luck stat, it would seem that there will be times when they are not sure things. Come to think of it, they aren't always guaranteed in Opera Omnia either (some enemies resist speed debuffs, etc.) so that might be the reason for it being how it is.

I would like to implement this (showing the effects of buff / turn-order-affecting statuses / etc) if it doesn't get too messy. I'll most likely copy how Final Fantasy X handles this situation in regards to moves that may either succeed or fail based on chance - the upcoming turn order display, while targetting, will simply assume the status / buff / debuff infliction succeeds and adjust accordingly, instead of calculating whether it will or not / paying attention to immunity etc.

Buffs would most likely be guaranteed to work. Having partial resistance to positive statuses / buffs feels weird to me - there are definitely cases that justify full-out immunity, especially with double-edged sword statuses like Reflect or (if Zombie exists and the enemy in question isn't immune to it) Regen.

[namida]

A bit hard to capture in pictures, but I made some significant progress on the battle system today.

The turn order - including different delays from different attacks - is now fully implemented! You can select attacks and pick targets for them (though the attacks don't actually do anything, except display their name if applicable, currently). Changing enemy target isn't yet implemented, because this will be a bit more complex than changing targets among allies.

The reason for this - allies are always in a line top to bottom. You press up, you go to the ally above the currently targetted one. Press down, you go to the one below. But enemies aren't always so straightfoward - they could be in just about any formation, really. And I need to think of how (in terms of coding - I know, from a human point of view, what should happen) to implement proper selection with this. It might seem simple at first, but think about situations like this:

Enemy A is at (10, 10). Enemy B is at (30, 9). Enemy C is at (26, 5).

If I'm currently targetting Enemy A and I press Right, yes, enemy B should be targetted. That's obvious, and easy to code.
But if I press up, what should happen? I feel that Enemy C should now be targetted. But what formula can make this happen, without hardcoding every single case? Enemy B is closer to (but still above) Enemy A both in terms of vertical distance only, and in terms of total distance (I think; I didn't actually test the numbers to make sure he really is closer).

But maybe enemies don't need to have complete positional freedom. If there are only a certain number of "slots", this could be handled much more easily. Perhaps the enemies could even be graphically offset from their natural slot-based positions, and the slots are used purely for target selection purposes (and tiebreaking in turn order; the last resort factor is "the ones listed earlier in the formation get their turn first". Before resorting to this, the game first uses the Agility stat as a tiebreaker, and if there's still a tie, it then uses a priority of "Characters, then boss enemies, then regular enemies" - only if all that still leaves a tie, the in-formation order is used, rather than bothering with yet another tier of tiebreakers.)

There is a slight random effect on how quickly a character / enemy get their first turn - and Luck stat indeed affects how likely you are to get a favorable outcome (in this case, it's just the character / enemy's Luck stat outright; not relative to another battler's Luck) - but there's no randomization at all involved in subsequent turns. Using the same test scenario as before over several trials (about 15 or so), looking at the first six turns of battle, only one trial deviated from "Red Girl gets three turns, the other battlers get one each" - in the trial in question, Blue Girl got none and the enemy got two; beyond that, the randomization only slightly affected the order of these turns. So it is a fairly minor effect. And of course, you could always avert that by equipping Pre-Emptive (not yet implemented, but I 100% intend to add it) to get a turn immediately at the start of battle.

EDIT: Wait, the Duck wasn't there last time I specifically focused on turn order in this topic. He has 11 Agility. (And just for the record, I don't intend to have a duck as one of the playable characters. If I use the duck graphic at all, it'll likely just be as a background decoration thing. I'm simply using it during testing because I made the graphic and so it's handy.)

[Proxima]

Enemy A is at (10, 10). Enemy B is at (30, 9). Enemy C is at (26, 5).

If I'm currently targetting Enemy A and I press Right, yes, enemy B should be targetted. That's obvious, and easy to code.
But if I press up, what should happen? I feel that Enemy C should now be targetted. But what formula can make this happen, without hardcoding every single case? Enemy B is closer to (but still above) Enemy A both in terms of vertical distance only, and in terms of total distance (I think; I didn't actually test the numbers to make sure he really is closer).

Will you still have healing enemies (e.g. with Zombie status) and hurting allies (e.g. with elemental drain) as a major part of gameplay? If so, I would make up/down cycle between the entities on a single team and left/right switch to the other team.

Incidentally C is closer to A than B is. 16² + 5² = 281 < 401 = 20² + 1².

[namida]

Hence the "(I think; I didn't actually test the numbers to make sure he really is closer)".

Wouldn't using up and down to target enemies feel weird if say, there are enemies in a formation like this?

On the other hand, I could definitely see an argument for "if already on furthest-right enemy, target party" / "press left on party to target enemy".

[namida]

Attacks finally do something!

There's still a long way to go. You still can't select an enemy target other than the default one (I'm still not entirely sure how I want to implement this), though you can choose to target an ally instead (and you can select which one). If you could, you'd probably be able to select dead enemies. Enemies also have no AI whatsoever - they just repeat the last action a party member made, including the target. And there's no animation for the attacks, apart from displaying the damage. Also, while enemies do disappear when killed, the game doesn't at all recognize "all enemies have been defeated, time for the battle to end" yet.

Still, it's progress!

[namida]

I was getting a bit burnt out working on the battle system for now, so I decided to start developing the menu system.

While it doesn't have much at this stage, a quick glance might already hint at some new features I plan to implement this time around. I'll be basing it off how FFX handled it, though not an exact clone (I plan to draw some inspiration from FF8 here too, although it'll be much closer to FFX).

On a side note, this is also the first new engine screenshot I've shown that shows the field screen, too. This is just a test map, it's not in any way intended to be part of the final game. (The tileset, or at least some of the tiles, likely will be used though.)

[namida]

I've reworked the code slightly to allow me to easily increase the resolution at a later date if I decide to do so. Well, "easily, not including actually making the higher-resolution graphics", I mean.

All I have to do is change a single constant, and slip in the higher resolution graphics. This is good - I'd like the graphics to be of a decent resolution for the final product, but if I try to achieve that while still making the engine work, I'm going to spend too much time on the graphics (instead of making crappy placeholders) and not enough on the coding - that was an issue with the first remake attempt.

I also implemented another change that looks really nice. See if you can spot it.

EDIT: And I've now implemented some more of the menu system, too.

[nin10doadict]

That new text spacing does look a lot better.

[namida]

So, the new engine's battle system has all the basics there now. By "basics", I mean you can start, and actually win (or lose), a battle.

In terms of attacks, not many have been implemented yet. Even the "Item" and "Escape" commands are currently just attacks called "Item" and "Escape", but obviously I intend to change that soon (some of the behind-the-scenes stuff for actually handling item use and escaping is there; it just hasn't been connected to those commands as such yet). However - the flow of turns works (already including different delays on the next turn for different moves), attacks now apply their effects and display animations / damage values, support for enemy AI is there (currently quite limited in terms of features, but the framework to expand on that is there already). As far as the battle system goes, it's time to start implementing the more advanced stuff.

The menu system and map haven't really progressed much since last time. I have made a couple of maps, but I haven't done anything new engine-wise.

EDIT: Okay, escaping works too now! (At least for party members; I haven't tested enemies escaping yet.) Most of the back-end code to handle it was there, I just had to actually make the "Escape" command be recognized as an attempt to escape. A couple of minor bugs existed - namely that the character's graphic remained visible and they could still be targetted with single-target attacks (although enemy AI correctly avoided doing so; this was only relevant to manual targetting of party members' attacks) - but these are fixed now.

The regular "Escape" command has a 75% success chance before the Luck stat is taken into account.

[namida]

I've now added the necessary stuff to have treasure chests on the map.

While a lot of things are lacking (eg. 98% of the menu system, and attacks that do anything other than straight damage / healing), random battles is pretty much the only thing needed before the engine will have enough features to support a basic filler dungeon, with multiple rooms and one or more bosses.

338KB of source code to reach this point. Wow.