Como falei com o Adauto, o Getting Real "é a coisa mais genial que eu li sobre gerência de projetos nos últimos 8 anos. É tão genial q chega a assustar." Ele vai diretamente contra tudo que a teoria nos empurra a fazer. O livro não passa de uma coletânea de práticas e estudos de caso do desenvolvimento dos produtos da 37signals, uma empresa de chicago que está no mercado desde 1999 fazendo software web. Por mais idiota que isso possa parecer (e, à primeira vista, ISSO PARECE), a 37signals produz softwares que, intencionalmente, FAZEM MENOS QUE A CONCORRÊNCIA. Antes de você desistir de continuar lendo saiba que são eles por trás do framework Ruby on Rails...

O próprio livro se define assim:

(Getting Real) é sobre pular todas as coisas que representam a realidade (cartas, gráficos, caixas, setas, esquemas, wireframes, etc.) e realmente construir a coisa real.

(Getting Real) é menos. Menos massa, menos software, menos funcionalidades, menos papéis, menos tudo que não é essencial (e a maioria do que você pensa ser essencial realmente não é).

(Getting Real) é permanecer pequeno e ser ágil.

(Getting Real) inicia com a construção da interface, ou seja, as telas reais que as pessoas irão utilizar. Começa com as experiências reais dos clientes, construindo a partir disso para trás. Dessa forma você obtém a interface adequada antes de obter um software errado.

"Ah Tiago. Essa parada ae é de desenvolvimento de sistemas na web. Eu só quero fazer um jogo. Prá quê você me manda ler isso?". Pois o Getting Real é justamente isso: cair na real, limpar tudo aquilo com o que você NÃO precisa gastar tempo agora e deixar para pensar no futuro. É sobre não pensar agora em resolver um problema que ainda não é um problema. É sobre não perder incontáveis dias otimizando uma rotina que só vai precisar ser otimizada quando você tiver 500 usuários ao mesmo tempo. É sobre não inchar o seu design, enxugar seu escopo, fugir da febre dos padrões e fazer SOMENTE o necessário para que seu projeto funcione com a qualidade que ele exige no momento.  Essas dicas, apesar de voltadas para uma aplicação web, são absolutamente verdadeiras para diversos outros tipos de projetos. Além disso, sua idéia principal pode ser adotada em todo e qualquer tipo projeto, seja de software ou não. Vai depende somente da forma com que a empresa encara eles.

Falando em empresas, As desenvolvedoras de jogos online já utilizam tais conceitos há anos: lançam atualizações constantes para seus jogos, aumentando gradativamente sua complexidade, começando a subir uma escada lá debaixo no primeiro degrau. Além disso, fazem correções de bugs críticos em tempo real, horas após sua descoberta. No final, o produto cresce naturalmente e não só ao trocar de pele: você se preocupa com pequenos problemas por vez, faz pequenos designs por vez, implementa pequenas novidades  por vez e tira pequenas funcionalidades por vez, tudo constantemente, em pequenos períodos por vez.

O Getting Real vai muito além de qualquer livro de gerência de projetos. Ele é uma coletânea de dicas que se torna seu livro de cabeceira já nos primeiros 15 minutos de leitura, daqueles que você não vai deixar de mostrar para todo mundo. E não tem essa de desculpa para não ler: ele é fácil, rápido, direto, tem versão em português muito bem traduzida e, ainda por cima, gratuita para ler na net. Tá esperando o quê para Cair na Real também?

Quem é leitor antigo lembra que postei, ainda no início do Nuss... E agora?!? uma série de artigos (parte 1, 2 e 3) entitulada "Um por todos e todos por um: as diversas profissões necessárias para fazer um jogo". Se gostou da série não pode deixar de conferir o da G1.

Agradecimetos ao Rafael Barboza pela indicação do link pelo twitter

Pense em um jogo onde o seu personagem muda de habilidades no decorrer da aventura. Não importa se pegando itens ou ganhando poderes especiais, o importante é que saibamos o quanto de trabalho isso dá para a programação. “Ué Tiago, não é só criar as classes de cada um desses poderes especiais e ir transformando o personagem em outro objeto?”

