In the implementation described below, you'll get a step by step guide of how to use BrainCloud’s Playback Stream service to add Replay Ghosts to your game. Based on your game design, you can even physicalize those ghosts so they feel like real teammates that help players to beat the level! This is a great way to add a sensation of coop teamwork to matches, even when players are playing solo.

To build this into your app you will need to use the Playback Stream service, Leaderboard service, and Lobby service. Different kinds of apps may use different services depending on design choices and details of implementation.

BrainCloud’s Playback Stream service is normally used for one-way multiplayer match replays, as demonstrated in the brainCloud Clashers demo. However, this service is versatile and can be used for any scenario where recordings of player gameplay could enhance the game experience, such as ghosted opponents to race against, or virtual teammates that fight with you.

Ideal examples:

In the Invaders demo, recordings of player gameplay are saved to brainCloud, and then played back in future games to provide assistance to the live players. This gives the player the benefit of help from co-op multiplayer teammates even when no other players are readily available.

In our demonstration, each player’s personal best is saved, with the best players’ replays offered back to the player by way of a leaderboard. When players start a round they will be able to bring replays of the top players into their live game, who will reenact the same gameplay that earned their high score.

There are 4 essential steps in this Playback Stream implementation:

We implemented these extra features to surface the replay system to the player and boost fun. Your design team will want to consider how best the following scenarios should be solved for your game.

In the Invaders game, players are only allowed to move along the horizontal axis and shoot upwards. The less actions players have available to them, the easier this becomes to implement.

First we create a new object to hold the data we want to record each frame:

We also create an object that holds some general information about the recording:

Next we create these objects inside our player controller when the game starts. We can also take this time to include some of the general information, such as the name of the player or the position the player starts in.

Now we need to keep track of which actions happen every frame. We do this in FixedUpdate() because this let us make sure the timing between frames stays consistent:

When the gameplay is over, we grab the score and record and move on to the next step. The gameplay could end for multiple reasons such as the player dying or the enemies reaching the bottom of the screen. To catch all of the different cases, the function can be called from OnDestroy().

This implementation makes frequent use of brainCloud’s Leaderboard service. The IDs of the saved recordings are put into the Extra Data of each player’s leaderboard entry. We only need to submit a recording if the score that it earned is the player’s highest so far.

To make the leaderboard for the app, navigate to App > Design > Leaderboards > Leaderboard Configs in the brainCloud portal. Add a new leaderboard config and remember your Leaderboard ID for later. In this demo it is “InvaderHighScore”.

We will first grab the player’s previous score from the leaderboard. If the recording’s score is less than the previous best, we break out of the function. This will save unnecessary API calls.

Now that we know we want to save this stream, we create it on brainCloud using StartStream() and attach it to our leaderboard entry by putting the stream ID in the third argument of PostScoreToLeaderboard().

We also need to add the gameplay that we recorded to the stream that was just created. To minimize the amount of data sent to brainCloud, we will compress multiple similar frames into one event.

After calculating which frames will be grouped into events, we format the data and send the events to brainCloud. They must be written in JSON format.

Now that we have created our stream and sent all of our recorded gameplay to brainCloud, we end the stream and delete the stream that was previously attached to the leaderboard.

The essential steps are halfway complete! At this point whenever a player completes a game and achieves a personal high score, you should be able to see their leaderboard entry with the ID of their replay under the Extra Data column. Find the leaderboard entries on the portal under App > Global > Leaderboards > Leaderboards.

To find the recordings and their events go to the User tab and browse for your desired user. Find the streams under User > Multiplayer > One-Way MP. The Match ID should be the same as the Extra Data in the leaderboard entry.

When the app needs to retrieve a recording, we use the ReadStream operation from the Playback Stream service to get the data from brainCloud. We need to have the ID of the replay that will be read from. The Invaders demo gets the stream IDs by letting players select from leaderboard entries on a menu in the lobby before the game begins. More information about that menu can be found in the Top 10 Replay Selection Menu step. Keep in mind that the way your recordings are selected is a design choice that will be unique to your app or game’s purpose.

The server will be in charge of instantiating the actors that play out the recordings, so we will read the stream data on the server. We send the replay IDs to the server using an RPC function.

