A comunidade brasileira de desenvolvimento e programação de jogos.
Bem-vindo: Qua Dez 02, 2020 9:18 am

Todos os horários são GMT - 3 horas




Criar novo tópico Responder  [ 55 mensagens ]  Ir para página Anterior  1, 2, 3, 4  Próximo
Autor Mensagem
 Título:
MensagemEnviado: Ter Out 24, 2006 2:45 am 
Offline
Membro júnior
Avatar do usuário

Registrado em: Ter Ago 08, 2006 5:52 pm
Mensagens: 49
Localização: São Bernardo do Campo - SP - Brasil
Retomando (em modo bíblia).

Dei uma estudada sobre o GLScene e fiquei surpreso. Achei que fosse mais um wrapper do OpenGL que uma biblioteca repleta de funções prontas. Quando li teu comentário sobre Verlet ainda não havia caído a ficha. Estou curioso com tudo isto, parece muito mais simples e completo que imaginava. Tem muita coisa que é preciso para começar um game 3D. Estou acostumando com estas coisas meio que na unha em C/C++, acho que é uma boa oportunidade para aprender Delphi. Só assim terei utilidade como programador no projeto. :0/

Bom, vou levantar algumas questões técnicas que vêm à cabeça no momento:

- Editores de cenário e unidade;
    Qual a função de cada editor que está trabalhando? São editores para desenvolvedor (possibilitando jogadores a fazerem seus MODs), ou editores in-game, que configurariam as regras das unidades e do cenário para a partida?
- Levels;
    Acredito que um game como este não irá requerir cenários out-door grandes, mesmo assim me preocupa como será feita a divisão espacial dos mesmos, como serão trabalhadas as múltiplas camadas de textura para o terreno, o LOD, a colisão e coisas do tipo. Para facilitar: do que você já viu, o essencial para o funcionamento e gerenciamento do cenário está contido no GLScene? Até onde podemos usar um cenário feito em modelador 3D externo dentro do GLScene, já contendo a exemplo mapeamento de textura, vertex color para múltiplas texturas, posição de objetos (players, itens, outros objetos móveis ou replicados), light-mapping, dados distinguindo materiais que poderão ser interpretados de forma diferente pelo game ou coisas do gênero? Com este planejamento é possível se ter uma idéia mais concreta de quão flexível pode ser a construção do conteúdo do game, e quais possibilidades/limites existem para o gameplay.
- Sistema de partículas;
    Vi que o GLScene tem suporte a partículas, mas não sei ainda como funciona. Os tiros e explosões, como efeitos mínimos para o visual do game, terão que ser construídos baseados neste sistema ou em um novo. Se for algo fácil e rápido, pode-se produzir efeitos climáticos, de detalhe de contato ou de cenário etc.
- Rede;
    Se for adotada a rede para batalhas em multiplayer, o Delphi me parece amigável para implementar a logística da mesma. Estou certo? Como funcionam threads no Delphi, você pode ter um Update() constante e um Render() à parte, tranquilamente? Isolando os "ticks" de atualização de pacotes de rede de outras camadas intermitentes seria a solução mais viável, certo?
- Animação;
    Além da física aplicada ao GLScene, que imagino ser suficiente para a maior parte dos requintes de simulação do game, como você está fazendo a animação do tanque e peças móveis (como esteira, torre etc.)? Como o modelo é feito no modelador? É parte feita na mão, e por isso surgiu a necessidade do editor de unidades?
- Conteúdo 3D.
    Eu tenho um conhecimento razoável em modelagem no Lightwave e estou aprendendo o Modo atualmente. Blender faz um bocado de tempo que não trabalho, mas na necessidade sei me virar nele. Gostaria de usá-los para ajudar no conteúdo do game, porém já vi que o GLScene aceita apenas alguns formatos. O que posso fazer, eu tento exportar no formato OBJ dentro das especificações técnicas que você disser sobre o item anterior ou temos como aceitar outros formatos senão os mencionados no site do GLScene, através de outras bibliotecas por exemplo? O mesmo se aplica aos cenários.

Outras menos importantes, "cosméticas":

- Câmera;
    A interpolação é interessante, os parâmetros podem ser vários como lag, limitador de aceleração etc. Pode-se acrescentar também um shake/quake (tremor) para trazer impacto à cena quando um tiro atingir a área próxima do jogador - mede-se a distância da colisão com o player e rotaciona inversamente proporcional os eixos (pitch, yall e roll) da câmera, usando por exemplo um B-Spline com o tempo também relativo à distância. Talvez seja necessário também um sistema para evitar a oclusão sem atrapalhar no gameplay logicamente, uma vez que trata-se de um game em terceira pessoa. A propósito, você usa quaternions para armazenar a rotação da câmera?
- Pós-produção.
    Notei no DropTeam que há o efeito "Bloom", mais visivelmente no céu. Como você comentou que gera texturas dinamicamente nos últimos experimentos com terreno, talvez seja possível trabalhar no pipeline e gerar RTT (render to texture) - vi algo do gênero no GLScene como "scene after-effects", mas este trata por objeto. Com isto, poderemos reproduzir o efeito sem grandes dificuldades, adicionando a textura gerada com blend sobre o render atual, tornando o recurso visível para jogadores com hardware antigo (uma nVidia TNT2 serve). Em adição a este efeito, poderia-se acrescentar visões noturna e por calor, glow, depth of field, filtros, projeções de textura, sombras suaves entre outros. É preciso, contudo, avaliar o peso que isto afeta sobre a estrutura atual do render. Uma pós-produção mais simples seria o de não usar o RTT, aplicando texturas procedimentais com blend sobre o render, produzindo efeitos como interferência na imagem, chuviscos (gotas d'água), filtros de cor entre outros. Tudo é uma questão de macetes, usando biasing da textura, mip-mapping, z-buffer, canais de textura e outras artimanhas. O que acha?


Bom... Espero não ter exagerado nos posts. Isto tá parecendo mesmo uma bíblia, mas quero só elucidar melhor sobre o projeto e tentar ajudar na medida do possível. Assim podemos levar o protótipo com o compromisso de produzir um game decente sem obrigação, apenas pela diversão de fazer algo que faça a diferença no futuro. O negócio é irmos trabalhando etapa por etapa, planejando macro e depois detalhando cada progresso para o game sair conforme o esperado. :0)

Deixe-me retificar um trecho que havia escrito no post anterior: o game que, entre outros, lembra o projeto TC é o Unreal Tournament 2004 (PC) no modo Onslaught, não o UT 2003.

Se lembrar de algo mais, volto a publicar.

[]'s

_________________
Rodolfo Calabrezi

Software Engineering
Business Development


http://cruelbyte.com
skype, twitter, facebook: rcalabrezi
linkedin: http://www.linkedin.com/in/rcalabrezi


Voltar ao topo
 Perfil  
 
 Título:
MensagemEnviado: Ter Out 24, 2006 8:57 pm 
Offline
Membro avançado
Avatar do usuário

Registrado em: Qui Jan 12, 2006 7:30 pm
Mensagens: 434
Localização: irc.voidzero.com - #gamedev
@Dracodomain:
Excelentes sugestões.
Estarei respondendo aos seus posts ainda esta semana, estou pensando em mais algumas coisas, e estou ainda analisando o que você sugeriu e opinou.
Portanto, em breve terá uma resposta minha.


@Dragon Ryu:
Aprendi olhando os demos, e através de várias horas brincando com o GLScene. Como não tem documentação, tem que ser por aí mesmo...
Tem também o newsgroup deles (você pode achar na página do GLScene).


Sobre o projeto, melhorei a parte que fazia a mixagem das texturas, para que as bordas ficassem mais suaves.
Hoje, consegui fazer um gerador (básico) de terrenos, com ele, dá pra gerar terrenos randomicamente, e, a partir do terreno gerado, uma textura é gerada com base nele.

Uma screen pra demonstrar:
Imagem

_________________
The best performance improvement is the transition from the nonworking state to the working state.
~J. Osterhout


Voltar ao topo
 Perfil  
 
 Título:
MensagemEnviado: Ter Out 24, 2006 10:13 pm 
Offline
Membro avançado
Avatar do usuário

Registrado em: Qui Jan 12, 2006 7:30 pm
Mensagens: 434
Localização: irc.voidzero.com - #gamedev
Dracodomain, sobre seu penúltimo post:


dracodomain escreveu:
Bom, talvez eu não tenha captado bem o espírito da coisa, portanto vou tentar ser o mais direto possível: gostaria mesmo de contribuir ativamente nisto. Posso?


Como a equipe atual é composta por somente uma pessoa, fazendo aquilo que eu (acho que) sei, que é programar, minha idéia era de que, após ter algo funcional, e digno de ser levado a público, começar a fazer recrutamento, e utilizar aquilo que estivesse pronto para atrair as pessoas (pois elas não precisariam se juntar à alguém que não tem nada concreto ainda). Imagino que seria mais fácil assim.

Mas, se sua intenção é ajudar, por que não?

dracodomain escreveu:
Seremos uma equipe, mantendo o mesmo ritmo de produção (no tempo livre), alvejando um possível produto com ou sem fins lucrativos.

Sim, estou trabalhando nele somente durante o tempo livre.
Sobre se ele ser lucrativo ou não, penso somente em fazer ele do melhor modo que eu conseguir fazê-lo.

dracodomain escreveu:
Ok. Gostaria de sincronizarmos o conceito do game, discutindo gameplay, tecnologia, apelo visual, marketing entre outras coisas.

Vou citar algumas características para falarmos a mesma língua. Se a essência do game estiver omitida ou distorcida, por favor me corrija.

Algumas questões conceituais já expostas seguidas de meus comentários:

- Tema futurista;
    Gostaria de desenhar alguns sketches e concepts de cenários, tanques, HUDs e outras interfaces. Podemos partir de um brainstorm, mas posso desenhar algo e, a partir disto, se decidiria o caminho.