Na realidade, isso é só o início dos nossos problemas. Quer ver só: vamos pensar no Mario. Em um jogo clássico como o Super Mario Bros. ele tem as seguintes formas: Mario, Super Mario (quando pega um Super Mushroom), Mario Flor de Fogo (quando pega uma Fire Flower), Mario Invencível (quando pega um Starman) e, claro, Mario Morto, quando ele morre. Para que isso funcione, o Mario precisa de um conjunto de ações simples: Pegar Cogumelo, Pegar Starman, Pegar Fire Flower, e, como nem tudo é perfeito, ele também tem que poder, Encostar em um inimigo.

“E o que isso tem a ver?” Se você ainda não percebeu, cada um dessas formas do Mario tem o mesmo conjunto de ações: seja um Mario, um Mario Flor de Fogo ou qualquer outra forma de Mario, todos têm que poder encostar em um inimigo, pegar um cogumelo, um starman ou uma fire flower. O que muda é o comportamento daquela forma de Mario perante aquela ação. Não entendeu? Bom... enquanto Mario encosta em um inimigo e morre, Super Mario encosta em um inimigo e volta a ser Mario. A mesma ação (encostar em um inimigo) engatilha 2 ações diferentes (Virar Mario Morto e Virar Mario).

Mapeando todas essas relações entre as formas do Mario temos...

Na 1a coluna, temos os estados iniciais. A 1a linha tem as ações e o corpo da tabela é a forma que o Mario assume após aquele evento. Por exemplo, Mario pega um cogumelo e vira Super Mario. Esse mapeamento de troca de formas é o que chamamos de Máquina de Estados: ela indica quais formas aquele objeto tem (o que chamamos de estado), quais ações aquele estado pode realizar e qual novo estado ele vai assumir após realizar tal ação.

Quem joga os jogos do Mario sabe que, na realidade, o estado Mario Invencível depende do estado onde o Mario estava anteriormente. Então teríamos além de Mario Invencível, as formas Super Mario Invencível e Mario Flor de Fogo Invencível... Olhe como adicionar essa simples característica aumenta muito nossa complexidade: no nosso exemplo, temos 4 ações x 5 formas = 20 métodos a serem implementados. Aumentar 3 estados significaria passar para 4 ações x 7 formas = 28 métodos.

“Até aí tudo bem, Tiago!” Sim, mas o problema vem agora: também precisamos saber qual ação foi executada e em qual forma o Mario estava. Para fazer isso, precisaríamos de um conjunto imenso de testes aninhados que fariam, para cada ação:

Se o jogador pegou um Cogumelo:
    está na forma Mario, troque para a forma Super Mario
    está na forma Super Mario, mantenha-se como Super Mario;
    está na forma Fire Flower Mario, mantenha-se como Fire Flower Mario;
    está na forma Mario Invencível, mantenha-se como Mario Invencível;
    está na forma Mario Morto, mantenha-se como Mario Morto;

... muito trabalho, né não? Além disso, para cada uma dessas novas formas, teríamos que ir nesse conjunto de testes aninhados para adicionar as novas regras. Estruturas mais complexas seriam tão trabalhosas de gerenciar que se tornariam inviáveis. Essa complexidade crescente é das grandes vilãs quando trabalhamos com estados: a cada estado adicionado temos que mapear todas as relações entre ele e os estados já existentes programando suas relações.

Para resolver esse problema de manutenibilidade, utilizamos o Padrão de Projetos State (ou “Estado”). No próximo artigo implementaremos essa Máquina de Estados do Mario. Então, até lá!

Imagens de http://mario.wikia.com

Prestem bastante atenção quando o Jeff Atwood diz que "você deve normalizar quando os dados te disserem para fazê-lo" e não simplesmente por ser mais elegante ou teoricamente correto. Isso não significa que seu código deva ser anárquico, completamente contrário às regras de boa programação, e sim que ele seja adequado ao que escopo que o projeto prevê.

Para quem quiser mais informação sobre essa lógica, coloquei aqui no Nuss... e Agora?!? há algum tempo o artigo Padrões de Projeto: questão de bom senso. Ele fala exatamente sobre essa briga entre os pontos de vista de "faça por ser útil" e "faça por ser elegante" focado na análise de sistemas.

