Topics

[Class data table]

Here are some suggestions for how to build Golden Sun's class system in a way that circumvents some design/functionality limitations imposed by the original methods. They're mainly aimed at those who want to make or are working on GS fangames or other GS-based games, though GSHC still seems like the most suitable place to put it on and refer to. And there's nothing stopping you from hacking this into the original games, although that may not be the most practical...

I'll start with the "how" and touch a bit on the "why" as I go. Occasionally I will refer to the original methods, but I don't think it's necessary to be familiar with them in order to follow this. The concept of elemental levels (may be abbreviated as eLevel) is still central, these can practically be thought of as the amount of djinn a character has equipped (set), e.g. one Mars djinni would add one Mars level. And in case anything is unclear, or if you think these ideas are bullshit or don't work, I'll have a Q/A section at the end.

It should be noted that the algorithm for assigning classes would be functionally identical to what it is in the GS series, only the arguments differ. Perhaps the main distinction is that originally, each entry in a class "line" has their own data set, whereas this will be based around the idea that each class is treated as a single object, with parameters (stats and abilities) that improve with higher eLevel.

Class data table

• Elemental level requirements
• Stat modifier table
• Ability table
• (Class name list)
• (Effect vulnerability list)

Each playable character would have 4 accessible class IDs assigned to them, with the one to actually be used being determined by which of their eLevels is the highest. They would also have a list defining elemental prioirity in case of ties. Consequently all of their potential classes can be either entirely unique or shared with other characters on a case by case basis.

Class IDs:

• Venus level highest
• Mercury level highest
• Mars level highest
• Jupiter level highest

Elemental priority value:

• Self = 4
• Opposite = 3
• Neutral = 2
• Affinity = 1

Opposite: Venus to Jupiter, Mercury to Mars
Neutral: Venus to Mercury, Mars to Jupiter
Affinity: Venus with Mars, Mercury with Jupiter

To determine which class ID should be used, do [(eLevel * 5) + priority] for each element and use the element which gets the highest resulting value.

The class ID refers to a list of classes, or just a single class as may often be the case with base classes. Once the ID is obtained, check each entry of that list until one meets the eLevel requirements, that class then gets assigned to the character. Entries should be ordered so that classes with higher eLevel requirements are checked before those with lower.

This method removes two quirks from the original system, the first being that classes with lower eLevel requirements could override those with higher, the most prominent example being base classes - add one djinni of any other element, and suddenly you're in a tier 1 class even though you have enough djinn for tier 5. The other one is "spillover" classes which could result from an element with a level of 6 or higher effectively being treated as the character's primary element. Though if one still wanted that functionality, it could be recreated and designed for in this system.

Originally, characters start with 5 base eLevels (no djinn equipped) of their own element. This system assumes they do not, and as such, the djinn requirements for tri-elemental classes would have to be changed a bit if you want them to be "truly" shared between characters, i.e. to avoid defining the class twice with different eLevel requirements. More specifically, they would need to have eLevels (djinn) of their own element in addition to the other two. On the flip side, this does offer the option to do that for some slight class variations while still sharing the same ID (group).

Edit: another workaround to enable shared tri-elemental classes would be to either add the 5 elemental base levels but disregard them when checking highest element, or to add them only to the check for class requirements. Both of those options would require the base element to be defined in the character data.

Stat modifier table
Two values would be defined for each stat, base modifier and eLevel modifier. The actual modifier for a given stat would be obtained by [baseMod + (eLevelMod * total eLevel)]
In other words, each equipped djinni, regardless of element, would contribute to the stat modifiers as defined on a per-class basis. This has the benefit - or drawback - of enforcing a more even stat scaling based on djinn equipped, you do not get the jumps of the original system.

An alternative that would be similar to the original mechanics is to instead refer to a table where each entry is a set of stat modifiers, and where the entry to be used corresponds to total eLevel (+1 if not 0-inclusive). For the record, this is basically how Golden Sun assigns eLevel-based elemental power and resistance bonuses. This would enable the uneven scaling as seen in some classes.

