[PC][RPG] Legends of an Otherworld

[namida]

Are there really no game engines out there that's not RPG-specific, but still generic enough to support making a few different genres of games of which RPGs can be one?  I have nothing against writing your own engine from scratch, but I have to wonder if there's already something between that and RPG Maker which you can use instead, so less time needs to be spent on the low-level nitty-gritty, but still provide enough flexibility to do the things you can't do in RPG Maker.

I did look at a few, but ultimately found that most of them were frustrating me trying to work with /their/ ideas of how things should be done. In general, I usually do find it easier to work with my own code than anyone else's.

Interesting. Don't know if I could offer any story input though; I didn't get very far. I got terrified that I might spend time earning AP for a character only to have them disappear forever later. Also got scared off from the looming threat of "this game is hard now and will only get harder."

Any character who you ever permanently lose is not possible to gain AP for in the first place. That's one of the few ways I was nice to the player. (It doesn't really spoil anything, because it's made quite clear when such characters join that they're temporary.)

[namida]

Remake menu system coming along nicely. Face graphic is obviously placeholder.

Note the HP and MP gauges. The ones in the original version of the game only show the character's current HP relative to their maximum HP (and likewise for MP). This can often be misleading - if you have one character with 400 HP out of 1200, and another with 200 HP out of 400, who needs healing more urgently? Obviously the latter character - however, looking at the gauges can mislead, as the former's gauge would only be at 33%, while the latter's would be at 50%.

Instead, I've decided to make them consistent. So - green shows the character's current HP (or MP). Red shows the difference between their current and maximum. The black section is the difference between their max HP and the HP cap (ie: 9999 - I'm doing away with Ultra HP; or in the case of MP, it's 999). This way, the same amount of green bar means the same amount of HP, regardless of who has higher max HP.

While on the subject of stat caps - the original version capped stats (except HP and MP) at 255. This seems a bit weird; it's not due to any technical limitation in the engine, but rather is arbitrary, albeit based on that Final Fantasy also caps stats at this point. Instead, I'm going with a more logical cap of 99 this time around. Similar to in the original game, enemies will not be affected by the HP cap, but will still be affected by all other caps - although with that being said, rather than giving enemies outrageous amounts of HP, I'm intending to reduce the availability of overpowered attacks that lead to such high HP enemies. I don't envision many enemies having more than maybe 100k or so HP. (By comparison to the original - one of the final bosses has 1,000,000 HP, and some sidequest bosses have more than triple this.) Instead, you're not going to be having access to attacks that deal nearly that much damage in a single hit.

[namida]

The main screen of the menu is now complete, at least in terms of functionality (obviously some graphics still need to be added).

What's "Primary Class" and "Unleash Skill", you may be wondering?