Sem problemas com os sketches de tanques, e HUD.
No entanto, quanto ao cenário, existe um pequeno problema (meu), que vou dizer mais adiante, que é relacionado ao Pathfindind 3D (que eu nunca fiz, e, portanto, não tenho idéia da complexidade dele).

dracodomain escreveu:
- Inicialmente com modo single player;
    Acho que poderemos conversar bastante a respeito disto, pois vejo algumas ressalvas: para melhor aproveitamento do game em relação a testes, divulgação, participação e até comunidade, sugiro inicialmente um multiplayer. A menos que o modo single player seja exatamente como o do multiplayer com a adição de "bots", a vantagem de um multiplayer exclusivo é evitar o desgaste de programação com I.A. para os inimigos, a complexidade do level design em níveis estratégicos, missões e desafios para sustentar um game prolongado e cativante. O que acha? Um "bot" é relativamente mais simples de se programar, usando uma máquina de estados e path finding para começar.


Existem duas limitações do "Programador Líder" do projeto:
1) Nunca fez um jogo com PathFinding em 3D. Portanto, não tenho como dizer se conseguirei fazer isto ou não. Não tenho idéia da complexidade disso, nem quais seriam os impactos no jogo (inclusive na estrutura do próprio jogo).
Isso influencia o design de níveis, que, como eu havia dito, eu havia planejado duas versões. A primeira, mais simples, e, como você disse, se houver uma sensação de "quero mais", uma segunda versão.
Nesta primeira versão, eu faria utilização de Heightmaps, pois facilita muito a criação de AIs.

2) Nunca fez um jogo Multiplayer. Mais uma vez, é algo que eu não tenho experiência.
A primeira versão, pelo que eu imaginaria, seria somente single player, pois nunca fiz nada além de softwares convencionais cliente/servidor em redes. Sendo que nenhum dos dois fazia utilização de threads.
Mais uma vez, não sei como "preparar" a estrutura interna do jogo para comportar isso, por isso, eu estava planejando algo somente single-player, mas, como você mesmo disse, faria extensa utilização de bots, com um conjunto pré-determinado de IAs (algumas ofensivas, algumas defensivas, etc).


dracodomain escreveu:
- Gameplay FPS, com possibilidade de adição de RTS;
    Imagino como um misto. Seria feito o básico do FPS e adcionaría-se o RTS gradativamente no controle da unidade e nos itens dos levels. Algo que exija habilidade no domínio da unidade, toda estratégia está automaticamente implícita. Haveria mais de um modo de jogo, como rouba-bandeira, mata-mata, times etc. É assim que imagina?

É mais ou menos assim.

A minha idéia inicial partiria do seguinte:
O jogador não controla uma unidade "superior" aquelas controladas pela IA.
Ele controla um veículo(tanque) exatamente igual aqueles controlados pela IA. Mesma quantidade de vida, armas com o mesmo dano, veículo com a mesma velocidade.
Neste caso, o jogador não seria diferente dos outros Bots (o que, de certo modo, seria necessário para ter o gameplay parecido com FPS, nos tipos de jogos de captura a bandeira, etc).
No entanto, haveriam diversos tipos de jogos:

1) Captura a bandeira. Sempre tem que ter :)
Um mapa aberto. Dois times. Cada time com um determinado número de unidades (do mesmo tipo). O modo convencional.
2) Mata-mata: Dois times, com o mesmo número de unidades, que fazem spawn nos dois cantos do mapa. Ao morrer, o bot (ou jogador) é novamente "spawnado" no spawn point.
Depois de um tempo, pré-determinado, conta-se a quantidade de kills de cada lado, quem faz o número maior, ganha.
3) Todos contra um. Repare, que até agora, não se falou em power-ups, pois eles não existiriam, exceto neste aqui.
Funcionaria assim: O jogador estará sozinho, e terá que enfrentar um determinado número de inimigos. Neste tipo de jogo, não é spawn point. Se o jogador morrer uma vez, game over.
Para ajudar o jogador a terminar este tipo de jogo, haveriam power-ups (algo do tipo quad damage, mísseis, +100% armor, etc).
Exceto pelo power-up de vida, que, estaria somente disponível, ao se matar um inimigo (ou seja: cada inimigo morto "dropa" um health power-up).
De todos os jogos, este seria o mais tático, pois ele teria que enfrentar diversos inimigos, sozinho, e não poderia usar táticas "hit & run", pois não existem power-ups para a vida. No entanto, para que este tipo de jogo seja viável, são necessários cenários mais complexos, que permitam ao jogador tomar vantagem de diversos obstáculos.
Este tipo de jogo só estaria disponível na segunda versão de Tank Commander.
4) Neste tipo de jogo, entraria o RTS. Como você mesmo referenciou, o modo Onslaught de UT. Com uma pequena diferença:
Em uma mapa aberto (provavelmente grande), existiriam alguns pontos para serem capturados. Em cada ponto a ser capturado, existe um tipo de instalação (nada mais que um modelo 3D de um prédio), que, ao ser capturado, faz com que novos tipos de unidades sejam "spawnados" no mapa.
Por exemplo, ambos os times começam controlando tanques, em um número fixo (digamos 10). Como só existe um spawn point, os 10 tanques saem do mesmo lugar.
Após um determinado tempo, o time Azul captura um outro spawn point, com a estrutura que permite a utilização de Mechs.
Agora, Além dos 10 tanques serem "spawnados" entre os dois spawn-points, 4 mechs são "spawnados" nos dois spawn-points.
Digamos que o time Vermelho capture um outro spawn point, que libere 6 gunships.
Então, além dos 10 tanques "spawnados" nos dois spawn-points, 3 gunships aparecem em cada spawn point.
Quando uma instalação Azul não possuir nenhum do seu time em um raio X, e um veículo Vermelho se aproximar dela, ela passa a pertencer ao time Vermelho.

Este tipo de jogo, também só estaria disponível na segunda versão.

dracodomain escreveu:
- Gameplay rápido (em conjunto com o tema futurista), levando em consideração física, balística e outros requintes de simulação;
    Isto pode ser o grande trunfo do game, é aqui que o fun-factor se define. Pelo menos, acho que algo assim ainda não tem. Achei a tua idéia original muito legal, mas se apimentarmos ela um pouco pode ser melhor ainda. Tive uma idéia em relação a movimentação do tanque, talvez funcione, talvez não. Durante os testes de gameplay é que poderemos sentir como ela será aceita. É um pouco difícil de explicar: seria o de usar as teclas A, D, W e S para movimentar o tanque seguindo a orientação da câmera, como se fosse um Quake. Ao invés das teclas A e D rotacionarem o tanque, elas o movimentaria para a esquerda e direita, respectivamente, levando em consideração a câmera. Se o jogador segurar a tecla W, ele poderia ir para qualquer direção apenas movimentando o mouse. É estranho pensar assim, mas de repente pode ser mais intuitivo. Pegando o jeito da coisa, o gameplay se adequaria a esta velocidade rápida de movimentação e tiro. Consegue imaginar? Tenho a solução para a movimentação do tanque, respeitando as teclas pressionadas. A exemplo, se o tanque está virado para frente, ao pressionar A ou D ele viraria para uma destas direções (90 graus), mantendo-a em qualquer uma das teclas pressionadas. O mesmo aconteceria no sentido transversal e diagonal. Assim, o jogador preocuparia-se mais com a posição estratégica do tanque e a mira/altitude com o mouse. Caso for do jeito original que planejara, o game também ficará interessante, porém imagino que um pouco mais lento, lembrando o gameplay do Resident Evil (PSX), que o personagem roda sobre o eixo com o direcional esquerda e direta, e anda/retrocede com o direcional frente e trás. Bom, é uma idéia louca, apenas.


Foi o primeiro estilo que eu havia pensado :)
Hovercrafts (tanques fluturadores) e mechs seriam controlados desta maneira.
Só que na primeira versão, o jogador só controlaria tanques (que aliás, seriam a única coisa disponível).

dracodomain escreveu:
- Jogador controla unidades de combate, como tanque, mech, aeronave etc.;
    Inicialmente pode-se fazer o game apenas com tanques. Se for suficientemente divertido, com aquele gostinho de "quero mais", pode-se envolver em novas unidades. A vantagem é no balanço do gameplay, quanto menos unidades, mais fácil. Seria razoável?

Pensei em o jogador controlar somente o seu tanque.
No entanto, ele poderia definir a estratégia geral das unidades, por exemplo, 70% ofensiva, e 30% defensiva. Algo assim.

Uma coisa que eu não havia dito é que o jogador não seria o comandante de todo o batalhão de tanques (em princípio, haveriam dois times iguais combatendo).
Penso em times de 10, até 20 tanques, cada lado, sendo que somente um é controlado pelo jogador, todos os outros pela IA.

dracodomain escreveu:
- Levels com teor tático contendo obstáculos e construções;
    Como seriam os levels? Eu acho imprescindível um editor, ou um padrão para modelagem do level e itens de gameplay em um modelador 3D conhecido e importar o arquivo para o game com as regras inclusas. Apesar de complicar tecnologicamente, isto facilita muito para a produção de conteúdo do game. O que acha mais produtivo e gerenciável?


A primeira coisa que pensei foi na facilidade de implementação :)
Imagino ser complexo demais níveis modelados em um software do tipo 3DS Max, e importado para o jogo.

E, aliás, o editor de mapas que eu havia dito que estaria começando, não foi começado, pois estive trabalhando na geração procedural dos terrenos e texturas.

dracodomain escreveu:
- Público-alvo sendo jogadores táticos mas que gostam de shooters.
    Isto me soa bastante interessante, tendo lugar para vários perfis de jogadores. Quanto mais elaborado o gameplay e modos de jogo, maiores chances da comunidade de jogadores crescer. Se o game for enxuto e gratuito para download, mais fácil ainda. Se existirem campeonatos, apoio com patrocinadores como nVidia e AMD, melhor para o sucesso. Isto seria um plano para o futuro, mas já concebido e acrescentado dentro do game design document atual.


