Multiplayer e comunicação

gordoido escreveu:Estou inciando agora o meu projeto e estou com dificuldade em escolher o framework de network que uso.
Entre as opções eu tenho:
1 - network da Unity(HLAPI), 
2 - Photon, 
3 - criar um servidor node.js com pacotes de sokets já existentes.
4 - SignalR da Microsoft WebSoket.


Inicialmente optei por usar o SignalR da Microsoft mas vejo que ele é bem voltado para Brwonzer e ai fiquei em duvida se vale apena continuar com ele.


E usar node.js eu não tenho muito conhecimento e estou meio assim de fazer com ele.



O Photon e o da Unity(HLAPI) tem um problema muito forte ao meu ver. Que é a questão de instanciar o servidor no cliente e ser obrigado a usar um servidor deles sempre, quando eu tiver que armazenar os dados em uma base de dados eu teria que gerar códigos no cliente para atualizar o servidor deles onde faz as replicações de dados via soket e tal... e fazer chamadas para um outro servidor meu onde eu atualizo uma base de dados e acredito que isso ficaria bem mais lento por ir em dois servidores.



O que vocês me indicam a usar alguem já trabalho com algum game multiplayer e possa esclarecer essas minhas duvidas.

MRX escreveu:Cara no meu projeto optei por network da Unity(HLAPI) por conta que pretendo fazer um master server usando hospedagem, no começo pensei em usar o photon por ele ter varias possibilidades ja prontas más não vejo muito diferente do Unet, o Unet está me satisfazendo até agr e por enquanto não tive problemas no meu projeto, más é bom experimentar os que você achar mais em conta 

gordoido escreveu:
O Photon e o da Unity(HLAPI) tem um problema muito forte ao meu ver. Que é a questão de instanciar o servidor no cliente e ser obrigado a usar um servidor deles sempre, quando eu tiver que armazenar os dados em uma base de dados eu teria que gerar códigos no cliente para atualizar o servidor deles onde faz as replicações de dados via soket e tal... e fazer chamadas para um outro servidor meu onde eu atualizo uma base de dados?

gordoido escreveu:

MRX escreveu:Cara no meu projeto optei por network da Unity(HLAPI) por conta que pretendo fazer um master server usando hospedagem, no começo pensei em usar o photon por ele ter varias possibilidades ja prontas más não vejo muito diferente do Unet, o Unet está me satisfazendo até agr e por enquanto não tive problemas no meu projeto, más é bom experimentar os que você achar mais em conta 

Mas como que você faz para trabalhar com os armazenamentos de dados que forem necessários?

MRX escreveu:

gordoido escreveu:

MRX escreveu:Cara no meu projeto optei por network da Unity(HLAPI) por conta que pretendo fazer um master server usando hospedagem, no começo pensei em usar o photon por ele ter varias possibilidades ja prontas más não vejo muito diferente do Unet, o Unet está me satisfazendo até agr e por enquanto não tive problemas no meu projeto, más é bom experimentar os que você achar mais em conta 

Mas como que você faz para trabalhar com os armazenamentos de dados que forem necessários?

 
Usando Mysql

artplayer escreveu:

gordoido escreveu:
O Photon e o da Unity(HLAPI) tem um problema muito forte ao meu ver. Que é a questão de instanciar o servidor no cliente e ser obrigado a usar um servidor deles sempre, quando eu tiver que armazenar os dados em uma base de dados eu teria que gerar códigos no cliente para atualizar o servidor deles onde faz as replicações de dados via soket e tal... e fazer chamadas para um outro servidor meu onde eu atualizo uma base de dados?

Sempre usei Unet e sempre usei VPS ou dedicados com uma compilação headless para o servidor. Então dizer que você é obrigado a utilizar os servidores deles não me parece estar correto.

Para banco de dados, eu utilizava uma API php/Mysql geralmente no mesmo servidor, fazendo as consultas via POST(wwwforms) e restringindo o acesso tanto do Apache quanto do Mysql somente a localhost.

Aprendi muito com Unet, sou entusiasta de o início, mas pra produção mesmo, pelo menos pra mim não rola. Por causa de questões como previsão e interpolação e Ipv6 que o Bolt resolve com praticamente um click.

Lógico, tudo depende muito do estilo do seu jogo e do seu tempo disponível/tamanho da equipe.

Abraços.

artplayer escreveu:Exato Gordoido;
Por isso eu utilizo uma api php rodando direto no servidor. Só quem tem acesso ao banco de dados e ao apache e o servidor.
Não sei se ficou  claro, mas quem acessa o banco de dados e única e exclusivamente o php, que é uma linguagem interpretada e não compilada. O cliente apenas recebe os retornos do sevidor. Adicionalmente, eu ainda posso reforçar a segurança me valendo de sessions, ssl e afins. Para evitar que os dados de retorno possam ser manipulados externamente de alguma forma, restrinjo  o apache apenas a localhost ( o próprio servidor ).
Já deixei trechos do código aqui no fórum e ia pro github, mas estou utilizando em um projeto privado e por contrato, nenhuma parte do código pode ser exposta.

gordoido escreveu:

artplayer escreveu:Exato Gordoido;
Por isso eu utilizo uma api php rodando direto no servidor. Só quem tem acesso ao banco de dados e ao apache e o servidor.
Não sei se ficou  claro, mas quem acessa o banco de dados e única e exclusivamente o php, que é uma linguagem interpretada e não compilada. O cliente apenas recebe os retornos do sevidor. Adicionalmente, eu ainda posso reforçar a segurança me valendo de sessions, ssl e afins. Para evitar que os dados de retorno possam ser manipulados externamente de alguma forma, restrinjo  o apache apenas a localhost ( o próprio servidor ).
Já deixei trechos do código aqui no fórum e ia pro github, mas estou utilizando em um projeto privado e por contrato, nenhuma parte do código pode ser exposta.

