Well, Futch-and-Bright. The ship dealer was still borked. I had a bad feeling this morning, and checked the code. I was certainly going through the motions to reapply the commands to be enabled/disabled when you switch actors, but, never actually applied the flag properly.
Fixed!
Small update to both the full version and demo version. The price that the NPC on Temou wasn’t being subtracted properly, and the process that determined difficulty in regards to militia was looking at an incorrect variable. Also, a spelling correction for the “Main Consource” (now “Main Concourse”) map.
Yes, I did look at, and test, both the demo and full versions to see if both had these issues.
*Edit: Ooops! The ship dealer wasn’t quite updating the command list properly after switching actors. To be fair, I don’t know if anybody would bother with this feature, but, the option is there.
Fixed!
So, by fixing the NPC on Tenmou for the demo, I kinda also broke it? That NPC shares a placement with the stand-in for the story advancement, and was the actual NPC from the full game. Which is to say that I lazily copied over the map data wholesale. I went back to fix that, and re-uploaded.
How much of that matters when the full game is out? Who knows, but, it’s better to be cautious.
Small update that includes the minor touch-ups mentioned previously, as well as a revision of equipment also previously mentioned, and their costs. The number of missions needed to move the difficulty level has also increased slightly because of this, and the NPC on Tenmou has been summarily revised.
Aside from possible bug fixes or grammar issues that I don’t currently know about, I’m pretty happy with the way the game plays. I’m not exactly sure at this moment how many events will be in the game, but, it is still my aim to allow players to have full control of when (if at all) they will be triggered.
I’ve sometimes had the idea of putting in some additional Extra equipment to bring up stats a bit more. For what it’s worth, my latest test plays where I was on par with the difficulty saw quite a lot of misses, or maybe it felt that way? Either way, there are definitely stats that don’t increase as much as others (accuracy being one of them) and, perhaps, having additional options to increase those values (or increase the values that are already high) might be worth a player’s while.
I also noticed some minor things to fix during those plays as well. So, if this idea does get pushed into the game, and the download gets updated, those would be patched up.
So, I did a bit of math regarding the approximate average number of credits a mission might reward versus what kind of ship (and outfits) a player might have. A Starfighter with tier 2 equipment took approximately 3 missions to obtain. A Galaxy with teir 3 equipment took approximately 7 missions to obtain. A Centurion with teir 4 equipment took about 14 missions.
To say the least, this is a far cry from the “10 missions per difficulty bump” that I haphazardly put into the game! That, and the NPC on Tenmou that offered to take 5000 credits off the player to decrease the number of missions completed by 10 was also way too cheap.
Which is a rather long-winded way of saying: I’ve updated the demo so that the number of missions completed before difficulty starts adjusting has gone down quite a bit. The NPC on Tenmou now costs 6000 credits, but the player has the option to adjust the difficulty with this method up or down.
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.