Arquivo da categoria: Design Grafico

Categoria voltada para design como Gimp e Blender.

Tutorial Blender – Como fazer relevo usando o recurso Displace?

Publicado em por

Foi publicado no canal da Junca Games na Playlist “Blender – Tutorial” usando os recurso do Displace Map. E também no vídeo vocês podem conferir como faze a textura para criar o map Displacement, como texturizar, como fazer iluminação atmosférica (ou iluminação realista) e como funciona o displace na prática, para ser aplicado a qualquer situação.

Programas utilizados:

Blender (versão 3.3.1);

Gimp (versão 2.10.34);

Textura (baixada do Pinterest) – Palavra-chave “Map Terrain canyon”

E caso aproveitem, dê sua curtida e inscrição no CANAL. Junca Games é uma iniciativa criada em 2019 e que faz parte do Mundo Pauta (criado em 2012).

Pílula de Marketing (113) – Não existe ‘desenvolvedor’ Front-End.

Publicado em por

Contextualizando.

  • No Material extra no final deste artigo, eu escrevi um anterior que fala sobre “Front-End: Uma área de Design ou T.I? está com um ( * ) para notificar um ponto de vista, que deixei explicado no tópico depois desse “Contextualizando”.

É uma mega provocação. Mas não é apenas uma provocação. É uma constatação. Desenvolvedor e projetista são áreas diferentes, que podem ser aplicadas a um mesmo campo. Mas tudo poderia ser resolvido no caso deste artigo, se Front-End não fosse Front-End e sim Webdesign. E vamos lá, porque você vai se interessar por este artigo, mesmo aqueles que vieram pelo título provocativo procurando revidar. Mas antes, leia, porque isso é mais do que uma mera ‘briga’ e sim uma ‘revelação’.

Há 20 anos Front-End, Back-End e Fullstack não eram reais, não existiam. Não tinham esse nome. E apesar e parecer sinônimos quando assumiam um outro nome, respectivamente Webdesign, Webmaster e ‘projetistas de website‘, eles possuem algumas diferenças que podem impactar inclusive sua escolha de como se capacitar e como se portar diante do mercado. Durante a pandemia de 2020, vagas de Front-End brotavam. Gurus diziam que era um campo fértil. Surgiram candidatos e interessados pelo ladrão. E nada podia impedir isso.

Muitos se consideram, aqueles que atuam como Front-End, desenvolvedores. Por aí sabemos que há uma deturpação de área. Desenvolvedor é quem programa, que desenvolve um programa, que realiza uma construção de solução utilizando o recurso de ‘software’. Por tanto Back-end pode ser considerado um desenvolvedor, mas um front-end? Não. Ele não desenvolve, ele usa o que está ali, para fazer uma aplicação visual. E há uma divisão enorme entre essas atuações.

O segundo problema é que existe uma falácia. Em 2005, Javascript mal era usado, quando cliente, apenas Html e anos mais tarde Css. Que ajudou em muito em elaborar recursos visuais. E quem se preocupava de como o website funcionava, era o webmaster e seus códigos em php ou asp. No passado, havia uma divisão bem clara. Quem atuava na interface era designer gráfico e até publicitário, e quem atuava no servidor, era um programador de T.I. Era bem claro isso. Mas havia uma luta, os T.I acreditavam que tudo que se tratava de site era da área de tecnologia. O designer acreditava que a interface era uma área essencial praticada pelo profissional de publicidade e design.

Até hoje é assim. Mas existe uma comunhão que essa área é uma área de T.I, quer dizer, website é uma área de atuação plena de T.I. O problema é que não é. E continua sendo como era em 2005, só que com nomes diferentes. E isso implica em muitas coisas. Que não o próprio ponto de onde você precisa capacitar. Por exemplo, uma pessoa que atua em Front-End deveria fazer uma faculdade de Computação ou Design?

Se você responder a primeira opção, provavelmente você está confundindo o uso do Javascript no lado do cliente (que é só para fazer efeitos, você não precisa de praticamente nenhum conhecimento avançado em computação, arquitetura, matemática aplicada) mas precisa ter conhecimento de UX Design, que quer você dure acreditar, não é uma cadeira existente no curso de computação. Mas sim de publicidade e de Design gráfico.

