Arquivo da tag: Game Design

Game Design (3) – Prototipação do Level Design: Como fazer?

Publicado em por

Reparou que os jogos se baseiam levels ou mapas? Essa é a parte essencial de um jogo, seria propriamente, o jogo. Mas desmiuçar essa parte torna o conceito de Design de Games mais fácil de ser entendido, uma vez que nós somos enganados pelo tempo de que fazer games consiste em programar em C++, não é mesmo? E temos diversas funções em um equipe de desenvolvimento games. Por isso, o mapa ou level é projetado por quem? Game Design. Vamos entender esse detalhe neste artigo.

LEVEL DESIGN: UM PAPEL MAIS FOCADO ATUALMENTE.

Há muito tempo eu pensava que ser um programador me levaria para os campos de projeção de games. Porém o que não te falam é que a parte de implementação de código se refere a um profissional da área de T.I com especialização em games. E nós todos queremos ser como Hideo Kojima e Shigeru Myamoto, Lead Designers, o que nos remete a pensar com projetistas e não codificadores.

Antigamente, anos 90 para baixo, era compulsório que um criador de games fosse habilitado em alguma linguagem de programação. Mas essa informação hoje cai por terra, quando que você tem GE (Game Engine) que possibilitam a criação de games utilizando apenas a funcional interface e a programação visual (que para exemplificar) temos o Blueprint do Unreal Engine que dispensa o uso integral de saber C++. E que lhe permite fazer títulos com um gráfico exuberante e ferramentas profissionais.

Hoje a resposta seria, depende de qual área você está optando. E em especial, depende menos ainda por ter um codificador no grupo ou como conhecimento primário para fazer games. E partindo para este conceito, quem será que faz os mapas e levels de um jogo? Como antigamente as coisas eram menos acessíveis, normalmente em C++, Assembly, Java e Basic. Hoje você opta, pode fazer sem mexer em nada apenas se preocupando com o design do jogo.

MAPAS.

A teoria de jogos permite pensar que temos que elaborar um mecanismo que funcione visualmente. Um puzzle para abrir uma porta e finalizar a fase. Vencer um monstro, achar um elemento chave, coletar moedas. Um sistema de recompensa que nos permita quantificar a diversão do jogador e que de orientação para dentro de um conceito de ‘segundas metas’.

PARA TUDO.

Level Design não era apenas a parte gráfica? Não, Level Design é um conjunto da estética e da funcionalidade. E a segunda é a menor importada a essa função, porque todo mundo pensa em Design como sendo ‘gráfico’ sempre. E pensam em Photoshop, Blender. Porém em nossos artigos de Game Design 1 e 2, falei que Design é um projetista, ele pensa no visual e em como a lógica vai ocorrer, sim o que você pensaria que era o trabalho do programador, é na realidade ‘desenhado’ primeiro pelo designer.

O que temos dentro de um LEVEL DESIGN?

  • Lógica da IA do cenário;
  • Lógica da IA dos personagens;
  • Mecânicas do jogador;
  • Obstáculos do cenário;
  • Objetos dinâmicos e estáticos;
  • Sistema de recompensa: Vitória, pontos, bônus;
  • Sistemas de ‘retenção’: Easter Eggs, fases secretas;
  • Tela de avisos: Como as regras vão funcionar, que level é, do que se trata, como foi o resultado do progresso (Conseguiu ou não conseguiu);
  • Splash de apresentação do Level e do jogo em geral (Menu Principal);
  • Tutorial para ensinar o básico e o avançado;
  • Estrutura do Tutorial;
  • Conceito estético e funcional;
  • Design dos elementos de identificação;
  • Definição de modo de jogo: Trial, Luta, Puzzle ou Hide-seek.

Viram quantos elementos? E cada um desses se subdivide em outros itens que são ‘estourados’ em grupos de análises cada vez mais específicos. Vamos considerar um deles para vocês entenderem. Mecânicas do jogador. Seriam os controles e a interface de abordagem de interação do jogador (humano). Então podemos considerar o seguinte:

  • Controle básico de movimento do personagem;
  • Possibilidade de agachar, pular, esgueira (lados e cima);
  • Usar obstáculos como defesa;
  • Usar objetos de forma ofensiva;
  • Ou apenas usar objetos por interação ‘livre’;
  • Animações atribuídas aos movimentos específicos;
  • Reações do jogador diante de ações de NPCS e Cenários;
  • Impedimentos: Colisões, Noclip, Nofly e constraints (limites do jogador).

