Ponto V!

Home Arquitetura Dissecando os games Dissecando o game: Duke Nukem 3d
Bruno Crivelari Sanches
Dissecando o game: Duke Nukem 3dImprimir
Escrito por Bruno Crivelari Sanches

Hoje vamos conhecer um pouco mais a fundo o jogo Duke Nukem 3d, que foi lançado no inicio de 1996 e apesar da idade, possui muitos itens modernos que só veríamos novamente anos depois. O jogo chama atenção não só pelo seu gameplay que foi revolucionário para os FPSs da época, mas também pela sua tecnologia, sendo que em 1996, duke já possuia um editor WYSIWYG (“o que você ve é o que você tem”) que se compararmos com os editores da época, que mais pareciam um cad do que um editor de níveis, era fabuloso, só voltariamos a ver editores assim novamente com o CryEngine, mais tarde Unity e vários outros.

Duke Nukem 3d

A história do Duke Nukem é das mais simples: Duke (o protagonista) ao voltar para terra é atacado por alienigenas e logo descobre que eles estão invadindo a terra e sequestrando todas as mulheres, ele então parte numa saga por Los Angeles, bases espaciais e outros cenários para destruir os alienigenas e salvar as mulheres.

Os níveis do jogo eram bem revolucionários para época, tentando retratar cenários reais (ao invés de cenários mais fantasiosos como era comum) e coisas do cotidiano. O jogo é repleto de cenários nada convencionais, como um cinema porno, um clube de strip, estudios de cinema e etc. Além de coisas banais do cotidiano, como banheiros funcionais, que realmente chamavam a atenção e eram motivo para todo mundo ficar: “oooohhhh”.

Primeira fase do jogo, a esquerda entrada do cinema

Sem falar que o jogo, mesmo com todas as limitações da época trazia efeitos que até hoje é difícil ver por ai, como, por exemplo, explodindo uma bomba em uma sala, os vidros se quebram, incluindo lampadas, que resultavam em uma sala bem escura. Era uma época que você nunca viria um level designer usar uma cadeira de adamantium para bloquear um corredor, como é comum hoje em dia.

Para completar o jogo tinha dezenas de referências a cultura pop da época, principalmente filmes, sendo possível encontrar pelos cenários personagens de filmes como Indiana Jones, Aliens, Pulp Fiction e muitos outros.

Se não bastasse tudo isso, o jogo vinha com uma tecnologia revolucionária, com gráficos soberbos e ainda incluia um editor de níveis que qualquer criança (da época) aprendia usar rapidamente e são esses itens que iremos explorar nesse artigo.

Motor Build

O que tornou tudo isso possível foi o motor Build, que era um motor de jogo 2.5D, que é o termo usado para classificar jogos que não são realmente 3d. Isso quer dizer que o mundo de Duke era descrito em 2d, mas era mostrado em 3 dimensões. Isso era devido aos computadores da época não conseguirem desenhar gráficos 3d descentes (apesar que isso mudaria alguns meses após lançamento do duke com a chegada de Quake).

O motor foi todo escrito em C por Ken Silverman e seu primeiro projeto foi um clone de Wolfenstein3d, chamado inicialmente de “Walken” (Walk + Ken) e depois de Ken’s Labyrinth, este acabou sendo publicado pela Epic Megagames (para quem não sabe essa empresa mais tarde lançaria um tal de Unreal). Por ser um clone de Wolfenstein 3d, o motor suportava apenas cenários quadrados (era montado por cubos) e os cenários eram sempre planos. Após o lançamento do Ken’s Labyrinth Ken começou a tentar fazer um motor que tivesse suporte a paredes em qualquer ângulo, como no jogo Doom.

Começou então a surgir o motor Build, que tem suporte a muitas coisas que hoje são trivias, mas para época não eram tão simples, funcionalidades como permitir o jogador olhar para cima e para baixo não eram trivias com esse tipo de tecnologia. Outro grande avanço foi que o motor não utilizava árvores BSP, que eram a base da tecnologia de Doom e mais tarde seriam também a base de motores como Quake e Unreal. Árvores BSP são extremamente práticas para determinação de visibilidade, funcionam muito bem com cenas estáticas, mas tem grandes problemas com cenas dinâmicas e o resultado foi que o motor Build lidava muito bem com ambientes dinâmicos.