Anyway, I believe that basing stat modifiers on total eLevel may help make class changing a bit less intimidating for players who are not very familiar with the system, as it grants stat boosts for each djinni equipped rather than having to conform to arbitrary element combination thresholds. It would also make changing classes in battle more tactically viable, same for using summons with multi-elemental classes. Which specific method to use is mainly a question of design philosophy.

Ability table
Each entry would have the following fields:

• Ability ID
• Level learned
• (Element)
• Min. eLevel
• (Max. eLevel)

Basically, the advanced class abilities would require the user to have sufficient eLevel rather than being in a specific class tier. This also opens up some new opportunities, mainly that it allows classes to conditionally have abilities of elements they would normally be unable to use. That would also make it seem more like individual djinn grant additional abilities when equipped.

Element can optionally be defined to know which eLevel to check, or it could be fetched from the ability data.
Max eLevel can optionally be defined for "upgrading" abilities, e.g. Ragnarok to Odyssey.
One could even have fields for min/max requirements in all four elements, which would allow for compound elemental abilities (plasma could be wind/fire, growth could be earth/water, etc). Just a thought, probably not something I'd do personally.

Class name list
Class names have always been a design headache to me, having to come up with several different names for a role that is fundamentally the same is bound to result in some reaching on occasion. Nevertheless there is the familiarity factor, and one may want to use the names as a means to telegraph the increased mastery of a role. For these reasons, I'll include methods for having named class tiers that are compatible with this system. Even so, having 5 or 6 different names for the same class seems a bit ridiculous, surely it would be enough to have 3 for standard classes and at most 2 for complex, multi-elemental classes.

A simple method would be to just take the "main" elemental level of the class and use that to check a list of [value, name], where if eLevel >= value then assign name.

For stricter and more flexible naming, one could instead use a list of:
[Venus Lv, Mercury Lv, Mars Lv, Jupiter Lv, name], i.e. exactly how Golden Sun already assigns classes but used for names only.

Effect vulnerability list
This is a somewhat peculiar part of class data in Golden Sun that a lot of people probably don't know about. Basically, up to 3 effect values can be listed, which makes the class more susceptible to fail resistance checks against those effects. I figure if you wanted classes to actually have individual effect weaknesses and/or resistances, you could put a simple list here with [effect, argument]. The argument could be a multiplier or it could be used however you want really, it depends entirely on the implementation of effect/ailment resistance checks.

All that said, having this at all is highly optional - but if you do include it, at least display it somewhere on the character status screen so that players have a fair chance to be aware of it.

Q/A

Q: Just four classes per character? You could have much more than that in Golden Sun.
A: I have a feeling this might come up, so I'll address it right away. The class ID value is just part of the sorting method; tri-elemental classes are defined by their eLevel requirements but still have a primary element, such as the Ninja which is a Jupiter-based class that requires both Venus and Mars levels, or the Dragoon which is the same but Mercury-based.

I've been asked to share a message from Adept's Refuge with everyone here. It's all explained in the message, so I'll just get right to it.

Hi everyone!


I am What? from Golden Sun Adepts Refuge


Maybe it's been a while since you last posted. Or surely, it's been a while since you last posted a lot. So get your typing fingers ready because, coming this December, we invite you to join us for our first ever inter-GS-forum post bomb. On Saturday, Dec. 19, we challenge you to post as much as you can (without spamming, of course!) across any or all of the GS forums (see the list of participating forums below). Meet new people! Fire up new conversations! Find a new niche! Together as a GS fan community, let's crush our previous posting records!

Participating forums as of now!:
Golden Sun Adepts Refuge
The Temple of Kraden
GoldenSunrise (very likely to confirm)
More forums to join in!


If you are interested we can add you to the list!
Also any questions you can ask Me or Kirigishi from GSAR

Very likely I'd be able to answer those questions too, though I doubt there would be any. Well that's all, peace out.

[Background]

Background

Summons - or more specifically, summon rushing - is often cited as a game breaker in Golden Sun, especially in the second game. I've already commented on what I see as the main reasons for this, so I'll just quote myself:

I wouldn't say the balance issue is that summons are too strong against high HP bosses - rather, the issue with them doing HP% damage is that you can have access to them instantly, i.e. summon rushing. More specifically, the later parts of The Lost Age has mechanics that mitigate the balancing factors of summon rushing. Those are:
-Multi-element summons (feed a higher amount djinn into an attack of the desired element)
-Backup party (bypass the class penalty)
-Ability to carry up to 18 djinn of every element (summon costs become considerably less restricting)