MOTIVO PELO QUAL O ARTIGO SE FAZ ESSENCIAL.

Em fevereiro de 2023, publiquei um artigo no Linkedin em minha Newsletter sobre Marketing e Publicidade, e o objetivo foi de “identificar” se o campo Front-End era design ou T.I. E lá fiz uma conclusão que ‘ambos’. No entanto após mais de um ano, senti a necessidade de ‘pontuar’ mais do que o necessário, já que de lá para cá, notei que o próprio mercado se confunde.

Apesar de ser ambos, ele está mais concentrado em Design do que em T.I. Tem T.I por conta da necessidade de haver um nível de interação com a tecnologia mais do que um usuário final teria. Mas que suas forças se concentraram mais nos recursos do Design, do que no de T.I, que apesar desse nome, eu diria que Tecnologia de Informação, transmite pouco sentido, quando falamos de uso “técnico” de conhecimentos de engenharia, como é o caso do uso da “Ciência da Computação”.

FRONT-END…WEBDESIGN.

Tem quem faça uma diferença. Daí podemos deduzir, ou nunca atuou como Webdesigner e supõe, ou atuou e está seguindo os conceitos do novo mercado sem indagar o que de fato era. Atuei (e até recentemente) como webdesigner por quase 20 anos. E nada de Front-End se diferencia do que era no passado. Você praticamente usa tecnologia para criar efeitos visuais. E mal usa script para isso. O que é realidade atual.

Na realidade é uma convenção esse título. Desenvolvedor deveria supor que você programa. Quer dizer, eu já li pessoas falando que Java (Swing, JavaFx) é uma negação para front-end. Mas eles adotam que ao usar Javascript são desenvolvedores. Por um lado há uma negação, por outro uma afirmação. Ora pois, Java foi e quando foi utilizado para criar interfaces na internet desde que Javascript era um feto e quando nasceu, mal fazia diferença frente ao próprio Java.

O que quero falar sobre isso? Existe pouco conhecimento da parte de quem fala sobre se autotitulação. Está mais para designer do que para dev. Bem mais. E isso deveria ser uma boa notícia. Porque você na realidade, o que atua em Front-End não é um T.I, não é uma exatas. É um Designer, humanas e artes visuais. E deveria ler mais sobre branding visual, diagramação, layouts e movimentos estéticos, do que sobre js, dart, flutter ou lógica de programação. E mais, isso já acontece de uma forma subjetiva.

A maioria dos ‘desenvolvedores’ front-end mal estuda lógica e programação. Por que? Eles não precisam. Não usam. Eles fazem especificação visual usando o css, o bootstrap (framework do css 3), na realidade você projeta a interface visual e se preocupa muito mais com Ux Design (UI Design também) do que a infraestrura do modelo TCP-IP, que o teu colega de back-end está careca de mexer. E você nem chega perto.

Algum front-end estuda matemática aplicada, cálculo e limite, integral? Estudam? Desenvolvem sistemas de conexão. Estuda API, API Resst? Estuda? Se estuda você não deveria estar em Front-End. Essa mistura ocorre. E isso causa os problemas. Talvez você esteja pensando – “Então estou trabalhando em duas áreas e recebendo por uma?” Sim. É isso que fez o motivo do Webdesign virar Front-End. Nunca foi pela mudança real das atividades.

Se fosse por pensar seria mais custo e benefício você programar em Java com o JavaFx para interfaces em website. Já que o próprio Java poderia desenvolver uma comunicação mais segura e íntegra do cliente-servidor, tanto no front como no back. Mas isso não se passa na sua cabeça. Porque você provavelmente não é um desenvolvedor. E sim um designer. E isso não é ruim. Porém você recebe por um deles. E atua com os dois. Mas não tem a habilidades em ambos.

ONDE TEM UM PONTO DE DISCORDÂNCIA AQUI?