A facilidade do motor em lidar com cenas dinâmicas permitia aos designers criarem cenários destrutíveis, veículos, plataformas giratórias e uma gama de efeitos que até então, nunca tinham sido vistas em jogos desse tipo.

Outra grande novidade do motor era permitir que o jogador “mergulhasse” em ambientes alagados, para conseguir tal efeito, quando um designer fosse criar uma piscina, ele no editor construia então a parte de cima da piscina com uma textura de água e em outro local, era construída a parte de baixo (ou a parte “submarina”). Ligaria uma cena na outra e quando o jogador mergulhasse, o motor o teletransportava de uma cena para outra, criando o efeito de que estava dentro da piscina.

Muitas dessas funcionalidades, como da água, poderiam ter existido em outras tecnologias da época, mas vemos aqui como a criatividade de alguns desenvolvedores fazia toda a diferença em encontrar soluções relativamente simples, para fazer construções bem complexas.

No resto do artigo, pretendo focar em detalhes de como era criado o gameplay no motor Build, principalmente em técnicas que são validas até hoje e sem focar em técnicas que eram específicas para o motor devido as limitações da tecnologia e que hoje não são tão relevantes.

Hoje a versão completa do jogo pode ser adquirida em alguns sites especializados em jogos antigos, como o gog.com e os saudosistas podem jogar a versão original usando um emulador como o dosbox, aqueles que quiserem algo mais moderno, podem usar um port moderno (como o eduke3d) com pacotes de alta resolução e ter uma experiência mais interessante:

Usando um port moderno e pacote de alta resolução

Editor de Níveis

Como comentado anteriormente, o jogo já vinha com seu próprio editor de níveis e estavamos em uma época onde MODs eram essenciais para jogos e criavam um mercado paralelo. Com o editor de níveis do duke era possível modificar praticamente todo o jogo, criando uma nova história, inimigos, armas, etc. Era possível criar um jogo totalmente diferente também, com novo protagonista e novos inimigos. Sem falar que o editor também incluia ferramentas para desenho de texturas, permitindo assim que o jogo fosse inteiramente modificado apenas com suas próprias ferramentas, com exceção do som, que era o unico formato de media não editável diretamente pelo jogo.

Ao acessar o editor, o usuário se depara com uma tela em 2d, onde pode desenhar seu mapa. Bastava ir posicionando o cursor com o mouse e pressionando barra de espaço para ir colocando pontos pela tela, ao conectar três ou mais pontos, forma-se um polígono e pode-se então acessar o ambiente em 3d, para tal, bastava pressionar ENTER do teclado numérico. No ambiente 3d o usuário já era presenteado com uma interface WYSIWYG (sigla em inglês para o que você ve é o que você tem), no modo 3d era possível então ajustar tamanho de objetos, luminosidade e ajustar a altura de salas e chão, etc.

Visão 2d parcial da primeira fase

Acima temos a visão 2d da primeira fase do jogo (compare com as imagens do inicio do artigo), pode parecer complicado, mas basta usar o editor um pouco para ver com é intuitivo, sem falr que editar um cenário 2d é muito mais simples do que um cenário realmente 3d. Observa na imagem acima, do lado direito o layout da entrada do cinema. As linhas brancas são paredes sólidas, que vão do chão ao teto, as vermelhas são paredes que eram chamadas de não sólidas, pois permitiam que o jogador passase por elas. As linhas vermelhas poderiam apenas ser usadas para subdivir o ambiente, sem ter uma parede na prática, ou para construir uma “parede parcial”, que poderia ser vista por cima. Observe na figura que as linhas vermelhas formam o contorno da calçada da rua.

Os vários circulos coloridos são objetos do jogo ou na terminologia da época “sprites”. Eram usados para se posicionar inimigos, itens e também, para controlar o comportamento do ambiente, como marcar portas, botões, elevadores, etc.

Nessa época, os jogos faziam uma separação clara entre partes estáticas e dinâmicas do cenário. A parte estática no caso do Duke são as linhas do cenário acima, que formam a geometria basica do cenário. A parte dinâmica era uma mistura de linhas que poderiam se mover e os sprites.

Por exemplo, para se criar um cenário simples, com duas salas e um elevador entre elas, basta entrar no editor e criar um cenário com esse formato:

Um marilhoso exemplo de arte de programador: duas salas e um elevador

