Golden Sun Hacking Community
June 27, 2019, 01:01:31 PM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News:
 
  Home Forum DC Wiki Help Search Calendar Downloads Login Register  
  Show Posts
Pages: [1] 2 3 ... 33
1  Golden Sun Games / General Golden Sun / Class and ability system implementation ideas on: June 09, 2019, 03:51:45 PM
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.
2  The Editor / Golden Sun: The Lost Age Editor / Re: Editor Questions I think on: April 29, 2019, 02:21:27 PM
This thread has been dead for a while, but I could really use some help regarding classes. I'm just wondering how critical the order of the classes is in the editor. I inserted a lot of new tier 3 classes for both parties 1 and 2, but it's not organized by number. In fact, they're kind of just randomly scattered around wherever I found space. Is there some sort of logic that I need to be following when ordering these classes? Because almost all of them don't work, and most of the already established classes have also broken down (everyone is just turning up as an NPC). The only ones that are working are the ones with Jupiter and Mars as primary elements.
Class requirements are checked from bottom to top / higher numbers to lower, and the first class to meet the requirements is assigned, so the order is very important. Make sure classes with higher elemental level requirements are placed after those with lower ones for all classes that share the same ID, otherwise the higher tiers will never have a chance to get checked.

As for getting NPCs, that happens when the character does not meet the elemental level requirements for any of the classes that uses the class ID they're getting from their current djinn setup. Here is an overview of how those are assigned. Generally, characters can have their primary element overridden by having 6 or more djinn of a different element, resulting in unexpected IDs (this is why the higher tiers of dual elemental classes are forced to use djinn of the character's own element)

Quote
Also related... I changed the elemental levels of the characters at some point as an experiment, but then I changed them all back to their original values. Would this mess anything up even though I changed it back?
No, not unless the editor does something funky. Which I'm pretty sure it doesn't in this case.

Quote
I also noticed the two values beneath the abilities in the class editor. Do these do anything?
Thanks in advance.
If you mean what I think you mean, those are IDs for ability effects (such as ailments or debuffs) that those classes are more vulnerable against. Yeah, that's a thing.
3  The Community / Introductions / Re: I'm new and I need help on: August 07, 2018, 04:31:13 PM
This is a seemingly random bug with the editor, I don't think anyone knows what causes it. Usually you can get rid of it by simply restarting your computer. With that, welcome and hope you have fun hacking!
4  The Community / Open Discussion / Re: You are beautiful on: June 22, 2017, 11:59:49 AM
Uh hi, who are you?

Lol Sala, hope you're prepared to see this a lot.
5  The Editor / Golden Sun Hacking / Re: Class Type code patch (Idea stage/no patch yet) on: May 12, 2017, 11:56:38 AM
Just so I'm understanding the idea in the OP (which I'm not sure I do), is the purpose basically to give more options for how to determine final class type by checking for more things? I get the impression it would be used to modify the class type value, or maybe even override/set it to something specific if certain conditions are met. Am I on the right track?

Anyway, for something else that has been brought up in this thread: getting more class slots to use. What complications would there be in reading the class data from different locations based on character number? For example, if PC number >= 4, use a second class data table, which could potentially double the amount of class slots available without having to rework the code to address numbers over 8 bits. Text string (class name) assignments have already been mentioned, but is that all?

(using this method, item classes should probably have a separate table as well, unless you want characters to get different classes from items)

Another idea to address the available slots issue that would be done on the editor (user) side rather than in code is to simply cut down on the amount of classes for each type. Instead of giving each class 5-6 stages with the same skill list just to have slightly different modifiers, they could have 1 or 2 stages and compensate for the lacking modifiers by making djinn give higher stat boosts.

