Off-Topic Boards > Non-Lemmings Projects

namida's new RPG project

(1/8) > >>

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.

Navigation

[0] Message Index

[#] Next page