Falando primeiramente sobre a área de jogos, dá pra dizer que o evento cumpriu o que prometeu. Existiam diversos stands onde o público podia jogar coisas como Street Fighter 4 e Guitar Hero, alguns jogos para Xbox 360 e até mesmo clássicos do Atari. Pra completar, tinha também um set completo do jogo Rock Band e arcades com vários jogos diferentes. A questão era ter paciência para enfrentar as filas pra jogar.

 Modelos caracterizados e participantes do concurso de cosplay desfilavam pelo local e tiravam fotos com o público. Não podemos esquecer também do desafio de WiiFit e do campeonato de Winning Eleven. Enfim, quem estava ali só pelos jogos, provavelmente se divertiu.

O problema é que eu não fui ao evento para ver os joguinhos, eu (e muitos outros) fui por causa das mesas redondas e das stands dos desenvolvedores nacionais.

Os expositores eram a DonSoft com seu Capoeira Legends e o Phoenix Team criador do jogo H.I.V.E (que venceu o XNA Challenge deste ano). Ambos os jogos foram bem expostos e estavam disponíveis para que o público pudesse testar, o que certamente foi uma decisão acertada. Quem gostou do Capoeira Legends podia levar uma cópia autografada se comprasse no evento.

Ok, tudo muito bom, mas e as mesas redondas? Devo dizer que está parte foi pra lá de decepcionante. Quase deu vontade de pedir o dinheiro de volta. Acontece que ao invés de deixar esta parte em um local separado, uma sala fechada, os organizadores acharam que seria uma boa idéia colocar um projetor e um telão em uma arquibancada de frente para a quadra esportiva onde o resto do evento ocorria e deixar o povo se esguelar ali pra tentar se entender.

A simples idéia de deixar as apresentações no mesmo lugar onde os jogos estavam já foi uma escolha péssima, mas eles ainda colocaram a cereja no bolo ao posicionar o telão exatamente atrás do stand do Rock Band. Não estou brincando, tem horas que eu ouvia perfeitamente o cara cantando no Rock Band e não entendia nada do que o apresentador que estava dois metros na minha frente falava.

O que passa pela minha cabeça ao ver um descaso destes é que parece que a organização achou que o atrativo “mesas redondas sobre desenvolvimento de games” traria um público maior, graças aos cursos na área existentes no Rio e em Niterói, mas que uma vez que o ingresso já havia sido comprado, não tinha necessidade de se preocupar com a qualidade do negócio.

Nem tudo foi perdido, de fato. Infelizmente muitas vezes simplesmente não era possível ouvir o que os palestrantes falavam e quando se abria para perguntas, estas também não eram bem ouvidas. Ainda assim, às vezes era possível captar alguma coisa e entender o que os caras falavam.

Não vou citar nomes dos palestrantes ou falar de detalhes específicos, porque como disse, no fundo não dava pra ouvir tudo. Houveram falas do pessoal da acadêmia, através de alguns mestrandos e doutorandos da UFF, e do pessoal da indústria, com a fala da DonSoft.

Lá pelas sete da noite foi aberta a melhor mesa redonda pra mim, uma que falava sobre desenvolvimento de jogos independentes. À essa hora o barulho já era menor e deu pra ouvir melhor, mas ainda incomodava. O microfone passou em várias mãos e foi falado muito sobre as faces do desenvolvimento independente, os business games como boa oportunidade de negócios, um game designer comentou sobre jogos de tabuleiro e como este tipo de jogo ajuda no desenvolvimento de um profissional da área (dica dele: se você quer ser game designer, crie um jogo de tabuleiro).

Por fim, não foi uma perda total de tempo, mas a decepção foi grande. Ainda assim deu pra pegar alguma coisa boa no final de tudo e também conhecer algumas pessoas da cena indie aqui do Rio, e este tipo de contato sempre é interessante. No mais, espero que os desenvolvedores recebam mais carinho da organização em um eventual Rio Game Show 2010.

Obs.: Eu sou um péssimo fotógrafo, por isso todas as fotos deste post foram tiradas pela minha namorada, Adrian.

