• Please make sure you are familiar with the forum rules. You can find them here: https://forums.tripwireinteractive.com/index.php?threads/forum-rules.2334636/
  • Weve updated the Tripwire Privacy Notice under our Policies to be clearer about our use of customer information to come in line with the EU General Data Protection Regulation (GDPR) rules that come into force today (25th May 2018). The following are highlights of our changes:

    We've incorporated the relevant concepts from the GDPR including joining the EU and Swiss Privacy Shield framework. We've added explanations for why and how Tripwire processes customer data and the types of data that we process, as well as information about your data protection rights.

    For more information about our privacy practices, please review the new Privacy Policy found here: https://tripwireinteractive.com/#/privacy-notice

TWI: Please reduce coupling!


FNG / Fresh Meat
Sep 20, 2011
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:

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: