The following tests were undertaken to improve my knowledge of Replication in UE4: networking between multiple Clients on a Server. These tests allowed me to redirect my game's design around hardware limitations by understanding the latency issues and how it'd affect a session.
Regardless of networking restrictions in labs, the tests would allow me to know whether or not the project is valuable in the future outside of University studies as a self-goal (cross-platform).
Testing
1 PC, Multiple Processes
To get things running at a quick pace, a 3D Platforming template was used to display movement lag between processes on a single system to prepare using a LAN server as the base. Barely any issues occurred with this as it was all local system, but the following things were established:
The Project's INI files need to have their settings such as DefaultPlatformService under the [OnlineSubsystem] altered to allow the Engine to engage in a Network
A Level needs to be loaded to bridge the connections (like a home point), due to needing to use a Network String when moving between Levels. If a connection is lost, Users are brought back to this original point before the level was loaded (like a save state).
When loading levels, the GameModes will trigger PostLogIn and OnLogout events (for each connected player), so this can be used to track user progress in the game
Outside of the UE4 guide, at this point it was super helpful to clarify replication features on Blueprint Custom Events using this very helpful guide by Cedric 'eXi' Compendium.
2 PCs
Running between 2 separate PC towers I had to alter firewall settings to ensure replication actions were being received on both ends:
As mentioned, Firewalls settings must allow apps to communicate, however due to application IDs changing on relaunching it may be easier to remove Firewall when attempting to connect completely and enable when connected.
1 PC and 1 Mobile
This was a tricky test. To truly test this out, I had to get my phone in Developer mode to have try the firsthand and proceeded in the steps to package an APK:
Similar to my previous module's UI tests, I downloaded the Android Studio APK and SDK files to allow official application production as a developer, and gave my project a licence through Windows Command Prompt.
With UE4 reading my Android licenses, I created the packaged the Android APK and moved it to my mobile to install (as a common app), and bypassed the need of an OBB file (full-game update) download by forcefully moving UE4's files through to the hardware using the Launch function once my device was recognised as a Developer Mobile.
By having both platform versions of the project use the same Project base (ID and all), it allowed them be read as both Clients and Servers when hosting sessions between them, where any differences in-game can be marked via the Check Hardware node for Windows and Android results.
Furthermore, as I understood UE4's networking replication is made to mimic AAA FPS titles (each user having the exact same experience running at all times), I understood that there'll be an issue with mobile users connecting as a pseudo-controller.
The goal was to have any Mobiles connecting (e.g. UE4's Player 2+) appear and play on the big screen rather than play remotely, meaning there would be no need to display the entire game on their small screens in real-time.
To ensured that anything that was to be on the TV only, anything that wasn't to be required would be removed from the packaged build (e.g. 3D assets only to show on TV) and as the engine forcefully tries to match the Levels when joining, anything that wasn't needed on the Mobile build would be ran as a Sublevel and removed on streaming once the Hardware type was identified.
The final issue would then be that due to filtering out assets to preserve memory on mobile devices, the system would no longer be technically "replicating" (as there would be no characters to be copying over).
Instead, I had the system just signal out variables from button presses instead, akin to how a Gamepad signals inputs as variables (e.g. Left Thumbstick is a float variable going from -1 to 1 with 0 as the deadzone for X and Y axis). This was replicated using the Virtual Thumbpads on UE4's mobile projects and sent just as raw numbers from the Player's hardware ID to be read as movement! This would then be done for virtual buttons such as Jumping and Attacking.
You can see the results below:
Results
Simply put, it's a game remote!
It took a while so I can clearly understand the flow of replication but it means I get the general idea of what can and can't be done and possible restrictions that can influence design choices.
Other than immediately being a standalone screen for a competitive game, on a shared-screen title it means I can bypass the limit of ~4/5 controllers on a single system (Gamepads and Keyboard) by turning the device into an additional controller for Party games or similar titles.
Alternatively, where the title runs as intended on personal networks, it must be said that the mobile app is likely best to be used simply as a companion app so progress isn't hindered by the technical difficulties from Campus restrictions.
Next
With these systems tested, I feel more comfortable with the ins-and-outs of replication setup and how it's used with APKs for future projects.
With this done I'll be returning to the critical design, noting functions that may need to cater to these systems and deconstructing my submission targets to be able to proceed with the artefacts outside of major tech restrictions.
Comments