Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Tutorials
Articles
Scripts
Utilities / Plugins
Resources
Engines
Engine Bulletins
What is Makerscore?
Past Events
Achievements
Misaos
Forums
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
Profile
Locker
Play ListsHEDGE1'S PROFILE
hedge1
862
Close
Crystals: Legend of the ...
Here's something you don't see every day: a game about Crystals and Swords!
Here's something you don't see every day: a game about Crystals and Swords!
Search
Filter
All
Game Pages
User Statuses
[RM2K3] Xenomic's Help Topic
You don't need to duplicate the code for Reimu's passive. You could try something like the following instead:
Var [2503:Character Variable] = 1
Var [2504:Condition Reference] = 2472
Label: 1
Variable Oper: [2505] Set, Var [V[2504]] Value
Var [0187:Random] = 100
Branch if Var [2503:Character Variable] is 1
<> Var [0187:Random] = 1...100
End
Branch if Var [2505:Temp Variable Auto-Med] is 1
<> Branch if Var [2503:Character Variable] is 1
<> <> Var [0187:Random] / 2
<> Else Handler
<> <> Var [0187:Random] = 1...100
<> End
End
Branch if Var [0187:Random] is 20 or less
<> Change Cond: V[2503] Poison Remove
<> Change Cond: V[2503] Blind Remove
<> Change Cond: V[2503] Silence Remove
<> Change Cond: V[2503] Slow Remove
<> etc.
End
Notice that the green section is now NOT under the conditional branch checking if the character has Auto-Med. This allows it to be used both for Reimu's passive and the Auto-Med condition. To ensure it doesn't get triggered erroneously, I've added in the orange line which sets Random = 100, or large enough so that the green branch which checks if Random < 20 never triggers by default.
What I'm doing in blue is to first set random to 1...100 for Reimu in all cases (whether or not Reimu has Auto-Med). This sets the passive to 20%, like you had in the code above. If you wanted it to be 10% like you originally said, just set the random to 1...200 instead.
Next you'll notice that I divide Random by 2 if Reimu has Auto-Med. This in essence doubles the chance for the Auto-Med passive to trigger. If again you originally want the passive to be 10% instead of 20%, you'll need to divide by 4 instead.
This won't make the code run any faster, but it'll allow you to not need to duplicate the Change Cond. At the very least it'll give you some more information on how you can manipulate your code to make it easier for you to write.
Otherwise it looks good. I still recommend you increasing the number of variables you dedicate to this and then check every one rather than jump over them like you're doing, but what you're doing right now should work regardless.
Out of curiosity, how large is this game? 50 characters is MASSIVE!
Var [2503:Character Variable] = 1
Var [2504:Condition Reference] = 2472
Label: 1
Variable Oper: [2505] Set, Var [V[2504]] Value
Var [0187:Random] = 100
Branch if Var [2503:Character Variable] is 1
<> Var [0187:Random] = 1...100
End
Branch if Var [2505:Temp Variable Auto-Med] is 1
<> Branch if Var [2503:Character Variable] is 1
<> <> Var [0187:Random] / 2
<> Else Handler
<> <> Var [0187:Random] = 1...100
<> End
End
Branch if Var [0187:Random] is 20 or less
<> Change Cond: V[2503] Poison Remove
<> Change Cond: V[2503] Blind Remove
<> Change Cond: V[2503] Silence Remove
<> Change Cond: V[2503] Slow Remove
<> etc.
End
Notice that the green section is now NOT under the conditional branch checking if the character has Auto-Med. This allows it to be used both for Reimu's passive and the Auto-Med condition. To ensure it doesn't get triggered erroneously, I've added in the orange line which sets Random = 100, or large enough so that the green branch which checks if Random < 20 never triggers by default.
What I'm doing in blue is to first set random to 1...100 for Reimu in all cases (whether or not Reimu has Auto-Med). This sets the passive to 20%, like you had in the code above. If you wanted it to be 10% like you originally said, just set the random to 1...200 instead.
Next you'll notice that I divide Random by 2 if Reimu has Auto-Med. This in essence doubles the chance for the Auto-Med passive to trigger. If again you originally want the passive to be 10% instead of 20%, you'll need to divide by 4 instead.
This won't make the code run any faster, but it'll allow you to not need to duplicate the Change Cond. At the very least it'll give you some more information on how you can manipulate your code to make it easier for you to write.
Otherwise it looks good. I still recommend you increasing the number of variables you dedicate to this and then check every one rather than jump over them like you're doing, but what you're doing right now should work regardless.
Out of curiosity, how large is this game? 50 characters is MASSIVE!
How long should it take for one to finish a game?
Just a couple of notes concerning Indinera Falls:
1. Most of his games don't actually take as long as advertised. They're still huge, but those numbers are usually generous estimates.
2. The games I've played of his don't value the player's time. Good game design looks for ways to reduce the time it takes to play the game. For him he just doesn't bother, and may even purposefully elongate it (hard to say for certain). I think this is one reason there's so much divide over his games. Those that can accept the senseless padding find a lot of value. Those that can't, don't.
3. He uses a lot of tricks to improve his design speed, especially with mapping. If you look at his rough drafts of dungeons he just grabs the floor tile and draws a bunch of passages, filling in the rest after he has the layout done. He'll even start with a map size of how big he wants the dungeon to be and fill it in, rather than do what we all do and adjust the map size as necessary. He makes extensive use of symmetry for his "nice" buildings, like castles and what-not. Put another way, if he's actually trying to design a nice looking map, he'll just draw half of it and copies it to make it twice as big. He doesn't attempt some of the masterwork that you occasionally see around here. It's all about quick design.
4. He takes the MMO model in his game design. That means combining a bit of player confusion with a lot of dungeons and random battles. Designing plot, towns, cut-scenes -- these take a lot of time and are quickly run through by the player. But a simple increase in the random encounter rate can significantly increase the length of your game with zero extra work. So if you want a longer game, add in a ton of optional side dungeons and what-not. Mandatory battles are also big for him. Expect a lot of on-screen fights you can't avoid (but only face once).
5. Lots of characters and unimportant things to level up. If you want to get everything leveled properly you'll have to replay areas and grind. You also may not even know how you can get everything leveled up properly, which means wondering around the game world fighting battles while you look.
6. He has at least one play tester who plays the game while he's completing it and helps him manage difficulty and squash bugs. This is a HUGE help. Frankly, I'm not even sure if he plays through his own games. Does anyone know?
7. He doesn't waste time trying to find assets. For him, he looks for assets and then fits them into the game rather than the other way around (the exception being anything that he has someone make for him).
8. I almost forgot: he doesn't subscribe to the standard spell design of a lot of games. That means that you won't have a fire, ice, and bolt spell of approximately the same power. It means spells that inflict status effects may also deal damage. It means taking advantage of the default options for weapons and what-not to give a lot of weird bonuses that aren't intuitive for the player. All of this semi-randomness gives players something to think about and consider -- strategy, if you will -- without him actually needing to plan out any semblance of real strategy in the game.
I figured that he takes about two hours of work to design one hour of content, if the advertised numbers are accurate. I tried that once and it would be generous to say the results were satisfying. Yes, I had one hour of game play with only two hours of work. And it didn't look half bad (if you're curious, the entire first dungeon and town of my game Crystals is part of that effort). But the balance was a complete mess since I didn't have time to play test it, and I didn't really have a chance to do any of the more fun coding that I wanted to do. Moreover, it really required focus to work on it. I never sat back and wondered what I was doing. I never questioned if the first dungeon should be three floors or two floors or considered where houses should go in town. I just made the stuff and called it good.
I estimate Indinera Falls takes at least 4 hours per hour of actual in game content. He's also really experienced with it, and so it's easier for him not to think about town layouts, for example. And it might not be that terrible of a method either. If you're just stamping down content to connect your plot points, give side quests, or shop/inn access, you probably don't need to spend that much time in the design. If instead you're creating a more clever, dense, game experience you won't be able to get away with what he was doing. But that's not what he does. His goal is content, and he does that very well.
So to go back to your game design: if you're trying to crank out plot and you're really concerned about time, you may consider skimping a bit more on mapping and gameplay so that you can more quickly get to each plot point. If you do this, be sure to include a lot of stuff for the player, though. If you're not going to purposefully design stuff to be fun for the player, you need enough stuff in there so that they can have fun by themselves.
1. Most of his games don't actually take as long as advertised. They're still huge, but those numbers are usually generous estimates.
2. The games I've played of his don't value the player's time. Good game design looks for ways to reduce the time it takes to play the game. For him he just doesn't bother, and may even purposefully elongate it (hard to say for certain). I think this is one reason there's so much divide over his games. Those that can accept the senseless padding find a lot of value. Those that can't, don't.
3. He uses a lot of tricks to improve his design speed, especially with mapping. If you look at his rough drafts of dungeons he just grabs the floor tile and draws a bunch of passages, filling in the rest after he has the layout done. He'll even start with a map size of how big he wants the dungeon to be and fill it in, rather than do what we all do and adjust the map size as necessary. He makes extensive use of symmetry for his "nice" buildings, like castles and what-not. Put another way, if he's actually trying to design a nice looking map, he'll just draw half of it and copies it to make it twice as big. He doesn't attempt some of the masterwork that you occasionally see around here. It's all about quick design.
4. He takes the MMO model in his game design. That means combining a bit of player confusion with a lot of dungeons and random battles. Designing plot, towns, cut-scenes -- these take a lot of time and are quickly run through by the player. But a simple increase in the random encounter rate can significantly increase the length of your game with zero extra work. So if you want a longer game, add in a ton of optional side dungeons and what-not. Mandatory battles are also big for him. Expect a lot of on-screen fights you can't avoid (but only face once).
5. Lots of characters and unimportant things to level up. If you want to get everything leveled properly you'll have to replay areas and grind. You also may not even know how you can get everything leveled up properly, which means wondering around the game world fighting battles while you look.
6. He has at least one play tester who plays the game while he's completing it and helps him manage difficulty and squash bugs. This is a HUGE help. Frankly, I'm not even sure if he plays through his own games. Does anyone know?
7. He doesn't waste time trying to find assets. For him, he looks for assets and then fits them into the game rather than the other way around (the exception being anything that he has someone make for him).
8. I almost forgot: he doesn't subscribe to the standard spell design of a lot of games. That means that you won't have a fire, ice, and bolt spell of approximately the same power. It means spells that inflict status effects may also deal damage. It means taking advantage of the default options for weapons and what-not to give a lot of weird bonuses that aren't intuitive for the player. All of this semi-randomness gives players something to think about and consider -- strategy, if you will -- without him actually needing to plan out any semblance of real strategy in the game.
I figured that he takes about two hours of work to design one hour of content, if the advertised numbers are accurate. I tried that once and it would be generous to say the results were satisfying. Yes, I had one hour of game play with only two hours of work. And it didn't look half bad (if you're curious, the entire first dungeon and town of my game Crystals is part of that effort). But the balance was a complete mess since I didn't have time to play test it, and I didn't really have a chance to do any of the more fun coding that I wanted to do. Moreover, it really required focus to work on it. I never sat back and wondered what I was doing. I never questioned if the first dungeon should be three floors or two floors or considered where houses should go in town. I just made the stuff and called it good.
I estimate Indinera Falls takes at least 4 hours per hour of actual in game content. He's also really experienced with it, and so it's easier for him not to think about town layouts, for example. And it might not be that terrible of a method either. If you're just stamping down content to connect your plot points, give side quests, or shop/inn access, you probably don't need to spend that much time in the design. If instead you're creating a more clever, dense, game experience you won't be able to get away with what he was doing. But that's not what he does. His goal is content, and he does that very well.
So to go back to your game design: if you're trying to crank out plot and you're really concerned about time, you may consider skimping a bit more on mapping and gameplay so that you can more quickly get to each plot point. If you do this, be sure to include a lot of stuff for the player, though. If you're not going to purposefully design stuff to be fun for the player, you need enough stuff in there so that they can have fun by themselves.
[RM2K3] Xenomic's Help Topic
If you want me to read through it, sure. I haven't read what you've posted already since you've already said you've changed it.
As for what I was saying with not having the checks for characters that will never be inflicted with Rain Dance:
First off, if they'll never be inflicted with Rain Dance, then the rest of the code will never trigger and the only cost is the variable you'll never use. I don't see a major downside to that. Running out of variables could be a problem, but the English release gives you 9999 variables, and if you're using the older version you can use a patch to get 9999 variables, which I hope would be sufficient. You won't include the big list of checks to see if someone is inflicted with the Med1 - Med6 condition for these people either, so literally only the unused variable matters.
More importantly, though, if you skip the extra checks for missing characters you'll speed up the code overall, which will matter if it's running every turn in battle. And finally, it'll keep your overall code more to a minimum and easier to read, which is really nice. All in all, I see it as a better way to manage it.
As for what I was saying with not having the checks for characters that will never be inflicted with Rain Dance:
First off, if they'll never be inflicted with Rain Dance, then the rest of the code will never trigger and the only cost is the variable you'll never use. I don't see a major downside to that. Running out of variables could be a problem, but the English release gives you 9999 variables, and if you're using the older version you can use a patch to get 9999 variables, which I hope would be sufficient. You won't include the big list of checks to see if someone is inflicted with the Med1 - Med6 condition for these people either, so literally only the unused variable matters.
More importantly, though, if you skip the extra checks for missing characters you'll speed up the code overall, which will matter if it's running every turn in battle. And finally, it'll keep your overall code more to a minimum and easier to read, which is really nice. All in all, I see it as a better way to manage it.
[RM2K3] Xenomic's Help Topic
Is there a reason any of the other characters would ever have the Rain Dance condition if they're not in the party? Trihan gives you the correct way to get around your problem, but I'm not sure if I follow why it is a problem in the first place, since only those characters with the given condition should ever be affected.
[RM2K3] Xenomic's Help Topic
Yes, you can put the logic that handles checking for the Rain Dance condition at the top of the common event. I separated it out because the condition check needs to be repeated once for each character, whereas the rest of the script only needs to be written once. But I do think putting them together is the best idea.
[RM2K3] Xenomic's Help Topic
This is fortunately not that difficult because conditions, unlike virtually everything else that deals with characters, can reference characters by variable. Thus the majority of the code is just a simple code, like so:
Var [0189:Character Variable] = 1
Var [0190:Condition Reference] = 2501
Label: 1
Variable Oper: [0188] Set, Var [V[0190]] Value
Branch if Var [0188:Temporary Number] is 1
<> Var [0187:Random] = 1...100
<> Branch if Var [0187:Random] is 80 or more
<> <> Change Cond: V[0189] Poison Remove
<> <> Change Cond: V[0189] Blind Remove
<> <> Change Cond: V[0189] Silence Remove
<> <> Change Cond: V[0189] Slow Remove
<> <> etc.
<> End
End
Branch if Var [0188] is 10 or more
<> Jump to Label: 2
Else Handler
<> Var [0189:Character Variable] + 1
<> Var [0190:Condition Reference] + 1
<> Jump to Label: 1
End
Label: 2
Variable #2501 - 2510 in this case represent variables for 10 characters (I don't know how many characters are in your game, but I'm just choosing 10 for this example). If the variable is 1 then the character is inflicted with Rain Dance. If 0 they are not. I'll call these 10 variables the "condition variables" just to make it easier to talk about.
Variable #190, the "Condition Reference," stores a number corresponding to 10 condition variables. Basically, this is what allows the loop to know what variable to reference to check to see if the character is inflicted with Rain Dance or not.
However, you can't use variable references in conditional branches. So first thing I do after Label 1 is to assign a temporary variable the value of variable # stored in "Condition Reference."
Hopefully that makes sense. It's the most complicated part, but extremely powerful when you're dealing with loops.
So to walk through the above script:
At Label 1, it stores the value of the correct "condition variable" into a temporary variable so that it can be used in the conditional branch to check to see if the given character has the Rain Dance condition or not.
If the Temporary Variable = 1, then it means the character has Rain Dance. Next we have our 20% chance that all of their negative conditions will be cured. Since this is the only time we'll need to list the conditions, it's easy to list just the ones you want curable by Rain Dance. As mentioned before, conditional changes can reference a character by variable, which is what allows this whole loop to function. In this case we reference the character ID by the Variable #189, which I named "Character Variable."
Afterward we check if the Character Variable is greater than or equal to 10. If it is that means we've already checked through all of the characters and need to leave the loop. We do so by going to Label 2.
However, if the Character Variable is less than 10 we still have some characters to check. In this case we need to add one to each of our reference variables so that the proper characters and variables are referenced during the next loop.
At this point there are two things left for you to do. First, you need to somehow populate the condition variables #2501 - 2510. These could either be populated by the Rain Dance spell or by checking conditions. You'll need to write this script for each character manually because you can't check for condition by variable reference.
Branch if Character1 has RainDnce Condition
<> Var [2501:Char1 inflicted with Rain Dance] = 1
Else Handler
<> Var [2501:Char1 inflicted with Rain Dance] = 0
End
The final thing is to figure out how to give Reimu a 40% chance to remove the conditions rather than 20%. There are two ways you could accomplish this. One option is to write a completely separate script just for Reimu. The other option is to write the main script to have a variable percentage chance. Because I don't like using extra variables when I don't have to, I'm instead altering the random number. Changes from the script above are in blue below.
Var [0189:Character Variable] = 1
Var [0190:Condition Reference] = 2501
Label: 1
Variable Oper: [0188] Set, Var [V[0190]] Value
Branch if Var [0188:Temporary Number] is 1
<> Branch if Var [0189:Character Variable] is 4 (I'm assuming this is Reimu)
<> <> Var [0187:Random] = 1...50
<> Else Handler
<> <> Var [0187:Random] = 1...100
<> End
<> Branch if Var [0187:Random] is 20 or less
<> <> Change Cond: V[0189] Poison Remove
<> <> Change Cond: V[0189] Blind Remove
<> <> Change Cond: V[0189] Silence Remove
<> <> Change Cond: V[0189] Slow Remove
<> <> etc.
<> End
End
Branch if Var [0188] is 10 or more
<> Jump to Label: 2
Else Handler
<> Var [0189:Character Variable] + 1
<> Var [0190:Condition Reference] + 1
<> Jump to Label: 1
End
Label: 2
Hopefully this helps you understand a bit how you can use loops and variable references to make some these custom scripts easier to manage.
Var [0189:Character Variable] = 1
Var [0190:Condition Reference] = 2501
Label: 1
Variable Oper: [0188] Set, Var [V[0190]] Value
Branch if Var [0188:Temporary Number] is 1
<> Var [0187:Random] = 1...100
<> Branch if Var [0187:Random] is 80 or more
<> <> Change Cond: V[0189] Poison Remove
<> <> Change Cond: V[0189] Blind Remove
<> <> Change Cond: V[0189] Silence Remove
<> <> Change Cond: V[0189] Slow Remove
<> <> etc.
<> End
End
Branch if Var [0188] is 10 or more
<> Jump to Label: 2
Else Handler
<> Var [0189:Character Variable] + 1
<> Var [0190:Condition Reference] + 1
<> Jump to Label: 1
End
Label: 2
Variable #2501 - 2510 in this case represent variables for 10 characters (I don't know how many characters are in your game, but I'm just choosing 10 for this example). If the variable is 1 then the character is inflicted with Rain Dance. If 0 they are not. I'll call these 10 variables the "condition variables" just to make it easier to talk about.
Variable #190, the "Condition Reference," stores a number corresponding to 10 condition variables. Basically, this is what allows the loop to know what variable to reference to check to see if the character is inflicted with Rain Dance or not.
However, you can't use variable references in conditional branches. So first thing I do after Label 1 is to assign a temporary variable the value of variable # stored in "Condition Reference."
Hopefully that makes sense. It's the most complicated part, but extremely powerful when you're dealing with loops.
So to walk through the above script:
At Label 1, it stores the value of the correct "condition variable" into a temporary variable so that it can be used in the conditional branch to check to see if the given character has the Rain Dance condition or not.
If the Temporary Variable = 1, then it means the character has Rain Dance. Next we have our 20% chance that all of their negative conditions will be cured. Since this is the only time we'll need to list the conditions, it's easy to list just the ones you want curable by Rain Dance. As mentioned before, conditional changes can reference a character by variable, which is what allows this whole loop to function. In this case we reference the character ID by the Variable #189, which I named "Character Variable."
Afterward we check if the Character Variable is greater than or equal to 10. If it is that means we've already checked through all of the characters and need to leave the loop. We do so by going to Label 2.
However, if the Character Variable is less than 10 we still have some characters to check. In this case we need to add one to each of our reference variables so that the proper characters and variables are referenced during the next loop.
At this point there are two things left for you to do. First, you need to somehow populate the condition variables #2501 - 2510. These could either be populated by the Rain Dance spell or by checking conditions. You'll need to write this script for each character manually because you can't check for condition by variable reference.
Branch if Character1 has RainDnce Condition
<> Var [2501:Char1 inflicted with Rain Dance] = 1
Else Handler
<> Var [2501:Char1 inflicted with Rain Dance] = 0
End
The final thing is to figure out how to give Reimu a 40% chance to remove the conditions rather than 20%. There are two ways you could accomplish this. One option is to write a completely separate script just for Reimu. The other option is to write the main script to have a variable percentage chance. Because I don't like using extra variables when I don't have to, I'm instead altering the random number. Changes from the script above are in blue below.
Var [0189:Character Variable] = 1
Var [0190:Condition Reference] = 2501
Label: 1
Variable Oper: [0188] Set, Var [V[0190]] Value
Branch if Var [0188:Temporary Number] is 1
<> Branch if Var [0189:Character Variable] is 4 (I'm assuming this is Reimu)
<> <> Var [0187:Random] = 1...50
<> Else Handler
<> <> Var [0187:Random] = 1...100
<> End
<> Branch if Var [0187:Random] is 20 or less
<> <> Change Cond: V[0189] Poison Remove
<> <> Change Cond: V[0189] Blind Remove
<> <> Change Cond: V[0189] Silence Remove
<> <> Change Cond: V[0189] Slow Remove
<> <> etc.
<> End
End
Branch if Var [0188] is 10 or more
<> Jump to Label: 2
Else Handler
<> Var [0189:Character Variable] + 1
<> Var [0190:Condition Reference] + 1
<> Jump to Label: 1
End
Label: 2
Hopefully this helps you understand a bit how you can use loops and variable references to make some these custom scripts easier to manage.
Ship Battle
author=pianotm
The least problematic way I've come up with is to transfer your PC to a map with the ocean tiles set to passable, change your PC sprite to a vehicle sprite, handle your movement and cutscenes accordingly, then when you transfer to your battle scene, change the vehicle sprite back into the PC sprite.
I just wanted to second this. Vehicles can be glitchy, and this is definitely the safest way I know to transfer out of the vehicle on one map while remaining in the vehicle on another.
An alternative is to first fade the screen to black on the ship map, then force the hero to leave the ship using the event command. Since the screen is black this won't be seen by the player. Now teleport to the ship battle map, and when the battle is finished, repeat the process: fade to black, teleport back to the ship map, call the "enter vehicle" event command, and then fade in. Since I'm reasonably confident that "exit vehicle" requires a valid land tile to function, you either need to setup this ship battle next to land somehow or use the "swap tile" event command to swap out the sea tiles with an unused tile that's marked as passable from elsewhere in the tile set. That sounds a bit wonky, but everything reverts back to normal when you return to the map, and it'll be done with a black screen anyway.
[RM2K3] Doublecast skills
author=Xenomic
I am quite curious though as to what the Temporary Number variable is meant for though. Is that meant to give it randomization of some form that's not just "Random 1...100" like with Patchouli's or is it something more? o.o?
The Temporary Variable is just a variable I use to do some math. In this case I'm trying to find the percentage chance of something happening. Since each increase in W-Magic increases the chance of a double cast by 5%, I make Temporary Variable = W-Magic * 5. Then I add 10 to it since I noticed that even if W-Magic = 0, the chance for double cast was still 10%.
Now that I have a variable with the percent of something happening, I just take another variable, Random, and set it equal to a value between 1 and 100. If the number is less than or equal to my "percent chance" (aka Temporary Variable) then the double cast was successful.
author=Xenomic
though wish there was a way to make a "Master Event" page so that I didn't have to copy/paste things so often. 2K3, why couldn't you let us do that?!)
The English version has all of the battle commands available in common events, which means you can just call a common event rather than copy/paste stuff all the time for each battle.
[RM2K3] Doublecast skills
It's amazing how much better rm2k3 would be if any command that did something to a character or checked something on a character would always have the option of using the character ID in a variable. However, since that's not the case....
This is for your "doublecast" common event. Repeat the following code for each character. I'm assuming "W-Magic" is for the Reisen and not unique to each character. If it is unique you'll of course have to alter it for each character. Also, I'm doing this for standard characters, not Patchouli.
Branch if Character1 has X-Wave Condition
<> Var [0188:Temporary Number] = [1451:W-Magic]
<> Var [0188:Temporary Number] * 5
<> Var [0188:Temporary Number] + 10
<> Var [0187:Random] = 1...100
<> Branch if Var is [0189:Temporary Number] or less
<> <> Var [14xx:Character1 Doublecast] Set 1
<> Else
<> <> Var [14xx:Character1 Doublecast] Set 0
<> End
End
And then you'd put what you already have in the battle event.
Branch if Var [14xx:Character1 Doublecast] is 1
<> Enable Combo: Character1 SkillSet Repeats 2 Times
Else Handler
<> Enable Combo: Character1 SkillSet Repeats 1 Times
End
If you did choose to have variables instead of conditions, you could check the first part in a big loop (like what I outlined in my first response) rather than having to replicate the code for each character. But it's up to you.
This is for your "doublecast" common event. Repeat the following code for each character. I'm assuming "W-Magic" is for the Reisen and not unique to each character. If it is unique you'll of course have to alter it for each character. Also, I'm doing this for standard characters, not Patchouli.
Branch if Character1 has X-Wave Condition
<> Var [0188:Temporary Number] = [1451:W-Magic]
<> Var [0188:Temporary Number] * 5
<> Var [0188:Temporary Number] + 10
<> Var [0187:Random] = 1...100
<> Branch if Var is [0189:Temporary Number] or less
<> <> Var [14xx:Character1 Doublecast] Set 1
<> Else
<> <> Var [14xx:Character1 Doublecast] Set 0
<> End
End
And then you'd put what you already have in the battle event.
Branch if Var [14xx:Character1 Doublecast] is 1
<> Enable Combo: Character1 SkillSet Repeats 2 Times
Else Handler
<> Enable Combo: Character1 SkillSet Repeats 1 Times
End
If you did choose to have variables instead of conditions, you could check the first part in a big loop (like what I outlined in my first response) rather than having to replicate the code for each character. But it's up to you.
Games - Tester
Games - Other
