Corrida de Entregas

Projeto Corrida de Entregas Roblox

Uma empresa de entregas acabou de abrir uma operação em uma cidade grande. O problema é que os pedidos chegam o tempo todo, os entregadores estão espalhados por diferentes regiões e ninguém quer ser o último a terminar a rota.

Você vai construir uma experiência multiplayer em que jogadores assumem o papel de entregadores, pegam encomendas, atravessam diferentes regiões da cidade e tentam completar suas entregas antes dos outros.

O projeto deve ser divertido de jogar e interessante de construir, mas também servir como um laboratório para sistemas distribuídos, persistência, otimização e comunicação entre servidores.

A corrida começa

Cada jogador começa em uma pequena central de entregas.

Ao entrar, ele recebe um pedido com um destino e precisa atravessar a cidade para entregar a encomenda.

Uma entrega pode ser simples, mas o sistema deve acompanhar informações como:

• Quantidade de entregas concluídas.
• Região atual.
• Recompensa recebida.
• Sequência de entregas.

Quanto mais entregas o jogador concluir, maior será sua progressão.

A cidade é dividida

Separe a cidade em pelo menos dois Places. Um representa o centro da cidade e outro representa uma região mais afastada.

O jogador deve conseguir aceitar uma entrega em uma região e viajar para outra utilizando TeleportService.

Não precisa criar uma cidade enorme. Construa poucas áreas com bastante identidade visual. Uma rua comercial, uma área residencial e um pequeno distrito industrial já são suficientes para criar variedade.

Pedidos acontecendo ao mesmo tempo

As entregas não precisam existir apenas no servidor atual.

Utilize MessagingService para criar um acontecimento global simples.

Por exemplo, quando um jogador completar uma entrega especial, todos os servidores podem receber uma mensagem avisando que uma encomenda bônus foi entregue.

Isso cria a sensação de que todos os jogadores estão participando da mesma cidade, mesmo estando em servidores diferentes.

A encomenda especial

Crie um evento temporário em que uma encomenda especial fica disponível por alguns minutos.

Utilize MemoryStoreService para controlar esse estado temporário entre os servidores.

Todos os servidores devem conseguir consultar se o evento está ativo e, quando possível, reagir à mesma informação.

Não precisa criar um sistema complexo de matchmaking ou filas. Uma única encomenda global temporária já é suficiente para exercitar o conceito.

Seu histórico acompanha você

O jogador deve possuir um perfil persistente.

Salve informações como:

• Entregas realizadas.
• Dinheiro acumulado.
• Nível do entregador.
• Quantidade de encomendas especiais concluídas.

Depois, imagine que a empresa lançou uma atualização e adicionou um novo campo ao perfil.

Implemente uma versão dos dados e faça uma pequena migração para que jogadores antigos continuem utilizando seus perfis normalmente.

Uma cidade que carrega aos poucos

Faça a região central da cidade relativamente maior e utilize StreamingEnabled.

Organize o mapa pensando que o jogador não precisa ter todos os prédios e objetos carregados ao mesmo tempo.

Depois, percorra a cidade observando o carregamento das diferentes regiões e pense em como a construção do mapa pode influenciar a experiência quando ele cresce.

Não entregue desempenho junto com a encomenda

Crie alguns sistemas que funcionem continuamente, como atualização de pedidos, marcadores ou indicadores da cidade.

Depois, procure oportunidades para reduzir trabalho desnecessário.

Observe especialmente:

• Loops executados com frequência excessiva.
• Eventos conectados várias vezes.
• Objetos que continuam sendo processados mesmo quando não precisam.
• Atualizações visuais acontecendo mais vezes do que o necessário.

Utilize o MicroProfiler para observar o desempenho e encontrar pelo menos um ponto que realmente possa ser otimizado.

A rua também tem física

Adicione alguns veículos ou elementos móveis simples à cidade.

Não é necessário construir um sistema completo de carros. O objetivo é observar como objetos físicos se comportam em uma experiência multiplayer e como a replicação pode afetar desempenho e estabilidade.

