Iniciando Na Carreira de Desenvolvimento de Jogos

iniciando na
carreira de
desenvolvimento
de jogos
autor Edgard Damiani
Afinal, o que um jogo?

Muito do que falamos para expressar nossos pensamentos pode adquirir uma roupagem absoluta
com uma facilidade enorme, mas o bom e velho Deus do Tempo sempre se encarrega de acabar com
esse tipo de posicionamento. O que escrevo aqui no deve ser visto como a Verdade, e sim como algo
que deve ser lido, refletido e absorvido medida que ressoar dentro de voc, leitor; portanto,
mantenha para si aquilo que concordar, e no pense duas vezes em descartar o resto.
Introduo
Quando falamos das grandes reas de desenvolvimento de jogos,
costumamos englobar todos os aspectos tcnicos sob a alcunha de
programao, mas ser que isso uma boa definio do ponto de
vista prtico?
Tecnicamente falando, a programao uma fase da engenharia de
software, a qual abarca no s a programao em si, mas tambm
todas as fases que vm antes e depois da mesma. Falar apenas de
programao acaba estreitando o foco do desenvolvedor, correndo
o risco de faz-lo esquecer que existem fases como planejamento,
teste, implantao, manuteno etc. dar a devida importncia a
todas as fases de desenvolvimento pode ser um fator decisivo para a
longevidade de um projeto de software.
Este artigo tem como objetivo dar uma breve introduo sobre o
desenvolvimento de jogos do ponto de vista da engenharia de software,
concentrando na fase de planejamento e mostrando como os aspectos
tcnicos e no-tcnicos do desenvolvimento de um jogo se mesclam
durante todo o processo, levantando questes importantes sobre como
WWW.UNIDIGITALDOBRASIL.COM.BR
2015 Unidigital do Brasil

Todos os Direitos Reservados
manter um certo grau de independncia entre os departamentos de

game design, multimdia e engenharia de software.
Ao longo do artigo voc ver vrios links da Wikipedia para verbetes
importantes caso no conhea algum dos termos destacados, sugiro
que interrompa a leitura do artigo e leia o contedo do link antes de
seguir adiante (sempre que possvel, os links estaro em portugus).
O que um jogo?
Quando falamos de jogos, muito comum usar a palavra sem definila, o que pode causar inmeros erros de interpretao. Sendo assim,
antes de comear a discusso, vamos tentar definir o termo de um
ponto de vista tcnico:
Jogo uma atividade interativa em que os elementos participantes
realizam aes baseadas em regras, dentro de um campo bem-definido
e separado do mundo real, a fim de superar desafios propostos interna
ou externamente para se alcanar um determinado objetivo.
Um jogo, portanto, tem trs aspectos centrais:
Interatividade.
Entidades e regras.
Imerso.
A interatividade o aspecto mais bvio de um jogo afinal, no h
jogo sem interatividade! As entidades e regras, por outro lado, definem
os elementos constituintes de um jogo ou o chamado domnio por
exemplo, jogadores, obstculos e itens so elementos constituintes de
um jogo, enquanto as regras definem como tais entidades interagem
entre si, bem como os objetivos a serem alcanados. Por fim, a imerso
determina o aspecto de separao do mundo ldico em relao ao
mundo real, a fim de tal mundo ldico poder ser experimentado como
uma realidade em si.
Curiosamente, esses trs aspectos interatividade, entidades/regras
e imerso podem ser dispostos linearmente no famoso esquema

Entrada-Processamento-Sada de processamento de dados:
Figura 1. Esquema Entrada-Processamento-Sada.
Ou seja, o jogador interage com o jogo (entrada), o qual ir processar

