Baby Game Engine

Um bébé é um sistema complexo, como um game engine e como um game engine tem coisas boas, coisas más e bugs. Aqui fica a minha apreciação, após 16 dias de teste do Baby Game Engine.

Máquina de estados: perfeita! É excelente, quando tem fome chora, quando está satisfeita sorri. Quando quer cagar chora, quando já cagou sorri. Quando está nua chora, quando está vestida sorri.

Interfaces: muito bugged. Já me disseram que a maturidade da plataforma, lá para os 30 dias de teste melhora imenso os interfaces, mas neste momento fica parada a olhar para nós, como quem diz: "Não conheço essa instrução" ou, em na linguagem deste game engine "nhé".

Os eventos também estão meio quinados. Por exemplo, se as dependências forem: mama, mudar a fralda, dormir, muitas vezes passa da mama ao dormir.

Fora isso é o melhor engine do mundo...

Nasce o Spoing

Tal como prometido, no aniversário do Blodasse, nasceu hoje o meu novo blog. De seu nome Spoing, fala do bom, do mau e do feio do desenvolvimento de videojogos.

Espero que gostem e juntem-se ao Spoing Movement!

Orion's Belt - Design Inteligente

Tive a oportunidade e o prazer de falar com o pessoal do Orion's Belt sobre a nova versão deste excelente webgame e não pude deixar de ser assaltado pela ideia tanto melhor é o design, quanto mais sólida é a equipa. Isto seria fácil de provar numa equipa com designer e embora não concorde com a inexistência explicita de um, a equipa do Orion's Belt prova que é possível e suficientemente sólida para concretizar.

Identifiquei alguns pontos que tornam isto possível:

Investigação

Normalmente a investigação para um jogo é realizada em jogos do mesmo género. No caso da nova versão do Orion's Belt, cada um deles trouxe a sua própria experiência de jogos em nada relacionados para o universo que estão a criar. Isto está longe de ser a velha discussão "designer vs. player" a renascer, muito pelo contrário. O que fizeram não foi importar ideias, foi descrever fórmulas e conceitos funcionais de design e confrontá-los com necessidades e ideias.

Partilha de informação

Mesmo que discordem entre si, colocam toda a informação à disposição de todos os elementos para que seja analisada e debatida. Pode parecer uma critica eu escrever aqui que por à discordância, mas eu considero isso positivo. Não há bons projectos sem desacordo. Se todos concordarem em tudo... a probabilidade de os jogadores discordarem com a equipa é enorme. Outra lição a reter e que vejo frequentemente entre designer wanabe's é esconder e não partilhar. Aprendam com a equipa do Orion's Belt: partilha trás força.

Ênfase no jogador

O jogador, a sua experiência, a sua malandrice, o seu intelecto, o seu bem estar e tudo o mais que possa ser emocionalmente explorado, vai e deve ser explorado.

Um jogo é um jogo

E interfaces são uma preocupação do developer e não do jogador, ou seja, ser jogador num browser não deve limitar o interface ao comum do browser, mas também não deve ser descurado que quem joga tem uma determinada convenção que é um browser. Este é um tópico muito complexo e a atenção que lhe está a ser dada é de louvar.

Resumindo

Vai ser um projecto enorme, muito diferente daquilo que eu conheço. Nenhum é designer, todos são designers, nenhum deles tanto quanto sei está a formalizar o design e no entanto têm as preocupações de um designer. Não estão a inventar nada e estão a revolucionar a fórmula dos webgames. Isto, meus amigos, é Design Inteligente... sem designer.

Um abraço à malta do Orion's Belt.

As idiossincrasias dos Design Documents

Estou absolutamente convencido que um Design Document é um ser vivo. Nasce fruto de uma necessidade, cresce alimentando-se de intelecto, multiplica-se em testes, protótipos e iterações e quando na cadeia alimentar, os bichos maiores se alimentaram dele, morre e é esquecido apenas para dar lugar a outro de certeza diferente.

Pela parte que me toca sou apologista dos Design Documents que cumpram dois propósitos: ajudarem-me na decisão e que sejam documentos de consulta. Se falharem qualquer um dos dois propósitos são completamente inúteis.

Por um motivo que me ultrapassa, leio de tempos a tempos e por essa Internet fora, opiniões que vão contra a realização de Design Documents em equipas de reduzida dimensão. As mais comuns são que os Design Documents são inúteis antes de um protótipo e com a realização deste tornam-se desnecessários porque as decisões estão tomadas com a prova feita com o protótipo na medida em que não há assim tanta gente a quem passar esse conhecimento e que este é partilhado por todos. Outra é que os Design Documents são uma perda de tempo.

