Project -QB- Redux: Day 1
Well, today starts the first of what I hope is a full telling of how I am going about redoing Project: -QB- both to be useful for others who are trying to make such games and the like to see what I'm doing and going about it, more less to keep people breasted at how fast I work and progress on these things, and the head aces and struggles that will ( more then likely ) happen along the way.
So first and formost: Why?
The answer is pretty easy in that. Back when I started the project, it was mostly a proof of concept situation. I didn't take steps to keep things organized nor clean in any fashion, and it shows utterly.
The maps where a mess, the common events where a mess, the triggers, everything was all over without any real good way to keep track of everything. This in and of itself is some pretty hard knocks on my own self, but this wouldn't be such a matter if not for the big issue at hand: Updating older features to work better started breaking everything else. I had learned a lot from working on Egg Assault, and I wanted to bring a lot of those updates and improvements over here to better my workflow, but alas due towards just how disorganized it really was at the end of the day, I've had to drop that build and start anew.
So, what goes into starting one of my game projects then from scratch?
The first tibit is the scripts, as without those, I've got nothing. Of course, the scrips I use....
...Come from the one and only CP, or Neon Black. As anyone who's followed me the last year or two would know, CP's stuff allows me to do everything that I do. From the battle system that changes images based off of status effects, towards the ability to 'stack' said status effects in turn towards worse and worse levels, CP's content has given my games the backbone to work off of time and time again. Out of all of them, I've only done a fix and edit towards one of them, the Custom Battle, in where it had a serous game crashing bug and error, and it took me well over a year to trace down the exact issue and learn how to patch it up for good. Ever since that fix though, these have been my go-to, and there's not been anything else on the market that gives me the type of control nor options I need for my products. CP might have gone off towards greener pastures, but I still carry and respect the work he's done, and am ever grateful for it.
So today was mostly about shifting over all the scripts I'll need to use into a new project, more less art assists and the like. In the last iteration of Project: -QB-, I used RPG Maker's default AI scripting. This is just it rolling a dice and seeing what attack goes off on whom, with me able to fiddle around with it ever so much via Varables or Switches, or if it's HP is in Selective ranges, but nothing else. Overall it's rather limited in function, and disallows a mot of creative ideas, or preventing attacks going off on targets it should not ( like targets that JUST recovered from status effects, so you don't get 'stun locked' ). Egg Assault was the first take on using CP's AI script, passed down by one of the more helpful assistance's a while back when trying to better my games, and as anyone who plays it shows, the AI is a lot more smarter and can really focus down a player in key situations if you don't disallow them to. That's because such AI lets me control whom it can and can't target based off a number of different pointers, being health, status, or even if they are being attacked! That kind of greater control lets me make far more smarter foes that try to set up onto the player, and it'll be on the player to ether try to counter that strategy...or let it go off...;3
As an example of how the AI works, here's a snapshot from the Resin bot:
Skill_Use_AI: 159
Required_Switch: 98, OFF
Remove_If: t.state?(16)
Select_Default
Skill_Use_AI: 161
Required_State: 16
Select_If: t.state?(26)
Select_Random
Skill_Use_AI: 160
Required_State: 16
Select_If: t.state?(303)
Select_Random
Skill_Use_AI: 160
Required_State: 16
Select_If: t.state?(306)
Select_Random
Skill_Use_AI: 160
Required_State: 16
Remove_If: t.state?(19)
Remove_If: t.state?(22)
Remove_If: t.state?(31)
Remove_If: t.state?(26)
Remove_If: t.state?(20)
Remove_If: t.state?(21)
Remove_If: t.state?(25)
Remove_If: t.state?(23)
Remove_If: t.state?(24)
Remove_If: t.state?(30)
Select_If: (t.hp_rate * 100) <= 25
Select_Random
Skill_Use_AI: 160
Required_State: 16
Remove_If: t.state?(19)
Remove_If: t.state?(22)
Remove_If: t.state?(31)
Remove_If: t.state?(26)
Remove_If: t.state?(20)
Remove_If: t.state?(21)
Remove_If: t.state?(25)
Remove_If: t.state?(23)
Remove_If: t.state?(24)
Remove_If: t.state?(30)
Remove_If: t.state?(252)
Select_If: (t.hp_rate * 100) <= 50
Select_Random
Skill_Use_AI: 126
Remove_If: t.state?(6)
Remove_If: t.state?(19)
Remove_If: t.state?(25)
Remove_If: t.state?(26)
Remove_If: t.state?(20)
Remove_If: t.state?(21)
Remove_If: t.state?(303)
Remove_If: t.state?(306)
Select_Random
Skill_Use_AI: 1
Remove_If: t.state?(19)
Remove_If: t.state?(25)
Remove_If: t.state?(26)
Remove_If: t.state?(20)
Remove_If: t.state?(21)
Select_Random
Skill_Use_AI: 7
Select_Default
...that's a lot of text huh? But you can chances are make out a few key factors of it if your savvy enough, even without knowing exactly what all each number is referring towards. For example, there's 4 different listings for the Skill #160, one of them can only work if the targets 25% HP or less, another is 50% HP or less ( but notice it has one more status effect the previous one did not as 'do not target' ), and then the last two only list it being able to work if a target has a single status effect. These refer towards the Resin drone able to coat someone in resin, and as you can guess, pans out from "At 25% HP as long as not under another status, 50% as long as not under Aiges Shard ( and any previously listed status ), and at any point and time a target is under Hypno/Hypno (Droned)". The order is also important to note, as the script reads from the top down, so whatever becomes the first 'valid' attack, it will always do before anything else under the list. Controlling that though is with creative use of limits ( don't attack if person doesn't have status/is under status ) more less if the foe can even legit use the attack ( not enough MP/TP usable to use the attack ) at the time.
Well, that's a good place to stop for now. If you guys want to have me explain other points in detail, or want to see selective parts being worked on, do chime in and let me know! Questions and the like are also welcomed!
So first and formost: Why?
The answer is pretty easy in that. Back when I started the project, it was mostly a proof of concept situation. I didn't take steps to keep things organized nor clean in any fashion, and it shows utterly.
The maps where a mess, the common events where a mess, the triggers, everything was all over without any real good way to keep track of everything. This in and of itself is some pretty hard knocks on my own self, but this wouldn't be such a matter if not for the big issue at hand: Updating older features to work better started breaking everything else. I had learned a lot from working on Egg Assault, and I wanted to bring a lot of those updates and improvements over here to better my workflow, but alas due towards just how disorganized it really was at the end of the day, I've had to drop that build and start anew.
So, what goes into starting one of my game projects then from scratch?
The first tibit is the scripts, as without those, I've got nothing. Of course, the scrips I use....
...Come from the one and only CP, or Neon Black. As anyone who's followed me the last year or two would know, CP's stuff allows me to do everything that I do. From the battle system that changes images based off of status effects, towards the ability to 'stack' said status effects in turn towards worse and worse levels, CP's content has given my games the backbone to work off of time and time again. Out of all of them, I've only done a fix and edit towards one of them, the Custom Battle, in where it had a serous game crashing bug and error, and it took me well over a year to trace down the exact issue and learn how to patch it up for good. Ever since that fix though, these have been my go-to, and there's not been anything else on the market that gives me the type of control nor options I need for my products. CP might have gone off towards greener pastures, but I still carry and respect the work he's done, and am ever grateful for it.
So today was mostly about shifting over all the scripts I'll need to use into a new project, more less art assists and the like. In the last iteration of Project: -QB-, I used RPG Maker's default AI scripting. This is just it rolling a dice and seeing what attack goes off on whom, with me able to fiddle around with it ever so much via Varables or Switches, or if it's HP is in Selective ranges, but nothing else. Overall it's rather limited in function, and disallows a mot of creative ideas, or preventing attacks going off on targets it should not ( like targets that JUST recovered from status effects, so you don't get 'stun locked' ). Egg Assault was the first take on using CP's AI script, passed down by one of the more helpful assistance's a while back when trying to better my games, and as anyone who plays it shows, the AI is a lot more smarter and can really focus down a player in key situations if you don't disallow them to. That's because such AI lets me control whom it can and can't target based off a number of different pointers, being health, status, or even if they are being attacked! That kind of greater control lets me make far more smarter foes that try to set up onto the player, and it'll be on the player to ether try to counter that strategy...or let it go off...;3
As an example of how the AI works, here's a snapshot from the Resin bot:
Skill_Use_AI: 159
Required_Switch: 98, OFF
Remove_If: t.state?(16)
Select_Default
Skill_Use_AI: 161
Required_State: 16
Select_If: t.state?(26)
Select_Random
Skill_Use_AI: 160
Required_State: 16
Select_If: t.state?(303)
Select_Random
Skill_Use_AI: 160
Required_State: 16
Select_If: t.state?(306)
Select_Random
Skill_Use_AI: 160
Required_State: 16
Remove_If: t.state?(19)
Remove_If: t.state?(22)
Remove_If: t.state?(31)
Remove_If: t.state?(26)
Remove_If: t.state?(20)
Remove_If: t.state?(21)
Remove_If: t.state?(25)
Remove_If: t.state?(23)
Remove_If: t.state?(24)
Remove_If: t.state?(30)
Select_If: (t.hp_rate * 100) <= 25
Select_Random
Skill_Use_AI: 160
Required_State: 16
Remove_If: t.state?(19)
Remove_If: t.state?(22)
Remove_If: t.state?(31)
Remove_If: t.state?(26)
Remove_If: t.state?(20)
Remove_If: t.state?(21)
Remove_If: t.state?(25)
Remove_If: t.state?(23)
Remove_If: t.state?(24)
Remove_If: t.state?(30)
Remove_If: t.state?(252)
Select_If: (t.hp_rate * 100) <= 50
Select_Random
Skill_Use_AI: 126
Remove_If: t.state?(6)
Remove_If: t.state?(19)
Remove_If: t.state?(25)
Remove_If: t.state?(26)
Remove_If: t.state?(20)
Remove_If: t.state?(21)
Remove_If: t.state?(303)
Remove_If: t.state?(306)
Select_Random
Skill_Use_AI: 1
Remove_If: t.state?(19)
Remove_If: t.state?(25)
Remove_If: t.state?(26)
Remove_If: t.state?(20)
Remove_If: t.state?(21)
Select_Random
Skill_Use_AI: 7
Select_Default
...that's a lot of text huh? But you can chances are make out a few key factors of it if your savvy enough, even without knowing exactly what all each number is referring towards. For example, there's 4 different listings for the Skill #160, one of them can only work if the targets 25% HP or less, another is 50% HP or less ( but notice it has one more status effect the previous one did not as 'do not target' ), and then the last two only list it being able to work if a target has a single status effect. These refer towards the Resin drone able to coat someone in resin, and as you can guess, pans out from "At 25% HP as long as not under another status, 50% as long as not under Aiges Shard ( and any previously listed status ), and at any point and time a target is under Hypno/Hypno (Droned)". The order is also important to note, as the script reads from the top down, so whatever becomes the first 'valid' attack, it will always do before anything else under the list. Controlling that though is with creative use of limits ( don't attack if person doesn't have status/is under status ) more less if the foe can even legit use the attack ( not enough MP/TP usable to use the attack ) at the time.
Well, that's a good place to stop for now. If you guys want to have me explain other points in detail, or want to see selective parts being worked on, do chime in and let me know! Questions and the like are also welcomed!