This naturally means that you can defeat any enemy with little regard to character levels, equipment, classes, or anything really.

As I also mentioned in that thread, there's really no best way to balance them. Since summons do damage that scale with the target's max HP, they can be very useful in boss battles without overkilling randomly encountered enemies, through the entire game. Relative elemental power also contributes significantly to the final damage, since it's a multiplier stacked on top of another multiplier, so this also increases the value of elemental power. While it's possible to reduce or outright remove the HP% damage, this takes away from the main function of summons. So, I've tried to think of alternatives.

One kind of solution

What I've been thinking about is making it so only djinn that have been set to standby in battle (by unleashing them) can be used for summons. This would make summon rushing simply not work, but without affecting any other playstyle. You could still use summons normally, and you could still leave leftover djinn on standby to avoid messing up your class.

The idea is to add the cost of a character action for every elemental level you make available for summoning, instead of getting a potential 72 levels in 0 actions on the first turn.

The simplest way I can think of to do this (without causing unnecessary gameplay restrictions) is to keep track of how many standby djinn of each element each character entered the battle with, and prevent that amount from being used in summoning until they are set manually.

The drawback of this method? The game never stated that you shouldn't be able to use summons because you put the djinn at standby a specific way (manually from the menu). But then again, they probably didn't account for the high number of djinn you could potentially get, at the time the system was created. And there's also the fact that the code might be a bit complex... which is why I would like some opinions on how feasible this seems.

Implementation

