Hi everybody,
Please bear with me here, I'm fully aware that AC cannot handle multiplayer of any variety out of the box.
I have yet again changed direction on my current game, hurrah! Well not fully, but the mechanics have changed at least. I'm aiming for an adventure game which uses a team-based puzzle-solving mechanic, the play mode will be similar to the LEGO games, where you have a small team of mateys who are either controlled by AI or a player. I'm using an external character controller to allow for climbing and the such.
My idea is that Player One is THE PLAYER from the perspective of AC, Player Two et al will be handled purely by custom code should the need arise. Because this is a team-based game, all players should be in the same vicinity and arrive/leave the current location at the same time. To simplify things, you won't be able to start a 'two plus player game' you will always start the single-player game, then other players can join by hitting something (within local and national laws).
I'm not a veteran AC user, I'm just trying to figure out the pain points before I proceed with this idea. To my knowledge, the issues I need to overcome are as follows.
- Handle character switching for the players who aren't player one e.g. AC's player.
- Integrate the split-screen camera, I have this setup already in a test environment outside of AC for isolation and debugging. Essentially I have a camera controller which enables the split-screen controller and dedicated cameras then disable the single cutscene camera when needed. I wondered if this would cause AC problems? Could I add a Basic Camera component to two cameras at once? Would I even need to let AC know about the split-screen camera? Could I just add the primary/player one split-screen camera to AC? The split-screen cameras will only render during gameplay, as soon as we have a cutscene it will switch to a single camera. - the questions in this point are things I have on my task list to explore, if you have any input on this it will be gratefully received, however, I'm not looking for people to do my job for me.
- UI based navigation and option selection. I'm not sure how I want this to work just yet, for example, I may want only Player One to have control in dialogue, or I may want any player to be able to take the reigns. I will handle this through Rewired by binding all controllers to the same UI actions if necessary.
- Saving / Loading. Because the game will always start as a single player I don't think I need to do anything special here. The other player-controlled characters will be treated like NPCs for the sake of saving and loading.
- Interactive elements provided by AC for example sliding puzzles. Only one of the players will engage with this type of puzzle at any one time, at which point my bridge between AC and Rewired will assign the appropriate player as providing the input which is fed to AC.
- Inventory will be shared amongst all players, again, the Rewired to AC bridge will switch the player controller based on who triggered the inventory screen. I will be creating a completely custom inventory UI anyway, so this might not be a problem.
These are the pain points I have so far, I was wondering if any fellow users who are more wisened to the ways of AC have any other considerations I may need to take into account. Perhaps madness lies ahead, I don't know. I feel that AC can handle this if I plan out the mechanics correctly.
Anyway, thank you for your time.
Comments
As AC indeed isn't intended for multiplayer, I daresay you'd find other assets out there more suited for the job.
But, with that disclaimer out of the way:
If each user controls their own Player character, I'm not sure what you mean by "switching" here - but any Player prefab listed in the Settings Manager will have their presence in the scene handled automatically by AC. This'll be based on either their "start data" (configured in the Settings Manager), or by use of the Player: Teleport inactive Action. Once they're in the scene, though, they're free to be repositioned by a separate motion controller.
AC already has a Camera: Split-screen Action, but it's only for one other camera - so you'll need a more generic approach for more.
You can have other cameras beside AC's MainCamera rendering alongside it - and you could have a simple script that attaches your own Camera to a given AC GameCamera. The wider issue, though, is that AC's MainCamera enforces its own Camera.rect values - which will account for Screen.safeArea as well as any enforced aspect ratio set by the user.
I imagine the easiest way to go about this would be to rely on an entirely custom camera system, with AC's MainCamera Camera component not rendering anything, and each player uses their own camera (which can still follow a given GameCamera if necessary). Such a change could be reverted when entering a cutscene by hooking into the OnEnterGameState custom event.
You may also have to set the value of KickStarter.CameraMain manually as well, which is a cache of "Camera.main".
If you make the other characters Players in the Settings Manager, their scene as well as position/rotation will be saved automatically. A tutorial covering AC's player-switching workflow can be found here.
I'm not sure about Rewired, but AC provides delegates for you to override input checks. See the Manual's "Remapping inputs" chapter - you can use such delegates to conditionally control whether or not an input can be read.
This'd probably run along the same lines as above.
AC has an All Players share same Inventory? option, and you can access it with:
Hi @ChrisIceBox,
Firstly thank you for the reply and insight.
I've investigated other assets out there, all have their strengths and weaknesses, AC seems the provide the highest level of extensibility. I may only use perhaps 50%-60% of AC's features without modification, but that is still a huge proportion of the game logic and features. As an aside, I will gain some experience with AC before I move onto a more serious project.
Player Switching
By player switching, I mean that P1 can switch from CharcaterA to CharacterB, P2 can switch from CharacterC to CharacterA once P1 has relinquished control. P1 will be done through AC as they are the primary player, the other players will be done using a custom mechanism. I might need to build a character manager that sits in front of AC, I haven't hammered out the detail yet.
The switches won't be a direct 'go to this character' it will be more of a cycle through the characters and give me control of the first available. So I will have custom actions for 'Switch to the next character' and 'Switch to the previous character'.
Split-Screen Camera
The split-screen system I'm planning on is going to mirror how the LEGO games do it, I think they nailed the top-down local multiplayer mechanics. (See attachment)
The camera split is dynamic, so if P1 is 50 metres away at a 45-degree angle from P2, the split will divide the screen diagonally, if they are off to the side the split will be vertical. This helps when you're trying to find your teammates after running off to investigate an interesting thing over yonder.
At around 4:15 in the following video it shows the camera split technique, it works quite well. NOTE I'm not making a LEGO clone, just taking inspiration from the camera and method of handling team-based actions.
https://youtube.com/watch?v=O-ZsixW4XGg&ab_channel=GamerLittle
Saving / Loading
Excellent, thank you for confirming this. I was sure this would be the case, the save system in AC is quite extensive.
Input & Interactive Elements
Absolutely, I have the rewired bridge from the downloads already installed
Shared Inventory
[quote]AC has an All Players share same Inventory? option, and you can access it with:[/quote]
This is why I'm trying to stay with AC for this game! Excellent, that is exactly what I'm looking for, thank you.
I realise there is going to be a lot of custom code here, and AC was not intended for this sort of game. But, as I've mentioned AC is extremely flexible and extensible, I have done my due diligence on this and AC wins so far.
The options I've looked into over the last couple of weeks are:
I've done the basic assessment, I'm at the stage now where I need to start making a POC. I think I have the pain points listed above, there may be more but the biggies are there.
You can assign the active Player with:
Or by use of the Player: Switch Action, whose "New Player ID" field can be set dynamically via an Integer parameter.
Either way, this'll call the OnSetPlayer event, which you can use to disable/enable any custom controllers you may have.
Very nice. Yes, this is certainly beyond AC's built-in split-screen option.
It's possible to limit the AC mouse cursor to only the MainCamera's rect, but that wouldn't apply if you're dealing with a diagonal separation. You could, however, rely on an additional cursor-position check when reading inputs - to ensure that clicks on the other player's screen aren't registered.