Adding characters is annoying

[NeonSRB2]

Extra characters are somewhat a common want for fangames, even if I really haven't seen that many out there with new ones, people might want to add mighty or shadow themselves or something like that to their games. Unfortunately, it takes a while for that to happen, since characters are almost always referenced via hardcoded tables in the locations they're used. This ends up with having to run around the codebase trying to find all the character specific stuff going on almost everywhere to make the game stop crashing. That's... not desirable for an engine designed to be used for fangames (hence the lack of pixel-accurate precision), so ideally this should be cut down somehow, here's the idea:

• Remove Player.gd's character table
  • It's redundant, and while it may save your fingers a tiny bit, it only adds another thing to add your character's entry to, and is slightly confusing since it lacks NONE as an entry and therefore not interchangeable. This change would mean that technically NONE counts as a valid character if you force it via code, but that would be much simpler to grasp in my opinion.
• Make a new character node class to contain various properties that scripts can grab from spriteController
  • This includes palette textures, name, idle sequence, the works. This is probably the most important thing here since at the moment, if a new character isn't referenced in a certain table, the game crashes, which is kinda dumb.
• Make the stats table independent of character
  • Stats right now are annoying for having character specific logic that really only matters for Knuckles and Knuckles only. I can see people wanting to mess with the stats, but since Knuckles is the only character in classic sonic to have character-specific stats, I think it's worth just making it hardcoded or a boolean to use his stats in the spriteController, as I feel it's safe to assume that most users won't want to mess with them, at least to be consistent with all the other characters.
• heavy, HEAVY commenting
  • A wiki article on doing so would be best, but unless a team member makes the article after the merge request for this, I assume I'm going to be alone in explaining everything in the code itself. Information on the character system would best be told than just simply observing what is there until it works in some strange way.

At the end of this, Air.gd's abilities, Global.gd's character list, and Player.gd's switching logic should be all the code changes that need to be made for every character added. I'm not entirely sure why I decided to make this given I plan on doing all this stuff right now... but it is what it is.

[DimensionWarped]

I've had some pretty similar thoughts about how this yeah. The most obvious to me was just that character-specific code probably shouldn't live inside the more standard state code and instead stuff like air.gd should be able to have a list of callbacks for each state. For instance Sonic would have one for air.gd that handles things like double jump/jump dash and he would have one for ground to handle peelout and another for ground to handle spindash (which most other characters would also share aside from maybe a Sonic Advance 1 style Amy).

And while we are at it we could make characters be able to override states process scripts entirely so that characters like Charmy for instance could just swap out the normal grounded state for one that handles Charmy's unique jump action.

[NeonSRB2]

instead stuff like air.gd should be able to have a list of callbacks for each state. For instance Sonic would have one for air.gd that handles things like double jump/jump dash and he would have one for ground to handle peelout and another for ground to handle spindash (which most other characters would also share aside from maybe a Sonic Advance 1 style Amy).

this is mostly vvhat cc does, but the big thing for me is that simply adding the character takes time going through every instance of character specific code, and the more complicated stuff is usually left vvithout comments. I'm fine vvith the user having to go to air.gd to add their ability since that's not complicated and mostly on them to do, but I don't think I like going through and giving them hitbox, super, and more annoyingly their "stats"

the changes planned make most of these things properties in a "Character" node type, I don't plan on adding a script to each spriteController for realsies (though a script is used to make the custom node, but if the user vvishes they can extend it to their ovvn. Maybe it's vvorth more of a discussion on if callbacks like this should exist as the engine as a vvhole seems to disagree vvith this, vvith the only example of it being vvith stuff like action_jump(), and even then it's used more than just once, something that these callbacks definitley vvon't be.