É possivel eu usar a biblioteca do Unet ou Photon dentro de um serviço meu e no cliente(unity) eu só chamar esse meu serviço? Não gosto da idéia das minhas regras ficar no meu cliente. E os exemplos que eu vejo desses caras os servidores são instanciados dentro do cliente, e isso me incomoda bastante já que sendo assim eu teria que colocar minhas regras no cliente.

recagonlei escreveu:É basicamente isso, mas no caso você mandaria a mensagem para um servidor unet(ou outros) e nele iria calcular físicas e lógicas, salva-las e mandaria de volta para os clientes. Dessa forma, o servidor dedicado(ou salas, tendo o gameserver spawnado em um host remoto) é responsável por tudo e as chances de alterações(crackers e hackers) são mais baixas.

gordoido escreveu:

É possivel eu usar a biblioteca do Unet ou Photon dentro de um serviço meu e no cliente(unity) eu só chamar esse meu serviço? Não gosto da idéia das minhas regras ficar no meu cliente. E os exemplos que eu vejo desses caras os servidores são instanciados dentro do cliente, e isso me incomoda bastante já que sendo assim eu teria que colocar minhas regras no cliente.

artplayer escreveu:

gordoido escreveu:

É possivel eu usar a biblioteca do Unet ou Photon dentro de um serviço meu e no cliente(unity) eu só chamar esse meu serviço? Não gosto da idéia das minhas regras ficar no meu cliente. E os exemplos que eu vejo desses caras os servidores são instanciados dentro do cliente, e isso me incomoda bastante já que sendo assim eu teria que colocar minhas regras no cliente.

Não sei se entendi bem. 
Você diz no caso de uma engenharia reversa o "cara" ver quais regras, nomes e tudo mais estão sendo utilizadas no servidor e de alguma forma se beneficiar disso?

recagonlei escreveu:É meio inviável colocar o host no cliente, é melhor criar um master server que controle tudo inclusive as atualizações das informações... Ficará muito inseguro, com o client sendo host, com o masterserver além de flexibilidade, mais segurança e um controle bem mais prático. Isso se aplica tanto como servidores dedicados, quanto salas privadas ou públicas. Só não é inviável, quando a intenção é disponibilizar o host, como no minecraft, o cs(ele é um exemplo dos dois sistemas juntos, servidores oficiais e não oficiais), rust, entre outros.

gordoido escreveu:seguindo esse modelo acima minha camada de gateway seria onde ficaria minha autenticação, segurança e tudo mais ... 

E o meu gatway acessaria todos os meus serviços necessarios.

E o a camade view ficaria por conta da unity e do unet fazendo o trabalho de espelahar minhas informações via soket.

Como eu tenho uma camada de segurança caso alguem tente rakear na camada de view eu consigo verificar o usuário e parar a partida.

A esse Master Service pelo que li é legado já e não é muito indicado a usarmos.

Acho que vou implementar essa iséia dando certo compartilho com voces.

O que vocês acharam da arquitetura é por ai mesmo ta uma droga qualquer observação é valida?

recagonlei escreveu:

gordoido escreveu:seguindo esse modelo acima minha camada de gateway seria onde ficaria minha autenticação, segurança e tudo mais ... 

E o meu gatway acessaria todos os meus serviços necessarios.

E o a camade view ficaria por conta da unity e do unet fazendo o trabalho de espelahar minhas informações via soket.

Como eu tenho uma camada de segurança caso alguem tente rakear na camada de view eu consigo verificar o usuário e parar a partida.

A esse Master Service pelo que li é legado já e não é muito indicado a usarmos.

Acho que vou implementar essa iséia dando certo compartilho com voces.

O que vocês acharam da arquitetura é por ai mesmo ta uma droga qualquer observação é valida?

Master Server velho... E qual você está dizendo? O antigo Master Server da Unity, sim... Ele é obsoleto e da API antiga. Tu ao mesmo deu ao trabalho de visitar o link que eu disse? Aquele não é o Master Server antigo e sim um sistema criado pelo Barebones, usando o HLAPI(Unet) e eu mesmo estou usando no meu projeto como base e estudo. Ele é um sistema completo, tudo que disse acima é basicamente implementado nesse assets. Ele tem um sistema de servidor dedicado, registros de salas, banco de dados, tudo isso GRATUITAMENTE. Estável e bom para estudo, para ti que não tem conhecimento, essa é uma boa escolha. Ele é divido dessa forma:

Master Server -> Spawners* -> Módulos -> Sistema de database, entre muitos outros. 
*O Spawner é o módulo usado para spawnar salas, quando criado uma sala, ele aparecerá na lista de salas e esse módulo é responsável pelo gerenciamento delas.

Nas próximas vezes, cheque o material dado antes de comentar! Abraços e um ótimo feriado pagão pra ti!

De olho nas regras:
3- Não é permitido postar novamente em um tópico mais de três vezes seguidas. Caso queira adicionar algo depois de três posts consecutivos, aguarde 24h. 

recagonlei escreveu:Entendo pouco, ainda tem muito estudo pela frente... Mas o que eu entendo é basicamente isso... A arquitetura que pensou, é interessante, dependendo do estilo online que seguirá seu game... Mas já lhe adianto, que cliente sendo host, é inviável se for ter informações que não devem ser acessíveis do jogador, de maneira tão fácil, o mais correto é um sistema de gameservers para spawn de salas que as controlam e sejam o host, como nos outros, encarregados de desenvolver todo o flow do game.