Dissecando o game: Duke Nukem 3d

Transcrição

Escrito por Bruno Crivelari Sanches
Qua, 21 de Novembro de 2012 11:00 - Última atualização Dom, 18 de Novembro de 2012 20:24
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”.
1 / 20
Sem
difícil
quebram,
você
corredor,
falar
nunca
ver
por
como
que
viria
osão
éocomo,
jogo,
um
comum
lampadas,
mesmo
por
hoje
designer
exemplo,
com
em
que
dia.
todas
resultavam
usar
explodindo
uma
asexplorar
limitações
cadeira
em
uma
uma
bomba
da
sala
adamantium
época
bem
em
trazia
escura.
para
sala,
efeitos
Era
bloquear
osprincipalmente
uma
vidros
quegráficos
época
até
um
se
hoje
que
é
Para
filmes,
Aliens,
completar
sendo
Pulp
Fiction
possível
jogo
elevel
muitos
tinha
encontrar
outros.
pelos
de
cenários
referências
personagens
ade
cultura
pop
de uma
filmes
da
como
Indiana
Jones,
rapidamente
Se
soberbos
não
bastasse
eincluindo
ainda
eai,
tudo
incluia
esses
isso,
um
itens
odezenas
editor
jogo
que
vinha
de
iremos
níveis
com
que
uma
qualquer
tecnologia
nesse
artigo.
criança
revolucionária,
(daépoca,
época)
com
aprendia
usar
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
2 / 20
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.
3 / 20
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
ed
uke3d
) com pacotes de alta resolução e ter uma experiência mais interessante:
4 / 20
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.
5 / 20
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.
6 / 20
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:
7 / 20
temos
Para
que
linhas
Observe
os
tal,
vermelhas,
3setores
setores.
basta
que cada
irvão
posicionando
aparte
tomando
operação
do
forma.
toda
o mouse
pode
forma
No
final
nos
ser
o que
basta
pontos
feita
com
conectar
jogo
desejados
apenas
é chamado
os alguns
pontos
e pressionar
de
cliques
dosetor,
meio
barra
do
na
para
mouse.
figura
degerar
espaços
acima
as
Pressionando-se
ENTER
docenário
teclado
númerico
já no
nos
deparamos
com:
8 / 20
Trocando
algo
já menos
algumas
feio: texturas, mudando altura do chão e teto e rapidamente podemos construir
9 / 20
E porcomeça
cursor
colocarmos
que
fim,
do mouse
basta
uma
no alto:
voltar
tag
sobre
neste
ao
o setor
modo
setor,
que
2d
digite
(pressionando
forma
16,oque
elevador,
é aENTER
tagpressionar
quedo
indica
teclado
aque
tecla
numérico),
este
T (de
setor
Tag)
posicionar
é um
para
elevador
o
10 / 20
Com
desce,
importar,
este
tudo
ajustar,
processo
isso
em
etc.
simples,
um
unico
já
editor,
criamos
sem
um
precisar
cenário
iro
funcional,
em
modelador
com
um
3d,
elevador
exportar
que
arquivos,
sobe
eusar
um
desafiador
como
level
esta
designer
oeexemplo
cenário
que
é botão,
claro,
produzem
experiente
éa
divertido.
extremamente
resultados
pode
São
em
poucas
simplista
algumas
tão
rapidamente.
as
ferramentas
se
horas
comparado
criar
hoje
um
com
nível
que
qualquer
são
totalmente
tão
jogo
simples
funcional,
moderno,
de
se
mas
Claro
strings
que
que
um
eram
objeto
nem
sempre
tudo
faz
eram
não
evitadas
flores,
nada
devido
intuitivo,
por
exemplo,
avez,
seu
custo
eram
usar
computacional.
números
dificuldades
da
descrever
época,
pois
aséforma,
propriedades
manipulação
de
e
Observando
número,
o
poderíamos
pressionano
do
quanto
0,
cenário
tempo…
era
nomes,
chamado
no
criar
novamente
o
linkar
mas
uma
de
objetos.
acima
HiTag
ele
simplicidade
botão
aéativa
imagem
Mais
temos
(ou
e
colocar
o
Tag
elevador.
uma
0,16.
acima,
do
alta),
editor
nele
Omas
era
note
Ou
16
usar
o
acabava
mesmo
é
usada
seja,
que
a
números
Tag
o
para
hitag
setor
superando
que
para
conectar
indica
do
era
dopara
elevador,
essa
elevador
usado
que
esses
objetos.
tarefa
este
para
defeitos
possui
dessa
não
setor
identificar
Exemplo:
um
éna
algo
um
outro
maior
um
tão
elevador,
objeto
prático
parte
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
11 / 20
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
s
prite
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:
Mas apenas colocar itens no cenários não cria jogabilidade, ainda falta uma forma de se criar
12 / 20
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:
13 / 20
Na
figura
aao
grande
letra
“A”
éaoose
sprite
activator,
vai
ser
conectada
doações
lado
direito
temos
uma
chave,
que
adicionado
também
outro
sprite
especial,
onúmero
Foicaso,
speed
, que
ele
afeta
pode
aacima,
velocidade
ser
usado
para
que
o
controlar
elevador
velocidade
que
as
são executadas,
Para
dizer
ao
jogo
que
a no
chave
afeta
activator
comunicação
entre
para
tal,
basta
definirmos
do
uma
elevador,
devemos
criaractivator.
canal
de
tag
baixa
abaixo:
idêntica
para
eles,
caso,
utilizei
omove.
1,
como
podemos
conferir
na nesse
imagem
14 / 20
Podemos
na
acima
claramente
oveículos
activator,
com
sua
tag
direita,
mecanismo
emobservar
verde
simples,
temos
jáfigura
podemos
a chave,
que
também
operações
esta
com
aetc.
no
jogo.
tag
baixa.
baixa
Com
de
valor
este
1, a
Além
destes,
outros
sprites
especiais
foram
criados,
alguns
exemplos:
touchplate:
um
gatilho
ativado
automaticamente
quando
jogador
entre
no
musicandfx:
para
tocar
eoriginal
música
- locator:
queé
éutilizado
usado
para
definir
rotas
que
emesma
alguns
inimigos
seguem
sectoreffector:
infinidade
Alguns
de
efeitos
explosões,
certamente
especiais,
teletransporte,
que
ocriar
mais
no
jogo
famoso
iluminação,
e complexas
mais
eram
um
total
responsável
36
efeitos
por
ativar
diferentes.
uma
Chega
efeitos
aexemplos:
bem
ser
complexos,
impressionante
ainda
como
mais
alguns
sesons
considerarmos
poucos
componentes
ausado,
época
eo
tornaram
osde
jogos
equivalentes.
possível
asetor.
criação
de
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:
15 / 20
- 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
16 / 20
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
17 / 20
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.
18 / 20
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/
19 / 20
Duke3d: http://www.3drealms.com/duke3d/
FAQ sobre edição de cenários: http://www.gamefaqs.com/pc/197174-duke-nukem-3d/faqs/166
4
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/duke3d
source.zip
20 / 20

Dissecando o game: Duke Nukem 3d

Transcrição

Documentos relacionados

Assis, Bruno Monte de, 1988

O BALCÃO DO WHOPPER

Apresentação FETEC

GAME DA RESPONSABILIDADE SOCIAL FAMATH

turma: 6º ano c

Residente da PINK ELEPHANT e proprietário Making Comunicação

// 109 MindGym: Jogos para Doentes com Alzeimer?

These all are free copyrighted scripts. Demo specs: • mp3, 128Kbps

o sono e o sonho - Projeto Andar de Novo

Dragon Ball Z: O Renascimento de F ganha jogo para celular