Dev Blog: Under the Hood of the Replication Framework

[Poyraz]

Thanks for sharing this blog with us @Leon Baker. It is really hard to build a system and make certain choices while building it. But in these 9 years, I am sure that the development team will make the best choices and do a good job and looking forward to Al traffic.

[Iuca]

I've always seen the idea of AI good in TMP but I have a couple questions:
 

• Would they be banned from areas such as Calais?
• Would they be disabled on arcade?
• What will happens after you crash into one
• Will this cause the minimum requirements to increase?

Thanks and great to see TMP is looking at the features that convoy mode has but TMP lacks.

[HAPPY-TRUCKER]

Hi,

 

Dont spread the community on different servers! 

 

Good luck !

 

 

["RICKY"]

What exciting news, I can't wait. 

[[ S.PLH ] Warrior]

Fantastic news, good to see that hard work pays of in knowledge over the years that has passed. Big shoutout to the developers!!

the long awaited AI and economy will come eventually.

 

 

[R3tuxn]

Thank you for the news!

['Nhympex.]

Great News!

[[Интегра] ResTed]

Usually, after such blogs, you expect changes and new features tomorrow)) I hope the code will be smooth and we will see these changes soon.

[KaptanTMP]

2 hours ago, clarkclaas said:

cd yolu + yapay zeka trafiği = patlamalar

[[KızılTürk] Rıdvan]

Great news

