• 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/

RS Faction A vs Faction B: Crowd-Source Brainstorm

The mutator that we use on the TWIL servers does have the ability to exchange classes by other classes. For instance replace the EliteAssault by a Rifleman class. It's full working as long as both classes are from the same faction. Just out of fun I once tried to use it to exchange a HOS class with an RS class. It does show up correctly on the class selection screen, however selecting is will give a "This class has already been taken" even though the counter still indicated 0/1. This was on a HOS map. I never tried to replace a RS class by a HOS class on a RS map. The chance of that working is a bit higher due to the inheritance tree of the HOS vs RS classes. But then still the HOS class would have characteristics of the RS faction due to all other objects being RS class instances.

In short, I think a lot of coding is required to get the factions to work as they do on their original maps.

I encountered the "Role has already been taken" problem when swapping role classes with new IOM ones. In my case it was caused by a mismatch between the roles on the client and server. I was able to solve it by swapping roles on the server in the mutator class and on the client in the player controller class.

Perhaps the RO2 roles in RS problem could be solved by creating a new set of roles for each faction (RSUSARifleman, RSGermanRifleman, etc.) instead of two sets of axis and allied roles per team.
 
Upvote 0
I encountered the "Role has already been taken" problem when swapping role classes with new IOM ones. In my case it was caused by a mismatch between the roles on the client and server. I was able to solve it by swapping roles on the server in the mutator class and on the client in the player controller class.

I don't think this was the case. The ladder mutator does swap the role classes on both client and server side.

Perhaps the RO2 roles in RS problem could be solved by creating a new set of roles for each faction (RSUSARifleman, RSGermanRifleman, etc.) instead of two sets of axis and allied roles per team.

Or create a generic RO2 role base class which contains all common characteristics of all derived classes. Then make derived classes per faction. For instance for rifleman role:
Code:
RO2RoleInfoRifleman --+-- HOSRoleInfoAxisRifleman
                      +-- HOSRoleInfoAxisRifleman
                      +-- RSRoleInfoAxisRifleman
                      +-- RSRoleInfoAlliesRifleman

Then in all code only use references of type RO2RoleInfoRifleman. The same could be done with PlayerController and Pawn classes.

Code:
RO2PlayerController --+-- HOSPlayerController
                      +-- RSPlayerController

The above ensures that all objects are referenced at the same inheritance depth.
 
Upvote 0
... The same could be done with PlayerController and Pawn classes.

Code:
RO2PlayerController --+-- HOSPlayerController
                      +-- RSPlayerController

The above ensures that all objects are referenced at the same inheritance depth.

This is true, but I'm not so sure having two PlayerController and Pawn classes is ideal. It's better in my opinion to have a single base to work from, just as in your role example. It would make a maintenance easier and make the addition of more factions easier, especially if the information about the Pawn's appearance and load out are all stored in the role they select. The Pawns in the game can then be treated interchangeably because except for faction specific behavior, all the Pawns of a faction are only different with respect to their uniform, voice and load out.

Say you have a single merged pawn class. Have four team indexes, with odd numbers meaning Axis and evens representing Allies (to be reflected else where in code.) So 0 = USA, 1 = Germany etc.

This index along with information about the players skin, voice and all the load out information are stored in one of your derived Role classes. This lets the mapper determine who plays on his maps, what they look like and what weapons they will have.

The player selects his role and spawns with the right team index, skin, voice and load out! Faction specific behavior would be handled by checking the team index of the pawn performing the action.
 
Upvote 0
Thanks a lot for this input so far guys - our coders are following this thread closely.

Which of the suggestions we pick up will depend a great deal on their application to the particular future strategic direction of the franchise that we have agreed with TWI.

Having said that, this is ALL very useful - even the stuff that we have already come up with ourselves independently - as it acts as verification.
 
Upvote 0
This is true, but I'm not so sure having two PlayerController and Pawn classes is ideal. It's better in my opinion to have a single base to work from, just as in your role example. It would make a maintenance easier and make the addition of more factions easier, especially if the information about the Pawn's appearance and load out are all stored in the role they select. The Pawns in the game can then be treated interchangeably because except for faction specific behavior, all the Pawns of a faction are only different with respect to their uniform, voice and load out.