Até aqui você teria pensado, nossa isso não era a função do programador? Na realidade temos uma visão bem mais clara desses papéis hoje com mais informações do que nos anos 90 e começo dos anos 2000. Que tudo se resumia a ser programador. Mas com as tecnologias que investem mais em Low Code ou NO-Code a parte de Design se tornou mais clara e óbvia.

Agora para tornar isso ‘funcional’ e ‘existente’ no game, quando disponível e necessário, o programador entra em ação. Mas munido de uma documentação gerada por um game design nestes tópicos que vimos. Vamos ver outro ponto que podemos considerar ao criar MAPAS.

MAPAS OPEN E SETORIAL.

Open World é um tipo de level que eleva-se a escala expansivo para criar a sensação de viagem e duração de tempo na experiência do jogador. Em alguns jogos isso funciona, como por exemplo: Horizon Zero que onde os biomas se transformam conforme se caminha, oferecendo diferentes ‘limites’ e experiências específicas de áreas. Mas se torna entediante se criarmos um mapa onde a interação não ocorre e apenas há ‘clones’ por todos os lados agindo igual.

Setorial é o tradicional game linear, não exatamente apenas ‘de ação’, Podemos ter jogos setoriais com liberdade de abordagens como é o caso do Dishonored. Mas podemos ter ações presas ao roteiro e lineares como é o caso do Half-Life 1 e 2.

No entanto temos que prestar atenção no seguinte:

  • Mapas open são só bons se oferecerem liberdade e permissão de uso do ambiente como parte do jogo e não como bound (limites) quando convier a mecânica do jogo. Como acontece em muitos jogos em que se você sair da zona de missão, ela falha. Ou quando em uma perseguição, se o perseguido se distanciar muito o jogo também falha;
  • Mapas Setorial tem mais controle pois estamos lidando com um limite de ambiente proposital, e há menos coisas para se preocupar e sabemos que há cantos e lados definidos. Por um lado permite um controle de criação, mas pode não ser o suficiente para o tipo de jogo que você pensa em fazer.

MODOS DE JOGO.

É uma forma ‘lidar’ com a mecânica de finalizar um level. E de quantificar a recompensa. Todo jogo pensa na mecânica simples: Ponto A para o ponto B. O que acontece em A para B ocorrer é o modo de jogo. E ele representa mudanças e criações específicas na fase para ocorrer. Vamos entender isso de uma forma mais ‘listada’:

  • Começo da fase: Respawning do jogador (Como ele vai entrar, vai ser teleportado do nada, vai se apresentar, em POV, em TPS?);
  • Durante a fase: Mecânicas do modo de jogo como o Puzzle, Lutar, achar ou esconder?;
  • Fim da fase: Como o jogador vai entender que passou de fase?

Durante a fase é o conceito do Modo de Jogo:

  • Puzzle é um formato que permite exploração do cenário por uma resposta que resolva a questão do enigma;
  • Luta é um formato que exige a eliminação de inimigos do cenário;
  • Procurar é um formato que exige a exploração do cenário a procura de um item;
  • Esconder é um formato de furtivo que impede do NPC achar o jogador e o uso do cenário como obstáculo;
  • Misto um pouco de cada modo.

Desses modos temos alguns exemplos:

  • Puzzle (Resident Evil, Portal, Soma, Quantum Conundrum, The Turing Test)
  • Luta (Tekken, Monster Hunter, COD, Phantasy Star)
  • Procurar (Call to Tchulhu, Narcosis, Everybody gone to Rapture)
  • Esconder (Outlast, Dead by Daylight, Amnesia)
  • Misto (Ghostwire, Fallout, Witcher 3, Chernobylite, Hogwarts Legacy)

Game Design (2) – Precisa ter conhecimento de GE?

Publicado em por

DEBATE SOBRE CONHECIMENTO E TÉCNICA.

GE é a sigla de Game Engine (Motor de Jogo), um software que agrega bibliotecas de física, gráfica, mecânica, personagem e mundo 2D/3D que pode ter um editor visual ou não, e pode ter suporte para linguagens de programação, apenas ou não. podemos compreender como um programa que cria jogos ou experiências interativas. E será que o GD (Game Design) precisa ter conhecimento de GE? Vamos lá.