Lembrem-se: "Adequação, não perfeição"

Os Padrões são receitas prontas e já muito testadas para resolver problemas recorrentes: aqueles que milhares programadores tinham. Logicamente falando, eles são para simplificar a nossa vida. Se você pode dizer "Ih. Já vi isso antes. A gente resolve isso com o State", não tenha dúvidas em aplicar o padrão. Ele vai fazer maravilhas pelo cronograma e tirar da cabeça dos programadores mais um problema.

Agora... uma coisa ninguém pode negar: padrões, sejam os de projeto quanto arquiteturais, sempre complicam programas simples. Se você tem um jogo simples de tabuleiro assim...

... sabe como ele poderá ficará depois de aplicado o MVC?

Não preciso nem perguntar se alguém notou como a complexidade aumentou, né? E olha que o MVC é só um padrão de arquitetura, hein? Imagina ainda adicionar estados para as TPeca e TTabuleiro, um Singleton para a TJogo...

Os padrões de projeto tornam as coisas mais coesas, porém aumentam o acoplamento geral de seu programa, pois as classes de um padrão são extremamente dependentes entre si. Eles aumentam muito a complexidade do código, coisa que muitas vezes não é necessário. Voltando ao exemplo acima, alguém acha necessário aplicar o MVC à um projeto que só tem 3 classes?

Usar Padrões de Projeto é uma questão de bom senso: utilize-os só quando eles simplificarem o problema, nunca para jogar mais gasolina no fogo que você tenta apagar, ok?

Aí eu vejo pessoas na Unidev que ridicularizam os novatos com o já clássico "vou fazer um MMORPG". Ta, é realmente absurdo ver um cara falar "sou iniciante" e "quero fazer um MMOG" na mesma sentença. É como entrar na faculdade de engenharia e querer montar no quintal de casa a torre mais alta do mundo.Agora, sejamos francos: os caras são iniciantes e, graças aos programistas de revistinha de banca, o mercado foi banalizado: qualquer um acha que é muito fácil fazer qualquer coisa. Então, ao invés de metralhar (mais) os sujeitos falando "isso não vai ser terminado", pq não dizer pra eles "por quê não vão terminar"?

É pra isso que eu vou começar essa lista e esperar que vocês a debatam, enfeitem, critiquem e aumentem. Eu vou editando assim que novas coisas forem surgindo e espero que tenhamos uma lista bem grande de motivos com os quais se preocupar. Ah, é claro, é também pra ter uma lista para linkar toda vez que alguém vier com mais um "eu sou iniciante mas vou fazer um MMORPG".

Então, vamo lá. Listando sem ordem de prioridade, os erros mais comuns nos quais consigo pensar:

• pessoas querendo "ajudar" ou "dar idéias" não são úteis ao projeto por incharem demais o design: se você não tá dando conta de fazer tudo a tempo, não vai terminar nunca com aquele "eu tive uma idéia boa..." adicional toda semana. Um design é o que deve ser seguido e terminado. Aí sim arruma-se mais coisa prá fazer.
  
  Links relacionados:
  Design Inchado

• se já é difícil gerenciar muitos profissionais que ganham e trabalham 6h por dia juntos, imagina 30 profissionais que nunca se viram e tão trabalhando no período de lazer... DUVIDO que alguém deixe de ir àquela festa fodônica no fim de semana, ou deixe de assistir aquele filme pela 15a vez só pq o seu cronograma tá apertado. Ah, falando nele...
  
  Links Relacionados:
  Atraso em Projetos de Horas Vagas

• Inexistência completa, total e absoluta de um cronograma a se seguir. O cronograma é uma tabelinha que, resumidamente, diz quem tá fazendo o que, há quanto tempo tá fazendo e quando tem que terminar de fazer. Assim vocÊ controla o que tá atrasando mais e quem tá à toa, podendo ser empregado em outra parte do projeto. Cronogramas nesses projetos são tão raros quanto lançamentos para Atari.

• Os grupos são sempre uma porrada de profissionais de conhecimento, no máximo, mediano. Um jogo é algo avançado e extremamente difícil de ser feito até mesmo quando todo engambiarrado.

