Re: issue with multiple variables in if statement
@38
Settings probably belong on Game, assuming you have a Game object. Alternatively they belong on Player. It depends how you set things up.
I wouldn't say that you "put things in a dependency injection". Dependency injection is a design pattern--it's like saying that you rode in the car factory. Better to say "I created a Game class". Don't make classes just so you can do the dependency injection design pattern either: that's like saying you built a skyscraper so you could have a ground floor apartment. I am not judging in any way, just telling us how to give us more useful information, and how not to end up in a hell of little classes everywhere that each have a couple variables on them that you use once and throw away. Saying you did a dependency injection sounds cool but says nothing concrete--it's like saying you hammered some nails. Into what? For what purpose? What kind of nail? What kind of hammer?
A really good model for this is to think about ownership. Settings "belong" to the class that "owns" them. For single-player games this could reasonably be the game or the player. But like, okay, let's say I'm making an online card game. Online card games aren't simple but they give us enough interesting things that it makes a good thing to talk about. I might have:
An engine, which knows how to make games (and owns the games it makes), offering functionality like listing all in progress games and letting a user connect to one.
Users, owned by games, which represent a unique real world person, with things like your name and password.
The game, which owns players and holds whose turn it is, and owns a card deck.
Card decks, which can have cards drawn from and returned to it, and maintain a count of how many kinds of each card are left.
Players, which own a hand and the player's network connection, and have things like the player's name and a link to the user that the player represents.
Hands, which own cards, and can do interesting things like tell us whether it contains a 4 of hearts.
Cards, which own nothing, but have useful card things on them, like suit and number.
In this model, you'd put settings on user because they don't go with games individually. You'd probably also put a different kind of settings on games because games have settings (like what kind of card game it is, max number of players, etc). You'd wire everything up so that you give cards the hand they're in, the hand the player it's for, etc. WHich is the dependency injection design pattern. This may seem a little confusing in that the things that the hand owns depend on the hand too, but the idea is that you probably always want to ask your parent for things and/or tell your parent about stuff, like letting games ask the engine to stop them and disconnect all the players, for example.
The day you get thinking about ownership right, you'll know it. It's really, really obvious the first time you think through a project and can lay out what the entities are and what thing owns what other thing. Thing about ownership-style thinking is that once you get it right you have lots of little tiny pieces that can all be worked on individually: in the above example each of the things I listed is a file, and each of the things I listed only needs to know about two other things at most. Then you can ask a question like "I'm doing this new thing, where do i need to put it so that all the things lower down can get access?" and that's where you put it, and if you're thinking about ownership right it's almost not a question because often there's only a couple right answers.
Think about it this way. For things like coding, you have less memory than your computer. In college psychology, I was told that you can only remember 7 things in your short term memory at once. I don't know how true that is, but it still works for this point. Your job, and what leads to success, is working out how to let you work on part of your program at a time without having to remember that the rest of it exists.
For actually loading and saving settings, you will go very far with dictionaries and the json module. json.dumps can turn dicts into strings, and json.loads can go the other way (plus, once you learn files, there's json.dump and json.load, which take open files instead).
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