Precisa, mas não no aprofundamento que se trata software, requisitos, área de codificação e linguagens. Essa é a parte que você precisa compreender, GD não lida com programação. Ele é a parte que concebe o projeto do game e precisa pensar em muitos detalhes do que unir outra área que é tão complexa, porém muito diferente. Uma lida com o processo criativo e projetista e a outra com a implementação e campo técnicos de informática. São duas profissões distintas para completar a explicação. E vimos isso bastante no artigo 1 dessa série.

Mas o GE é o framework que dará suporte para a criação do GAME, e o Game Design vai precisar de ter conhecimento das que existem e ver o que pode lhe oferecer. Por exemplo que é importante fazer leitura sobre quais existem e o que é necessário para fazer algo com elas. Será que é possível mexer com elas e ter o resultado que deseja sem precisar de uma mão de obra especializada? Ou é preciso? Do que se precisa para definir quais os pontos temos que levar em consideração.

GD é um especialista em projetos. E com o foco em games ou experiências interativas. Ou seja podemos conceber que ele é um Especialista em projetos de games e experiências interativas. Levantar recursos materiais que farão parte do projeto é uma etapa importante. Então é preciso ter conhecimento sobre o que a ferramenta permite, mas não de forma técnica. Precisamos separar isso aqui. E vamos ver do que se trata ter conhecimento, mas não técnico.

CONHECIMENTO.

  • Entender a funcionalidade (e não como funciona ou aplica) como um recurso que permita realizar o que foi desenhado. Um GE que seja capaz de simular a física realista de trincar vidro. Uma leitura superficial permite compreender se há ou não.

TÉCNICO.

  • A funcionalidade da física de trincar vidro como funciona? Aspecto de cálculos? Qual seria a linguagem mais apropriada para lidar com motor de física desse tipo? Gerar testes e experimentações visuais para cada situação. E criar algoritmos específicos para a solução do projeto em si.

O GAME DESIGN vai se preocupar com o CONHECIMENTO. Essa ferramenta tem isso. Ok. Não tem, vamos continuar a procurar. Se acharmos, quem vai entender como o processo funciona e quais as opções que podemos ter a mais? O programador.

Vamos compreender o lado do programador aqui, pois no nosso artigo 1 definimos muito bem essas duas áreas que são muito confundidas e sobretudo confusas também. Pois o GD lida com a concepção do Level Design como as mecânicas vão funcionar na fase e o programador meio que vai por esta linha, e esses dois se encontram. Mas uma coisa é você “desenhar” e “arquitetar” como a mecânica vai funcionar, outra é você implementar a mecânica.

São fases de planejamento e execução. O programador ele não é uma parte criativa, não digo que seja não imaginativo. Mas dentro do escopo do projeto, ele é o executor do plano. É como se olhássemos para um mapa e fossemos até o ponto com o X marcado nele. Vamos ver os papéis desempenhados aqui. Quem desenhou o mapa? E nós, somos quem nesta história? Se optamos por ler o mapa e ir até o X teremos que aprender técnicas e exploração, sobrevivência e leitura geográficas.

O segundo tipo, que seríamos nós neste caso, executaríamos o plano tendo conhecimento técnico para tal. Quem construiu o mapa tinha outro tipo de conhecimento técnico, provavelmente de interpretação histórica ou desvendar de pistas, porque ele de fato tirou esse mapa de algum lugar. Mas o sobrevivencialista que vai procurar o X no mapa terá outras habilidades que quem desenhou o mapa, que pode ser um historiador, filósofo se diferenciam por meio de pilares de conhecimento. Compreenderam?

O programador não é ausente da criatividade, mas normalmente ele executa o que já foi desenhado. E se sair daquilo pode ser que tenhamos um pé no lugar errado, uma mão de zebra no lugar de um braço de pessoa. E há outros pontos a ser considerado quando pensamos em implementar e projetar. Duas áreas diferentes demais. E há uma máxima, até muita antiga, você não executa ao mesmo tempo que você planeja.

COMO O GD PRECISA ENCARAR O GE?

Diferente do programador, ele e não vai atrás de GE que são unicamente codificadas. Como por exemplo o PYGAME, PANDAS3D, Ogre3d, Unity. Ele vai atrás das que dispensa as linhas de código, que possui parte funcional e quase pronta, senão pronta das aplicações. Como Unreal, Godot, Rpg Maker. Sabendo disso, o primeiro ponto é aprender a mexer com o Software, ou seja, ler o manual. Depois é compreender os recursos, mesmo que tenha que ler alguma tecnicidade, é provável que isso será importante.