Eu nem havia pensado nisto, mas, pelo que vi, me encaixo neste perfil.
Foi pensando em reduzir o tamanho do download que decidi brincar com geração de mapas e texturas proceduralmente.

dracodomain escreveu:
Alguns games que lembram este (se lembrar de mais, acrescente à lista):

- DropTeam (PC), com adição de um gameplay mais frenético;
- Ratchet Gladiator (PS2), nos momentos de combate com unidades;
- Unreal Tournament 2003 (PC), no modo Onslaught dentro das unidades;
- Assault Rigs (PSX), como contexto.


Baixei o Assault Rigs, achei ele no Home Of The Underdogs.
É mais ou menos isso, só que os níveis deste jogo são bem fechados.

Outro jogo que me lembrei é o Uprising, que tem algumas coisas parecidas:
Você controla um tanque, e, em determinados locais, você cria uma base, para produzir mais unidades. É algo bem parecido, no mix de FPS e RTS.
Baixa ele aqui:
http://www.the-underdogs.info/game.php?id=4252


Sobre o seu último post:

GLScene tem várias coisas prontas, só não tem documentação, principalmente porque ela está em constante desenvolvimento.

dracodomain escreveu:
Bom, vou levantar algumas questões técnicas que vêm à cabeça no momento:

- Editores de cenário e unidade;
    Qual a função de cada editor que está trabalhando? São editores para desenvolvedor (possibilitando jogadores a fazerem seus MODs), ou editores in-game, que configurariam as regras das unidades e do cenário para a partida?


O editor de tanques (que ainda não está pronto...) serve pra "montar" um tanque. Ele não é utilizado para modelagem. Você importa as partes (Lagartas, Chassi, Torre e Cano), "monta" elas, e define onde ficam as armas, os pontos para a movimentação do terreno etc.
Ainda não pensei em MODs.


dracodomain escreveu:
- Levels;
    Acredito que um game como este não irá requerir cenários out-door grandes, mesmo assim me preocupa como será feita a divisão espacial dos mesmos, como serão trabalhadas as múltiplas camadas de textura para o terreno, o LOD, a colisão e coisas do tipo. Para facilitar: do que você já viu, o essencial para o funcionamento e gerenciamento do cenário está contido no GLScene? Até onde podemos usar um cenário feito em modelador 3D externo dentro do GLScene, já contendo a exemplo mapeamento de textura, vertex color para múltiplas texturas, posição de objetos (players, itens, outros objetos móveis ou replicados), light-mapping, dados distinguindo materiais que poderão ser interpretados de forma diferente pelo game ou coisas do gênero? Com este planejamento é possível se ter uma idéia mais concreta de quão flexível pode ser a construção do conteúdo do game, e quais possibilidades/limites existem para o gameplay.

O editor de mapas (que eu fiquei de começar, mas ainda não comecei) seria utilizado para, a partir de um heightmap, definir onde ficariam os spawn-points.
Mas, agora, como é tudo gerado proceduralmente, ele é inútil.

Quando aos demais tipos de cenários (do tipo Quake/Assault Rigs), eles podem ser modelados em aplicativos do tipo 3DS Max, e exportados para o formato 3DS.
GLScene suporta uma gama de formatos:
B3D - Blitz
3DS - 3D Studio
MD3 - Quake 3
MD2 - Quake 2
SMD - Half Life
MS3D - Milk Shape

E também arquivos BSP de Quake 3.

Para o particionamento, GLScene pode, construir uma Octree automaticamente do cenário (ou modelos 3D de objetos), utilizar tanto para Culling de partes invisíveis, como para colisão, checando somente as folhas em que o objeto está.

Para Heightmaps, como estou atualmente utilizando, GLScene implementa automaticamente ROAM.

Para um possível editor de níveis, imagino que poderia ser feito assim:
Após a modelagem 3D, ele é importado para um editor (construído por nós) para informar as posições dos objetos, que seriam salvos em um arquivo separado do modelo do cenário.
Isto permitira que um mesmo cenário poderia ser utilizado em mais do que um tipo de jogo.

Quanto as regras do jogo estarem no próprio cenário, prefiro nem pensar em tal complexidade...

Quanto as texturas, se importado um modelo 3DS corretamente texturizado, GLScene carrega e aplica automaticamente as texturas.

Quanto às colisões, existem diversos modos de calcular elas.
GLScene ainda possui métodos e managers específicos para colisões.

dracodomain escreveu:
- Sistema de partículas;
    Vi que o GLScene tem suporte a partículas, mas não sei ainda como funciona. Os tiros e explosões, como efeitos mínimos para o visual do game, terão que ser construídos baseados neste sistema ou em um novo. Se for algo fácil e rápido, pode-se produzir efeitos climáticos, de detalhe de contato ou de cenário etc.


Esta é a parte fácil :)
Tem vários tipos de efeitos, prontos.


dracodomain escreveu:
- Rede;
    Se for adotada a rede para batalhas em multiplayer, o Delphi me parece amigável para implementar a logística da mesma. Estou certo? Como funcionam threads no Delphi, você pode ter um Update() constante e um Render() à parte, tranquilamente? Isolando os "ticks" de atualização de pacotes de rede de outras camadas intermitentes seria a solução mais viável, certo?

As threads funcionam como em C.
Só que eu nunca fiz um jogo multiplayer...

dracodomain escreveu:
- Animação;
    Além da física aplicada ao GLScene, que imagino ser suficiente para a maior parte dos requintes de simulação do game, como você está fazendo a animação do tanque e peças móveis (como esteira, torre etc.)? Como o modelo é feito no modelador? É parte feita na mão, e por isso surgiu a necessidade do editor de unidades?


GLScene suporta modelos animados, como os de Quake 2/3 e Half Life.
Os modelos que eu uso são estáticos, mas separados.
O editor só "monta" (ou encaixa as peças).
A animação da esteira é só o Offset da textura dela que é alterado de acordo com o movimento (pra frente ou pra trás).
O restante do tanque é operado como partes separadas, só que GLScene trabalha com um sistema hierárquico. Se você alterar a posição (ou rotação, ou escala) do objeto pai, seus filhos sofrerão a mesma alteração. Então, é só saber qual parte movimentar.
No caso, o demo atual funciona assim:
Um cubo (root)
A lagarta (child do cubo)
O Chassi (child da lagarta)
A torre (child do chassi)
O Cano (child da torre)

Move o cubo pra frente, tudo se move. Gira a torre, a torre e o cano giram.

dracodomain escreveu:
- Conteúdo 3D.
    Eu tenho um conhecimento razoável em modelagem no Lightwave e estou aprendendo o Modo atualmente. Blender faz um bocado de tempo que não trabalho, mas na necessidade sei me virar nele. Gostaria de usá-los para ajudar no conteúdo do game, porém já vi que o GLScene aceita apenas alguns formatos. O que posso fazer, eu tento exportar no formato OBJ dentro das especificações técnicas que você disser sobre o item anterior ou temos como aceitar outros formatos senão os mencionados no site do GLScene, através de outras bibliotecas por exemplo? O mesmo se aplica aos cenários.


Se não me engano, a lista está desatualizada.
Existem diversos formatos que ela suporta.
Quanto à adição de novos, em teoria, é possível fazer subclassing, e adicionar as funções necessárias, só que eu nunca fiz isso.
Os cenários, poderiam ser mesmo 3DS, que GLScene contrói a Octree, e textura automaticamente.

dracodomain escreveu:
- Câmera;
    A interpolação é interessante, os parâmetros podem ser vários como lag, limitador de aceleração etc. Pode-se acrescentar também um shake/quake (tremor) para trazer impacto à cena quando um tiro atingir a área próxima do jogador - mede-se a distância da colisão com o player e rotaciona inversamente proporcional os eixos (pitch, yall e roll) da câmera, usando por exemplo um B-Spline com o tempo também relativo à distância. Talvez seja necessário também um sistema para evitar a oclusão sem atrapalhar no gameplay logicamente, uma vez que trata-se de um game em terceira pessoa. A propósito, você usa quaternions para armazenar a rotação da câmera?


Também pensei no shaking da câmera.
Quanto ao armazenamento das posições, GLScene faz isso, só preciso me preocupar como vou movimentar os objetos. Se o mouse vai pra direita, rotaciona pra direita. GLScene possui diversos métodos prontos pra isso.

dracodomain escreveu:
- Pós-produção.
    Notei no DropTeam que há o efeito "Bloom", mais visivelmente no céu. Como você comentou que gera texturas dinamicamente nos últimos experimentos com terreno, talvez seja possível trabalhar no pipeline e gerar RTT (render to texture) - vi algo do gênero no GLScene como "scene after-effects", mas este trata por objeto. Com isto, poderemos reproduzir o efeito sem grandes dificuldades, adicionando a textura gerada com blend sobre o render atual, tornando o recurso visível para jogadores com hardware antigo (uma nVidia TNT2 serve). Em adição a este efeito, poderia-se acrescentar visões noturna e por calor, glow, depth of field, filtros, projeções de textura, sombras suaves entre outros. É preciso, contudo, avaliar o peso que isto afeta sobre a estrutura atual do render. Uma pós-produção mais simples seria o de não usar o RTT, aplicando texturas procedimentais com blend sobre o render, produzindo efeitos como interferência na imagem, chuviscos (gotas d'água), filtros de cor entre outros. Tudo é uma questão de macetes, usando biasing da textura, mip-mapping, z-buffer, canais de textura e outras artimanhas. O que acha?


Existem diversos efeitos já prontos, como blur, por exemplo.
Ainda não olhei nesta parte.

dracodomain escreveu:
Bom... Espero não ter exagerado nos posts. Isto tá parecendo mesmo uma bíblia, mas quero só elucidar melhor sobre o projeto e tentar ajudar na medida do possível. Assim podemos levar o protótipo com o compromisso de produzir um game decente sem obrigação, apenas pela diversão de fazer algo que faça a diferença no futuro. O negócio é irmos trabalhando etapa por etapa, planejando macro e depois detalhando cada progresso para o game sair conforme o esperado. :0)


