Skip to content

PS5 – Porting Knowledge: Activities

You are here:
Estimated reading time: 13 min

by Luiz Aguilar and Rodrigo Martins

Activities

Activities Overview

 Activity Types

Activities are designed to be flexible enough to support many different types of games and experiences. Before adding activities to your game, there are several different activity types that you should become familiar with to determine which is best suited for your game. Each is designed to cover a specific type of in-game experience. The figure below shows the different supported activity types:

Progress Activity

A progress activity is defined as any activity that requires the player to complete an objective or series of objectives in order to complete the activity.

Progress activities can optionally contain tasks and subtasks that players can use to understand what they should do next and track how close they are to completing an activity. See Tasks and Subtasks for more information on how these can be used.

Progress activities must have a result when ended. For single-player progress activities, the game can set the result to COMPLETED, FAILED, or ABANDONED and pass this result back to the platform by means of the UDS activityEnd event. If you end a progress activity as COMPLETED or FAILED, it is written into the player’s history and progress is reset for the next instance.

For the multiplayer match case, SUCCESS or FAILED are the only supported results. You must use the matches API to pass these results. If you want to make an activity no longer active while retaining its progress, you must move the match to ONHOLD through its status property.

Open-Ended Activities

An open-ended activity has no specific completion objective. It ends when the player chooses to end it.

Open-ended activities can contain tasks and subtasks that can be used to track optional objectives within the activity.

The system handles open-ended activities like progress activities, but when an open-ended activity ends, any result sent is ignored.

Just like progress activities, results for single-player activities can be passed using UDS events. You must use the matches API to pass results for open-ended activities that are being played in multiplayer scenarios.

Competitive Activity

A competitive activity determines a ranking based on the outcome of synchronous play experiences. Competitive activities can be player vs. player, player vs. computer, or some combination of the two.

Competitive activities always use the matches API to pass information to the platform. Rankings can be passed with the match result when the match is completed. If your competitive activity’s result is based on a score, you can use the match API to represent that score on the console both in real time and in the result.

Competitive activities can be put on hold through match progress to keep that progress available in suggestions until the player starts again.

Challenge Activity

A challenge activity is a repeatable activity that displays rankings in leaderboard format, score, or time, based on the outcome of asynchronous, single-player results.

When a player completes a playthrough of a challenge, their result is passed along with the activityEnd UDS event for use in the leaderboard for the challenge. Leaderboards are shown at the platform level and the system generates appropriate cohorts: global (if enabled for the challenge) and friends-only.

A challenge activity can be created by the game developer from existing single player activities, or it can be created independently as a standalone activity. All challenge activities must be repeatable such that the player can repeat their experience and continually improve their score.

Challenge activities (click on link for more information) feature a unique social mechanic that serves to drive re-engagement. For example, when a player is ranked on a challenge leaderboard and one of their friends performs better than them, a system-level notification is sent encouraging the player to reclaim their position.

Tasks and Subtasks

As games vary in their design and scope, much of the activity object itself is optional to configure, leaving the key design decisions to you. To help with this, progress and open-ended activities can contain tasks and tasks can contain subtasks which allow you to provide more granular guidance for the player. These are typically objectives or goals a player must complete as a step of completing the parent activity. For example, you may have a mission in your game to “Repair the Generator” which is represented as an activity. This activity can have tasks such as “find the missing gears” and “find gas to power the generator”. The “find the missing gears” task could be further broken into subtasks for gear one, gear two, etc.

Tasks are child activities designed to represent increments or subunits of a progress activity or an open-ended activity. Tasks, like their parent activities, have the ability to be available or unavailable, as well as to be started and stopped.

Making a task available through the “activityAvailabilityChange” UDS event allows you to control when the task becomes viewable by the player. This allows for progressive disclosure of tasks so as to not spoil the user’s experience.

A subtask is a child of a task. You can use subtasks to exercise finer control over progression and help. Subtasks are managed in the same way as tasks, but subtasks have much less metadata and fewer properties to work with. Outside the game help experience, the player cannot interact directly with a subtask.