Por exemplo, GODOT tem o lado funcional, não precisa programar. Basta mexer como se fosse um Photoshop. Mas há mutas ferramentas que são convencionadas da programação. Como nós, Classes, Objetos. Então muitas vezes o manual faz analogias as classes da programação para o uso do conceito que o jogo cria. Todos os jogos são criados com o paradigma de POO (Programação Orientada a Objetos), a lógica é que tudo que tem no jogo é um OBJETO.

Faz sentido. Então essa ideia precisa ser absorvida. Mas não é preciso ou tão intencional, buscar conhecimentos avançados em POO para tal entendimento. Essa compreensão é como uma linguagem do GE. E não é tão complicada de entender com o material fornecido. O foco do GD não é como a GE processa, mas se processa o que ele tem em mente. GODOT consegue criar jogos do tipo plataforma, puzzle, primeira pessoa, nave, jogo medieval, cyberpunk? Consegue importar modelos 3D de suíte terceira? Essa física de trincar vidro tem? Como isso funciona, a mecânica, a engenharia por trás, isso é a parte do programador.

Mesmo aqueles que se aventuram a aprender sobre conceitos mais profundos, sugiro evitarem se perder. A linha de conhecimento técnico de projetista e programador é bem fina. É fácil você começa com Level Design e terminar o dia programando em Java. Porque eles são muito próximos. Mas onde um termina o outro começa. Então ao olhar GE, olhem os recursos em sua documentação. Se começar a ficar muito programacional, e tiver menos formas de compreender os recursos, sugiro mudar de GE.

COMO FUNCIONA O MERCADO GD PARA GE?

Você imagina. Pensa se a GE existe para o que você imagina para depois. O mercado de GD com GE é simples. Normalmente você tem uma equipe de desenvolvimento que vai procurar formas de criar soluções para o projeto elaborado. Se não houver solução pronta, vai ser criado. Muitos GE foram criados a partir de necessidades de projetos. Por exemplo, a maioria das pessoas gosta de fazer jogos de construção de base, defesa de torre, RPG de slash\loot, gosta de jogo de carro. Então não é muito complicado que as GE do mercado ofereçam tais respostas.

Mas se quiser elaborar mais do que isso, pode ser que criar uma GE própria seja necessário. Foi assim com Kojima Productions ao desenvolver o Decima. Ou Frostbite. Mesmo os GE conhecidos como CryEngine, Havok, tiveram seus dias iniciados por uma necessidade de projeto. Mas não é o GD que inicia essa solução, ele precisa de um programador para fazer isso. Não queira perder seu tempo em estudar programação para criar GE, é bem mais complexo do que você imagina.

Game Design (1) – O que é?

Publicado em por

VEM PARA LEITURA, PORQUE VOCÊ VAI DESCOBRIR QUE PENSOU ERRADO O TEMPO TODO.

Uma nova categoria – “Game Design” para tratar de assuntos desse campo, que é pouco conhecido, no entanto acredito que esse pouco conhecido tem dois gumes. Que é exatamente o que quero constar no artigo. O primeiro é que pouco conhecem as funções do GD, e ao mesmo tempo, talvez seja o que mais as pessoas querem ser quando se trata de Game Dev. E acabam muitas vezes dando voltas até acertar o alvo. Vamos lá.

Todo mundo quer criar jogos? Acredito que todo mundo que gosta de um jogo acaba se inspirando e querendo reproduzir o jogo aos seus moldes. E isso acaba provando dois pontos. Ou você quer ser gamedev ou quer ser game design. Não é bem claro, mas todo mundo que lê sobre criar jogos, percebe que tem que aprender uma linguagem de programação, aprender bibliotecas gráficas, ser designer e roteirista. Isso se não for trabalhar em equipe e caberá aprender uma dessas áreas em particular.

Mas sempre nos condicionamos que o único caminho é ser programador. Não estou certo? Pois é, esse é o grande epílogo, pois na realidade pelo o que a gente sabe, a maioria das pessoas deseja ser game dev, mas na hora de perceber o conceito de criar jogos, descobre que tem diversas áreas que atuam em uma criação de jogo, e existem como funções, e não como campo teórico. E aí as pessoas se redescobrem.

CRIAR GAMES NÃO É EXATAMENTE PROGRAMAR.