I also think class data in GS could be stored much more efficiently. However, the work it would take to both change the code to read a different data format and to give it editor support... doesn't seem like it would be worth it, since I'm assuming there's more than enough free space scattered throughout the ROM to use the current format even for a large amount of classes (500+).
6  The Editor / Golden Sun Hacking / Re: Golden Moon on: May 06, 2017, 02:57:43 PM
Yes, the game looks at all classes with the type value resulting from the highest two elemental levels in order, starting from the highest index and counting down. It then assigns the first class that fulfills the elemental level requirements. So if for example the Ninja class line started at a lower index than the Apprentice class line, nobody would be able to access the Ninja class line since the resulting class in the Apprentice line would be assigned before Ninja is even checked for.
7  The Editor / Golden Sun Hacking / Re: Golden Moon on: May 06, 2017, 10:49:03 AM
does anyone know why I cant seem to get the RNG to work, or otherwise know of a cheat to enforce drops?
There are many reasons the RNG exploit might fail, but if you just want to test getting the drop you could set the drop rate to 1/1 temporarily

Quote
(on that note, does anyone know how i can make it so that even the player character can speak?)
I believe you could do it by editing the script, but if you don't already know specifically what to do it would probably be a disproportionate amount of work just to make this change.

Quote
-if i get it to work, natural quatro-elemental classes for 2 characters
This should be pretty simple. If you set djinn of the 3 non-innate elements for a character, you'll see which of the class lines get priority. Use the class type value for that class line for the new classes, put them after all other classes that use that value in the class list, and set the elemental level requirements to 5/1/1/1 and 5/2/2/2 with 5 in the character's innate element, if you want to make sure they're character specific (though other characters will be able to access the first class if you can set 8 djinn or more).

In general I'm not really sure what to comment on, the changes listed don't seem like they would have any major effect on the game. I guess you could release a patch when you feel it's ready, and hopefully people will play it and give some feedback.
8  The Editor / Golden Sun Hacking / Re: [RELEASE] Golden Sun: The Balance Age on: December 08, 2016, 08:21:30 AM
Heh, wouldn't that be a nice Christmas gift?
I'm planning to give it a go at some point after your final update to the current version, then hopefully after that I'll be able to provide some real feedback as well.
9  The Community / Creative Works / Re: Quick Poll - Golden Sun classes in Minecraft on: May 28, 2016, 03:44:57 PM
I think what Squirtle was trying to say there was that you don't need ideas if you already know what you're going to do.

Now, I don't play Minecraft so I can't get too involved with the specifics, but everything so far seems like relatively simple suggestions. You act as if the notion that something could potentially not be the most efficient distribution of work in regards to the end result (according to what measure?) means you have to dismiss any and all ideas with no consideration. You're not on a budget or a deadline, you don't have to manage a staff, allocate resources, or meet a certain result. You can do as much or as little as you feel like.

So, don't ask other people for ideas if you don't intend to consider them. If you don't want to do something because you disagree with the idea or just don't want to put in the effort... that's perfectly fine. But trying to rationalize it any other way just looks silly.
10  The Community / Creative Works / Re: Quick Poll - Golden Sun classes in Minecraft on: May 25, 2016, 08:12:51 AM
Golden Sun does not originally distinguish between gender for classes, females can be Wizards, Swordsmen, Monks etc. If it seems like it would be an issue, you can use gender neutral class names or make alternate versions based on gender. But having gender restrictions for classes seems like it would be unnecessary. I'm more concerned about the fact that the female option has beast ears...

Bashing stuff with a stick is not quite as charming as it sounds, it's essentially the same as bashing them with a sword but slightly worse. However, I think the issue has less to do with physical damage being based on a stat that scales with level, and more to do with attack spells becoming obsolete by the time you get them once your levels start hitting the 30-40 range.
11  The Community / Tech, Gaming and Entertainment / Re: Nintendo NX (codename) on: May 25, 2016, 07:58:57 AM
-It’s not merely the successor to the handheld 3DS or stationary console Wii U.
-This will be hardware that’s been made with a new way of thinking. (Basically a redundant line?)
Basically PR lines that tell us absolutely nothing. It's going to succeed the 3DS/Wii U regardless of whether it is "merely" a successor, and it can be said to be made with a "new way of thinking" as long as it's not a copy of an earlier system.