Tasks and subtasks are key to providing game help, as game help is provided on the leaf of the activity hierarchy. The hierarchy of these pieces is shown in the figure below.

You can start and stop tasks using the activityStart and activityEnd events. This becomes a more granular way for players to understand what they are playing and to obtain quality help quickly. With “activityEnd”, you can send a result of COMPLETED, FAILED, or ABANDONED. Successfully completing tasks fills up the completion progress if the task is required to complete the activity. You can configure this when creating the task. Note that ending all tasks does not automatically end the parent activity. You must call activityEnd on the parent activity to end it.

 “activityStart” and “activityEnd” events on tasks and subtasks are tagged on any publicly available user-generated content (UGC) that is created. In the case of successful completion, this UGC can be surfaced to other players who are at the same point in the game as a form of help or walkthrough. You can check more information about Activities in this official documentation.

Activity Configuration

When configuring your activities, there are key values you can set to improve player engagement with your game. This section shows some examples of how your configuration can affect the UX a player sees and how you can optimize it.

In order to get up and running with activities, you will need to setup a product concept in Content Pipeline and the subsequent product associated with that concept in DevNet first. In this section, we will be going through these steps to get you up and running with this, so you can start defining Activities in UDS.

You will need to first create a Concept in Content Pipeline. Click on the “Create Concept” button as shown here and follow the steps.

Once you`ve created your Concept, you will need to create a Product Group. Click on the “Create Product Group” button.

You will need to fill in the specified information, such as the region, platform etc. As Activities are specific for PS5, ensure you are creating a PS5 concept and product.

Once you filled in the required information and have followed the steps, you will have created your product in the Content Pipeline. You will not have an NP Title ID and product label associated with your title.

You will now need to navigate to DevNet and add a new product, associated with the Concept and product we`ve created in the Content Pipeline. Click on the “+ New Product” link in the Titles and products page in DevNet.

You will need to create a franchise name and title name for your title and also link the DevNet title with the NPTitle ID that was associated with the product in Content Pipeline in the previous steps. Click on “Add Product” once the required information is all filled out.

You have now created your Concept and product in Contente Pipeline, and have added it to a new product on DevNet.

To define your Activities, you will need access to the UDS Management Tool. In order to access the tool, you will need to request the Universal Data System service on DEVNet on your product page. To do this, click on the “+” button and the “New Service”.

Click on the “Request Universal Data System” button.

