Playable Location Quality Feedback

Google supports two approaches for providing feedback on the quality of playable locations from within your game:

Bad playable location reporting
This approach allows players to report unusable playable locations.
Logging impressions
This is the automatic logging of playable locations that are (a) presented to users, and (b), that are actually used (interacted with) in gameplay. Collectively, these measures are known as impressions .

Reporting bad playable locations

The Maps SDK for Unity provides the PlayableLocationsService.ReportBadPoint method for submitting bad playable location reports from end users.

void ReportBadPoint(string placeId,
                    PlayerReport.Types.BadPlaceReason reason,
                    string reasonDetails,
                    ReportBadPointStatusCallback statusCallback)

This method takes a placeId, and a reason that indicates why this is a bad playable location. The reason is specified as one of the BadPlaceReason enumeration values. The reasonDetails is a string that contains details that explain what is wrong with the playable location. This method also takes a delegate:

delegate void ReportBadPointStatusCallback(PlayableLocationsService.ReportBadPointStatus status);

This delegate is called when the request finishes. The status object contains information about whether the report was successfully submitted.

Example

playableLocationsService.ReportBadPoint(“Zhlj79ZW1ohQwokRWPhGmWQ2K4",
                                        PlayerReport.Types.BadPlaceReason.NotPedestrianAccessible,
                                        “Location is in the middle of a lake.”,
                                        status => Debug.LogFormat("ReportBadPoint request status:
                                                                  IsError={0},
                                                                  Error={1}",
                                                                  status.IsError,
                                                                  status.Error)
                                       );

How to determine if a playable location is bad

Your players can report bad playable locations whenever they feel that a playable location meets any of the following criteria.

CriteriaExample
Unsafe
  • The playable location lies within 50 meters of the edge of a cliff.
  • The playable location lies in the middle of a major thoroughfare, or is close to fast moving traffic.
Non-public areas
  • Restricted government facilities. For example, a military base.
Inaccessible
  • Areas that are fenced-off.
  • Landmarks in water.
Temporarily inaccessible
  • Locations that are closed for renovations.
  • Locations that are closed seasonally.
  • Roads closed for repairs for more than one week.
Culturally sensitive
  • Cemeteries.
  • Places of worship.

How to report bad playable locations

You should collect bad playable location reports from players using a form within your application. Your form must include a field for capturing the Reason, and another for capturing the associated Details. It must also include the following text in the footnote:

This report will be sent to Google, and it will be governed by Google's Terms of Service and Privacy Policy.

The following image shows an example of how your form might look.

Logging impressions

To improve the selection and ranking of playable locations, we ask that you log impressions. That is, we ask that you log:

  • Which playable locations are presented to players.
  • Which playable locations users actually interact with (use).

How to log impressions

You can use the following two Maps SDK for Unity methods to log impressions:

public void ReportPresentedPlace(int gameObjectType, string placeId);
public void ReportInteractedPlace(int gameObjectType, string placeId);

About gameObjectType

The two methods in the previous section both take a parameter called gameObjectType. But what's this parameter for? It exists because you use some playable locations for some types of game objects, and other playable locations for other types of game objects. For example, you might use some playable locations for spawning monsters, and other playable locations for spawning power-ups.

In each case, the associated playable locations will end up being visited with differing frequencies. So, the gameObjectType parameter is used to distinguish between the different ways that you use playable locations. This allows you to collect data and compile statistics per playable location usage type. To do it, you assign integer values to each of the game object types (for example: monster=0, and powerup=1).

Calling ReportPresentedPlace

ReportPresentedPlace logs impressions for playable locations that have been presented to the player, but that the player hasn't interacted with yet. At a minimum, you should log impressions for presented playable locations:

  • The first time a playable location is presented to the player.

  • Anytime a playable location is presented after the player has interacted with it. For example, when the player retrieves a powerup, then the playable location becomes inactive for 30 minutes (don't log presented impressions during this time because the playable location isn't active, even if it's visible to the player); then the playable location becomes active again.

But you're free to log presented impressions anytime if the playable location remains presented to the user (for example, every second, or every frame).

Calling ReportInteractedPlace

ReportInteractedPlace logs impressions for playable locations that the player has interacted with. You should call it whenever users interact with a playable location (for example, when they pickup a powerup).

Example usage

The following code example demonstrates an approach to logging impressions.

const int monsterGameObjectType = 0;
const int powerupGameObjectType = 1;

// The player sees a monster at location "a", and a powerup at location "b".
playableLocationsService.ReportPresentedPlace(monsterGameObjectType, "a");
playableLocationsService.ReportPresentedPlace(powerupGameObjectType, "b");

// In the next frame, the player still sees the same game objects, so you can
// call the same methods again. They will not result in any network requests.
playableLocationsService.ReportPresentedPlace(monsterGameObjectType, "a");
playableLocationsService.ReportPresentedPlace(powerupGameObjectType, "b");

// The player picks up the powerup.
playableLocationsService.ReportInteractedPlace(powerupGameObjectType, "b");

// The powerup playable location is no longer active, so the player just sees the monster.
playableLocationsService.ReportPresentedPlace(monsterGameObjectType, "a");

// After a while, the powerup becomes active again.
playableLocationsService.ReportPresentedPlace(monsterGameObjectType, "a");
playableLocationsService.ReportPresentedPlace(powerupGameObjectType, "b");

If you create your own random playable locations

You can always create your own random playable locations for areas where the Playable Locations API can't provide you with enough of them. If you do, then Google would still like to collect bad playable location reports and impressions for them.

To support this, Google asks that you treat these playable locations as if you received them from the Playable Locations API, and that you use the location's Open Location Code (also known as Plus Code) for its placeId.