Para tal, basta ir posicionando o mouse nos pontos desejados e pressionar barra de espaços que os setores vão tomando forma. No final basta conectar os pontos do meio para gerar as linhas vermelhas, a operação toda pode ser feita com apenas alguns cliques do mouse. Observe que cada parte do cenário forma o que no jogo é chamado de setor, na figura acima temos 3 setores.

Pressionando-se ENTER do teclado númerico já nos deparamos com:

Preview do cenário

Trocando algumas texturas, mudando altura do chão e teto e rapidamente podemos construir algo já menos feio:

Cenário com alguns ajustes

E por fim, basta voltar ao modo 2d (pressionando ENTER do teclado numérico), posicionar o cursor do mouse sobre o setor que forma o elevador, pressionar a tecla T (de Tag) para colocarmos uma tag neste setor, digite 16, que é a tag que indica que este setor é um elevador que começa no alto:

duke6

Com este processo simples, já criamos um cenário funcional, com um elevador que sobe e desce, tudo isso em um unico editor, sem precisar ir em modelador 3d, exportar arquivos, importar, ajustar, etc.

Claro que o cenário é extremamente simplista se comparado com qualquer jogo moderno, mas um level designer experiente pode em algumas horas criar um nível totalmente funcional, desafiador e é claro, divertido. São poucas as ferramentas hoje que são tão simples de se usar como esta e que produzem resultados tão rapidamente.

Claro que nem tudo eram flores, por exemplo, usar números para descrever as propriedades e o que um objeto faz não é nada intuitivo, mas eram dificuldades da época, pois manipulação de strings eram sempre evitadas devido a seu custo computacional.

Observando novamente a imagem acima, note que o setor do elevador possui um outro número, no exemplo acima temos 0,16. O 16 é a Tag que indica que este setor é um elevador, o 0, era chamado de HiTag (ou Tag alta), era usada para conectar objetos. Exemplo: poderíamos criar uma botão e colocar nele o mesmo hitag do elevador, dessa forma, pressionano o botão, ele ativa o elevador. Ou seja, o hitag era usado para identificar um objeto do cenário e linkar objetos. Mais uma vez, usar números para essa tarefa não é algo tão prático quanto nomes, mas a simplicidade do editor acabava superando esses defeitos na maior parte do tempo…

Objetos de Jogo

Para implementar o jogo é claro que não poderiam faltar os objetos do jogo. Já vimos que os setores do mapa possuem tags, que podem ser a “lotag”, que é uma tag específica do jogo e indica o que o setor faz. E temos a hitag, que é definida pelo usuário e serve para identificar um determinado setor, ou seja, é usada como nome. Bom sabemos que podemos criar portas, elevadores, etc, apenas usando o próprio cenário, como vimos no exemplo acima, mas como criar outros objetos?

Para criar objetos, como monstros, botões, itens, etc, no jogo tinhamos os sprites, sim, é o mesmo que sprite em um jogo 2d, que é apenas uma figura com mascara. Lembre-se esse tipo de motor não era realmente 3d e para representar objetos eram usadas figuras 2d ou sprites. Para criar o efeito de 3d, como pode ser observado nos inimigos, eram gerados sprites a partir de seis ângulos diferentes, dessa forma, conforme o ângulo de visão e o ângulo do item, o motor escolhe o sprite mais apropriado. Na figura abaixo temos os sprites de um dos inimigos:

duke8

Mas apenas colocar itens no cenários não cria jogabilidade, ainda falta uma forma de se criar eventos e fazer com que os objetos comuniquem-se entre si. Por exemplo, pode ser desejável que um elevador seja ativado por um botão na parede, ao invés de ser ativado diretamente pelo jogador. Para se criar esse tipo de efeito, foram criados sprites especiais, que certa forma funcionam como componentes.

Por exemplo, um desses sprites é chamado de activator (ou ativador), que é um sprite que ativa ou invoca uma ação de um setor. Se colocarmos ele dentro de uma porta, ela ativa a ação desta, se for colocado em um elevador, ativa o elevador. Usando-se um ativador, podemos criar uma chave para ativar o elevador que criamos anteriormente, como podemos ver abaixo:

duke9

Na figura acima, a grande letra “A” é o sprite activator, do lado direito temos uma chave, que vai ser conectada ao activator. Foi adicionado também outro sprite especial, o speed, que pode ser usado para controlar a velocidade que as ações são executadas, nesse caso, ele afeta a velocidade que o elevador se move.