as entradas do jogador e redefinir os estados de todos os elementos
de jogo (processamento) e apresentar os resultados ao jogador (sada)
em um processo contnuo de retroalimentao ou feedback.
Loop de jogo
Sendo assim, do ponto de vista tcnico, qual a grande diferena
entre um jogo e um aplicativo comum? Na maioria dos casos (e
existem algumas excees aqui), a grande diferena fica por conta do
tempo levado desde a entrada at a sada e, consequentemente, at o
processo de retroalimentao, ou seja, o tempo de resposta do ciclo de
processamento de dados tende a ser muito curto, a fim de criar o que
se chama de experincia em tempo real.
Quanto mais curto o tempo de resposta, melhor o jogo ser capaz de
responder s aes do usurio, facilitando o processo de imerso do
jogador dentro do jogo. Esse ponto to fundamental que poderamos dizer
que ele , literal e metaforicamente, o corao de um jogo metafrico
porque ele determina um ritmo, por assim dizer, de processamento do
jogo, e literal porque ele cria o conceito central de loop de jogo.
O loop de jogo, portanto, a estrutura central de um jogo que cuida
para que a entrada, o processamento e a sada ocorram de maneira

ordenada e orquestrada, sempre respeitando o tempo de cada batida

do corao metafrico.
Sempre que ocorre uma batida do corao do loop de jogo, o jogo
avana um pouquinho, e esse avano quase imperceptvel de cada
batida do corao gera um ritmo constante que cria a iluso de
que o universo daquele jogo est vivo. Podemos, ento, modificar
ligeiramente a figura anterior para esquematizar o panorama tcnico
geral de um jogo:
Figura 2. O esquema Entrada-Processamento-Sada como loop de jogo.
Usando uma pseudolinguagem de programao, poderamos dizer de

maneira simplificada que o loop de jogo algo assim:
Enquanto jogo estiver sendo executado

Capture entradas de usurio

Atualize o jogo de acordo com as regras

Atualize a inteligncia artificial

Atualize a fsica

Atualize os grficos

Atualize o udio
...

Renderize a cena
Fim Enquanto

Em termos tcnicos, quem prov funcionalidades como captura

de entrada de usurio, fsica, grficos, inteligncia artificial etc.
uma biblioteca chamada game engine, ou mecanismo de jogo. O
objetivo de um game engine (ou de qualquer engine, na verdade)
prover funcionalidades de alto nvel que possam ser reutilizadas
em vrios jogos por exemplo, captura de joystick, carregamento
de imagens e modelos 3D, clculos de coliso e aplicao de foras,
clculo do caminho percorrido por um personagem, reproduo de
arquivos MP3 etc. Sem um game engine, desenvolver um novo jogo
sempre significaria recomear da estaca zero, gerando um ciclo de
desenvolvimento mais longo (e mais caro) do que o necessrio.
Do ponto de vista da arquitetura de software, poderamos dizer que
o game engine cria uma camada de abstrao entre o jogo em si e as
APIs de um sistema operacional, que so bibliotecas de baixo nvel
com acesso (quase) direto ao hardware:
Figura 3. Especificao de um jogo dentro de uma arquitetura de 3 camadas.
Agora que sabemos como o game engine e o jogo conversam entre

si, podemos nos concentrar na camada superior e fazer a grande

pergunta: como estruturar um jogo?

O processo de transformao de uma ideia em software um processo
delicado, exigindo uma ateno especial por parte das pessoas
envolvidas na sua criao. Simplesmente sair programando sem um
projeto prvio pode at funcionar em situaes simples como a criao
de um Pong, mas no caso de jogos mais complexos faz-se necessrio
estabelecer metodologias de desenvolvimento e uma arquitetura geral
que permita dividir a complexidade do processo em partes menores e
mais gerenciveis.
Tenha em mente, portanto, que quando falamos de arquitetura ainda
no estamos falando de cdigo o objetivo neste nvel determinar
um plano de ataque inicial que nos permita criar uma base de
cdigo mais flexvel e que siga certos princpios e boas prticas de
desenvolvimento, mas antes de prosseguirmos no assunto, vamos
subir um pouco mais o nosso ponto de vista e entender o panorama
geral de desenvolvimento de um jogo.
A trade Game Design/

Multimdia/Engenharia
de Software
A criao de um jogo eletrnico pode envolver literalmente centenas
de pessoas com dezenas de papis e cargos distintos, mas podemos
resumir o processo de desenvolvimento central em trs grandes reas:
game design, multimdia e engenharia de software.
A rea de game design, de um modo muito geral, responsvel por
criar e cuidar daquilo que se chama jogabilidade, ou seja, a habilidade ou
capacidade de jogar. Ao contrrio do que se pode pensar, a jogabilidade
em si no est inicialmente ligada ao ambiente tcnico muitos
game designers criam seus primeiros prottipos utilizando materiais
nada tecnolgicos como tabuleiros, miniaturas ou pees, dados, fitas
mtricas etc. Estou enfatizando este ponto aqui para deixar claro

