New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor game validity checks #636
Comments
@Askaholic Hey. I had a look into this one and want to check the approach I'm thinking of. The default The logic in
Remaining question is whether |
Yea that sounds like what I had in mind, checks that happen for all games (like for unrated maps or mods etc) should happen on the base class, and checks that are specific to some other type of game like a coop game or a ladder game should happen on those classes. Right now there is a direct mapping between featured mod and game class, but that's going to change with TMM. With the addition of TMM, we are going to (eventually) get rid of the |
This commit restructures the validity checks that are performed on games. It starts taking advantage of the OOP setup of Game classes. Child classes of Game can redefine the `_validate_game_mode_settings` method to set custom game validity rules.
This commit restructures the validity checks that are performed on games. It starts taking advantage of the OOP setup of Game classes. Child classes of Game can redefine the `validate_game_mode_settings` method to set custom game validity rules.
This commit restructures the validity checks that are performed on games. It starts taking advantage of the OOP setup of Game classes. Child classes of Game can redefine the `validate_game_mode_settings` method to set custom game validity rules.
This commit restructures the validity checks that are performed on games. It starts taking advantage of the OOP setup of Game classes. Child classes of Game can redefine the `validate_game_mode_settings` method to set custom game validity rules.
When I added the coop validity checks initially, I added them all on the base
Game
class with a switch that checked the featured mod. However in hindsight, I should have made use of the existing object oriented design and put the coop checks in theCoopGame
subclass. This would have the added benefit of decoupling the coop validity checks from the featured mod. We should also do a similar refactor for the "faf validity checks" as well.Related code:
server/server/games/game.py
Line 587 in e4ca993
The text was updated successfully, but these errors were encountered: