O que há de novo no Firebase para desenvolvedores back-end de jogos?
Olá, pessoal.
Obrigado por estarem aqui comigo virtualmente neste espetáculo online.
Sei que o título original da palestra era
"O que há de novo no Firebase para desenvolvedores back-end de jogos."
Mas, atenção para o spoiler,
vamos falar sobre o Cloud Firestore.
O que é, por que é importante
e por que o engenheiro de banco de dados ao seu lado ficou animado.
Como já devem saber, o Firebase tem várias ferramentas
para ajudar a botar seu jogo para funcionar.
A ideia é deixar a gente cuidar do trabalho chato de infraestrutura
e você pode se concentrar em deixar seu jogo interessante,
que deve ser a sua prioridade máxima.
Nós oferecemos serviços como autenticação no Firebase,
que facilita muito para o usuário entrar no seu jogo
a partir de vários provedores diferentes.
Temos hospedagem no Firebase.
A ideia aqui é facilitar para você ter um site
funcionando rapidamente
em uma CDN global que tem SSL por padrão e todas aquelas coisas legais.
E isso é muito legal se você tem um site exclusivo
para comercialização de um jogo que você quer hospedar com rapidez.
Temos o Cloud Storage, que é um serviço poderoso, mas simples,
para armazenar grandes objetos binários.
E pode ser tanto conteúdo gerado pelo usuário
como capturas de tela ou vídeos
ou fornecido por você, como dados do jogo pós-instalação.
Há o Cloud Functions para o Firebase,
para você executar o código de back-end sem precisar instalar servidores próprios.
E temos bancos de dados para armazenar dados na nuvem.
Muitos desenvolvedores já ouviram falar no Realtime Database.
É o principal produto do Firebase,
da época em que era uma startup independente.
E ainda é um ótimo produto.
A ideia é que se o usuário altera um valor em um dispositivo,
os SDKs e servidores atualizam esse alteração automaticamente
em todos os outros dispositivos que ouvem esse valor.
E tempo real aqui é um pouco diferente
do que desenvolvedores de jogos estão acostumados.
São algumas centenas de milissegundos de latência,
então não é adequado para o seu atirador em primeira pessoa,
mas você pode usar em um jogo de bingo, por exemplo.
Tenho um fato interessante.
O Realtime Database foi usado no jogo Loteria.
É um jogo tipo bingo que rodava como um Doodle do Google.
Estava na página principal do Google em mais de uma dúzia de países.
E o Realtime Database fazia as combinações, anunciava os números,
mostrava a jogada do oponente em tempo real e declarava o vencedor.
E o mais legal é que esse jogo foi de zero a milhões de jogadores
de um dia para o outro
quando o colocamos na página principal do Google.
Aparentemente, o Google recebe muito tráfego.
E o Realtime Database aguentou bem o tranco.
Nenhum engenheiro ligou em pânico nem nada do tipo.
E temos até um artigo no blog
contando em detalhes como a equipe de engenharia fez tudo isso.
E recomendo que vocês leiam para saber mais.
Isso é legal, mas para desenvolvedores Web e de aplicativos,
apresentamos a próxima geração do Realtime Database,
um produto conhecido como Cloud Firestore.
E tem sido um produto muito bem recebido,
exceto pelo fato de que não tem bibliotecas de clientes para C++, nem Unity
até agora, ou até algumas semanas atrás,
quando anunciamos que a versão Alfa estava liberada.
Vou falar daqui a pouco sobre esse rótulo de Alfa,
porque é meio importante.
Pode ser que alguns de vocês já estejam salivando por isso
e correndo para criar seus próprios índices compostos ou o que for.
Mas para vocês que não são fanáticos por bancos de dados
podem estar pensando: "Parece que é uma boa noticia,
mas o que significa e por que devo me importar?"
Então, vamos explicar.
O Cloud Firestore, assim como o Realtime Database,
é parte de uma família de bancos de dados conhecidos como NoSQL.
E se você quer saber a versão bem simplificada,
pense em um banco de dados tradicional.
Você tem tabelas,
que armazenam tipos de dados altamente estruturados.
E você pode mesclar esses dados usando uma linguagem chamada SQL.
E você pode fazer muitas coisas legais.
Pode mesclar diferentes dados,
como dados calculados de várias tabelas diferentes.
E, ainda que isso seja bem legal, o desempenho pode ser bem variável.
Essa consulta pode demorar muito ou pouco tempo,
dependendo da quantidade de dados, como estão configurados,
e do tipo de consulta que você está fazendo.
Bancos de dados NoSQL são diferentes em alguns pontos importantes.
Uma coisa que vão perceber é que eles são mais flexíveis com os dados.
Oficialmente, isso é chamado de sem esquema.
E costuma ser visto como algo bom.
Ele permite que os desenvolvedores acessem mais rápido os dados subjacentes
sem se preocupar em replicar todas as alterações que fizeram
para todos os registros mais antigos.
Ele também permite armazenar
dados similares mas não exatamente iguais.
Vocês podem ver que armazenei vários personagens na mesma coleção.
E é claro, eles são similares.
Mas posso adicionar um livro de feitiços para o mago,
um grito de guerra para o lutador, e gazuas para o ladrão.
E o banco de dados não vai reclamar
se a estrutura de dados não for igual de um personagem para o outro.
Ele sabe lidar com isso.
Mas a maior diferença em um banco de dados NoSQL
é o fato de que não tem nenhum SQL, as consultas são muito mais simples.
Você não tem todas as combinações de dados e dados calculados.
Isso quer dizer que você pode ver coisas
que podem parecer estranhas à primeira vista,
como cópias dos mesmos dados em vários lugares.
Algumas dessas peculiaridades,
como esse conceito conhecido como dados denormalizados,
assusta os desenvolvedores SQL mais antigos no início.
Mas, a longo prazo, essa esquisitice compensa.
Para começar, bancos de dados NoSQL podem crescer horizontalmente.
E é muito legal.
À medida que seus conjuntos de dados aumentam de tamanho,
você pode ir acoplando mais máquinas.
E ele vai simplesmente servir os dados por todas essas máquinas diferentes.
E isso é muito útil em um ambiente hospedado na nuvem,
como, sei lá, pode escolher qualquer um,
o Google Cloud Platform, onde há inúmeros servidores
que podem ligar ou desligar de acordo com a necessidade.
O banco de dados simplesmente se expande
por esses vários servidores por trás dos panos
e sem você perceber que estamos fazendo esse trabalho para você.
Em contraste, bancos dados SQL tradicionais
tendem a crescer verticalmente.
À medida que seu conjunto de dados cresce,
você precisa de computadores cada vez maiores para hospedá-los.
E isso pode ser problemático, pois, em algum momento,
não vai ter um supercomputador grande o suficiente para os dados.
E sempre que precisar trocar
para um supercomputador maior e mais rápido
vai enfrentar algum tempo de inatividade.
E com bancos de dados NoSQL, você verá que o desempenho é melhor.
Na verdade, no mundo do Cloud Firestore,
dizemos que as consultas são dimensionadas pelo tamanho do resultado
não do conjunto de dados subjacente.
E o que isso quer dizrer?
Digamos que você tem um jogo
em que armazena enigmas gerados pelo usuário no Could Firestore
e pede para o banco de dados enviar
os 10 principais níveis ativos nos EUA ordenados por classificação,
a consulta vai demorar o mesmo tempo
seja com 300 registros ou 300 milhões.
Não importa o tamanho dos dados subjacentes,
a consulta vai demorar o mesmo tempo.
E isso é ótimo, porque significa
que você não precisa reestruturar o seu banco de dados
por questões de desempenho conforme seu jogo fica mais popular.
Vamos ver outras características
que tornam o Cloud Firestore agradável de se trabalhar.
Para começar, o modelo de dados é muito bom para se trabalhar,
especialmente, se comparado com o Realtime Database
ou outros bancos dados NoSQL.
Todos os seus dados são armazenados em documentos e coleções.
Por documentos, você pode pensar
em documentos que contêm pares de chave-valor.
E esses valores podem ser qualquer coisa
de matrizes a sequências de caracteres, floats, objetos em JSON
e, até mesmo, pequenas quantidades de dados binários.
Esses documentos podem ter até um megabyte de dados para cada documento,
o que é bem grande dado que, na maioria dos casos,
você vai estar lidando com texto, números e objetos em JSON.
Esses documentos são armazenados em coleções,
que, como você imaginou, são coleções de documentos.
E esses documentos geralmente apontam
para subcoleções que contêm outros documentos
que podem apontar para outras subcoleções e assim por diante.
É importante observar que todas as consultas são rasas,
você pode capturar um documento sem se preocupar com os dados subjacentes.
Você pode estruturar seus dados hierarquicamente
de forma que tenha sentido lógico para você
sem precisar se preocupar em capturar dados desnecessários
a cada vez que o usuário solicitar um desses documentos aqui em cima.
O Cloud Firestore tem um ótimo suporte offline
em todas as bibliotecas de cliente,
os SDKs armazenam os dados no cache automaticamente
conforme você os busca do servidor.
Se o seu usuário entrar em um avião, e ligar o modo avião,
ele ainda terá acesso aos dados que estão no cache do dispositivo,
ou seja, ele pode continuar jogando
e você pode consultar todos os dados armazenados no cache offline.
Além disso, qualquer coisa que os seus jogadores gravarem
fica na fila no dispositivo.
Assim que eles ficarem online novamente,
são enviados para o banco de dados na ordem em que foram gravados.
Assim, nenhum dado da sessão do jogo será perdido.
O Cloud Firestore suporta buscas simples e isoladas de dados
que você deve estar acostumado a fazer se vem de um banco de dados tradicional.
E muitos desenvolvedores começam no Cloud Firestore dessa forma,
mas você pode adicionar ouvintes em tempo real,
para que o cliente seja notificado
quando um documento for alterado.
E é muito legal, não?
Você apenas diz para a biblioteca escutar os resultados da consulta.
E o Cloud Firestore envia atualizações quando os valores forem alterados,
assim você não precisa deslizar para atualizar.
Os dados aparecem assim que estiverem disponíveis,
o que é ótimo em jogos de múltiplos jogadores
quando você quer que o estado do jogo
seja atualizado depois que o usuário jogar.
O Cloud Firestore tem suporte para múltiplas regiões,
ou seja, podemos armazenar dados
em diferentes locais distantes alguns quilômetros uns dos outros.
E isso é ótimo em termos de confiabilidade
porque, digamos que um lagarto radioativo ou algo assim deixe a sua cidade offline,
seus dados continuariam acessíveis a partir dessas outras regiões.
Mas, ao mesmo tempo, ele é muito consistente,
ou seja, os dados recuperados são a última versão dos dados
que foram escritos no banco de dados,
não importa a região de onde o usuário se conectou.
E vou ser sincero.
Ter esse suporte para múltiplas regiões e ser altamente consistente
é um problema incrivelmente difícil
que solucionamos para você nos bastidores.
E não acho que as pessoas percebem como isso é legal.
Podem acreditar, é um problema bem interessante que resolvemos.
O Cloud Firestore também tem suporte para transações atômicas
se quiser garantir que nenhum cliente está mexendo ao mesmo tempo.
Não tenho um slide para isso, mas sei que é importante para vocês.
Por isso, estou mencionando.
E porque fazemos jogos e sabemos que nem sempre
podemos confiar nos clientes,
também temos suporte a Cloud Functions e regras de segurança.
Você define as regras de segurança para rejeitar solicitações de um cliente
se ele estiver pedindo dados que não deveria,
ou escrevendo dados que não são aquilo que você espera.
Mas se precisar de controles mais sofisticados,
pode usar as Cloud Functions.
São funções sem servidor executadas na nuvem,
em um ambiente que você controla e confia.
Assim você pode garantir
que a funcionalidade é consistente em todos os seus clientes.
E você confia nas alterações que elas fazem no seu banco de dados.
Já falei muito sobre o Cloud Firestore,
nosso banco de dados NoSQL em tempo real que vive na nuvem.
E vocês devem estar se perguntando
qual é a diferença para o Realtime Database,
o banco de dados em tempo real que vive na nuvem?
Você não precisa escolher um ou outro.
Pode usar os dois no mesmo projeto, dependendo das suas necessidades.
Mas se você quiser comparar e contrastar os dois,
eu costumo pensar no Cloud Firestore
como uma versão do Realtime Database para serviços pesados.
Acho que ele lida melhor com dados mais complexos.
É a minha opinião pessoal,
mas acho que o modelo de dados é mais fácil de usar.
Você tem recursos de consulta mais poderosos.
Suas transações são um pouco mais sofisticadas.
Ele é mais escalável do que o Realtime Database.
E tem suporte a múltiplas regiões para melhor confiabilidade.
Mas tem algumas coisas que o Realtime Database faz melhor.
Ele é um pouco mais rápido
se os seus clientes estão na América do Norte,
e tem suporte interno para presença.
Muitos desenvolvedores acham importante
que os jogadores saibam se seus amigos estão online.
O Cloud Firestore tem soluções alternativas mas não é um recurso nativo.
E não é tão elegante como no Realtime Database.
O modelo de precificação também é diferente.
No Realtime Database, os custos são baseados
principalmente na quantidade de dados que você envia e recebe dos clientes.
No Cloud Firestore, os custos são baseados
principalmente na quantidade de operações de leitura e escrita.
Em geral, o Realtime Database será um pouco mais vantajoso
se você tiver muitas pequenas operações.
Pense em um jogo como bingo ou pôquer,
onde os clientes enviam pequenas informações com muita frequência
como, call, raise ou B14.
O Cloud Firestore é mais vantajoso
quando você tem operações grandes em pequenas quantidades.
Pense em um jogo de desenho assíncrono,
em que você envia um grande bloco de dados em JSON
que representa o desenho do jogador,
ou um jogo de palavras ou xadrez,
em que os jogadores pensam por um longo tempo antes de dar a vez.
Eles não estão executando muitas operações.
Mas não se fixem demais no preço.
O Cloud Firestore pode facilitar a sua vida de muitas formas.
Seu tempo de engenharia também custa dinheiro.
Se é preciso 10 horas adicionais de engenharia
para economizar 18 dólares em custos de servidor,
não é exatamente um bom negócio.
Use o tempo de engenharia com sabedoria. Esse pessoal custa caro.
Então, como você pode usar o Cloud Firestore na vida real?
Vamos ver alguns cenários em potencial do mundo real.
Um dos casos de uso mais simples, salvar o jogo na nuvem, certo?
Seus usuários querem jogar em múltiplos dispositivos.
E com o Cloud Firestore, é muito fácil salvar o estado do jogo na nuvem.
Grave o estado do jogador em um documento, e o documento no banco de dados.
E um outro cliente que estiver ouvindo aquele valor
pode pegar a última versão e garantir que o progresso
seja refletido em todos os lugares onde estiverem jogando.
O armazenamento no Cloud Firestore é relativamente barato,
especialmente se comparado com o Realtime Database.
Assim você pode salvar algumas versões anteriores.
E quando ligarem desesperados para o suporte ao cliente
dizendo que tem algo errado com o jogo,
você tem a opção de restaurar uma versão anterior do jogo.
Outro bom caso de uso é o estado de jogo compartilhado.
Como um jogo de palavras ou de desenho baseado em turnos.
É muito fácil para os clientes consultarem os jogos em que estão participando.
E quando for a vez do jogador, você pode gravar um novo estado de jogo
nesse documento compartilhado ao qual todos os jogadores têm acesso.
E, graças a mágica dos ouvintes em tempo real,
os clientes dos outros jogadores são atualizados
quando o estado do jogo muda para que saibam que é a vez deles.
E, se você quiser uma segurança adicional,
em vez de ter clientes atualizando o documento diretamente,
eles podem passar a alteração para uma Cloud Function.
São aquelas funções sem servidor que vivem na nuvem.
Essa Cloud Function pode validar a jogada e garantir que está tudo certo.
E então pode efetivamente atualizar o estado do jogo compartilhado
que será enviado a todos os outros jogadores.
E graças à integração com o Firebase Cloud Messaging,
você pode notificar os outros jogadores.
Assim, mesmo que o aplicativo não esteja aberto,
serão informados que está na vez deles.
Desafios diários são outro bom exemplo.
São uns bons blocos de conteúdo
que você precisa enviar para todos os clientes
toda vez que eles entrarem.
Sei que existem muitos jogos de RPG, enigmas,
palavras-cruzadas e coisas assim que têm desafios diários.
São os dados que podem ser
facilmente armazenados e servidos pelo Cloud Firestore.
Conteúdo gerado pelo usuário também é um bom caso de uso.
Para grandes objetos binários como vídeos ou screencasts,
recomendo usar o Cloud Storage.
Mas pense em um jogo de enigmas ou de plataforma
onde os usuários criam seus próprios níveis.
Você provavelmente armazena esses dados em JSON.
E funciona muito bem no Cloud Firestore.
E você pode executar consultas como,
todos os enigmas da América do Norte ordenados por classificação,
ou os enigmas mais recentes, ou todos os enigmas de determinado autor.
Mas o caso de uso mais interessante para empresas mais estabelecidas
é usar o Cloud Firestore como uma camada de cache escalável globalmente em tempo real
por cima da infraestrutura atual.
Pense em uma companhia aérea.
Essas empresas têm servidores herdados de 30 anos
com lógica de negócios e de assuntos regulatórios e de conformidade.
Eles não podem trocar tudo para um banco de dados NoSQL, certo?
Mas talvez queiram uma moderna infraestrutura de aplicativos
que possa lidar com milhões de consultas e atualizações em tempo real
e um bom suporte offline e aquelas coisas sofisticadas.
Essas empresas podem copiar alguns de seus dados
para uma instância do Cloud Firestore.
Isso facilita muito para os clientes fazerem buscas,
como consulta de preços de passagens
ou informações sobre o status de um voo.
E obter as atualizações em tempo real
deixando os servidores herdados para lidar com coisas importantes
como compra da passagens,
que ainda precisam passar pelo servidor original.
Se você está assistindo, imagino que não tenha uma companhia aérea.
Mas talvez tenha um MMO, um jogo de cartões colecionáveis,
ou um RPG em que você tem um monte de dados,
configurações de balanceamento do jogo, perfil do jogador, ou o que for
que seus clientes vão querer ler regularmente.
Tem muitos clientes que acessam seus dados constantemente
Então considere colocar o Cloud Firestore na frente.
Seus clientes podem consultar os dados no Cloud Firestore
deixando seu servidor original livre para lidar com coisas importantes
como transações de jogadores ou compras de usuários.
Depois de ouvir tudo isso,
você deve estar empolgado para usar o Cloud Firestore,
mas quero falar sobre esse rótulo Alfa.
O serviço de back-end do Cloud Firestore já existe há algum tempo
e é usado em aplicativos em produção,
mas essas bibliotecas de cliente são novas e ainda não foram exaustivamente testadas.
Vocês podem encontrar bugs, devem haver alguns.
Alguns recursos avançados ainda não foram implementados no SDK do Unity.
Algumas consultas mais sofisticadas não estão disponíveis.
E ainda não há suporte para transformações numéricas.
E a superfície da API deve ser alterada nos próximos meses.
Você vai precisar renomear os métodos
quando atualizar as bibliotecas de cliente.
Sugiro que você comece a experimentar essas novas bibliotecas.
Veja como se encaixam na infraestrutura do seu jogo.
E envie seus comentários.
Mas espere alguns meses
antes de passar todo o seu negócio para o Cloud Firestore.
Agora que já dei esse aviso,
espero que estejam interessados em usar o Cloud Firestore no próximo jogo.
Se quiser saber mais sobre o Cloud Firestore
ou algum dos serviços que oferecemos,
acesse firebase.google.com/games e confira.
E, como sempre, obrigado por assistirem.