Side-view has been in here for a while, hasn’t it? Hasn’t… it? nervous laugh
Anyway, I’ve just completed a test-run all the way through the end of the game that ran me a little over two hours. I was kinda still building/editing the game as I ran it, though, so, I should do at least one more run only editing to squash whatever bugs I might find. Then, I might do a blog on both sites as I slap the “complete” tag on this after uploading the build.
Small update, here, but, I think it’s worth a post. A certain event has given me a bit of a boost to the production of this game! Rather than dragging my feet, I’ve been chipping away at the project, doing a little bit each day. A map here, some creature configuration there, some event implementation, stuff like that.
I want to stave off playtesting for a bit longer, but, there’s quite a few events to still implement, as well as putting together the new encounters. If my pace keeps up, this might not take as long as I originally thought. Regardless of how long things take, I suspect the next update will be for the full release!
I’ve still a few scenes to write out, but, I felt I could, at least, draw the maps in the editor. If the time is right, and the moons are in alignment, I could see a full release by the end of February. Maybe early March. That’s including playtesting, and any possible revisions that could come from that.
Even with the holidays (largely) out of the way, I’m finding it rather difficult to find/make time to work on this game. By all accounts, there shouldn’t be much left to work on, but, it’s effectively become a case of “I open RPG Maker, stare at it for maybe five minutes, then close it” deals.
A part of me is considering uploading what I have so far to see what, if any, responses such a build will garner. Another part believes that, despite the current slump, I can overcome it. Maybe I won’t release what I had originally envisioned for this game, but, what will be released should be a close/good enough approximation to that vision.
As something of an addendum that I forgot to mention that may be of interest is a revision on the Encompassing Rune. It didn’t feel quite right for it to be missing out on the status removal spells. For what it is worth, those were part of the “healing” package that the simpler healing-type runes typically taught.
The price was moved to 5000. This was done mostly as a point of comparison to the Angel Rune. Even if the Encompassing Rune didn’t include the status removal spells, the two Runes granted a very similar set of spells.
You know, in a certain way, I kinda wish Eiyuden Chronicle: Hundred Heroes did what I’m doing here with the spell Runes? Maybe not the whole “characters have exactly two slots” thing, but the way Runes progressed as they “leveled”? I dunno, my memory is probably off, as it’s been maybe a year or two since I’ve played it. However, I seem to recall a level 2 Rune only having level 2 spells? I can’t recall if I ever had a level 3 Rune, but, I’ll cut off the Eiyuden Rune-related rant here.
Bit of an update on this. The in-game implementations are up to the point where the party consists of everyone except Sue! There was at least one attempt of a “low-level” run in regards to playtesting, and I think it might be possible to get to that point as low as the mid 30’s? Having 40 max ECN (achievable when your party’s average level is 31) certainly helps in cancelling the larger encounter costs in the right-most maps, which is where Camp Kupva and Ferdil lie. Player’s won’t “need” to access Huil Wood or Bisha Palace for this type of run, but, having access to the best weapons and armor that Bisha Palace provides can be a benefit.
That aside, the game will eventually ask players to visit Huil Wood, and lands beyond that of the map grid the game’s established for them so far. It’s possible the “low-level” run up to when Sue joins can be as low as 41 (when players achieve 50 max ECN), but, I can’t say for sure until the game actually gets there.
Of course, the writing has to get there too, but, I did promise myself a bit of a breather/break. With the holidays right coming up soon, it might be until early January that I even start that? We’ll see!
There may not be an RMN, but, fellow user lavandersiren has volunteered to host a poll for nominations for this year. You can find the nomination form here.
Now, I’ve not been much on the whole social media thing, so, I know my chances of being nominated, much less win anything, is slim-to-none. However, even if you don’t nominate/vote for this game (and I would be lying if I said I didn’t want that at all), please participate!
Don’t walk! RUN to the Misaos!
As I write various scenes for the game, the idea of there being a subfaction within the Sisters of Hope might not fit the way the story is panning out. I don’t necessarily mind cutting a faction, as it should make things a bit easier on my end.
That said, with the rate I’m going, it might still take a while for the writing to be complete. Once that is done, I can move to implementation and testing. I don’t want to give a hard deadline here, but, if I can do a full release by February or March, I’d be happy!
The rounds of playtesting complete, I move back to story events. I had a few scenes written before hand, and I’ve already made a few revisions. That said, moving the story forward will be my focus in the upcoming month.
As the story progresses, and the playable roster reaches to that relayed in the demo, there will likely be additional rounds of playtesting. While my latest rounds of playtesting only included four playable characters, it might be interesting to see how the bounty fights fare with more characters/options available. It might also be interesting to see how low a level a player might be able to get away with, but, with the modifications to the ECN cost of the higher-level enemies, a low level challenge run might not be as possible as it may have been?
Map-making is done (for now), so a round (or two) of playtesting of what’s available is on the plate before more story-events go in.
I’ve been thinking about the ECN meter as well. It’s one thing for encounters in areas accessible in the demo to be cancelled with no cost whatsoever. If a player grinds bounties, they can probably cancel tier 2 enemies without cost at some point. Teir 3 enemies? Well, I suppose it could be possible for a player to grind bounties enough to be able to cancel those without cost eventually!
However, I’m not sure if the level of the enemy, by itself, is enough of an indicator as to the cost of cancellation. The idea in my head is to allow a note-tag that can be read to act as a cost. Level can still be used, but, if the note-tag is there, that would take priority.
The question would then become what the ECN of those harder enemies should be so that it would still feel “fair”? Though, what “fair” might mean can be tricky, onto itself. An ECN cost of 5 might be significant in the beginning of the game. However, as the party gains levels, and raises their max ECN, that cost might not be as significant?
To wit, the maximum the ECN gauge can possibly go is 50. The party’s maximum level, at least in the context of this game, is also 50. In this most extreme case, let’s say the level of this enemy is 50, or that custom cost variable is 50. The cost, in either case, would return as a “1”. This might make mathematical sense, but, you know, it should probably be a lot, lot higher? Like, maybe that would be a “5”, I dunno, I’m just pulling numbers out of my head.
Still in the middle of making maps, but, given that said task is the one I enjoy least in game development, perhaps this is non-news. The number of maps left to make is still dwindling, so, there is a light at the end of that tunnel. I have a few concerns about what Ferdil might look like, as the town wouldn’t necessarily be in ruins, but, it shouldn’t be in pristine condition either.
On another minor note, I may change the name of the Seeker Rune to the Hunter Rune, as something of a nod to the game’s Suikoden inspiration. This change would be so minor that I wouldn’t bother uploading a new demo to reflect this change, if that was the only change to be had.
I wouldn’t call it sufficient news, but, it’s been a while, and I want to write something as to alleviate any thoughts of this project dying. If that is, in fact, a consideration.
That aside, the game has seen three over world maps, two dungeons, with one in progress. Once I fill out the “tier 2” areas (which might be in the next few weeks depending), I might switch focus to encounters in those areas, including the bounties.
The fix wasn’t as bad as I thought, but, there were certainly headaches to be had before said fix was found.
So, what was happening was in the BattleManager.endBattlerActions function. If a character is using a unite skill, there is a a variable inside BattleManager.processTurn to remember the skill.
// Process when an actor finishes their action.
BattleManager.processTurn = function() {
const subject = this._subject;
const action = subject.currentAction();
if (action) {
action.prepare();
if (action.isValid()) {
this.startAction();
if (subject.isUnite()) {
subject.setActionStateUnite("acting");
// The action would be removed from the stack below, but, we still need it for a bit longer.
this.unite = action;
};
};
subject.removeCurrentAction();
} else {
this.endAction();
this._subject = null;
}
};
Since the action is removed from the action queue, my thought was to use the endBattlerActions function to put it back on the queue, even temporarily, and set the involved characters to the “done” state/motion.
// Process when an actor finishes their turn.
BattleManager.endBattlerActions = function(battler) {
// Hey, was there a Unite skill stored earlier?
if (this.unite) {
// Cool. Put it back onto the current actor's queue.
battler._actions.push(unite);
// Have everyone involved get an action state of "done".
// I'm not concerned about the value of `this.isTpd()`, so...
battler.setActionStateUnite("done");
// Remove the action again.
battler.removeCurrentAction();
// Forget this ever happened.
this.unite = undefined;
} else {
// Regular processing.
battler.setActionState(this.isTpb() ? "undecided" : "done");
};
battler.onAllActionsEnd();
battler.clearTpbChargeTime();
this.displayBattlerStatus(battler, true);
};
One problem with this. The line that would put the skill on the stack?
battler._actions.push(unite);
That line puts an entirely different thing in there than what this.unite would put in there.
// Base unite damage formula, replacing "a.atk", "a.mat", or possibly both.
function unite(skill_id, mode=undefined) {
let array = uniteArray(skill_id);
let total = 0;
switch (mode) {
case "physical":
for (let i=0; i<array.length; i++) {
total += $gameActors.actor(array[i]).atk;
};
return total;
case "magical":
for (let i=0; i<array.length; i++) {
total += $gameActors.actor(array[i]).mat;
};
return total;
default:
for (let i=0; i<array.length; i++) {
total += $gameActors.actor(array[i]).atk;
total += $gameActors.actor(array[i]).mat;
};
return total;
};
};
So, while the correct motion/state may be being passed, the check to see if the involved characters would fail, because the return value for the unite function would be undefined in the context it was given.
Suffice it to say, I’ve updated the demo again (again again again again) with this fixed.
While trying to move forward with the full version, I did various rounds of playtesting. In so doing, I noticed something peculiar about Unites. The specific case was Richard (involved via Best Friends (Richard/Lester) or Bounty Hunters (Richard/Jodelle)), was the target of a First Aid from Janice. Now, the intent is that once a Unite is done, the involved characters step back into formation, like any other skill, or ability, out there. However, in certain observed cases, the characters were still in their “stepped forward” position when another character stepped forward, and activated their action. Then, once that action was done, all of the characters stepped back into formation.
At this juncture, I cannot say for certain how consistent this bug is. Aside from the above scenario, I’ve seen instances of one of the bounty monsters targeting an in-Unite Richard, and the characters wouldn’t step back until after Janice’s First Aid, which appeared to be the last skill on the queue in that scenario.
There’s instances where things appear to work as intended as well. I wasn’t paying attention to see if the target in such instances was a character other than the character who put the Unite skill into the queue. I also am considering that it could also stem from how I got all characters involved in a Unite to step forward to begin with. For the moment, I’m largely scratching my head about what the heck is going on, or what kinds of workarounds might need to happen.
The easiest solution would be to increase the speed penalty on Unite skills, and don’t mess with things further. Though, if I go that route, I would be inclined to increase the damage multiplier for Unites, as the risk for the skill to be cancelled becomes greater.
I’m taking the lack of comments in the past fortnight (I absolutely mean to use this term) on the “Demo Available” blog as a “go ahead” signal for the full version. I’ll make a different blog when there is sufficient news, or other notes, to speak about in regards to the game’s progression. Thanks in advance for your patience!
If it was just a spelling update, maybe one could use an old-version save file, and things would be fine. However, with an update like this, it was probably best to start from scratch. Though, I do find it somewhat interesting to know that there’s a missing file report when one attempts to load an old-version save into this version, despite said files existing? I could see the actor graphics in battle simply not showing up, as they weren’t defined in the database before, and, the save data might indicate that there wouldn’t be graphics to begin with.
From what I understand, $dataActors would store whatever is written in the database. However, since actor graphics can change mid-game, there’s probably a function/variable within $gameActors to allow for graphics to be applied to the actor, and would be in the save data.
EDIT
Anyway, from what I can tell, the issue seems to be stemming from loading an old-version save into the new version? So, I’m going to stop worrying about it, and focus my energies elsewhere. I’ll hold back on updating the game for a little while longer, in case more spelling, text display, or other error, pops up.
That is definitely not a known issue! Attempts to replicate it have failed so far, so, I wonder if I forget to associate/include the side-view graphics for the characters before uploading? I’ll be double-checking that (putting me in the awkward position of downloading my own game), as well as additional attempts at replication.
If nothing else, I found an error with “Rivals” in regards to it’s text display in combat. It was displaying…
Nari and Sue unite!
$2!
…when it should be displaying…
Nari and Sue unite!
Rivalry!
…this.
So, one might recall a comment I made in the “Today’s musings” devlog about getting Unites to work with the default side-view combat engine in MZ? I have done exactly that. Consider the demo updated!
I suppose I could have staved off this coding until another game, but, I guess I wanted to test myself just a bit further in this iteration of the Unite mechanic. I refuse to consider going the route of Chrono Trigger, and including ATB mechanics. Just. No. Sorry.
Every so often, I consider how I might implement Unites with a side-view combat system. The fact that MZ comes with a side-view system is certainly a load off my shoulders, but, I’m not, exactly, sure how one might go about inducing an animation for said system.
There’s also the small detail about not having/making side-view sprites for these characters, but, that might be the least of the potential issues of making the unite code more complex than it already is!
It’s sorta funny how even without any weapons, a person can still use Unite. Was checking out the Unites, which is hard because I gotta keep switching members around, but a weaponless Roxanne can still be part of Snipers without a bow! heh
It’s certainly possible, and maybe not particularly flavorful with not just “Snipers” (see also: “Brothers of the Blade” and “Sisters of the Spear”). However, weapons are where a character’s damage base lies, and without them, well, I guess you saw for yourself?
Possible Unites is wrong if it’s supposed to account for empty spaces, because no way I can do Sisters of Hope with only one empty slot while the other five are: Sue, Nari, Richard, Lester and Massaki? Where would Janice and Roxanne go? Heh.
The “Possible Unites” display does not account for empty spaces, nor do I want it to. It’s there as a player aid, and I consider it a quality of life component for this game. It’s there to let players know what Unites exist with any given character in the party, even if the characters in question aren’t even available yet! Like, I would have loved to have seen something like this in the party switch scenes in Suikoden games, and Eiyuden Chronicle Hundred Heroes. This is the angle I’m coming from on this decision/window. If I recall, there might have been Unite information in Suikoden 3 (maybe 4 and 5 as well?), but, that was only after the involved characters were already in the party.
Only inconsistency is how most runes say “imbues grandmaster X” but Elementalist, Angel, Devil, and Omniscience all say “at grandmaster level”.
The other way might work for the Elementalist, Angel, and Devil Runes. As for the Omnisciense Rune, I don’t know. Maybe it’s just me, but, “Imbues all grandmaster spells” doesn’t quite have the same feel/effect as “Imbues all spells at grandmaster level”? I’m largely willing for those Runes to stay as they are, description-wise, if I must be honest.
When selecting the Skill option in the status screen, the character initially selected seems to be memorized as “last character you saw the skills of”, which makes the screen scroll immediately if they’re not on screen? Intentional?
So, this effect might be because of a variable (menuActor?) stored by the game in some way (within $gameParty?) that I haven’t done anything to. I’m going off sheer memory with this information, but, I might consider looking into it.
And the “Chamkaq” only seems useful as a Vagrant Story ref, not a real world type of axe?
I fully admit to referring to Vagrant Story with a lot of the equipment in this game. I doubt I will be changing those, even if I probably should.
As an aside, I keep trying to delay releases in the case there’s more spelling corrections to be had, but, weeeeellll… yeah. Best laid plans, and all that.
EDIT
So, if there’s been any area expansion, I haven’t found it, just tried to leave Cevik Heights then turned back to check the spells.
Map expansion wasn’t a consideration for the demo. I had thought this point was covered somewhere on this gamepage, but, maybe not?
The spelling corrections pointed out by Milandy have been attended to. Thanks again for the umpteenth time! A proper update to the demo version may come later.
Though, saying that, I fully admit to stalling on moving beyond the context of the demo until I get a release of the demo version that doesn’t have such issues. However, moving forward is something I have been giving a bit more consideration to. To this end, I’ve been working towards at least writing out some scenes dialogs for the game. The idea being that, once all the scenes are done and to my satisfaction, I move to mapping the rest of the game, filling in whatever events the game needs to be filled with.
Demo updated! Typos pointed out by Malandy have been corrected. I’ve also revised a number of chests in regards to manipulation of ECN. The intent is to use visual cues to inform the player as to how a chest might interact with ECN, outside of standard event encounter cancellation. The precise balance and frequency of such chests are still in consideration.
I’m not sure how ECN limit increases, and not sure there’s anywhere left for me to poke around…
I had to double-check this myself, and it should occur around level 11. Which would be able to cancel most, if not all, regular encounters in the context of the demo.
Final Fantasy ref: Esnua > Esuna [?]
Nothing against the other spelling corrections (or any other corrections that might come down the pipe), but, I gave this idea/reference another think. I might replace it with either a different reference, or, a more generic name of “Remedy”, or something.
Demo updated! Again!
Attempting to add a character into any empty slot will move the cursor to the last available position. This includes when the party size is less than the maximum that is possible.
I’ve also looked into the font size discrepancy when it comes to using skills, or items, outside of combat. The font size seems to vary somewhat from class to class, but, at least the relative size adjusts according to the maximum number of party members.
There is additional handling for hidden/inactive characters. What this ultimately means is that inactive characters can use skills, and be the target of items and/or skills outside of combat. They also would not be considered targets in combat.
Thanks again to Malandy for the bug reports, and spelling errors!
Potion weirdness: On the screen to select who to use a potion on, it has big text, but then after using the potion on someone, the text shrinks down to what it’s like in the main status menu?
I’ve noticed this, and in other contexts, such as using skills. As far as I can tell (or am aware), those menus should be using the same window classes as the main party menu. Which should mean the font/line heights should be based on how big the active party can be. Clearly, something is up with the timing, or something, because the window does, eventually, fix itself. I’m just not 100% sure why it’s not displaying as it should to begin with!
From testing with a Lester, Janice, Richard LV 1 party in the Quaysha Caves, it seems like: Two Crows are LV 7. Mushmen are level 3 or so? And Mosquitoes are level 8 or something. And Goblins are probably level 2.
At level 1, Quesha Caves should be between 1 (Goblins) and 7 (Mosquitos) in ECN cost. Crows should cost 5, Mushmen should cost 3.
If I have:
- Lester
- Richard
- Janice
Then try to put Lester in the empty third spot, then Lester and Janice swap to become:
- Lester
- Janice
- Richard
Which I don’t think can be predicted from how the cursor works? That’s my only issue, that the player couldn’t know that’d happen. But once it does, it’s easy to remember at least.
I was looking into this earlier today. My test party started off with Richard and Lester, then tried to put Richard in the third slot. My resulting party was…
I suppose the expected result would be…
…like so. However, what’s happening under the hood is that…
$gameParty.members()[0]
…is being swapped with…
$gameParty.members()[2]
…and having their “isHidden” values switched with them. I will concur that it working this way might be a little awkward, but, it might be something I’ll leave as-is.
Getting the active party cursor into the correct position at various max party sizes looks like a much easier solution. If things go well, I can do another update some time tomorrow, lest more bug reports (or spelling corrections) come down.
Use all three, navigate to an empty space, then try to “add” someone, and you should see “Type Error: Cannot read property ‘isHidden’ of undefined”
And here I was thinking this was another Unite bug!
Well, this is still a bug to look into, as the cursor should have re-selected whoever was in position 3 in the instance of a party that consists of exactly three members.
ALSO, making a Formation with less than everyone and trying to add someone who’s already added into an empty space will add the first inactive person into the space of the person who was selected? A.k.a: Party of Lester and Janice, with Richard inactive and trying to add Lester or Janice into the empty space, will add Richard to replace who I was trying to add?
To help me visualize things a bit, you’d have a party-list that could look like, using boldface for active characters…
…so? Something like this was certainly possible earlier in an earlier build of the system, though, I might not have accounted for adding a character already in the party to an empty active slot.
EDIT So, I looked into how inactive members are unable to be targeted, as well as their inability to use skills outside of combat. Apparently, being considered “hidden” (which is the flag I use to set members as inactive) is a condition that is checked for the “canMove” and “isAlive” functions of Game_BattlerBase. I’m not sure if removing the condition, or making it an optional condition, is the right move, as I’m not sure if those functions have some decision-making processes in regards to how enemies determine their targets.
“Cannot read property of undefined”
Under what context are you getting this error? It would be supremely helpful to know!
What controls how much ECN it takes to cancel an encounter?
Basically, it’s the incoming encounter’s average level minus the party’s average level. There is still a cost of 1 should these two values be the same, but, that’s the underlying gist. Should the party’s level be higher, the cost should be 0.
Okay, the inability to Potion inactives makes how they take damage on leveling a bit more annoying…
I’m not worried about “damage” on level-up, because of the (admittedly) corner case of a player swapping party members literally every fight. I am vaguely aware inactives can’t use their Active Rune skills, possibly due to what traits/variables have to be set to flag them as inactive. If they cannot be targeted outside of combat, my best guess is that the trait/variable that is set to make them inactive is also probably also making them unable to be targeted in the party screen(s). It might be possible to use an ability that targets all allies, and have the inactives be included in that array? I see I’ll see how true that is when I look at this again (again again again again again).
Demo updated! Hopefully, the Unite issues are out of the way this time. I’ve also replaced the Celerity Rune (increases attack speed) with the Seeker Rune (doubles item drop rates from enemies), largely due to the Celerity Rune’s interaction with Unites. I don’t know if I’ll ever look into setting Unites to be executed at the agility/speed value of the slowest character involved, but, for now, they only have an action-speed penalty to the character that put it on the stack.
Demo updated! Here’s a brief list of changes.
Aside from the spelling corrections pointed out by Malandy, some additional corrections were found in some of the Rune descriptions. It was also discovered that some Runes didn’t have the right equipment slot associated to them.
It was discovered that backing out from targeting an enemy would flag an ally as “acting” in regards to Unites. This has been fixed. Annnnnnd now that I write this, I completely forgot to look into the situation of backing out from targeting an ally.
Scrolling through characters during the party-switch screen should update their stats, regardless if you hold down the up/down key or press it once. Page Up/Page down works similarly, but only in regards to character stats. If a character is not selected, and the Possible Unites screen is being displayed, holding down Page Up or Page down will not cycle through the Unites. Testing showed that allowing that would cycle through them too quickly to be of any use.
Selecting an empty space in the party-switch screen when you don’t have another/enough characters to put in that position will re-select to the last available position that can contain a character.
The “Optimize” option in the equip screen will remove both the character’s active and support runes. You’ll have to re-equip them manually. In the full game, or if (when?) there is another update to the demo, those slots will be left alone.
BUG? “Getting the “beyond here lies” message doesn’t encounter cancel, and it follows me into the battle menu, and then says “enemy emerged” as well.
Probably not relevant unless you’re gonna use the feature outside of the demo.
Confirmed. That Common Event was proving a bit problematic to begin with, so, I’ll have to come up with a different solution that would do what I want that event do to.
BUG: Was messing in the Party Formation menu with the first three characters: Use all three, navigate to an empty space, then try to back out and got “Type Error: Cannot read property ‘isHidden’ of undefined”
Confirmed. This should mean including a handler for when the party size is less than the maximum number of slots.
BUG: Holding down when scrolling through the characters list doesn’t update the stats.
Confirmed, but technically not a bug, per say? Still, I could see this as a quality-of-life feature. I’ll look into getting this in there.
BUG: Unites should lock out overlaps, right? My party of: Lester, Massaki, Richard, Nari, Vince, and Sue can do all three of Dark Sun Bandits, Brothers of the Blade, and Returning a Favor / Rivalry?
Depends now what you mean by overlapping in this instance. That party SHOULD have those Unites as available options! For example, if you have Lester select Dark Sun Bandits, the game should go directly to Vince, skipping over Massaki, Richard, and Nari. If you choose Best Friends, it would go to Massaki instead. If you select Family Attack at that point, it should skip both Richard and Nari, and go to Vince.
And using Best Friends, Family Attack, and then selecting Golden Triangle and backing out stops Massaki from selecting any Unites anymore.
This, however, certainly IS a bug! Selecting Family Attack during Massaki’s turn should involve Nari, and therefore, consider her as unavailable for Golden Triangle! Once that bug is squashed, I can look into the other matter. I’m mostly hoping that fixing the first matter will also fix the second, but, we’ll see!
That aside, I still haven’t looked into skipping the Rune slots for Optimize, so, I’ve got my work cut out for me for a while.
Some of the things you’re listing were issues before, and it seemed like they were gone. Guess I’ll have to check those again (for the billionth time ;_;), among the other things listed. That said, here is what I can manage to answer now.
BUG? Opening a chest as the Encounter Timer hits 0 stops encounter?
Opening a chest should, in fact, perform an encounter cancel. The same is true for swapping maps, or triggering story events. Or, at least, this is the theory! I don’t know about performing an encounter cancel when the timer is at exactly 0, regardless of how the cancel is triggered. My gut tells me that it might be possible to still be able to cancel when it displays “0”, but, the window of opportunity to do so is slim?
And everyone leveling up on its only text box is taking a while.
You can fast-forwarding any in-game text message text by holding CTRL and/or ALT. This method is true across any MZ game I’ve made, more or less. Knowing this should alleviate this issue somewhat for future plays. An alternate solution would be to remove level-up messages entirely, but, I don’t exactly feel good about that alternative?
Question: Why is Optimize favoring Sue to have the Vile Rune over the more comprehensive Devil Rune?
Basically, the “Optimize” function only compares statistical differences, and doesn’t look at other traits. With weapons, the stat is attack/strength. For any other equipment, it’s defense/endurance. It would not consider skills, skill categories, or other similar traits that a piece of equipment could have. For an in-game example, it would probably favor the Warrior Rune as a Passive Rune every single time, simply because it grants a bonus to defense. If there is no difference found, then the optimization method might choose the equipment with lesser ID, as that would technically have been the initial point of comparison? Something along those lines!
I think this was an issue I addressed in Nakaishi Wars in regards to the “Programs” equipment slot. I don’t quite recall exactly how I addressed this issue in Nakaishi Wars as of this writing, but, I seem to recall something about using the equipment’s ID in the database to be the most relevant factor in deciding what program to equip? This tactic might be something to look into for this game, as Runes that have upgraded versions increase with their ID as more/better skills are available. However, it might also behoove me to remove the Rune slots from the optimize method entirely. Either of these options would mean making exceptions in the code, and I’ve doubts one method would be strictly “easier” to do than the other.
Demo updated with the spelling corrections, and Potion fix that Malandy mentioned. I’ve also altered Unites in regards to their base damage values.
It might be some time before I can more fully focus on this project, but, I can at least look into other issues that might pop up, or answer any questions about the game, if it’s not too much of a spoiler to do so.