imagine one would like to create a multiplayer game with fundamental different gameplay for different players. Think for example of a tactical shooter, where several players would be soldiers in FPS mode and one player would be the “commander”, viewing the map in top-down perspective and giving orders. Or the HL2 mod Zombie Master (in case anyone remembers that), where there are several first-person “survivors” and one “zombie master” with RTS-like gameplay.
What might be the best way to approach this task? I am not exactly a billiant C++ programmer, so I would prefer a Blueprint approach (although C++ is not totally out of the question). Is it possible to create two seperate PlayerControllers for different players? Or should I pack all the functionality in one Controller and initialize it differently when the game starts? Or are there other ways that I have not yet thought of?
Any suggestions are appreciated
You would have to make multiple pawns and switch through them using the possess node in blueprints.
Hi Munky, thanks for the quick answer! However, I am afraid this does not answer my question.
In case that was unclear: I do not simply want to control another pawn through PlayerController → possess. What I had in mind was having a completely different interface for the players: Different HUD, different camera, different pawn or no pawn at all (see my examples above), different controls, different rules.
I suppose, simply switching pawns wouldn’t do the trick here. Please do correct me if I am wrong!
I am also curious about the proper way to implement asymmetric gameplay. In the most extreme cases it sounds like players would actually have to be in separate level files that can communicate with each other through a server. It will be interesting to see if someone comes back with a solid implementation proposal for such games.
Couldn’t you do this by Creating several working copies of each system you want to be different, assign them to different pawns and then switch through the pawns that way?
Eg; You want 3 different characters, with 3 different huds.
You make 3 pawns, that you can switch between.
You then create a hud blueprint with a sequence with 3 different huds, have a branch to then check which pawn you are and transmit the corresponding hud to the pawn.
You could then do any other system with similar logic, or would that not work? I’m not brilliant at this stuff, just theorizing.
Which is not enough I think. The main idea is using multiple pawns with different player controllers for different players it seems.
The question is indeed quite interesting. I honestly have no idea how Unreal would behave with different types of player controllers in one multiplayer game but from all I know so far it should be very much possible.
When opening a new level (or connecting to a server via console commands) you have a few additional options. Finding out the parameters is a bit tricky but it’s possible to select the game mode via those. I’m not entirely sure if you can do the same for HUD and Player Controller. It really comes down to how Unreal handles the whole structure in each level. Since you always have to cast your playercontroller from everywhere you get it, the changes for such a thing in BP would be minimal. This is pretty much up for testing.
If this should happen to not work out properly you have a possible fix via your controlled pawn. It’s possible to simply use your controller as input receiver and directly forward controls to your character. You can set your camera behavior and everything in your pawn BP which means for a Top Down commander you could simply do an empty pawn with no collision and only the camera which uses the inputs to do the commander stuff and fps controls and camera via your other characters which are set up as usual. This would also allow hotswapping (changing the controls form commander to fps player during runtime in the middle of your level) which is not really possible if you do it via the player controller as you can’t swap that out via Native Blueprint and even C++ gives you some trouble there.
I am aware that this is not a nice workaround but it will certainly give you the intended result.