['Matheja]

It will be a challenging situation, but I'm sure the TruckersMP team will get through this, we'll have to wait and see.

[Sinyordess.]

a good news that players have been waiting for a long time and we finnaly got the news

  this new move will really ensure that players do not get bored while traveling in different parts of the map and will be able to travel more beautifully and have more fun but there are some situations that will be added to this game will be players who can drag artificial intelligence vehicles that will be added to this game into bad negativity situations such as having accidents and deviating from the road at the very beginning if this progress comes I can't even think on the C / D road many players will abuse it which is not a good sign and we are waiting with curiosity to see what kind of measures will be taken

[Bradd]

i hope they make a separate server for the AI when they do get that up and running

[Donii.]

This is excellent news, and something the community is very excited for. Based on the new framework I am very intrigued to see what else can be achieved in the future.

 

Thank you to everyone within the TMP Team for putting the time in to better TMP over the years! You are incredible! 

[Leon Baker]

3 hours ago, loolee said:

I've always seen the idea of AI good in TMP but I have a couple questions:

• Would they be banned from areas such as Calais?
• Would they be disabled on arcade?
• What will happens after you crash into one
• Will this cause the minimum requirements to increase?

Thanks and great to see TMP is looking at the features that convoy mode has but TMP lacks.

 

We are unable to respond to those queries at the moment because AI traffic is not in the development. The Game Development team is currently working on the Replication Framework, which will eventually allow them to work on features like AI traffic, for example, as stated in the blog. When developing the AI traffic feature itself, we will begin to consider things like how the AI traffic will operate, on which servers it will operate, and etc.

[Gonzalox]

This was a very interesting read, I've seen dev/engineers presentations about how server replication works in other types of games but with way less clients at the same time. It's a major technical challenge and I hope the development goes well, I can't wait to test the first betas of this project!

[Jordan.]

This sounds good, the developers are doing a great job.

[kelt_kreqht]

The TMP team continues to surprise us with its innovations. Thanks for this good information and news, mate @Leon Baker . TMP  

[Sneezy]

Thanks for the information, this is great news.

[Еugеnijus]

AI traffic need testing on the C-D road and looking how it works with many players.

[Dias2001_BR]

6 hours ago, Leon Baker said:

 

Prefácio

 

Ao entrarmos em nosso nono ano no TruckersMP, é uma grande oportunidade de não apenas olhar para trás em tudo o que conquistamos com a plataforma ao longo dos anos, mas também olhar para o futuro, enquanto nos esforçamos para alcançar as ambições que temos de tornar a experiência MMO (massively multiplayer online) que oferecemos mais rica em recursos e atraente para a comunidade desfrutar do que nunca.

 

Uma das principais barreiras que enfrentamos como uma modificação do American Truck Simulator e Euro Truck Simulator 2 é a maneira como desenvolvemos nossa plataforma para trabalhar com os jogos ao longo dos anos, enquanto os métodos usados nos serviram bem, permitindo-nos criar e fornecer todos os recursos que oferecemos atualmente, queremos fazer mais.

 

Para entregar alguns dos recursos mais solicitados e esperados, como o tráfego de IA em nossos servidores, precisamos mudar a maneira como as coisas funcionam sob o capô, é aí que nosso novo projeto Replication Framework entra em jogo, já em desenvolvimento há mais de um ano, este projeto em andamento nos permitirá entregar o tipo de recursos revolucionários que a comunidade deseja, e isso é fundamental para nossa continuação contínua como o destino de escolha para MMO (massively multiplayer online) para caminhões virtuais.

 

---

 

Introdução

 

Neste blog, faremos um mergulho técnico profundo nessa nova estrutura de replicação. Você pode estar curioso sobre o que isso significa, quais benefícios ele nos proporcionará a curto e longo prazo, e por que está demorando tanto para se desenvolver. Este blog de desenvolvimento fornecerá um pico sob o capô dessa estrutura e, embora atraia principalmente os usuários experientes em tecnologia entre nós, dada a linguagem técnica usada, ele deve fornecer uma visão geral de alguns dos desafios que enfrentamos ao desenvolver o TruckersMP.

 

TruckersMP é uma modificação multiplayer, então devemos sincronizar o mundo do jogo entre os clientes. Nossa modificação é um MMO (massively multiplayer online), e dependemos da sincronização do estado do jogo usando um servidor. Isso significa que usamos uma arquitetura cliente-servidor em que os clientes se conectam a um servidor. O servidor do jogo tem conhecimento sobre todo o estado do jogo, incluindo a localização dos veículos dos jogadores, os acessórios necessários para construí-los, apelidos dos jogadores, o conteúdo de seus bate-papos e assim por diante.

 

Para entender melhor os conceitos envolvidos, é importante ter algum conhecimento do que são pacotes. Em redes de computadores, um pacote é uma unidade de dados transmitida através de uma rede. Pense nisso como uma mensagem enviada de um computador que pode ser recebida por outro. Um pacote pode conter quaisquer dados, como texto ou binário, mas não pode ser muito grande. Se uma mensagem for muito grande, ela será dividida em pacotes e remontada pelo receptor.

 

---

 

Desafios do desenvolvimento de jogos em rede

 

Ao desenvolver jogos em rede, há vários fatores importantes a serem considerados, incluindo uso de largura de banda, uso de CPU, segurança, estabilidade e confiabilidade. O uso de largura de banda refere-se à quantidade de dados transmitidos pela rede, medida em bits por segundo (b/s). Um servidor dedicado pode transmitir até 1 Gb/s, mas pode ser caro atualizar. A preparação de pacotes no servidor requer o uso da CPU, que pode consumir muitos recursos, especialmente ao preparar pacotes para 4000 clientes 10 vezes por segundo. Também queremos que os clientes mantenham bons FPS (frames por segundo). A segurança é crucial, pois devemos garantir que os hackers não possam assumir o controle do aplicativo do servidor do jogo, levando a violações ou infectando os computadores dos clientes. O servidor e o cliente do jogo também devem permanecer estáveis e confiáveis, com entidades sincronizadas de forma confiável para evitar problemas de dessincronização.

 

Desde o início do projeto, há oito anos, empregamos um design simples de arquitetura de código de rede. Sempre que precisamos sincronizar o estado de algo, construímos manualmente um pacote com um ID específico e o enviamos para o cliente. No lado do cliente, o pacote é recebido, lido e o estado é aplicado. Da mesma forma, quando um veículo de jogador local muda de posição, por exemplo, um pacote é construído e enviado para o servidor, e o servidor aplica as alterações.

 

Essa arquitetura tem suas vantagens e desvantagens. No lado positivo, o uso da largura de banda parece ser gerenciável e o código é direto e de baixo nível, facilitando a criação em C++. A segurança está ligada ao receptor de pacotes e a confiabilidade é baseada na biblioteca de rede.

 

No entanto, também há várias desvantagens neste design. O código de alto e baixo nível é misto, dificultando o dimensionamento da base de código. É um desafio transmitir apenas propriedades modificadas pela rede para economizar largura de banda, e a sincronização está espalhada por muitas partes do código, tornando difícil otimizar o uso da CPU no cliente do jogo e no servidor do jogo. Utilizar mais de um núcleo/thread de CPU é um desafio, adicionar novos recursos é complicado e a confiabilidade é baseada na biblioteca de rede. Na realidade, a largura de banda nem sempre está sob controle.

 

Vamos esclarecer cada um desses pontos:

 

(Pro/Con) O uso de largura de banda parece ser gerenciável, mas, na realidade, na verdade não é:
criamos manualmente um pacote em código C++ específico cada vez que queremos sincronizar algo, o que mantém o uso de largura de banda sob controle. No entanto, isso pode não ser infalível. Com muitas entidades para sincronizar e com o código de sincronização espalhado por toda a base de código, não há controle real do uso da largura de banda. Cada parte do código tentará enviar pacotes sem qualquer orquestração. Outro grande problema é que não sabemos quais sistemas tomam mais largura de banda em tempo real (por player, e globalmente, isso é importante).

 

(Pro) O código é simples e de baixo nível:
Criar pacotes é um conceito simples de entender. Você os envia, os recebe na outra extremidade, lê a ID do pacote e aplica uma lógica específica para desserialização. Essa simplicidade se deve à importação de uma biblioteca de rede existente (por exemplo, RakNet), à criação de soquetes e à gravação de manipuladores de pacotes.

 

(Pro) Foi fácil criar em C++:
Usar a biblioteca de rede existente e escrever manipuladores de pacotes para sincronização facilita a criação do código de sincronização em C++.

 

(Pro) A segurança depende do receptor do pacote:
O código de deserialização está bem escrito e falhas de segurança podem ser evitadas se você tiver cuidado. No entanto, você deve ser cauteloso durante a profanação de pacotes, pois um único erro pode introduzir vulnerabilidades de segurança.

 

(Pro/Con) A confiabilidade depende da biblioteca de rede:
Optamos pelo uso de UDP (User Datagram Protocol) para transmitir pacotes em vez de TCP (Transmission Control Protocol). O TCP não permite o envio de pacotes não confiáveis, o que significa que o protocolo deve garantir que todos os pacotes sejam entregues. Essa abordagem resulta em sobrecarga adicional de largura de banda. Para um jogo de simulação em tempo real, o uso de TCP pode levar a alta latência devido à perda de pacotes. O TCP sempre preserva a ordem dos pacotes, resultando em altos atrasos devido à sobrecarga. Isso pode ser problemático ao considerar a distância que o veículo de um jogador pode percorrer durante esse tempo. No caso, digamos, de latência de 500ms e o veículo de um jogador viajando a uma velocidade de 150 km/h se moverá 41 metros a cada segundo, o que significa que ele pode viajar até 20 metros em 0,5s. Tal atraso poderia causar problemas com o posicionamento do veículo do jogador atual, levando o jogo a se tornar injogável.

 

O UDP não garante a entrega de pacotes nem preserva a ordem dos pacotes, ao contrário do TCP. No entanto, é possível construir uma camada de confiabilidade sobre o UDP. Muitas bibliotecas de rede oferecem recursos como envio de pacotes de confirmação, armazenamento em buffer de pacotes até que os necessários cheguem e contagem de pacotes. Embora construir essa biblioteca possa ser um desafio. Apesar disso, é preferível usar uma biblioteca de rede que ofereça recursos de confiabilidade sobre UDP em vez de TCP. A razão para isso é que a biblioteca de rede permite a transmissão de pacotes confiáveis e não confiáveis simultaneamente. Ao enviar um pacote, pode-se decidir se a biblioteca de rede deve garantir sua entrega ou não.

 

(Con) Código de alto e baixo nível é misto:
Misturar código de rede com recursos de jogabilidade pode tornar o código mais difícil de entender e manter, especialmente quando há vários conceitos de alto nível para sincronizar.

 

(Con) Não é bem dimensionado:
cada tipo de entidade requer um conjunto diferente de propriedades e código de sincronização, o que pode tornar o código difícil de escalar. Por exemplo, o código de sincronização para veículos de IA difere do código de sincronização para veículos de jogadores, e o código de sincronização para semáforos difere do de passageiros de ônibus. Com vários tipos de entidade, é um desafio criar códigos de rede diferentes para cada um deles, tornando a base de código difícil de manter.

 

(Con) Enviar apenas propriedades modificadas para economizar largura de banda é difícil:
Suponha que já enviamos o estado leve do veículo e ele foi recebido pelo cliente. Nesse caso, é desnecessário reenviar as mesmas informações se apenas a posição do veículo tiver mudado. Isso pode ser um problema se o código cria pacotes manualmente para cada tipo de entidade separadamente. É um desafio criar código que envia apenas propriedades modificadas para economizar largura de banda.

 

(Con) A sincronização está espalhada por toda a base de código, tornando desafiador otimizar o uso da CPU:
Como o código de sincronização é colocado em muitas partes do código, é difícil otimizar o uso da CPU. Se o código de sincronização fosse colocado junto, seria mais fácil medir e otimizar o uso da CPU. Além disso, é desafiador usar mais de um núcleo/thread de CPU para sincronização, o que pode resultar em atraso no jogo.

 

(Con) Difícil adicionar novos recursos:
Sempre que você precisar adicionar um novo recurso sincronizado ao código, você precisará escrever código de sincronização de rede de baixo nível novamente. É muito simples errar lá, mas não é o maior problema. Como a largura de banda é limitada para servidores dedicados (1Gbps, digamos), você não pode enviar muitos dados para um cliente específico. Você só deseja enviar dados que o cliente deve estar interessado. Tipo, só jogadores por perto. É difícil manter a lógica para cada coisa, que vai sincronizar propriedades com o cliente que chegou a um local específico, acabou de entrar no jogo, ou saiu do local, então a coisa deve ser desovada. A complexidade é alta. Além disso, pacotes não confiáveis podem não ser recebidos pelo outro lado, e você não sabe se eles foram recebidos e deve reenviar dados de propriedades modificados. Você pode garantir a confiabilidade enviando pacotes confiáveis, mas toda vez que você faz isso, isso traz custos com isso.

 

---

 

Rumo à estrutura de replicação

 

Eventualmente, os problemas acima mencionados levarão à necessidade de uma solução geral para sincronizar objetos de jogo e suas propriedades, o que é comumente conhecido como replicação. O código de replicação fornece uma interface para replicar entidades e suas propriedades. Sua arquitetura é simples:

• O servidor inicia a sessão de replicação.
• Os clientes se conectam à sessão de replicação.
• O servidor cria um objeto de veículo para o cliente.
• O servidor adiciona o objeto de veículo à sessão de replicação.
• A sessão de replicação cria pacotes genéricos e os envia para garantir que os clientes recebam as entidades nas quais estão interessados e suas atualizações.
• Quando um cliente se desconecta, o veículo é destruído e removido da sessão de replicação no servidor.
• A sessão de replicação garante que o veículo seja removido de todos os clientes.

Esse design simplifica a arquitetura de código de rede e fornece um único ponto de responsabilidade para sincronizar objetos de jogo. Embora esse design tenha inúmeras vantagens, incluindo uso controlado de largura de banda, código simplificado e melhor segurança, ele também tem algumas desvantagens, como a dificuldade em desenvolver uma estrutura de replicação confiável e o potencial para bugs. Vale a pena observar que a sessão de replicação é apenas uma parte da estrutura e há vários outros aspectos, incluindo suporte para o Sistema de Componentes de Entidade interno, vários tipos de dados, gráfico de replicação e Chamadas de Procedimento Remoto.

 

---

 

Conclusion

 

We hope this blog provided a useful insight into the work our Game Development team is doing behind the scenes. In the short term, implementing the replication framework will lead to clear, high-level, and manageable code, making it easier to synchronise existing game features and new ones. In the long run, it will enable the addition of more complex game features, such as AI traffic, a shared economy, and a global reporting system.

 

 

--> Ver post na página inicial

Adding AI traffic to TruckersMP would be really cool! But it's important to think carefully before doing so. One concern is that it could make the virtual roads even more congested, especially on the busiest routes. Additionally, adding AI traffic could make the game run slower and delay gameplay.

But on the other hand, having more interaction and making the game more realistic is really cool! It could even make the game experience more customizable. So if everything is thought through carefully, adding AI traffic could be a really good idea for TruckersMP!

Anyway, good luck with the development! We're excited to see this new feature in action. If it's implemented well, it will definitely be awesome for us.

[Zulnex]

Great news. It's going to be interesting to see what the future holds for TMP.

 

Looking forward to AI traffic.

[HAPPY-TRUCKER]

7 hours ago, Sinyordess. said:

a good news that players have been waiting for a long time and we finnaly got the news

  this new move will really ensure that players do not get bored while traveling in different parts of the map and will be able to travel more beautifully and have more fun but there are some situations that will be added to this game will be players who can drag artificial intelligence vehicles that will be added to this game into bad negativity situations such as having accidents and deviating from the road at the very beginning if this progress comes I can't even think on the C / D road many players will abuse it which is not a good sign and we are waiting with curiosity to see what kind of measures will be taken

 

[INS FEATHER]

Sounds very intresting. Best of luck TMP for future projects

[TeamWolfyta]

This is going to be awesome. I don't understand specifics but the new features and better maintainability will be awesome. Can't wait to see this go to production, Awesome work TruckersMP and especially the Dev team, Keep it up!