• Cadê a Especificação de Requisitos? Somente um "vamos fazer um jogo" é absurdamente raso. É difícil achar alguém com conhecimento profundo das tecnologias que vão ser utilizadas nem do público alvo ao qual se destina. Isso, claro, sem falar no design básico: como o jogo vai ser, o que ele vai ser e como vão jogá-lo. Isso tudo se reflete nos profissionais que se consegue. Acaba-se criando o que eu chamo de projeto Torre de Babel: você tem umas 30 linguagens de programação diferentes e artistas em 2d, 3d, 4d e 5d.
  
  Links Relacionados
  A Roda do Tempo

• Gerência é algo em 15º plano. "Gerência? Não não, queremos só fazer um jogo". Quando muito, o cara que resolve juntar o pessoal saca um cado de programação. Sem gerência nada vai pra frente: você precisa impor limites, cobrar resultados e motivar pessoas. Precisa mover recursos, precisa solucionar problemas. Isso tudo requer estudo profundo e extenso ou então esteja preparado para muita bateção de cabeça.

Algumas coisas aí estão realmente necessitando de uma explicação mais profunda, como o Cronograma. Por isso, assim que eu abordar esses documentos de desenvolvimento aqui, prometo eu linká-los diretamente aqui.

Além disso, peço que vocês também enviem-me links sobre os tópicos aqui relacionados, fazendo essa biblioteca crescer cada vez mais!

Antes de tudo, leiam esse post do Rodrigo Flausino sobre a Blizzard e o Warcraft. Já leu? Então agora a gente pode começar a destrinchar o problema. O que vou expor aqui é um pensamento que pode vai mudar drasticamente dependendo do projeto, principalmente quando levamos em conta coisas como escopo, público-alvo e recursos. Mas pensando na Blizzard, duvido muito que tenha faltado alguma coisa ou que algum limite intelectual tenha sido alcançado. Isso faz com que tracemos uma linha possível: mercado.

"Mas Tiago, não pode ser problema nos servidores deles?". Não, não pode. Gráficos não afetam em nada o tráfego de informações. Eles rodam localmente, não vêm de um servidor. Portanto, se você joga Tibia ou Lineage, o que vem pela net é virtualmente a mesma coisa: pacotes com informações de localização, características e ações de personagens, monstros e NPCs. Aliás, o Tibia é conhecido por pesar mais a rede que jogos de gráficos bem mais avançados, como o Silkroad Online. Portanto, ta mais que provado que a carga na rede não pode ser o foco dessa tal decisão. "Mas se não é, então o que será?"

Ouvi por aê que o World of Warcraft já é relativamente pesadinho do jeito que já tá, não sendo um jogo para qualquer máquina. Pode ser que estejam perdendo um cado de clientes que simplesmente não conseguem jogar por limitações de hardware, como placas de vídeo ou memória RAM. Se for o caso (e acredito que seja), a Blizzard está querendo ampliar seu público-alvo, alcançando uma fatia maior do mercado.

"Então eles estão certos em parar de melhorar graficamente seu jogo, já que isso vai fazer com que parem de perder clientes", você diz. "Não! Eles estão justamente ERRADOS em fazer isso" eu respondo e vou explicar por quê eu acho isso.

A Blizzard pensou muito mal em parar de melhorar graficamente seu jogo pois parar no tempo é burrice e quem pára é atropelado. Ponto final. "Mas Tiago, estamos falando de WoW, não de qualquer coisinha aí." É, estamos falando de WoW. Mas antes dele tinha um MMOG foderoso que dominava o mercado... um que foi atropelado pelo WoW tão logo tenha chegado a data de lançamento do último. Entendeu o que eu quis dizer?

Não é só por ser uma grande empresa que a Blizzard não vai errar. Olha o lixo em que transformaram o Mortal Kombat, olha o fracasso que tem sido os últimos jogos do Sonic, olha o fiasco que foi o Crysis. Todo mundo erra e, ao invés disso, deveriam ter pensado no óbvio: configurações gráficas abrangentes.

"Mas hein?" Ah gente, sabe aquele basicão do Age of Empires III de desativar tanto efeito gráfico que o jogo roda numa placa de vídeo arcaica de 64mb? Pois então, eles estão fazendo com que o MESMO jogo lindo para as máquinas absurdamente potentes seja jogável pelas máquinas cansadas de 5 anos atrás.