Para dizer ao jogo que a chave afeta o activator do elevador, devemos criar uma canal de comunicação entre eles, para tal, basta definirmos uma tag baixa idêntica para eles, no caso, utilizei o número 1, como podemos conferir na imagem abaixo:

duke10

Podemos observar na figura acima claramente o activator, com sua tag baixa de valor 1, a direita, em verde temos a chave, que também esta com a mesma tag baixa. Com este mecanismo simples, já podemos criar operações complexas no jogo.

Além destes, outros sprites especiais foram criados, alguns exemplos:

  • touchplate: é um gatilho ativado automaticamente quando o jogador entre no setor.
  • musicandfx: utilizado para tocar sons e música
  • locator: que é usado para definir rotas que veículos e alguns inimigos seguem
  • sectoreffector: certamente o mais famoso e mais usado, responsável por ativar uma infinidade de efeitos especiais, que no jogo original eram um total de 36 efeitos diferentes. Alguns exemplos: explosões, teletransporte, iluminação, etc.

Chega a ser impressionante como alguns poucos componentes tornaram possível a criação de efeitos bem complexos, ainda mais se considerarmos a época e os jogos equivalentes.

Scripts

Já temos uma noção razoável de como funciona o editor do jogo e de como criar mecanismos dentro do nível do jogo, mas como adicionar novos objetos? Para essa tarefa o jogo contava com um sistema de scripts próprio. Relativamente simples, mas permite adicionar novos objetos de maneira simples e rápida.

O principal item que pode ser criado com os scritps são os atores, que na terminologia do jogo são os objetos do jogo que tem “vida” ou executam ações, sendo a grande maioria os monstros do jogo. Um ator possui algumas propriedades:

  • action (ações): a mais simples de todas, define quais sprites representam o ator, a animação desta ação.
  • ai (IA ou inteligência artificial): define como o ator deve se comportar em um determinado momento. Para cada ator são definidos vários ai, com os parâmetros de nome, action, velocidade, função. A função é o tipo de rotina que o jogo vai executar, como perseguir o jogador, olhar para o jogador, fugir, etc.
  • state (estado): o nome aqui é um tanto contraditório, pois na verdade o estado funciona como uma função e não como um estado no sentido de uma maquina de estados ou como temos em Unreal Script

Com essas três funcionalidades simples foram criados todos os inimigos do jogo, alguns com comportamento e ações bens distintas. Abaixo temos um exemplo de script:

actor DRONE DRONESTRENGTH
  state checkdronenearplayer

  ifrnd 2
      fall
  else
      soundonce DRON_JETSND

  ifaction 0
    ai AIDRONEGETE
  else ifai AIDRONEGETE 
      state dronegetstate
  else ifai AIDRONEWAIT
  {
    ifactioncount 4
      ifrnd 16
        ifcansee
    {
      sound DRON_ATTACK1
      ifp phigher
        ai AIDRONEGETUP
      else ai AIDRONEGETE
    }
  }
  else ifai AIDRONEGETUP
      state dronegetstate
  else ifai AIDRONEPULLBACK
  {
    ifcount 32
    ai AIDRONEWAIT
  }
  else ifai AIDRONEHIT
  {
    ifcount 8
      ai AIDRONEWAIT
  }
  else ifai AIDRONESHRUNK
      state droneshrunkstate
  else ifai AIDRONEDODGE
      state dronedodgestate
  else ifai AIDRONEDODGEUP
      state dronedodgestate

  ifhitweapon
    state checkdronehitstate

  ifrnd 1
    soundonce DRON_ROAM

enda

Este é o script usado para controlar o Drone, que é um tipo de robo voador que ao avistar o jogador corre em direção a este e quando esta próximo o bastante, explode. No script acima temos a palavra chave “actor”, que é usada para definir um novo ator. No caso deste jogo, ator é todo objeto do jogo que executa alguma ação, na grande maioria dos casos, um monstro. Ao se definir o ator é definido seu nome e sua força (ou energia), no exemplo acima são usados macros (como em C) para facilitar modicações. Existe um arquivo chamado DEFS.CON onde estes macros são declarados.

Após definição do ator, temos o código do ator, que é executado todo quadro por cada ator deste tipo que estiver ativo. Cada ator possui uma ação em execução e uma rotina de ai. A primeira linha do script do ator chama o estado checkdronenearplayer (o código deste pode ser visto abaixo), o estado simplesmente verifica se o jogador esta próximo, se sim, checa se o tempo é suficiente, se sim, explode o drone, caso contrário apenas toca um som de alarme.

Em seguida temos o teste “ifrnd 2”, ifrnd é uma versão especial do if que verifica se o jogo sorteou um número aleatório, caso sim, o código do if é executado. Este bloco em particular faz com que o drone caia um pouco e toque um som de turbina. Outros estados fazem com o que drone suba, dessa forma é criado um movimento de para cima e para baixo, apenas um efeito especial.

Na sequencia temos o comando “ifaction 0”, que verifica se a ação atual é a de número 0 (ou seja sem ação, o estado inicial do ator), se sim, é iniciado o ai AIDRONEGETE, que é uma abreviação para “procure inimigo”. Caso a ação atual não seja a de número zero, são checados os diversos estados do ator. Logo na sequencia é checado se a ação atual é a AIDRONEGETE, caso sim, é invocado o estado dronegetstate, que checa se o jogador esta visivel, caso sim, começa mover o drone em direção ao jogador.

Na sequência o código vai checando os demais estados, onde podemos ver que é verificado se o ator esta sendo atacado, onde ele tenta então desviar das balas, caso tenha sido encolhido (o jogo possui uma arma de encolher), checa se já não é hora de crescer novamente, etc.

A definição de um ai é extremamente simples, como podemos ver no exemplo abaixo:

ai AIDRONEGETE DRONESCREAM DRONERUNVELS faceplayerslow getv

Na declaração acima o primeiro parâmetro (AIDRONEGETE) é o nome deste ai, o segundo parâmetro a ação (DRONESCREAM, que define a animação a ser executada), o terceiro (DRONERUNVELS) é um macro com a velocidade deste ai, após este três parâmetros (obrigatórios) temos as rotinas de ai, neste caso, vão ser executadas as rotinas faceplayerslow e getv, sendo qua primeira faz com que o ator se vire em direção ao jogador, a segunda faz com que ele se mova verticalmente (lembra que o drone de tempos em tempo cai um pouco? Aqui ele sobe para compensar).

Abaixo temos o estado checkdronenearplayer:

state checkdronenearplayer

  ifp palive
    ifpdistl 1596
  {
    ifcount 8
    {
      addkills 1
      sound DRON_ATTACK2
      debris SCRAP1 8
      debris SCRAP2 4
      debris SCRAP3 7
      spawn EXPLOSION2
      sound RPG_EXPLODE
      hitradius 2048 15 20 25 30
      killit
    }
    else
      ifcount 3 nullop
      else
        sound LASERTRIP_ARMING
  }

ends

O estado acima verifica primeiramente se o jogador esta vivo, caso positivo, verifica se ele esta perto o bastante, caso sim verifica se esta a tempo suficiente e explode para tentar destruir o jogador.

Observe que a linguagem de script é extremamente simples, não existem expressões complexas, declarações de variáveis, etc, existem apenas blocos e testes simples. Os comandos de if são todos fixos para testes determinados, como:

  • ifai : verifica se o ai especificado esta ativo, caso sim, executa o bloco
  • ifaction : idem ao anterior, mas verifica se a ação especificada esta ativa
  • ifcount : todo ator possui um contador interno, incrementado todo quadro, como se fosse um relógio, este comando verifica se o contador é maior ou igual ao valor especificado. Dessa forma pode-se atrasar ou controlar o tempo de execução de ações.
  • ifrnd : o jogo possui internamente um valor aleatório, que vai de 0 a 255. Este comando checa a probabilidade de um valor ocorrer. Por exemplo, ifrnd 255 é o mesmo que if true, ou seja ocorre o tempo todo. ifrnd 127 ocorre 50% das vezes, etc.

Observe que nem mesmo expressões lógicas existem, como ou, e, ou exclusivo, etc. Caso seja preciso fazer expressões lógicas, elas são construídas encadeando-se vários ifs.

Como a linguagem não possui expressões, fica extremamente simples de se compilar. Basicamente a compilação consiste em checar os comandos em uma tabela e ir trocando pelo bytecode específico, não sendo preciso construir árvores sintáticas ou qualquer outra técnica de compilação classica.

Considerações Finais

