A API Playable Locations veicula coleções de pontos geográficos selecionados e gerados (locais jogáveis). Cada local jogável é escolhido pelo Google com base na adequação para uso em jogos desse tipo como pontos de origem para itens como depósitos de reparo e prêmios.
Alguns locais de jogos ficam perto de pontos de interesse importantes, alguns ficam em calçadas de estradas, enquanto outros ficam aleatoriamente em parques, playgrounds, praças e outras áreas de acesso público.
O objetivo deste documento é fornecer uma visão geral de como a API foi implementada para que os desenvolvedores de terceiros possam aproveitar os principais conceitos para gerar o próprio conjunto de locais jogáveis usando uma fonte de dados alternativa.
Contexto
Esta seção fornece uma visão geral das Bibliotecas de Suporte usadas e apresenta conceitos básicos relacionados a locais de jogo.
Bibliotecas de Suporte
As bibliotecas de suporte abaixo são usadas ao longo deste guia.
| Biblioteca | Descrição |
| Geometria S2 | Suporte flexível à indexação espacial. |
| Protocol Buffers | Uma maneira extensível e neutra de linguagem neutra e extensível de serializar dados estruturados para uso em protocolos de comunicação, armazenamento de dados e muito mais. |
Biblioteca de geometria S2
A Biblioteca de geometria S2 (link em inglês) é um sistema de informações geográficas que representa dados em uma esfera tridimensional. A biblioteca inclui os seguintes recursos:
- Suporte à indexação espacial.
- Isso permite aproximar áreas arbitrárias como coleções de células S2 discretas.
- Indexação espacial rápida na memória de coleções de pontos, polilinhas e polígonos.
- Operações construtivas robustas (como interseção, união e simplificação) e predicados booleanos (como teste de contenção).
- Operações de consulta eficientes para encontrar objetos próximos, medir distâncias e calcular centroides.
- Uma coleção de predicados matemáticos para testar relações entre primitivos geométricos.
- Arredondamento de ajuste.
Estatísticas de células S2
As Estatísticas de células S2 são úteis para calcular itens como o tempo necessário para fazer o download de um conjunto de dados em uma QPS específica.
Repositórios de códigos geométricos S2
Clone qualquer um destes repositórios para começar a trabalhar com células S2.
SSTables
O formato de arquivo SSTable é usado para armazenar, processar e trocar conjuntos de dados com eficiência. Ela fornece um mapa permanente, ordenado e imutável das chaves para valores, em que ambas são strings arbitrárias de bytes.
Locais jogáveis
De modo geral, um local é um ponto geográfico em um mapa, mas um local de jogo é considerado adequado para colocar objetos em jogos reais, ou seja, como pontos de criação para itens como prêmios.
Tipos de locais de jogo
Selecionados
Os locais de jogo selecionados são pontos geográficos associados a objetos que existem em locais específicos. Eles representam os locais de pontos de interesse (PDIs) retirados de um banco de dados do Places.
Gerado
Se não houver locais jogáveis selecionados o suficiente para atender aos seus critérios, a API Playable Locations vai gerar mais locais. Esses locais de jogo gerados são pontos geográficos que não são associados a objetos existentes. Em vez disso, esses pontos geográficos são criados de maneira programática e colocados aleatoriamente ao longo de calçadas, parques, praias e playgrounds, praças e outras áreas públicas.
O objetivo é fornecer pelo menos uma densidade mínima de locais de jogo, considerando os seguintes critérios:
| Critérios | Exemplo |
| Segurança do jogador | Os prêmios dos jogos não devem aparecer no meio de rodovias ou dentro de bases militares. |
| Adequação para o jogo | Os jogadores não devem perturbar cemitérios ou locais de cultos. |
Propriedades de local reproduzível
Confira a seguir algumas das propriedades associadas aos objetos de localização de jogo na implementação do Google que podem ser úteis para os desenvolvedores na criação de jogos baseados em local.
- placeId
- Uma string alfanumérica que identifica exclusivamente o local. Esse é um ID de lugar para locais de reprodução selecionados (por exemplo, Chlj79ZW1ohQwokRWPhGmWQ2K4). Você pode usar um ID de lugar de um local jogável selecionado para anexar metadados específicos dele ao local.
- plusCode
- Um Plus Code, que identifica exclusivamente o local jogável gerado. Plus Codes são strings alfanuméricas. Por exemplo, 23CPRV2R+WG76. Você pode usar o Plus Code de um local gerado para anexar metadados específicos do jogo a ele.
- tipos
- Uma matriz de tipos de local jogável (strings) que especificam o tipo de local de reprodução. O primeiro tipo na matriz é considerado o tipo primário. Por exemplo, você pode ter um local jogável que seja ao ar livre e entretenimento.
- centerPoint
- As coordenadas geográficas correspondentes ao ponto central do local. O ponto central é usado para determinar se uma localização está dentro de uma área de interesse.
- snappedPoint
- As coordenadas geográficas correspondentes à localização alinhadas à calçada da via mais próxima (quando existe uma via próxima). Use o ponto ajustado para colocar objetos de jogos quando os proprietários das empresas não quiserem que os jogadores entrem nas suas instalações. Quando um ponto alinhado não está disponível, o ponto central precisa ser usado.
- biomeType
- Quando um local jogável está situado em um bioma, esse campo é preenchido com um ou mais valores de BiomeType. Exemplos de biomas são florestas, pântanos e áreas urbanas.
Design
Seleção de pontos para jogos
Como selecionar locais selecionados
Como mencionado acima, os locais selecionados são pontos de interesse (PDIs) reais considerados adequados para a jogabilidade. Confira a seguir uma visão geral de alto nível de um pipeline de dados (com critérios de seleção e filtragem) que pode ser usado para gerar esses locais. O objetivo desse pipeline é gerar um SStable de locais selecionados codificado em S2CellIds que poderia ser alimentado a um banco de dados para consultas em tempo real de locais com jogos em uma determinada região.
Presumimos que o desenvolvedor tenha acesso a um recurso de mapa ou repositório de lugares que contenha um conjunto de candidatos de PDIs, além de geometrias de regiões excluídas (onde locais de jogos não deveriam existir).
O pipeline funciona usando uma abordagem combinada de lista de permissões/bloqueio, em que, em uma fase, selecionamos todos os PDIs que correspondem a uma lista permitida de tipos considerados adequados para a jogabilidade (por exemplo, café, biblioteca, floricultura etc.) e, em outra, filtramos todos os PDIs que se enquadram em um conjunto de regiões excluídas. As regiões excluídas são formadas usando a geometria (por exemplo, caixas delimitadoras) do conjunto predefinido de recursos do mapa considerados inadequados para o jogo (por exemplo, bases militares e cemitérios) para gerar uma cobertura S2. Essas coberturas S2 podem ser usadas para ver se algum dos PDIs selecionados se encaixa nas regiões excluídas e, em caso afirmativo, filtrá-los. O conjunto final de locais selecionados é indexado pela conversão dos pontos centrais em S2CellIds no nível 30. Isso permite pesquisas de locais de exibição com base em intervalos em uma região especificada.
Como selecionar locais gerados
Como mencionado acima, os locais gerados são usados para complementar os locais de jogos em áreas em que os PDIs reais não têm a densidade necessária para a jogabilidade. Como regra geral, encontramos cerca de nove locais de jogos em cada nível 16, a célula S2 (aproximadamente 0,02 km^2) precisa ter densidade suficiente para jogos baseados em local.
A geração desses pontos geográficos "aleatórios" também é feita usando uma abordagem combinada de lista de permissões/bloqueio. A lista de permissões inclui recursos do mapa em que é considerado adequado gerar pontos (por exemplo, parques, calçadas etc.). A lista de bloqueio são áreas em que os pontos precisam ser excluídos (por exemplo, corpos d'água, vias para veículos motorizados etc.). Em ambos os casos, as geometrias de recursos do mapa são usadas para gerar uma cobertura S2 das respectivas áreas. Quando os dois conjuntos são unidos, as regiões excluídas sobrepostas são subtraídas das regiões incluídas para gerar o conjunto final de áreas candidatas para os locais gerados. Como etapa final, geramos "aleatoriamente" pontos geográficos nessas áreas e gravamos em um SStable indexado usando os S2CellIds no nível 30 que representam os pontos centrais. Para locais gerados, os Plus Codes são usados como IDs de lugares.
Visão geral do pipeline de locais
Como mencionado acima, a saída dos dois pipelines de dados anteriores são duas SSTables de objetos PlayableLocation indexados usando S2CellIds no nível 30 do S2. Esses arquivos podem ser carregados em qualquer armazenamento de chave-valor ordenado para pesquisas indexadas espacialmente. Uma opção é o banco de dados SQL distribuído do Google Spanner.
Biomas
Um bioma é uma comunidade de plantas e animais que compartilham características comuns de adaptação ambiental. Biomas se formam em resposta a um clima físico compartilhado. Exemplos de biomas são florestas, pântanos e áreas urbanas.
Quando um local jogável está situado dentro de um bioma, um campo biomeType pode ser preenchido com um ou mais valores de BiomeType.
Você pode usar as informações do bioma para colocar diferentes tipos de objetos do jogo no mapa. Por exemplo, se o campo bioma contivesse o valor campos, ele poderia gerar um tipo diferente de criatura do que se o campo de bioma contivesse o valor urban.
Veja a seguir um processo para adicionar informações do bioma aos locais de jogo como parte do pipeline dos locais acima. O Earth Engine do Google tem vários conjuntos de dados de cobertura do solo com classes de informações, como floresta, pradaria e água, que podem ser usadas para coletar informações sobre o bioma. Recomendamos as seguintes etapas de alto nível para adicionar informações sobre biomas:
- Selecionar dados que tenham informações de bioma e geolocalização.
- Atribua as informações do bioma como um atributo aos Locais de jogo existentes
com base na geolocalização deles, e isso geralmente pode ser feito por uma mesclagem espacial.
Por exemplo, se as informações de bioma estiverem disponíveis no nível 17 da célula S2 e
os locais jogáveis forem indexados usando os S2CellIds no nível 30, uma mesclagem poderá
ser realizada desta forma:
- Mapear os locais reproduzíveis para as células S2 no nível 17: PlayableLocation.s2CellId.parent(17)
- Junção com Biome S2CellIds no nível 17
- Exiba o local de exibição com o atributo bioma quando disponível.
Consultar locais de jogo jogável
Se as recomendações acima forem seguidas e indexarmos os locais de exibição usando S2CellIds no nível 30 (consulte a Biblioteca S2 para converter de LatLng em ID de célula), podemos realizar verificações baseadas em intervalo para recuperar todos os locais reproduzíveis em uma região específica.
Exemplo de consulta:
Se quiséssemos recuperar todos os locais de jogo localizados em um S2Cell no nível 12 (aproximadamente 5 km^2), poderíamos emitir a seguinte consulta:
S2CellId: 0x89c2599000000000 Intervalo mínimo: 0x89c2598000000001 (s2CellId.rangeMin().id()) Intervalo máximo: 0x89c2599fffffffff (s2CellId.rangeMax().id())
SELECT * FROM PlayableLocations
WHERE S2CellId BETWEEN 0x89c2598000000001 AND 0x89c2599fffffffff;
Espaçamento
Mais uma vez, a S2Library pode ser útil para controlar a densidade dos locais de jogabilidade no seu jogo. Os níveis S2 são hierárquicos, então cada célula no nível 14 contém quatro células no nível 15 e assim por diante. Consulte Estatísticas da célula S2. Essas propriedades podem ser aproveitadas ao colocar objetos no seu jogo. Por exemplo, é possível optar por um "monstro" por célula de nível 14 e, para distribuir uniformemente 64 "joias" nessa mesma área, você coloca uma "joia" em cada célula de nível 17 (cada célula de nível 14 contém 64 células de nível 17).
Interações de consulta e armazenamento em cache
O fluxo de lógica recomendado entre o cliente, o servidor, o banco de dados de estados do jogo e o banco de dados de locais jogáveis é mostrado no diagrama da sequência a seguir. É possível combinar o estado do jogo e os locais jogáveis em um único banco de dados, mas eles são deixados separados para maior clareza.
Relatório de localização incorreta
Veja a seguir um processo para coletar feedback sobre a qualidade dos locais jogáveis no jogo, permitindo que os jogadores informem locais inutilizáveis. Esses relatórios podem ser processados em um pipeline de dados e usados para remover locais incorretos do banco de dados de locais de jogos.
Recomendamos implementar os relatórios de localização incorreta seguindo estas etapas:
- Crie um ponto de entrada no lado do cliente (formulário para dispositivos móveis ou Web) para que os jogadores enviem relatórios estruturados de pontos inadequados ao desenvolvedor do jogo.
- Crie um pipeline de dados para processar todos os relatórios recebidos e gerar indicadores para ajudar a classificar a qualidade de cada local.
- Dependendo do caso de uso real, um modelo de ML puro ou um modelo híbrido de ML com solução humana pode ser usado para escalonar o processo de moderação e remover locais inadequados do PlayableLocationsDB.
Confira a seguir um conjunto de critérios de exemplo que podem ser usados para ajudar a determinar se um local de exibição é inadequado:
| Critérios | Exemplo |
| Perigoso |
|
| Áreas não públicas |
|
| Inacessível |
|
| Temporariamente inacessível |
|
| Culturalmente sensível |
|