Classes structure

Good afternoon everyone!
Not really sure this is the right place to post such a question but still.

I´ve a pretty simple concept of game, which is a turn-based resources manager.
And now wondering about how to organize my code. The choice is:

  1. I can create different classes for various game systems, mechanics etc. E.g. - a class with game variables, a class with victory conditions, a class with timing systems and turns system etc.
  2. Or I can create as few classes as possible so that one class will control game variables, victory conditions, timing etc, so that 2 different classes are created only if their spheres of responsibility are really different.

Which one is the best?
Thanks in advance!

Nobody here can answer this. If they do try to answer, they’re just making #$@#% up.

You have to try stuff out yourself, maybe get ideas from tutorials, and do actual engineering to find out what works best for your specific problem space.

1 Like

So it’s just the matter of personal preferences and specific traits of the project and nothing more?

I think you need to follow this principle from your “Option #2”, but that shouldn’t lead you down the path of “As few classes as possible”. Your goal should be a well-defined but not over-broad area of responsibility for each class.

For example, I don’t know anything about your game. “Victory conditions” might be a simple concept that boils down to something like “in easy mode, you need 10 points, in medium mode you need 20 points, in hard mode you need 30”. In that case, certainly a single “VictoryConditionChecker” class would be appropriate. However, your victory conditions might be more complicated. Maybe your victory conditions change depending on the season, or mission type, and they are something more complicated than a simple tallying of points. In that case it might be appropriate to have a more complicated class hierarchy for calculating whether the player has achieved victory.

This is just one example. You will just need to use your best judgement and try to balance simplicity of development against future readability and maintainability. You’re going to get it wrong too, a lot, and you have to be ok with that. In some cases you will spend too much time splitting things up where a simpler setup would have been more appropriate. In other cases you will kick yourself for not separating concerns and end up with a 1000+ line file that takes you two days to unravel.

There’s no “correct” way to do it!

1 Like

Thanks! Will try a bit different approach then :slight_smile:

Hey, making #$@#% up has gotten me pretty far in this life :smile:

1 Like

Heh, no offense @PraetorBlue , I just was trying to forestall randos asserting “YOU MUST DO THIS!” rather than a reasoned discussion like you provided.

However, I still assert that OP must actually do the work in order to actually evaluate a viable solution given his problem space, about which we know almost nothing.

1 Like

No, it is engineering.

This means you need to engineer a solution, which involves trying some stuff, iterating, and seeing how it goes, learning, perhaps asking pointed questions if you have a difficulty with some particular approach.

Otherwise anyone here trying to say “Oh you’re doing a turn-based resources manager? then do this exactly…” that is not going to be useful. @PraetorBlue kicked in some good general purpose notes however, but you still have to do the engineering and decision-making yourself, since you are holding the game in your hands as it is created.

1 Like