É um assunto bem complicado, principalmente pois hoje em dia as pessoas acham que um jogo bom é um jogo que tem gráficos bons: se você não os tem, já vai ter que suar pra mostrar que o jogo é bom. À quem duvida disso, recomento lembrar-se de como falaram merda do Zelda: Wind Waker por usar cel shadding ao invés dos gráficos realistas que mostraram no lançamento do Game Cube.

Essa escalada rumo à perfeição cria jogos injogáveis pela maioria absoluta da população mundial. Excessos e utopias do gênero foram o que jogaram o Atari Jaguar no lixo, foram o que jogaram o Crysis no lixo e são o que está jogando o PS3 no lixo. Aplaudo a Blizzard em ir contra essa tendência: critico mesmo é a forma com que definiram a situação.

Então fica só um artigo de ponto de vista pessoal com uma pitada de desabafo e experiência adquirida com o erro de outros jogos. Afinal de contas, jogar também é aprender!

Um abração e até a próxima.

É gente, tá aí a 2a parte do meu exercício de Game Design. A 1a parte você encontra aqui e o exercício você encontra lá no blog do Flausino, aqui. Dessa vez vou destrinchar um cado o que exatamente vai ser o jogo, como ele vai funcionar, as tecnologias que eu quero usar e coisas do gênero. Paratal feito, vou usar um documento de gerência chamado Especificação de Requisitos. Como o assunto é um tanto quanto extenso, falarei sobre a confecção de uma num outro artigo. Na situação atual, basta que vocês saibam que ela é muito boa para esboçarmos o que temos que fazer no nosso projeto, sem entrar em grandes detalhes sobre eles. Quando bem feita, ela pode ser a base do seu Diagrama de Casos de Uso, Cronograma, contrato e também do seu Game Design. Poderosa, não?

Vamos logo ao que interessa, a Especificação de Requisitos:

A Roda do Tempo é um jogo completamente 3D multiplataforma feito em C++ e OpenGL. Permite que o jogador salve seu progresso em pontos específicos utilizando um sistema de estados salvos em arquivos, estrutura que facilita a troca de jogos salvos pela internet. Sua duração varia de acordo com a quantidade de auxílio para resolver os quebra-cabeças, mas pretende-se uma diversão entre 10 e 15 horas.

É um jogo predominantemente de ação, exploração e solução de quebra cabeças, idealizado para concorrer diretamente com o jogo Tomb Raider (Eidos). O jogador, na pele do explorador Jonathan Williams, tem a missão de desmembrar todas as 36 áreas periféricas de uma gigantesca cidadela circular em ruínas coletando 36 medalhões. Cada medalhão é uma fatia da chave que abre a última área da cidadela de Taklan, da qual sabe-se somente que é protegida pela Sala da Corrente. Essa 37ª área é o centro de tal cidadela, localizada no topo de uma torre.

Para decifrar os mistérios e solucionar os quebra-cabeças, o jogador pode fazer com que Jonathan corra, se abaixe, escale muros e outras superfícies íngremes, empurre e puxe objetos, atire, se arraste, escorregue, role, lute com seu facão, se pendure em cordas, balance em cipós, nade, mergulhe e até se impulsione com a ajuda de galhos. Os comandos são simples e condicionais: se Jonathan está na águaeles mudam para refletir o novo ambiente em que se encontra. Se estivesse correndo, poderia realizar outras ações.

Taklan possui ambientação geral de um templo asteca, construído em pedra mas já em ruínas, desgastado pelo tempo e pelas plantas que passaram a nascer em sua arquitetura. Dentro de seus muros Jonathan e Bobby encontrarão ambientes variados, incluindo restos de uma vila, um templo em ruínas, uma cripta dentro de uma pirâmide, um lago, rios, cavernas, uma floresta e uma série de passagens subterrâneas.

Tais áreas não são fases isoladas. Ao contrário: fazem parte de um gigantesco mapa livre, como no jogo Banjo Kazooie (Rareware). Será necessário que o explorador volte várias vezes às áreas passadas para continuar explorando-as com cada um dos artefatos especiais que encontrará na cidadela, no melhor estilo The Legend of Zelda (Nintendo). Só assim o jogador conseguirá encontrar todos os segredos ocultos em Taklan. Estes artefatos especiais conferem ao explorador novas habilidades, como aumento de velocidade, resistência a elementos e aumento de força.

Ainda sobre as áreas da cidadela, elas não são temáticas. Ao contrário, obedecem ao mapa da região. Dessa forma, pode ser necessário atravessar 2 ou mais áreas para ter acesso completo à um setor das ruínas, estilo de exploração muito bem utilizado no jogo Super Metroid (Nintendo).

Comparado com Tomb Raider, uma grande mudança de jogabilidade é a parceiria entre Bobby, o cão, e Jonathan, o explorador. Extremamente inteligente, o cão é capaz de entender diversas ordens do homem (diferenciadas pelo tipo de assobio), como pisar em ladrilhos, puxar correntes, farejar ou até atacar inimigos. Em algumas áreas onde o homem é muito grande para se mover, o jogador pode assumir o controle do cão como no jogo Overlord (Codemasters).

A maior dificuldade é que Bobby é um personagem bem diferente de Jonathan e, portanto, possui características bem diferentes de tal. Por várias vezes, o cão é necessário para realizar uma tarefa, mas não consegue chegar onde Jonathan está. Inicialmente, Jonathan pode simplesmente carregar Bobby, mas a dificuldade incremental do jogo faz com que seja necessário criar caminhos para que o eles cheguem aos locais desejados, o que torna os quebra-cabeças muito mais complexos e desafiadores. Enquanto não está sendo ordenado, Bobby seguirá Jonathan por onde ele for.

As ações de Bobby são rosnar para inimigos, farejar, correr, atacar inimigos, puxar coisas pequenas, carregar coisas pequenas, parar em algum lugar, pular e escalar superfícies limitadas (não verticais como as de Jonathan). Bobby também pode nadar na superfície da água e mergulhar por um tempo bem mais curto que Jonathan, normalmente para pegar itens. Vale lembrar que, como acontece com Jonathan,suas ações dependem do ambiente onde se encontra.

Durante toda a aventura, flashes de memória explicam ao jogador o porque da aventura, algumas vezes introduzindo dicas sutis para que ele desvende segredos e adquira artefatos. Alguns destes flashes são interativos, sendo considerados como fases e, portanto, não podendo ser re-explorados. Esses flashes interativos não afetam diretamente a aventura, mas incluem dinamismo no desenrolar da história.

A diversão não acaba com o final do jogo: o jogador pode reiniciá-lo com A Roda em mãos. Com uma limitada manipulação do tempo em jogo, ele poderá alcançar locais que não conseguiria no jogo normal, alcançando 100% de exploração. Poderá, por exemplo, entrar em uma caverna antes que uma cachoeira a cubra, ou então correr por uma ponte que ele deve derrubar para alcançar uma área nova.

A Sala da Corrente

A Sala da Corrente é assim chamada por esse nome na 1ª vez que Jonathan a vê e é assim referenciada por várias vezes no jogo. Mais tarde o jogador descobre, num flash, que era assim que as anotações de John falavam sobre ela.

Fica localizada no exato centro matemático de Taklan, numa torre tão alta quanto as muralhas da cidadela. A torre possui uma espécie de labirinto coalhado de armadilhas que protege a sala.

Visualmente possui forma circular e é feita completamente de pedra. Há goteiras em algumas áreas e rachaduras no teto deixam passar a luz do dia. O chão e paredes possuem musgo e alguns cogumelos, mas a característica marcante é a grande corrente que desce do teto e atravessa o chão por um buraco.

Há pilares em toda a extensão das paredes, cada um com uma fenda em forma de fatia de pizza: nesses pilares o jogador deve inserir os medalhões para, só assim, acessar a 37ª área.

A Música

A trilha sonora de A Roda do Tempo é predominantemente orquestrada, com arranjos que mesclam música indígena e rock. Os vocais são tratados como instrumentos à parte, já que nenhuma das músicas tem letra específica.

Os inimigos

Os inimigos não são comuns como em outros jogos. Compreendem animais em sua maioria, mas também pode-se encontrar eventuais remanescentes da expedição que Glenn banca que estão dispostos a acabar com você por um pagamento extra.