que a essncia do trabalho de um game designer so as entidades e

as regras de um jogo, que podem ser expressas futuramente de mil
maneiras distintas no ambiente tecnolgico. (Obviamente, existem
jogos cujas regras s podem ser expressas adequadamente em um
meio digital nesses casos, as reas de game design e programao
acabam se mesclando, mas sem mudar o fato de que a essncia do
game design o trabalho de criar e equilibrar a jogabilidade.)
Uma vez que a rea de game design tenha considerado as entidades
e regras como suficientemente desenvolvidas em nvel de prottipo,
duas frentes de trabalho surgiro: a primeira dever considerar os
desafios tcnicos de construo do jogo, e a segunda dever considerar
os aspectos estticos ou multimdia do mesmo. Engenharia de software
e desenvolvimento multimdia, portanto, dependem de um bom game
design para que suas tarefas possam correr normalmente, lembrando
que design significa projeto, e qualquer implementao depende de
uma fase prvia de projeto para que possa ter um rumo adequado,
garantindo um mnimo de foco a fim de os desenvolvedores no
ficarem pisando uns nos ps dos outros. (O que no significa, claro,
que isso no v acontecer; hoje sabe-se que praticamente impossvel
tentar definir perfeitamente toda a fase de anlise e projeto antes de
se iniciar a fase de desenvolvimento, e por isso que as metodologias
geis promovem a ideia de desenvolvimento iterativo.)
Para que cada elemento dessa trade possa fazer sua parte,
importante que suas reas ou interesses possam ocorrer o mximo
possvel em paralelo, para que cada um possa continuar realizando
seu trabalho com um mnimo de independncia em relao s outras
duas reas. O grande desafio, ento, organizar o desenvolvimento
de forma que a rea tcnica no se torne um gargalo para as demais
reas e vice-versa. Nesse sentido, a responsabilidade acaba ficando
nas costas da engenharia de software, j que, em ltima instncia, o
objetivo produzir um software.
Como, ento, garantir que cada rea consiga fazer a sua parte com
um mnimo de independncia? A soluo dividir o processo de
desenvolvimento do software considerando a existncia dessas trs
reas, e por coincidncia essa arquitetura especfica existe desde a
primeira verso do primeiro sistema operacional grfico.

MVC e amigos
Existem inmeros problemas que so recorrentes no mundo do
desenvolvimento de software, e vrios desses problemas recorrentes
tiveram suas solues devidamente catalogadas tanto no nvel de
arquitetura quanto no nvel de projeto. Cada problema com sua
respectiva soluo e aplicao conhecido como padro de arquitetura
Figura 4. Ilustrando Arquitetura de Software
ou padro de projeto (dependendo do nvel em que estivermos

conversando), com os padres de arquitetura representando solues
mais amplas do que os padres de projeto. O objetivo dos padres
de arquitetura e/ou dos padres de projeto criar um vocabulrio
conceitual de desenvolvimento que possa ser usado para melhor
estruturar o projeto como um todo, facilitando a viso global do projeto
e, em ltima instncia, organizando o processo de programao em si.
Um padro de arquitetura amplamente conhecido o Modelo-Viso-

Controlador ou MVC. Nesse padro, um sistema dividido em trs

