Trouble deciding on a solution.

[FirestormNeos]

(if this thread's in the wrong forum, please feel free to move it) yeah, i thought it was in the wrong spot. thanks, mods!

So in the project I'm working on in VX Ace, there are 27 classes based on what weapon the player character has equipped. I have for the most part finished with creating all the classes, but I've run into a problem; there's only 66 spaces left for non-player skills (The weapon classes average at about 32 skills each, with a couple of significant outliers). This includes enemies & bosses as well as the player character's companions. As using a database limit breaker plugin isn't going to be feasible for this project, I'm down to possible solutions I've come up with:

1. Cut half the classes outright with minimal changes to the remaining classes.
   
2. Rework all the classes from the ground up to be much simpler, cutting as I go along.

Which option do you all think would be the better one to go with?

Edited for clarification.

 

[bgillisp]

For project specific feedback ideas and prototypes would be better. I'll move you there.

To answer your question, I'd cut the classes in half. Odds are you will not use all 27, and long term you will probably not even want to balance all of them, especially if this is a first project. Maybe try 10 or even 6 at first, and after you get those set up well add more if you feel they are still needed.

 

[NinjaKittyProductions]

I agree with @bgillisp. Cutting the classes in half or even in a third will probably bare more fruit for your project. I had a project that had 15 classess and it took over a year just to balance them out and make sure that they did not have any skills that resemble skills of other classes. I ended up getting burned out and I haven't touch the project for years now. Variation is awesome and important, in my opinion, but too many options can also cause players to get confused or it can overwhelm the player.

 

[gstv87]

you could also simplify the skills themselves to a pile of "Effect A", "Effect B", "Effect C", etc.... where many skills would be based on Effect N + increment.
that way, with all that summed up to generic values, you can take the whole thing and move it over to the code, which is virtually infinite.
then, from the actors or the weapons, you call Skill ID X, Skill ID X would bring over it's own definition (which is Effect + increment, plus, description, plus, scope of target) and the game itself would take care of the rest.

basically: break free of the database, and go back to raw code, which is essentially what the database is: raw code, plus the interface for better management.
what's limiting you, is the interface.

 

[Oddball]

You could also increase the skill database size
If thats not an option, then i say cut the classes in half. I'd rather play a game with a few interesting, well designed classes then a bunch of boring ones with simple skills

 

[TheoAllen]

Possible solutions:

• Cut the number of skills per class, so each class is more unique
• Cut the number of class
• Overlap some of the skills so that it also present in the other classes

In an unrelated note, you started big by designing such huge database. Have you tried to design a small game? Because sometimes even when the database is small, it's difficult to make them interesting, let alone the huge database.

 

[FirestormNeos]

After careful consideration, I've cut down the classes to 13 and scrapped the element system (which was the cause for a lot of the database bloat).
On top of all of that, I've reworked the classes that survived so that each of their primary mechanics remains intact but with much less filler.

As a result, I went from approximately 933 skills to around 300.

tbh? I think I'm back in business. Consider this a problem solved.