Como se sabe, nem tudo em um jogo se resume a programar. Na realidade você precisa ter uma concepção do game, planejamento, desenho, paradigmas, mecânicas, gráficos, público, recepção, retorno, o perfil dos personagens, os gatilhos, o level design. Acredita que todos esses campos não são funções de um programador? Exceto aqueles que fazem o game sozinho e acabam misturando essas áreas em uma só. Todas essas funções tem cargos diferentes e nada tem haver com aprender C++.

Já se perguntou o que Hideo Kojima faz nos jogos? Se respondeu programar, vou pedir para repensar. Vamos mais uma tentativa. Se respondeu de novo programador. É por isso que esse artigo foi escrito. Não. Hideo Kojima, Shigeru Myamoto não são programadores. São Lead Designers. Que é isso? Designer Líderes ou seja Game Designers. Esse nome é sob a função de chefe de departamento. Eles são os responsáveis por conceber o game.

Eles lideram todas as equipes. Ilustradores, engenheiros de som, roteiristas, MOCAP, história, level design, personagens e por aí vai. Um rápido teste, vocês sabem algum nome de algum programador do Metal Gear Solid? Ou do Death Strading? Algum do Horizon Zero Dawn? Witcher? Skyrim? Mas você com certeza deve conhecer esses nomes:

  • Pawel Sasko (Lead Designer de Cyberpunk 2077)
  • Hideo Kojima (Lead Designer de Metal Gear Solid, Death Strading)
  • Shigeru Myamoto (Lead Designer Zelda, Super Mario)
  • Michiel van der Leeuw (Lead Designer e Diretor Técnico de Horizon Zero Dawn)

DUAS ÁREAS MUITO DIFERENTES: GAME DESIGN X PROGRAMADOR.

Agora pensa no seguinte. Todas as vezes que vamos pensar em GAME DEV, o que a gente mais pensa? Em como o jogo vai ser? É isso? E depois a gente planeja como os conceitos irão atuar na franquia. Paradigmas, concepções visuais e funcionais. Bem é óbvio que quem for fazer um game sozinho, vai ter que ocupar todas as funções. Mas a maioria das pessoas que se engaja em criação de games volta com a mão abanando justamente por entender que:

  • Programador pensa em: Tecnicidade de hardware e Software, programação, implementação e não se envolve na maioria das vezes nas soluções de criação. Não tem quase ou nenhum visibilidade na publicidade do projeto e tem menos chance de estabilidade trabalhando para outros e precisa pensar em ser empreendedor, para o ‘sonho’ dar certo; (LITERALMENTE UM T.I)
  • Game Designer pensa em: Concepção do projeto do game, características, personagens, artes conceituais de locais, personagens, eventos, gatilhos, level design, audio design, publicidade, venda, distribuição, dlcs, mecânicas, design dos personagens (Tanto visual como funcional). Possui uma participação significativa no projeto, geralmente é o gerente do mesmo e normalmente tem uma autoria no game. (LITERALMENTE O CRIADOR DO GAME)

Essas características vão servir para entendermos uma direção interessante, pode te ajudar. Nós quando queremos criar games, CRIAR, queremos projetar o game. Não implementar, ou seja PROGRAMAR. Quem já se aventurou por GE (Game Enginer, motor de jogo) que só tem codificação e não um editor visual como Unity, Unreal, Godot, já percebeu que passa a maior parte do tempo tendo que ler documentação de código. A parte criativa fica para bem depois. E se você sofre da impaciência com essa parte, é um sinal que você não quer ser o PROGRAMADOR e sim o DESIGNER.

Talvez até não o DESIGNER, pois essa área pode não ser sua profissão também. mas se for, pode ser que esteja criando confusão. Programador é um profissional de T.I que vai implementar o que um projetista elaborou que é um profissional de artes visuais, design gráfico ou industrial. Note que essa é uma realidade prática do mercado e não uma teoria extraída de um livro. E grande maioria das pessoas que querem desenvolver GAMES, veja que não estou totalizando, mas é uma grande amostra, querem é PROJETAR O GAME. E não programar ele.

