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.

Level Designer X Level Artist

Então eu descubro que existe uma diferenciação entre as funções de Level Designer e de Level Artist, apesar de que eu já sabia dessa diferenciação implicitamente. Explico: normalmente tem-se o game designer e as suas ramificações, como o character designer (que projeta personagens) e o level designer (projetista de locais. As fases). No character designer, por exemplo, o profissional define o design do personagem: define atributos físicos, psicológicos, história de vida, e outros. Então o designer pega a parte física (a aparência) e passa pro artista 2D: quero que você faça algo parecido com este design, com este tipo de roupa, com este tipo de cabelo, estas cores e etc. Depois esse artista pode passar o concept aprovado para o modelador e o mesmo já ir montando o personagem. Ou o character designer já passar estas especificações diretamente para o modelador.

No level design a situação é bem parecida. Eu achava que um bom level designer deveria necessariamente ser também um bom modelador. Nem sempre, já que, pelo que andei lendo neste post, deu pra entender que o level designer planeja a fase e o scripting dela. Ou seja, ele define suas diretrizes e os locais onde tem os eventos do local (como iniciar uma conversa entre dois inimigos num jogo de espionagem, por exemplo).

Já um level artist é o profissional da parte técnica. É aquele que vai usar um editor 3D para criar a localidade, setar texturas e, em alguns casos, até programar alguma coisa no level para testar algumas funcionalidades, como abrir portas (por exemplo).

Esta diferenciação acaba ocorrendo com mais facilidade em equipes médias e grandes, onde um game é feito por mais de 30 pessoas (só lembrando: o número é um chute). Em equipes pequenas (indie) normalmente o modelador acaba pegando tanto a parte de level design (ou o líder do projeto pode esboçar alguma coisa do cenário) quanto a de level art. Os programadores também podem ter algum conhecimento de level art para criar satisfatoriamente o cenário e fazer ele rodar com alguma coisa pré-finalizada, como setar colisões entre a câmera e os objetos e criar alguns movimentos de objetos diversos (como fazer uma porta abrir).

É claro que se um level designer souber bem desenho artístico (para esboçar o local), modelagem 3D (para criar o local), texturização (para texturizar o local) e detalhes mais complexos como ilumiunação e animação, ele com certeza será mais valorizado dentro da empresa e no mercado de trabalho.

Por fim, caso alguém queira comentar melhor sobre isso (ainda não tenho experiência na área, mas me interesso bem por ela), fique à vontade!

3 cenários. 3 novas tentativas

Algum tempo atrás eu cheguei a comentar sobre um tech-demo que estava pretendendo fazer, mas o projeto acabou engavetado por falta de tempo e por falta de vontade, já que é maçante planejar um cenário do zero com a sua planta-base e já definir elementos como localização dos inimigos e eventos.

Mas ainda acredito que isso é a primeira coisa que deve ser feita já que tendo o planejamento do teu lado o desenvolvimento flui com mais naturalidade e rapidez.

Então recentemente andei cogitando voltar a tentar desenvolver algum cenário pra ter alguns tech-demos no currículo, para mostrar a possíveis empregadores que eu tenho capacidade técnica para fazer isso. E uma oportunidade perfeita para isso é a possível abertura de um contest de Level Design na UniDev:

Level Design Contest - O que acham?

Bom, como desta vez eu não pego mais nada pra organizar, então vai ser bem melhor apenas participar como diversão e aprendizado. Com este contest eu quero tentar arrumar tempo pra desenvolver 3 cenários (sim: 3!): um medieval, que ainda estou planejando, um de fantasia, para o Contest, e um atual, para o CSIB, um projeto que está congelado. Sobre o projeto atual (que vou chamá-lo de Berlim, por ser ambientado na Alemanha) já tenho um pré-planejamento pronto e vou usar apenas rascunhos em papel para planejar o mesmo. Já no projeto medieval eu vou usar o RPG Maker para planejar as locações e depois passar isso para o Blender, o que será mais fácil tecnicamente.

Então eu vou divulgar aqui (e também no fórum da UniDev) no GamedevBR todo o andamento desses mapas, desde as concepções iniciais até mesmo os testes de renders e quem sabe até testes práticos envolvendo alguma engine 3D. Como tenho um sólido conhecimento de Java, vou usar a jMonkeyEngine para isso e vou procurar referências e informações sobre a ferramenta, o que pode render um post futuro. Pelo que vi no post sobre a mansão, alguns leitores concordam com este tipo de abordagem, o que pode ser útil para todos: para mim que é um canal de divulgação e para vocês, que é uma opção a mais pra ficarem por dentro desta área.

Dos mapas, só o mapa de Berlim e o medieval que será exclusivo para o GamedevBR e para o meu blog pessoal (lá só terá um post com as imagens finais, como faço com os meus desenhos). O de fantasia eu irei postar mais no fórum na UniDev e colocar aqui alguns reports sobre o meu andamento do trabalho. Como o Contest ainda não começou, este tempo livre até o seu início será usado para adiantar outros assuntos aqui, como o XNA Gamefest e alguns assuntos diversos. Aí sim depois disso que posso pegar pra valer e ficar por conta disso durante algum tempo.

Vamos ver também se consigo terminar alguma coisa. Ultimamente eu só prometo, só prometo e nunca consigo terminar. Me desejem sorte!

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

Como deve ser o portfólio de um aspirante a desenvolvedor de games

À esquerda o modelo com Normal Maps. à direita o modelo com finalização avançada de trabalho

Uma questão muito importante e que poucos colocam em prática é a questão do portfólio. Pra quem não sabe, o portfólio é um local onde tem os trabalhos de uma pessoa, como se fosse o currículo. Tudo bem que o profissional tem de ter o currículo, mas um processo de seleção deve passar por várias etapas. Uma delas é o analisador ver o portfólio de um artista 3D pra ele poder ver como são os trabalhos dele.

O problema é que, como disse acima, o aspirante a desenvolvedor normalmente não se preocupa muito com isso e fica apenas estudando uma das áreas, como programação. Bom, fica difícil um analisador ver se o cara é bom se ele não tem nada pra mostrar (e isso é um problema que enfrento. Ainda não tenho games/trabalhos prontos e estou tentando arrumar tempo pra criar alguns…). Então o jeito é criar uma página com um portfólio com os trabalhos apresentados.

Read more

A questão dos idiomas em gamedev

Uma coisa que a maioria não se preocupa direito é com a questão do idioma, tanto no seu jogo quando no mercado de trabalho e para ajudar os desenvolvedores na parte de arrumar conhecimento. Sim, estamos falando de português e de inglês, dois dos principais idiomas para nós, brasileiros, que queremos nos dar bem na selva do gamedev, onde poucos conseguem criar um jogo decente e onde existem poucas empresas aqui no Brasil.

Só lembrando que não sou nenhum especialista e outros leitores podem complementar o texto com opiniões bem melhores. Vamos lá:

Português

Pode não parecer, saber escrever razoavelmente bem é fundamental, e caso queira fazer um jogo em português, tenha sempre um corretor ortográfico aberto. Já é um pouco desagradável ver em tópicos de fóruns de discussão erros grosseiros de ortografia (e algumas vezes erros de concordância, mas nem ligo pra isso. Eu erro também de vez em quando), abreviações de palavras básicas (vc, por exemplo), etc.

O seu jogo é o seu produto, e deve ter uma boa aparência. Afinal, outros jogadores vão avaliar e isso será parte do seu portfólio. Um examimador de uma empresa vai ser criterioso ao avaliar seu jogo e se o mesmo estiver com erros, a sua possibilidade de ir pra empresa cai e pode chegar a zero.

Tente também não usar gírias regionais. É difícil, mas o seu jogo será acessado por pessoas de todo o planeta (sim, do mundo. Há muito brasileiro que mora fora, etc) e nem todas vão saber o significado daquela gíria.

O português também pode ser usado como tema do seu jogo, caso queira criar um game educativo neste idioma. Mas isso é assunto para outro texto.

Inglês

Aqui entra a mesma situação acima, mas com mais complexidade. Você terá de saber inglês por três motivos importantíssimos: ter mais público, mais chance de arrumar um emprego na área e ter mais acesso ao conhecimento de gamedev que está nos grandes sites da área: Gamasutra e Gamedev.net.

Ter mais acesso significa que você terá de dominar a leitura em inglês. Sei que a gente tenta sempre ajudar em fóruns e blogs com conhecimento de dúvidas, mas se você souber inglês, é mais fácil encontrar um tutorial específico e poder estudar com mais facilidade. Muita coisa avançada não tem em português e aí não tem jeito: ou você se vira com o inglês ou você não conseguirá estudar direito.

Ah, mas eu posso usar os tradutores online! Sim, claro, mas eles não são infalíveis e podem te confundir e te atrapalhar.

O segundo motivo é o de ter mais chance de entrar numa empresa. Como a maioria das empresa nacionais fazem outsourcing ou games pra exportação (criam partes dos jogos pra empresas internacionais ou mesmo o lançam fora do mercado nacional, que, infelizmente, ainda é pequeno), saber inglês é fundamental. Aí não tem jeito: é ter quase fluência tanto em escrita como na fala. O melhor jeito de treinar é, além de ler tutoriais, se interagir com os fóruns gringos, como o Gamedev.net, a CGSociety (um dos maiores fóruns de 3D do mundo) e outros.

Aí se interagir com pessoas de fora é o terceiro motivo principal. Se você desenvolve um game multi-idioma, você terá mais público e poderá exportar seu jogo para outros países. Além disso, você pode inclusive comercializar o seu projeto em sites internacionais que podem ter mais visitas que os sites nacionais.

Concluindo

Espero que agora você possa se preocupar melhor com o idioma do seu jogo. Se você souber administrar bem isso (e o game ter legendas, claro!) você conseguirá criar um jogo decente e profissional, que pode ajudar no seu portfólio no futuro e/ou mesmo ajudar a equipe a faturar uma graninha extra, vendendo seu jogo em mídias diversas, como na internet.

Dicas para desenho - Parte 01

Faz quase 1 ano que estou num curso de desenho. Então decidi compartilhar um pouco do meu conhecimento básico aqui para aqueles que querem seguir nesta área, que é difícil e demanda muito tempo para você ficar bom. Diferente da programação onde em poucos meses você pode estar dominando uma linguagem ou ferramenta (com pouco tempo de estudo diário ou semanal), em desenho, mesmo treinando diariamente pode demorar anos até você ficar razoavelmente bom. É bem mais difícil.

Vou fracionar os posts em partes, já que vira e mexe eu posso aprender coisas novas e aí vou compartilhando com vocês aos poucos.

1 - Arrume um tablet

Essa é para quem quer seguir na área digital. Quem pensa em desenhar DEVE ter um tablet (também chamada de mesa digitalizadora), que troca o mouse por uma caneta. Não quer dizer que você não consegue trabalhar com o mouse, mas tendo um tablet a coordenação e o desenho ficam bem melhores. É claro que num desenho o esboço inicial do papel sempre é mais importante, mas em empresas de gamedev e outras áreas artísticas as finalizações sempre são no computador.

Tablet Genius

Quanto aos tablets, apesar de não ter uma Wacon, recomendo esta marca, onde a maioria recomenda com afinco. Hoje tenho uma Genius que ainda dá pro gasto, mas pretendo adquirir outro em alguns meses.

2 - Adquira um scanner

Depois do tablet, outro aparelho essencial é um scanner. Com ele você poderá escanear os seus desenhos para serem finalizados depois. Hoje um scanner comum é baratinho e muitas impressoras vem com este recurso. Na época eu paguei 600 reais, que é um preço razoável, mas um scanner você deve encontrar por uns 200/300 reais, em média.

Caso tenha um, escaneie seus desenhos usando resoluções mais altas que a padrão, que gera imagens maiores e que podem ser melhor acabadas posteriormente (além de que muitos avaliadores querem ver todos os detalhes dos desenhos. Um desenho grande pode fazer diferença num teste de seleção). Recomendo usar 300 e 600 dpi.

3 - Instale um editor de imagens

Ou, em outras palavras, tenha o Photoshop e/ou o Gimp instalados. Pode parecer óbvio, mas muita gente nem liga muito pra isso. Mesmo que você tenha um scanner, pode ser necessário o usuário fazer um tratamento na imagem, diminuindo um pouco a qualidade (pra ficar menor) ou mesmo colocando uma marca dágua na imagem. Dos dois softwares citados, o Gimp é gratuito e bem poderoso.

4 - Tenha um portfólio

Outra coisa essencial. Você tem de ter um local na internet onde você pode colocar os seus desenhos. Pode ser um site simples, um blog, algum lugar onde um possível empregador pode ver os seus desenhos. É por isso que recomendei um scanner acima: você tem de ter os seus desenhos em formato digital pra poder enviar os mesmos para outras pessoas ou mesmo postar num fórum para avaliação. Você pode até usar uma câmera digital, mas ela nunca será igual a um scanner.

O maior problema é que muita gente mal-intencionada pegam desenhos dos outros e usam em seus portfólios. Aí é bem difícil de identificar e caberá ao examinador ver se cara manja mesmo de desenho. Uma coisa é copiar um desenho e refazer olhando (que eu estou fazendo pra aprender). A outra é eu pegar um desenho qualquer na internet e dizer que fui eu que criei. Isso eu acho errado. E também o cara pode pedir num exame algo do mesmo nível que os desenhos do pórtfólio e aí o espertinho pode se queimar.

Concluindo

Bom, se você chegou até aqui deve estar pensando: e as dicas de desenhos? Você não falou quase nada! Sim, aqui não tem muita coisa, mas este é a primeira parte do texto. Pretendo escrever outras com o passar dos meses e ir postando aqui.

De qualquer jeito eu recomendo que o usuário entre numa escola de desenho ou mesmo tenha aula. Nada contra quem é auto-didata, mas é muito melhor ter um professor te auxiliando do que tentar apenas via internet/revistas e não aprender direito.

Planejamento e criação de chefes. Um esboço inicial

Hoje me deparei com um fato curioso que virou o embrião deste texto:

Chefe de Final Fantasy XI pode demorar 18 horas pra derrotar

Veja uma foto do Pandemonium Warden, o chefão supremo da série Final Fantasy

Basicamente comentei no meu blog pessoal sobre o Pandemonium Warden, o novo chefe fodão da série Final Fantasy, que, apesar de desconhecer os pontos de vida do personagem, os jogadores tentaram derrotá-lo durante 18 horas, tirando do trono o Yiazmat, o chefão supremo de Final Fantasy XII, que possui 50 milhões de pontos de vida e que, em condições normais, o jogador demoraria umas 6 horas pra derrotar, podendo ter a chance dele salvar, recarregar as energias durante o confronto, etc etc:

Yiazmat, um super-chefe

Isso me fez pensar sobre os chefes. Para quem não sabe (existe alguém que não sabe? O.o ) são os personagens que são mais fortes do que os inimigos normais. Normalmente são únicos e o chefe é o desafio final de uma localidade.

Sempre gostei de chefes difíceis. Fico admirado quando vejo que um game designer soube criar um chefe difícil de derrotar e que seja balanceado. E que não seja extremamente difícil, já que a paciência do jogador tem limite.

Ultima Weapon, em Final Fantasy VIII

Mas como criar um chefe que seja difícil e épico? Bom, primeiro você, obviamente, terá de pensar no estilo do seu jogo e no próprio enredo, além de estudar um pouco sobre biologia e ecossistemas, que são dois assuntos incomuns do desenvolvimento de jogos.

Porquê estudar esses assuntos? Bom, você precisa saber definir como que será o chefe dependendo da localidade. Você num vai colocar um castor gigante no mar, caso você esteja enfrentando o mesmo num navio, como numa batalha contra o Sin, em Final Fantasy X, onde você enfrenta um monstro enorme dentro de um navio (e o monstro no oceano).

Você tem de estudar ecossistemas básicos e biologia pra criar um inimigo compatível com o local e com o enredo. Por exemplo: eu posso criar um super-vilão como o Sephiroth e você pode interceptar o mesmo numa caverna de gelo. Aí você pode definir alguns fatores, como o nível do mesmo, prevendo que nível o jogador pode estar naquela parte do enredo. E definir possíveis ataques baseados no local, criando uma batalha situacional e fazendo com que os personagens possam interagir com o local. Por exemplo: criando um movimento onde o inimigo pode quebrar várias estalactites e fazer chover uma chuva de lâminas pra ferir seus personagens.

Mas também o desenvolvedor não pode exagerar na dose. Você pode até querer criar um chefão ultra-poderoso, mas fica a pergunta: você conseguiria derrotá-lo? Apesar dessa pergunta ser bem fácil de responder, pense: você pode deixar escapar um bug e você mesmo pode não conseguir derrotá-lo caso queira testar a sua criação.

Acredite, isso é possível de acontecer.

Outra dica útil é pedir pra amigos próximos ou mesmo os beta-testers testarem seus chefes. Configure os personagens com um nível parecido com o do chefe, ensine os movimentos e comandos do jogo e assista eles jogarem, anotando as dificuldades e facilidades. Assim você pode ir arrumando seu inimigo pra deixar o mesmo melhor e não tão desafiador a ponto de frustrar o jogador e criar uma situação que pode estragar o seu jogo.

E também faça igual no Final Fantasy XII: coloque inimigos comuns com um nível compatível de acordo com o possível chefe da fase na dungeon. Se eu vejo que tem inimigos poderosos num local e começo a sofrer pra avançar numa localidade, eu penso em voltar e evoluir melhor, pra tentar novamente posteriormente com um nível maior. Ou mesmo continuo com o enredo do jogo e volto àquela localidade depois

E por falar em localidades, em praticamente todos os RPGs existem sempre aquelas localidades secretas com inimigos bem poderosos. Recomendo criar uma e também seguir os passos acima, pra criar inimigos balanceados e não tão apelões a ponto de frustar o jogador também. Em Star Ocean 2, por exemplo, tem a Cave of Trials, que a cada andar os inimigos vão ganhando mais poder. No começo pode até parecer fácil ter inimigos simpes, mas quando o jogador começa a avançar bem no local, ele começará a encontrar inimigos realmente poderosos que podem deixar ele feliz ou um pouco frustrado por causa do nível de dificuldade. Mas é aquele negócio: saiba balancear bem o local e os inimigos. Assim você conseguirá criar uma localidade perfeita, desafiadora e que seja possível de passar por ela para o jogador fechar o jogo com 100%

Sei que não sou lá um especialista em inimigos e locais. Mas eu pensaria nisso enquanto criasse um jogo de RPG. Afinal, não posso estragar a diversão só pra criar um inimigo fodão e impossível de derrotar

A questão da divulgação de idéias do seu projeto

Recentemente, um post no ene3 me chamou a atenção:

Miyamoto proibido de falar dos seus hobbies

Basicamente conta sobre a proibição da Nintendo dos funcionários divulgarem seus hobbies. Isso me deu idéia deste texto, sobre as idéias que surgem no tempo livre que podem se transformar num jogo. E essas idéias serem copiadas por outras pessoas, para elas ganharem grana.

Aí entramos no X da questão: se eu tenho uma idéia de um jogo, eu poderia divulgar ela pra avaliação em fóruns de discussão?

Depende. Se você for um desenvolvedor indie e quer saber a opinião da comunidade antes de começar um projeto, é até recomendável fazer isso. Mas você estará sujeito a ter a sua idéia copiada e usada por outra pessoa, que pode ver nela uma oportunidade de faturar em cima dela.

Oras, eu posso simplesmente dizer que não se pode copiar a idéia! Tudo bem, mas ainda assim o cara pode simplesmente adaptar a sua idéia e modificar alguns pontos. Aí mesmo num processo você não poderá fazer nada, já que ele foi esperto e soube aproveitar. Você não, por ter tido a burrice de ter divulgado isso na net.

Então divulgar é burrice?

Depende de novo. Como disse antes, você tem de estar ciente dos riscos. Se você tem uma idéia fenomenal e quer botar em prática num jogo indie que pode te render alguma grana, recomendo não fazer isso na net, mas para um grupo de pessoas confiáveis que não irão roubar a sua idéia. Aí você pode mostrar isso e chamar eles pra entrar na sua equipe. Aí basta criarem o jogo e lançarem.

Mas aí temos também outro problema. Eu não daria crédito a alguém que quer chamar gente pra uma equipe num fórum mas não vai divulgar nada relevante, como um esboço do enredo. Eu precisaria de informações cruciais pra saber se valeria a pena entrar numa equipe indie. O problema é que se você vai chamar alguém, terá de divulgar a sua idéia. E aí entra na mesma situação acima!

Tudo isso é válido pra quem é indie. Em empresas, uma idéia interessante e bem estruturada pode lhe render, dependendo do seu cargo (se você for um game designer), um financiamento de um jogo completo. E divulgar pode ser proibido e perigoso para as empresas e para você.

Por exemplo: Já imaginou se alguém como o David Jaffe postasse sobre a idéia do God of War antes do jogo começar a ser desenvolvido num fórum indie? Outra empresa poderia pegar a idéia e passar na frente do cara, tendo assim uma franquia excelente em suas mãos. Além disso, se a outra empresa passasse na frente e o Jaffe começasse a desenvolver, a empresa que copiou poderia acusar a Sony de plágio e/ou falta de criatividade, ferrando com tudo. Ou mesmo ela divulgasse a idéia e a Sony perder a chance de faturar milhões com uma nova franquia.

Por isso que a Nintendo proibiu o Miyamoto e os outros de divulgarem a suas idéias ou o que eles fazem no seu tempo livre. Ela é esperta suficiente pra saber que qualquer idéia simples pode gerar um game original e a Nintendo sair na frente de todo mundo. Se o Miyamoto se diverte com alguma coisa, essa idiversão pode fazer parte de um jogo e com isso

É aquele negócio: a gente vai fazer um game baseado, em parte, na nossa diversão. Se eu gosto de ler X tipos de livros, com certeza eles vão me influenciar nos meus futuros projetos.

Por fim, pense muito antes de sair por aí divulgando qualquer idéia. Se você não se preocupa com isso, vá em frente e divulgue. Assim você pode ver as opiniões de outros desenvolvedores sobre a sua idéia/projeto. Se você consegue ver na idéia uma oportunidade de faturar uma grana, aí sim você pode segurar a sua idéia, melhorá-la, estruturá-la e aí sim você pode desenvolver um game design e montar uma equipe indie de confiança pro jogo sair.

A questão das customizações

Recentemente com o lançamento de Soul Calibur IV (imagem acima), voltou à tona na minha mente sobre a questão das customizações nos games. Para quem não sabe, é a capacidade do jogo de poder dar ao usuário poderes para modificar certos trechos do jogo. Bom, isso já está bem presente em muitos jogos de FPS (tiro em primeira pessoa) e quando você vai criar um personagem num jogo online, onde o game te dá um personagem-molde e você vai setando a aparência, roupas, raças, atributos, etc. Algo bem parecido com os RPGs de mesa (D&D, Vampiro, 3D&T, etc), onde você cria um personagem, define atributos, história, etc e sai jogando com ele numa partida qualquer

A vantagem maior é justamente a longevidade do game: depois que você termina certo jogo, você pode, se quiser, desenvolver uma fase extra e quem sabe até disponibilizar a mesma para outros usuários testarem e avaliarem. Ou mesmo, com o Soul Calibur, criar personagens clássicos dos games e postar sobre isso na internet, apenas como curiosidade. Pelo que andei lendo na EGM Brasil, no quarto jogo será possível jogar online com o seu personagem customizado.

Mas tudo depende do estilo do jogo. Num RPG clássico (falando de modo geral, não comentando sobre sistemas de lutas), onde a base é o enredo, isso é quase impossível de se ter. No máximo uma troca de nome dos personagens e de invocações, como acontece em alguns games da série Final Fantasy.

Por quê? Simples: num jogo de RPG ou num jogo de ação como o Metal Gear Solid, as cenas já estão prontas, além de que em muitos jogos a aparência do personagem pode ser essencial para a trama, como o próprio Solid Snake, que na quarta versão está velho.

Ah, mas não seria difícil ter um personagem criado por você numa cena do Metal Gear, já que as mesmas são em tempo real! Com certeza, mas aí isso detona totalmente com o enredo. Se eu jogo Metal Gear é pra ver os personagens do jogo em ação, e não uma versão modificada no lugar do Solid Snake! Além disso, as cenas, mesmo sendo rodadas em tempo real, já foram previamente renderizadas e editadas, onde foram setados movimentos de roupas, animações faciais, etc.

Mas não quer dizer que você não possa colocar isso no seu projeto. Acredito que se você já pensar num modo de customização, isso só lhe trará vantagens. A primeira é você usar o próprio editor pra te ajudar a criar certos elementos do seu próprio jogo. A outra é que tendo algo assim, a possibilidade do jogador poder testar seu projeto é maior: com certeza eu daria preferência a games que eu pudesse modificar (mesmo que eu não faça isso normalmente) posteriormente.

Editor de personagens do MMO World of Warcraft

Mas, como disse antes, é necessário ter isso em mente antes de desenvolver o game design do seu jogo. Se você cogitar essa possibilidade, o desenvolvimento de alguns elementos terá de ter uma opção de flexibilidade, onde, ao programar certas coisas, deverá ter uma seqüência de “E SE” dependendo de como que o personagem foi criado.

Por exemplo, num jogo de RPG onde terá opção de customização:

SE UM PERSONAGEM USAR UM MACHADO:
- causa x de dano com o inimigo próximo. Longe só acertará o ar. O ataque é mais lento mas causa mais dano.
- o ataque só fará efeito se o personagem estiver próximo do inimigo.
- A animação do braço do personagem será de cima pra baixo, com as duas mãos no machado (dependendo do estilo do machado).
SE ELE USAR UMA ESPADA:
- causa y de dano com o inimigo próximo. Longe só acertará o ar.
- o ataque só fará efeito se o personagem estiver próximo do inimigo.
- a animação braçal poderá ser de cima pra baixo com uma das mãos empunhando a espada OU de um lado para o outro. Ou alternando os movimentos.
SE ELE USAR UM ARCO E FLECHA:
- o ataque fará efeito de qualquer local, mas demora x tempo pra recarregar o arco e tem um y raio de ação.
- a animação será definida assim: braço esquerdo segurando o arco e braço direito que segura e solta a flecha.

Já imaginou a quantidade de possibilidades? Já imaginou se você apenas deixa o personagem com um tipo de arma e depois que o jogo estiver num nível avançado de desenvolvimento a equipe quiser implementar a possibilidade de customização para o personagem principal no início do jogo? Você iria refazer trechos enormes do jogo só pra colocar isso?

É loucura querer alterar o que está funcionando pra colocar isso. Isso demandaria tempo, dinheiro e seria muito custoso na parte técnica.

Então você pode planejar algo assim ou mesmo deixar fixo. Deixando fixo (cada personagem com apenas um tipo de arma), facilita o desenvolvimento, cabendo aos programadores apenas setarem os danos de acordo com a arma. Se você já imaginar algo assim, o desenvolvimento pode acabar demorando mais, mas com um recurso desses pode ser um diferencial para o estilo.

[Créditos das imagens: Site oficial de World of Warcraft e Hatimaki]

« Previous Page — Next Page »