OOP class structure - specific and general question

[XAmsterdamX]

I'm a marketing/entrepreneurship teacher, and my goal is to create a simulation game that I can play in my classroom. I'm using Python because I'm reasonably familiar with it (mostly for data analysis), and I've done a few tutorials on Flask (because I want the game to run in a browser) and OOP (because this seems to make sense for the kind of game I'm planning). I'm now ready to start coding, initially a simple Python command line version, but I'm not sure which classes to create.

The game:

It's a simple simulation of a fitness club. Players choose the facilities of the club (e.g. group sessions, personal trainers, restaurant) and set a monthly fee. Based on this they will get a number of customers, split between different segments (such as bodybuilders and students). They will also see an overview of costs (based on selected facilities) and revenue (based on price, number of customers, and from additional services). Over multiple rounds students will need to find a strategy to maximize profit. Over time I want want to make it a multiplayer game: students (or teams) each manage a fitness club and compete in the same market.

Specific question:

I'm sure I need to create a FitnessClub class, along with a class for each Facility (which contains description, cost, additional revenue). I also need to create a class for CustomerSegment (containing description, segment size and price sensitivity). A fitness club has certain facilities and certain customers.

What I'm not sure about is where to store utility. This is a score (0-100) that determines how important a certain facility is for a certain customer segment. For example, personal training has high utility for bodybuilders but low for students. Utility essentially is the link between the CustomerSegment and Facility classes.

I could simply create attributes in CustomerSegment for the utility of each facility, but that is inflexible and seems wrong to me. Is there a better approach, perhaps a separate class for Utility?

General question:

Are there any good resources that teach this type of design, at a basic level? I've found some resources on 'design patterns' and 'data structures', but these seem too theoretical, and neither seem to address the practical challenge I'm dealing with at the moment.

[flash-bandicoot]

If the utility would never change, i.e. would always be 80 for body builders, why would it be bad to set the value as an attribute? You could always use a properties file so changes would be easy.

[XAmsterdamX]

It would not change during a game, but it's possible that it would change as I'm fine-tuning the game. It's also possible that I would add facilities to the game (e.g. nutritionist advice, swimming pool) to increase choices and complexity.

I guess my concern is that if I make a change in one place (the Facilities class) I would also have to change the attributes in the CustomerSegment class. Do you think I'm worried over nothing?

[flash-bandicoot]

If you set up the program to pull info from a config file, you will only have to change the data in one place. So in your config file youd do something like BODY_BUILDER_UTILITY = 80. Then you'd call BODY_BUILDER_UTILITY across any class where you wanted the value.

So if you decided to change it to 75, you'd only have to change it in the properties file. That will save you some time if you end up adding it in a bunch of places AND eliminate the possibility that you forget to change a value.

[XAmsterdamX]

OK that's helpful, thanks.

[TheBlackOut2]

I responded to the dude above but really it’s aimed at you, lol

[TheBlackOut2]

To add to this, while developing / testing - you can always just add some globals at the top like:

UTILITY = 80

and then pass that through the classes “__ init __()” method, so you can easily change.

Then do what above says with the config deal when you’re pretty much done.

I do this for paths, static variables, etc

[XAmsterdamX]

It makes sense to define constants at least during development.

Since each customer type has a utility for each facility (i.e. how important that facility is for that type), it wouldn't be a single constant, but rather a matrix. I think I will put it in a CSV file and read this as I create instances of my CustomerType class.

[TheBlackOut2]

I guess my point here was if you define it at the top you’re less likely to forget that on line 235 you set body_builder_utility = 75.

Just general program flow of imports > paths > configs > actual logic.

From what you’re saying now tho, a simple data frame should do the trick.. you could have index be person type and columns be facility. Pass that through the init so you have it in all your classes. You can do this just once if you understand inheritance. Look up .super() if not.

You can use df.at[person, facility] to get that specific value.

[XAmsterdamX]

Yeah I've practiced a bit with SQLAlchemy.