Os dois propósitos que eu julgo indispensáveis para um Design Document são a prova de que estas duas ideias não serão uma visão adulta e profissional do dito documento. Se a realização de um Design Document me ajuda na decisão, quer dizer que, já houve um protótipo e que se vai avançar com produção, mas desta vez, sem experiências desnecessárias. Elas vão existir de certeza mas serão menos. A segunda é que se é um documento de consulta, permite o acesso rápido à informação, ao próprio processo, ao que se pretende e/ou é necessário. Qualquer uma das duas bate o preconceito de ser uma perda de tempo.

Há um defeito nos Design Documents para o qual pessoalmente não arranjei solução. Como ser vivo evolutivo, o Design Document vai sofrer alterações durante as diversas iterações de desenvolvimento por motivos mais ou menos válidos. A única forma de o tornar perfeito seria conseguir prever essas alterações e penso que isso é praticamente impossível. Por isso o defeito é não haver um momento definido em que sei que o Design Document não deve entrar na fase seguinte sem iniciar o desenvolvimento.

Vlad on Game Design IX

Boas, nono "on Game Design", a minha triste colagem a dois bons livros de design. Hoje, com uma aplicação tão prática quanto é possivel numa blogada que desejo curta.

Tenho lido muito sobre design teórico (até porque não há muito mais para ler sobre design) ultimamente. Um dos tópicos mais interessantes é: o que é que faz um jogo divertido? Já vi várias tentativas de explicação, desde a listagem de elementos (muito útil por acaso) que definem o divertimento, até à justificação psico-quimica da influência de acção-lógica-feedback. Mas isto não é prático, é teórico! E o problema de tanta teoria é que não permite a cada um de nós desenvolver as suas próprias metodologias e quissá, novos elementos divertidos de design.

Não existe nada que prove esta aplicação prática. Foi retirada do livro Theory of Fun e o método que utilizo. Se querem entender a teoria por trás, comprem o livro, senão esperem que eu já ando para escrever sobre essa teoria há uns tempos consideráveis.

Sintetizadamente funciona assim: o cérebro não gosta de pensar. O cérebro gosta de reconhecer padrões e usá-los de forma a mecanizar tudo o que puder. Cada vez que um conjunto de acções proporciona a mecanização de algo, o cérebro proporciona ao jogador uma sensação de prazer.

Querem um exemplo? Pensem num jogo que gostem muito. Pensem nas metas que esse jogo vos oferece. O que é que sentem quando conseguem iniciar um processo que vos permita alcançar esse objectivo? Sentem-se felizes, certo? Ao longo do tempo mecanizam esse processo e isso traz-vos menos felicidade mas, com o devido equilibrio, alcançam esse objectivo. E aí sentem-se felizes outra vez!

Sim, o game designer é um simples passador de droga, com a diferença que a droga ja existe no organismo. O truque é ir dando pequenas doses, em intervalos cada vez maiores, mantendo o jogador interessado até ao objectivo final. That's it!

Bah! Então a parte prática?! Ok, cá vai!

Entendam que o cérebro do jogador quer mecanizar. A primeira coisa que ele tem de mecanizar é o gameplay básico do jogo. Se isso demorar mais do que 3 minutos, estão a abusar! Pessoalmente aponto para explicar o minimo possivel e a mecânica ser entendida em 3 segundos.

Depois dou-lhe 3 minutos para mecanizar. Algures nestes 3 minutos o cérebro do jogador deu-lhe uma descargazinha da droga que nós passamos. Ao fim desse tempo previsto, damos-lhe mais qualquer coisa para mecanizar. Isto pode ser um tipo novo de inimigo, um tipo novo de arma, um tabuleiro de um puzzle com uma forma diferente. As opções são ilimitadas.

Aumentem os niveis de dificuldade dos elementos (não confundir com os niveis de dificuldade do jogo, embora possam ser relacionados) em intervalos que aumentam progressivamente. Imagino que a ultima questão seja "então e quais são esses intervalos?" e é muito relevante. Muito curtos e tornam-se complicados de assimilar, muito longos e tornam o jogo aborrecido. Por isso, a resposta depende do jogo que por sua vez depende da audiência do jogo.

Pessoalmente uso uma variante a uma "regra" que li já nem sei onde: a regra dos 3. Esta regra defende que deve ser oferecido conteúdo novo ao jogador aos 3 segundos, aos 3 minutos, aos 30 minutos and so on. Claro que depende do jogo... mas é só para terem uma ideia.