I think it's safe to assume that:
-You can play games on it (considering a title has been announced for it...)
-It's either stationary or portable (if it's not one, it's the other)
12  Golden Sun Games / General Golden Sun / Re: If you were making a sequel... on: May 05, 2016, 10:56:14 PM
Hmm, I guess the lighthouses can be explained by saying that to create the stone of sages, it was necessary to focus/seal the power into the elemental stars. I think that's the key here, the power once flowed freely throughout the world, but was sealed by the actions of man. If the lighthouses themselves were the seal, one could simply destroy them.
13  The Editor / Golden Sun Hacking / Re: [RELEASE] Golden Sun: The Balance Age on: May 05, 2016, 10:44:19 PM
Oh, umm. You must know about the goal values every 20 levels... the base growth per level is the difference between them, divided by 20, rounded down to the nearest integer. And the chance to gain an additional one stat point is relative to how close the result is to the next integer before rounding, so there's no randomness if the division is even. It's detailed in Terence Fergusson's mechanics guide.

Or if you meant how it works regarding the RNG, I have no idea. Sure wish I knew though.

If you're willing to dig into hacking the level up mechanics, ideally you'd have a function that calculates the stat increases for the current level based on the goal values, meaning it would consistently return the same stat increase for a given level. Having a growing luck stat would not be a problem in that case.
14  Golden Sun Games / General Golden Sun / Re: If you were making a sequel... on: May 05, 2016, 06:33:50 PM
Alright, so this old topic. Before Dark Dawn came out, I was hoping that a potential sequel would head in one of two directions:

-Alchemy was not meant to be sealed forever, but only those who could pass all the trials (as the player does) would be allowed to unseal it, having proven their ability to protect the world from those forces. Following the events of The Lost Age, all hell breaks loose around the world as a result of alchemy returning, and the plot would be centered around creating order in that world.

-A story taking place in a rather distant future, a new "Golden Age" where the names of the former heroes are at best mentioned in stories, if at all. This could be a very different type of game. It might be very similar to a prequel, considering.

I've been toying with the idea of a prequel as well. The main obstacle I've come across is "what was the world like before the lighthouses were built?". What do they do, exactly? They can't have been built to channel the "power" of alchemy into the world, because that's supposedly the power they were built with, not to mention the world wouldn't have functioned properly before they were built. The only answer I can think of, then, is that they were built as a means to seal alchemy... but how would they be able to build them then, considering those who wanted alchemy to remain in the world? I doubt they were built overnight in secret.

Also you mention disregarding Dark Dawn, which actually even in a prequel I would do so. No Ei Jei nonsense, no Light, no Dark. Like I said above, no Luna Tower, perhaps just a nod here and there to it and other DD elements, but nothing that could impact the world. Also Psyenergy Vortexes or a generic evil empyror which diverts from the theme the games have about the villains residing in a gray area.
Personally I think the lore in Dark Dawn was a completely unecessary retcon out of nowhere. It doesn't contradict anything as far as I know, but since it's never mentioned or acknowledged in the earlier games it feels like something they pulled out of their @#$.
15  The Editor / Golden Sun Hacking / Re: [RELEASE] Golden Sun: The Balance Age on: May 05, 2016, 05:38:30 PM
But yes, it's less than 1 Luck per level so the only thing i can say is don't exploit it if you want to enjoy it.
Aww, and here I was hoping you had come up with some fix :p (not really, that would be a bit unrealistic)

It's not that it's exploitable, just that random variation has such a big impact on it compared to other stats. I hate to say this when I can't provide any other suggestions, but there's a number of reasons luck does not work well as a growing stat.