Once you`ve requested the service, it will be in the “Requested” status. This will be processed, and once ready, the service status will change to “Development”.

Subcategory Information

By filling out the subcategory field, players are able to understand what the activity is and what happens when they play it. If a game has a natural split in activity types such as main missions vs. side missions vs. online multiplayer, it makes sense to put this in the subcategory field for the player to recognize the activity. The subcategory appears on your activities above the activity name.

Defining Images

There are two images that you can upload to visually represent the activities you configure. A 16:9 4K asset appears when the activity takes over the game’s hub cover. This is the only place at this time that shows this asset.

You can also provide a small image to appear on the cards that represent your activity throughout the rest of the system. This image must be 864w x 1040h. It is best practice to have a unique image for each of your activities as they allow the player to identify them at a glance, speeding up the activity selection process. It is best to put the focus of your image on the right side of the image as that is the best location for the asset when placed alongside many other images, with metadata placed on top of it.

See Asset Specification for best practices and guidelines for using image assets.

Rewards for Activity Completion

You can also inform players what potential rewards they get for completing the activity. You can provide an icon sized (512w x 512h) asset to appear with the reward. If your game does provide the player with an incentive to play, it is ideal that you provide both the string and the image asset as that is more likely to drive the player to engage. If your game features scaling rewards depending on the player’s status, consider using a more general string such as “gold” rather than “100 gold”.

“Available From” and “Available Until” Fields

These fields are used when an activity has some time limit or schedule to it where players are not able to play before or after a certain time. As this field only allows one time, it is good practice to have the activity go live around the world at the same time. If it must roll out at different times depending on region, it is best practice to set the start time to the first time it becomes available to all players globally. Additionally, the end time should be set to when it is removed for the first group of players.

A good way to utilize this is to set an activity to be available for the player (through configuration or the activityAvailabilityChange event) before the availableFrom time. This makes it appear as a suggestion to players at that time without the player having to first launch the game.

Other Key Activity Properties

  • availableByDefault – When set to true, this automatically sets the availability of an activity to available. Use this for any activity that the player can play from the very first time they launch the game. For players who have the Spoiler Warning set to warn on “Everything You Haven’t Seen Yet”, this setting instructs the Spoiler service to ignore this activity as containing any spoilers, even when it hasn’t yet been seen by the user.
  • isRequiredforCompletion – This is used to determine if the player must complete the activity to complete the main story and to pass the activities TRC if your game has a main story. Primarily, this is used to determine the sorting of activities, as activities with isRequiredforCompletion set to true that the player has never completed are more likely to be suggested to the player. In addition, this can be set on tasks. When completed, those tasks are treated as part of the progress of the activity, ultimately controlling the completion percentage progress bars. If set to false, then tasks are ignored in the completion percentage progress bar giving you more granular control of those bars. You cannot set this value on subtasks. All subtasks are considered required for completion.
  • hidden – When set to true, this activity, task, or subtask is considered a spoiler throughout the UX of the platform, until it becomes available, started, or ended for the player. This means that players see a spoiler flag on any user-generated content containing this activity, task, or subtask if they have not encountered it in the game yet. Additionally, if a friend is playing a hidden activity that the player hasn’t encountered yet, the card is obscured for the player when viewed on the friend’s profile.
  • scoreStatistic – Provides configuration for the statistic used to rank players per activity. In competitive activities, it is shown as the top-line stat in the UI for players or teams. For challenges, it is the value the leaderboard is based off of when ranking players. In progress and open-ended activities, it is used to assess each player’s performance on that activity, which is then used for ranking playthroughs for game help, selection of UGC media to show other players, and ranking activities for suggestions.
Multiplayer Specific Fields
  • isOnlineMultiplay – Tells the platform that an activity supports online multiplayer. This is used for determining if the player should be able to launch the activity and automatically invite their friends to play. This is called “boot to group”.
  • numberOfPlayers – Displayed to the user in the system. This defines the maximum number of players who can play an activity together in a singular in-game group. If this number is greater than 1 and isOnlineMultiplay is set to true, then the activity is eligible for boot to group. When the player launches the game via boot to group for this activity, you receive a session where the maximum number of users is set to this number. To learn more, see Boot to Group (Game Intents that Include Sessions).
  • numberOfTotalPlayers – This is the total number of players that can play an activity. For an activity that is 6v6, this number is 12. This is displayed to players on the activity card.
  • isTeamActivity – This lets the platform know that it must expect teams. Setting this to true means that when you define your roster, you must define which team each player is on. This is used for data validation and to make sure the card accurately displays what the game is expecting in regards to teams.
  • additionalStatistic – An array of other statistic configurations used in the competitive activity type. Each appears in the UI in both real-time and after play is finished in the activity card.

Activities and User Generated Content (UGC)

You can surface UGC to players at various places in the console UX. In some cases, contextually relevant UGC is shown based on the player’s recent or current gameplay progress. This gives players access to personalized, spoiler-free videos that can serve as strategy guides, help, or walkthroughs.

Activities and UDS events allow you to surface contextually relevant UGC. When a PlayStation®5 game implements UDS Activities, all videos of that game that are recorded by a PlayStation®5 contain the following:

  • UDS events that are mapped to the video timeline (media auto-tagging).
  • Identified spoilers, which are customized for each player.
  • Metadata that can indicate gameplay strategic approaches and skills

This applies to both privately and publicly shared videos on PlayStation®5. After configuring activities and UDS events, no additional work is required for your game to surface contextually relevant UGC to players.

Notes on Configuring Activities to Show UGC

  • You can segment media automatically at the activity, task, and subtask levels. As shown in the image above, the displayed metadata for each video includes the activity or task name and the name of the skill that is being demonstrated. For this reason, assume that all name properties are user-facing. Subtasks do not have a name property, so videos for subtasks inherit the name of the associated task. If a localized name is not available for an activity or task, the value from the default language is used.
  • Contextually relevant UGC relies on explicit activityStart and activityEnd events to accurately match a player’s progress with user-generated video content for the same activity. The platform can’t surface this type of UGC for activities, tasks, or subtasks that do not have explicitly-defined activityStart and activityEnd events. Limit the duration between activityStart and activityEndevents to 15 minutes or less for the average player to complete. This allows the platform to surface shorter UGC for players to use as walkthroughs or guides. This applies to the duration of activities, tasks, and subtasks
  • The activityEnd.outcome property is used to identify media that contains successful outcomes. The outcome can be set to completed, failed, or abandoned. If the outcome is not recorded on activityEnd, SIE assumes the activity was successfully completed.
  • The platform uses the duration between activityStart and activityEnd events as a metric for play speed. Set the start and end points as consistently as possible across all players. This ensures the platform surfaces the most helpful videos to players.
  • The activityEnd.difficultySetting property allows the platform to filter content based on the player’s selected difficulty setting. If the game allows users to set a difficulty setting, the platform can only surface content from players who played at the same or higher difficulty level than the viewer. This is because content generated by players 
  • playing at lower difficulty levels is less likely to be informative. This is only possible if the activityEnd event includes a difficultySetting value. Difficulty settings should be configured such that a larger number corresponds to greater difficulty.
  • The activityEnd.score property allows the platform to identify higher quality performances. Where possible, report a score for completed activities. This value is most useful if the score is relative to the overall player ecosystem. Also, ensure that the scoreStatistic.sort property is correctly configured for the associated activity object, so that the platform can determine whether a large score value represents a good performance or a poor one. The scoreStatistic.sort property can be set to one of the following values: performance or a poor one.
    • asc Lower score values represent a higher ranking. For example, racing games where the lowest time represents the most successful race
    • desc Higher score values represent a higher ranking. For example, fighting matches where maximizing the number of combo hits results in a higher final score that represents a more successful round.

Activity Implementation

The activities in the game use a slightly complex activation system and must be implemented correctly. It’s important to ensure that the players are placed directly in the activity they’re supposed to participate in. In section “Types of Activities“, various implementation proposals have been discussed for creating these activities in the game.

During calls, it is possible to identify when a trigger is activated. These triggers are defined in the UDS and serve to indicate when an action is taken, such as starting an activity, completing it, failing or abandoning it. All these events are recorded in the UDS LOG as well. Below are some examples of how to implement these calls in Unity to start activities, make them available or not, handle abandonment and failure, with detailed reasons for the failure.

Starting an activity using the ID.

 Completing all activities at once.

Terminate an activity by passing an outcome, including the activity ID and the type of termination.

A coroutine is invoked within “TerminateActivityCaller” that receives the type of termination that will be registered.

 A coroutine is used to make an activity available for starting.

 There is a function that calls a coroutine to disable the availability of an activity.

 Create a coroutine that can disable the availability of an activity. 

Regarding the behavior to be executed for each activity, it occurs in the “OnGameIntentNotification” function within the “PS5Manager”. This function is bound to the delegate in “EarlyInit” during the initialization of our UDS system within the manager. In this function, we use a switch statement with the activityID to check the strings and execute the corresponding action for each specific activity. These actions may include loading a level, delivering an item, starting a mission, or other tasks that are specific to each project.

Don’t forget to download NPConfig to synchronize Activity and Trophy information changes. To do this, go to the product’s main page

Click on the arrow located on the Universal Data System (UDS) tab, and then select the “Package/Disc Management Tool (GEMS)” option.

Select the correct tag and then click the download button. In case you can’t find the right tag, you can create one by going to the product’s UDS, clicking on the “Publishing” tab, and then selecting the “NP Config Tags” option. Please note that certification cannot be done using a development tag.

Extract the contents of the downloaded .ZIP file into the “sce_sys” folder of each region. Replace the files to update the Config TAG for testing trophies and activities.

Attachments

Was this article helpful?
Dislike 0
Views: 18
Back To Top