LMPGAMES'S PROFILE

Software engineer by day, game developer by night. Yo! Welcome to my profile. While you are here, check out the games I have added to RMN or hope over to my website to find everything I am working on at the moment.

Major Active Projects:
Legend of Emilar (RPG Maker MV)
Odyssian Void (Unreal Engine)

On Hold:
Combine Insurrection (Source)

Search

Filter

Game Mechanics Part 5

author=TrashCanEnthusiast
Are there any more details on the Anima system? Will we be able to tell what our values are during situations where dialog will be changed by the system? Like an on-screen window or something?

What are your plans for the Day/Night system outside of what you have stated, if any?


That is an interesting idea for the Anima system; one I had not considered. My initial plan was to have a value added to the dialog options and then color that based on the anima stat it was tied to and enable or disable if usable. But if I move the value out to a UI element instead it might allow for more flexibility.

Hmm, I will have to think on that.

Day/Night system is what is described in the blog. No plans to expand it past that.

Game Mechanics Part 4

author=TrashCanEnthusiast
I like how much you are putting into the Grand Classes. Since they are supposed to be hard to unlock, making them worth that time is necessary. Are we going to learn about any more Grand Classes in these blogs or is that something that will be revealed in later types of posts?

Also you mentioned a bit in the latest post how non-magic and magic mixed compound classes are going to work for that Lancer/Mage class. Are we going to be given information on all of the Compound Classes like that to get an idea of the total landscape of class choices and their perks?

Finally, how are the No Item and Boss Rush modes going to work?


Eventually I will be posting up class breakdowns as part of the page information for the game. That will be later, closer to release. Part of the reason for that delay is I still don't have a lot of the classes locked down so by then I should (better have, or else we are going to have problems lol). That applies to both the Grand and Compound class questions.


Aside from what I stated in the blog, here is some further information:

No Items
The Item option will be removed from the battle menu entirely. Healing items are basically going to be removed from the game writ large. Not sure how to accomplish that just yet outside of a lot of conditional eventing.

Thinking about making Inns more expensive as well. The idea behind this mode is to focus you on making sound tactical decisions on your magic usage. When a portion of your magic has to be sequestered for healing, how does that impact your game plan going into fights, especially boss fights.

Along side the other systems, I think this mode will be a real challenge to veteran players.


Boss Rush:
I think what I am going to do is build out a few maps for this mode where you move between them, fighting the bosses. You won't fight a boss that you have not fought before. This applies to all of your playthroughs, so the tracking has to be done outside of save files.

I think there will be circuits. One for just normal bosses, one with normal and optional bosses, and then a final one with all bosses including supers.

At the start of each fight you will be given the chance to respec your party. I am leaning towards allowing full access to all of the characters you have encountered, and letting you set up classes and magic the way you want.

There may be an additional set of circuits where you build up your characters over each fight with resources you get. A Survival kind of boss rush mode if you will.

Game Mechanics Part 12

author=Crystalgate
The formula seems unnecessarily complicated.
Math.floor((2 * a.level) + (a.atk + (a.atk * 0.50)) - (b.def + (b.def * 0.35))) can be rewritten as;
Math.floor((2 * a.level) + (a.atk * 1.5) - (b.def * 1.35)) and it should have the same effect.

Also, how does this formula prevent 0 damage? Your text implies that the level times two part of the formula is a minimum guaranteed damage, but I don't see it. Once an enemy has a defense greater than 1.111... times the attacker's attack, the defense of the enemy will reduce the damage to less than level times two. In order for your formula to have its minimum damage, you have to give the (a.atk + (a.atk * 0.50)) - (b.def + (b.def * 0.35)) part of the equation a minimum of zero.

Mind you, I don't think your formula is bad, but I don't see how it does what you implies it does.

First, thanks for the refactorization. I have been working at shortening the formulas and this never occurred to me for some reason; literally had a "omfg what am I doing" moment lol. Makes complete sense now that I am looking at it though.

As for your question, you do have a point. The formulas, as written, don't actually prevent every instance of invalid damage. They do cover most though. I have done extensive static testing outside of the engine on the way I have them formatted, enemy defense values would need to be fairly unbalanced to reduce the damage to 0 in most intended cases.

YanFly's Armor Scaling plugin does a lot of work as well to balance out enemy vs player stats in damage calculations.

The only edge case that will probably happen that I am not handling right now is when you have a low level character fighting against a higher level enemy, one that is high enough to have unbalanced stats; probably would only happen against super bosses and maybe some end-game bosses.

The enemy level system should handle some of that, if you have a low level character it will pull down the average party level which will impact enemy stats somewhat.

There is also a system coming up I will be discussing on how lower level characters will be handled. Long story short, if you have a character that is drastically lower leveled than the average party level, either because it's a new class or a new character you just recruited, they will get a mild exp boost to get them leveled up closer to where they need to be if you enable it.

All of that said, there could still be situations where this will be a problem and I have a contingency plan ready to be put into place if it needs to be; a small plugin to deal with invalid damage totals. I don't want to use it if I don't need to, but if all else fails I will.

It's either that or adding some code to each skill through YanFly's skill core to do it, which I would rather not as it would have to be on each skill and maintaining that would be a pain when the game will have around a minimum of 700 player character skills once everything is said and done if I have calculated things correctly.

Good callouts though, it's always good to get challenged on your designs so that you have to think about the reasoning behind them and defend those choices or find that yeah, changes are needed.

Game Mechanics Part 10

