Well, here I go again.  But a bit different this time...

Yep, this is a battler being created by multiple image layers... essentially a paperdoll system for battlers.  However, this is not exactly new.  I already wrote one:  Brenda's Visual Battlers.

However, it is going through a rewrite, one where it uses techniques and has methods mirroring the content from Ah-sung's Paperdoll.  I already have the basics worked out.  But some things I have need to integrate:

• UserIDs in the EQUIP entries for custom graphics per actor
  
• 'T' flag for two-handed weapon use (MultiSlots compatibility)
  
• Possible Enemy Battler equipment (a variation of 'event' paperdolll options)
  
• Testing of changed equipment in-battle to refresh the battlers
  
• Testing of changing facing direction to refresh the battlers
  
• Testing of changing battlers (odd, yes).
  
• Facing direction flags for the ORDER_STYLE array
  

Otherwise, it has much already functional:

• Usage of the ORDER_STYLE array to dictate the order of graphics rendered, including the body
  
• Usage of the EQUIP and SUBSTITUTE entries for graphic acquisition
  

The fun part will be determining how to get a changed 'facing direction' system working. This may not seem necessary, but there are some systems where the battler changes facing direction.  Not only from an animation system standpoint, but a battler rotation standpoint.  Consider the 'Golden Sun' camera rotation system as one example.

Did some audio balancing and some bugfixes on several of the boss fights, nothing game breaking, but awkward? Definitely!

So here's all those!






Enjoy~!

Above, I have two images... though I didn't separate them with a line.  OOPS.   Well, there's two, okay?

The upper shot shows enemies facing the right, and the hero holding a sword and shield facing the left.  However, the sword and shield happens to be the gear carried and not part of the original sprite.  It is a paperdoll system after all.

The lower shot shows the battlers after I used a mirror effect upon them, a common horizontal flip effect used in most animated battle systems.  And when the hero battler's sprite is flipped, the directional facing system kicked in, and used the already existing ORDER_STYLE array to determine that way the graphics are themselves layered.

The first shot had the shield drawn last, so it was atop the sprite.  But with the ORDER_STYLE layering system, the shield was drawn first and hides behind the battler when the sprite is mirrored...  Just as it should IF your battle system can recognize the use of mirrored battlers.

So I can now confirm that equipment may change in-game during battle for the actors, and the facing direction of the battlers does affect the layering as wanted and desired. I tested to see if the UserID feature from Ah-sung's Paperdoll worked, and it was a success... no alteration was even needed. So I highly doubt any need to worry about the 'T' flag to allow for dual wielding characters. Nice, eh?

But, ahhh...

Two steps forward.... two steps back.   It appears that there will needs to be more work to make the updated Paperdoll system for battlers work with any animated battle systems.  The issue is that both systems, animation and paperdoll, refresh and renew the sprite separately when changed or updated.

If the animation system is executed first, it attempts to render the battlers, and then the paperdoll will kick in... and render with the overlain graphics without the individual frame animations  But if the paperdoll system executes first, it creates and renders the sprite only to have the animation system kick on and re-acquire the original graphic... and you go back to square one.

So, some study needs take place in order to see what can be done for a 'few' systems at least.

Eddy: Ed... why is your shield strapped to your butt!?
Ed: For protection!
Eddy: Ergh! it goes on your arm!

Is all I can think of when I see that.

So. in some Fantasia news, I want to talk about...
Disk 3: Thousandfold Namesake Kaleidoscope
This is the final portion of the game before the end game, and the final five icons will be fought with and recruited.

These are as follows:
Mad E. Lin

Zardari Zitei

Mira Crowspeaker

Esperia Frostwhisper

Fyori Felicee

Believe it or not, the twist boss is not Fyori or Esperia, they are kinda twisty, but the real twist bost is probably best given away by the acts name.

Mira and Mad E. Lin have no DENUI. Mad is the daughter of the Queen of Shadows, who is Yi's friend, so likely she never had one. Mira openly admits to entering her own mind and killing hers without regret.

Zardari has the Archangel Raphiel, Esperia the Archangel Azreal and Fyori the Archangel Jopheline (Jophiel).

the finale of this Disk will be with M.F. Lazarus, and will be only one of two main story battles prior to endgame where you can control Sacreblu as another party member and not just her second wind status.

Speaking of, I wanna talk about Sacreblu. In spoilers though for those who aren't interested.

Making a Goddess Lovable

So, not everything is set in stone yet, but here's the plans for Demo 3!

To the Sunless Expanse
A new Galaxy is unlocked where in the second and third icons of the disk are found. With Zardari being on Planet Terra and Mira being on her home world: Shale.
Rescuing Mad will unlock her optional event chain, and doing that will unlock the optional events on Zen Aneia. Same goes for Mira in regards to Shale and Noir Pinot, and Zardari for Terra.

