Ae, Saddan! Grande idéia, fazer um cliente para o TabajaraHost. O protocolo já é conhecido, pode ser adaptado para um flight simulator livre pra implementar isso. Teria que ser adaptado para massive multiplayer. Você seria capaz disso? Estudar um simulador, o protocolo Warbirds e implementar um sistema aberto? Teria de haver facilidades para criação de terrenos, planes, veículos, modelos de danos, cenários. Acho que deveria ser capaz de ser usado sozinho ou em rede. Penso num sistema que use informações geográficas livres (altura e cobertura de terreno) para se recriar qualquer lugar do mundo (como os mapas do AcesHigh). Algo como um Target Rabaul, mas open source.
hmmm... Saddan chegou a conversar comigo por msn um tempo atrás sobre isso também. Franz falou comigo outra idéia (algum tempo atrás também), vamos ver se a gente concilia isso... -> Saddan: cliente externo, um programa externo que controle as AIs -> Alemão: Adaptação para massive multiplayer, protocolo Warbirds -> Franz: DLL que o tabahostserver carrega Pensando um pouco, Cliente externo que use o protocolo Warbirds e tal Vantagens - certa independência no desenvolvimento das AIs para com o servidor; - drones controlados por programa externo. Desvantagens - trabalho para codificar as informações; - limitações a somente informações determinadas pelo protocolo Warbirds; - no servidor teria de ser adaptada a "multiconexão" (dependência dos programas); - uso de 1 conexão a mais; - dado que vai ter bastantes AIs rodando na arena, aumento no tráfego de informações; - em conseqüência, mais possibilidades a lag. DLL Vantagens - também há uma certa independência no desenvolvimento das AIs para com o servidor. - não é usado o protocolo do Warbirds; - não é gasto banda com tráfego de dados -> necessariamente haveria, mas via memória/processador, o que é muito mais rápido. Desvantagens - teria de ser desenvolvido a "comunicação" Dados AI x Dados Server (interligação de como a DLL deverá pegar os dados do servidor, e como devolver os dados para o servidor - dependência dos programas); - drones controlados pelo programa servidor, ou seja, mais tarefas para o mesmo processador executar - em conseqüência do ítem anterior, possibilidade de Lag, mas em menor impacto. Agora aqui vai a minha sugestão: Utilização de DDE Para quem não sabe o que é isso, é uma comunicação entre aplicativos diferentes na mesma máquina, que se dá pelo sistema operacional. Para saber mais, recomendo esse link aqui: http://sheepdogguides.com/dt4n.htm Penso que, quem tem que se dar o trabalho de thread-ar as coisas é o SO, ele foi desenvolvido dessa maneira, e a gente pode utilizar isso. O servidor deve executar apenas o papel de servidor, não o de controlador de AI, de comboio de tanks, ou qualquer outra coisa. O servidor deve apenas servir: pegar um dado daqui, repassar para outro lado, manda um pacote para lá, diz a tarefa do que deve ser feito com esse pacote para o tal programa, enfim, divisão de tarefas, sendo o servidor trabalhando única e exclusivamente para gerir o tráfego de dados (e algumas coisas básicas). Vantagens - independência no desenvolvimento da atividade principal de ambos os programas; - não gastar uma conexão no protocolo Warbirds; - comunicação rápida (e mais dedicada) entre os programas; - distinção do que e como interpretar os dados: protocolo Warbirds para o cliente jogador e protocolo AI (DDE) para o cliente AI; - "independência" no rolamento da execução dos programas (o SO separa uma parte de tempo para ambos os programas, em que o podemos até determinar a prioridade de execução de um programa). Desvantagens - pesquisar como implementar DDE no linux (sei fazer isso no delphi/windows ...); - trabalho com implementação da comunicação DDE Servidor <-> Aplicativo de AI (dependência dos programas); - Ambos os programas (servidor/aplicativo ai) devem estar na mesma máquina. Abraços
A coisa mais proxima que existe disso no linux eh o CORBA, e acredite, melhor a gente ficar com sockets...
- drones controlados pelo programa servidor, ou seja, mais tarefas para o mesmo processador executar Se a .so for colocada em outra thread, nao vai rodar no mesmo processador. Se o sistema for bem feito, aceita ate bewoulf cluster...
hmmm Então fazer DLL (.so) acho que pode ser a melhor opção... Se no programa servidor for definido lugares globais de acesso aos dados, as AIs podem ter acesso rápido à informação que precisar, e o problema do thread for bem feito, teremos uma agilidade grande, podendo desenvolver a dll (.so) externamente. Basta colocarmos as mãos na massa, e já irmos anotando quais são as informações que as AIs devem ter acesso, e criar o método para acessar esses dados de forma prática (franz me disse tempos atrás: struct).
cara, eu vou tentar vim sim, é quase certo... q eu vou vir cara!!, mas se acontecer algum imprevisto, ja sabe o motivo :/
