Golden Sun Hacking Community
February 17, 2020, 02:08:21 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  
Pages: [1]   Go Down
  Print  
Author Topic: Class and ability system implementation ideas  (Read 5138 times)
0 Members and 1 Guest are viewing this topic.
Misery
Bad Luck

Great Member
***

Coins: 20
Offline Offline

Gender: Male
Clan Position: Mercury Hack Leader
Posts: 715

« 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.
« Last Edit: June 10, 2019, 06:02:08 PM by Misery » Logged
View Profile
Pages: [1]   Go Up
  Print  
 
Jump to:  

Cbox
Today at 04:54:34 AM
Fox: I guess one thing this game has going for it is the Day and Night cycle.
Today at 04:51:46 AM
Fox: Also, I noticed since the very beginning of the game, that usually the dresser drawers (whatever you call them) have items in them.
Today at 04:48:20 AM
Fox: (And I only recently got Karn, the fourth PC.)
Today at 04:36:01 AM
Fox: Was playing Breath of Fire I.... and I must say.... that game's pretty bland.... listening to the same songs basically everywhere... and multiple NPCs saying the exact same thing.  Most of it plays about the same... a maze with common useless items in chests, maybe you'll get one or two fine equipment, but yeah.  ... I want to check #II again later, the game I remember playing like... over a decade ago.
February 04, 2020, 08:06:18 AM
Salanewt: We're more active on the Discord though.
February 04, 2020, 08:06:01 AM
Salanewt: Oh hey! It does, yeah.
February 02, 2020, 06:42:38 PM
Mastermind: holy crap this place still exists?
December 24, 2019, 09:33:09 PM
Fox: Even just plain Editor work can make some difference. = At least these forums are indexed on the Search engine. I was also curious about whether to um... go through all the topics on these forums and take all the important stuff out/placed into a folder for a bit of organization. Would be a bonus since if something ever happened to this forum, or if we ever wanted to start afresh again, it wouldn't be that difficult to do so.
December 24, 2019, 09:23:03 PM
Fox: One thing is for sure. This place has become completely dead. (Mostly because of Discord.)  = I don't think much will happen with this forum unless I, Salanewt, or someone else does a thing.
December 24, 2019, 09:18:05 PM
Fox: Probably not?
December 24, 2019, 06:51:08 PM
Luna_blade: I suppose this is the last Christmas of this forum? 
December 24, 2019, 06:50:51 PM
Luna_blade: Yay thanks for the coins
December 19, 2019, 04:39:45 AM
Fox: Okay, another thought... "gsmagic" could be the code name/project name... and "Golden Sun Magic" could be the more formal official name... (As in using both names.)  -  I still need to look into these other games as well... so who knows if it could be better to call it Camelot Magic if those should ever be supported to a decent standard.  Would probably be a long time from now, though. As I can be pretty lazy.
December 18, 2019, 10:01:39 PM
Foreclosure: gsmagic is fine
December 17, 2019, 05:44:32 PM
Fox: Also. I call my program "gsmagic" and not "GSMagic" =P (Not asking for correction/I being silly)... Had to call it something, so picked something short.  Maybe I should rename it to Golden Sun Magic later. *shrug*
December 17, 2019, 05:35:04 PM
Fox: (And "Golden Sun" instead of "GS" to reduce confusion that would likely not be there anyway... when "Golden Sun" doesn't take up much space to start with. (Imagine being new and thinking GS meant GameShark, or some other oddity. Ew.)) - All just thoughts...I'm still going with most of this not mattering that much, though.
December 17, 2019, 05:12:55 PM
Fox: "Misc. GS Hacking" = That name looks odd, so I'd probably just go with "Golden Sun Hacking"
December 17, 2019, 05:08:05 PM
Fox: I tempted to also suggest the Editors can go in the first category. Since the Editor is the reason this place exists in the first place. (I think.)
December 17, 2019, 04:53:19 PM
Fox: (combined = Not meant to be taken literally... but rather.... to generalize things more, since it apparently looks like we don't need the extra space no one is using.)
December 17, 2019, 04:48:49 PM
Fox: Worse still... we've only used those for Golden Sun content.... and there's not much there.
December 17, 2019, 04:45:53 PM
Fox: E.g. Maybe everything in "Assets & Discussion" could be combined with "Creative Works".... I don't feel like sound and art apply to general hacking anyway... that only comes into play when you have tools to insert them.
December 17, 2019, 04:40:26 PM
Fox: categories and/or forums
December 17, 2019, 04:36:48 PM
Fox: Everything else seems to be about right, though. Perhaps some categories could be combined(?), but doesn't really matter that much.
December 17, 2019, 04:33:03 PM
Fox: (I still think The Community section fits best at the bottom. =P)
December 15, 2019, 05:10:04 PM
Salanewt: Heya! I'm planning to get the demo up today, but if you can't wait then it's already available on the Discord.
December 15, 2019, 04:12:27 AM
Fox: (Then sell the badges on the Trade Center for a very high price... and give a lot of active people coins to buy them with, so they can basically transfer the coins to me if they want something... Gosh I could be a naughty hoarder. =P)
December 15, 2019, 04:06:19 AM
Fox: I'd buy up all the stock for each item too... but man... I think I'm too lazy for that. =P
December 15, 2019, 04:01:24 AM
Fox: There we go. That should be all of them.
December 15, 2019, 03:25:32 AM
Fox: Duplicates will still show up as separate entries on the profile as well. Interestingly enough.
December 15, 2019, 03:18:25 AM
Fox: (Well, one of each badge, at least.)

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.118 seconds with 22 queries.