Two suns to orbit their world.
Esperia and Fyori will respectively be at one of the colored suns. Esperia at Blue and Fyori at Pink. A fun bit of Trivia is that these two were in early concepts of the game, going to be the final antagonists, but that was scrapped because that was back before I'd had the joy of watching gravity falls which helped me really formulate the stakes for the plot.

The Goddess of Love finds her mojo!
The boss fight with Esperia is when Sacreblu gets her ENNUI empowerment, though she also gets a transformation and becomes a full time party member to cement her words in the game with gameplay changes. Esperia and Fyori already have their optional event chains implemented and can be all done in Disk 2.

Entertainment abound, gather round!
If you count the character-focused optional event chains that unlock the three new worlds, there are 55 events slated in total. 17 of these are boss fights. With one at medium Difficulty, Five at hard difficulty, eight at SURREAL difficulty, and 3 at INSANE difficulty.

Spriteopia: Eight events planned, two being boss fights.
The Queen of Shadows
Seradath: The Night Bringer (Aspect of Darkness)

The Pink Sun: Two events planned.

Dysmonia: Three events planned.

Terra: Five events planned, three of which are boss fights.
Valin Jaeger
Nikki Hirogashi
Trixie Valenthart

Archanul Minor, Major and Ultima (Terra's moons) are three events, one on Minor, then Major, with a boss fight on Ultima.
Safael: The World Shaper (Aspect of Form)

Noirpinot: Four events planned, two of which are boss fights.
King Richard
Ghosts of the Apocalypse

Shale: Six events planned, three of which are boss fights.
Dibella Crowspeaker
Bubbles: The Grim Reaper (Aspect of Death)
Xeltara: The Unholy Butcher

The Pandemonic Clock: Four events planned, two of which are boss fights.
Rykki: Schroedinger's Catgirl
Xaela: The Eldritch Mortician

There's also small singular space encounters. Five in total, two of which will initiate boss fights.
Galdath: The Light Bearer (Aspect of Radiance)
Xenrasa: The Scarlet Rager

There's also five events upon the Starship Entropy, including one boss fight.
Xali: The Letter of Endings

Finally, there's a single event on a so far unknown location. This is a boss fight.
Astaroth: The Demon Lord

Despite them being among the Children of Calamity, Xenrasa and Astaroth are NOT rated as insane difficulty, but surreal. They will follow the gimmick of not really being able to be beaten, only survived. They are not considered super bosses.

I think that's all I can share right now!
There will be a couple little bonus fights in the main story, such as M.F. lazarus testing you as the end of Act twist boss.As well as a fight with The Sun God Ra, although you have Mira and Dibella helping in that battle. it might honestly just become a cutscene instead. We'll see.

Oh, if you're wondering, The Pandemonic Clock is the location where Lucifrael hides herself. Similar to how Naamah is on the moon, and Eisheth is on the Sun, and Agrat bat Mahlat a void. Rykki is the first character you'll meet there- well, one of her anyway. There are just a bunch of time copies running around repairing the clock while others break it or just play with a ball of yarn. The clock itself is potentially the system clock for Yi and Wi's computer, or at least its ingame implementation. Fighting Xaela here makes perfect sense, as she was the Aspect of Time back in Eden's time and still retains those abilities.

Xeltara is actually guiding Mira as Eset but still considers her a good friend even though Mira doesn't work for her. Her fighting you on Terra, a planet where the heavens are in free fall and there's loads of upside down triangles serving as arena floors on the tops, just kinda suits perfect.

Xenrasa is in space when you find her, but she'd recently devoured the world soul of Polara, and you meet those funny doofuses and the one they wanna kill, or... whats left of him.

This is also when we'll get a brief appearance from Mischevia in her Demon Lord apparel, how? Time travel. She's stabilizing a loop.

Astaroth? I dunno. Probably on a dying world that she's taking her time to leisurely drain the people of. Likely intending to wait until she's drained its people one by one until she finished it all off with the world's soul itself.

Anyway, right now I gotta worry about the April build. if you get far enough in Demo 3, you'll likely start to notice placeholders and other stuff, rare as it is, is missing. April build will correct that and more.

One of the things I wondered about the Battle System paperdoll script was...  .... Can the enemies use paperdoll graphics?      And I decided to say... YES!

Now the problem was... HOW?  I figured I needed to mimic how I allowed map events to have equipment attached with Ah-sung's Paperdoll.  And that I felt was going to be extremely problematic.   First, you would need to have the change occur according to a schedule within the TROOPS database.  That way enemies could equip or change gear according to a schedule.  And since that is controlled by the Scene_Battle update method which is nothing but a LOOP.... and the Interpreter's update method which is a loop in a freakin loop... I feared I was toast.

But then, I tried to attach code before Scene_Battle's update method executed, and I found I could garner THIS!!!!!!

• The top red box shows I can get the contents of the TROOP commands per page.
  
• The middle blue box ... I just cleaned up the routines, one action per line... easier to read.
  
• The bottom green box... the actual troop commands.  In fact, you can see that the acquired contents is in the same order as the troop commands that are supplied.

AKA... VICTORY!!!

But the focus is on the commands specific to the paperdoll system and the changing of the equipment.



And apparently, acquiring the actual content is possible....

As I stated, I am using comments much like the Paperdoll system.  But here, I have one line per object which includes the 'Trigger' word... Brenda in this instance.   The currently shown statement is "Brenda|1|1|3" which means...

• Brenda:  first entry saying... I'm a Paperdoll command!!!!
  
• 1:  The second entry saying (I belong to battler#1 in the current TROOP.  NOT the enemy ID in the database.
  
• 1:  The third entry saying... I go in slot #1 (the weapon slot)
  
• 3:  The fourth and last entry saying... I am item ID #3.  Being a weapon, it would be the Steel Sword.

So yep, there IS a plan.  And the format for the comments have been thought out.

But what if a designer wanted to add multiple pieces of gear?  And what if multiple battlers were going to have the paperdoll effect?

Well....  hehehe...  It looks like I already thought about that, and the green box below now shows three pieces of gear being added, two for one battler, and one for a second battler.



As you can see, I can even properly sort the data by the battler ID and the weapon slots.  Even better, though you cannot see it, is that I can remove duplicate entries.  So if I set battler #5 to use a broad sword, and then set battler #5 to use a broad sword.... again... the system isn't STUPID!

Now the above example 'may' appear to have an error.  But not necessarily.  You may see that Battler #1 is assigning an ID of 4 to equipment slot #0.  And true, there is no equipment slot 0.  BUT... Slot 0 is designated the 'BODY' slot.  By default, the slot assumed an equipment value of 0.  BUT, if the game developer so decided that he could swap the body graphic with something in the Graphics\Paperdoll folder, said capability is actually there!!!!

So....  I have two more things to work on for this capability to continue.

1.  The actual implementation of the paperdoll overlay on enemy sprites.  This should not be hard as most of the Ah-Sung modules seem to work or are compatible.
   
2. This currently doesn't account for [Enemy Transform] which allows the battler to change its current graphics.
   

Other than that, a basis for the Brenda rewrite is coming along nicely.

Well, more work was accomplished.

I didn't fully think how to handle the horizontal mirror effect all that much... how to test if the battler was mirrored or not.  I totally forgot that the 'battler' data didn't contain any mirror effect flags, that it was only flagged in the 'Sprite' class itself.  So there was nothing like

      if @active_battler.mirror == true

or anything.

And this was needed for the use of the ORDER_STYLE arrays to determine the order in which all the sprite graphic layers are applied.

Oh, make no mistake.   I resolved the issue.  I did it before with a very simple routine found in AnimBat!  (formerly Animated Battlers)... whereby I made a method within the Spriteset_Battle class just to loop through all the battlers (both actor and enemy) to see if any one of the sprites in the spriteset WAS mirrored.  Heck, the one from AnimBat! was written so well, I just copied it.  There will be absolutely no conflict with the method if this paperdoll is used.

So, the order of the graphic layers is worked out!

(04-09-2023, 08:03 PM)DerVVulfman Wrote: So....  I have two more things to work on for this capability to continue.

1.  The actual implementation of the paperdoll overlay on enemy sprites.  This should not be hard as most of the Ah-Sung modules seem to work or are compatible.
   
2. This currently doesn't account for [Enemy Transform] which allows the battler to change its current graphics.
   

That took... some time.

The method I wrote to acquire the 'comments' from the Troops page had to be expanded to look for the code  identifying the Enemy Transform system.  And I had to come up with some format that would be acceptable, especially since the system will sort all the commands.

So while the arrays generated for the paperdoll layering reads as:  battler, slot, item....

The structure for the Enemy transform will be added to it as: battler, -1, new_ID

This suggests that all of the arrays sort on the battlers first, then the 'enemy transform' reads before any slot values, and then...   Well, nothing should matter at that point.   And as to the value of new_ID, that would be the new enemy ID that the battler will be using.

---

Now, for the readers to wonder... What the heck do I need to get the Enemy Transform stuff, or get the ID of the newly changed enemy, here's why.

The layering system allows you to have layers on both sides of the character sprite.  If the hero or enemy is facing the left, the sword may be drawn first and then covered up by the hero, and then the shield last... covering part of the hero.   But if the hero or enemy is facing right, then the shield is drawn first, then the hero, then the sword.

In essence, I need the actual filename (and hue) of the battler when it comes to the rendering process.

However, the comments and Enemy Transform command are fully gathered before the actual ENEMY TRANSFORM effect is executed.  So I needed to be able to get the Enemy Transform data at that very moment.  If I didn't acquire the Enemy Transform data, the system would THINK the battler was still the original one when the rendering data was gathered.

BIG OOPS averted!

---

Now a bunch of my code for all this hot garbage is in the Scene_Battle class.  That is not desired, and I do eventually want to move it into Sprite_Battler where the rest of the content is residing.  It will take time, but it will move there eventually.

DerVVulfman, your paperdoll system reminds me of a RPG Maker game I played long time ago where the players actually changed appearance when equipped with different weapons.

While it wasn't as in-depth as the system you're working on, it was the first time I saw such feature in a RM game.

Oh, I've seen something akin years ago with RPGMaker 2000 games... but the designer just made multiple combinations of sprites and used a hella big series of conditional branches.

Hey, I got respect for anyone that can come up with detailed event systems... I even saw a Final Fantasy Sideview Battlesystem evented in RPGMaker 2000.  Respect.

For the battle system paperdoll script, it appears that I need to take another step backwards.

You see, if the hero changes direction (even in Ah-sung's), the sprite for the hero is recreated based on the facing direction.  This allows for the layering I've talked about so much.  But the hero has equipment slots to store what items are drawn, enemies in battle... don't.

Yes, the battle paperdoll system can grab the equipment from the TROOPS database as I've described, and grabs it just fine.  It even acquires the proper filenames for the equipment.  But if the enemy sprite needs to change direction, the enemy will have need for a backup of all the equipment that was defined for it.  Otherwise, the enemy will be stripped of any previous graphic changes.

In other words, a semblance of equipment slots per enemy battler.  DISPOSABLE of course, and not saved in memory.

That... I'll see about tomorrow.

(04-12-2023, 02:10 AM)DerVVulfman Wrote: In other words, a semblance of equipment slots per enemy battler.  DISPOSABLE of course, and not saved in memory.

That... I'll see about tomorrow.

I saw about it.

Oh, the code needs a bit of cleanup, and I don't have sprite resources that work with the mirrored layering option, otherwise the enemies in the shot would have their swords appear in their RIGHT hand where it should appear.

And this is still not compatible with any 'animation' system as yet, so not yet ready for AnimBat, Atoa ACBS, or whatnot.

BUT, so far... not bad, eh?

Okay, the steps I have taken have done wonders!   As you can see on the left side of this screenshot, I have made this work with at least a few sideview battle systems.  Technically, it may just be that I cleaned it and reworked some of the methods for naming sake... and it just worked fine with the animation systems by itself.

I tested this with one of the earliest editions of Animated Battlers by Minkoff © 2005/6, and then with my more advanced AnimBat!  While I have not tested it with Cybersam's animation nor the ACBS (Atoa's CBS) by Victor Sant, I am pretty sure they will work fine.

Now, you can see on the center-right that it can use over-sized graphics just as Ah-sung's Paperdoll.  By that, the sprite can be one size, and the additional graphics could be larger or smaller, the size itself makes no difference.  However, this capability only exists if the battler is 'static'.  That is, it is in the default RTP's style of only 1 image per actor or enemy and not a spritesheet.

So if you were to use an animation system, the spritesheets must 'still' be the same size.  But for RTP-styled battlers, you have no size limitations!

OH, and for users of Ah-Sung's, I have a switch that says "Screw setting up the graphics in Brenda, use Ah-Sung's Setup".   By that, you can use the same EQUIP entries from Ah-Sung's Paperdoll for the acquired filenames for the Battler paperdoll system.   If you wanted to have Weapon #1 (Bronze Sword) to use a file of "MyBronzeSword" in both the Graphics\Papersdoll (for Charactersets) and the Graphics\Brenda (for Battlers), you can just make one EQUIP entry that works for both.  No having to copy everything over!  Users of Brenda will not need to recreate the list if it already exists in Ah-Sung's.

I made error-check systems just in case you neglect to have any EQUIP entries defined.  Yep, plenty of error checks and testing before THIS revision gets released.


I'm gonna take a little break now... but I guess tomorrow will be the arduous (and frankly boring) task of reworking the introduction page.  Much will appear like Ah-Sung's as much of the Configuration section is the same.  Heheh, which is why you can use Ah-sung's EQUIP and SUBSTITUTION entries if you wish. BUT it is annoying, and I do have to include notes on the other methods newly created.

To take advantage of the mirrored layer-reversal system, I may have need to update AnimBat! I mean, at least mine would be able to take advantage of NOT needing two sets of animations if they run back n forth on an attack, right?

And the Half Kaiser Battler Project may need an upgrade for some REALLY Sweet dual layer graphic sets for its use.