É como eu tinha pensado. Investir o tempo livre, e fazer o melhor que se conseguir.

_________________
The best performance improvement is the transition from the nonworking state to the working state.
~J. Osterhout


Voltar ao topo
 Perfil  
 
 Título:
MensagemEnviado: Qua Out 25, 2006 3:24 am 
Offline
Membro júnior
Avatar do usuário

Registrado em: Ter Ago 08, 2006 5:52 pm
Mensagens: 49
Localização: São Bernardo do Campo - SP - Brasil
Muito bom! Fico feliz em poder ajudar. :0)

Suas explicações e idéias foram concisas e esclarecedoras, está sendo um prazer participar do projeto. Ia até começar a desenhar algo para publicar hoje, mas depois que li sua resposta não pude conter a euforia de continuarmos detalhando os aspectos do game.

Mesmo que estejamos de acordo até agora, gostaria de adiantar que minhas opiniões serão sempre flexíveis. A idéia é, mais uma vez concordando com você, analisarmos o que é tangível e viável dentro do conhecimento e disponibilidade de cada um, fazendo o melhor de nós mesmos. Acho que é uma boa forma de trabalharmos em equipe: sermos abertos a discussões.

Também sou a favor de ingressar nesta investida com o intuito de produzir o melhor que conseguir e de proporcionar aos jogadores uma experiência única e agregadora ao mercado, e ainda, de auxiliar e incentivar outros desenvolvedores conosco ou em seus games, analisando e seguindo alguns de nossos passos, bastando acompanhá-los aqui mesmo na comunidade GameDev - ou seja, tentaríamos deixar o mais transparente possível cada procedimento seguido, a começar pelas discussões conceituais, técnicas etc., e assim esta pode ser uma boa contribuição para o site, o que acha?

Bom, vamos seguir em frente. :0)

A partir de agora, você não estará mais sozinho. Logo, seus problemas se juntarão aos meus problemas, e minhas soluções se unirão às suas soluções. Em outras palavras, irei te ajudar na estrutura do código com rede e também no path finding em 3D se quisermos implementá-los. Não se esqueça: não conheço Delphi, mas nem por isso vou deixar pesar sobre você toda a programação, ou deixaremos de aprender uma técnica nova para a melhoria do game se assim for preciso. Vamos decidir o melhor caminho a seguir em relação às dificuldades técnicas e conceituais juntos, a menos que tenha uma idéia melhor. :0)

Dito isto, gostaria de aproveitar e repensar com você, então, sobre algumas questões mencionadas anteriormente.

Level design:
    Pensando bem, também me agrada muito a idéia de gerarmos procedimentalmente o cenário, itens e posições de partida. É realmente mais simples de se implementar, sem dúvida. Isto lembra o game Worms e derivados, que o cenário é gerado no momento da partida. Podemos usar a chave do randomizador para utilizar o mesmo cenário em alguns casos (rede, game salvo ou coisas do gênero). E o bom é que você já tem adiantado muita coisa neste sentido. Só me ocorreu o seguinte: o game, no primeiro estágio conforme previu, seria divertido o suficiente em fun-factor, desafio, gameplay em geral, contendo apenas um mapa aberto randomicamente? Não vejo muitos problemas em fazermos o primeiro game bem simples, mas que a essência do gameplay esteja nele. De repente pode ser interessante produzirmos o cenário de forma randômica porém com conteúdo inteligente, analisando alguns aspectos de gameplay e posicionando itens e objetos de forma coerente pelo cenário gerado.

Multiplayer:
    A rede pode ser um desafio para nós, pois requer estruturalmente já implementada a conversação entre os módulos. Alguns engines, como o Cipher por exemplo, já trazem o servidor e o cliente em contato com o game, independente se for single player ou multiplayer. Também concordo contigo sobre a I.A. dos bots não ser complexa, e de repente até necessária independentemente desta questão, mas uma vez que estaremos programando um game com todos os aspectos de um multiplayer (time versus time na maioria dos casos), por que não prepará-lo para tal? Minha preocupação, novamente, é com a diversão do game. Até compreendo sua preocupação em ver uma versão do projeto pronta, mas é preciso estudar o quanto ela terá utilidade para a versão final - para o público, a expectativa de um game diferente pode não agradar; e para nós, refazer todo o código para suportar o multiplayer pode ser pior que começar a fazê-lo já pensando nisto. Eu também costumo pensar assim, "façamos o básico do básico antes e vejamos isto funcionando", mas é importante balancear o planejamento com as etapas, pois num game de FPS em primeira instância (em resumo ele é um), sem história ou missão, um single player pode não agradar aos jogadores (não se esqueça que eles são espertos, logo descobrem como funciona a I.A.). Entende meu ponto de vista? Aí te pergunto: jogar sozinho contra o computador um game de competição pode ser suficiente, tecnicamente e conceitualmente, para a primeira versão? :0/


Espero que consigamos achar o melhor jeito de fazer o trem andar nestas duas questões mais cabeludas. Realmente, fazer do zero em rede, é um pé no saco. Mas eu só insisto tanto neste assunto porque seria muito recompensador fazer um game que tivesse sua essência do gameplay já funcionando na primeira versão - se o fizermos como pensou, em suma ele estará assim, porém com dois agravantes: 1) não em toda sua plenitude pois só suportaria um jogador real e 2) teríamos provavelmente uma grande distância entre a versão um e dois do projeto. Aguardarei suas observações. :0)

Gostei dos modos de jogo que sugeriu, seriam similares aos games de FPS com estratégia como os que citamos no geral. Também achei muito interessante a idéia de ser em times, o jogador e demais bots. O primeiro game que me veio à tona foi o antigo Warhammer 40k (PC-DOS), onde você controlava 5 mariners, FPS, podendo alternar entre eles. Mas depois que entendi melhor, o mais próximo talvez seria o Unreal Tournament, em time, onde você apenas pode ordenar aos bots o que quer que eles façam (na melhor das hipóteses de modo de jogo).

Ainda estou em dúvida sobre qual o diferencial nosso em relação à movimentação do tanque, uma vez que temos certa liberdade no tema futurista e também por juntar um game frenético a um de simulação de tanques. Você pensa em balística, o qual se aponta para uma direção e o projétil faz a curva no ar? Tenho algumas idéias a agregar sobre isto, podemos discutí-las depois com calma.

Você está certo, o Assault Rigs é in-door praticamente e possui vários puzzles. É um game single player mesmo. Vou tentar fazer o download do Uprising, será bem útil certamente para conseguir entender melhor o gameplay.

Bem, é isto aí. Legal que estamos trabalhando juntos e trocando idéias, acho que isto pode ser útil para todos. Pretendo continuar sobre as questões técnicas novamente no próximo post, já que este é praticamente sobre conceito. Mas já adianto que adorei a forma o qual o GLScene e o Delphi trabalham na hierarquia dos objetos. Vi que é realmente bem amigável esta plataforma de desenvolvimento, só espero me acostumar à sintaxe (nunca me familiarizei com Pascal, mesmo programando há 22 anos). E eu aqui, perguntando se processava a câmera em matrizes, Euler, radianos ou Quaternions. :0)

[]'s

_________________
Rodolfo Calabrezi

Software Engineering
Business Development


http://cruelbyte.com
skype, twitter, facebook: rcalabrezi
linkedin: http://www.linkedin.com/in/rcalabrezi


Voltar ao topo
 Perfil  
 
 Título:
MensagemEnviado: Qui Out 26, 2006 4:14 am 
Offline
Membro júnior
Avatar do usuário

Registrado em: Ter Ago 08, 2006 5:52 pm
Mensagens: 49
Localização: São Bernardo do Campo - SP - Brasil
Estive pensando em mais uma saída ainda na questão conceitual.

Como hoje cheguei tarde em casa e já são quase 4h, tentarei ser breve. Mas antes de qualquer coisa, é apenas mais uma sugestão para refletirmos. Não veja como imposição, veja como um brainstorm que precisa ser amadurecido. :0)

Bom, fiquei martelando e pensei: entre nascer um código com estrutura diferente para aceitar a rede e um gameplay que em princípio funciona melhor com vários jogadores, talvez a alternativa seja mudar o estilo do game para se adequar melhor ao single player, mantendo gameplay e identidade previstos. Calma, não vamos mudar tudo, mas talvez possamos seguir um caminho diferente. Para te passar um pouco do que imaginei, tente esquecer por um momento o estilo do game atual e imagine um game com o perfil de "arcade", simples, frenético e vicioso, trazendo como principal objetivo do jogador um destaque entre outros jogadores. O destaque pode ser qualquer coisa, como o alcance de um nível (os cenários seriam "rounds" com puzzles e/ou ondas de inimigos para resistir - ainda podemos manter muita coisa do que temos), uma pontuação (baseada em quantidade e formas inteligentes de derrotar os inimigos, por exemplo), ou até mesmo modos de game como "resistir tanto tempo vivo", ou "fazer 1 milhão de pontos", coisas que um game "arcade" teria. Em vez de lutarmos contra inimigos de mesmo nível ou em times, poderíamos enfrentar inimigos em grande quantidade, lembrando algo que você previu no modo 3 de game, mais tático, que mencionou lá atrás. Ou ainda, você poder "ordenar" os bots do seu time, assim o jogador poderia se sobressair num dos destaques por usar a melhor estratégia. Existem sempre muitas possibilidades. Mas a idéia é pensar como um game "arcade".

Por que me veio isto: games "arcade" chamam a atenção pela simplicidade, competição e emoção que transmitem. Se conseguirmos sintetizar isto em um game de simulação de tanques com características "arcade", pode ser muito interessante e diferente do que há por aí. Primeiro porque simulação de tanques não é um tema muito explorado (tanto quanto shooters), segundo que, para nós, seria um game mais tangível de produzirmos (sem rede) e terceiro que estaríamos atingindo o público certo: os de single player.