Edit: pessoal, só pra esclarecer. Deve ter tido algum tipo de problema no Wordpress e os comentários deste post foram apagados. Não sei se aconteceu em outros também. Os comentários não foram apagados de propósito, ok?

Possíveis posts relacionados:

1. Rio Game Show
2. Evento de Computação Gráfica Livre no Rio de Janeiro
3. Software Freedom Day RJ – evento de gamedev e software livre no Rio de Janeiro

Gandalf, por John Howe

Pesquisa de opinião aqui! Tava lendo os comentários de um post do Continue sobre desenvolvimento de jogos e aí o povo andou comentando sobre um tal de Tolkien. Então decidi postar este texto que aparenta ser fora de desenvolvimento de jogos, mas também é importante um game designer pelo menos saber quem ele é.

E quem é o tal do Tolkien? Ele é o criador do Hobbit e do “melhor livro de ficção que já li” Senhor dos Anéis. Eu li a série principal umas 3 vezes inteiras. Vi os filmes várias vezes. Não tenho os livros (mas ainda penso em comprar pra ter aqui em casa). Mas a importância do cara pra literatura fantástica é enorme. O cara criou um universo inteiro dentro do jogo. Criou religião, criou vegetação, desenhou e esboçou mapas. Criou uma mitologia própria. O cara foi tão perfeccionista que ele calculava de maneira quase precisa a distância pra chegar a pé de um ponto a outro. Eu me lembro de ter lido que ele consultava manuais de marcha do Exército e ele calculava a distância em dias prum personagem ir de um local a outro. Se você for analisar bem, o RPG atual (de mesa e de games) bebeu muita coisa do cara. Ele que praticamente popularizou este estilo de escrita e conseguiu virar lenda. Acho que o RPG e até os games não seriam o que são hoje se o cara não tivesse existido. Pode parecer fanboysismo demais, mas se for analisar bem, muita coisa se baseou em suas obras e outras obras fantásticas ficaram igualmente famosas.

Aí eu vi no Continue opiniões diversas sobre “tem de ler o Tolkien” ou não precisa ler o Tolkien pra fazer um RPG de fantasia medieval. Também tem pessoas que recomendaram outros autores e outros livros. É claro que o próprio Tolkien se baseou no folclore europeu pra se basear nas suas obras. Como o Beowulf, mitologia nórdica, contos ingleses, etc etc etc.

Aí eu pergunto a vocês: é realmente necessário entender o cara pra ser um bom game designer? Tudo bem que a resposta padrão é “não”, mas e pra criar um universo próprio? Ou será que algum filme, livro, desenho animado, etc não tenha se baseado direta e indiretamente dele e você não sabe? Complicado dizer. É claro que eu poderia me basear na mitologia egípcia que não teve influências do Tolkien (óbvio). Ou na mitologia grega (fanboy de God of War detected!). Realmente, não precisaria ler o Tolkien. Mas será que a mitologia grega é tão complexa quanto o mundo do Senhor dos Anéis, que possui talvez mais realismo que explicar os fenômenos naturais e a mecânica do planeta usando deuses e pessoas?

Que tipos de bases poderíamos utilizar? Se basear apenas em 1 autor é complicado (salvo se você fizesse uma obra derivada (e devidamente autorizada) de um autor), e aí a gente tem de caçar referências nos livros e na mídia atual. É claro que quanto mais conhecimento melhor: hoje os games são baseados em outras coisas, e quanto mais você conhecer e entender, será melhor pra bolar alguma mecânica original ou mesmo criar um universo próprio pra tentar enviar pra um BrGames.

Fica aberta a discussão. Dissertem com sabedoria!

[Imagem via Paolo Marzola]

Possíveis posts relacionados:

1. O desânimo em estudar e os ruídos que atrapalham os estudos

Como falei antes, a escolha do C++ será em virtude das empresas nacionais estarem atrás de gente nesta linguagem. O Flash eu posso desenvolver games simples e colocar no meu blog pra faturar grana com publicidade. E tem os meus gostos por game design e level design, onde posso criar um level e pelo menos me movimentar dentro dele com colisões configuradas.

Ou posso simplesmente criar um puzzle casual e distribuir por aí, só que aí entra aquela velha máxima que muita gente experiente vai dizer: planejar um puzzle não é pra qualquer um.

Simples: como planejar um quebra-cabeças? Como planejar a sua mecânica? Confesso que nesse ponto a situação muda bastante de figura. Todo mundo tem idéias, mas idéias de games de RPG com histórias medievais, idéias ambientadas no cenário atual (espionagem e guerra por exemplo), histórias futuristas, etc. Tudo envolvendo algo como herói percorre atrás de vilão que quer dominar o mundo etc etc etc. Isso é fácil planejar, mas pode ser inviável desenvolver (salvo se usar o RPG Maker). Se for em 3D então…

Num puzzle normalmente tem gráficos mais simples. Algo como um Bejeweled, Zuma, games 2D diversos ou mesmo uma versão do Tetris. Isso é rápido de se fazer até mesmo pra quem não tem muitas habilidades artísticas, mas que tipo de puzzle eu poderia fazer? Montar algo novo, que inove é algo muito, muito difícil. Praticamente todas as mecânicas de jogo possíveis já foram utilizadas em games de sucesso, limitando as opções do desenvolvedor. Fazer versões de games conhecidos pode até ser divertido e ter algo no portfólio, mas você acaba sendo mais um no mundo de desenvolvedores indie que criam versões do Pacman. Se você consegue inovar com games originais e ganha notoriedade, conseguir ir para uma empresa será mais fácil: todo mundo gostaria de ter no quadro de funcionários uma pessoa criativa que consiga criar novos games e formentar os lucros da empresa.

Pra terminar, aceito sugestões do que devo fazer nas férias de abril!

No related posts.

Estudo – Modelagem de cenários

O bom é que ele passa muitas dicas pro pessoal. A idéia em si é muito boa já os modeladores iniciantes e intermediários podem fazer perguntas e tanto o Merkel, que já é profissional, quanto outros usuários mais experientes, podem responder ajudando os modeladores.

Para quem se interessa por esta área vale a pena dar uma conferida. O tópico pode virar uma referência pra quem quer estudar a área de criação de levels.

Possíveis posts relacionados:

1. Dicas e especificações técnicas 3D para o Nintendo DS
2. Profissionais da indústria nacional dão dicas a quem quer trabalhar na área

Segue listagem:

Português

• A importância do Game Design
• [Para não Esquecer] Links com Recomendações de Livros de Game Design
• Disk Chocolate – Artigos de Game Design
• Top-5 livros de Game Design
• Alguns livros sobre Game Design
• Game Design, o que não fazer
• Ajuda com documento de design
• Criando Documento de Design
• Como Fazer um Projeto Real
• As idiossincrasias dos Design Documents
• O que é Document Design, Saiba aqui o que é Document Design
• A importância do Planejamento
• [livro] The Art of Game Design: A Book of Lenses

Inglês

• The Anatomy of a Design Document, Part 1: Documentation Guidelines for the Game Concept and Proposal
• The Anatomy of a Design Document, Part 2: Documentation Guidelines for the Functional and Technical Specifications
• The Process of Game Creation & the Game Design Document
• Game Design: Theory & Practice Second Edition Chapter 1
• The Art of Computer Game Design by Chris Crawford
• Tom Sloper’s Format for Game Design Specifications
• The Game Design Process
• Creating a Game – milestone 0 – Design Phase
• The Process of Game Creation & the Game Design Document

O desafio será saber montar os tópicos do game design. Acho que a parte mais difícil é estruturar bem as idéias e criar algo coeso e com algum sentido. Idéia todo mundo tem. Saber montar e deixar estruturado já é outra história!

Em breve devo postar aqui no GamedevBR um template que irei montar e utilizar em futuros projetos. Postarei mais a caráter de avaliação por parte de vocês, leitores do blog

Por fim, caso vocês conheçam outros links, postem nos comentários!

Possíveis posts relacionados:

1. É importante entender e estudar o J R R Tolkien e suas obras?

Você é artista 3D e quer um desafio de nível elevado? Entre no Dominance War, uma guerra amigável entre alguns dos principais fóruns de games do planeta, onde o objetivo principal é criar digitalmente em 3D um personagem, em formato lowpoly (com pouca taxa de polígonos. Um personagem para games). Mais informações:

Dominance War IV – Massive Art Challenge Online

A novidade maior deste ano é a entrada do fórum brasileiro 3D4All, que considero o maior fórum de 3D do país. Lá participam os principais e mais talentosos artistas 3D do Brasil e com certeza a entrada deles pela 3D4All pode ser bem interessante. Antes o pessoal teria de escolher um dos fóruns internacionais para participar. Agora poderão escolher a 3D4All e ajudar os brasileiros a conseguirem mostrar para o mundo o talento do pessoal daqui!

Bom, sobre o concurso, o mesmo começará no dia 20 de fevereiro e ainda não se sabe as regras e nem as premiações, mas não deve ser pouca coisa. Na véspera, caso saia novas informações, posto aqui uma nova chamada para a competição. A equipe do GamedevBR deseja boa sorte e a todos os brasileiros que forem participar.

[Via 3D4All]

Possíveis posts relacionados:

1. Vai começar a Game Developers Conference 2009
2. Slides de God of War 3 da Game Developers Conference 2009!

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)

Tamanho do pente - A quantidade de balas de cada pente da arma. Normalmente é de 20 a 50 balas.

Poder de ataque - É o poder da arma. Você pode definir isso por porcentagem ou por números fixos, mas isso vai depender do sistema de danos do seu jogo. Se você definiu que os inimigos e personagens terão dano numérico (o famoso HP os jogos de RPG clássicos) então você pode colocar uma quantidade de dano X e caso uma bala atinja o seu alvo, ela irá retirar um pouco de energia do seu personagem.

Agora, você também pode definir o tamanho do dano dependendo do local atingido. Se for na cabeça, você pode colocar um DANO TOTAL, fazendo o inimigo morrer e nos braços retirar uns 20% da energia. Você também pode apelas pro realismo e travar o movimento de um braço, mas em teoria os games atuais só retiram trechos da energia total do personagem, não importa o local atingido (desde que não seja na cabeça).

Além disso, tem também o fator colete: se o personagem estiver usando, o dano pode ser reduzido ou mesmo anulado, cabendo ao jogador e aos inimigos atirarem na cabeça pra acabar com o personagem. Em Syphon Filter (isso nos 3 games do PSOne) eles incrementaram ainda mais, colocando um aviso de Head Shot. Para o jogador isso é um pouco indiferente, mas para o inimigo, isso se tornou sinônimo de adrenalina para o jogador! No segundo game da série alguns inimigos vieram com este recurso programado e com isso quando você via um Head Shot na sua direção, ou você saia do raio de ação do inimigo ou você iria pro beleléu!

Ruído - É o barulho da arma ao atirar. Aí você pode colocar um raio de ação do barulho e dependendo da quantidade, isso pode acionar alguma ação para o inimigo, como procurar a origem do barulho, acionar um alerta ou, caso ele te veja, entrar em confronto com você. Nesse caso, caso você use um silenciador, o barulho será reduzido.

Raio de ação - É a distância de ação da arma, partindo do seu personagem até um determinado ponto, que pode ser medido em metros ou em alguma escala definida pelos programadores do jogo. É claro que o game design que vai definir em metros se baseando em referências ou inventando um raio de ação.

O melhor exemplo que já vi é no primeiro Parasite Eve, que inclusive mostrava no campo de batalha (na hora de selecionar o inimigo durante a luta):

Então caso o inimigo esteja fora do raio de ação o tiro pode não acertar. É claro que na vida real a possibilidade de acertar é de quase 100%, mas aí entramos novamente na questão do realismo. No caso dos rifles o raio aumenta, mas aí vai depender da visão do personagem na hora.

Quantidade máxima de pentes - Aqui entra a velha questão da mochila infinita da Lara Croft: quantos pentes poderá ser carregado pelo personagem? Em alguns games como Metal Gear existe uma quantidade máxima e que, ao atingir o máximo, não deixa pegar mais munição para ir levando na reserva. No Tomb Raider não existe este limite. No meu projeto eu decidi colocar uns 6 pentes, mas isso de maneira geral (não importando a arma). Se o jogador encontra 4 pentes de uma arma e depois acha 3 de outra, ele pode pegar apenas 2 (e completar os 6) ou jogar “no lixo” um da arma 1 e pegar a outra.

Quantas pode empunhar - Aqui é a quantidade de armas que o jogador poderá empunhar ao mesmo tempo. Armas pequenas, obviamente, podem ser usadas nas duas mãos. Rifles podem ser usados apenas um (a não ser que você seja tão fodástico a ponto de conseguir usar DOIS M16 ao mesmo tempo e sair metralhando os inimigos!), em virtude do peso e da precisão. Em games como Metal Gear Solid até mesmo armas pequenas podem usar apenas 1 das armas (usando as duas mãos), o que é mais realista.

Jack Bauer usa uma arma, mas deve mirar igual um Sniper!

Aparência - Entra na mesma questão do personagem: no jogo a aparência será armazenada num arquivo 3D. No game design, o desenvolvedor pode usar uma referência real e colocar fotos, isso se as armas forem de domínio público. Não sei se as armas tem direitos autorais  de uso de imagens, como nos carros de marca que aparecem nos games atuais de corrida, mas caso não as tenham, pelo menos o desenvolvedor pode inventar uma e descrever a arma no documento de design do jogo

Tempo de carregamento - O tempo de carregamento de cada arma caso a quantidade de balas acabe. Em tiroteios com ação elevada o tempo pode ser crucial para definir se o jogador consegue sair vivo do mesmo! Cada arma pode variar muito o tempo de carregamento e isso vai depender de uma série de fatores. O game designer pode procurar referências em outros games ou, caso ele tenha recursos, perguntar pra alguém das Forças Armadas quanto tempo os soldados demoram pra carregar uma arma de fogo. Outros fatores podem incluir a animação 3D do personagem e colocar elementos de peso e agilidade do personagem. Definir isso é algo bem complicado caso o game designer procure realismo, mas para simplificar, ele pode colocar uma porcentagem de tempo para os tipos de arma e ser mais feliz, não complicando a vida dos desenvolvedores.

Usa silenciador? - Aqui é simples: se a arma usa ou não um silenciador para diminuir o ruído. Antes de dizer que todas podem usar, lembre-se: dá pra colocar um silenciador num lança-foguetes? Ou numa granada? Isso também são armas e ter um atributo que define isso facilita para os programadores: basta na lógica do jogo ter um SE USASILENCIADOR=SIM, ENTÃO INSERE NA ARMA; SENAO, NAO INSERE.

Bom, acima eu coloquei alguns atributos e tentei explanar os mesmos. É claro que caberá ao game designer e/ou equipe definir o que é melhor para o jogo em reuniões de desenvolvimento. E como o artigo ficou bem extenso, ele terá uma terceira parte, onde irei colocar uma planilha com as armas que irei colocar no jogo.

Por fim, tentei explicar um pouco sobre sistemas de armas nestes dois artigos. É claro que se eu jogar outros games que usem armas de fogo posso ver outros elementos interessantes que podem ser usados no meu jogo. O problema é que dependendo do elemento usado o game perderá um pouco da originalidade, item muitas vezes buscado pela maioria dos desenvolvedores que querem criar algo diferente e único. Se tiverem qualquer comentário a respeito, podem fazê-lo sem problemas.

Possíveis posts relacionados:

1. Criando um jogo da memória em Java – Parte 01

Num game qualquer, uma arma do personagem possuem vários atributos, como o poder de ataque, defesa (caso de um escudo) e, no caso de armas de fogo (longo alcance), podemos também colocar o tempo de carregamento da arma, seu raio de alcance, o barulho do tiro e a quantidade de balas no pente. Eu peguei algumas referências de Goldeneye (e de outros games que já cheguei a jogar) e cheguei a algumas conclusões:

1 – Quantidade de armas que podem ser carregadas pelo personagem: O personagem principal poderá carregar 3 armas de fogo, sendo duas pequenas e 1 grande. Duas pequenas já que, em teoria, dá pra usar as duas mãos para armas pequenas. Já uma arma grande (como um rifle) é necessário usar as duas mãos e com isso eu defini pro personagem carregar apenas uma, que ficará nas costas, como em Splinter Cell:

Aí entramos num problema inicial: no jogo será possível trocar de arma? Se for possível, teria de ter um limitador de número máximo de armas e as mesmas teriam de ser colocadas na fase para poderem ser coletadas. Se eu defini apenas 3 armas (isso varia de cada projeto) caso o jogador encontre outra arma no local o jogo terá de limitar que a capacidade máxima e avisar ao jogador de que o número máximo de armas chegou ao seu limite. Aí você pode dar duas opções ao jogador: jogar uma arma fora e pegar a nova ou simplesmente não pegar a arma, aproveitando elementos como o pente de balas.

Ah, mas em Tomb Raider a Lara Croft carrega trocentas armas naquela mochilinha que não caberia muitas! Mas isso vai variar do grau de realismo do seu game. Se você preza a diversão, então você pode não limitar a quantidade de armas.Caso queira deixar com muito realismo, aí limite. Mas antes de fazê-lo, pense: isso pode deixar o jogo divertido? Ou o realismo demais pode prejudicar? Isso é assunto para outro artigo!

2 – Combinação de armas: cheguei a cogitar isso, de poder juntar várias armas e pegar os melhores atributos de cada uma e ter uma super-arma no jogo. Dependendo do tipo de jogo, isso pode ser até necessário, mas convenhamos: isso pode tirar um pouco a graça do jogador. Aí você pode colocar desvantagens em cada troca, para que o jogador pense se vale a pena ou não combinar duas armas. Por exemplo: se eu tenho duas armas quaisquer e qao combiná-las o ruído e a quantidade de balas pode diminuir

Mas isso varia de cada caso. Tudo tem de ser analisado. Teoricamente, na vida real, é bem difícil ter alguém que consiga, em tempo hábil, tirar partes de uma pistola e colocar em outra. Só pensei nessa possibilidade já que seria uma mecânica de jogo eficiente.

No meu caso eu retirei esta mecânica já que ficaria mais difícil projetar e executar essa funcionalidade. Aí entra uma questão bem interessante do game design: o conhecimento de várias áreas do desenvolvimento de jogos. Antes de pensar numa funcionalidade, pense: se eu fosse programador, seria fácil implementar isso numa linguagem? OK, muitos não tem conhecimentos de programação, mas acredito que a maioria das pessoas conseguem pelo menos inventar um modus-operandi qualquer. Ou seja: fazer, passo a passo, como seria esta funcionalidade. Exemplo:

1. Pegue duas armas no menu.
2. Defina quais atributos podem ser usados numa troca com outra arma. Exemplo: transferir o tamanho do pente de balas.
3. Analise se a outra arma pode aumentar o tamanho do pente. Se puder, então troque a quantidade pela nova arma.
4. Exia isso ao jogador.
5. Pergunte ao jogador se é isso que ele quer.
6. Caso o jogador queira, grave isso e deixe pronto para uso do jogador.
7. Caso ele não queira, volta a posição inicial das armas.

Bom, confesso que o exemplo acima é um exemplo muito ruim, mas acredito que você conseguiu entender a situação. Acima eu defini como seria a funcionalidade de uma combinação direta entre duas armas. E não irei colocar no game design do jogo, já que o nível de complexidade é imenso. E como sou programador, quero cortar algumas possíveis dificuldades que posso ter caso eu esteja na equipe de programação do jogo (caso eu chame uma equipe).

3 – Upgrade de armas: Eu vi a palavra upgrade de armas ao ler sobre o Resident Evil 5 numa revista ontem e confesso que não pensei nisso neste artigo, mas é algo a se cogitar no futuro. Dependendo do projeto você pode espalhar no jogo objetos que possam melhorar as armas, sem precisar de fazer combinações. O normal é ter um silenciador, mas você pode colocar outros apetrechos. Isso vai variar de jogo para jogo.

4 -Atributos da arma: Chegamos ao ponto onde queria chegar! Como no Goldeneye e em vários games de tiro, cada arma possui atributos diferenciados que podem fazer diferença na mecânica de jogo. Por exemplo: se o raio de ação seja muito pequeno, caso o inimigo esteja muito longe, o dano causado pela bala ao atingir o alvo pode diminuir com a distância. E isso pode ser definido ou não pelo game designer.

Então, me baseando nos conhecimentos atuais que tenho, esbocei no StarUML uma classe de armas de fogo:

Bom, para um iniciante como eu, até que ficou bastante satisfatório! E a lista é baseada nos conhecimentos atuais. Acredito que se eu tivesse jogado mais games de tiro, poderia colocar algum elemento interessante de algum jogo. Dica para futuros desenvolvedores: jogue muito. Quanto mais referências mentais você tiver, melhor na hora de projetar algum elemento de um game.

Como o artigo ficou enorme, vou continuar no próximo artigo, onde explicarei cada atributo e colocarei uma tabela com alguns exemplos que inventei para o projeto. Caso queira comentar, criticar ou dar sugestões sobre este assunto, pode comentar sem problemas!

Possíveis posts relacionados:

1. Criando um jogo da memória em Java – Parte 01

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.

Então acho que pode ser bem útil também usar UML para desenvolvimento de jogos, pelo menos para projetar e ter documentado como que serão alguns elementos de seu jogo. A primeira coisa que vem na mente é numa estrutura de personagens:definir como que eles serão (idade, nome, aparência, sexo) e que métodos eles poderão fazer (atacar, defender, usar magias). Para este artigo e para os próximos, usarei o StarUML, software gratuito de modelagem UML. E como forma de estudra, andei fuçando um pouco no software e gerei a seguinte estrutura:

É claro que o nível de complexidade do seu diagrama de classes vai depender de cada projeto. Aqui, por simples capricho, eu quis detalhar a aparência do personagem, o que pode não ser necessário, cabendo ao jogo ter a aparência definida num objeto 3D já devidamente texturizado e completo (um character). Mas para fins de game design, cada personagem terá de ter a sua aparência detalhada nos mínimos detalhes, para que o game/character designer possa passar para os artistas como que os personagens deverão ser.

Pra terminar, caso queira baixar o diagrama, pegue-o aqui. Para conhecer mais sobre orientação a objetos, comece por aqui.

No related posts.

Último texto do ano e para deixar vocês com alguma coisa pra fazer deixo um texto bem interessante do Girls of War, onde é comentado sobre as coisas estranhas dos RPGs normais:

Coisas estranhas do RPG

Basicamente a Vivi Werneck juntou muitos clichês básicos dos RPGs clássicos de games, como o herói dormir e no dia seguinte acordar todo inteiro (série Final Fantasy!), os monstros terem dinheiro e ítens diferentes da sua anatomia (como poções de cura e etc, isso para muitos monstros pouco racionais biologicamente) e outros. É claro que sem muitos elementos citados os games deste gênero seriam muito chatos, mas sempre é bom tentar ir para um caminho diferente do habitual na hora de desenvolver um jogo, sem perder os elementos de diversão deste gênero.

Pra terminar, uma mensagem off: Feliz Ano Novo a todos os leitores!

Possíveis posts relacionados:

1. Conheça alguns dos profissionais brasileiros que estão no exterior
2. Vídeo e infos do Project Natal, a nova revolução dos videogames