grandes reas:
Modelo: Define o conjunto de entidades e as regras de interao
entre elas.
Viso: Define a apresentao do modelo ao usurio.
Controlador: Captura a entrada de dados do usurio.
Se reordenarmos os elementos para Controlador-Modelo-Viso,
veremos que essa ordem guarda uma coincidncia muito grande com
a sequncia Entrada-Processamento-Sada.
Mas o que exatamente o padro MVC soluciona? O padro MVC foi
criado para resolver problemas relacionados a interfaces de usurio, e
a sua principal ideia a separao de interesses, ou seja, cada elemento
do padro MVC agrupa funcionalidades semelhantes, permitindo que
os demais elementos concentrem-se nas suas reas de atuao.
Tomemos como exemplo o modelo: seu objetivo definir o ncleo
de processamento de um programa, independentemente de como
o usurio estiver interagindo com ele ou de como o programa ser
apresentado ao usurio.
Se imaginarmos um jogo como o Space Invaders, podemos entender o
modelo como sendo a cena de jogo (ou melhor, os elementos de cena
que interajam com as entidades de jogo), a nave do jogador, as naves
inimigas, os tiros disparados pelas naves e as regras de interao
entre todos eles no entanto, no modelo no estamos interessados
em como as entidades sero representadas, e sim no que as entidades
fazem.
Observe a figura a seguir:

10
Figura 5. O jogo Space Invaders como visto pelo jogador.
Nela, podemos ver o jogo tal como ser apresentado ao jogador. No

modelo, no entanto, podemos imaginar o jogo assim:
Figura 6. O mesmo Space Invaders visto do ponto de vista do programador do modelo.

11
Aqui, estamos preocupados apenas com os aspectos abstratos de cada

entidade como posio, tamanho, rea de coliso, velocidade etc.,
sem nos preocuparmos com o aspecto esttico de tais entidades (os
retngulos foram pintados de cores diferentes apenas para deixar
claro que cada cor representa um tipo de entidade). Dessa forma, o
programador do modelo fica livre para se concentrar nos algoritmos
do jogo em si, sem se distrair com detalhes como se as naves sero 2D
ou 3D, se um efeito sonoro ser reproduzido ao disparar um tiro etc.
A viso, por outro lado, cuida exatamente dos detalhes negligenciados
pelo modelo para isso, importante que a viso tenha acesso aos
dados do modelo, para que as entidades possam ser representadas da
maneira correta em termos de posio, tamanho, estado atual etc. Se
imaginarmos um jogo como o Prince of Persia, veremos que alguns
elementos fazem parte do modelo e outros da viso. Um exemplo claro
disso o movimento do personagem principal: ao moviment-lo para
o lado, o personagem ir se deslocar na tela, ao mesmo tempo em
que apresenta uma sequncia de imagens que do a sensao de que
ele est realmente andando at chegar ao ponto de destino (o famoso
ciclo de caminhada ou walking cycle). Na figura a seguir, estamos
representando o personagem como um retngulo que se movimenta
da esquerda para a direita:
Figura 7. Sequncia de nove quadros sobrepostos representando o movimento da entidade.
Este seria o nvel de implementao do modelo, no qual ele se

encarregaria do deslocamento da entidade pela cena e de estabelecer
qual o estado atual do mesmo (parado, movendo-se para a esquerda,
movendo-se para a direita, pulando etc.).
A viso, por sua vez, pegaria o estado atual da entidade que representa

12
o prncipe dentro do modelo e faria isso:
Figura 8. Os mesmos nove quadros com os respectivos sprites sobrepostos.
A viso, portanto, ficaria responsvel por capturar o estado do

personagem definido no modelo e apresentar a sequncia de imagens
equivalente a tal estado.
At aqui tratamos o personagem como se ele estivesse sendo movido
por uma fora oculta, mas na verdade precisamos de um elemento
que sirva de ponte entre o jogador e o jogo em si (ou seja, o modelo),
e esse componente o controlador. A grande vantagem de usar um
controlador est representada na figura a seguir:
Figura 9. O controlador dentro do esquema geral do MVC.

13
Perceba que o controlador recebe qualquer tipo de entrada de usurio,

mas envia mensagens padronizadas para o modelo por exemplo,
independentemente de o jogador pressionar a seta para a direita
no teclado ou o direcional direito no joystick, o modelo receber
uma mensagem mova o personagem para a direita. Com isso,
conseguimos mais uma vez isolar o modelo de certos detalhes de
implementao, permitindo que o programador do modelo concentrese em trabalhar as entidades e as regras entre elas.
Exemplo prtico: Pong