Say you have a single merged pawn class. Have four team indexes, with odd numbers meaning Axis and evens representing Allies (to be reflected else where in code.) So 0 = USA, 1 = Germany etc.

This index along with information about the players skin, voice and all the load out information are stored in one of your derived Role classes. This lets the mapper determine who plays on his maps, what they look like and what weapons they will have.

The player selects his role and spawns with the right team index, skin, voice and load out! Faction specific behavior would be handled by checking the team index of the pawn performing the action.

The problem with a single end class is that the class will contain HOS dedicated code and RS dedicated code. This means that you introduce a lot of conditional code paths. Introducing code paths results in complex test protocols. And too many code paths result in impossible code to test with ET charters. If you use a base class for the common characteristics and derived classes for the specific characteristics, then you keep the code paths limited to those which are of value for the purpose of the class. Thus easier testing and less error prone.

An other approach could be what I use in most of my mutators (well almost the same). In general it comes to having 1 end-class and an end-class extension base with derived dedicated classes. Something like:
Code:
ROPlayerController
       :
       :
       .....> ROFactionPlayerController ---+---> HOSFactionPlayerController
                                           +---> RSFactionPlayerController

In ROPlayerController a field is defined of type ROFactionPlayerController (and ROPlayerController will be an end-class). That field then points to extension objects which contain the dedicated code for the purpose of the faction. Faction dedicated code will then be in the classes derived from ROFactionPlayerController. This way the code paths can stay limited. The difficulty of this approach is that you must design ROFactionPlayerController with care. You must ensure that you have defined the right delegates and override-able functions. If not then the whole concept will at some point end up in the trash bin, but if the design is solid, then it will be easier for modders to add their own home-made faction. It will simply be a matter of exchanging the ROFactionPlayerController instance with their StarWarsRebelFactionPlayerController instance.
 
Upvote 0
I see. I would then propose a single base Pawn class be created along the same lines as your ROFactionPlayerController, with carefully defined functions that handle behaviors unique to RS and RO2. Then faction specific classes can be derived from it to make the needed changes... and then be stored inside the roles :D

It would indeed be a massive pain to merge the two... but I think it's worth it. It makes it much easier to define new factions and have them 'work' with the others right out of the box. It's also important in my opinion to get rid of the huge trees the Pawns are derived from in both games. Otherwise there might be 200 more hard coded subclasses of both ROPawn or RSPawn that modders will have to work through to make changes to existing Pawns, let alone create their own faction.

Another entirely different and altogether simpler solution:

It would be relatively easy to reskin the Americans as the Russians by copying a section of the American Pawn tree, giving them
Russian voices and weapons and turning them against the Japanese. Find the faction specific RO2 functions overridden by RSPawn and restore them in the RSRussian root class.
Derive the Germans from the Americans in the same way. Then in an ideal world you have two new factions in RS that just happen to look like the Germans and the Soviets but behave like the Americans with some changes. However they would still likely be compatible with all of RS's additions such as the flames, bonzai charge and knee mortar, having been derived from RSPawn.
 
Upvote 0
I see. I would then propose a single base Pawn class be created along the same lines as your ROFactionPlayerController, with carefully defined functions that handle behaviors unique to RS and RO2. Then faction specific classes can be derived from it to make the needed changes... and then be stored inside the roles :D

I used the ROFactionPlayerController as an example. The same procedure can indeed be used for the pawn classes.

It would indeed be a massive pain to merge the two... but I think it's worth it. It makes it much easier to define new factions and have them 'work' with the others right out of the box. It's also important in my opinion to get rid of the huge trees the Pawns are derived from in both games. Otherwise there might be 200 more hard coded subclasses of both ROPawn or RSPawn that modders will have to work through to make changes to existing Pawns, let alone create their own faction.