We will be using a cloud code script to read the streams, as there could be almost a dozen streams that need to be read at the same time. Grouping multiple operations together with a cloud script is cheaper than calling each operation individually from the app. We will send the replay IDs to the cloud script as an array called ‘stream_ids’.

To make a cloud script navigate to Design > Cloud Code > Scripts and press the ‘Create Script’ button. For this demo, the script needs to be callable by S2S. The other settings can be left as their default values.

Cloud scripts access the parameters that were sent to them using properties of ‘data’. In our cloud script data.stream_ids is the array of IDs that will be turned into streams. The function main() returns response, which is the JSON that our app will receive. We add each stream to the response under the key “streams”.

Make sure to save the script when you are finished editing. If you already have some IDs from playtesting, you can test if the script works by pressing “DEBUG” and putting the IDs into the parameters section of the page. Press “QUICK AUTH” and then “EXECUTE”.

In the script’s callback function, we find the array of streams and loop through each one to start parsing out their data.

Here we will start parsing the data to transform it from JSON to something usable. We begin by checking if there is enough data to work with, and log a warning if we do not.

We fill out the general data from the summary first, then add in all of the frames from the events.

We hand the data that we parsed out to the next step, where it will be used to instantiate a ‘ghost’ actor.

After instantiating the prefab that will act out the recording, we pass the recording it will act out as well as how much time has passed since the start of the game.

There are two variables we can immediately use: startPosition and username. We also start a coroutine which will handle acting out each of the frames.

For every frame we need to copy the direction the player moved as well as shoot a bullet if the player shot a bullet. We then wait for the next fixed update to act out the following frame.

Once the recording has run out of frames, we call the retreat function. When the actor retreats, it moves downwards until it is sufficiently below the camera, then gets destroyed. Your game or app should have some fallback behaviour in case the data ends.

The menu will display a list of ten options to choose from. Each entry will show players the score that was achieved by the replay, as well as the name of the player that performed the gameplay. Players will select a replay to add to their game by clicking a button attached to the entry.

The entries will be made of prefabs. On the root of the prefab we attach a script and drag three objects from the prefab’s children into serialized fields to be used for later.

Our new script will store the score of the entry, and the name and the ID of the player that created the entry. These values will be set when we retrieve them from brainCloud.

Each entry’s button will send its player’s ID to the LobbyControl script when the button is pressed. Make sure the following function is subscribed to the OnClick event of the button in the inspector.

Now that the prefab is complete, they can be placed in the lobby scene. In this example the playback selectors have been grouped under a scroll area. We also take this opportunity to make sure the lobby control script has references to each of the selectors to be used for later. We do this by adding a serialized list to the lobby control script called leaderBoardSelectors and dragging each of the selectors in through the inspector.

To initialize the values stored on the selectors, we request the top 10 leaderboard entries from the cloud. This function is called from Awake(), and we will receive the leaderboard data a few milliseconds later.

We parse out the data from JSON to get an array that contains information about the 10 entries. The values we care about are the rank of the entry, the name and ID of the player that made the entry, and the score of the entry.

We set the values of each entry, then we update the labels so that they display the most recent information. If not enough leaderboard entries were retrieved to fill all 10 selectors, the remaining selectors will be left blank.

Remember that the buttons on each selector are connected to the LobbyControl singleton. The lobby control script combines the user ID with the list of all previous user IDs and sends that list to the BrainCloudManager singleton.

We will store the list of all of the selected user IDs in the lobby’s settings. This will allow players that join the lobby after some selections have already been made to read the list of selections. If the player that made the selection is not the owner of the lobby they do not have permission to change the lobby settings, so we send a signal instead.

The UpdateSettings and SendSignal functions don’t need callback functions. Instead, they are both received as types of events in the RTT lobby callback. Using brainCloud’s lobby service requires using RTT, which stands for Real-Time Tech. The RTT lobby callback may receive any type of lobby event, but we will only focus on three for this feature: “SIGNAL”, “SETTINGS_UPDATE”, and “MEMBER_JOIN”.