Muitos criadores de GAMES hoje são DESIGNERS. Não sabem programar uma linha sequer de código. E fazem uso de ferramentas que possibilitem eles dispensarem essa parte. Que é o caso das GE que são funcionais e possuem editores visuais, como:

  • Godot;
  • Unreal;
  • Roblox;
  • Unity; (Em parte, pois é obrigatório programar em C#)
  • CryEngine;
  • RPG MAKER.

Por isso é bem fácil de compreender porque alguns criadores de games, conseguem em 3 anos, desenvolver projetos sozinhos. Se fosse ter que fazer um roadmap de programador, esses anos seriam bem mais. Acontece que a funcionalidade dos programas hoje e a distribuição massiva de scripts é bem democrática e acessível. Logo é menos problemático criar linhas de código, se for necessário.

DE ONDE SAIU QUE CRIAR GAMES É PROGRAMANDO?

Então a filosofia de criar jogos se firmou que todos deveriam programar em C++ ou Java, por ocasião dessa dificuldade que havia nos anos 90. Não tinha informação, não eram GE acessíveis, eram proprietárias, a tecnologia era restrita, era mais difícil conseguir implementar. Então a ideia de criar games permaneceu que devemos saber alguma linguagem de programação. E a história pode ser muito diferente, pois dois motivos:

  • Nós, em maioria, queremos projetar o GAME. E pensamos que a linguagem de programação é o caminho.
  • Acessibilidade atual é bem maior tornando dispensável a programação em muitos casos e o foco no Game Design.

Então, até aqui o que aprendemos?

  • Que talvez nossos objetivos sobre criar GAMES se resuma a parte do PROJETO de Games do que na programação de Games;
  • Que Game Design é mais famoso, mais envolvido no projeto, é normalmente o gerente dele, é a parte criativa e comercial;
  • Que Game Dev é menos envolvido no projeto, normalmente implementa o que foi pensado e está envolvido na parte técnica de informática do que na concepção do game;
  • Que temos uma percepção um pouco distorcida dessa área, e pensamos em querer ser criadores optando por um caminho que achamos que vai nos levar para lá;
  • E confundimos o conceito de GAME DESIGN com GAME DEV.

E o que é GAME DESIGN?

Já falamos exaustivamente durante todo esse artigo. Mas preferi fazer uma comparação e trazer também o ímpeto que muitos de nós temos ao querer trabalhar com criação de games, e nos confundimos com esses conceitos. Mas como a pergunta do artigo é – “O que é?”. Nesta conclusão podemos descrever o GAME DESIGN como o CRIADOR DO GAME.

E podemos também definir que, nós de forma equivocada, definimos como desenvolvedores em um termo mais comum do campo Dev (Developer, ou seja desenvolvedor programacional) como GAME DEV. E achamos que as palavras como PROJETAR, IMPLEMENTAR, PROTOTIPAR, MECÂNICAS, CARACTERÍSTICAS, LEVEL DESIGN, EVENTOS, IA, NPCS, NARRATIVAS se resumem ao programador. E estamos errados.

Estamos errados porque ao pensarmos assim, vamos fazer a trilha do programador e não do designer. O Design tem por etimologia (origem do significado) do inglês – desenho. Que podemos adaptar para o conceito de projeto. Ou seja, o desenho do game é o projeto do game. O processo de criação. Quando a gente joga um jogo como o Horizon Forbbiden West, nós olhamos com um olhar críticos esses detalhes:

  • Mecânica;
  • Aloy e NPCS;
  • Cenários;
  • Questão visual e funcional;
  • Inventário;
  • Árvore de habilidades;
  • Eventos;
  • Bugs;
  • História;
  • Escolhas e mudança de caminhos;
  • Personalização;
  • Contexto.

Mas já parou para pensar que a gente não pensa qual seria o melhor caminho em programação que resolveria ou melhoria alguns desses pontos? Ninguém pensa que a chamada de uma biblioteca melhoria o desempenho do game e nem qual linguagem de programação seria ideal para cada tipo de item listado. Originalmente pensamos no conceito de projeto e design de cada item, no planejamento. Não pensamos em campo científico de informática. Pensamos em criatividade e ideias sobre o projeto.

E nós quando queremos criar GAMES, pensamos como DESIGNER, desejamos trabalhar como DESIGNER, mas optamos por aprender programação no lugar de DESIGNER. E apesar de programação ser a parte que torna os elementos pensados e criados em uma funcionalidade, hoje não necessariamente precisamos de um programador. Ou seja você não precisa ser um programador, mas precisa ser um DESIGNER.

GAME DESIGN é o autor do game. Por si só, o desenvolvedor do game. E assim, o GAME DEV.