In the original, each character had an inherent class, that they could use moves from without any special equipment. Then, equipment was available to allow them to equip extra classes. I've decided to greatly overhaul this system. Instead, each character now has a primary class, and up to two secondary classes. The character can use abilities from any equipped class. It's possible to unequip classes again, but the character must always have a primary class (I have actually already implemented this, but I haven't added support to the editor for actually setting their initial one yet, which is why the screenshot shows them all as empty). Thus, until you get to the point in the game where you get second copies of classes, you can't actually change them around - once you do, you can by all means remove the character's original class altogether and give them a different one - just keep in mind this won't significantly change their stats, so certain characters may not always be best suited to certain classes.

As for Unleash Skill, that's just the game's name for limit break type skills. I'm going to add, or in some cases repurpose particularly powerful moves from the original (think like Glory, Mix, etc), as limit break type skills. Similar to classes, you can equip and unequip these; you're not required to have one equipped, though characters don't have any inherent one to fall back on if you don't equip one. The Unleash Skill must match the character's primary class.

Aside from the unleash skill, regular skills will also be equipped and uneqipped, but a skill can only be equipped if the character has the matching class (it doesn't necesserially have to be their primary class).

At this point, beyond the Unleash Skill, I haven't implemented any ways the secondary classes are disadvantaged or lesser in effect compared to the main one. I'm still thinking about how, or even if, I want to do that.

That aside, yes, I've also added armor now. Note that most armor types are used by several characters rather than just one, so they're more interchangeable between characters than weapons are. Rather than equipping abilities directly like in the original version, I plan to go more FFX-like here and have the abilities be linked to weapons / armor. I'm undecided on whether the player will be able to customize the abilities on equipment, or if it'll be a matter of having to find equipment with the abilities you want.

[namida]

In the original version of the game, once you got to the point where most enemies gave more than 1 or 2 AP per fight, you could very quickly amass a huge number of abilities to have ready to use at any time.

I want to somewhat nerf that (not to mention the lack of direct levelling), and as such, I'm introducing the "Gem Gear" system. The above image shows the gem gear, to which you can equip gems which unlock various abilities. You can remove them, but you can only use abilities that come from currently-equipped gems.

As you can see, the gem gear provides 12 gem slots. This will be constant throughout the game. However, the slots are not all interchangeable.

There are three types of gems - Class, Unleash and Standard.

Class gems don't do much in and of themself. They might provide some minor passive benefits, such as slightly boosting some stats. The gem slot with the two green stars around it is the primary class slot; this is the only slot which must be filled at all times. The slots immediately to the left and right of it are the secondary class slots; these do not have to be filled.

Unleash gems provide a "limit break" type attack. An unleash gem will always have a corresponding class gem; you must have that class equipped as your primary class in order to equip the unleash gem. The slot right at the top is for an unleash gem. You don't have to have one equipped, but you can only equip one at a time. To be clear - there may be multiple unleash gems that correspond to the same class gem; but any given unleash gem will only have one class gem that it matches up with.

Standard gems might provide either a skill you can use in battle, or some kind of passive boost, or in some cases, both. Like Unleash gems, standard gems can correspond to a specific class gem; however, unlike unleash gems, there are also "neutral" standard gems that don't correspond to any particular class.

All remaining slots (besides the class slots and unleash slot) are for standard gems. Additionally, the two secondary class slots can also hold standard gems, if they aren't being used to hold class gems. There are some further limitations here: The four slots at the bottom can only hold neutral gems, or gems that correspond to the primary class. The two slots on each side (as well as the secondary class slots, if being used for standard gems) can hold gems that correspond to the primary class, or the secondary class on the same side. For example - if you equipped Fighter as the primary class, Theif as the left-side secondary class, and Black Mage as the right-side secondary class, the two standard slots on the left could hold Fighter-class gems, Theif-class gems, or neutral gems; but not Black Mage-class gems - those would have to go in the slots on the right. And you wouldn't be able to equip White Mage-class gems at all.

I envision most gems will provide some drawback to equipping them - as well as possible side benefits. Some neutral ones might be purely beneficial, but in this case, the downside would be taking up a slot that could otherwise allow you to equip an ability. But as an example, a standard gem that provides a fire spell, might also give the user a weakness to the ice element; or a standard gem that provides a strong physical attack might reduce the character's Defence and/or Magic stats. In this sense, it becomes not just a balancing game of deciding which skills within a limited range will be well suited for an upcoming battle, but also in terms of making sure you don't open too many weaknesses via the downsides of various gems.

I am wondering whether allowing the side slots to be used for the primary class might be overpowered, and I am considering making them for the secondary classes (or neutrals) only.

The gems themself would be found in all the standard ways to find items - drops / steals, purchasing, finding in chests, etc. Characters would also come with at least a primary class already equipped; and usually a couple more too (although in the case of Tara and Leanna, most likely they'll start with none beyond the primary class, but with them finding some very early in the first dungeon, as an opportunity to introduce and explain the system in-game).

(This is probably a bit of a confusing explanation, so feel free to ask if anything is unclear. Likewise, input is always appreciated, it's nowhere near too late to change any of this.)

[Nepster]

Nice to see such progress on your project!

One comment regarding the new main menu: I like the proportional HP/MP display over the characters, however at the beginning the bars will all be extremely small. How about setting the full bar to the maximum HP/MP among the characters, instead of the max possible HP/MP?

And I am not fully convinced of the gem system. It looks rather overly complicated. Whether this is worth in terms of new tactics, has to be seen however.

[namida]

One comment regarding the new main menu: I like the proportional HP/MP display over the characters, however at the beginning the bars will all be extremely small. How about setting the full bar to the maximum HP/MP among the characters, instead of the max possible HP/MP?

That's actually quite a good idea, thanks!

[namida]

I implemented Nepster's suggestion regarding the HP and MP gauges. The menu background looks different because I was also testing out code to allow for different window styles.

[namida]

Regarding the gem system, it can essentially be broken down to:

1. The character must always have a primary class equipped.
2. The character may equip one unleash skill (basically, limit break), which must be of their primary class.
3. The character may equip up to two different secondary classes, at a cost of one skill slot (see next point).
4. The character may equip up to ten skills, which may be either active (eg. Dark Attack) or passive (eg. HP+10%), subject to three conditions:
--- Any skills equipped must correspond to one of the character's equipped classes, except in the case of neutral skills (eg. HP+10% would be considered neutral, and could be equipped regardless of classes)
--- For each secondary class, only two skills that correspond to it may be equipped.
--- Two copies of the same skill may not simultaneously be equipped.

Beyond that, the only other thing of note is that some gems with one clear primary purpose (such as "let this character use the Fire spell") may also have minor passive side effects - for example, the Fire spell gem might also give the character a slight weakness to Ice and/or a slight resistance to Fire. These side effects would be made clearly visible when viewing the gem's information in game, they are not secret or unknown. This can also allow for giving drawbacks to even having certain skills available, for example, a powerful attack - perhaps the Disaster spell - might have a side effect of that the character's max HP is reduced by 10% when it's equipped. And whereas if skills had similar side effects in the original, you'd either have to choose "go without Disaster" or "have this character lose 10% of their max HP permanently", due to this system if you came across an enemy you really needed that extra HP for, you can simply unequip Disaster for that fight.


I have got an alternative idea I've been thinking about though - not a huge change from the initial one, but significant nonetheless.
1. The character must always have a primary class equipped.
2. The character may equip one unleash skill (basically, limit break), which must be of their primary class.
3. The character may equip up to four skills (active or passive) that correspond to their primary class (or are neutral).
4. The character may equip up to two secondary classes.
5. For each secondary class, the character may equip up to two abilities that correspond to either it, their primary class, or are neutral.

The key differences here are that the secondary class slots cannot be reused as skill slots for characters with only one or two classes, and that the extra slots also function as an unlock bonus when you get far enough to have secondary classes available. Under such a system, there could also be a "neutral class" gem, which essentially does nothing and doesn't allow equipping any new types of skills, but does make the extra slots available (for use of primary class or neutral skills). Thus, initially, the player would have only four skill slots available, but as they progress could get six, and then eight - and around the same time, also become able to equip characters with each others' skills to some extent, while still somewhat enforcing a lean towards the character's primary class (of course, you could change that - although, there isn't really any reason why I couldn't make that one permanent, now that I think about it).

Either way - the gem gear is just a fancy way of displaying it. And the more I think about that, the more I think the fancy display is a bad idea and I should probably scratch that image (but keep the underlying system).

[namida]

WIP status screen. At the moment only some basic info is shown - I plan to expand this to show (with details) current equipment, available skills, etc, using the currently unused space.

Note the much simpler gem display, rather than that confusing gem gear stuff. Only the classes (and unleash skill) get the name display, the rest just show the color of the gem (which will generally correspond to what class it is).

Rather than having to pre-create all the different variations, the different colorations (and presence or absence of the star, which signifies an unleash skill gem) are generated on-the-fly at render time. Thanks to GPU rendering, this has virtually no performance impact over having them pre-rendered.

The way coloring works (from a user point of view I mean; internally, there's nothing enforcing this) is:
- A class gem will have a white base, and a colored top - eg, the Fighter class gem in this image.
- An unleash skill gem will (base and top) be colored like the class it corresponds to, and have the star - eg, the Swiftslice gem in this image.
- A regular skill gem will (base and top) be colored like the class it corresponds to, but not have the star - no example of this in the above image, but it'd be exactly like the Swiftslice one minus the star.
- A neutral skill gem will be completely white - eg, the unnamed white gem in this image (which if you're curious, is one that boosts HP by 5%, which is also why her HP differs in this shot compared to earlier ones).

That aside, all gauges on the status screen show the stat relative to the stat cap (9999 for HP, 999 for MP, 99 for everything else), rather than relative to the highest in the party. Since the status screen only shows one character at a time, I felt it unnessecary to adjust for highest-in-party here (whereas I felt it made a lot of sense for the main menu screen, or for that matter, for the battle screen).

Despite the lack of the gem gear graphic, the underlying rules still more or less apply. The unleash skill slot, and the four slots under the primary class gem, can only contain a skill that corresponds to the primary class (or is neutral). The two slots under each secondary class slot, can contain a skill that corresponds to that secondary class (but not the other one), the primary class, or are neutral - but they can only be used if the respective secondary class slot has something in it (which must be a class gem of some kind; I will probably add a "neutral" class gem which fills one of these slots simply for the purpose of allowing more primary class (or neutral) gems to be equipped). You cannot equip two of the same gem. You can equip two gems that have the same effect (for example, if both the Fire and Ice skill gem had a side effect of boosting your Magic stat by 5%, you could still equip both of them as they're two different gems), but each specific effect will only be received once (so using the same example, your Magic stat would only increase by 5%, not by 10% or 11.025%). Different but similar effects can still stack - so you could get the combined effect of a gem that gives HP+5% and one that gives HP+10%; just not two that both give HP+5%. (I suspect most cases where gems give identical effects will be variants of each other anyway, such as this example of Fire and Ice).

The whole idea behind these tighter restrictions is that you can no longer head into battle with every skill you've obtained at your disposal - you must think about which ones you want to have for the battle (or area, when preparing for regular encounters) in question. Equipment will remain possible to change in-battle, but gems will only be possible to change outside of battle. With that being said, I plan to make the effects of equipment much less significant; major boosts will come from gems, which mean that in order to gain their benefits, you must sacrifice a skill in its place. And given the lack of any levelling system outside the effects that gems and equipment (and on a temporary basis, status effects) can give you, this can result in some tough decisions - for example, you're preparing Harley for a boss fight; you've decided you absolutely *need* a curative spell, a status heal spell and a revive spell. What's more important for that last slot (we'll just assume he only has access to the four main ones at this point) - boosting his HP by 20%, or also giving him the Haste spell?



EDIT: I have since added displays for current equipment - it shows not only the name of the equipment, but also the traits of it - as well a list of skills, and a list of passive abilities (whether they come from equipment or from gems, or potentially, are inherent to the character - not sure if characters will use the inherent passive abilities feature, it's more intended for enemies, but characters have support for it too just in case).

There's room for up to 10 skills (probably more than a character will ever actually have, given only 9 slots that can actually equip a skill - but there isn't anything that rules out one gem granting more than one skill), and up to 23 passive abilities, to be displayed. Each piece of equipment can have up to four effects, and as the presence of "(empty slot)" under them suggests, I'm at least considering making it possible to some extent to customize the equipment.

Also notice how the weapon effect is described as "Physical Damage+5%". This is part of trying to make ability descriptions more accurate - this is the actual effect of what was described in the original version as "Strength+5%" (it didn't actually affect the Strength stat at all, but increased physical damage directly by 5%). Whereas an ability described as "Strength+5%" (which already also exists) would actually have the effect of raising the Strength stat by 5% of its previous value. The two do not have exactly the same impact on damage, especially taking into account the possibility of skills which do physical damage but aren't affected by the Strength stat (for example, perhaps an attack that does damage equal to 50% of the enemy's HP regardless of user's strength; Strength+5% wouldn't affect this, but Physical Damage+5% would mean it now does damage equal to 52.5% of the enemy's HP).

On a side note, you can also switch quickly between characters rather than having to exit out and go back in, by using Z / X on the keyboard, or the left and right shoulder buttons on a controller. There's no support for doing so with mouse input as of yet (for the record, touch input on mobile devices works identically to mouse input on desktop devices).

I'm not sure off-hand what I'll use the remaining area for. Maybe some of it can go to useless but interesting stats like number of enemies killed. Any suggestions are welcome, though.

[namida]

So, I realised I haven't posted updates in a while on this.

Just so you know, the remake attempt definitely isn't abandoned. I just don't have anything new to show, because everything I've been working on in the last few weeks for it is very behind-the-scenes stuff. Specifically, I've split the engine code into two seperate parts - a core package, which contains any code from it that would be useful in general for games; and the rest, code that's specific to this game itself. The main reason, of course, being so that I can re-use the code for other projects - none in mind at this stage, but I'd like to have the really "core" stuff available as a package if/when I do.

That aside, I've also been working on implementing a kind of script interpreter. This would be to handle events, and possibly enemy AI scripts. While initially my intent was to just write actual code and compile it into the EXE, I soon realised that while this works fine for enemy AI, it wouldn't work so well for events - because the code that they run needs to be possible to pause and resume (say for example, if it comes across a "show message box" - it then needs to halt execution until the player closes that message box, then resume from where it left off, which would be quite hard to do the way I originally had in mind). This is coming along quite nicely - although I've yet to actually test it, code's in place that should work for all the basic stuff (conditional branching, looping, managing boolean / numeric variables (haven't implemented support for string ones yet)). Yes, I could grab an existing one or use something like Lua, but there's two issues there - firstly, I hate working with (other people's) premade libraries and avoid it as much as possible (the remake still uses a grand total of one such library that isn't either part of FPC's or Lazarus's standard runtime libraries, or my own); and secondly, I also tend to find most existing scripting languages are awful. (And a distant third - I find doing these kind of challenging tasks fun.)

[namida]

Forgot to update the download link here when I migrated to OneDrive. It's fixed now.

[ccexplore]

Slightly out of topic but, what prompted the migration from Dropbox (IIRC) to OneDrive?  More free storage (though I thought Google Drive had more?)?

[namida]

Slightly out of topic but, what prompted the migration from Dropbox (IIRC) to OneDrive?  More free storage (though I thought Google Drive had more?)?

Better selective sync (Dropbox only lets you choose on the level of individual folders, OneDrive lets you select by individual files; and non-synced files still show up in Windows Explorer and are downloaded on-demand), better price for the 1TB plan ($70/yr on OneDrive, $100/yr on DropBox or Google Drive), can backup multiple folders (Google Drive has this one too, though), free copy of MS Office included (I prefer LibreOffice anyway, but it's useful for the occasional file that LibreOffice doesn't handle properly).

The biggest one was the price though.

Another reason for ruling out Google Drive is the fact that I use it at work; and I do a lot of work stuff on my personal machine. Not using the same provider helps reduce risk of putting something on the wrong account (similarly, I use different browsers for each, too - Firefox for personal stuff, Chrome for work stuff).

[namida]

I still hope to eventually, someday, remake this project in better quality. While I'd follow the original for the most part, this is about a culled plot thread that I really do want to work back in, so spoiler tagged just in case.

About the culled "side area" from Sysona forest, in some of the early demos

The intent was that this would lead to some kind of jail (or worse) for those who were seen as a threat to Sysona. The original intent was that it would turn out Tara and Leanna ultimately came from here - hence why their ultimate weapons are in Sysona. This was where the boss fight against Mia was originally going to take place - not that she was herself in on it, but rather, as was hinted at in Sysona's history, this was historically used as described as above, and while Mia had stopped ongoing use, she hadn't done anything about historical cases - perhaps even having killed them off herself (this line wasn't fully figured out, so some details were still undecided). Thus, it would have resulted in a 2-on-1 fight Tara/Leanna vs Mia, with the second ultimate weapon becoming available after this fight.

I do hope to remake this game with better qualtiy someday, even though realistically it's probably not going to happen (I just don't have the dedication, nor the skill to really get the graphics / music to a level I'm happy with). If I do, this thread will likely be worked back in - as part of the main story, not just a sidequest.

The only hint of this thread that ever existed was, in the early versions with debug menu, the Mia fight was accessible via debug menu, and played a sad music (the same one used in much of Alicia's flashback) instead of the generic boss music - the intent was that this music would play in the cutscene around the fight, and continue throughout the fight itself. It would also have been a fight where you didn't have the full party, instead with only Tara and Leanna participating.

As those who've played the game will note, in the final product, this side area doesn't exist, and the fight against Mia is pretty much a "fight me for the fun of it" thing that she challenges you to, with her being almost unambiguously a "good guy". The intent was never to make her a villian per se, but more someone who was really conflicted between covering up Sysona's nasty past vs doing the best she can in the present.