Personally I don't like the idea of merging the RO2 and RS classes into one class. It will be a nightmare to debug/test. Personally I'm more for an OO structure where base classes are used and contain the generic code while the derived classes contain the dedicated code. It's clean and better testable. Disadvantage is indeed that modders need to override a lot of classes to get their things done, but in most cases it means tweaks in the same trend for each class. The per-processor is a very handy tool for this job.

Another entirely different and altogether simpler solution:

It would be relatively easy to reskin the Americans as the Russians by copying a section of the American Pawn tree, giving them
Russian voices and weapons and turning them against the Japanese. Find the faction specific RO2 functions overridden by RSPawn and restore them in the RSRussian root class.
Derive the Germans from the Americans in the same way. Then in an ideal world you have two new factions in RS that just happen to look like the Germans and the Soviets but behave like the Americans with some changes. However they would still likely be compatible with all of RS's additions such as the flames, bonzai charge and knee mortar, having been derived from RSPawn.

It's a possibility. But it feels more like the mutator approach. It means overriding a class with code of a base class in the class inheritance chain.
 
Upvote 0
Thanks a lot for this input so far guys - our coders are following this thread closely.

Which of the suggestions we pick up will depend a great deal on their application to the particular future strategic direction of the franchise that we have agreed with TWI.

Having said that, this is ALL very useful - even the stuff that we have already come up with ourselves independently - as it acts as verification.

are you gonna make a poll to ask us what scenario we'd like to play? :)
 
Upvote 0
One of the most obvious problems would be weapons especially for the axis

Non existant/replaced weapons on the western front 1944-1945:

MKB 42 (Replaced at this time by the StG44)
G41 (Replaced by the G43)
G41 marksman variant (Same as above)
MP40II (Unsuccessful experiment dropped years before)
Hafthohlladung (Completely replaced by the panzerfaust)
PZB 7B4 (Captured soviet AT rifles being exported to the western front would make no sense)

The US and Japanese could be mixed straight in as their weapons already suit the time period, so could the soviets if you remove the ATV-40.
 
Last edited:
Upvote 0
One challenge is KF2. It would not do for a fraction mode released after KF2 to seem too retrograde compared to advances included in KF2.

The enduring texture changes
High FPS weapon animations
Ragdoll advances (though not the full gore of course - more inspirational).
General graphical improvements
More adroit AI (bots)


To name a few I am aware of.

I would suggest making a short-list of "must have" code being developed for that game for use in the fraction vrs fraction.

These are perhaps not the brain-storms you were looking for. But it is what it is :).
 
Upvote 0
Rising Storm does not have vehicles. If the Russian team were to use a universal carrier against the Japanese would it work, or is it only for RO2?

Indeed a Japanese tank would be nice to fight tank battles in the large plains of Manchuria and Mongolia. :)
Nonetheless the Japanese have the AT Type (forgot the number), so it just needs a new class like Tankhunter in the Japanese role selection and we are good to go.

Something that would cost much more effort than Soviets vs Japanese would be adding the Nationalist/Communist Chinese forces fighting the Japanese invaders. It would need new player models, weapons and voices.
Nonetheless it would be a faction never seen before in any WWII game as the mainstay are Germans, American, British and Soviet, few occasions Japanese. Chinese forces would bring fresh air into the whole scenery. Like I said, it is quite some work to do but I'd be willing to pay for it, just like for Rising Storm.


Flamethrowers for RO2 would indeed be a nice feature as I recently re-watched the 1993 Stalingrad movie and the Germans used flamethrowers in the sewers.
 
Upvote 0
Well, since this early Alpha of the Heroes of the West has been introduced, I think that Moskeeto and General Shepard are on a good path. But I do know that there's still a lot of work in front of them to make it all operational.