Se não perceberam como se aplica esta pequenina prática de design, deixem aí um comentário e eu buzino. :)

Vlad on Game Design VIII

A maior parte das pessoas, quando absolutamente convencida de algo, defende esse algo ao ponto do absurdo. A frase anterior funciona um pouco como aquela máxima: "reconhecer o problema é o passo para a cura." Sou um acérrimo defensor das minhas convicções e ideias e disse a minha avózinha que me criou que eu devia ser advogado, dado o poder de argumentação, mas tenho uma característica que gostava que se espalhasse a toda a humanidade, uma que toda a gente diz que tem, mas que raramente vejo aplicada: dar o braço a torcer.

E é por isso que estou a escrever isto hoje. Para dar o braço a torcer.

Uma das minhas convicções em termos de game design é que devemos partir dos sistemas de gameplay, como a acção e o sistema formal de regras para o conceito e o contexto. Ou seja, dado um sistema de regras, a roupita que se põe lá em cima pode ser uma qualquer desde que contextualizada. Não haverá melhor exemplo do que os jogos de match-3. Ao mesmo sistema de regras já vi aplicadas gemas, hamburgers, roupa, etc. Mas os exemplos são quase infinitos.

Tenho defendido esta convicção por dois motivos; primeiro porque os casos em que "tive" de a defender estavam relacionados com os criadores de clones de FPS, TPS, RPG e MMORPG que , se estão a clonar o conceito é porque não sabem criar as regras; segundo (e aqui fica o meu braço torcido) sempre achei que partir do conceito era absolutamente errado porque o gameplay seria sempre o principio de tudo.

Continuo a achar que para os jogos em que o factor gameplay tem um peso maior e os factores contextuais e temáticos são relativamente direccionados para um publico mais abrangente, que a estratégia é essa: partir da acção, do gameplay, para o conceito. Tal acontece nos casuais por exemplo. Quando o gameplay é completamente abstracto, como o xadrez apesar de ser uma simulação militar, deve-se partir de baixo.

Mas para jogos fortemente temáticos ou com componentes contextuais muito fortes, um "ataque" a partir do conceito pode ser a melhor formula e SIM!, a semana passada eu não acreditaria que estava a escrever isto. Por exemplo, um jogo de grande teor cinematográfico, ou uma simulação desportiva devem partir do conceito. Simulações menos abstractas, novamente o exemplo das simulações desportivas, também devem partir do conceito.

Haverá sempre o perigo de, sendo a ideia inicial o conceito, assumir que é por aí que se deve começar. Dou-vos um exemplo, se eu me lembrar de fazer um webgame cujo conceito seja um jogo de gestão de recuros, controlo de território e batalhas num set medieval, parece que é do conceito que parto. A verdade é que vou condicionar o gameplay desnecessariamente e isso significa um jogo menor do que potencialmente pode ser.

O sistema de regras tanto pode servir para um set medieval, como para um set futurisitico. A verdade é que limitei o conceito, devido ao contexto.

E finalmente, o texto que me levou a pensar nestas questões, com o agradecimento ao Kosmic que me enviou o link. Espero que seja útil para os vossos designs.

Game Design Cognition

p.s.: hoje comecei a trabalhar às 8:22, ok? :)

Vlad on Game Design VII

Este não é um post fácil nem de escrever nem de ler. Quero que seja curto e conciso, mas só consigo provar o ponto onde quero chegar com pequenos eventos. Por isso, recostem-se e desfrutem e não percam o fio à meada que eu vou dar o meu melhor para explicar isto.

Parte I.1
Quando decidi atacar o mercado casual não fazia a mais pálida ideia de como desenvolver um jogo para esse mercado. Não me ocorria nada que não pegar nos chavões que vendiam e isso não me agradava nada. Estava a meio da minha fase "ler livros de design" e quase todos eles falavam da história dos videojogos e um deles abordou a questão de que um video game designer é uma especialização de um game designer, logo, a história a estudar deve ser a história dos jogos e não dos videojogos. A disciplina base deve ser a ludologia e não o design em si.

Parte I.2
Achei o principio absolutamente fascinante e durante um par de semanas, como preparação para a apresentação de algumas ideias, comprei jogos, mas não de computador. Fui à Toys'r'Us, ao Papagaio Sem Penas e a algumas papelarias e comprei jogos simples. Construí designs para video jogos aplicando estudo de jogos mais simples, normalmente desprezados por video game designers. Depois joguei casuais e fiz listas de features. Cruzei os dois e voilá, design de casuais com mecânicas, se não originais, pelo menos diferentes q.b.