A ação acontece principalmente nas armadilhas da cidadela, como paredes que se movem ou salas que se inundam. Por vários momentos também é possível batalhar diretamente contra Glenn que, normalmente, está em posições de vantagem estratégica (batalhas clássicas do universo de Resident Evil, da Capcom).

Mas como sempre passo um estudo de caso de exemplo, eu vou escolher o Star Fox 64? O QUÊ?!? VOCÊ NÃO CONHECE O STAR FOX 64?!?!?! Ele é um jogaço de 1997 pro Nintendo 64. Sozinho o jogo já era absurdamente maneiro, mas ficava muito melhor quando você jogava com o Rumble Pack, que tremia o joystick quando você batia ou atravessava uma explosão. Foi um dos melhores na sua época e por isso vou usá-lo, além de ter lembrado dele por qualquer aleatoriedade universal.

• Descobrindo o jogo:

Sempre antes de encontrarmos os CdUs de um programa, precisamos identificar o uso desse programa. Um documento de design do jogo não é muito válido, mas o pessoal do PMBOK pode (E DEVE!) usar a Especificação de Requisitos. Ela é um texto beeeeem parecido com o que eu escrevi aí embaixo pro Star Fox 64

Logo no início do jogo pede-se que você aperte o START para escolher o modo de jogo. Você escolhe um dos diversos modos e confirma novamente. Vamos escolher o modo Main Game, ok? Escolhido seu modo, aparece na tela um Arwing girando e a história do jogo, nada fora do comum. Confirmando de novo, você é jogado na tela do Sistema Solar Lylat, (se não me engano... faz tempo que joguei isso) onde deve-se escolher qual área será seu próximo destino. Caso você tenha mais de um possível destino, pode escolher um deles tranqüilamente. Caso queria refazer a fase anterior, você perderá uma vida.

As fases se dividem em 4 tipos: No Blue-Marine, o submarino, no tanque Landmaster e nas Arwings, as naves, tanto no típico “vai direto pra frente” quanto no “gire por esse lugar até completar a fase”, que eles chamam de all-range mode. O conjunto de ações que você pode realizar depende do tipo de fase, mas normalmente você atira, carrega o tiro teleguiado, lança a bomba, se move, acelera, breca, dá um barrel roll (giro em parafuso) e um loop.

Quando a fase termina, você vê uma tela onde os pilotos conversam e, logo em seguida, o dano das naves de suporte é recuperado baseado na contagem de inimigos que você destruiu na fase. Caso alguma nave tenha sido abatida na fase anterior, ela será recuperada para a próxima.

Com esse basicão aí nós podemos começar a definir alguns dos casos de uso que o Star Fox 64 tem.

• Descobrindo os CdUs:

Já que cada interação é um CdU, vem a hora de definir quais são os nossos CdUs. Lendo o texto, marcamos cada coisa que o usuário pode fazer. Nesse exemplo aí a gente pode tirar:

1. Sair da tela principal
2. Escolher modo de Jogo
3. Cortar introdução
4. Selecionar fase
5. Escolher fase
6. Voltar à fase anterior
7. Atirar
8. Carregar tiro teleguiado
9. Lançar tiro teleguiado
10. Lançar bomba
11. Mover veículo
12. Acelerar
13. Brecar
14. Realizar Barrel Roll
15. Realizar Loop

Nesse curto texto conseguimos identificar 15 interações diferentes, ou seja 15 Casos de Uso diferentes. É importantíssimo deixar claro que, mesmo coisas simples como “acelerar” ou “atirar” não devem ficar por fora da lista: CdU podem ser extremamente simples ou incrivelmente complexos, depende de sua aplicação.

Algumas pessoas trabalham com CdUs extensos, mas eu não gosto de fazer isso. Fica como dica tentar dividir aqueles extremamente complexos em diversos pequenos, como eu fiz na lista. Não há um jogar. Ao invés disso, eu desmembrei ele nas diversas ações que constituem jogar, como Acelerar, Brecar, Atirar e Realizar Loop.

Já com a lista em mãos, precisamos guardar isso tudo de uma forma clara de se entender. É claro que já há uma ferramenta na UML para tal e é dela que vou falar agora. Vamos desenhar isso tudo num Diagrama de Casos de Uso.