O jogo já possui uma certa idade e se compararmos com os grandes titulos da atualidade este fica devendo em muitos pontos. Mas por outro lado foi um jogo que marcou época, não só pelo seu gameplay revolucionário para a época, mas também pela sua tecnologia soberba. Mas ao mesmo tempo que o jogo era simples, sua tecnologia era extremamente avançada e mesmo com algumas gambiarras, ela até hoje nos traz muitas lições e ideias para design de motores 3d e ferramentas de autoria.

Um dos pontos que mais me chamam a atenção é como o sistema de sprites e efeitos se assemelha a um moderno sistema de componentes, que atualmente é um dos pontos mais discutidos e considerado estado da arte na industria atual.

O código fonte do jogo esta disponível para os curiosos, pode ser baixado diretamente do pontov clicando-se aqui. Este é o código original disponibilizado pela 3D Realms, construído originalmente com o Code Warrior e próprio para ser compilado para Dos. É muito útil para quem quer explorar os detalhes da implementação do gameplay e conhecer melhor um motor para Dos. Para quem quer algo mais moderno, é recomendável usar o código já portado para plataformas modernas, que pode ser encontrado no site EDuke3d.

O código fonte pessoalmente considero bagunçado, existem muitas constantes diretamente no código que dificultam a leitura, conversões de ponto fixo diretamente no código, além de uma grande falta de modularidade em alguns pontos. Basta observar que o código é formado por poucos arquivos gigantes. Não é incomum encontrar grandes blocos de ifs e switchs para execução de rotinas especificas para cada inimigo / objeto.

Referencias

Arquivos Con (scripts): http://dukertcm.com/knowledge-base/downloads-rtcm/duke3d-faqs-con/

Ken Silverman (criador do motor Build): http://advsys.net/ken/

Duke3d: http://www.3drealms.com/duke3d/

FAQ sobre edição de cenários: http://www.gamefaqs.com/pc/197174-duke-nukem-3d/faqs/1664

Tags: http://infosuite.duke4.net/index.php?page=basics_tags´

Ótima documentação sobre os scripts: http://dukenukem.wikia.com/wiki/Con_files/Files

Duke 3d (código fonte): http://www.pontov.com.br/files/arquitetura/dissecando/duke3d/duke3dsource.zip


