Lemmings Forums

Off-Topic Boards => Non-Lemmings Projects => Topic started by: namida on November 25, 2018, 10:57:58 PM

Title: namida's new RPG project
Post by: namida on November 25, 2018, 10:57:58 PM
(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 (https://www.lemmingsforums.net/index.php?topic=1653.0). 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.)
Title: Re: namida's new RPG project
Post by: namida on December 05, 2018, 09:21:04 PM
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. :)
Title: Re: namida's new RPG project
Post by: namida on December 07, 2018, 05:50:27 AM
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.
Title: Re: namida's new RPG project
Post by: namida on December 08, 2018, 09:17:15 AM
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".
Title: Re: namida's new RPG project
Post by: nin10doadict on December 09, 2018, 12:23:45 AM
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.
Title: Re: namida's new RPG project
Post by: namida on December 09, 2018, 01:45:02 AM
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.
Title: Re: namida's new RPG project
Post by: namida on December 09, 2018, 08:56:57 AM
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.)
Title: Re: namida's new RPG project
Post by: Proxima on December 09, 2018, 09:49:21 AM
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. 162 + 52 = 281 < 401 = 202 + 12.
Title: Re: namida's new RPG project
Post by: namida on December 09, 2018, 10:50:47 AM
Hence the "(I think; I didn't actually test the numbers to make sure he really is closer)". :P

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".
Title: Re: namida's new RPG project
Post by: namida on December 09, 2018, 11:51:11 PM
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! :D
Title: Re: namida's new RPG project
Post by: namida on December 12, 2018, 09:02:35 AM
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.)
Title: Re: namida's new RPG project
Post by: namida on December 16, 2018, 07:37:19 AM
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.
Title: Re: namida's new RPG project
Post by: nin10doadict on December 16, 2018, 05:58:00 PM
That new text spacing does look a lot better.
Title: Re: namida's new RPG project
Post by: namida on December 18, 2018, 10:02:51 AM
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.
Title: Re: namida's new RPG project
Post by: namida on December 19, 2018, 04:04:49 AM
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. :D

338KB of source code to reach this point. Wow.
Title: Re: namida's new RPG project
Post by: namida on December 21, 2018, 10:26:39 PM
Elements and status effects (in general, not every individual status) are now working (though I still need to implement immunity / resistance to statuses).

In terms of which status effects are actually implemented so far, it's only Death, Zombie, Haste, Slow, Shield, Aura, Weaken and Meltdown - but more are coming, don't worry about that! I'm not necesserially going to copy everything from the original (for example, two of these have been renamed, and are just similar rather than identical in effect), but it's likely we'll see at least some of the standard-RPG-fare ones - and maybe some new stuff if I come up with good ideas that I think will have practical use scenarios.

I've also decoupled animations / displaying attack effects, from the overall progression of the battle system. This means, essentially, that I can make an animation play and/or an effect show at any time - one use case for this would be showing statuses being removed at the end of a turn due to expiry; another might be to show Poison damage (once I implement that).
Title: Re: namida's new RPG project
Post by: namida on December 22, 2018, 07:22:56 AM
Done a lot today. In addition to those mentioned in the previous post, I've now added the status effects Poison, Blind, Silence, Sleep, Virus, Regen and Defend (EDIT: and Reflect). Additionally, buffs and debuffs - or at least, Strength, Defence, Magic and Spirit buffs and debuffs - are all working. I'm probably not going to add HP, MP or Luck (de)buffs (but I will likely add Agility). Finally, status resistance is now a thing at last.

I've also finally implemented equipment. I won't say too much for now on how equipment will work this time around, but I will say it's a little bit different - though should still be very easily understood by anyone who's played the original game.

One feature FFX had that didn't make it into the original game, but the new engine has now, is "SOS Status" abilities. These are similar to Auto-<Status>, but only activate when the character is below half HP.

EDIT: And, finally implemented enemies dropping items!
Title: Re: namida's new RPG project
Post by: namida on December 23, 2018, 12:18:51 AM
I've now implemented status-touch/strike and element-strike abilities. :D

So, let's talk about how equipment's going to work this time around. Instead of having a traditional-style weapon, and several ability slots, instead, you'll have a weapon and an armor, which themself may contain abilities. Similar to FFX, the weapons and armor have no special features whatsoever outside of the abilities on them - so even if you got them in different places or they have different names, two weapons with "Physical Damage +10%" as their only ability will function exactly the same.