É, tô morrendo de sono... Talvez esteja falando bobagem. Mas vale a pena pensarmos melhor a respeito. :0)

[]'s

_________________
Rodolfo Calabrezi

Software Engineering
Business Development


http://cruelbyte.com
skype, twitter, facebook: rcalabrezi
linkedin: http://www.linkedin.com/in/rcalabrezi


Voltar ao topo
 Perfil  
 
 Título:
MensagemEnviado: Qui Out 26, 2006 8:28 pm 
Offline
Membro avançado
Avatar do usuário

Registrado em: Qui Jan 12, 2006 7:30 pm
Mensagens: 434
Localização: irc.voidzero.com - #gamedev
Eu estava pensando hoje sobre o pathfinding, talvez seja possível implementá-lo com base em um pathfinding 2D, do tipo A*, que, ao que vejo, seria muito mais fácil de se implementar.

A idéia é a seguinte...

O mapa em escala de cinza (heightmap) utilizado no projeto consiste em um bitmap de 8 bits (256 cores). Aparentemente, utilizando bitmaps de 32bits resulta em efeitos indesejados, com deformações no terreno. O motivo disto, pra falar a verdade, nem ao menos procurei saber.

No entanto, o mapa gerado proceduralmente, é de 32 bits, que, eu, então, crio uma paleta para o novo bitmap de 8bits. Então, faço a conversão do bitmap de 32bits para o de 8bits. Deixando que o Delphi administre automaticamente a conversão de 32bits para 8bits resulta em um bitmap "deformado" pelas cores da paleta, mesmo que o bitmap utilize exclusivamente escala de cinza. Por isso, a conversão é "manual". (Na verdade, somente os 256 valores da paleta é que são criados).

Para o gerador de texturas, serve tanto um bitmap de 8 quanto de 24 ou 32 bits, mas, somente o canal R é utilizado para a análise do terreno, uma vez que, como se assume uma imagem em escala de cinza, os valores de R, G e B seriam os mesmos.

Bom, então, pensando nisto foi que eu tive um daqueles momentos "porque não pensei nisso antes?"

Se o bitmap gerado proceduralmente (do terreno) só necessita do canal R para a geração da textura, e para a renderização do terreno, também se faz necessário somente um canal, porque não usar os outros canais para guardar mais informações?

Deste modo, o bitmap 32 bits permaneceria na memória, e seria utilizado para o pathfinding.

Minha idéia é a seguinte:

Toda a colisão com objetos no terreno (prédios, árvores, etc) seriam baseados em algum outro canal do bitmap (G, B ou A).
Em teoria, eu poderia utilizar um outro canal para gerar decalques na textura do mapa, como por exemplo, criação de estradas.

Isso permitiria a colocação de objetos no mapa, como prédios.
Ao se escolher (randomicamente) uma posição no mapa para a colocação de prédios, seria necessário ajustar o heightmap para comportar o prédio (para que ele não seja colocado no lado de uma montanha, e fique metade enterrado, e metade flutuando). Para isso, bastaria igualar os píxeis adjacentes do heightmap.
Isso aconteceria no canal R.
No canal G, os píxeis "embaixo" do prédio, serão marcados como "bloqueados", bem como todos os outros píxeis que estariam "embaixo" dos outros prédios e árvores.
Realizei um pequeno teste, e, um píxel no mapa heightmap possui um tamanho aproximado do tanque (1 unidade). Seria ideal para marcar como intransponíveis objetos pequenos, como árvores, e muros.
Isso acabaria tornando o pathfinding bem mais simples, pois não estaríamos mais pensando em 3D, mas sim em 2D, com tiles, o que facilitaria imensamente isso.
Além de permitir a colocação de objetos no cenário, o que permitiria a implementação dos outros modos de jogo ainda na primeira versão.
Se você já trabalhou com tiles, sabe como isso funciona.
Talvez daria até para prever a colisão com os tanques no terreno.

Só ainda não estou muito certo sobre a possibilidade de utilizar outro canal para os decalques (como estradas), pois ainda não olhei nisto.

Ainda sobraria um canal, da textura.

Estive olhando a possibilidade de deformar o terreno em tempo real, como quando um tiro atingir o chão e ele "desce". Embora possível, me pareceu meio lento, mas vou ver se dá pra melhorar a velocidade disso. Mas isso acabaria ficando para a lista de coisas a fazer depois que quase tudo está pronto...

Acho legal a idéia de discutir tudo aqui, talvez alguém mais apareça com algumas idéias tangíveis.

dracodomain escreveu:
Level design:
    Pensando bem, também me agrada muito a idéia de gerarmos procedimentalmente o cenário, itens e posições de partida. É realmente mais simples de se implementar, sem dúvida. Isto lembra o game Worms e derivados, que o cenário é gerado no momento da partida. Podemos usar a chave do randomizador para utilizar o mesmo cenário em alguns casos (rede, game salvo ou coisas do gênero). E o bom é que você já tem adiantado muita coisa neste sentido. Só me ocorreu o seguinte: o game, no primeiro estágio conforme previu, seria divertido o suficiente em fun-factor, desafio, gameplay em geral, contendo apenas um mapa aberto randomicamente? Não vejo muitos problemas em fazermos o primeiro game bem simples, mas que a essência do gameplay esteja nele. De repente pode ser interessante produzirmos o cenário de forma randômica porém com conteúdo inteligente, analisando alguns aspectos de gameplay e posicionando itens e objetos de forma coerente pelo cenário gerado.


Delphi utiliza uma função (Random), que é pseudo-randômica. Ideal para isto, pois, se utilizarmos ela (já estou usando no gerador de mapas) para gerar todo o cenário, como o mapa, e posição dos objetos, basta salvar um número inteiro de 32 bits. Nada mau, considerando que nos primeiros testes eu estava utilizando mapas .HTF, com tamanhos de 1 até 5 MB, sem textura...

Se possível a implementação do pathfinding já nesta versão, como eu imagino que seja possível, o mapa não será mais "vazio", embora seja ainda aberto. Haveriam diversos objetos nele, sendo o fator limitante, a quantidade de objetos que a engine suportaria sem muito impacto na fluidez do jogo.

Imagino até, que seja possível implementar mapas mais "cerrados", através da utilização de obstáculos no cenário, o que poderia, talvez, tornar viável a idéia do modo de jogo mais tático.