As for historical accuracy, there are some things that should be put in, such as:
- The M1A1 Thompson, which was the preferred SMG for the U.S. Army forces on the Western Front. Most M1928 Thompsons were sent or issued to British troops fighting in Europe.
- If there are gonna be variations of forces fighting in the modification or the stand-alone expansion (such as Rangers, Airborne, Infantry and Armored divisions), then the loadouts would have to be different in terms of weaponry used. The Airborne units used M1A1 Carbine, while the Rangers and other Infantry divisions used the standard M1 Carbine (which already exists in-game).
- As for the AT weaponry, there would definitely be proper AT weaponry. That includes the Bazooka, Panzerschrek, Panzerfaust as a possible battle-pickup by the ammo dumps. But the implementation of the Bazooka and the Panzerschrek, in my personal opinion, would require a separate Squad slot. Why? Because most Bazooka units worked in pairs (one shooter and one reloader). Even though the Bazooka and Panzerschrek would be able to fire on their own, I'd rather see that team-work in this, but it would be very hard to implement it into the game itself :/.
- Other weapons were used by German forces fighting on the Western front, and Moskeeto needs people to make those guns, such as Gewehr 43 and SturmGewehr 44. Also, the sniper class for the Germans would have to be updated to use the Gewehr 43 Scoped. Some officers carried Lugers and not Walther P38 pistols, so I think that the Luger should find its way here as well. I don't know if MP41 was used at all on the Western front, but if it was, I'd certainly love to see that one as well.
- Considering that not everyone used the M3 Grease Gun (it was mostly used in the Pacific Theatre), some units still used it on the Western Front (mostly Airborne units like 82nd and 101st Airborne). I don't know how much of it is true, but here's a link to check it: http://www.d-day-publishing.com/portrait-series/col-bob-piper.html
The M3 Grease Gun would be a nice addition for the American forces, since it has a lower RoF than the M1A1 Thompson and I'd love to hear its sound during various skirmishes :D.

Now, that completes the infantry ideas that I have. Now, onto the vehicles and possible maps and locations.

Vehicles:
- Certainly ones to be included should be the M4 Sherman and Panzer IV tanks. Just for starters. As for the Panzer IV tanks, I think that Panzer IV Ausf.H would be the model I'd choose for the Western Front.
- Transport vehicles: definitely the Sdkfz.251, which is already in the game for the Germans. For the Americans, the standard M3 Halftrack.

Locations and possible maps:
- Omaha Beach would be the first one, obviously :D.
- I am a fan of the Brothers in Arms games, and there are many locations from that game that could be used as an inspiration for a map. I would definitely love to see the assault on Carentan by Airborne troops. Since Rising Storm was mostly fought on islands, urban maps is sort of a requirement for the Western Front :D.
- One map that revolves around Operation Cobra and the liberation of St. Lo.
- Definitely something during winter and Battle of the Bulge. Foy would be a great map for this.

Other stuff:
- The biggest problem I see, when combining forces such as Americans and Germans, is the issue of proper Artillery strikes. Naval barrage could be used only on the Omaha Beach map and not anywhere else. On other maps, Naval barrage could be switched with a different artillery strike (I'd choose from a variety of options here: M4 Sherman Calliope Rocket Strike, Creeping Barrage or just leave the standard Artillery Strike). As for the Germans, I'd love to hear that Nebelwerfer strike fear into the hearts and minds of the American troops.
- Hero ranks and uniforms: now that is probably the biggest question. If there are various forces and uniforms, how to make the Heroes stand out in front of the other soldiers? For the Airborne units, I'd make the Hero wear paint on his face and have his sleeves rolled up. As for the Germans, it would depend on the type of forces that would be chosen to stand for them in this game. I still have no idea how it would work for the Rangers units.
- Uniforms would have to be different within different units. As you know, Airborne used different uniforms in Normandy and later in Market Garden and the Battle of the Bulge. The Normandy ones were M42 uniforms and sort of brownish color, which were soon replaced with M43 uniforms that were green. Also, the markings on the helmets differentiate (they used Hearts for 502nd PIR, spades for 506th PIR and diamonds for the 501st PIR. The clubs were reserved for the 327th Glider Infantry Regiment). So, proper uniforms for proper units in the game or modification.


I know that these are not scripting ideas, but they are ideas and the possibilites that could be in the stand-alone game (or the Heroes of the West modification). And I know that these ideas probably add to the complexity of making the whole project possible, but I'd still love to see it in-game and I'd definitely cash out (e. g. 30 to 40 €) for something like this :D
 
Upvote 0