I'll just give the general concept for this, since I'm honestly pretty awkward at working with ASM (read: I have basically no idea what I'm doing), and just making sense of the summoning function alone would take me forever.
Note: "elemental levels" in this post exclusively refers to djinn costs for summoning, not elemental levels on the characters

First, we'll obviously need to keep track of how many standby djinn of each element every character enters battle with. This data can be stored in 16 bytes by using each byte for the djinn of two elements for a character (unless you wanted them to have more than 15 djinn each for some reason). I assume it would best be stored in RAM. So we need a function that writes to whatever location we assign for this, based on the character djinn data at 0x02000B48. This function should be run only at the start of battles.

Now, when the elemental levels available for summoning are determined (which I have no idea when or how it happens), subtract a number (will usually be 0 though) from each element according to the data we just created, from the currently active party members (not backup party). The result of this is what the summon should check for at the time of execution.

If the function for summoning works the way I hope it does, this would also set the "preview" of available standby djinn to their effective values, as well as prevent Valukar from summoning your djinn before you have unleashed them (or before he has set them to standby with Djinn Stun).

Also, whenever a character uses the "set" djinn command in battle, the "standby djinn counter" we created should be decremented by 1, assuming the value for that element on that character is greater than 0.

I think this should work, but of course it's possible I have overlooked something. Feel free to ask if I've been unclear about something, or neglected to mention something. Other questions, comments or suggestions are welcome as well.

For anyone new to Golden Sun, be aware that this thread will probably contain a lot of spoilers for all games in the series.

The ending of Golden Sun: The Lost Age, while concluding the main quest of the game, left players with more than a few loose threads and unanswered questions. For a time, a sequel showing the world of Weyard after the unsealing of alchemy was highly anticipated. However, when a sequel finally appeared, it was designed as a game independent of the previous two and mostly aimed at new players, and in many ways, wasn't quite what the majority of the old fanbase was hoping for.

So, if you were making a sequel to the second installment of the series while disregarding the events of the canonical sequel Dark Dawn, how would you design it? How would the story play out? This doesn't have to be ideas that could work in a hack, and it doesn't have to be related to the community project... this is essentially a brainstorming thread, and is relevant to Golden Sun in general.

I do have a few points and ideas to bring up that I have probably written down somewhere... I might post those later.

I created this topic mainly because the one in Dimensional Crisis subforum wasn't really meant for plot discussion and had an awkwardly long title. If you have an idea specifically for the community hack, it's better to present it in a new topic in Dimensional Crisis General or Storyline. But please, only do this if you have an idea you have faith in and that is developed enough to function as the basis for a game.

Looking at some discussion about debuffs and the likeliness of inflicting status effects in the class ideas topic, I was reminded I've been hoping for a long time that someone would shed light on the matter. We know that luck affects it, but what about the actual formula? This could be a suggestion for the editor as well, it's likely to be something one would want to change in the game, as status effects are prone to becoming either broken or useless unless you balance them perfectly. The current debuffs wear off quickly and aren't even guaranteed to work, making them little more than a waste of a turn.

Here are my ideas for a Golden Sun hack I started long ago. It's currently no more than a game balance adjustment with aesthetical changes, but if map editing through the editor becomes available it's likely I'll try to make something of it. If you're interested/patient enough to read through this, all criticism and opinions are greatly appreciated. Everything I plan to implement so far has been successfully tested, save for enemy resistances. Expect "new" skills, animations, equipment, classes, enemies... the works.

I've distributed stat bonuses to the classes, and I'm currently working on ability strength, distribution and PP cost, which I should be able to provide some good initial values for by using expected character stats for reference. Abilities, equipment and enemies will need a lot of testing of course, so nothing is really finalized, and this will mostly serve as an introduction (I doubt the class descriptions would fit anyway). If I haven't managed to scare you away by now, read on!

First of all, the four elements have new themes (except for earth) and slightly different properties, and are made to be more unique in terms of abilities. Note that I haven't changed any text or plot points to reflect this, though I suppose I could remove a lot of dialogue since it serves little purpose for this hack. This game normally has about two hours worth of unskippable cutscenes.

Elements:
[spoiler]
Earth
Makes the sturdiest fighters - attack, defense and HP are all high, and earth-based attacks are certain to hit those high HP monsters where it really hurts. However, PP gets a penalty, making them poor magic users, and they tend to be slow. They can raise defense and slow down enemies. They can give life (revive) or bring death. Lastly, they can break away the opponent's stat boosts.

Spirit
Has the strongest healing abilities, high luck and PP, good hp and defense, so they're ideal for keeping the party alive. They can protect the party from magical damage with wards and lower the offensive power of enemies. Other abilities are sealing away an opponent's magical abilities, purging the body of status ailments and drive out evil spirits. They can also summon spirits to their own aid. Their magic is powerful against undead monsters, but is limited to that, and their overall offensive power is the worst out of the four elements.

Chaos
The element of disorder, their high PP and agility coupled with good offensive power and wide range of spells means they excel at destroying their opponents. Their defense, HP and luck are all unimpressive though, making them prone to suffer damage themselves, and while they are the most powerful damage dealers, healing is nearly impossible for them.
They can increase the attack power of their allies and make enemies less resistant to elemental damage, and some of their attacks can cause paralysis.

Nature
Drawing their power from plants, animals and the moon, users of the nature element generally have a balanced set of stats (only agility and luck being above average), and a wide range of abilities. These abilities include healing, curing poison and status ailments, inflicting sleep, delusion and poison, HP and PP draining, regeneration, making allies faster, and reducing the defensive strength of enemies. They can also summon a variety of monsters. However, they aren't notably proficient in any field.

Note that when I say an element is effective against a type of enemy, that assumes I can edit resistances. I know enemies share sets of resistances, but I've also noticed in the editor that enemies have elemental levels, whatever purpose that might serve, so maybe it goes beyond that.

Anyway, what I have in mind for resistances is:
-High-defense monsters have proportionally high earth resistance.
-Chaos resistance is inversely proportional to defense - lower defense, higher resistance.
-Undead and "dark" type enemies have 0 Spirit resistance (if possible), others have 200.
-Nature is more or less neutral against most opponents.
[/spoiler]With that said, what I have in mind for this hack is:
-Make battles against normal enemies (and thus grinding) more interesting (more challenge, greater variety, more rewarding)
-Make all classes useful for the full range of levels, and rebalance the difficulty without changing the game's core mechanics. Ultimately achieved through extensive playtesting.
-Climb through the full range of levels, making the average player about level 80 at endgame/postgame. Increase the significance of levels.

I don't intend to make a "hard mode" type of hack, but rather change how the game is played. But of course, these changes include stronger and more numerous enemies, reduced healing ability, and other things to magnify the consequenses of the player's actions, so I guess it's technically harder.

Some stuff regarding the classes/game balance:
[spoiler]
-At some point I was going for a different organization in the class system, but unknown parameters kept screwing me over. ALL classes in this hack are currently edits of existing ones, the only change I've done to the class system is to remove a stage from the aligned element dual classes (Brute and Hermit lines in the original).

-Since there's no stat used exclusively for calculating magical damage, the effectivity of spellcasting-oriented classes is mainly decided by how frequently they can use their special skills. PP, in other words. There will be no PP restoring items. Expect more attack based spells even for mage-type characters, since the attack stat scales with level. This doesn't transfer well to wide area spells though, since the attack based add damage mod loses the diminishing damage effect for multiple targets, so they will still have to rely on base damage.

-Some higher classes have more powerful versions of their own psynergy series, based on the expected level the PCs will have upon reaching those classes.

-Bind uses the same effect as psynergy sealing djinn, giving it a perfect success rate.

-Pure stat down psynergies are not considered an asset to a class since they aren't even guaranteed to be successful, and even if they were, they would barely (if at all) contribute to a statistical advantage. As such, they are almost exclusively seen as secondary effects.

-No special djinni abilities. ALL djinn function as an EPA with 0.8x multiplier. That way you're still allowed to make djinn kills, but it's a bit harder than usual.

-No summons, there's simply no good way to make it balanced without completely changing the way they work, which I'm trying to avoid. Summon animations are used for fancy one-shot nuke style class exclusive killer moves instead.

-Unleashes are reduced to flashy critical hits with little impact on the game balance (much like in the first GS). They generally won't have a secondary effect, even most artifacts won't have them, and unless the weapon has an elemental affinity, the unleash will be elementless as well. After all, why use designated attack skills if you can get
them for free?

-The second party will not join you - you're stuck with four party members. On the flip side, there's no djinn blast/storm, since you can't switch characters out. 36 djinn will be obtainable. You will be playing as Felix, Jenna, Ivan and Mia (until I can make custom characters, if I haven't finalized the patch by then).