Ainda assim, não seriam cenários fechados como em Assault Rigs, ou Quake. Ainda existiria espaços vazios, mas não tão grandes. Poderia ser possível até diminuir o tamanho do mapa para isso (atualmente os mapas são de 512x512, realmente grandes, pela escala do jogo.
Seria relativamente fácil gerar cenários maiores ou menores, com pequenos ajustes nas funções atuais.

Acho que dá até pra usar o meu gerador de labirintos (http://www.gamedev.com.br/forum/viewtopic.php?t=184) e ligar com o mapa.
Mas pra isso ainda precisa de mais testes...

dracodomain escreveu:
Multiplayer:
    A rede pode ser um desafio para nós, pois requer estruturalmente já implementada a conversação entre os módulos. Alguns engines, como o Cipher por exemplo, já trazem o servidor e o cliente em contato com o game, independente se for single player ou multiplayer. Também concordo contigo sobre a I.A. dos bots não ser complexa, e de repente até necessária independentemente desta questão, mas uma vez que estaremos programando um game com todos os aspectos de um multiplayer (time versus time na maioria dos casos), por que não prepará-lo para tal? Minha preocupação, novamente, é com a diversão do game. Até compreendo sua preocupação em ver uma versão do projeto pronta, mas é preciso estudar o quanto ela terá utilidade para a versão final - para o público, a expectativa de um game diferente pode não agradar; e para nós, refazer todo o código para suportar o multiplayer pode ser pior que começar a fazê-lo já pensando nisto. Eu também costumo pensar assim, "façamos o básico do básico antes e vejamos isto funcionando", mas é importante balancear o planejamento com as etapas, pois num game de FPS em primeira instância (em resumo ele é um), sem história ou missão, um single player pode não agradar aos jogadores (não se esqueça que eles são espertos, logo descobrem como funciona a I.A.). Entende meu ponto de vista? Aí te pergunto: jogar sozinho contra o computador um game de competição pode ser suficiente, tecnicamente e conceitualmente, para a primeira versão? :0/


Eu realmente não sei se seria suficiente somente o single player...
Seria bem mais interessante, mas como eu disse, nunca programei tal tipo de jogo, não imagino as complicações que poderiam surgir por causa do multiplayer, como threading, tratamento de lag, e coisas deste tipo.
Você tem experiência em jogos multiplayer?

dracodomain escreveu:
Ainda estou em dúvida sobre qual o diferencial nosso em relação à movimentação do tanque, uma vez que temos certa liberdade no tema futurista e também por juntar um game frenético a um de simulação de tanques. Você pensa em balística, o qual se aponta para uma direção e o projétil faz a curva no ar? Tenho algumas idéias a agregar sobre isto, podemos discutí-las depois com calma.


Penso em não tornar ele realista demais. Apenas utilizar a física para que o jogador corrija a trajetória do projétil na base do "achismo" (quanto mais longe, mais alto teria que mirar), simplesmente para que não seja fácil demais acertar um "headshot" num tanque do outro lado do mapa. Somente para aumentar (um pouco) a dificuldade.

Quanto à movimentação, ainda não pensei nisso.

Estou refazendo todo o código, ainda pensando se o jogador poderia controlar outras unidades (como por exemplo, alternar entre um tanque e um hovercraft). Neste caso, os controles seriam diferentes, mas ainda não cheguei nesta parte.

dracodomain escreveu:
Bom, fiquei martelando e pensei: entre nascer um código com estrutura diferente para aceitar a rede e um gameplay que em princípio funciona melhor com vários jogadores, talvez a alternativa seja mudar o estilo do game para se adequar melhor ao single player, mantendo gameplay e identidade previstos. Calma, não vamos mudar tudo, mas talvez possamos seguir um caminho diferente. Para te passar um pouco do que imaginei, tente esquecer por um momento o estilo do game atual e imagine um game com o perfil de "arcade", simples, frenético e vicioso, trazendo como principal objetivo do jogador um destaque entre outros jogadores. O destaque pode ser qualquer coisa, como o alcance de um nível (os cenários seriam "rounds" com puzzles e/ou ondas de inimigos para resistir - ainda podemos manter muita coisa do que temos), uma pontuação (baseada em quantidade e formas inteligentes de derrotar os inimigos, por exemplo), ou até mesmo modos de game como "resistir tanto tempo vivo", ou "fazer 1 milhão de pontos", coisas que um game "arcade" teria. Em vez de lutarmos contra inimigos de mesmo nível ou em times, poderíamos enfrentar inimigos em grande quantidade, lembrando algo que você previu no modo 3 de game, mais tático, que mencionou lá atrás. Ou ainda, você poder "ordenar" os bots do seu time, assim o jogador poderia se sobressair num dos destaques por usar a melhor estratégia. Existem sempre muitas possibilidades. Mas a idéia é pensar como um game "arcade".


A idéia de "resistir tanto tempo vivo" parece bem legal... ainda mais se você analisar jogos como Crimsonland, Evil Invasion, e Alien Shooter, que acabaram sendo consagrados exatamente por causa deste tipo de gameplay.
Não vejo problema nenhum com isto.

Dá uma conferida em Alien Shooter 2:

http://www.sigma-team.net/alienshooter_ ... s2demo.exe

O modo de jogo "Survival" é a melhor parte:
Para cada morte, aumenta a quantidade de pontos. Vence quem se manter por mais tempo vivo.
Existem diversos power-ups para auxiliar o jogador.

É mais um daqueles momentos "porque não pensei nisso antes?".

_________________
The best performance improvement is the transition from the nonworking state to the working state.
~J. Osterhout


Voltar ao topo
 Perfil  
 
 Título:
MensagemEnviado: Sex Out 27, 2006 3:33 am 
Offline
Membro júnior
Avatar do usuário

Registrado em: Ter Ago 08, 2006 5:52 pm
Mensagens: 49
Localização: São Bernardo do Campo - SP - Brasil
É isto mesmo, estamos começando a nos sintonizar. :0)

Analisando estes dias o MMOG Guild Wars, cheguei à conclusão que devem utilizar path finding 2D também. Apesar do game ser em 3D, os jogadores não podem pular e estão constantemente correndo atrás uns dos outros, selecionando o alvo durante a batalha. Sendo assim, isto facilitaria o tráfego de dados da posição dos clientes pela rede, uma vez que as coordenadas seriam em 2D. Enfim, uma idéia que serviria para o nosso propósito, bastava eu ter percebido antes realmente.

Sobre a solução que adotou com a textura de 32 bits, achei muito, muito interessante. Aproveitando os canais para não desperdiçar processamento em conversões de formato, sobraram três canais livres. O que é mais engraçado é que me ocorreu parte disto também, principalmente sobre a elevação do terreno para acomodar um prédio ou itens dispostos no cenário. Temos então "canais de dados" para o cenário, sendo: 1) heighmap gerado e pós-manipulado (para acomodar estruturas 3D externas sobre o nível gerado, além de possivelmente suportar deformação do terreno em real-time caso necessário*), 2) informação estática (256 tipos de informação relativas ao cenário ou 8 tipos combinados, entre eles sólido, deslizante, spawn-point, itens etc.) que pode ser útil para path finding, colisão contra o cenário etc., 3) informação dinâmica (256 tipos ou 8 para combinar também relativas ao cenário**, como decals) e 4) camadas de textura do terreno***.

* Deformação de terreno em real-time é uma idéia que me agrada em termos de tecnologia, mas é preciso ser bem estudada pois ela causa grandes mudanças ao gameplay. Vamos levá-la em consideração como um tipo de game, por enquanto. Se funcionar bem, poderemos adotá-la aos demais tipos, caso não, será um tipo de game que acabará indo para o "deleted scenes" do projeto. :0)

** Eu acho que colisão entre unidades feitas utilizando a textura podem ser imprecisas, assim como qualquer outro armazenamento e cálculo que envolva as unidades ou objetos que se movam e se posicionam com maior resolução. A menos que sejam do cenário, onde as posições seriam fixas, ou até móveis, mas com uma mobilidade interpolada com os pontos na resolução do terreno também.

*** Não sei exatamente como está fazendo com a texturização do terreno, mas é sempre possível utilizar a cor dos vértices do mesmo para calcular o alpha responsável pela transição das múltiplas texturas (tileable, com mapeamento planar relativo ao terreno). Uma vez que sobra um canal, talvez pudéssemos utilizá-lo para definir quais texturas seriam utilizadas no terreno à partir de um conjunto pré-definido delas para o cenário em questão.

Minha experiência quanto a programação de games multiplayer é basicamente teórica. Já programei em games multiplayer, mas não projetei nenhum do zero ainda. Na Eleven Cells, onde trabalho, estamos num projeto há quase 2 anos e que trata-se de um game 3D on-line. Apesar de não ter tido a oportunidade de me envolver com a programação da rede junto aos demais programadores (por estar focado em outras áreas), tenho acompanhado de perto boa parte do processo e já estudei muita coisa a respeito fora do ambiente de trabalho. Mesmo assim, meu conhecimento prático em games on-line com estrutura "decente" passa longe de alguns indivíduos da empresa. Sorte eles estarem por perto. :0)

Independente disto, eu consideraria a importância de tentarmos fechar o conceito do game para que possamos nos planejar melhor. Se, entre nós, há uma certa deficiência técnica para a rede, por mais que saibamos (por minha ou por tua parte) quais seriam os desafios e problemas relacionados, eu aconselharia tentarmos facilitar as coisas e estudarmos aquela solução, de focarmos num game com estilo mais "arcade" para nos aproximarmos mais do single player. O que acha?

A propósito, a idéia do "resistir tanto tempo vivo" veio do game Geometry Wars: Retro Evolved do Xbox 360. O game é simples e genial, e este conceito é bem aceito, como você mesmo havia dito.

Ainda não fiz o download, mas conferi as screenshots do Alien Shooter 2... Cara, muito boas! Não sabia da existência dele, fiquei curioso. Na E3 vi e joguei um game para o Xbox 360 que lembra muito este em estilo e visual, só que era para dois jogadores... Mas não consigo lembrar ou encontrar o nome dele. :0/

Bom, tive uma idéia simples. Podemos listar detalhadamente os "features" do game, separados em conceito e tecnologia inicialmente, e irmos discutindo, alterando, tirando e acrescentando as questões até firmarmos a primeira versão do game. Pode até sofrer alterações posteriores, já que alguns itens, principalmente de conceito, só serão testados após terem sido implementados. Gosta da idéia? Vou preparar algo para o próximo post. :0)

[]'s

_________________
Rodolfo Calabrezi

Software Engineering
Business Development


http://cruelbyte.com
skype, twitter, facebook: rcalabrezi
linkedin: http://www.linkedin.com/in/rcalabrezi


Voltar ao topo
 Perfil  
 
 Título:
MensagemEnviado: Seg Out 30, 2006 8:24 pm 
Offline
Membro avançado
Avatar do usuário

Registrado em: Qui Jan 12, 2006 7:30 pm
Mensagens: 434
Localização: irc.voidzero.com - #gamedev
Sobre a utilização de vertex coloring no terreno, não acho que seja possível, pelo modo que GLScene trata o terreno. Mas, como eu disse, não tenho certeza disso.

Então, sobre as características, ficariam:

Single-player;
Arcade, mas com um mínimo de física para a balística;
Bots;
FPS + RTS (RTS somente em um modo de jogo);
Jogador controla somente um tanque (no princípio, só haveriam tanques);
Níveis abertos, variando em tamanho de 128x128 até 512x512, de acordo com o modo de jogo;
Níveis incluiriam obstáculos, possivelmente, talvez, até labirintos;

Quais seriam as prioridades de programação dos modos de jogo?
Imagino que seriam nesta ordem:
1) Mata-mata (killfest)
2) Sobrevivência
3) CTF
4) Todos contra um
5) Onslaught + RTS


Acho que é isso. Qualquer coisa, só dizer.
Tenho ainda que re-ler todo o tópico pra me lembrar do que foi dito, e acrescentar na lista.

[Edit] Só agora percebi que o modo "Sobrevivência" seria um tanto quanto parecido como o "Todos contra um", exceto pela necessidade de tornar o combate do "Todos contra um" bem mais tático que o "Sobrevivência", que seria muito mais "trigger happy".

_________________
The best performance improvement is the transition from the nonworking state to the working state.
~J. Osterhout


Voltar ao topo
 Perfil  
 
 Título:
MensagemEnviado: Dom Nov 05, 2006 4:18 pm 
Offline
Membro avançado
Avatar do usuário

Registrado em: Qui Jan 12, 2006 7:30 pm
Mensagens: 434
Localização: irc.voidzero.com - #gamedev
E neste fim de semana:
Utilização de objetos Proxy, que atuam como referência dos modelos, evitando entupir a memória carregando diversas vezes o mesmo mesh.

E também o primeiro teste de colisão, entre os tanques.
Só existe uma pequena observação:
Coisas estranhas começam a acontecer quando se coloca cerca de 40 tanques em um espaço onde só cabem 20... :twisted:

Ainda falta integrar estes testes dentro do programa principal, mas isso vai demorar um pouquinho...

[img]http://www.gamedev.com.br/images/gallery/345/Colisão.JPG[/img]

_________________
The best performance improvement is the transition from the nonworking state to the working state.
~J. Osterhout


Voltar ao topo
 Perfil  
 
 Título:
MensagemEnviado: Ter Nov 07, 2006 2:28 pm 
Offline
Membro avançado
Avatar do usuário