Currently, I'm thinking along the lines of capping the number of abilities per equipment piece at 4. Remember - this is per piece, so between a weapon and an armor you'll be able to have 8 total abilities. However, I don't plan to allow total freedom over what abilities are on equipment - I might implement shops where you can custom-build a weapon, but this would only be from a (shop-specific) limited selection of abilities. For the most part, it'll be a matter of what you find (which will be fixed) or receive as drops (which there will be room for variance on - for example, the swan enemy I've been using as a test will have a 50/50 chance of weapon vs armor, which then has a 50/50 chance of having either Physical+/-5% (+ for weapons, - for armor) or Magical+/-5%, and then a 10% chance of also having the corresponding 10%). The scripting for drops allows for a bit more complex than this - for example, the abilities could vary depending on which character they're for.

Any individual weapon / armor is tied to a specific character. However, the character will be able to switch weapon / armor at any time (even in-battle, though this will cost a turn, and only one piece can be changed per turn, not both).

Abilities also won't always be positive. While there'll be more positive than negative, you may very well come across an armor that gives you an elemental weakness, or a weapon that reduces the damage you deal, or an armor with something like Hasteproof on it. In some cases, this really will just be junk equipment that serves no purpose, but in other cases, it might be that you come across a double-edged sword (pun not very intended) - for example, you might find a weapon that reduces your physical damage dealt by 10% but increases your magical damage by 25%, or an armor that makes you immune to Haste but gives you auto-Shield and auto-Aura. Or, there might be situational uses for them - for example, an armor with Auto-Zombie might not be so useless against a boss that likes to use instant death moves, especially if it also comes with an elemental absorb on it so you've still got a way to heal. Or if a boss likes to use the Zombie-Regen combo and you don't have any way to block Zombie, you might have at least picked up a Regenproof armor somewhere.

I've also now implemented summoning - or at least, the basic summon / dismiss (though there are further details of how this will work, that remain to be implemented). Probably the only major battle system features that are still missing are in-battle equipment changing and member switching. (Some specialized moves - eg. Steal, Mix (maybe) - still need to be implemented.) EDIT: Both switching and equipment changing are possible in-battle now.

Because there'll be a limit to how many abilities a character has available at a time, I don't see the need to segregate attacks into sections like "Black Magic", "White Magic", etc. However, the list will be split into two sublists (accessed by pressing left / right from the other list). The first one has Attack, Summon, all equipped attacks, and Item (in that order). The second one has (currently in this order, but I wonder if this is the optimal order) Defend, Change Weapon, Change Armor, Stall (pass turn without doing anything), Switch and Escape. In particular, I wonder if having Stall in the middle is optimal (as you can wrap around, Escape and Switch are still fairly quick to get to).

As a point of interest - just to get to this point, which is still far from done (especially in terms of the menu system, where almost nothing works so far - you can view (but not use / equip) your inventory and you can view and reorder your party, that's all), there's already 421KB of source code. o_O

And another very important feature has just been implemented - you can now save and load your game! At the moment, it's limited to a single save file, but this is purely a matter of "I haven't added a menu to select from extra ones" yet.

Counterattacks have also finally been implemented. One thing I can confirm is we won't see the behaviour from the original where counterattacks can occur mid-attack (eg. in the case of Double Hit, where an enemy would counter once after each hit, or when using a hit-all magic spell against multiple counter-capable targets, where each target would counter immediately after taking damage rather than after the whole attack finished).
Title: Re: namida's new RPG project
Post by: namida on December 26, 2018, 03:41:24 AM
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. :-\

I've now got this implemented for Haste and Slow. I still need to do it for Agility buffs / debuffs, as well as handle some edge cases. EDIT: And now the (de)buffs, and all the edge cases I could think of, are covered. :D

When you're selecting a command, the turn order will update to reflect what will happen from use of that command alone. Once you're selecting a target, it will also reflect what any status inflictions will do to the turn order. When rendering this, it assumes the infliction will succeed (it makes this assumption even if it's literally impossible for it to succeed). And yes, it takes into account any [status]touch/strike abilities you may have when using physical attacks, too. :)

MP-damaging and draining attacks (including MP-draining attacks) are also implemented now. I still don't feel very comfortable with the idea of enemies actually requiring MP (being able to drain away all their MP just feels like a really cheap tactic, unless they solely use unique attacks that don't consume MP, in which case it's no different from them having free use of spells), so it's likely that'll be the same here - that enemy MP is only there for the purpose of absorbing it. However, perhaps if other means of healing MP aren't so common... ;)
Title: Re: namida's new RPG project
Post by: nin10doadict on December 26, 2018, 04:56:33 PM
The turn queue reflecting buffs gained/lost with the move sounds very good.

Well, enemies having infinite MP or not needing it for anything is fine, as long as you don't try to play tricks with it.

I recall one battle in Bravely Default where a boss character was talking about his party "using up too much MP," leading me to believe that using abilities and attacks to drain their MP was a valid strategy. Nope. They either have practically infinite MP or just don't need it for their attacks.
Coincidentally, that battle is one of the hardest in the game if you don't use cheese tactics, and not just for the reason that the dialogue tries to mislead you.
Title: Re: namida's new RPG project
Post by: namida on December 26, 2018, 11:57:39 PM
So, you may have noticed in an earlier screenshot, the presence of a "Summons" option in the menu. I'm sure you're all familiar with the general concept of summoning in RPGs, and as you probably guessed the way they work in this game is similar to FFX.

Each character can equip one summon at a time. I plan to tie useable and/or learnable abilities to the equipped summon, but haven't decided on exact details of this yet. It is possible that some characters won't be able to summon, or that some otherwise-regular characters won't be able to change their equipped summon.

During battle, you can summon on any turn. This essentially works like switching to the summon, except that it replaces your entire party (not just the character who summons it). It's not a game over if the summon dies; you go back to controlling your party instead. Once the summon dies, you cannot summon it again for the rest of the battle - after the battle, it comes back with 1 HP, just like characters do.

Summons also have a "rage meter" (actually, regular characters do too, but it works a bit differently for them). When they receive or deal damage, this meter fills up. When it reaches full, the summon automatically uses their special move (usually a very powerful hit-all attack, but there are exceptions, for example, one summon has a move that fully heals your party, including status effects, and bypassing Zombie and Virus). Once they use their special move, control returns to your party and you cannot summon that summon again for the rest of the battle. On other turns, they work just like regular characters do, aside from that they cannot use items, escape, change equipment (since they don't have equipment) or defend.

Aside from this, summons also have three special moves. The first one, "Guard", halves all damage taken (unlike Defend, which only halves physical damage), and increases the rate the rage meter charges at, until the summon's next turn. The other one, "Relax", increases all damage taken by 50%, but prevents rage meter charge. Whether the rage meter effect is positive or negative will likely be a situational thing. The final special move, "Dismiss", returns control to your party. This does not prevent you summoning that summon again, but their rage meter does not reset next time you summon them (unless it's in a new battle).

The exact numbers are likely to change, but the general concept isn't, unless it really ends up being too broken (and of course, enemies / bosses will be designed with the fact that this feature exists in mind).
Title: Re: namida's new RPG project
Post by: namida on December 27, 2018, 01:00:03 AM
Scan window!

Blue Girl doesn't have any status effects currently inflicted on her, but if she did, they'd display (one at a time, with the icon and name) in the top-right corner. Despite their vulnerabilities not being listed (since immunity / resistance to them would be kind of silly), Defend, Guard and Relax will also be listed among the current status effects.

Immunity to statuses is specifically displayed as "Immune" (or rather, abbreviated to "Imm."), rather than just "0%". Additionally, "Auto" will be displayed when relevant.

There'll be none of the varying degrees of elemental resistance, which is why they don't show as percent. "Weak" always means double damage, "Resist" always means half damage.

Speaking of Scanning in general, there's now a shortcut to scanning all enemies. If one of your frontline characters has a weapon with the Sensor ability equipped, all scannable enemies are treated as scanned. This isn't a permanent effect - if you switch the character back out, the enemy is no longer scanned (unless you've actually casted Scan on it too). Although I might just change this to "if you have a non-dead, non-escaped character with a Sensor weapon anywhere in the party, even if not on the frontline", since there's nothing stopping a player from switching the Sensor character in, looking at the scan info, then switching back out.
Title: Re: namida's new RPG project
Post by: namida on December 28, 2018, 09:26:52 AM
Made some progress on the menu system. :)

But for now, a notable milestone - the new engine now supports everything needed to replicate the Transient fight from the original game! (In fact, I think a lot could be reproduced, although there are a few that couldn't yet, eg. Returner.)
Title: Re: namida's new RPG project
Post by: namida on December 31, 2018, 02:56:43 AM
So, I've implemented most of the levelling and attack learning system now.

Learning attacks works somewhat similar to the old game, except instead of each character having an inherent class, the attacks they can learn are determined by the equipped summon. You still earn AP, and spend it to learn attacks. However, you won't have all your attacks available at all times. Instead, you can equip up to a certain amount - I'm currently thinking four or five - at any given time. Once you've learnt an attack, you can equip and unequip it freely, you don't have to pay the AP cost again if you unequip it. On a side note, you can also learn a limited number of abilities (similar to the ones on equipment) this way. They have a separate cap from the attacks, which I'm currently leaning towards setting at two.

As the attacks are tied to the summon equipped, you'll mostly only be able to use attacks that were learnt off your currently-equipped summon. But I am leaning towards allowing the equipping of a single attack (and maybe a single ability, not sure) from a different summon.

Summons themself will similarly have to learn and equip attacks to use them in battle, though one key difference - they don't gain or spend their own AP. Instead, they learn the attack once a character with them equipped learns it - this is not tied to that character; they'll retain the attack even if they're later moved to another character who hasn't learnt it.

Blue magic will likely, again, work a bit differently from everything else. I haven't decided for sure how it will work yet, though I do have some ideas.


Now, increasing stats on the other hand, has undergone a huge overhaul. You still gain EXP from defeating enemies, and probably still won't gain EXP from bosses, but that's the only similarity really. Your EXP doesn't directly increase your level, instead, it's stockpiled in the same way AP is. You can then spend EXP on directly increasing your stats. Each upgrade will increase your max HP by 25, max MP by 5, or any other stat by 1. The cost per upgrade varies between stats, as well as between characters. On a side note, stats are now capped at 9999 HP, 999 MP, and 100 for all other stats - there's no "Ultra HP" / etc this time.

This also means that if you want to do a low-level game, you can do so without having to avoid battles - simply don't spend more EXP than you feel is acceptable to still count as "low level". Likewise, you can decide separately whether it's also a no / limited ability learning game, or if it's just "keep your stats low but learn as much stuff as you like" (or vice versa).
Title: Re: namida's new RPG project
Post by: namida on January 01, 2019, 12:27:10 AM
I've got most of the menu done now.

Still left to do is a proper save menu, and the settings menu (although I can't think of much to put on here, aside from controls). Source code now stands at 626KB, plus 107KB of text-based data files (most, but not all, of which were hand-written). This includes a lot of will-actually-be-used content, especially in regards to attacks and abilities.

I've also implemented the learning system for Blue Magic. This won't be based on items, rather, the blue mage character will be unable to use summons, and will instead learn new attacks (and passive abilities, although they can still get those from equipment too) when they scan an enemy. This doesn't require the enemy to be vulnerable to Scan (although in general, I plan to generally avoid using immunity to scan - most likely only on enemies that do weird stuff with their HP behind the scenes and thus Scan could be misleading, or in cases like Pyragon where hiding some info is part of the puzzle). So for example, instead of learning Blessing by using an item that teaches it, you'd learn it by using Scan on (most likely) an enemy that uses it themself.

In terms of actually using them, this is a case where a non-summon would make use of the rage bar. It would charge in much the same way as a summon's does, although slower, as well as having a move similar to Charge that specifically charges it - this move would only be available to the blue mage, and would cost MP. Blue magic then uses the rage bar as a cost - weaker blue magic similar to Smokescreen might only require 5% of the rage bar, whereas powerful ones like Judgement and Glory would possibly require the entire bar.

(For other characters, the Rage bar is simply a matter of that they have one special attack they can only use when their Rage bar is full. Unlike summons, they are not compelled to use it, nor do they suffer any negative side effects from doing so - it's just a regular attack apart from requiring (and consuming) a full Rage bar.)
Title: Re: namida's new RPG project
Post by: namida on January 08, 2019, 06:10:52 AM
I've finally made a decent map editor, having previously used a kludgy one that I built into the game engine itself. While the kludge one did everything I needed it to functionally, the UI was terrible even by "designer tool only" standards. This one is a bit better, even though it's still nothing fancy (and definitely not up to the quality I'd consider if it was a tool I intended to release). I did fall back to Lazarus for designing the map editing tool, as I don't really have a good feel for form-based C# code yet.

Here's a preview of the only intended-for-actual-use map I've been working on so far. This isn't the whole map.

The darkened area on the left is an editor thing; that region wouldn't actually be that color in-game. The graphics will also very likely be higher resolution in the final product; I'm working on a basis of 512x288 while developing, but have coded it so I can very easily substitute higher-resolution graphics later (without having to adjust any existing coordinates - I've got an abstraction layer that converts to and from internal coordinates when rendering). I'll very likely make - or perhaps look for an artist to make - better quality graphics if the project ever gets close to release. This does accurately reflect how much of the map the player will be able to see at a time in-game though.

That aside, "events" on the map (pretty much anything you can interact with, aside from straightforward warps or treasure chests) can also finally have move routes when idle! (It's been possible for a long time for a script to tell them to move.)
Title: Re: namida's new RPG project
Post by: namida on January 09, 2019, 01:32:31 AM
Videos work better than screenshots for the map, so here!

https://www.youtube.com/watch?v=iBaTEHFRZjw
Title: Re: namida's new RPG project
Post by: namida on January 09, 2019, 09:28:26 PM
First indoor map that's reached a point where I feel it's okay to show off. It's still incomplete, but it's coming along nicely.
Title: Re: namida's new RPG project
Post by: Proxima on January 09, 2019, 09:58:51 PM
As it is now, the map has the same problem as a lot of novice RPG Maker maps, judging by the number of times this comes up in the "Maps and Screenshots" discussion topics: the room is unrealistically large. (Although one way you could maybe justify it being this large would be to add furniture so that it becomes, in essence, an entire house in one room; that may be more common in other cultures?)
Title: Re: namida's new RPG project
Post by: namida on January 09, 2019, 11:53:59 PM
Quote
(Although one way you could maybe justify it being this large would be to add furniture so that it becomes, in essence, an entire house in one room; that may be more common in other cultures?)

That's part of the "still in progress". ;)
Title: Re: namida's new RPG project
Post by: namida on January 14, 2019, 07:52:11 PM
So, I've posted another video, showing off a fair bit more than the last one did.

https://www.youtube.com/watch?v=YbI_zjvP8Yo

Of particular interest:
- A random encounter about 1/3rd of the way through the video
- Three different maps are visited.
- Visiting an Armor forge near the end. This is a shop that can custom-make armors (and yes, equivalents for weapons exist too).

Read after watching (click to show/hide)
Title: Re: namida's new RPG project
Post by: namida on January 18, 2019, 06:40:43 AM
I've mostly completed the first town, the first field area (these were both seen in the video) and the first dungeon - including a boss.

Still missing are proper graphics and lines for the majority of NPCs, and most of the cutscenes (I've only made one so far, and it's a very simple one). Also, very few attacks have proper animations so far (all enemies have a proper graphic, though). Also, I've only done rudimentary balance-testing so far, so it'll likely need more tweaking. And, no custom music yet - I'm still using Lemmings music as placeholders. :P

For story-related reasons, the player won't be able to learn any attacks (or have any of the learnable ones pre-learnt) at this point, which means the boss is mostly a matter of equipment, and good use of items and Defend. The boss was somewhat inspired by - though far from identical to - Klunky from the original game.
Title: Re: namida's new RPG project
Post by: namida on January 19, 2019, 09:36:20 PM
For those who've played the original game - you may recall that there were some guys near the start that explained a lot about game mechanics.

So one issue there, obviously - it's very easy to miss this. That's easily solved; for the new game, I've made it so that a mandatory cutscene draws attention to their presence, and specifically points them out as people who will tell you useful info about how the game works (though in less fourth-wall-breaking language).

But another is - there's HEAPS of them, and the information can be a bit much to all take in at once. So I'm wondering - to those who have played, what information do you think would have been useful to have in such a place? What doesn't really need to be there? (FYI, nothing about learning abilities beyond maybe "you'll eventually be able to" needs to be discussed there, because you only gain the option to do that after defeating the first boss - so an explanation for that can come later.)

Also, more preview stuff! Keep in mind these will likely be replaced with better, higher-res ones later*, but here's the current face graphics for the first two summons your party obtains - the fire-elemental Laraven, and the water-elemental Sualvelon. I have story-related reasons why I've decided to make all the summons humanoid. (Besides these two, I've made the face graphic for one other, and have a decent image in my head of what two more will look like.)

* maybe. I'm actually starting to be a bit undecided on this, in some ways, I like the simple graphics even if they don't look amazing. Also, chances are if I want better looking art, I'm going to have to look at hiring an artist because I'm not likely going to be able to produce high-quality, high-resolution artwork myself and I don't want to use stuff (other than sound effects, because those simply aren't all that feasible to get any other way) from resource collections, free or otherwise.
Title: Re: namida's new RPG project
Post by: namida on January 28, 2019, 01:56:24 AM
Progress has been a bit slow over the last week, but I'm still making progress. I've done all the cutscenes for the first "quest". Still using placeholder graphics for all the NPCs, aside from one who's very plot-significant. Attack animations, except Miana's physical attack, are still all placeholders.

I might just stick to leaving placeholders except for major characters, for now (including for attack animations). I intend to replace the current graphics with better ones later anyway, so it's probably not that vital to have not-as-placeholder-y placeholders. :P But I do like to have proper graphics for major characters (including non-party-members), even if they're low-quality placeholder ones.

I've also created the heal / fast travel points (these are the same thing, you can do either at them). Generally, fast travel points in towns can be travelled to, while ones in dungeons / fields cannot (you can only travel from them, or use them to heal). You can save anywhere, so I won't be calling them anything resembling "save point" this time around.

Heals, however, are limited. While there's no permanent cap, either globally or per-point, you need to fight a certain number of battles inbetween heals at these points. You begin the game with a heal available, but after this, you must win 3 battles before the next heal, then 5 before the one after that, and so on. This is capped at 32 battles between heals. Battles you escape from, or losing a battle that doesn't result in a game over for losing, won't count towards the requirement. Discovering a new destination point will immediately drop the "battles until next heal" to zero. This is not tracked per-point; it's a single battle count requirement shared across all fast travel points in the game.

Note that the heal is not automatic when you access a fast travel point and are eligible for a heal - you must explicitly select to use it. This also means you can fast travel, while still saving your heal for a later time. If you aren't currently eligible for a heal, the fast travel points will display in a darker color on the map, and when you try to use it, the (disabled) "heal" option will have a number next to it indicating how many battles you need to fight until you can heal again.

I haven't implemented the actual fast travel mechanism yet, only the healing mechanism and the unlocking of new points. The travel itself is probably one of the next non-content things I'll do.

I may revise having the cap set at 32, but aside from that I'm pretty happy with these mechanics.
Title: Re: namida's new RPG project
Post by: namida on February 02, 2019, 09:53:47 AM
Here's the whole combined outdoor area so far. This doesn't include the insides of buildings in town, or the dungeon segment.

To the player, this would seem like one huge map (some of the transition points could be detected by the music changes, or the split-second lag when changing map) - but it's actually five maps altogether, using three different tilesets.

There are some parts that are abruptly cut off, but it's impossible to get close enough to those points to see it in-game (at least, not without using a debug feature that lets you walk through solid tiles).

Note that this is purely the map - it doesn't show NPCs, chests, etc. Also, these are rendered by the map editor, which doesn't share the game's codebase (it's not even written in the same language - the game is C#, the map editor is Pascal), so there might be slight differences in color etc. There shouldn't be, but it's possible.
Title: Re: namida's new RPG project
Post by: namida on February 15, 2019, 07:25:42 AM
Haven't had the most time where I feel like working on it lately, but I got some stuff done today. I also implemented the actual fast travel a while back, so that's fully functional now too.

I've added the option to push a button while on a map screen (that has encounters) to get an instant random encounter. I'm considering combining this with a random encounter cap per area, after which you won't get any more encounters in that area unless you specifically trigger one with the button. Alternatively, I might consider having only touch encounters outside of specifically-requested ones - possibly with the added factor that the touch encounters cannot be escaped from.

I've also changed how enemy AI works. Instead of an unnecessary script interpreter, I'm now hardcoding the AI into the source code itself. This averts a lot of mess. (Some other things still need interpreters, eg. event scripts, because they can't just be run entirely in one go but often need to stop at certain points; while equipment drops are simple enough that it's easier to keep them as scripts in the data files.)

Finally, a very familiar random encounter foe from the first game has been made for this one too. A certain one that's well known for their tendency to appear in large groups and gang up on a single target... :P
Title: Re: namida's new RPG project
Post by: namida on March 01, 2019, 06:12:39 AM
So, I've been thinking a lot about this, and found that in general - I'm just not really feeling it with creating the overall story / world for this new game. I had some interesting ideas, but couldn't really come up with much of a great way to tie it all together, and wasn't really enjoying that much creating the maps / etc.

Maybe that's something that will change, I don't know. But I'm strongly considering taking this project in a new, and somewhat unique direction... one that will likely appeal even more to people who quite enjoyed my first game. ;) I won't go into too much more detail than that for now, while I'm still working out some of the details of this new direction (and deciding if I actually want to take it), but I think it's something that I'd be much more inclined to keep at it with.