Parte II
Há uns tempos atrás, em amena conversa com o Marco Vale, perguntei-lhe se, na opinião dele, seria possível um gajo como eu desenhar. O objectivo era tornar a tarefa tão impossível que ele admitisse que não era possível TODA A GENTE ser artista e ele respondeu-me algo do género: "Com treino, estudo e prática, claro que sim." Ao longo da conversa entendi que o importante são as bases e a prática.

Parte III
Hoje disseram-me isto "...e eu que nunca me achei minimamente original no sentido de criar e pensar em novas coisas..." sendo o contexto, design de novos gameplays. A minha resposta foi que a criatividade se treina, cultiva, educa. A sociedade moderna está toda ela apontada para a inovação constante.

Conclusão
Tal como a arte, a programação, a música, o desporto ou qualquer outra actividade que possamos considerar exclusiva ao homem moderno, também o design é uma questão de ter bases e praticar. Na minha opinião as bases fornecidas mas mundialmente aceites são erradas. Na palavra videojogo e no que toca a design há um foco total no video e pouco no jogo. Há demasiado foco no meio e pouco no conteúdo. É o mesmo que dizer que uma pintura, enquanto obra, é tanto melhor, quão melhor for a tela. Mas o que quero transmitir neste post é que o verdadeiramente importante no design é o mesmo que noutra área qualquer: boas bases, muita prática. Depois, como em tudo, sobressaem os que trabalham mais ou são simplesmente e inatamente melhores.

Vlad on Game Design VI

Acabámos aqui uma coisinha no nosso joguito e eu fiquei satisfeito. Tenho andado a matutar nas soluções quer de design quer de programação que temos arranjado. A verdade é que para primeiro projecto desta equipa, o jogo é demasiadamente complexo e esse é um facto que só nos apercebemos tardiamente. Nada que nos preocupe, está tudo a correr muito bem nesta fase.

Mas o meu propósito com esta blogada não é transmitir uma mensagem subliminar de um eventual projecto ultra-secreto. Serve mais para identificar algumas alterações na minha forma de ver design e development depois de "sobreviver" a 90% de um projecto.

Das conversas informais que tenho e de alguns posts no GD-PT concluo que a maior parte das pessoas tem uma ideia de que design é ter as ideias e documentá-las. Se na generalidade isto é verdade, no detalhe torna-se mais complicado. Isto porque a documentação tem de ser sintética e objectiva. Acredito que, e embora espere estar enganado, a maior parte dos pretendentes a game designer assumem que se escreverem num design document a generalidade de um objectivo de um elemento de design, o seu trabalho está concluído.

E se estou a escrever esta blogada é para demonstrar o oposto. Estávamos a preparar uma versão para playtesting. Existe um elemento do jogo que permite ao jogador safar-se de algumas situações complicadas. Se este elemento existir em demasia, o jogo perde o desafio. Por outro lado é um elemento bom demais para não servir como recompensa momentânea a uma boa performance do jogador. Estava estabelecido que sempre que o jogador atingisse um determinado threshold, ganhava uma unidade desse elemento. Como queríamos reduzir essa recompensa, considerei uma certa aleatoriedade, uma probabilidade de recompensa.

Estas soluções parecem-me sempre coxas. Por um lado o factor aleatoriedade ofende-me em algo tão importante e tão pouco circunstancial como recompensas porque é a recompensa que alimenta o ímpeto. Por outro precisava de uma solução que não fosse algo tão corriqueiro como "recompensa de duas em duas vezes" ou "uma recompensa por nível". Lembrei-me então da sucessão de Fibonacci, excluindo o 2 e não é preciso pensar muito para ver como pode ser eficaz para reduzir de uma forma recursiva e não aleatória. O resultado final foi 1, 3, 4, 7, 11, etc... não é bem a sucessão, mas serve exactamente o propósito.

Não escrevi nada e decidimos e implementámos uma importante alteração ao design em 20 minutos. Do lado do design não foi usada uma solução tipicamente fácil como aleatoriedade e não foi descrita como um desejo do género "o jogador recebe este elemento de vez em quando". Do lado do desenvolvimento foi escrito um gerador da sequência que é inicializado a cada nível. Resolvemos um problema de design mais complexo do que parece, de uma forma totalmente elegante e eficiente.

