AppWarp Viking Demo is an extended version of Unity’s Third Person Demo. The original demo has been transformed into a Multi-player version without making any major changes in the original demo so as to show that any current game can be easily integrated with AppWarp Unity SDK.
Watch the video
Open the Demo in Unity. You will find a folder named AppWarp inside Unity Assets which will contain AppWarp SDK .dll file and two additional scripts : appwarp.cs and listener.cs. The main file which will handle the appwarp logic is appwarp.cs and the other script listener.cs contains the listeners. Both scripts are inherited from MonoBehaviour, hence they both can be added to any game object as components.
The assets also contain a prefab ‘VikingPrefab’ which is the prefab of our viking model. Every player is an instantiated game object of this prefab. The prefab already contains important components and scripts attached to it. You will observe scripts attached to it like Third Person Controller, Third Person Camera and Animation Controller. These were the parts of original Unity’s Third Person Demo.
The ThirdPersonController.cs has been slightly modified, a new variable is added to the script named isRemotePlayer. This variable identifies whether the script attached to GameObject is a remote player or a local player.
The main scene is stored in Scene folder inside the Demo folder in assets. The Scene contains a GameObject ‘Dude’. This is our local player. It contains two more scripts: appwarp.cs and listener.cs, additional to all the VikingPrefab’s scripts.
In the Inspector window of ‘Dude’, beneath appwarp.cs script there are some important properties that must be set carefully. It contains ‘Api Key’ and ‘Secret Key’ of your application, RoomId where the player will be present, RemtotePrefab which represents the prefab for instantiating remote player (i.e. VikingPrefab) and Interval describing the time interval when the messages are sent. By Default the interval is set to 0.06 i.e. approximately 15 messages per second. Another important option in AppWarp (Script) is useUDP, if set true, the game uses UDP to exchange messages otherwise messages are transferred through TCP. Keep in mind that some networks don’t allow UDP.
Initialising the AppWarp
In start() function of appwarp.cs, we have initialised the WarpClient with ApiKey and SecretKey and have added all the listeners. The warpclient connects to AppWarp with a random user name generated from the current time. The isRemotePlayer variable of ThirdPersonController component is set false, as AppWarp script is attached only to the local player. Once we are successfully connected, the name of the game object representing the local player is changed to the name used to connect to AppWarp in onConnectDone() of listener class. This helps to easily identify our local player in the scene.
The update() function continuously sends the position, rotation and velocity information of the local player based on the interval defined. We are sending information in form of bytes through sendUpdatePeers()/sendUDPUpdatePeers(). The first 9*4(=36) bytes of the message are the x,y,z values of position, rotation and velocity. These are followed by name of the local player. This is the name that was generated in the start() to connect to the AppWarp server. Since we are dealing with byte messages, all the above information is copied to a byte array using System.Buffer.BlockCopy() function before sending the message to AppWarp. Then we update the WarpClient with WarpClient.GetInstance().Update(). This is a very important step as the Update() function continuously checks for the incoming messages.
onUpdatePeersReceived() of listener class receives the messages. The messages are further processed in the onBytes() of appwarp class. We extract the information from the bytes in the same way the information was encoded in the bytes. Whatever message, the local player sends, the same is received by him as well. Hence we ignore the messages sent by the local player and will only process the messages that were sent by remote players. Then we search for any gameobject representing remote player whether it already exists in the game or not. If no such player is found, a new game object is instantiated from the Viking Prefab otherwise that game object’s position, rotation and velocity is updated with the information received.
The reason behind the remote player being added by searching for it at the arrival of messages is that if we have created players at the onUserJoinedRoom event, we might miss the players that have joined before the local player joined. Hence the developers who are developing MMOs or a virtual world should consider this approach.
Smoothing the movement
Since we are only sending 15 messages per second to save network bandwidth and the game is running at higher frame rate than 15, there will be jerkiness in the motion of remote player. Therefore we have used interpolation to smooth the movement. To achieve this interpolation a new script was created ‘RemoteThirdPersonSmooth.cs’ and was attached to ‘VikingPrefab’. The RemoteThirdPersonSmooth uses lerp to interpolate the values. This will result in smooth movement of the remote player. So, whenever information is received, instead of directly applying it to the game object, we pass it to the RemoteThirdPersonSmooth script which interpolates the values.
Destroying Players on leaving the Room
Whenever the remote player leaves, its game object is destroyed from the scene.
This was a little demo showing the capabilities to AppWarp. Anyone can use this sample to learn the basics to create a MMO or a Virtual World.
If you have any questions or need any further assistance, please feel free to write us at firstname.lastname@example.org.