Para tentar explicar certos conceitos, vamos usar o bom e velho
Pong como exemplo. Inicialmente, surge a ideia de fazer um jogo no
qual dois jogadores devem rebater uma bola a fim de impedir que
seu oponente a devolva, marcando um ponto. A criao dessa ideia,
mais os detalhes de como os jogadores vo interagir com a bola, como
cada entidade vai se comportar dentro do jogo, como ser o sistema
de pontuao etc. tudo isso entra no campo de atuao do game
designer.
Em seguida, a ideia dever ser transformada em software, e para isso
precisamos determinar em nvel de projeto quais so os elementos
principais do jogo, como mostra a figura a seguir:
Figura 10. Entidades de jogo.
Agora que sabemos quais so as entidades, podemos determinar as

interaes bsicas entre elas:

14
Figura 11. Relaes entre as entidades de jogo.
O que estamos fazendo determinar o modelo de domnio do jogo,

sem nos preocuparmos com detalhes de implementao relacionados
entrada de usurio ou apresentao do jogo ao jogador.
Perceba, no entanto, que houve uma alterao entre as figuras 9 e 10:
o que previamente chamamos de Campo virou Limite de Campo
na figura 10 isso um acontecimento perfeitamente normal quando
estamos projetando um software, pois a compreenso do mesmo vai
aumentando conforme avanamos em seu desenvolvimento.
Vamos, agora, adicionar o controlador ao nosso projeto, supondo
que o paddle do jogador possa ser controlado por teclado, mouse ou
toques em uma touch screen:

15
Figura 12. Relao entre controlador e modelo no Pong.
Perceba que o controlador gera mensagens ao modelo, mas o modelo

no faz a menor ideia do tipo de hardware que as est gerando, j que a
mensagem apenas indica que o paddle deve ser movido. (Poderamos
deixar a mensagem mais genrica ainda, indicando apenas que houve
um movimento para a esquerda, por exemplo, sem indicar qual
entidade deve ser movimentada.)
Por fim, precisamos adicionar a viso ao projeto:
Figura 13. Incluso da viso no esquema MVC do Pong.


16
Perceba que a viso possui elementos semelhantes ao modelo, com cada

um desses elementos obtendo informaes sobre a sua contraparte
abstrata para que o jogo possa ser corretamente apresentado ao
jogador.
Conforme vamos avanando o projeto, pouco a pouco os elementos
conceituais vo se transformando em objetos propriamente ditos, com
uma representao cada vez mais prxima do mundo da programao.
Vejamos, ento, como dar mais um passo nesse sentido:
Figura 14. Verso mais detalhada do esquema MVC do Pong.
Desta vez, criamos dois objetos dentro do controlador: um Gerenciador

de Eventos, responsvel por receber os dados brutos vindos do usurio,
e o Controlador do Jogo propriamente dito, responsvel por receber os
eventos do gerenciador, interpret-los e enviar os comandos corretos
ao modelo perceba que a forma como o Gerenciador de Entradas e

17
o Controlador do Jogo se relacionam formam um padro de projeto

chamado Publicador/Assinante (Publisher/Subscriber) ou Observador
(Observer).
Outro elemento que foi adicionado ao diagrama foi o Gerenciador de
Jogo dentro do modelo o primeiro ponto motivador de criao do
mesmo foi o reconhecimento de que algum deveria armazenar o
placar do jogo, entre outras informaes globais (por exemplo, o jogo
est em execuo ou em um estado de reincio de partida?).
Desse ponto em diante, o diagrama pode comear a ser transformado
em classes de programao, mostrando seus elementos internos como
variveis e mtodos; aps isso, inicia-se o processo de programao
em si, o qual ir fornecer feedback sobre a validade e veracidade dos
diagramas criados.
Agora, o que fazer caso fique constatado que um diagrama de projeto
no pode ser traduzido fielmente em cdigo? Lembrando do esprito do
processo de desenvolvimento iterativo, devemos retornar ao diagrama
errneo e corrigi-lo, para que a representao abstrata do cdigo e o
cdigo em si continuem em sincronia. Apesar de isso parecer trabalho
em dobro, ao fazer isso voc estar mantendo a documentao do
software atualizada, auxiliando enormemente nos processos de teste
e manuteno (lembre-se, desenvolver um software no significa
apenas programar!).
Por fim, importante entender que os diagrams em nvel de projeto
e em nvel de implementao nunca tero uma representao umpara-um entre seus elementos constituintes, j que a implementao
sempre ter mais detalhes do que o projeto por exemplo, os
diagramas de projeto no esto indicando como as entidades e os
sprites sero armazenados, mas os diagramas de implementao
devero de alguma forma deixar claro como isso vai acontecer (por
exemplo, usando repositrios de objetos ou object pools). Nesse nvel,
os padres de projeto comeam a ganhar proeminncia, j que eles
possuem uma granularidade tal que permite uma traduo quase
direta em cdigo.