author=Prajna
First of all, the game looks very promising and I will keep an eye on the development process until the release.

The reason for my post is how you intend to handle the save mechanic. From my point of view, there isn't any reason not to let the player save anywhere in this kind of game (which is obviously supposed to be a JRPG instead of a hardcore ironman mode Rogue-like game). Being able to save anywhere always saves time (even compared to auto-saves) when something goes wrong, and it makes players more comfortable. They might even hunt for bugs, which they won't do without being able to save anywhere. Finally, if you don't allow manual saves everywhere, you will lose potential players, whereas I've never heard of players not playing a game because they would be allowed to save whenever and whereever they wanted.

Furthermore, there's a - not so obvious - reason why I hate auto-saves. As a save-scummer, I already spend way too much time in save menus, so it's important to me that saving the game doesn't take long. Usually, that's the case thanks to the save menu defaulting to the latest save file entry, but with auto-saves being implemented and active, the save menu defaults to the auto-saves most of the time, forcing me to manually scroll and check the latest manual save file entry (or constantly memorize it in advance). Of course, provided you won't allow players to save inside dungeons, an auto-save feature is better than not being able to save at all; still, for the reasons stated above, I prefer being able to save anywhere without being annoyed by auto-saves.

I don't know if my rant will make you change your mind - it's still your game and your design choice, of course -, but I wanted to provide some food for thought. Ultimately, the way saving is handled won't be a dealbreaker for me. If you really want to make sure that I won't play your game, implement features like day/night cycle or other direct/indirect time pressure elements, equipment durability, lots of permanently missable stuff, level-scaling and/or a low level cap. ;)


Yo, thanks for the reply! I have to be real with you, the game has some of those things. Let me address auto-saves first.

There will be an option to disable them entirely and allow you to save at any point you would like. It will also disable the save points in-game and any story/dialog related to them.

This is true of many of the systems in the game. I don't know exactly what will be optional and what won't, but if I have plans to add something to the options menu, I have been mentioning it throughout these game mechanics blogs.

Now for the rest.

There will be a day/night system though it is based on pacing in the story and isn't a real-time system. Some NPCs only come out at night and some of those give you side quests. None of the main quests nor major events require you to do them at a certain time of day.

The only other thing tied to it is that some monsters are nocturnal, they are mostly normal monsters though and for anything more specialized it's tied to a quest that puts you into night mode at the start of it.

Anything you could obtain from a night mode NPC can be gotten later; these quests just allow you to get certain things earlier.

There are no timed elements in the game other than the Lantern. One of my biggest gripes in Tales of Symphonia was that major plot points were locked behind missable events that you could only see if you followed a certain quest order.

None of that in the game. There may be times though that certain areas are inaccessible for a limited amount of time due to story reasons.

Certain equipment will have a durability system; this will be able to be disabled from the options menu. The system isn't something I have covered in these yet, but here is how it works.

Each attack used in battle removes a point. Once the durability reaches 0 the weapon damage output is reduced to 25%. Durability is upgrades with levels and refinements. Certain weapons, when synthesized with a weapon with durability, can remove durability from it entirely.

Nothing in the game is permanently missable so far; I can't promise things will stay that way, but I also would like to try and minimize the possibility of it happening. The only way I see this happening is if you are unable to unlock a story branch path because you don't meet the Anima System requirements to do so.

The Anima System is something we covered in Game Mechanics Part 5: https://rpgmaker.net/games/12774/blog/25313/

Even then, those branching paths should not lock off areas of the game, just the story elements related to those paths. Any items you and places you would otherwise go during those paths should generally be accessible at some point in the game.

There will be level-scaling on enemies. Most enemies have a max level cap though, so eventually they will stop. Bosses have level scaling as well, but a much lower max level cap.

I talked about this system before, but not about how the levels are determined I think, so let me explain that here. Generally, for normal monsters, I want them to have a max level cap of around +10 levels of what the player would be, on average, in that area during that part of the game.

The starting maps in the game, the max enemy level cap is 25. The player should get to around level 15 on the Novice class and start leveling their first standard class by the time the Prologue is done. Enemy levels are based on your current class too, so if you slap a bunch of new classes onto your party, you shouldn't get punished for it.

All non-boss enemies will be designed to be fightable with low level characters and then the level system brings them up to your average level. Enemy levels are based on your party's average level, so if you slap a bunch of new classes onto your party you shouldn't get punished for it.

For bosses, the scaling is +5 of the level you would normally be by that point. The first major boss in the game has a max level cap of 20. This means that if you're party is level 25 average, you are 5 levels above the boss.

The level cap for the game is 125 and all classes can and will have to reach that if you intend to unlock the Grand Classes. We covered the class system in the Game Mechanics 4 blog: https://rpgmaker.net/games/12774/blog/25286/

Whew, sorry for the wall of text. I wanted to address each one of the systems you listed because some of them are present in some form or another in LoE.

Game Mechanics Part 1

Yo, sorry the next post is taking so long to finish! Work has been a real pain this week and one of the mechanics we will be discussing (the Codex) is a massive system with lots to talk about.

Getting all of that information straight, readable, and the gifs and images to go along with it is taking a while. I will release post 2 and 3 together in one to make up for the delay and then attempt to stick to the weekly schedule there after.

But please note that for large systems, a delay in posting might occur. That said, the Codex is the largest system I have at the moment. The only other one that might be close is the Advanced Weapon Plugin and we won't be talking about that for a while yet.
Pages: first prev 123 last