RPGMaker 2 Exclusive Class FAQ v1.0 In-Depth FAQ by David Reisig 11/10/03 BlueSenshi@hotmail.com Table of Contents 1) Legal Information 2) About this FAQ 3) What is an "Exclusive" Class? 4) What do I need to know? 5) Method Explanation 6) Controlling Requirements 7) 'Dummy' Classes 8) Controlling Conditions 9) Specific Exclusive Class examples 10) Special Class Examples **Updated** 11) Additional Comments 12) Acknowledgements **Hint: Use your browser's "Find" function to jump to a specific section.** **Hint: Use your browser's "Find" function to find Updates quickly, too.** ----------------------------------------------------------- | Legal Information | ----------------------------------------------------------- Copyright 2003 David Reisig. This may not be reproduced under any circumstances except for personal, private use. It may not be placed on any web site or otherwise distributed publicly without advance written permission. Use of this guide on any other web site or as a part of any public display is strictly prohibited, and a violation of copyright. All trademarks and copyrights contained in this document are owned by their respective trademark and copyright holders. If this FAQ is found somewhere other than: www.gamefaqs.com (GameFAQs) www.rpgmpavilion.com (The Pavilion) email me and let me know. -------------- About this FAQ This FAQ is about creating and managing "Exclusive" Classes in RPGMaker2. This FAQ will explain some basic information about Classes, but it also assumes the reader has some knowledge of RPGM2 basics. This FAQ will not explain how to create Scripts or Events, nor will it explain Event placement. This FAQ was written with the assumption that the player is using the default settings and understands basic controller functions. The instructions in this FAQ can not be executed from "Beginner" mode. ----------------------------- What is an "Exclusive" Class? An "Exclusive" Class (from now on just called exclusive) is a class that every character can not become. The default system allows any character to become any class as long as they have fulfilled the requirements to become that class. Setting up an exclusive class just controls those requirements. ----------------------- What do I need to know? You need to know how to do the following: 1) Create a new Class 2) Set Class requirements 3) Reorder Classes in the Class menu You may also need to know how to: 1) Locate and Edit a Script 2) Create a conditional statement 3) Reorder lines of Script 4) Use the "Member Info Load" function If you can not at least create and edit Classes, don't bother reading the rest of this FAQ yet. Practice with the basic stuff first. ------------------ Method Explanation Some of you are probably thinking "Why don't you just make a brand new Class Change Script? You could set it up however you wanted." I'll tell you why I'm not using a completely custom Script... It would take way too long and the whole process would be error prone out the wazoo. The default Class system can handle most of the actual work on its own, I just want to make it more specific. Besides that, the default Class system handles changes to Classes (Names and Numbers, especially) automatically, a custom Script would have to be updated every time the Classes were changed. I'm not only working towards a customizable Class system, but also a Class system that can be maintained with minimal time and effort. RPGM2 will take quite a lot of time to use as it is. No sense making it overcomplicated. ------------------------ Controlling Requirements Because the default Class system allows anyone to become any class as long as they meet the requirements, the first step to creating an exclusive class is to create controllable requirements. The default system only allows you to restrict class changing by requiring other classes to be obtained. Also, you must have a rank for each requirement, or the system will ignore it. The first property of exclusive classes: Classes can not be requirements of themselves. If they were, exclusive classes would be a lot easier to set up. Considering the default system assumes that party members can become any class (like in Dragon Warrior 7), it stands to reason that the designers would not allow players to directly exclude classes from the class list. The second property of exclusive classes: If two classes are requirements of each other, then a party member can not become either class unless they are already one of the classes. For example, suppose you have a class "Lizard" and a class "Bird". The requirement for "Lizard" is "Bird" and the requirement for "Bird" is "Lizard". If a party member is neither "Lizard" nor "Bird", then they do not meet the requirements to become either Class, according to the default system. Considering classes can't require themselves, I figured the system wouldn't allow classes to require each other, either. I'm glad I was wrong. We can use this to our advantage. The third property of exclusive classes: If you do not meet the requirements of the class that you are currently in, you can not choose it from the class list. Another shocker. I figured the system would override requirements once a party member has become a class. I was wrong again. If you do not meet the requirements of any particular class, then you can not choose that class from the default class list. We can use this to our advantage as well. The fourth property of exclusive classes: If an exclusive class has a 'Dummy' class as one of its requirements, then a party member that is not already the exclusive class can not become the exclusive class. This stems from the second property of exclusive classes. Dummy classes are special exclusive classes, and are explained in the next section. --------------- 'Dummy' Classes A major part of exclusive Classes is creating something I'll call a 'Dummy' Class (just called dummy from now on). A dummy class is a class that will never appear in the class list because the requirements will be impossible to meet. The first property of dummy classes: A dummy class will require a party member to have been one or more exclusive or dummy classes. Obviously, the point of an exclusive class is to prevent a party member from becoming more than one of them. Also, the point of dummy classes are to prevent a party member from becoming any of them at all. Requiring one or more exclusive or dummy classes will therefore make dummy classes impossible to acquire. The second property of dummy classes: There might be times when it is necessary to give a character a Rank in a dummy class. As long as the requirements are impossible to meet, this will not be a problem. You will see what I mean later. The third property of dummy classes: A dummy class can be replaced by a conditional statement within the Class Shop Script in some cases. However, in most cases, a dummy class is easier to manage, especially for people who do not understand Scripting very well. The fourth property of dummy classes: Starting with the fourth dummy class, you can make dummy classes more efficient. By using combinations of dummy classes, you can create more complicated requirements which will allow you to have more exclusive classes per dummy class. I have provided a small table below to help you figure out how many dummy classes you'll need. Dummy -> Exclusive 1 -> 1 2 -> 2 3 -> 3 4 -> 6 5 -> 10 6 -> 20 7 -> 35 8 -> 70 9 -> 126 So you will never need more than 9 dummy classes. As long as you never need more than 91 exclusive classes, you'll be fine! And if you're curious how I came up with those numbers, it's easy. You just figure out the combinations of N things taked N/2 at a time. Scientific calculators should be able to do combinations easily. I used a TI-86. In cases where N/2 is a decimal, you can either round up or down from the result. The answer will be the same. ---------------------- Controlling Conditions In some cases, a conditional statment within the Class Shop Script is a better idea than several dummy classes. Obviously if someone has a large game with several Class choices (nearly 100) or lots of characters that have separate Class paths, conditional statements would be the best choice. Also, if someone wants a specific character or a specific Class to never change classes, conditionals might be better. The first function of conditional statements (within the Class changing context) is to prevent the player from accessing the Class List at all. The second function of conditional statements is to provide a temporary class change just prior to accessing the Class List. This function would be most useful for allowing characters to become 'Dummy' classes temporarily. The third function of conditional statements is to provide a class change just after a class change has taken place. This function would be most useful in disallowing the player from choosing the 'No Class' option, since you can't remove it from the Class List. You would be able to change a party member from 'No Class' to another class immediately or bring the Class List up again and force them to choose another class before they can continue. --------------------------------- Specific Exclusive Class Examples This section will be divided up into the following subsections: 1) One party member - one exclusive class. All other party members - all other classes. 2) One party member - exclusive class path. All other party members - all other classes. 3) All party members - individual classes / Sets of party members - one class per set. 4) All party members - individual class paths / Sets of party members - one class path per set. 5) Other methods - Restricting 'No Class'. 6) Other methods - Allowing the player to choose the Class Path. -----One Party Member - One Exclusive Class----- Party member "Kitty" is a cat and is in the "Cat" Class. Obviously a cat can not become a "Fighter" or "Mage". All other party members are humans. In your game you want only "Kitty" to be a "Cat" and never change classes. Assume you have already set up the "Cat" class. Problems: 1) The default system allows Kitty to become any other class. 2) The default system allows Kitty to become "No Class". 3) The default system allows anyone else to become a "Cat". Solutions: 1) Create a dummy class called "Can't Change". 2) Reorder your Classes so that "Can't Change" is spot 0 and "Cat" is spot 1. 3) Put "Cat: Rank 8" as a requirement for "Can't Change". 4) Put "Can't Change: Rank 8" as a requirement for "Cat". 5) Go into the Script Editor and find the Script for the Class Shop. 6) Copy the Script and Paste it as a new Script. 7) Edit the new Script. 8) Between lines 014 and 015, enter the following lines: Data: Member Info Load Script Branch: Condition: Variable 088 'Class Number' = 1 Text: Clear Message Text Content: Input: Display 'Common Name' Text: ' can not change classes.' Wait 20F Script Branch End Script Brand: Condition: Variable 088 'Class Number' /= 1 Script Branch End 9) Starting on line 023, highlight all the code until you come to four consecutive Script Branch Ends, including the first two Script Branch Ends. Copy. 10) Highlight the same code again, only this time, Delete. 11) Paste the copied code between lines 021 and 022. 12) Save your work. Test play. It should work perfectly. Explanation: What you did here was create the "Can't Change" class (a dummy class) that, in conjunction with the "Cat" class (the exclusive class), prevents any party members from acquiring the "Cat" or "Can't Change" class. That solved problem 3. You also set up a condition in the Script that checked the selected player's Class, and if it was "Cat" (the exclusive class), the Script simply tells the player they can't change classes and never opens the Class List. That solves problems 1 and 2. Because you never want "Kitty" to change classes, this is probably the best setup. This can also be used for several characters of class "Cat" that you never want to change classes. Because the condition checks the character's class, any member of class "Cat" will not be able to change classes. -----One Party Member - One Exclusive Class Path----- Once again, "Kitty" is a cat and is in the "Cat" class. This time, however, you want to allow "Kitty" to change classes, but you want "Kitty" to have a class path that is different from everyone else's. Assume you have already created your classes and set requirements appropriately. Assume that "Cat" is the first class in "Kitty"s class path. Problems: 1) The default system allows Kitty to become any other class. 2) The default system allows anyone else to become a "Cat". Solutions: 1) Create a dummy class called "Kitty Path". 2) Create a dummy class called "Others Path". 3) Put "Others Path: Rank 8" as a requirement of "Kitty Path". 4) Put "Kitty Path: Rank 8" as a requirement of "Others Path". 5) Put "Kitty Path: Rank 1" as a requirement of "Cat". 6) Put "Others Path: Rank 1" as a requirement of all the other 'first' classes. 7) Give "Kitty" a 'Title' of "Kitty Path: Rank 1" in the Party Member Editor. 8) Give all other players a 'Title' of "Others Path: Rank 1". Explanation: What you did this time was create two dummy classes so that you could differentiate between the "Cat" class path and the other class paths. There are no conditions this time because you want everyone to be able to access the Class List. -----All Party Members - Individual Classes----- -----Sets of Party Members - One Class Per Set----- If you don't want anyone to change classes, then don't put any Class Shops in your game. It's that simple. I shouldn't have to say it, but I'm sure someone will look at my guide and naively complain that I didn't explain how to do this. -----All Party Members - Individual Class Paths----- -----Sets of Party Members - One Class Path Per Set----- I'm changing the format for the last example. The problems are the same as before, and the Steps are nearly the same as well. Also, in this example, I'll talk about combining dummy classes to be more efficient. Use the chart under 'Dummy Classes' to figure out how many dummy classes you'll need. If you need more than 3, chances are you won't be able to give the dummy classes very descriptive names. Just write down which path each combination goes to, and use that to set up your Classes and Party Members. I'll give a detailed example using 4 dummy classes. More than that would be more complicated and probably won't help as many people. Suppose you have 6 Exclusive Class Paths. According to the chart, you'll need 4 dummy classes. We'll call them "D1", "D2", "D3", and "D4". Make D1 and D2 requirements of each other, Rank 8. Do the same for D3 and D4. Now we'll make a list of Class paths and give them a unique combination of dummy classes to identify them: (1, 2) Warrior (1, 3) Ninja (1, 4) Hunter (2, 3) Wizard (2, 4) Cleric (3, 4) Summoner Now, in the Warrior Class, make D1 and D2 requirements, Rank 1. Do the same for the other classes, only using the appropriate combinations. Then, in the Party Member Editor, give the "Warrior" the 'Titles' D1: and D2: Rank 1. Do the same for the other members, only using the appropriate combinations. Now everything should work perfectly. To set this up for sets of party members is exactly the same, only you set the same 'Titles' for the members of the same Class Path. The rest of the setup is identical. -----Other Methods - Restricting 'No Class'----- Unfortunately, you are not able to remove the 'No Class' selection from the Class List because there is no place to put requirements on it. However, there is a way to prevent the player from ever having a 'No Class' character. This is quite easy, and can be used in conjunction with any class setup. All this method does is prevent the player from choosing the 'No Class' Class. Open the 'Class Shop' Script and find the line that reads: Script Branch: Condition: Variable 'Class Number' = -1 Highlight from that line to the Script: Branch End below. Delete. In its place, put in the following lines: Script Branch: Repeat: Variable 'Class Number' = -1 Text: Message 'You must choose a valid class.' Input: Class Change List Text: Clear Message Script: Branch End Also, take out the condition directly below. It should read: Script Branch: Condition: Variable 'Class Number /= -1 That should do it. If the player chooses 'No Class', then the script will force them to choose another class from the class list. -----Help Menu Inside Class Select List----- Tarendol emailed me a wonderful idea. Rather than leaving the option of 'No Class' in the list and forcing the player to pick another class, you should change the name of 'No Class' (Menu Text 29) to 'Help', and call the Class Description list so that the player can get the class descriptions while they're trying to decide on a class. This is a great idea, and here is the Script to implement it: If you already have the above Script that restricts 'No Class'. Insert the following lines: Text: Message 'Which class would you like information about?' Input: Display Class Info Text: Clear Message Text Content: Display Description Class (When Called) Wait 30F Text: Clear Message Text: Message 'Have you decided on a class?' Insert the lines so that they are the first lines inside the loop. Then delete the "Text: Message 'You must choose a valid class.'" line. If you do not have the loop already, insert the loop and the lines so that the code looks like this: Script Branch: Repeat: Variable 'Class Number' = -1 Text: Message 'Which class would you like information about?' Input: Display Class Info Text: Clear Message Text Content: Display Description Class (When Called) Wait 30F Text: Clear Message Text: Message 'Have you decided on a class?' Input: Class Change List Text: Clear Message Script: Branch End This will cause the system to check whether the player chose 'No Class' (which is now 'Help'), and if they did, it will show the Class Descriptions and then ask the player to choose a class. The player can choose 'Help' as many times as they need. Many thanks, Tarendol, you've put the 'No Class' option to good use. -----Other Methods - Allowing the Player to Choose the Class Path----- Rather than giving party members default class paths, assume you want to let the player decide which path each party member will take. This process is much more complicated than simply setting up dummy classes and assigning them to players. You must create a Script that allows the player to choose which type they want their characters to be. Be forewarned... this script is nearly 60 lines long! Any mistakes could be hard to find and correct, so make sure you're doing everything correctly. In this example you have three starting characters: "Member0", "Member1", and "Member2". They all start out as 'No Class'. There are three possible class paths: 'Warrior', 'Wizard', and 'Cleric'. The dummy classes are 'Warrior Path', 'Wizard Path', and 'Cleric Path'. Assume all paths and dummy classes are set up correctly. Use the 'All Party Members - Individual Class Paths' guidelines to set the classes up. The event you are about to set up asks the player to choose a class path for each character, and then assigns the appropriate dummy class and exclusive class to each character. Data: Flag" 'Cancel Menu' OFF Script Branch: Repeat: Variable 'Member Number' < +3 Data: Get Member Name Text: Clear Message Text: Message 'You must choose a class for ' Text Content: Input: Display 'Common Name' Text: Message ':' Input: Multiple Choice 3(X,X) 'Warrior'Wizard'Cleric' Script Branch: Condition: Variable 'User Choice' = +1 Script Branch: Sort: Variable 'Member Number' Script Branch: Apply If: Number is +-0 Member Info: 'Member1' Class = 'Warrior Path' Member Info: 'Member1' Class = 'Warrior' Script Branch: To End Script Branch: Apply If: Number is +1 Member Info: 'Member2' Class = 'Warrior Path' Member Info: 'Member2' Class = 'Warrior' Script Branch: To End Script Branch: Apply If: Number is +2 Member Info: 'Member3' Class = 'Warrior Path' Member Info: 'Member3' Class = 'Warrior' Script Branch: To End Script: Branch End Script: Branch End Script Branch: Condition: Variable 'User Choice' = +2 Script Branch: Sort: Variable 'Member Number' Script Branch: Apply If: Number is +-0 Member Info: 'Member1' Class = 'Wizard Path' Member Info: 'Member1' Class = 'Wizard' Script Branch: To End Script Branch: Apply If: Number is +1 Member Info: 'Member2' Class = 'Wizard Path' Member Info: 'Member2' Class = 'Wizard' Script Branch: To End Script Branch: Apply If: Number is +2 Member Info: 'Member3' Class = 'Wizard Path' Member Info: 'Member3' Class = 'Wizard' Script Branch: To End Script: Branch End Script: Branch End Script Branch: Condition: Variable 'User Choice' = +3 Script Branch: Sort: Variable 'Member Number' Script Branch: Apply If: Number is +-0 Member Info: 'Member1' Class = 'Cleric Path' Member Info: 'Member1' Class = 'Cleric' Script Branch: To End Script Branch: Apply If: Number is +1 Member Info: 'Member2' Class = 'Cleric Path' Member Info: 'Member2' Class = 'Cleric' Script Branch: To End Script Branch: Apply If: Number is +2 Member Info: 'Member3' Class = 'Cleric Path' Member Info: 'Member3' Class = 'Cleric' Script Branch: To End Script: Branch End Script: Branch End Data: Variable: 'Member Number' = 'Member Number' + (+1) Script: Branch End Data: Flag: 'Cancel Menu' ON Explanation: First, you turn the 'Cancel Menu' Flag OFF. This will keep the player from cancelling out of the Multiple Choice window later. If the player cancels out of the window, the game will not assign any class to the member who was skipped. You then set up a loop that will go from 0 to 2 (the player numbers of the players you want to assign classes to). This can be changed depending on which players you want to assign class paths to. Within the loop, you want to ask the player to assign a class path to each member of the party. In the Multiple Choice line, (X, X) is just the coordinates of the Multiple Choice menu. You can place the menu wherever you like. The conditions are 'User Choice' (which tells the game which option they picked) and 'Member Number' (which tells the game which member to assign the class path to). Note that the Script assigns the dummy class first and the exclusive class second, so that the player ends up in the exclusive class. The last step in the loop is to add 1 to 'Member Number'. This is so that the game will go to the next member. This can also be changed depending on the party members you wish to assign a class path to. This Script can be simplified a lot if you are only dealing with one member. You can leave out the condition checking 'Member Number' and also take out the additional Script Branches that deal with other members. In the case of multiple dummy classes, be sure to assign all appropriate dummy classes before assigning the exclusive class. The order of dummy classes does not matter. ---------------------- Special Class Examples This section is about Class changing without using the default Class List. The only example so far uses Accessories to change Classes. Credit for the idea goes to Neo3, although I wrote the Script. What you need to do is create an Event and a Script to go along with the Accessory that will change the party member's Class. Assume that Member 00 is named 'Guy'. Assume that Member 01 is named 'Girl'. Assume that Member 02 is named 'Dog'. Assume that you are changing the party member's Class to Warrior. The Script will look like this: Data: Member Info: Load Text: Message '' Text Content: Input: Display 'Common Name' Text: Message ' has become a Warrior!' Script Branch: Sort 'Member Number' Apply If: Number = 0 Member: Change Class: 'Guy' to 'Warrior' Script: To End Apply If: Number = 1 Member: Change Class: 'Girl' to 'Warrior' Script: To End Apply If: Number = 2 Member: Change Class: 'Dog' to 'Warrior' Script: To End Script Branch: End And that's all for the Script. All you're doing is checking to see who is equipping the Accessory and changing their Class appropriately. You'll need to make the Event a System Event and put the Script in the Apply Spot. Then go into the Item Editor, Edit the Accessory, and in the Advanced Tab, there is a slot for an Equip Event. Put the Event you made in that slot. That's all there is to it. Now anyone who equips the Accessory will become a Warrior. Also, you should make it so that no one can remove the Accessory. If they can, then everyone in the party can be the same Class without wearing the appropriate Accessory. You can either set up a menu in the Square button, or use the User menu in the Default Menu to remove the Accessories. You could also set up a shop or something similar that the player has to visit to remove Accessories. Then, during the removal process, change the party member's Class to 'No Class' or some generic Class. As with the other Examples, this can be used in conjunction with the default Class List. If you simply give all the Classes that are restricted to Accessories a requirement of a dummy Class, then the Classes will never be in the default Class List. And in this case, you don't have to worry about giving anyone Rank in a dummy Class, either. ------------------- Additional Comments If you find that any information contained within this FAQ is inaccurate, contact me at my email address and let me know. If you have a different method for setting up Exclusive Classes and you would like me to add it to my FAQ, email me. If I decide to add it to the FAQ, I will give you full credit, either by your email address, real name, or both. If several people email the same method to me, the first person I recieve it from will get full credit. Everyone else will be mentioned in the Acknowledgements below. If you use my FAQ to set up code or classes within your game, a simple mention of my FAQ in your game credits would be nice. ^_^ One line isn't too much to ask. If you thought my FAQ was not useful or did not address a situation that you needed help with (within the context of this FAQ), email me with suggestions. If all you can think of is "Your FAQ sucks" don't bother mailing me. If you email me and I don't respond, then I either didn't get your mail or I read it and it didn't require a response. I can lose email very easily since all mail from accounts not in my address book go straight to the junk mail folder. Once I know who you are, I might add you to my address book. If I happen to not get your email or not respond, don't email me demanding to know why I ignored you. That will likely make me ignore you. If you email me again and simply ask whether I got your mail or not (along with a copy of the email, because that'll help a lot), I'll respond. If you do intend to email me, make sure the Subject line tells me exactly what the email is about. Good subject lines would be: "RPGM2 Class FAQ" "Class FAQ Suggestions" "RPGM2 FAQ - New Method" or something similar. Bad subject lines would be: "hey", "hi", etc. "[no subject]" "BlueSenshi" "suggestions" "methods" and the list goes on. I get plenty of junk mail and I probably won't even see your email if it has a subject line like those. ----------------------------------------------------------- | Acknowledgments | ----------------------------------------------------------- Thanks to: EnterBrain and Agetec - For making and bringing RPGM2 to the US. RPGMaker Pavilion - For (hopefully) posting my FAQ. GameFAQs - For posting my FAQ and for that nice copyright statement. ^_^ Tarendol - Contributed the 'Help' menu idea. ButterbeanCD - For motivating me to experiment with the Class Shop Script before I really needed to. Everyone at the GFAQs and Pavilion Forums. The communities are developing nicely.