18
O que vem depois disso?

Os prximos passos envolveriam preencher as lacunas entre a
representao em nvel de projeto e a criao de cdigo, mas
infelizmente preciso encerrar este artigo antes que ele vire um livro!
De qualquer forma, gostaria de comentar rapidamente um ponto que
gera muitas crticas ao padro MVC: a criao da interface grfica.
Um dos grandes problemas do padro MVC que ele foi concebido
em um contexto no qual todas as interaes do usurio do software
ocorreriam em um mesmo plano, por assim dizer, mas um jogo
possui pelo menos dois planos de interao: o jogo em si, que recebe
determinadas entradas de usurio por exemplo, setas direita e
esquerda do teclado , e a interface grfica de usurio ou GUI (Graphical
User Interface), que recebe um conjunto diferente de entradas por
exemplo, um clique de mouse sobre um boto de menu.
Se voc tentar gerenciar tudo isso de maneira planificada, certamente
ter problemas de confuso entre as camadas da GUI e do jogo em si,
principalmente naqueles casos em que as entradas de usurio forem
muito similares, como ocorre, por exemplo, ao tratar eventos de toque
em um dispositivo mvel.
Apesar de estarmos cutucando os limites do padro MVC clssico,
importante entender que o padro no estanque. Alis, muito
pelo contrrio: do padro clssico surgiram variantes como MVP,
MVVM, HMVC (MVC hierrquico) etc., mostrando que dificilmente
uma soluo ser to abrangente a ponto de conseguir abraar todo o
universo de desenvolvimento de software. Alis, o padro HMVC (ou
alguma variante do mesmo) pode ser visto como um bom candidato
para resolver o dilema jogo/GUI, permitindo que um controlador
global informe sub-controladores sobre o disparo de um evento,
com o controlador global definindo certos critrios para que um subcontrolador receba ou no uma determinada mensagem.
Outro ponto que poderia ser discutido mais amplamente seria a
redistribuio do padro MVC em quatro partes, e no trs, mas isso
j uma histria para outro e-book.

19
Concluso
A engenharia de software enquanto disciplina e metodologia um
assunto vastssimo que deveria ser parada obrigatria para qualquer
programador, mesmo que ele no tenha interesse em seguir tal
carreira. Cada vez mais, grandes empresas de jogos esto usando o
ttulo Programador Snior para indicar programadores que devero
no s gerenciar equipes de programadores, mas tambm gerenciar
o processo de desenvolvimento em si, fatalmente caindo no universo
da engenharia de software. Sendo assim, cada vez mais as empresas
esto demonstrando que a sequncia evolutiva Desenvolvedor Jnior
> Desenvolvedor Pleno > Desenvolvedor Snior caracteriza uma
ampliao contnua da viso do desenvolvedor, at o ponto em que
no ser capaz de enxergar o todo de um projeto e no ser capaz de
gerenci-lo pode indicar estagnao profissional.
Eu j ouvi muitos programadores dizerem que no gostam de
diagramar ou trabalhar em nvel de projeto porque isso acaba
gerando burocracia e papelada sem valor, e verdade que excesso
de anlise e projeto pode levar chamada paralisia da anlise, na
qual os analistas e projetistas ficam to obcecados com os detalhes
que nunca chegam fase de implementao. De qualquer forma,
importante entender que isso um caso extremo, e que o conceito
de desenvolvimento iterativo surgiu justamente para evitar que tais
extremos ocorressem.
Simplesmente sentar e comear a programar pode parecer algo lgico,
mas em projetos de grande porte isso pode significar meses, ou at
mesmo anos de trabalho jogados no lixo caso os programadores
tenham decidido seguir um rumo que se mostrar um beco sem sada
l na frente. Projetar um software ajuda a entender certos becos com
antecedncia, gerando um certo gasto de tempo inicial que pode
significar uma economia enorme de tempo e dinheiro no futuro.
Portanto, no subestime o poder da engenharia de software, mas
tambm no a abrace como se fosse uma religio mantenha
cada coisa em seu lugar e dando a elas suas devidas propores, e
certamente voc ter uma experincia de desenvolvimento de jogos
muito mais satisfatria no futuro.