In the case of a signal, we know a player that was not the lobby owner wanted to change the lobby settings. Every member of a lobby receives every lobby event, but only the lobby owner has permission to update the lobby settings. We break early if the current client is not the lobby owner. Then the lobby owner updates the settings with the data that was passed with the signal.

In the case of a settings update, we take the most recently added element in the array of replay user IDs and add it to the client’s list. IDs are only ever added one at a time, so this will keep every client’s list synced with each other.

In the case of a member joining, that member needs to receive all of the IDs that have already been selected before they joined. This is why we stored a copy of the array of IDs in the lobby’s settings.

We delay adding the IDs to the client’s list because some of that client’s UI may not have been initialized yet.

When we try to add a new user ID to the client’s list, we first check to see if it is a duplicate. If not, it successfully gets added to the list. We also display to the user a count of how many playbacks they are about to bring with them into the game. Finally, we hide the button associated with the ID that was just added to prevent players from pressing a redundant button.

When the players are ready to start their game and no more entries are going to be selected, we send all of the stored user IDs to the PlaybackFetcher script.

To turn the user IDs into replay IDs, we will find each user’s entry on the leaderboard and get the attached replay ID.

When brainCloud responds with the data, we parse it from JSON into a list of strings. We then convert that list into an array that can be sent through an RPC function once the client connects to the server.

This “Top 10 Replay Selection Menu” is only one way to choose which replays to use during gameplay, and is very specific to this type of use case. It is likely that if your game or app uses replays for a different purpose that this method may not suit your needs.

One user will be chosen by the developers to have their replay accessible to bring into the game. This serves as an alternative to the Top 10 Replay Selection Menu, however many of the systems used to make that menu will be reused here. While these two menus could be implemented independently, this tutorial will assume the previous menu has already been implemented.

To allow designers to pick one user to be featured, we will make a global property that contains the user ID of a player. Using a global property has the advantage of allowing the developers to change the featured player without updating the app. Navigate through the brainCloud portal to Apps > Design > Cloud Data > Global Properties and click the add button.

The name of the property in this demo is “FeaturedPlayer”. We will need to use this exact name later to read the property in the app. We will not need to use the category of global properties in this example, but if your app has many properties you may benefit from filling out the category field. In the ‘DATA’ tab, enter the ID of a user that has already recorded a replay.

Place one of the selector prefabs we made for the top 10 menu into the scene, along with a “Featured” label. Make sure the lobby control script has a reference to the new selector.

In the Awake() function we start a coroutine that will find which user is currently being featured and then get their user ID, username, and score from the leaderboard. The ReadSelectedProperties operation expects an array of properties as its first argument. This is where we place the name of the global property we made earlier.

After parsing out the ID, username, and score from the player’s leaderboard entry we pass that information to the LobbyControl singleton to initialize the featured player selector. Then we use the foundFeaturedUserInfo boolean to mark that the UI has been initialized.

The new selector should now display the username and score of the featured user. To make it usable as a menu item, most of the system is already complete from when we made the leaderboard selectors. The featured selector’s button already either updates the lobby settings or sends a signal to the lobby owner to update the lobby settings.

When a new player joins the lobby, they should only add all of the selected user IDs to their list after both types of selectors have been initialized.

When a new ID is added to a client’s list, the button of a selector with that ID is disabled to make sure players cannot press a button that does not do anything. We have to update this function to include the new selector.

The Invaders demo’s current implementation has replay actors end only when the original recording ended. To make the actors feel more like real players, we can have them take damage and get destroyed by the enemy bullets.

Looking into the EnemyBullet script, we can see the bullet checks whether the collider it hits has either a player control script or shield script before dealing damage. We will add a check to see if the collider has a player replay control script.

If the bullet hits a replay actor, the Despawn() function will remove the bullet on the server and clients. We then call a function on the player replay to handle being hit.

Each time the replay player gets hit by a bullet, they will lose one life. When they run out of lives we stop all coroutines, which ends the function that does the acting, ActPlayBack(). We then despawn them from the network.

When the player replay is hit and dies, we instantiate some large particles. If they do not die, we instantiate smaller particles. These particles get spawned on the client’s side using an RPC function.