Registrado em: Sáb Jun 24, 2006 7:42 pm
Mensagens: 400
Que coisas estranhas???


Voltar ao topo
 Perfil  
 
 Título:
MensagemEnviado: Seg Nov 13, 2006 4:00 am 
Offline
Membro júnior
Avatar do usuário

Registrado em: Ter Ago 08, 2006 5:52 pm
Mensagens: 49
Localização: São Bernardo do Campo - SP - Brasil
Perdão pela ausência nestes dias.

Estive sem cabeça para pensar em algo técnico, acabei usando o outro hemisfério do cérebro para tentar fazer algo produtivo. Como resultado, modelei um tanque no Modo para testar algumas coisas e discutirmos mais sobre o conceito visual do game. :0)

Imagem
Mais detalhes sobre a imagem

Antes de chegar num design futurista, arrisquei algo mais tradicional. Não sei se vai ficar legal isto no engine, só testando. Assim que for possível, te passo os arquivos para vermos a compatibilidade e os ajustes necessários para que possa modelar outros tanques.

Note na imagem que tomei a liberdade de pensar num logotipo para o projeto. :0)

Bom, tenho que voltar às nossas discussões conceituais e listas de prioridades. Mas antes, gostaria de saber a compatibilidade do projeto com outros IDEs como o Lazarus. Ainda não tenho o Delphi por aqui. :0(

[]'s

_________________
Rodolfo Calabrezi

Software Engineering
Business Development


http://cruelbyte.com
skype, twitter, facebook: rcalabrezi
linkedin: http://www.linkedin.com/in/rcalabrezi


Voltar ao topo
 Perfil  
 
 Título:
MensagemEnviado: Seg Nov 13, 2006 1:42 pm 
Offline
Membro avançado
Avatar do usuário

Registrado em: Sáb Jun 24, 2006 7:42 pm
Mensagens: 400
Ficou do c**** :P

Curti o logo... E curti a textura tb...

A propósito, achei um jogo chamado TASpring, nele os disparos de tanques deformam o chão, e eu achei super-divertido, consegui ficar 2 horas seguidas apenas furando o chão... Nos mais variados formatos... Tem até gente criativa que desenha no chão, e no meu caso, eu tive a paciencia dps de ficar 3 horas seguidas atirando até eu conseguir nivelar perfeitamente uma montanha...

A propósito, o mapa, além do bitmap de heightmap, tb tem o bitmap de hardness map, assim por ex um piso de areia afunda mais que um de pedra :P


Voltar ao topo
 Perfil  
 
 Título:
MensagemEnviado: Qui Nov 16, 2006 7:38 pm 
Offline
Membro avançado
Avatar do usuário

Registrado em: Qui Jan 12, 2006 7:30 pm
Mensagens: 434
Localização: irc.voidzero.com - #gamedev
Speeder escreveu:
Que coisas estranhas???


Se você olhar no screenshot da colisão de tanques, existe um tanque que "afundou", que é o resultado de quando você "empilha" os tanques.

Se criar os tanques em distâncias maiores, onde eles não se empilhem, isso não acontece. :P

Speeder escreveu:
A propósito, achei um jogo chamado TASpring, nele os disparos de tanques deformam o chão, e eu achei super-divertido, consegui ficar 2 horas seguidas apenas furando o chão... Nos mais variados formatos... Tem até gente criativa que desenha no chão, e no meu caso, eu tive a paciencia dps de ficar 3 horas seguidas atirando até eu conseguir nivelar perfeitamente uma montanha...

A propósito, o mapa, além do bitmap de heightmap, tb tem o bitmap de hardness map, assim por ex um piso de areia afunda mais que um de pedra :P


Pois é... também gostaria de terreno deformável. Vamos fazer o possível pra ter ele no jogo, mas, se não conseguir melhorar a perda de performance que ele causa, sem chance... :(

A idéia do hardness map é boa, andei pensando agora, e acho que dá, sim pra implementar isso. Essa é uma que vai pra lista de coisas a serem feitas. Acho que daria até pra modificar a velocidade conforme o terreno que o tanque está.

Mas ainda é cedo pra isso.

dracodomain escreveu:
Antes de chegar num design futurista, arrisquei algo mais tradicional. Não sei se vai ficar legal isto no engine, só testando. Assim que for possível, te passo os arquivos para vermos a compatibilidade e os ajustes necessários para que possa modelar outros tanques.


O concept ficou arrasador :lol: O modelo e texturas, também.

Acredito que ainda não há muita necessidade de modelagem de diversos tanques (por enquanto, claro), pois acredito que, mesmo com um só tanque, já dá pra mudar a textura, e fingir que são os inimigos 8)

O mais importante, ainda, é definir os conceitos, pra termos uma idéia do que vai ser feito.

dracodomain escreveu:
Note na imagem que tomei a liberdade de pensar num logotipo para o projeto. :0)


Boa, eu nem tinha me tocado disso...

dracodomain escreveu:
Bom, tenho que voltar às nossas discussões conceituais e listas de prioridades. Mas antes, gostaria de saber a compatibilidade do projeto com outros IDEs como o Lazarus. Ainda não tenho o Delphi por aqui. :0(


Sobre os conceitos, acredito que neste fim de semana vou preparar alguma coisa pra que nós possamos nos fixar em algo mais concreto.
Ainda devo este post detalhando os conceitos, e algumas coisas que você citou, que ainda não pensei direito, mas que me soam muito bem, como possibilidade de modding (o que poderia aumentar a vida útil do jogo), e multiplayer.

Sobre compatibilidade, me lembrei de portabilidade...

Embora, pelo que eu saiba, o pacote GLScene é 100% compatível com o Lazarus, eu nunca instalei o GLScene nele, nem ao menos tenho o Lazarus, e não faço idéia da compatibilidade entre Delphi <-> Lazarus, sem falar no meu código, uma vez que sempre programei para Windows, o que, poderia, no futuro, dificultar a portabilidade do jogo (se é que vamos arriscar isso, pois só uso Windows).

Experimenta baixar direto do CVS do GLScene e tenta instalar no Lazarus, se não der, dá uma olhada em:
http://www.skinhat.com/lazarus

Ainda, você pode achar uma cópia do Delphi (versões entre 5 e 7), Personal, e instalar o GLScene nele. (Não acho que seja uma boa idéia baixar o Turbo Delphi, porque, parece que eles não deixam instalar componentes de terceiros nas versões free, mas existem métodos para circundar essa limitação).

Por fim.... vamos aos updates! :lol:

Como eu não estava satisfeito com o visual do terreno, decidi tentar melhorar ele um pouco, e foi feito o seguinte:

1) Mixagem das texturas para a geração da textura do terreno foi refeita, permitindo que sejam geradas texturas maiores que o terreno. Por exemplo, antes, o tamanho da textura do terreno era igual ao tamanho do terreno, resultando que um terreno de 128x128 possuiria uma textura de 128x128.
Agora, é possível gerar texturas de 1024x1024 para qualquer tamanho de terreno, melhorando (um pouco) o visual. Não que 1024x1024 seja o último tamanho, é possível gerar texturas para o terreno de 2048x2048, 4096x4096, mas o problema é o tempo que se leva para gerar elas.
O tempo de geração de um terreno, utilizando o algoritmo que simula fluidos, para um mapa de 512x512, gerando uma textura de 1024x1024, é de aproximadamente 8 segundos (para criar o terreno) e 2 segundos (para gerar o texture map), em um PC de 1GHz. ** Não incluindo shadowmap **.

2) Baseado no livro Game Programming Gems I, nos três artigos de Jason Shankel, implementei três novos algoritmos para geração de terreno: Midpoint Displacement, Particle Deposition, e Fault Formation.

O único problema, é que nenhum destes três algoritmos geram terrenos suaves o suficiente para serem utilizados no jogo...

Por isso, estarei pesquisando sobre Gaussian Blur, para tentar suavizar o terreno, para poder utilizar estes algoritmos. Se não funcionar, vamos ter que nos contentar com somente um gerador de terreno :(

3) Geração de lightmap (ou shadowmap) via raytracing.
Essa eu gostei :P
Agora, depois de gerado o terreno, dá pra gerar um lightmap, produzindo sombras no terreno.

Ainda não "liguei" o texture map com o lightmap, porque pretendo finalizar todo este processo de geração de terrenos antes disso, mas, só botei o lightmap como textura normal sobre o terreno, e mandei pra um outro demo que é utilizado como testbed.
Tirei uns screenshots disso, e mandei pra galeria:
http://www.gamedev.com.br/gallery/view.php?id=400

Também aumentei a escala do tanque (deixando a câmera mais longe do terreno), pra melhorar o visual do terreno.

Não medi o tempo que demora o raytracer, mas, deve demorar entre 10 e 15 segundos para criar o lightmap de um terreno de 512x512.
O lightmap continua no mesmo tamanho do terreno, para economizar tempo.

Depois que terminar de implementar o Gaussian Blur, colocar os três novos algoritmos para gerar terreno, e mais o criador de lightmaps dentro da classe do terreno, vou ver se o visual do terreno vai me satisfazer, senão, vamos ter que ver o que pode ser melhorado (sim, já pensei em grama e árvores, mas, só mais tarde).


Ah, sim, só confirmando, que acredito que neste fim de semana, eu coloque mais algumas idéias sobre o conceito, e talvez, a lista de prioridades (nunca me dou muito bem com esta lista...)

_________________
The best performance improvement is the transition from the nonworking state to the working state.
~J. Osterhout


Voltar ao topo
 Perfil  
 
 Título:
MensagemEnviado: Dom Nov 19, 2006 6:49 pm 
Offline
Membro avançado
Avatar do usuário

Registrado em: Qui Jan 12, 2006 7:30 pm
Mensagens: 434
Localização: irc.voidzero.com - #gamedev
Bom, pode-se dizer que este é o game design document do jogo, versão 0.1, aberto a críticas e sugestões.

