I'm trying to create a custom game type for RO2. Unfortunately, almost everywhere, the game types are highly coupled, and that causes many problems. Here's a few examples:
-HUD
One HUD object adds the HUD elements, based a gametype enum value. It should not be designed this way.
The game type should add the HUD elements it needs to the HUD manager. Why? Simple, if you create a custom game type, you can't simply add an enum value, and change the HUD manager to consider that new enum value, because you can't change the SDK code.
-Round screen
Like the HUD, ROUISceneAfterActionReport decides what to display depending on an enum value, in UpdateRoundStartScreen. In other words, all the gametypes that this class knows are handled in a single huge function. What happens when you want to add a custom type? You're fu***d again.
There are many other examples like that, where some class is given a role that it should not be given. A HUD manager should not know what each game types need, it should just offer a way for the gametypes to supply what they need.
The only workaround I've found is to create subclasses, copy-paste the base class code and modify it, but that is very bad, because any modification made by TWI in the base class code needs to be copied by the modder in the derived class. But even there, you still find out where/how the base class was spawned, and find a way to put your own class as a replacement.
So in the future, please keep in mind that generic managers should not deal with game-type specific stuff. And decoupling should be applied in any other context: a manager class should never know what to do for all the specific cases that are beyond its scope.
-HUD
One HUD object adds the HUD elements, based a gametype enum value. It should not be designed this way.
The game type should add the HUD elements it needs to the HUD manager. Why? Simple, if you create a custom game type, you can't simply add an enum value, and change the HUD manager to consider that new enum value, because you can't change the SDK code.
-Round screen
Like the HUD, ROUISceneAfterActionReport decides what to display depending on an enum value, in UpdateRoundStartScreen. In other words, all the gametypes that this class knows are handled in a single huge function. What happens when you want to add a custom type? You're fu***d again.
There are many other examples like that, where some class is given a role that it should not be given. A HUD manager should not know what each game types need, it should just offer a way for the gametypes to supply what they need.
The only workaround I've found is to create subclasses, copy-paste the base class code and modify it, but that is very bad, because any modification made by TWI in the base class code needs to be copied by the modder in the derived class. But even there, you still find out where/how the base class was spawned, and find a way to put your own class as a replacement.
So in the future, please keep in mind that generic managers should not deal with game-type specific stuff. And decoupling should be applied in any other context: a manager class should never know what to do for all the specific cases that are beyond its scope.
Last edited: