Esboçando um sistema de armas de fogo - Parte 02

Hora de continuar com o artigo que publiquei ontem sobre o sistema de armas que estou tentando planejar. Acredito que depois deste texto e do próximo os artigos relacionados devem dar uma parada, já que preciso pesquisar algumas coisas sobre criação de documento de design para ir criando, efetivamente, um game design decente. Bom, sem mais demora, primeiro vamos rever a estrutura que inventei e vou explicar cada ítem:

Código da arma - Em banco de dados, o código serve pra armazenar um ID, o um código de identificação. Apesar de não ser tão necessário, é interessante pra economizar espaço na memória e nos arquivos de save, onde eu posso armazenar apenas o ID e alguns dados mutáveis e caso o jogo chame a arma, ele pesquise pelo banco de dados de armas do jogo pelo código.

Nome - O nome da arma em questão.

Descrição - Um informativo da arma. Por exemplo: “M16 é a designação das forças armadas norte-americanas para uma família de fuzis de assalto derivados do AR-15. Este fuzil de assalto tem sido o principal fuzil de infantaria das forças armadas dos Estados Unidos desde 1967. Além de ser utilizado por 15 países da OTAN, o M16 é a arma de fogo mais produzida em seu calibre.” (Wikipédia)

Read more

Esboçando um sistema de armas de fogo - Parte 01

Hora de continuar com o meu diário de projetos que estão virando artigos diversos. Ontem publiquei um pouco sobre UML e hoje vou começar (numa série de 2 artigos) a falar um pouco sobre armas de fogo. Não, este post não é para falar das armas propriamente ditas, mas para planejar e esboçar um sistema de armas de fogo para games que usem este tipo de funcionalidade. Aí incluem vários tipos de games, como os games de tiro em primeira pessoa (First Person Shooter), terceira pessoa e games de espionagem. Como o meu projeto (ainda farei um post melhor e atualizado sobre o mesmo aqui) é sobre um game de espionagem, comecei a planejar como que as armas de fogo terão influência da jogabilidade. Para isso, peguei a Gamers Book 2 (revista bem antiga) e analisei um pouco sobre o game Goldeneye, do Nintendo 64, considerado um dos melhores games para o console.

Read more

UML em gamedev

Se eu disse que o ano seria bom para novos projetos pessoais, não estava brincando. Eu já comecei (de forma um pouco lenta…) a re-desenvolver um dos meus projetos, mas por enquanto está só na fase do game design mental e alguns rascunhos simples. Com isso tudo que eu for aprendendo (softwares, metodologias de desenvolvimento, pesquisas que irei fazer pela internet) eu vou postar o andamento aqui. Quero ver se eu consigo, em 3 a 4 meses, ter o game design do Resgate de Jade de forma completa! E para começar, vou falar um pouco sobre um dos pesadelos de muita gente: a UML.

Em tecnologia da informação, a UML é uma metodologia de projetos de sistemas. Você usa a mesma para definir algumas coisas de um sistema comercial, para que os programadores possam desenvolver com mais desenvoltura. Na UML a gente define como serão as tabelas de um banco de dados, seus atributos e que ligações as tabelas podem ter. E cada classe de UML pode ser uma classe do teu sistema.

Read more

Dúvida em desenho artístico: Girar ou não a folha na hora de desenhar?

Esta semana uma questão assombrou a minha mente num tópico de desenho artístico na UniDev. A questão de girar ou não a folha na hora de desenhar. Como eu já ando fazendo desenho a cerca de 1 ano e alguns meses, acabei pegando este hábito. Algumas vezes eu pego a folha e coloco num ângulo diferente para fazer um traçado melhor. Para colorir isso é algo praticamente automático, principalmente quando eu coloro um cabelo e sigo a direção do mesmo. Em arte final vi que é mais fácil eu traçar de baixo para cima e com isso algumas vezes quando passo canetinha eu até coloco a folha de cabeça para baixo o desenho, dependendo do traço a ser traçado.

Read more

O estado da área de gamedev no Sul do Brasil

Uma desvantagem de se acessar mais de 30 blogs nacionais de games é que você perde algum tempo lendo eles e filtrando o que interessa, o que prejudica nos estudos de desenvolvimento de jogos. Já uma vantagem é você ver textos que acabam saindo numa esfera pequena de público e poder divulgar num canal específico, no caso, aqui neste site! Saiu no Canal dos Games uma reportagem bastante interessante sobre a área de desenvolvimento de games no Sul do Brasil, especificamente em Santa Catarina e Rio Grande do Sul:

A arte de se trabalhar com games

O mais legal é que a matéria cita as instituições de ensino da região onde o interessado pode estudar e comenta sobre algumas áreas específicas, como game design, música, arte e programação.

Mas um trecho me deixou um pouco intrigado:

Diretor da empresa Palmsoft, que produz jogos para celular e integra o Pólo de Games, em Florianópolis, Dennis Kerr Coelho, disse que a cidade já é o maior pólo dessa área, no Brasil, e que a tendência é o mercado crescer cada vez mais. No entanto, ele ressaltou que, para expandir, é necessário mão-de-obra qualificada, principalmente em tecnologia da informação.

– Um dos maiores problemas é que a tecnologia da informação não é vista como algo glamouroso e não tem tanto prestígio quanto Medicina e Direito, por exemplo. Temos uma carência por profissionais muito grande e, por isso, eles serão bem pagos.

Seria bem interessante que a matérias divulgasse quais os valores normais para quem pensa em seguir na área. Já comentei aqui sobre os valores potencialmente baixos para quem trabalha na área, se comparar com a área básica de TI (programação de sistemas, banco de dados, redes, segurança da informação, etc). E tem outra: se eles tem carência de profissionais, onde que eles divulgam as vagas? Hoje é difícil ver empresas oferecendo emprego nestas áreas. Ou será que eles divulgam apenas em canais locais (leia-se blogs e sites de instituições de ensino na região ou mesmo posters colados em faculdades de tecnologia)? Será que eles não sabem que muita gente tem disponibilidade em se mudar até de estado pra conseguir trabalhar na área? Eu quase me mudei pra Campinas pra trabalhar com programação J2EE em Java no meio do ano (pena não ter dado certo…) e com certeza me mudaria pra outras cidades dependendo da proposta e do local.

Ou talvez as empresas precisam de pessoal qualificado, mas não estão contratando agora por causa das festas de fim de ano. Ou lá tem muita mão de obra mas a mesma não é tão qualificada pra trabalhar na área. Já li no Finalboss e no UOL Jogos que alguns desenvolvedores acham que as instituições não ensinam, direito o profissional. Disso eu tenho um certo receio: hoje alguns cursos superiores custam uma fortuna e normalmente tem uma garantia de preparar bem o profissional. Mas pelo que já vi em algumas grades, os cursos em parte formam generalistas: aprende-se um pouco de cada área e cabe ao profissional, quando estiver terminando o curso, seguir numa área específica. Mas mesmo quando ele chega lá, algumas empresas de ponta pedem profissionais muito bem qualificados, com X anos de esperiência em modelagem e/ou programação avançada em C++ e isso muito profissional não tem, o que acaba em parte dificultando o mesmo de entrar na área, mesmo com um curso superior de desenvolvimento de games.

Pra terminar, de qualquer jeito estamos vendo uma expansão intersessante da área e com certeza podem surgir novas oportunidades no futuro. Além disso, quem já está estudando hoje ficará melhor no futuro e com certeza pode até conseguir, depois, um emprego na área e poder finalmente dizer: estou trabalhando com gamedev

Diário Java 01 - Recomeçando a estudar

Algum tempo atrás eu tentei começar a estudar o C++ voltado para gamedev, mas o tempo foi passando e acabei desanimando. Recentemente, alguns acontecimentos atuais de característica pessoal me fizeram voltar ao Java e desta vez será pra valer. O problema maior que encontro agora é o foco dentro do próprio Java.

Bom, em cidades do interior é raro você encontrar empresas que só trabalham com o Java. A maioria usa Visual Basic e/ou Delphi, duas ferramentas conhecidas e fáceis, mas que hoje não estão tendo tantas atualizações e novidades quanto as linguagens Java e C# (e as IDEs). Além disso, a maioria das empresas médias e grandes estão atrás de profissionais destas linguagens, o que torna boas as oportunidades de trabalho com salários maiores do que no interior (entre 3 e 5 mil reais por mês), onde a área é muito ruim. Hoje convivo com salários baixos, baixíssima expectativa de crescimento, ferramentas ultrapassadas (definitivamente o VB 6 é muito ruim. E posso dizer com segurança, já que mexo com ela há 1 ano e alguns meses. Java e C# são muito superiores em muitos aspectos), clientes enchendo o saco todo dia, enfim, o cotidiano de uma empresa de manutenção de sistemas comerciais.

Read more

Dicas para desenho 02 - Lápis de cor (colorindo)

Vamos começar pra valer a série de dicas para desenho. Sei que o foco maior deste texto é mais pra quem já sabe alguma coisa de desenho tradicional, mas como muitos aqui pensam em desenvolver games, o desenho é uma das partes mais importantes. Vou dividir este post em 3 páginas, para não ficar muito grande para carregar. Para os leitores do feed, deve ir apenas a primeira página e se você se interessar, visite o post!

Você, caso não saiba desenho, também pode treinar em desenhos já prontos, já que estas dicas são bem básicas. É claro que se você fizer um desenho novo e colorir, pode ser bem mais interessante. Ou mesmo entrar num curso de desenho, mas aí vai do foco de cada pessoa.

Só lembrando: o foco aqui é desenho tradicional. Não tem nada de dicas de manuseio de tablets e pintura digital (outro assunto de muito interesse pra mim). Isso vai ficar mais pro futuro, quando estiver bem melhor nesse quesito. E as imagens aqui são scans próprios (onde eu mesmo fiz os desenhos para este tutorial).

1 - Definir bem as cores antes de colorir

Regra de ouro! Quando você for fazer um desenho, pense nas cores antes de começar. Tente imaginar o desenho colorido e pense numa cor legal. Caso esteja copiando algum desenho, veja bem as cores antes de sair colorindo. E anote a numeração dos lápis. Como algumas cores são bem parecidas, você pode acabar trocando a cor sem querer e estragar o seu desenho, onde partes de uma roupa pode estar numa cor e parte dela em outro tom.

2 - Fazer testes numa folha separada

Outra regra interessante. Separe uma folha do mesmo tipo que você estará colorindo apenas para testes. Então, antes de colorir, faça um teste qualquer dependendo de como você vai colorir. Talvez você precise misturar as cores ou mesmo tentar um tom mais claro ou mais escuro, e testar antes pode ser fundamental. Se você não testar, quando você for colorir, você pode acabar descobrindo que não era a cor certa e aí já era: você terá de refazer o desenho.

Veja um exemplo de uma folha de testes:

3 - A questão da superfície onde você irá colorir

Taí algo que pode gerar um pouco de controvérsia. A resposta óbvia é “na mesa”, mas você tem de analisar se a mesma não tem pequenas rachaduras. Se você passar o traço em cima de uma, existe a possibilidade do tom ficar alterado e o seu trabalho pode ser prejudicado. No meu caso, eu utilizo uma folha de raio-x, que deixa o colorido com uma finalização melhor e não deixa aquela sensação de “colorido em cima de uma mesa”. Teste em várias superfícies e veja os resultados.

4 - Tentando manter um tom uniforme

Aqui é um assunto difícil de explicar, o que demanda alguns scans para explanar melhor. Quando você está colorindo e não tem habilidades de um profissional, você, ao preencher uma área relativamente grande, você acaba colorindo de forma normal um trecho e depois continua “em cima”. Com isso, a sua mão acaba passando o traço em cima da parte já colorida, criando algo parecido com isto:

No meio do desenho, se você reparar bem, vai ver que a área é um pouco mais escura do que nas redondezas. Isso acontece porquê você coloriu de forma normal embaixo e ao continuar em cima, você pode ter forçado um pouco e o mesmo ganhou um tom mais forte. para sanar isso é necessário, depois colorir as redondezas no mesmo tom, espalhando o desenho de forma uniforme, até chegar em algo parecido com isto:

Nesse caso, em cores mais escuras isso é mais visível do que numa cor mais fraca. Se você pega uma cor como um amarelo, você mal percebe isso, mas você já reparou que na cor amarelada você acaba forçando o lápis para ele ficar mais visível? Então.

A questão do conhecimento básico e de aprender durante o tempo

Tela do XSI do Making-Of do Metal Gear Solid 4

Tava aqui matutando um artigo pra escrever neste domingo, enquanto que uma porção de gente está preocupada com o campeonato brasileiro de futebol. Aí lendo este texto do Allan Brito, me veio a idéia deste artigo na cabeça, sobre a questão do conhecimento básico inicial e de aprender outras coisas depois.

Não entendeu? Explico: quando alguém pensa em seguir na área de programação, a primeira coisa que muitos recomendam é estudar a parte de lógica de linguagem de programação. É aprender a base de como que funciona um programa de computador e tentar fazer algo mais simples, evoluindo com o passar do tempo. Em modelagem 3D é um pouco mais complicado, já que os softwares são diferentes e um mesmo software muda a sua estrutura básica com o passar do tempo.

Mas até mesmo em 3D existe uma parte básica de modelagem, que é aprender as técnicas de modelar. Usar comandos como o extrude, pelo que li no artigo do Allan, estão presentes em vários softwares e também depois que você aprende a base e de como usar corretamente um recurso, aprender novos recursos ou usar outro programa torna-se uma tarefa mais fácil e corriqueira.

Hoje estou no meu emprego atual trabalhando como programador de Visual Basic. Entrei na empresa do modo tradicional, com entrevista, já que eles estavam precisando de um programador. Mas eles queriam alguém que tivesse uma experiência necessária e não precisaria ser em VB. Eu já conhecia o Java e disse: olha, não sei VB, mas posso aprender. Então passei por um período de treinamento e hoje sei muito bem a linguagem e consigo fazer as atividades normais da empresa. Na empresa anterior foi parecido: o Java eu aprendi dentro do ambiente de trabalho. Se alguém sabe bem uma linguagem aprender outras é mais fácil: é só aprender a sintaxe e seus recursos extras.

Com 3D é a mesma coisa: se você sabe bem a parte básica, aprender um software novo pode não ser tão difícil e muitas empresas podem te dar a chance de te dar um treinamento bom naquele software. Aí vai depender da negociação que o profissional terá com os responsáveis pela empresa. Se o cara é bom, não será difícil aprender os novos recursos. Além disso, em certos projetos pode ser necessário aprender certos recursos para executar a tarefa, como aprender animação, por exemplo.

Ma sé aquele negócio: se você tem tempo livre pra aprender uma ferramenta/recurso novo, recomendo que o faça. Ele tem de pesquisar e saber bem o que o mercado necessita e se preparar. Aprender em casa, sem compromisso com tempo, pode ser útil para que o conhecimento possa ser melhor fixado. Aí quando uma oportunidade aparecer, ele poderá aproveitar melhor e ter mais chances de conseguir aquela vaga.

A imensidão das tecnologias gráficas das engines 3D

Half Life Lost Coast - Efeito de HDR (High Dynamic Range Rendering)

Nos últimos dias andei lendo e tentando entender os artigos traduzidos do Loading Time sobre a história do 3D. Na verdade o artigo é mais como um dicionário de termos técnicos comuns, mas focado em tecnologias que são hoje aplicadas em engines técnicas. Você vê explicações (algumas vezes bem difíceis de entender) sobre anti-aliasing, Z-Buffering, Normal Map e tecnologias que você pode nunca ter ouvido falar na vida, como Parallax Mapping, Post Processing e Ambient Occlusion (que eu só sabia que existia o nome). Eu fiquei maravilhado com isso, com esses termos difíceis, com as próprias tecnologias, mas eu estava no mundo da fantasia. Uma hora a ficha cai e você volta para o mundo real: meu, como eu faria um treco desses no meu jogo?

Pegamos o Realtime Shadows (Sombras em Tempo Real), usado em Splinter Cell. Pelo que eu entendi lendo o texto, é necessário ter um mapa de sombra, onde, caso um objeto se mova da fonte de luz, seria necessário atualizar todo o mapa de sombras do objeto e refazer todos os cálculos. Minha mente de programador está até agora sem nenhum tipo de idéia de como que eu poderia fazer um negócio desses.

OK, eu admito que não tenho conhecimento algum em engines. Não saberia, neste momento, criar algum tipo de efeito gráfico ou mesmo explicar, mas isso é algo a se pensar pra quem quer ser programador de games. E eu digo: programador de games. Aquele que vai mexer com códigos-fonte, com linguagens de programação, com engines, com inteligência artificial. Hoje muita gente acha que o termo programador de games se refere a alguém que cria o jogo. OK, ele pode acabar sendo o responsável por dar vida ao jogo, mas temos que dividir as áreas. Temos um modelador que faz os modelos 3D, temos os game designers que projetam as coisas, temos os ilustradores de conceitos para mostrar uma idéia usando um desenho, etc etc etc. Que tentemos colocar cada função e cada um em seu devido lugar.