Há muito tempo é que se confundia essa duas áreas, quando elas se chamavam Webdesigner e webmaster. Até porque o entendimento de site era ainda uma exclusividade tecnológica. E não um canal de comunicação, com o que temos hoje. E isso implicou na interpretação da atuação. Não sei se foi um tiro que sai pela culatra. Mas tentar ‘absorver’ o que seria a criação da interface pelo campo de T.I criou uma bola de neve. Aumentou a exigência, diminuiu a recompensa.

Quando que no passado era necessário ter conhecimento de Publicidade + Photoshop + HTML, hoje você é exigido saber Javascript, python, dart, go, flutter, design, ser t.i, ser publicitário, branding, marketing e receber menos de de 1/4 do que era no passado. É um acúmulo de área. Essa foi uma luta antiga dos T.Is que acreditavam que ao ‘pegar’ eessa área para si, se beneficiariam. O que eu leio de pessoas surtando na internet por causa do front-end não são poucas.

Sem falar que já, em um número frequente também, leio sobre pessoas que discutem sobre front-end, mal possuem conhecimento básico de design. Ficam entre a berlinda de um Dev que não é dev de um design que não é design. É uma área que sofreu uma zumbificação do que ela era mais clara no passado e agora parece uma integração de T.I com Design, que não é T.I e nem Design. É uma estação morta, é o andar entre dois que não existe. Você nem sabe o que você precisa ler ou estudar para de fato fazer o que é preciso.

Roadmap tem aos montes, mas o que eu ouço? Que a tecnologia muda da noite para o dia e você precisa constantemente estar atualizado(a). O engraçado é que isso é quase e unicamente uma realidade para Front-End. Back-end não tem essas mudança radical de tecnologia. Nem na área de desenvolvimento de software. Todo ano, um novo framework de js é inventado, todo ano, tem uma nova ferramenta para ser usado como ‘design’, todo ano você tem uma nova reformulação. E issso significa que você precisa reaprender e não e se atualizar, se torna uma das áreas mais estressantes do momento.

O ponto de discordância é que ela é clara, mas não é. Ela é uma área de T.I, mas não é. Ela pode ser defendida porque acha que precisa saber quase tudo e mudar toda hora, como um efeito de rotatividade, mas ao mesmo tempo, é uma ciência tecnológica “sem lógica”. Como você mantém segurança em um sistema, com mudanças constantes na tecnologia e portanto sua “recodificação”. E aí existem diversas teses, mas sem atentar ao conceito de integridade e lógica visual. Websites não precisam ser “inovativos” o tempo inteiro. Ele precisa funcionar e ser visualmente agradável.

Então por um lado, todos pensam que Front-End é uma área de T.I, porque ela se encontra ás vezes com isso, o que confundiu os T.Is do passado e sua reinvindicação. A interface de um website é formado por uma tecnologia de internet, mas seu trabalho e modelagem, dependem de uma visão de um design e não de um desenvolvedor. A mudança de nome criou um caos 100%, no lugar de “reserva de mercado” como era discutido em 2005.

CONCLUSÃO.

Não há desmerecimento. Não há necessidade de revidar. Porque a confusão dessa área, atormenta quem atua nela. E não é um ponto crucial que podemos concluir – “Você não é um desenvolvedor” e sim um designer que está sendo imposto a ser um desenvolvedor.

E ganhar por um. Por um lado você perde, e pelo outro lado, também perde. Porque você tem sua saúde mental abalada, tem um lado que você não se identifica profissionalmente, por outro lado você não sabe como se capacitar. Se deve ser pelo lado do Design, do T.I ou da Engenharia.

E ao mesmo tempo temos um conceito menos óbvio, o quanto você compreende, ganhou ou se realocou com facilidade quando nestes caos, você não se encontra, quando ao ler algo que pode lhe esclarecer, pode na realidade abrir mais portas?

Porque você saber que é um desenvolvedor vai lhe garantir uma resposta mais precisa pela sua procura do que ser um designer e vice-versa. E não confundir que o uso de uma tecnologia que pode lhe permitir ‘programar’ como é o caso do Javascript, do Kotlin, é que na realidade você está sendo ‘um usuário’ do programa do que um ‘engenheiro’ do programa.