TBS has a predictable RNG.  That's why you can get a perfect level up run reliably in TBS, but not really in TLA.  As such, TBS is a bad game to test RNG with.
It's still predictable, just less friendly to perfect levels. If you do a battle against the same encounter and take exactly the actions, it will always give the same result for stat growths. It's just that it changes with every level instead of every 20 levels, and there's no reliable way to hunt down the specific encounter you want.
Pages: [1] 2 3 ... 33
Cbox
June 25, 2019, 02:51:42 PM
ryancaesar12345: jupiter revive animation any?
June 24, 2019, 08:05:17 AM
Fox: Such a patch would mean you need to be careful with item drops, coins, exp, etc. Because those things would then no longer be an infinite supply.  Whether or not one uses it depends on what they want to do with it.
June 24, 2019, 07:55:01 AM
Fox: (High enough being based on the area you are in.)
June 24, 2019, 07:54:02 AM
Fox: I had a thought today. What if I look into making a simple patch just for lulz.  One that works the same way as using Avoid, but it lasts from start to finish, and can't be disabled.  Avoid only works if your levels are high enough, though... so thought is to keep that as is.
June 24, 2019, 01:55:17 AM
ryancaesar12345: hi guys i have new update in Golden Sun 2 Lost Age Revise Mod.ips try this. :)
June 24, 2019, 01:54:16 AM
ryancaesar12345: where's that link?
June 24, 2019, 01:53:56 AM
ryancaesar12345: i have no account in discord.*
June 23, 2019, 08:44:52 PM
Salanewt: Although in the case of Wish, you could probably just use Breeze instead.
June 23, 2019, 08:44:36 PM
Salanewt: Yeah, it's a messaging program sort of like Skype. I find that it's much easy to walk people through some of the basics of assembly, since that's what you'll need for most animation hacks.
June 23, 2019, 09:39:10 AM
ryancaesar12345: discord? im not good in asm or assembly.
June 22, 2019, 09:37:26 AM
MaxiPower: gpnna update my thread on progress of my character art if anyones interested. :P
June 21, 2019, 07:51:44 PM
Salanewt: Hey there! Animation editing can be tricky, but I can share some notes with you if you pop in on our Discord. Are you good with assembly?
June 21, 2019, 02:59:40 PM
ryancaesar12345: and how to change a death curse turn in hex editor?
June 21, 2019, 02:50:00 PM
ryancaesar12345: and how to make animation but changing palette only like wish blue i want to change violet. for AOE healing and earth element.
June 21, 2019, 02:47:44 PM
ryancaesar12345: im done already thanks man i change the icon in that tutorial and all i need is animation most of elemental like healing like wish but wind element. how to import animation in TLA editor in *game crashes* index
June 21, 2019, 12:01:35 PM
Fox: Oh that. You are talking about Caledor's tutorial?
June 21, 2019, 11:49:55 AM
Fox: So in little endian... 08FA0000 (32-bit) is the same as 00 00 FA 08 (8-bits) (Since GBA is little endian) ;;; but if this were big-endian, it would have been 08 FA 00 00 (8-bits)     
June 21, 2019, 11:42:17 AM
Fox: "in the ROM file" = I mean when using any other hex editor to look in the file... ROM section in VBA is 08000000-09FFFFFF, but ROM files are different sizes, so GS1 stops a quarter the way (08800000 / 8MB), and GS2 stops half way. (09000000 / 16MB)
June 21, 2019, 11:39:55 AM
Fox: I am not sure I understand what you are trying to do? ... But all little endian is is just reverse byte. (of the bytes in a data type).... So like... 8-bit is the same regardless of big or little endian. 16-bit is like 0102=big endian 0201=little endian .... 32-bit is like 01020304=big endian ; 04030201=little endian.  (I use 01-04 numbers to represent how the bytes are ordered by address.) ; 00FA0000 in the ROM file is 08FA0000 in VBA's memory viewer/and that's how it works when the game reads
June 21, 2019, 05:20:47 AM
ryancaesar12345: i sa that in icon compressor 00FA0000 -> in 00FA0008 hmm?

Affiliates
Temple of Kraden Golden Sunrise
Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.168 seconds with 21 queries.