Há um ano atrás eu teria escrito dois ou três parágrafos sobre como seria melhor recompensar o jogador e optaria de certeza por uma probabilidade comparada com um valor aleatório. Hoje, detectado o problema, definiu-se uma solução aberta e alterável, pronta para teste sem se escrever uma linha porque o design doc não é mais importante do que a implementação do design ou a diversão do jogador.

Vlad on Game Design V

Instalei à dias o Jade Empire Special Edition. Há uma questãozinha com a instalação e fiz umas buscas na net para arranjar a solução. No meio das buscas e relativo ao jogo encontrei algures um jogador que dizia algo do género:

"The game seems too big for such bad graphics."

A minha primeira reacção foi que, só em diálogos o jogo devia ser enorme, logo a frase não fazia sentido. Além disso o Jade Empire Special Edition é uma conversão para PC de um jogo com uns anitos, ou seja, não só os gráficos não estariam ao nível dos actuais, mas os constrangimentos de espaço resumiam-se ao DVD sendo portanto natural dados os gráficos e dado o som fosse dada alguma "liberdade" na produção de som, particularmente de diálogos.

Depois imaginei que talvez uma opinião deste género possa ser relativamente comum em relação a tantos jogos.

Depois lembrei-me da frase "you are not your audience" e aplica-se. Não acredito que um jogador, por muito taralhouco, não entende-se se alguém lhe explicasse o espaço ocupado por diálogos, a questão do port para PC, etc, mas não é isso que o jogador quer. O jogador quer o jogo o melhor que puder ser e somos nós que temos de lhe fazer chegar isso às mãos.

Fazer chegar a um jogador uma obra prima da gestão de produto como o Jade Empire Special Edition e depois haverem questões que saltam à vista do jogador alvo é potencialmente perigoso.

Vlad on Game Design IV

Acordei meio aluado e decidi dar continuidade ao Vlad on Game Design. Desta vez vou tentar abordar uma questão mais técnica. O Design Document! Uma espécie de FAQ... se quiserem juntem perguntas aos comentários que eu tentarei responder.

O que é o Design Document?
O Design Document (DD, ok?) é, ou pode ser, uma série de coisas. Depende fundamentalmente do emissor e do receptor. Na sua forma mais básica, o DD é composto por capítulos ou secções que descrevem o conceito do jogo, o sistema formal de regras, o gameflow e as listas de assets a serem geridos pelo jogo. Conforme o tipo de jogo, poderá incluir outras secções como storyline, modelos económicos, interacção de sistemas, etc, etc, etc.

Como redigir um Design Document
Se procurarem exemplos na Internet, vão encontrar um pouco de tudo, desde autênticos livros ricamente ilustrados e pomposamente escritos, até documentos quase exclusivamente técnicos. Na minha opinião, a própria evolução técnica de um Game Designer mistura-se com a evolução dos seus DD. Os primeiros que fiz eram extremamente descritivos, texto, texto, texto, muita formatação, etc. Neste momento inclino-me para descrever o menos possível e esquematizar o mais possível. Penso que, e é uma opinião relativamente generalizada, o DD é um documento de consulta, não de leitura. Assim, o uso de listas, gráficos e esquemas, tudo enquadrado num documento perfeitamente formatado é a melhor forma. Quem o consulta espera recolher informação.

Um Design Document deverá conter detalhes técnicos?
Esta é uma questão muito complicada e embora o contexto não seja claro, normalmente depreendo que entende-se como detalhes técnicos, algo relacionado com tecnologias de programação e conteúdos. Nas grandes empresas de desenvolvimento de jogos não havia Design Document, havia Design Documents, plural, porque havia um Game DD, um Technical DD entre os quilos de documentação. Aquilo que eu defendo ser o Design Document é o Game Design Document, não havendo neste qualquer referência a tecnologia, excepção feita (no meu caso) à indicação do engine usado. Essa referência pressupõe que se sabe onde ir buscar documentação sobre o mesmo.

Quando começar a escrever o Design Document?
Na minha opinião, a partir do momento em que se tem uma ideia do sistema formal de regras que mereça um prototipo.

Quando é que não se deve começar a escrever um Design Document?
Quando se tem uma storyline, uma ideia para o ambiente ou qualquer outro erro intrinsecamente newbie. Ambientes e storylines são fantásticos para escrever contos, livros, etc... não para definir gameplays.

Quando é que um Design Document está pronto?
Quando o desenvolvimento do jogo estiver terminado. Um DD é um documento de consulta, logo é perfeitamente natural que esteja em edição constante.