20

Iniciando Na Carreira de Desenvolvimento de Jogos

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Iniciando Na Carreira de Desenvolvimento de Jogos

Загружено:

Авторское право:

Доступные форматы

iniciando na

Afinal, o que um jogo?

2015 Unidigital do Brasil

manter um certo grau de independncia entre os departamentos de

2015 Unidigital do Brasil

Entrada-Processamento-Sada de processamento de dados:

Figura 1. Esquema Entrada-Processamento-Sada.

Ou seja, o jogador interage com o jogo (entrada), o qual ir processar

2015 Unidigital do Brasil

ordenada e orquestrada, sempre respeitando o tempo de cada batida

Figura 2. O esquema Entrada-Processamento-Sada como loop de jogo.

Usando uma pseudolinguagem de programao, poderamos dizer de

2015 Unidigital do Brasil

Em termos tcnicos, quem prov funcionalidades como captura

Figura 3. Especificao de um jogo dentro de uma arquitetura de 3 camadas.

Agora que sabemos como o game engine e o jogo conversam entre

2015 Unidigital do Brasil

pergunta: como estruturar um jogo?

A trade Game Design/

2015 Unidigital do Brasil

que a essncia do trabalho de um game designer so as entidades e

2015 Unidigital do Brasil

Figura 4. Ilustrando Arquitetura de Software

ou padro de projeto (dependendo do nvel em que estivermos

2015 Unidigital do Brasil

Controlador ou MVC. Nesse padro, um sistema dividido em trs

2015 Unidigital do Brasil

Figura 5. O jogo Space Invaders como visto pelo jogador.

Nela, podemos ver o jogo tal como ser apresentado ao jogador. No

Figura 6. O mesmo Space Invaders visto do ponto de vista do programador do modelo.

2015 Unidigital do Brasil

Aqui, estamos preocupados apenas com os aspectos abstratos de cada

Figura 7. Sequncia de nove quadros sobrepostos representando o movimento da entidade.

Este seria o nvel de implementao do modelo, no qual ele se

2015 Unidigital do Brasil

o prncipe dentro do modelo e faria isso:

Figura 8. Os mesmos nove quadros com os respectivos sprites sobrepostos.

A viso, portanto, ficaria responsvel por capturar o estado do

Figura 9. O controlador dentro do esquema geral do MVC.

2015 Unidigital do Brasil

Perceba que o controlador recebe qualquer tipo de entrada de usurio,

Exemplo prtico: Pong

Figura 10. Entidades de jogo.

Agora que sabemos quais so as entidades, podemos determinar as

2015 Unidigital do Brasil

Figura 11. Relaes entre as entidades de jogo.

O que estamos fazendo determinar o modelo de domnio do jogo,

2015 Unidigital do Brasil

Figura 12. Relao entre controlador e modelo no Pong.

Perceba que o controlador gera mensagens ao modelo, mas o modelo

Figura 13. Incluso da viso no esquema MVC do Pong.

2015 Unidigital do Brasil

Perceba que a viso possui elementos semelhantes ao modelo, com cada

Figura 14. Verso mais detalhada do esquema MVC do Pong.

Desta vez, criamos dois objetos dentro do controlador: um Gerenciador

2015 Unidigital do Brasil

o Controlador do Jogo se relacionam formam um padro de projeto

2015 Unidigital do Brasil

O que vem depois disso?

2015 Unidigital do Brasil

2015 Unidigital do Brasil

Вам также может понравиться