Mas porquê um programador (ou alguém que queira entrar neste ramo) teria de pensar nisso? Porquê são eles que terão de se preocupar com os efeitos gráficos do jogo. São eles que vão botar a mão na massa e setar. São eles que terão, também, de escolher a engine certa para o projeto.

Hoje eu considero bem difícil escolher uma engine gráfica. Mais difícil seria projetar uma engine, já que o programador teria de estudar matemática em níveis bem avançados para criar cálculos que possam gerar efeitos gráficos. Vento, água, fumaça. Pode não parecer, mas são efeitos que quebram a mente de um programador avançado com uma facilidade tremenda. Mas pode ter alguma engine possa fazer isso. E aí entra os termos citados no começo deste texto.

Quando você joga um game, como jogador, você não pensa na dificuldade que os programadores podem ter tido ao desenvolver o mesmo. Chegar e pensar, por exemplo, em maneiras de poder economizar recursos de memória para o restante ser usado com outras coisas. Pensem numa multidão vista no vídeo abaixo, em Assassin’s Creed:

Impressionante? Então veja o Hydrophobia, game que mostrará uma simulação de água num nível que realmente impressiona:

OK, hoje os consoles atuais e os PCs conseguem facilitar a vida dos programadores, mas mesmo assim pense naqueles programadores que fazem as engines internas das produtoras. Ou mesmo pense naqueles programadores que desenvolvem engines gráficas de ponta, como a Unreal Engine 3. Pense nas pessoas que criaram parte do que você viu acima. Eu tenho um respeito enorme pelos caras, já que eles devem quebrar bem a mente pra poder criar cálculos efeitos gráficos. Um sistema comercial com banco de dados pode ser chato e monótono, mas é mais fácil do que você pensar em desenvolver cálculos complexos para criar efeitos de luzes e que pode ser fascinante ficar testando durante o seu horário de trabalho. Ou mesmo desenvolver uma boa rotina de inteligência artificial ou quebrar a cabeça com um monte de personagens na tela se interagindo de forma realista.

Hoje existem tantos efeitos técnicos numa engine que você acaba ficando maluco. São termos técnicos que até mesmo um modelador não entenderia logo de cara. Um game designer muito menos. Tenho certeza também que muito programador de games também podem não conhecer tudo. Não quer dizer que eles tem de conhecer, mas saber pelo menos o básico pode evitar muita dor de cabeça no futuro. Se uma equipe analisar bem que tipos de efeitos o jogo pode ter, a equipe pode escolher a engine que possa se adequar melhor aquele projeto. E não se preocupe por não saber tanto sobre Ambient Occlusion ou mesmo sobre HDR (High Dynamic Range Rendering). Talvez você nunca possa pensar em utilizar este tipo de tecnologia, dependendo do seu foco atual como desenvolvedor. De todos os termos, só conhecia o Normal Map, mapeamentos de textura e o Anti-Aliasing. Este último por ser algo bastante difundido em revistas de games. O mapeamento de textura por já ter feito algo parecido no Blender. E o Normal map por estar habituado a ver objetos 3D que possuem irregularidades numa superfície.

Pensando no cabelo dos personagens

Temos mais um assunto incomum na área: a questão do cabelo dos personagens, que pode ser crucial para dar mais realismo (ou mais fantasia) aos seus personagens nos games. A idéia deste post surgiu desta notícia do G1, onde está acontecendo na Bulgária um festival de penteados extravagantes:

Bulgária faz festival de penteados

Decidi aproveitar o timing! Como to gostando de character design, um assunto que não pode faltar nas reuniões de definições dos personagens (isso numa equipe) são o tipo de cabelo do personagem e suas implicações posteriores. A primeira delas é de característica estética, onde os personagens masculinos tem poucas variações: cores, tamanho e o formato. Cor no sentido de que é necessário analisar o quão realista é o seu projeto. Se você vai fazer algo parecido como o Splinter Cell ou ambientado no presente, você não pode colocar variações de cores nos cabelos da maioria dos personagens (talvez num inimigo com estilo punk…). Em RPGs e em games com estilo anime, você pode se dar ao luxo de colocar uma cor mais extravagante como um azul ou laranja, e mesmo assim os personagens serão bem naturais em virtude do estilo do game.

Read more

Next Page »