Nem tudo que está aqui significa que deverá estar implementado, e nem tudo que será implementado estará escrito aqui =P

Tank Commander é um jogo tematicamente futurista, no estilo shooter, onde o jogador é colocado como comandante de um tanque de guerra, em meio à diversas batalhas.
Com visão em 3ª pessoa, o objetivo principal é se manter vivo e ser capaz de destruir o maior número de inimigos, para completar a missão (que, curiosamente, consiste em matar os inimigos!)
O jogador poderá (ou não, dependendo da missão) ser ajudado por tropas amigas durante as batalhas, controladas pela IA.

Inicialmente, seria apenas single player.
A questão de multiplayer, ainda, permanece em aberto, possibilitando a implantação.

Quais seriam as dicas para a implementação?

Embora existam somente tanques, já seria programado desde o princípio, de modo que seja possível, em uma futura expansão, adicionar mais unidades, e permitir que o jogador assuma o controle de outras unidades amigas.
A única excessão seria permitir o controle de aeronaves, em princípio.
Ainda falando sobre unidades-que-viriam-a-ser-implantadas-caso-haja-a-tal-expansão, poderiam ser adicionadas torres, estáticas, para aumentar a tática de jogo, em alguns modos de jogo.

Sobre o gameplay, iria variar de acordo com o modo de jogo escolhido, embora, o que pode ser definido para todos eles é o seguinte:
1) Dois modos de controle, que podem ser escolhidos pelo jogador, que são aquele já implementado atualmente, e aquele "Quake-like", onde as teclas A e D não fariam rotação, mas sim, seriam utilizadas para strafe.
2) Combates rápidos, onde pode se abater (ou morrer) com pouca quantidade de tiros.
3) Física "básica" para a balística e unidades (como gravidade, aceleração, etc).
4) Cenários out-door, gerados proceduralmente, com inclusão de obstáculos (ou prédios) que podem (ou não) influenciar diretamente no jogo, dependendo do modo de jogo escolhido.

Sobre os modos de jogo:
A sua idéia sobre tornar o jogo mais Arcade será aplicada diretamente nesta parte.

Modos arcade, onde o jogador controla uma unidade com maior resistência, e maior poder de fogo do que os inimigos:
1) Sobrevivência: O jogador enfrentaria onda após onda de inimigos, cuja dificuldade varia de modo crescente, conforme a onda.
2) Defender instalação: Onde o alvo dos inimigos não seria o jogador, mas a instalação a ser destruída. Seria similar aos jogos do tipo "Tower Defense", onde, na existência de uma expansão, seriam utilizadas torres estacionárias para auxiliar o jogador.

Nestes modos de jogo, haveriam power-ups, podendo variar de quad-damage, até uma outra unidade amiga.



Os outros, listados a seguir, não incluiriam power-ups, e fariam com que o jogador controlasse uma unidade com o mesmo poder de fogo/vida que os inimigos, bem como as outras unidades de seu time:
1) Captura a bandeira.
Um mapa aberto. Dois times. Cada time com um determinado número de unidades (do mesmo tipo). O modo convencional.

2) Mata-mata: Dois times, com o mesmo número de unidades, que fazem spawn nos dois cantos do mapa. Ao morrer, o bot (ou jogador) é novamente "spawnado" no spawn point.
Depois de um tempo, pré-determinado, conta-se a quantidade de kills de cada lado, quem faz o número maior, ganha.

3) Neste tipo de jogo, entraria o RTS. Como você mesmo referenciou, o modo Onslaught de UT. Com uma pequena diferença:
Em uma mapa aberto (provavelmente grande), existiriam alguns pontos para serem capturados. Em cada ponto a ser capturado, existe um tipo de instalação (nada mais que um modelo 3D de um prédio), que, ao ser capturado, faz com que novos tipos de unidades sejam "spawnados" no mapa.
Por exemplo, ambos os times começam controlando tanques, em um número fixo (digamos 10). Como só existe um spawn point, os 10 tanques saem do mesmo lugar.
Após um determinado tempo, o time Azul captura um outro spawn point, com a estrutura que permite a utilização de Mechs.
Agora, Além dos 10 tanques serem "spawnados" entre os dois spawn-points, 4 mechs são "spawnados" nos dois spawn-points.
Digamos que o time Vermelho capture um outro spawn point, que libere 6 gunships.
Então, além dos 10 tanques "spawnados" nos dois spawn-points, 3 gunships aparecem em cada spawn point.
Quando uma instalação Azul não possuir nenhum do seu time em um raio X, e um veículo Vermelho se aproximar dela, ela passa a pertencer ao time Vermelho.


Nestes modos de jogo, ainda poderia ser possível permitir ao jogador escolher as variáveis que determinam as condições de vitória, como tempo de jogo, número de mortes.
Ainda, poderia ser possível permitir a escolha da quantidade de unidades no mapa.

Código:
[O modo de jogo a seguir, ficaria em aberto, e completamente pendente, pois não seria possível implementá-lo atualmente]

4) Todos contra um. Repare, que até agora, não se falou em power-ups, pois eles não existiriam, exceto neste aqui.
Funcionaria assim: O jogador estará sozinho, e terá que enfrentar um determinado número de inimigos. Neste tipo de jogo, não é spawn point. Se o jogador morrer uma vez, game over.
Para ajudar o jogador a terminar este tipo de jogo, haveriam power-ups (algo do tipo quad damage, mísseis, +100% armor, etc).
Exceto pelo power-up de vida, que, estaria somente disponível, ao se matar um inimigo (ou seja: cada inimigo morto "dropa" um health power-up).
De todos os jogos, este seria o mais tático, pois ele teria que enfrentar diversos inimigos, sozinho, e não poderia usar táticas "hit & run", pois não existem power-ups para a vida. No entanto, para que este tipo de jogo seja viável, são necessários cenários mais complexos, que permitam ao jogador tomar vantagem de diversos obstáculos.
Este tipo de jogo só estaria disponível na segunda versão de Tank Commander.



Sobre os tipos de mapas, seriam abertos, variando em tamanho de 128x128 até 512x512, de acordo com o modo de jogo;
Níveis incluiriam obstáculos, possivelmente, talvez, até labirintos;


Ainda falta discutir sobre as armas.
Alguns modos de jogo (Sobrevivência e Defender Instalação) iriam requerer diversos tipos de armas, enquanto que os outros, não.

Me ocorreu da possibilidade de se customizar a unidade, antes de entrar em combate, para montar as armas.
Mas, isso implicaria em não permitir que o jogador pudesse trocar de controle de unidades, a menos que a configuração escolhida por ele seja distribuída para todas as unidades do mesmo tipo.

Sobre as unidades:
Cada tanque possui aceleração e velocidade, o que modifica a sua movimentação pelo mapa, além da vida e tipo de arma que possui.


Sobre MODs:
Quais seriam as necessidades?
Permitir adicionar modelos, e reconfigurar as armas?
Uma vez que não seria muito provável permitir a inclusão de custom-made maps.

Em princípio, é isto.

A (minha) lista de prioridades (atuais :P ), que pode não condizer com a versão final dela:

Terreno:
Inclusão dos três novos algoritmos de geração de terreno na classe Terreno;
Inclusão do raytracer na classe Terreno;
Inclusão de Gaussian Blur na classe Terreno;
Colocação de prédios, spawn-points e demais objetos;

Câmera:
Refactoring da classe Câmera: Será adicionada a interpolação, além da possibilidade de ser acoplada a qualquer objeto móvel;
Inclusão de configuração para a sensibilidade do mouse (para controle da câmera);
Zoom via mousewheel;
Zoom para tiros de longa distância;
Shake;

Teclado:
Inclusão de configuração de teclas;

Tanque:
Refactoring total; :(
Inclusão de colisão Tanque/Tanque na classe;
Inclusão de colisão Tanque/Prédios (não tem nada feito disso);
Inclusão de colisão Tiros/Tanques (não tem nada feito disso);

Tiros:
Tudo :(


Todo o resto que não me lembro agora, incluindo:
Sons
Menu (que já está feito, mas é feio que chega a doer)
Intro (que já está feita, e consiste em um cubo girando)
Skybox estática;

Ultimas-coisas-que-serão-feitas:
Pós produção, incluindo:
Chuva
Lens flare;
Sol;
Fumaça (tiros, explosões)
Rastros do tanque (tanto via decalque no terreno, como fumaça);
Nuvens animadas;
Grama, árvores;
Terreno deformável;
Hardness map (afundando o tanque, e influenciando velocidade)

_________________
The best performance improvement is the transition from the nonworking state to the working state.
~J. Osterhout


Voltar ao topo
 Perfil  
 
 Título:
MensagemEnviado: Dom Dez 10, 2006 3:14 pm 
Offline
Membro avançado
Avatar do usuário

Registrado em: Qui Jan 12, 2006 7:30 pm
Mensagens: 434
Localização: irc.voidzero.com - #gamedev
Uma pequena atualização:

Uma screenshot mostrando um Texture Map de 2048x2048, combinado com o Lightmap (gerado via raytracing), e com um Detail map, em um terreno de 512x512, gerado via simulação de fluidos.

Estou ainda trabalhando nos outros métodos de geração de terreno, que falta só fazer o blur no terreno gerado para suavizar ele, e estou trabalhando no novo sistema de câmera.

Screenshot:
Imagem

_________________
The best performance improvement is the transition from the nonworking state to the working state.
~J. Osterhout


Voltar ao topo
 Perfil  
 
Exibir mensagens anteriores:  Ordenar por  
Criar novo tópico Responder  [ 55 mensagens ]  Ir para página Anterior  1, 2, 3, 4  Próximo

Todos os horários são GMT - 3 horas


Quem está online

Usuários navegando neste fórum: Google [Bot] e 1 visitante


Enviar mensagens: Proibido
Responder mensagens: Proibido
Editar mensagens: Proibido
Excluir mensagens: Proibido
Enviar anexos: Proibido

Ir para:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Traduzido por: Suporte phpBB