• Desenhando o Diagrama de CdUs (DCU):

Um DCU é extremamente simples, porém poderoso. Ele é uma forma infalível de definir o grau de interação com o usuário, o que gera uma maior complexidade na interface. Vale lembrar que a quantidade de CdUs não indica a complexidade lógica de um programa: jogos normalmente possuem uma quantidade de CdU inferior ao número de CdUs, mas de complexidade unitária muito maior.

Para desenhar um DCU, nós jogamos um bonequinho ali que chamamos de ator. É esse ator quem realiza as ações do CdU. Se iniciar sistema é feito só por administrador, temos que ter um ator administrador lá no dagrama. Ah, importante: cada CdU está relacionado com pelo menos um ator, mesmo que indiretamente.

Os CdU são as elipses, cada uma com seu respectivo nome. Todas elas estão dentro do grande retângulo que identifica o escopo do seu sistema: o conjunto de coisas que define tudo aquilo que ele faz e exclui tudo aquilo que ele não irá fazer. No final, nosso DCU fica assim:

Esse exemplo é bem simples. Podemos ter herança de Casos de Uso, bem como extensão (extends) e inclusão (includes) de casos de uso em outros Casos de Uso (onde a relação fica de CdU para CdU, ao invés de CdU para ator), mas isso já é assunto para um próximo artigo. Até lá!

Sabe quando a gente ta cheio de coisas na cabeça e precisa documentar, mas não sabe por onde começar? Sabe quando a gente tem um brainstorming em mãos e tem que organizar aquilo tudo? Sabe quando queremos mostrar o passo-a-passo de um jogo? Para esse tipo de coisas, vou mostrar-lhes o Diagrama de Mapeamento Mental, Mapa Mental, ou Mental Mapping Diagram. O nome é pomposo, mas o diagrama em si é a coisa mais simples de ser feita, pois não pode atrapalhar seu fluxo de raciocínio: é pensar numa coisa e inserir um nó relativo à ela.

Mas o importante é saber como fazer um diagrama desse funcionar. Primeiro, escolhemos o assunto a ser mapeado. “Quero mapear os terrenos possíveis para meu RPG, Tiago”. Beleza. Então, para encontrar diferentes terrenos, vamos começar pelo começo: Iniciamos o modelo com uma Bolha:

É pela bolha que começaremos a dividir nossos terrenos. Ela vai receber o nome do que a gente quer mapear. Nesse caso, “terrenos”.

1. Começamos a organizar nosso pensamento

Eu vou colocar os grandes grupos de terrenos já como filhos, para direcionar mais ainda meus pensamentos desorganizados. O troço inicialmente ta assim, ó:

1. Hora do Brainstorming

Agora podemos começar a realizar um brainstorming: vamos deixar nossa mente voar em cima desses 4 títulos, anotando ali tudo o que pintar. Não podemos esquecer de adicionar os filhos nos locais certos, afinal, estamos organizando nosso pensamento!

“Vixe! O troço ficou muito maior que o esperado.” Claro! Essa que é a idéia. Enquanto fazíamos o brainstorming, note que apareceram vários outros grupos de terrenos (como Deserto, Polar e Cidades) que não estavam no exemplo inicial. Além disso, conseguimos subdividir alguns desses terrenos em diversos outros terrenos, como aconteceu em Construções, em Cavernas e Subaquático.

Ainda faltam MUITOS outros terrenos nesse exemplo, como terrenos vulcânicos, ilhas e cachoeiras, mas a idéia principal eu aposto que vocês já pegaram. Basta lembrar que esse diagrama vai servir pra virtualmente qualquer coisa. O Mário já me disse que leu um artigo sabe-se lá onde ensinando uma técnica para escrever artigos baseada nesse mesmo diagrama (Mário, to esperando pelo link!), enquanto eu já passei pra ele todo o funcionamento do Caso de Uso Batalha no mesmo diagrama.

Nota: Eu usei o programa FreeMind para fazer esses diagramas. Ele é gratuito e absurdamente fácil de usar. O programa você encontra aqui, já o arquivo do exemplo pode ser baixado aqui.