Comentários (15)
  • Calvin
    avatar

    Muito bom este post.
    Excelente ver a participação da empresa ao disponibilizar o código-fonte para comunidade. Isto gera um enorme ciclo de conhecimento para os desenvolvedores. E para aprender como fazer uma engine é uma enorme experiência.

  • Bruno Crivelari Sanches
    avatar

    Obrigado Calvin!

    O código do duke em si eu não recomendo muito, é muito bagunçado e tem muitas gambiarras, tem que ser analisado com cautela, tanto que nem entrei em detalhes sobre o código no artigo.

    Mas os conceitos em geral e como o motor funciona é muito interessante e vale a pena aprender sobre.

  • David Augusto
    avatar

    Parabéns pelo post e pela série Dissecando! Está me ajudando e incentivando muito na jornada de aprendizado.

  • Anônimo
    avatar

    Obrigado David!

  • José F. Filho
    avatar

    Excelente análise Bruno.

    Eu sempre fiz um esforço danado para tentar entender o código do Duke, Shadow Warrior e da própria engine Build, porém sempre acabo por desistir. Quando eu era adepto do C, encontrei no código do Duke um macro bem interessante. Eu implementei uma versão dele assim:

    #define new( t ) ( ( t* )malloc( sizeof( t ) ) )

    Para mim foi bem mais intuitivo usar new( type ) do que ( type* )malloc( ... ).

  • Anônimo
    avatar

    OBrigado José!

    Legal o macro, já adiantaram o cast do malloc.

    O código do duke não é muito complicado de entender, se você entende como o motor funciona e o caminho para isso é aprender a fazer mods.

    O pessoal hoje despreza muita a criação de mods, jogar 15 minutos de WoW e já querem construir seu próprio MMORPG.

    Para mim, estudar como modificar jogos existentes é uma das melhores formas de entender como eles funcionam.

  • José F. Filho
    avatar

    Você está correto sobre a questão do MMORPG, que (in)felizmente virou obcessão de qualquer aspirante a programador.

    No caso dos mods, o exemplo mais notável é o ruim de doer ( pra mim ) Counter-Strike, mod do Half-Life. Sou péssimo em jogos online. :)

    Aliás, no site http://blendogames.com/older há alguns mods bem bacanas feitos por Brendon Chung, autor do excelente Gravity Bone, que foi feito com o id tech 2. No site há outros, como mods de Half-Life, Doom, Doom 3, etc.

    Por falar em Half-Life, seria bacana dissecá-lo. Até hoje o motor GoldSrc me fascina. Assim como os motores id tech, principalmente a versão 2 ( id tech 2 ).

  • Anônimo
    avatar

    Os motores da id estão na lista aqui, esses vão dar trabalho pois conheço de forma bem mais detalhada que o Duke.

    Ainda não sei em cima de qual vou fazer, pois a arquitetura de gameplay é tem muitas semelhanças entre todos eles. Talvez o Half Life, pois ele tem algumas coisas mais interessantes que os demais.

  • José F. Filho
    avatar

    Até hoje eu me pergunto como a Valve conseguiu fazer tudo aquilo no Half-Life usando uma "variante" do motor Quake.

    O SDK do Half-Life¹ é bem interessante, principalmente a AI, escrita hard coded em C++ no lugar do QuakeC. E eu que aprendi a programar em meados de 97 usando o QuakeC ! :D

    Sempre achei a arquitetura Client - Server do Quake engine fantástica. Bem aproveitada pelo citado Counter-Strike.

  • Anônimo
    avatar

    A id chutou o QuakeC logo após o primeiro quake, questão de desempenho se me lembro bem. Tanto que o Quake 2 já tinha o gameplay todo feito em C.

    A Valve pegou o código original do quake e socou C++ onde pode e o gameplay foi um dos pontos. Mas a sacada ali não é a linguagem, foi como eles arquitetaram os componentes, ou no linguajar do quake: as entidades.

    O divertido era que a valve ainda usava restos do QuakeC em arquivos de configuração :).

    A valve investiu pesado no IA, os inimigos tiham um bom IA e sabiam muito bem como navegar pelo cenário, isso foi diferencial.

    Depois eles montaram um sistema de entidades que comandavam toda a parte scriptada do jogo, nào tinha script mesmo, era tudo montado no editor de níveis linkando partes. Eu anos mais tarde copiei essa arquitetura na cara dura quando fizemos a Jessy.

  • José F. Filho
    avatar

    Jessy inclusive é um baita jogo. Tinha um cara que comprou e me emprestou para dar uma olhada.

    Uma questão: O Jessy explorou todo o potencial do Craft3D ou havia algo mais que não foi aproveitado ?

    Outra questão: os modelos usados no Jessy usavam o formato MD2 ou SMD ?

    Há alguma chance de virar open source ?

  • Anônimo
    avatar

    A Jessy levou o Craft3d na época ao limite, pois ele era um projeto de final de curso meu e do Danny, até a Jessy, estava apenas naquela fase de testes, foi a primeira vez que ele começou a ser usado em produção mesmo.

    A Jessy foi boa para deixarmos o Craft usável como motor de jogo, mas o prazo apertado forçou muitos cortes. Ele ainda tinha algums coisas instáveis que atrapalharam muito a produção.

    O formato de modelos era um SMD modificado. Na época um sujeito fez um exportador de SMD e eu entrei em contato com ele e ele liberou o código para usarmos. Eu modifiquei o exportador para ele suportar múltiplos bones por vértices, o SMD original só suportava um.

    Open source tem sim, o Danny até me mandou o código final que ele tinha em um arquivo, eu acabei nunca publicando pois até o momento ninguém tinha mostrado interesse. Preciso tentar compilar e subir para o github.

  • José F. Filho
    avatar

    Bacana.

    Pelo menos eu estou interessado. ;)
    Quando publicá-lo, certamente vou checar.

  • renan  - :)
    avatar

    Muito legal esses artigos "dissecando".

  • Anônimo
    avatar

    Obrigado Renan!

Escrever um comentário
Your Contact Details:
Gravatar enabled
Comentário:
[b] [i] [u] [url] [quote] [code] [img]   
:angry::0:confused::cheer:B):evil::silly::dry::lol::kiss::D:pinch::(:shock:
:X:side::):P:unsure::woohoo::huh::whistle:;):S:!::?::idea::arrow:
Security
Por favor coloque o código anti-spam que você lê na imagem.
LAST_UPDATED2  

Busca

Linguagens

Twitter