Some stuff on enemies and item drops:

-There will be many instances of enemies dropping non-artifact equipment, and other items that are mainly intended to be sold.

-Enemy experience/money rewards and item drops will be distributed depending on how close to a healing spot they appear. So enemies appearing on the overworld, for common instance, would be more work for less reward.

-No artifacts will appear *exclusively* as enemy drops (bosses are the exception).

-Enemy groups will generally be bigger. Also, several humanoids will be used as enemies.
[/spoiler]Coming up next: class stats and abilities.
Thoughts so far? I think it would be kind of hard to get an impression before seeing the classes...
anyway, stay tuned!

Hello everyone, nice to meet you. Even though I say that, I've been keeping an eye on this community since back when the editor was pretty new (How long has it been? 2 years?), checking it out from time to time. So, I'm feeling quite familiar with the forum regulars here, even if you have no idea who I am.

So who am I? An aspiring concept artist and game developer, spare time hacker/programmer and occasionally composer. Yeah, big claims that say absolutely nothing about my ability. Or my personality. See, at least I'm aware of it. I'm also a diehard Golden Sun fan. And Touhou fan. And various other kinds of fan as well. Anyway, I got started with ROM hacking a bit over 5 years ago with Super Metroid, and since then I've also been onto Pokémon Gold/Silver (if by any chance anyone has been to Metroid Construction, I made a brief appearance there almost a year ago).

As for Golden Sun hacking, back when it was new and hot I was working up ideas for a hack with a new story/setting, new characters, alternate elements, changed mechanics... then someday I read a post by Lishy presenting his ideas, and it dawned on me that my game had nothing to do with Golden Sun. So I started making plans for a completely new game instead (and I'm still at it). However, I just recently noticed that the GS editor now has fully functional text editing with automatic repointing, so what the heck, now I can at least implement some of my themes! I'll probably post some info about it later.

Now, this is getting a bit long for an introduction. So I'll just say, glad to be a part of this community, and it's good to see you all still going at it even after all this time. I don't know if I'm going to be very active, but I'm here to stay in any case.