Bottom-line: Para que é que eu vou escrever isso?
Para tomares decisões, para guardares informação, para reveres o teu próprio raciocino, para poderes partilhar trabalho, para saberes para onde queres ir, para seres coerente, para não andares a inventar features durante 1 ano e não fazeres uma linha de código, mas principalmente para te ajudar a pensar.

Boa sorte e bons jogos.

Vlad on Game Design III

Recebi por mail um link para uma tese sobre Game Design e/ou New Media. Admito que não sei ao certo, já explico o porquê.

O índice faz prever um texto estruturado e uma abordagem refrescante. Abro o capítulo I e no primeiro parágrafo encontro as palavras "cultural patterns" e "design patterns". Aparentemente alguém decidiu escrever um tese sobre "nada de novo". Continuando a exploração do capítulo introdutório deparo-me com as mesmas referências aos mesmos livros que os outros livros tomaram como referência para se tornarem referências aos livros futuros.

Confuso? Admito que sim, mas não consigo deixar para trás a ideia de que os Game Design Theorists querem impor a sua fórmula e que a discussão está fechada aos outros. Logo, como é possível estabelecer tantas referências sem que exista ainda uma base formada que eleve o game design ao próximo estágio?

Vou continuar a ler o texto, mas faço-o já com um pé atrás. Se entretanto provar ser algo diferente, eu posto aqui o link.

Vlad on Game Design II

Escrevo este post porque me encontro numa encruzilhada em termos de design. Por um lado sinto que é possivel colocar em prática e de forma metódica a teoria avassaladora que existe. Por outro, essa colocação em prática parece ser subjugada para segundo plano, porque ser teórico dá status e porque a prática poderá por a nu a verdadeira fórmula de design de um jogo. Por isso só vejo duas maneiras viáveis de se encarar o game design nos dias de hoje.

A primeira é continuarmos a ver o game design como o produto de génios, os que teorizam incessantemente em livros com conteúdo similar, mas com terminologias distintas. Aprende-se muito com eles, é indiscutivel, mas ao mesmo tempo ficamos um pouco afogados na teoria ao ponto de tentarmos teorizar nós próprios. Não nos é passada a metodologia prática. E se vierem daí tresloucados a dizer que há livros que o fazem... leiam-nos outra vez e vejam lá se a metodologia de design que é passada não é ela também teórica.

Os game designers não se entendem, ou melhor, não chegam a uma plataforma estável de entendimento. Desde que se começou a tentar unificar o game design que se criou uma teia entre concordâncias e discordâncias entre os game design theorists. Essa teia estende-se claro, aos game designers "comuns". No meio desta teia e desta teorização massiva de tudo o que tem um cheirinho a game design, alguém se esquece da prática de game design. Há tanta coisa que qualquer programador nos sabe responder e que faz parte do design, mas nós designers, mantemos o nosso cu gordo sentado na cadeira da teoria absoluta.

Blodasse... já está na altura de sair da cadeirinha não? É que já chateia... Qualquer pessoa que leia um bom livro de game design parte do principio, mesmo sem prática, de que é game designer. E nem me façam falar dos que não leram nada, ok? Esse só mesmo à pedrada, Monty-Python Style!

A segunda maneira é aquela que sinto mais próxima da minha forma de estar. Game design estar para para um game designer, como a programação está para um programador. Conhecimento teórico, conhecimento prático, experiência. Se só com estes três juntos há um programador com qualidade, porque raio é que conhecimento teórico é suficiente para game design? E porque é que o conhecimento prático não é partilhado? Será que há assim tanto medo da concorrência de futuros game designers ou será que não queremos sair da cadeirita? Será que é porque tantos míudos querem fazer game design?

Amigos, deixem os míudos fazer game design, mas ensinemo-los a fazer game design na prática! Dá tanto trabalho quanto outra coisa qualquer, o que quer dizer na prática que 90% desistem no primeiro ano e que só vão sobrar aqueles com quem quereremos trabalhar no futuro.

Vlad on Game Design

Se, Chris Crawford, Edward Rollings e companhia têm notas sobre game design, porque é que eu não hei-de ter?

Estava para aqui a desfolhar livros à procura de uma frase para um tutorial que estou a fazer. Tropecei numa que é absolutamente brilhante.

Complete amateurs whose only relevant skill is programming undertake to design games with no further preparation than their own experience as game players. Those who overrate their own understanding undercut their own potential for learning.

by Chris Crawford in The Art of Computer Game Design

E 'tá tudo dito