Mirror of Class Transmutation Class Modification Explanation

Although the Class Transmutation Hack changes the structure of the class system, the general algorithm for how classes are assigned hasn't been changed - minus one small exception - rather, the changes are mostly a result of changes to the Class Type table (which is essentially what gives the class system its structure).  However, I don't think it would be sufficient to *just* explain the changes to this table; in order to give an explanation that I think is satisfactory, I'll need to explain three things: 1. How classes are assigned in Golden Sun, 2. Vanilla Golden Sun's class structure, and 3. The Class Transmutation Hack's class structure.  However, if you happen to already know about Golden Sun's class system inside and out, you should be able to skip right to Part 3.

Before I begin, let's quickly make note of some elemental relationships, because these turn out to be important in a few ways.  Every element has a "symbiotic" element - Venus and Mars are symbiotic with each other, and Jupiter and Mercury are as well.  Every element also has an "opposite" element - Venus and Jupiter are opposite, as are Mars and Mercury.  For each element, this leaves one remaining element which they bear neither relation to, i.e. Venus is neither symbiotic with nor opposite to Mercury; Mars and Jupiter are the other pair.  I call these "antisymbiotic" elements, and have also seen them described as "neutral" elements in the fandom.

**Part 1. How classes are assigned in Golden Sun**

In this section I'll explain how the game decides which class each Adept should be in.  I'll try to keep this section concise; as a result, I might gloss over some details.  For more detailed info on this topic you can check out this post and the rest of that thread (finding it was a *huge* help when creating this hack - big thanks to Atrius and everyone who contributed to that thread).

To assign a class to an Adept, the first thing you need to do is find their "eLevel" in each element.  An Adept gets 5 eLevels in their innate element, and then for each Djinn they have set, they get +1 eLevel in the corresponding element.  For a quick example, Isaac with 1 Venus Djinni and 3 Jupiter Djinn will have 6 Venus eLevels, 3 Jupiter eLevels, and 0 Mars and Mercury eLevels.

Next, you need to find their highest and second-highest eLevels - I call this their "eLevel ranking".  There is a special case here - if an Adept only has one eLevel which is 1 or higher, that element will count as *both* their highest *and* second-highest eLevel.  Using Isaac with the same Djinn as the previous example, his highest and second-highest eLevels are Venus and Jupiter respectively.

If two eLevels are equal, the tie is broken in a consistent way based on the innate element of the character.  Their innate element is prioritized the highest; after that is the element that's 'antisymbiotic' or 'neutral' to their innate element; after that is the element opposite to their innate element, and finally the element symbiotic to their innate element is prioritized the lowest.  The way this is actually achieved in the game is by simply giving each character decimal eLevels, e.g. Isaac actually innately has 5.4 Venus eLevels, 0.3 Mercury eLevels, 0.2 Jupiter eLevels, and 0.1 Mars eLevels.

Once you've found the eLevel rankings, you simply need to consult the Class Type table to see what the Adept's Class Type will be.  For instance, checking the table will tell you that a highest eLevel of Venus and a second-highest eLevel of Jupiter puts an Adept in Class Type 5.  A "Class Type" is a broad category of classes which usually contains several Class Series (which themselves contain several classes).  For example, in vanilla, both of the two Pilgrim class series as well as the Ranger series all share the same Class Type.  This Class Type table is essentially what determines the structure of the class system; in parts 2 and 3 I'll go into what I mean by this, and what that structure looks like in both vanilla GS as well as the hack.

Now that you've assigned the Adept a Class Type, it's now time to actually assign them a class from the class list (i.e. the list of every single class in the game).  Each class has its own Class Type as well as a list of eLevel requirements.  If an Adept was assigned the same Class Type as the class, and they meet the eLevel requirements for that class, then they are qualified for that class; Adepts are ultimately assigned to the last class in the class list which they are qualified for.  This means class assignment is technically somewhat dependent on the order that classes are listed in within the game.  In practice, this Adept's will be assigned the class of the highest possible tier within a class series, and prioritizing 3-element class series over 2-element ones, because classes are listed in ascending order of tier within their Class Series and 3-element classes are always listed after 2-element classes within their Class Type.

One thing that's important to understand about this system is that meeting the eLevel requirement for a class isn't enough - the Class Type also has to match too, and the structure of the Class Type chart is *not* necessarily such that these two factors will coincide - there are a fair number of cases where Adepts meet the eLevel requirement for a class but can't access it due to Class Type.

So, to review all of this - an Adept's highest and second-highest eLevels are found.  These are used to assign them a Class Type based on a table.  They are then placed in the 'strongest' class which their Class Type matches and for which they meet the eLevel requirements.

**Part 2. Vanilla Golden Sun's class structure**

While part 1 describes the algorithm for assigning classes, the actual structure of the class system is determined by the nature of the Class Type table, as well as what sorts of classes actually exist within the game.  This section will describe that structure, as well as some of its consequences, and how these consequences inspired my hack.

I think it will be more clear what I mean once we have a look at the Class Type table as it is in the vanilla games: (small note - in the actual code it's in a slightly different order, but I find it to be more natural to be listed this way)

There are many things to notice about this chart.  The first thing I want to point out is that the only combinations of elements with *unique* Class Types are the ones with the same element in the highest and second-highest position.  Recall that these correspond to having only one eLevel that's at least 1, which means that these Class Types - 1, 2, 6, and 7 - are the Class Types corresponding to mono-element classes (since the only way to avoid raising any other eLevel above 0 is to only set Djinn corresponding to the Adept's innate element).

All other Class Types are 'shared', in the sense that there is always more than one combination of highest and second-highest element which will lead to that Class Type.  E.g. Class Type 9 results from either Jupiter 1st and Mars 2nd, or Mercury 1st and Mars 2nd.  There are two patterns for how Class Types are shared, and they're actually based on symbiotic pairs.  Let's look at these one at a time.

If both of an Adept's highest and second-highest eLevels are symbiotic with each other, then they'll be put in a Class Type corresponding to that symbiotic pair, *regardless* of which order the elements are in.  For instance; Venus and Mars are a symbiotic pair; whether an Adept has Venus 1st and Mars 2nd, or Mars 1st and Venus 2nd, they'll be placed in Class Type 4.  Note that the two symbiotic pairs are the only case where this is true - in other cases, reversing the order of the elements changes the class type.

The rest of the 'shared' Class Types are a bit stranger.  Two combinations of non-symbiotic pairs of elements will share a Class Type if their second-highest element is the same, and their highest element is from the same symbiotic pair.  This is complicated to describe in words, but I think it's actually fairly easy to see by just looking at the chart - Class Types tend to line up vertically, meaning they have the same second-highest element, but different highest elements.  For instance, Venus 1st Jupiter 2nd is Class Type 3, and Mars 1st Jupiter 2nd is also Class Type 3 - they have the same second-highest element and symbiotic highest elements.

The way 2-element classes work in-game corresponds pretty neatly to these relationships - because of this, I think that exploring the class structure in terms of 2-element classes and how Adepts can access them is a natural way to explore the Class Type Structure.

If Isaac sets Mars Djinn, he'll be in the Brute series; if Garet sets Venus Djinn, he'll also be in the Brute series.  They share this class series because the Venus/Mars symbiotic pair assigns Adepts to the same class type regardless of which order the eLevels are in.

Meanwhile, if Isaac sets Jupiter Djinn, he'll be in the Apprentice series.  If Garet sets Jupiter Djinn, he'll be in the Page series, which is a very similar class series to the Apprentice series, sharing many Psynergy and the same stat bonuses.  This is because the Apprentice and Page series are in the same Class Type.  Indeed, all of the similar class series are in the same Class Type; both Seer series share a Class Type, as do both Pilgrim series, etc.

While Isaac with a few Jupiter Djinn set will be in the Apprentice class series, Ivan with a few Venus Djinn set will be in the Seer class series.  This is because Venus and Jupiter are not symbiotic, so they don't 'share' a Class Type - Venus 1st and Jupiter 2nd puts an Adept in a different Class Type than the other way around.  However, this has an interesting effect - if Isaac sets 6 Jupiter Djinn, his Jupiter eLevel will be 6 and his Venus eLevel will be 5, meaning his eLevel ranking will flip, and thus he will become a different Class Type and switch from the Apprentice series to the Seer series.  This is why "Partial Classes" exist for all non-symbiotic elements - if an Adept sets enough Djinn of a non-symbiotic element, their Class Type will change to reflect that new element now being in 1st place in their eLevel ranking.

Based on all this, one way to characterize each Class Type (not counting the mono-element Class Types) is that each Class Type corresponds to an eLevel ranking of the following format: In first place, one of the elements from a particular symbiotic pair; in second place, either a particular element outside the symbiotic pair, or the other element in the symbiotic pair.  Again, this is awkward to describe in words, but if I list each Class Type, I hope it will become clear what I mean:

Venus or Mars first, Jupiter second = Class Type 5 = Apprentice and Page series

Venus or Mars first, Mercury second = Class Type 3 = Both Swordsman series

Venus and Mars first *and* second (in either order) = Class Type 4 = Brute series

Jupiter or Mercury first, Venus second = Class Type 8 = Both Seer series

Jupiter or Mercury first, Mars second = Class Type 9 = Both Pilgrim series

Jupiter and Mercury first *and* second (in either order) = Class Type 10 = Hermit series

Now, let's look at 3-element class series.  Of course, access to these classes is also impacted by the Class Type structure.  But to understand what sorts of 3-element classes exist and how to access them, I think it's better to look at some particular examples rather than to simply sort the existing classes into Class Types.  So, this time, I'm going to focus in on two particular class series to use as an example - the Ninja and Samurai class series.  Both of these class series have the same combination of elements - Venus, Mars, and Jupiter.  The Samurai series is Class Type 4, meaning it's in the same Class Type as the Brute series.  Ninja, on the other hand, is Class Type 5, meaning it's in the same Class Type as both the Apprentice and Page series.  This has some interesting implications in terms of which Adepts can access these class series.

Let's start with Ninja - in order to access the Ninja series, an Adept needs to be in Class Type 5, which means that they need to have either Venus or Mars as their highest eLevel, and Jupiter as their second-highest eLevel.  Then, of course, they also need to meet the eLevel requirement, which requires 3 eLevels in each element.  Venus Adepts can achieve this pretty easily - their Venus eLevel is innately their highest, so all they need to do is to get Jupiter into second place and then set enough Mars Djinn to meet Ninja's requirements.  Setting 3 Jupiter Djinn to get Jupiter into 2nd, and 3 Mars Djinn to meet the eLevel requirement will do the trick.  For Mars Adepts, it's the same story - just with Mars and Venus reversed.  But for Jupiter Adepts, it's different.  Since they innately have 5 eLevels in Jupiter, they need to set a whopping 6 Djinn - either 6 Venus Djinn or 6 Mars Djinn - in order to raise the corresponding eLevel high enough to be in first place in order to be in Class Type 5.  Then, in order to satisfy the eLevel requirements for Ninja, they need to set 3 more Djinn of the remaining element, which is 9 Djinn total.  This is why Jupiter Adepts can access Ninja as a weird partial class in two different ways with a whopping 9 Djinn - unlike the other Adepts who can access Ninja, they need to get a non-innate eLevel above their own, which can be either Venus or Mars.

The Samurai series is a similar story, but it's even worse for Jupiter Adepts.  Samurai is Class Type 4, which requires Venus and Mars to be the highest eLevels in either order.  Again, Venus and Mars Adepts can do this easily, since both of their innate elements already work towards this requirement.  But for a Jupiter Adept to access Samurai, they would somehow need to raise *both* their Venus and Mars eLevels above their Jupiter one, which would require 6 Djinn of *each* element, i.e. 12 total, which is impossible.  So Jupiter Adepts can't even access Samurai as a partial class like they can access Ninja (unless you use cheats, hacks, exploits, etc to give them 12 Djinn).

This is how 3-element classes work in general - out of the 3 elements involved, the symbiotic pair is the most important, and one element from that pair needs to be the highest eLevel in order to reach that class.  Then, either the third element OR the remaining element in the symbiotic pair needs to be in 2nd.  Finally, since a third element is still required (these are 3-element classes after all), you can think of that remaining element as being the third-place eLevel.  To illustrate this, here's a list of all the 3-element classes in the game and their corresponding eLevel rankings:

The pattern established here really seems to suggest that the following two class series should also exist - and they'd be really easy to add in if you designed them - but... they don't exist, for whatever reason.  Some hacks do add in these class series, however, such as the popular Reloaded hacks (which do a quite good job coming up with class series for these spots, in my opinion):

 "Missing" Class Series
 "Missing" Class Series

To summarize, 3-element classes - like the Class Types they belong to - are characterized by their symbiotic pairs.  An Adept can only fully access a class if their innate element is in the class series' symbiotic pair.  Adepts of an element NOT in that symbiotic pair only have partial access to those classes *at best*.  Every symbiotic pair has only 3 corresponding 3-element class series, which means that each Adept only has full access to 3 different 3-element class series (or 4 if those 'missing' class series were added).  This always struck me as too limiting - there are so many ways to combine elements that each Adept only having access to 3 seemed unnecessarily limiting to me.  This fact was notably the main inspiration for the Class Transmutation Hack.

**Part 3. The Class Transmutation Hack's class structure**

The changes to the class system in the Class Transmutation Hack are mainly due to a total overhaul of the Class Type table.  Here is the table as it appears in the hack:

The most important thing to notice with this new table is that there are NO 'shared' Class Types - that is, every combination of highest and second-highest eLevels has a unique Class Type.

What this means is that the class system's structure is no longer based on elemental symbiosis to any extent.  This has several effects.

One effect is that 2-element class series are no longer shared between Adepts of different elements.  Whereas in vanilla, Isaac with Mars Djinn and Garet with Venus Djinn would both be Brutes due to a shared Class Type, they now each get their own class series - Isaac with Mars Djinn will be in the new "Scavenger" class series, while Garet with Venus Djinn will be in the class which has inherited the "Brute" name.

A directly corresponding effect is that Adepts now have "Partial Classes" for each possible element they can set.  For instance, Isaac can access the higher tiers of the "Brute" series if he sets enough Mars Djinn to overcome his innate Venus eLevels.

In general, this all means that the structure of 2-element class series is the same for all pairs of elements, rather than having special behavior for symbiotic pairs.

Although 2-element class series are no longer shared between Adepts of symbiotic elements in this hack, 3-element class series notably *ARE* still shared somewhat, though doing this required a little trickery.  Indeed, the sharing of 3-element class series was one of the advantages of the way the original games implemented things - for instance, Venus Adepts and Mars Adepts could painlessly share their 3-element class series - namely, Ninja, Samurai, and Dragoon - without issue.

Achieving this required a change of how 3-element classes are defined.  As described in Part 2, in vanilla GS, 3-element classes were essentially defined by a symbiotic pair as their primary element and another element as their secondary element.  This concept has been sort of 'generalized' in the Class Transmutation hack - now, each 3-element class is defined by *a* pair of elements as their primary elements, plus another tertiary element; however, the primary pair of elements does not have to be symbiotic.

One way to think about this is that while vanilla had "Venus-Mars" classes and "Jupiter-Mercury" classes, the Class Transmutation Hack has more diversity - it has "Venus-Mars" classes, "Venus-Jupiter" classes, "Venus-Mercury" classes, "Mars-Jupiter" classes, "Mars-Mercury" classes, and "Jupiter-Mercury" classes.

This results in both an increase in the total number of 3-element classes as well as opening up access to more 3-element classes for each Adept.  The reason why is that Adepts no longer need to include their symbiotic element in order to access a 3-element class.  For instance, in vanilla, a Jupiter Adept like Ivan could only access the three 3-element classes with the Jupiter-Mercury symbiotic pair as their primary element.  But now in the Class Transmutation hack, Ivan can access six different 3-element classes - two for the Jupiter-Venus pair, two for the Jupiter-Mars pair, and two for the Jupiter-Mercury pair.

Here's a chart listing every 3-element class in the Class Transmutation hack and their corresponding eLevel rankings; compare this chart to its counterpart in Part 2:

In order to actually achieve this, I needed to use one little trick - which is hinted at in the chart.  With the new Class Type table, having Element A in 1st and Element B in 2nd will always lead to a different Class Type than with A and B switched around.  This presents a problem for defining 3-element classes by a pair of elements, because each pair of elements has TWO corresponding Class Types - one with each element of the pair in 1st and the other in 2nd.  I solved this in a pretty cheeky way - I simply made two copies of every single 3-element class, and assigned each of the copies to one of the two Class Types corresponding to its elemental pair.  (Camelot themselves actually used pretty much the same trick before I did - in Dark Dawn, Sveta is only able to access the Medium class series because an exact copy of it was put into one of her character-specific Class Types)

In addition to these significant changes to the class list and the Class Type table, I also made a few other changes which affect class assignment which I should also mention.

First, in vanilla GS, Jenna and Piers have unique mono-element classes.  Basically, if they would be in the usual mono-element Class Types, they are instead put in unique Class Types containing their own unique class series.  In the hack, I pretty much just did the same thing for Felix and Sheba so that they, too, have their own unique mono-element class series.

The one change I made is that across the board, ties in eLevel rankings are settled differently.  Recall that eLevel ranking ties are essentially settled by hardcoded decimal eLevel values for each Adept.  I rearranged all of these so that every Adept's innate eLevel would LOSE all ties instead of winning all ties, by setting every Adept's innate eLevel to 5.0 instead of 5.4.  This basically only has one important effect - it means that Adepts can access partial classes slightly earlier, since it now only takes 5 Djinn instead of 6 in order to reverse an Adept's eLevel rankings in favor of the other element.

This concludes my explanation of the class system changes.  This was supposed to be a """concise""" explanation, but it turned into a right ol' mess, so thanks for bearing with me if you bothered to read the whole thing, haha.