Experimente diferentes quantidades de objetos e observe o comportamento com mais de um jogador conectado.

Informações que não podem esperar

Alguns elementos da corrida podem ser atualizados constantemente sem que cada atualização precise chegar obrigatoriamente ao jogador.

Crie um indicador visual de movimento ou outro dado transitório e utilize UnreliableRemoteEvents para atualizá-lo.

A informação pode ser perdida ocasionalmente sem quebrar a experiência. O jogador simplesmente receberá a próxima atualização.

Essa é a situação ideal para entender por que nem toda comunicação precisa utilizar um evento confiável.

Um pouco de trabalho paralelo

A cidade possui vários elementos que podem ser analisados independentemente.

Crie uma tarefa pequena que possa processar objetos de uma região sem depender diretamente das outras partes do sistema.

Utilize Actors para experimentar o Parallel Luau e entender como uma tarefa pode ser distribuída para execução paralela.

O objetivo não é tornar o projeto inteiro paralelo. É aprender a identificar uma tarefa que pode ser isolada com segurança.

Quando o projeto começa a ficar grande

Separe os principais sistemas em ModuleScripts especializados.

Você pode ter módulos responsáveis por:

• Pedidos.
• Entregas.
• Perfil do jogador.
• Eventos globais.
• Recompensas.
• Viagens entre regiões.

Evite criar dependências desnecessárias entre eles. Um módulo de recompensas não precisa conhecer os detalhes de como o jogador é teleportado, por exemplo.

A arquitetura deve facilitar a criação de novos tipos de entrega sem obrigar você a modificar todos os sistemas existentes.

A corrida precisa continuar depois da atualização

Prepare o projeto pensando que ele poderá receber novas versões.

Teste alterações antes de publicá-las, acompanhe erros e observe o desempenho da experiência.

Se uma nova versão alterar a estrutura dos dados dos jogadores, a migração deve acontecer sem destruir o progresso existente.

A experiência deve ser pequena o bastante para você entender todos os sistemas, mas organizada o suficiente para demonstrar como um projeto Roblox começa a lidar com múltiplos servidores, persistência e desempenho.

Conceitos técnicos praticados

• Arquitetura modular em larga escala: separação dos sistemas de pedidos, entregas, recompensas, jogadores e eventos.
• DataStore avançado e versionamento: persistência e migração dos perfis dos entregadores.
• MemoryStoreService: controle temporário da encomenda especial entre servidores.
• MessagingService: comunicação de acontecimentos globais entre servidores.
• TeleportService: transporte dos jogadores entre diferentes regiões da cidade.
• StreamingEnabled: carregamento progressivo de uma cidade maior.
• Otimização de scripts e eventos: redução de loops, conexões e operações desnecessárias.
• MicroProfiler: identificação de pontos de custo computacional.
• Otimização de física e rede: análise de objetos físicos e replicação multiplayer.
• UnreliableRemoteEvents: atualização de informações contínuas que não exigem confiabilidade.
• Parallel Luau: experimentação de uma tarefa independente utilizando Actors.
• Publicação, monitoramento e manutenção: preparação da experiência para receber atualizações e acompanhar problemas.

Quando a entrega foi concluída

O projeto estará completo quando for possível iniciar uma entrega, atravessar diferentes regiões, receber acontecimentos globais, participar de um evento temporário e manter o progresso do jogador entre sessões.

Além disso, você deve conseguir explicar por que cada sistema utiliza determinada tecnologia e identificar pelo menos uma otimização feita a partir de uma observação real do desempenho.

Se quiser transformar a cidade em uma competição

• Criar um ranking temporário entre os servidores.
• Adicionar entregas especiais com destinos diferentes.
• Criar veículos desbloqueáveis.
• Adicionar eventos globais que alterem temporariamente a cidade.
• Criar diferentes categorias de entregas.
• Adicionar uma nova região sem modificar os sistemas principais.