Você faz uso do método criado, mas não desenvolve o método. Então esse artigo não vem para ‘roubar’ tua função. E sim pedir que você olhe para onde você está e o que faz. E ver para onde você quer ir. Muitos pensam que poderiam ser T.I e Design, mas será que poderia ser T.I (estamos falando de matemática) e de Design (estamos falando do que a maioria de fato quer). E até a próxima.

Material extra para leitura.

Ilustração (2) – Pontos de Fuga

Publicado em por

Pontos de Fuga é uma elaboração da época renascentista (empregando o nome de forma clássica ao chamado Pontos Renascentistas) que em lugar de uma reta partindo de um ponto localizado em um horizonte, era usado raios de luz para conferir a perspectiva (afastada ou aproximada) do ponto de referência (ou ator). E são importantes para qualquer desenho que se faça, em especial, efeitos 3D e angulação.

E para uso óbvio, todo tutorial disposto na internet parte do princípio de um quadrado formado e dele parte as retas. Saiba que basicamente você constrói o quadrado depois que define as retas de um ponto de origem. E explícito assim, porque, se você já constrói um quadrado e dele parte para o ponto de fuga, não há muito sentido em ter um horizonte.

A CISMA DA RÉGUA PARA ALGUNS ILUSTRADORES PURISTAS.

E mais, não ache que usar régua o fará menos desenhista. Se o fizer sem, verá o caminho das pedras de perto e verá que cada segundo será um calvário. Então esqueça quem diga que não usar réguas e compasso não é coisa de artista, porque o teu objetivo é fazer o desenho, e não ser uma máquina que faz reta sem régua. E se está ganhando dinheiro com isso, vai por mim, teu cliente quer a reta 90 graus certinha, se você vai fazer isso sem régua ou não, é outra história.

Esta aí traçada uma linha no horizonte. Dela você vai definir um ponto nesta reta que chamaremos de Ponto de Fuga (P.F). Normalmente para visões proporcionais ao como vemos, apenas um ponto de fuga é apropriado. Para mais pontos de fuga era começa a criar distorções: Como olho de peixe, distorção sphere map e panorâmica. Que seria através do uso de uma GO PRO ou uma câmera que abra mais os ângulos laterais.

Vamos desenhar um quadrado. Mas a partir do ponto de fuga. Não faz sentido em fazer o quadrado e dele puxar as retas de fuga. Não vamos seguir uma métrica ainda, vamos apenas traçar. Vocês irão notar que o quadrado vai ficar bem desalinhado.

Tracei em vermelho, para deixar claro o desenho do quadrado a partir das retas de fugas. Vamos desenhar em perspectiva a face da parte de trás. Para apenas visualizarmos a figura que se forma.

Vamos apagar a parte que estaria atrás desse desenho que acabamos de fazer, para dar entender que essa face oculta o que está ali. E vamos pintar as retas em vermelho em preto para que faça jus a um quadrado que desejamos construir.

O mesmo podemos fazer para tornar as faces do lado opacas, e nos conferir como se fosse uma caixa aberta.

Agora para fazer uma quadrado com ângulo reto (90º) é preciso sair do ponto de fuga com as retas de fugas com ângulos opostos. Por exemplo duas retas para cima com ângulo de 45º e para baixo com o mesmo ângulo. Para conseguir essa angulação você precisa usar régua. Fazer na mão, criará uma assimetria que você só vai notar quando desenhar a figura que deseja. E verá como n nosso exemplo ‘sem usar métricas’ o quadrado saiu torto (de propósito).

E assim também podemos compreender como desenhar as figuras, prédios, carros, pessoas, se baseando que elas não foram criadas. Se você as cria a parte do ponto de fuga e retas, não faz muito sentido já que não terá ideia de como formar as figuras a partir delas. E pratique isso em um desenho tradicional antes de partir para o digital.

Porque naturalmente você vai se acostumar em fazer como se faz na internet, primeiro a figura e depois liga as retas. Na hora de fazer isso no desenho tradicional, como se fala? Vai penar um bocado.

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.