A Trilha do Oregon é, na maioria dos casos, o jogo educativo para computador de maior sucesso de todos os tempos. Muitas versões do jogo foram criadas ao longo dos anos, desde 1971. No entanto, a versão que muitas pessoas supõem ser a "original" - a versão que aparece constantemente em memes e artigos de revistas é o ano de 1985 Apple II versão. (O design de 1985 também foi implementado no IBM PC, Macintosh e outras plataformas, mas apareceu pela primeira vez no Apple II). Eu fui o designer principal e líder da equipe dessa versão mais famosa desse jogo educacional mais famoso e, portanto, sou uma excelente fonte para revelar exatamente como esse design foi criado.
Como esta é uma história de sucesso - e "o sucesso tem muitos pais" -, os nomes de várias outras pessoas aparecerão neste relato (não apenas o meu próprio nome, apesar da fanfarronice do título deste artigo). Todas essas pessoas desempenharam papéis importantes no sucesso da A Trilha do Oregon.
Há vários motivos por trás da impressão popular de que a versão de 1985 era a "original". Um motivo óbvio é que a versão de 1971 era somente de texto, e relativamente poucas pessoas viram ou jogaram a versão somente de texto. Um segundo motivo importante é que a maioria dos recursos que as pessoas associam carinhosamente ao jogo foi introduzida pela primeira vez em 1985. O produto de 1985 foi muito mais do que uma nova versão - foi uma reimaginação completa de como criar um jogo sobre a Oregon Trail. Tenho certeza de que o design de 1985 foi a versão mais original e criativa de toda a história do produto, excluindo (é claro) a versão totalmente original de 1971. Em outras palavras, o jogo que acabou se tornando tão bem-sucedido foi inventado em dois estágios igualmente importantes - um em 1971 e o segundo em 1984-85.
Você quer ler mais sobre design de jogos?
5 coisas que você deve saber sobre Stardew Valley
Fotografia com uma câmera de Nintendo Game Boy de 1998
Os melhores jogos novos criados para designers
A verdadeira versão original
A primeira versão do A Trilha do Oregon começou como um conceito na cabeça de Don Rawitsch, que em 1971 era um professor estudante em Minnesota. Ele imaginou um jogo de tabuleiro que poderia ser jogado pelos alunos da turma que ele estava programando para dar aula. Logo depois que Don começou a trabalhar nesse conceito, ele compartilhou sua ideia com seus colegas de quarto - Bill Heinemann e Paul Dillenberger - que também eram professores estudantes. Eles ficaram entusiasmados com a ideia de Don, mas sugeriram que deveria ser um jogo de computador em vez de um jogo de tabuleiro. O distrito escolar de Minneapolis, onde os três lecionavam, havia comprado recentemente um computador mainframe, e cada escola do distrito tinha um terminal de teletipo para acesso remoto ao computador. Além disso, tanto Bill quanto Paul haviam aprendido BÁSICOA linguagem de programação simples era ideal para a criação de um pequeno programa de computador, como o que eles imaginavam.
Imagem da máquina de teletipo via Flickr.
Don concordou rapidamente com a mudança de planos, e os três começaram a projetar e programar o conceito. Duas semanas depois, bem a tempo para a aula que Don estava programado para dar, uma primeira versão preliminar do jogo estava pronta para mostrar às crianças. Apesar da estranheza da máquina de teletipo, as crianças claramente gostaram de jogar o jogo. Bill e Paul observaram resultados semelhantes em sua escola. O jogo permaneceu disponível, acessível aos alunos em seu tempo livre, durante o restante do semestre. Mas, no final do semestre, quando seu período como professor estudante chegou ao fim, Don excluiu o programa do sistema de computador.
Alguns anos depois, Don começou a trabalhar na MECC (Minnesota Educational Computing Consortium), um novo órgão estadual de Minnesota encarregado de fornecer acesso à computação a todas as escolas do estado. O modelo de computação do MECC era semelhante ao do distrito escolar de Minneapolis - um computador mainframe localizado centralmente que podia ser acessado por meio de um terminal de teletipo em cada escola. Mas agora, em vez de atender a um único distrito escolar, essa nova organização atendia a todo o estado. Don havia guardado uma impressão do programa BASIC do jogo de 1971, portanto, em 1974, ele digitou o mesmo programa no sistema de computador da MECC. Em seguida, fez alguns ajustes finos, ajustando a frequência dos vários eventos aleatórios do jogo. Finalmente, em 1975, ele disponibilizou o jogo para todos os usuários da MECC. OREGON (como era chamado) logo se tornou a atividade educacional mais popular do sistema, e assim permaneceu até que a MECC encerrou suas operações de mainframe em 1983.
Essa versão inicial somente de texto do A Trilha do Oregon era extremamente simples, assim como quase todas as atividades educacionais no mainframe da MECC. E, no entanto, sete dos principais conceitos que apareceram no jogo de 1971 reapareceram em todas as versões desde então.
Esses conceitos fundamentais são:
- O jogador compra suprimentos antes de iniciar a jornada para o Oregon.
- Você terá a oportunidade de caçar alimentos ao longo do caminho.
- Há oportunidades de fazer compras em fortes ao longo da rota.
- O jogador deve gerenciar o nível de suprimentos para evitar o esgotamento.
- A taxa de deslocamento depende das condições atuais.
- Os infortúnios ocorrem com frequência.
- O jogo termina quando o jogador chega ao Oregon ou quando ele morre no caminho.
O jogo de 1971 foi estruturado como um ciclo repetitivo. Cada ciclo representa duas semanas de viagem na trilha. Abaixo está um exemplo de um ciclo típico, de uma sessão real do jogo. A maior parte do texto desse exemplo foi digitada pelo computador, mas, às vezes, o computador para para aguardar uma resposta do jogador. As respostas do jogador estão destacadas em amarelo:
Como você pode ver neste exemplo, cada ciclo começa com uma atualização de status. Em seguida, o jogador decide se quer caçar. (Às vezes, a opção de visitar um forte também está disponível, como mostrado aqui.) Se o jogador optar por caçar, ele dispara o rifle digitando "BANG" quando solicitado. Se a digitação foi rápida e precisa, a caça foi bem-sucedida. Agora, o jogador decide quanto comer. Por fim, ocorre um ou mais "infortúnios", que podem reduzir os suprimentos. Em seguida, o ciclo se repete duas semanas depois, levando em conta os suprimentos usados nesse intervalo. O ciclo continua até que o jogador chegue ao Oregon ou morra tentando. Uma jornada bem-sucedida requer aproximadamente 12 ciclos - dependendo de várias circunstâncias que afetam a velocidade da viagem.
Para muitos jogadores, a principal atração desse jogo era o desafio de caçar - digitar a palavra "BANG" com rapidez suficiente para ter sucesso, sem cometer erros de digitação. Portanto, a maneira típica de jogar era dar uma resposta idêntica em cada ciclo - primeiro digite "2″ para caçar, depois digite "BANG" e, em seguida, digite "2″ para comer moderadamente. O único desvio necessário é quando um dos itens de suprimento fica perigosamente baixo, forçando o jogador a fazer compras em um forte em vez de caçar. O segundo aspecto interessante desse jogo foi o desafio de gerenciar os recursos - ficar de olho nos suprimentos para garantir que nenhum deles acabe, o que seria um erro fatal. O terceiro aspecto interessante é que há muitos infortúnios diferentes que podem ocorrer. Assim, você nunca sabe o que acontecerá em seguida, a menos que fique sem suprimentos, caso em que provavelmente morrerá logo.
O design original também apresentava ataques aleatórios de animais selvagens, bandidos e "cavaleiros hostis", cada um dos quais fornecia oportunidades adicionais para digitar "BANG" - e consequências terríveis para quem não conseguisse digitar com rapidez e precisão. No final da década de 1970, foi feita uma pequena alteração no jogo para que o jogador não soubesse antecipadamente a palavra que deveria digitar quando chegasse a hora de atirar. Às vezes era "BANG", mas também poderia ser "POW", "BLAM" ou "WHAM".
O mundo muda
Em 1978, Don Rawitsch publicou o código BASIC para o OREGON em Computação criativa revista. Depois disso, muitas pessoas ajustaram o código para que fosse executado em várias marcas de microcomputadores. Alguém - não sei quem - colocou uma versão desse código de programa em um Apple II. Essa versão do jogo não era um projeto novo - na verdade, usava principalmente o mesmo código BASIC que apareceu na revista. No entanto, o autor fez três alterações importantes no jogo, uma das quais foi a reimaginação da atividade de caça. Em vez de ser baseada em texto, como todas as outras partes do jogo, essa nova atividade apresentava um esboço de um cervo, no qual o jogador podia atirar pressionando qualquer tecla do teclado.
Em 1979, a MECC estava comprando computadores Apple II em grandes quantidades (a um preço com desconto) e revendendo-os a preço de custo para escolas de todo o estado de Minnesota. Em 1980, a MECC também começou a distribuir discos contendo software Apple II para essas mesmas escolas. (Esses discos eram fornecidos gratuitamente para as escolas de Minnesota, mas vendidos com um lucro significativo para escolas fora de Minnesota). Cada disco continha uma coleção de programas transferidos do computador mainframe da MECC. O jogo OREGON apareceu em duas dessas coleções, uma das quais foi denominada "Elementary Volume 6:"
A MECC continuou a distribuir o "Elementary Volume 6″ por muitos anos, e o jogo OREGON continuou sendo o produto mais famoso da MECC, mesmo depois que a MECC encerrou suas operações de mainframe para se concentrar totalmente nos microcomputadores (Apple II, Atari, IBM, etc.). Entretanto, o cenário competitivo mudou completamente entre 1980 e 1984. Em 1980, todos os softwares para computadores educacionais ainda estavam sendo projetados e programados por amadores, amadores e professores que criavam esses programas pequenos e simples em seu tempo livre. Além disso, nenhuma grande empresa privada havia entrado no mercado de software educacional, nem no mercado escolar nem no mercado doméstico.
Em 1984, o mundo do software educacional era completamente diferente. Um grande número de empresas, tanto grandes quanto pequenas, havia começado a vender software educacional para computadores. Algumas dessas empresas se especializaram no mercado escolar, enquanto outras se especializaram no mercado doméstico. Em 1984, todos os melhores softwares educacionais foram projetados e programados por profissionais, pessoas cujo trabalho em tempo integral era projetar ou programar esses softwares. Para se manter competitiva, a mesma transição ocorreu na MECC. Em 1983, a MECC adquiriu uma equipe de designers e programadores profissionais encarregados de criar software original de alta qualidade para o Apple II. Em 1984, o aprimoramento dos produtos da MECC era bastante óbvio para todos. Esse foi o início da "era de ouro" da MECC - um período de uma década em que a MECC produziu novos softwares excepcionais ano após ano - principalmente voltados para o mercado escolar, mas também incluindo alguns títulos para o mercado doméstico.
Embora a MECC estivesse agora concentrada quase que inteiramente na criação de títulos novos e originais, ela também tinha três simulações famosas da década de 1970.Oregon Trail, Barraca de limonadae Lago Odell-que não queria abandonar. Todas as três atividades haviam sido transferidas para o Apple II em 1980, mas em 1984 estavam embaraçosamente desatualizadas, especialmente em termos de aparência. A MECC decidiu que criaria novas versões das três atividades.
A decisão de romper com o passado
Foi nesse contexto que fui escolhido pela MECC, em outubro de 1984, para liderar a criação de uma nova versão do A Trilha do Oregon. Eu havia entrado para a equipe da MECC em 1981 com uma experiência substancial em design e programação de simulações baseadas em computador (embora, antes de 1981, todas as minhas simulações tivessem sido direcionadas a alunos de nível universitário). Eu era a única pessoa da equipe com esse tipo de experiência e, portanto, era a escolha lógica para a função de designer principal e líder de equipe. Ainda assim, fiquei surpreso com os detalhes do mandato que me foi dado.
Em primeiro lugar, disseram-me para projetar um produto para o mercado doméstico, não para o mercado escolar. Anteriormente, a MECC sempre havia se especializado no mercado escolar. Essa seria a primeira tentativa da MECC de criar um produto projetado especificamente para o mercado doméstico.
Em segundo lugar, minhas instruções eram para fazer muito mais do que apenas criar uma versão mais bonita do jogo original. Disseram-me que eu deveria pegar o conceito original e trabalhar com ele. Eu deveria expandir o conceito original, criando um jogo muito mais elaborado e robusto. Eu poderia fazer isso da maneira que achasse melhor, desde que preservasse a magia que havia tornado o original tão popular. No entanto, tive de projetar o produto especificamente para o Apple II, o que resultou em algumas restrições sérias, como ter de trabalhar com uma paleta de apenas seis cores. (Eu teria preferido usar uma máquina mais recente, como o Commodore 64.)
Meu mandato para repensar e redesenhar A Trilha do Oregon O jogo OREGON foi quase esmagador no início - as possibilidades eram infinitas, mas eu tinha que acertar em cheio no primeiro lançamento. Durante 13 anos, de 1971 a 1984, o jogo OREGON permaneceu essencialmente inalterado. Alguns pequenos detalhes foram ajustados ao longo do caminho, mas o produto nunca havia sido completamente reimaginado e reprojetado. Os modelos subjacentes nunca foram alterados - as estruturas, os algoritmos e as suposições nos quais o jogo se baseia. Pela primeira vez, jogaríamos fora tudo, inclusive toda a programação de software existente, que datava de 1971, e começaríamos completamente do zero. Cada detalhe estava sujeito a reconsideração. Além disso, eu precisava criar uma experiência muito mais rica e elaborada do que o OREGON original, e isso exigiria uma grande quantidade de pensamentos novos e originais.
Para dar início ao projeto, defini uma métrica fundamental que serviria de base para nossa abordagem: "As crianças que adoram a versão antiga gostam ainda mais da nova versão?" A ideia era realizar esse teste periodicamente durante todo o projeto, para verificar se ainda estávamos no caminho certo. Sempre que nos encontrássemos no meio do caminho, essa medida nos traria de volta à realidade, permitindo-nos ver o panorama geral novamente.
Como eu estava projetando um produto para o mercado doméstico, sabia que precisava criar um jogo que fosse altamente divertido, além de ser claramente educativo. Achei que era possível fazer as duas coisas, sem comprometer seriamente nenhuma delas, mas tive que encontrar um equilíbrio cuidadoso nos detalhes. Em particular, achei que tanto o valor educacional quanto o valor de entretenimento deveriam resultar da imersão do jogador em uma experiência historicamente precisa.
Desde o início, percebi que esse projeto apresentava muitos desafios, mas a questão das restrições de espaço parecia especialmente desafiadora. O novo jogo precisava ter um conjunto rico de gráficos coloridos, mas os gráficos exigiriam muito espaço, tanto no disquete quanto na RAM (memória) do Apple II. Eu também esperava acrescentar muitos novos detalhes e aspectos de jogabilidade, o que exigiria espaço. Infelizmente, eu estava projetando para um computador que tinha apenas 64K de RAM. Além disso, o produto seria distribuído e jogado em um disquete de 5,25″ de dupla face, fornecendo um total de apenas 280K de espaço de armazenamento. (Observe que o Apple II não tinha um disco rígido, apenas uma unidade de disquete).
Quando o projeto começou, nossa equipe principal era composta por cinco pessoas. Além de mim (Philip Bouchard), havia também John Krenz (programador principal), Charolyn Kapplinger (artista principal), Shirley Keran (pesquisa) e Bob Granvin (programação adicional). Todos nós cinco desempenhamos papéis ativos no brainstorming e no planejamento inicial do produto, embora a MECC tenha transferido Bob para outro projeto que precisava de sua atenção. Assim, nós cinco começamos um projeto que se tornou o maior esforço da MECC até o momento, com duração total de 10 meses, de outubro de 1984 até o final de julho de 1985.
Desenvolvimento dos conceitos-chave
Na abordagem de design tradicional da MECC (a partir de 1984), o designer instrucional primeiro imagina uma atividade do aluno baseada em computador e, em seguida, cria uma série de esboços que ilustram o que deve aparecer na tela em cada uma das principais etapas da atividade. Essa coleção de esboços é então acompanhada de anotações escritas que fornecem detalhes adicionais. Os esboços e as anotações juntos constituem um "documento de design". Em seguida, o designer analisa o documento com uma pequena equipe de até três outras pessoas: o programador líder, o designer gráfico líder e um programador/analista experiente. Juntos, eles identificam os detalhes que faltam no design e ajudam a resolver quaisquer outros problemas que o design apresente. Em seguida, o designer faz os acréscimos ou as alterações necessárias para concluir o design e a equipe começa a trabalhar na criação dos gráficos e na geração do código do programa.
Esse modelo funcionou bem para os produtos relativamente simples que a MECC vinha criando até então, mas percebi que não funcionaria para o produto que eu pretendia projetar. Em primeiro lugar, imaginei que o jogo se basearia em um conjunto complexo e interligado de modelos de simulação matemática - um modelo meteorológico, um modelo de saúde, um modelo de viagem e assim por diante. Além disso, cada um desses modelos seria baseado em um conjunto complexo e interligado de fórmulas matemáticas. Esses modelos exigiriam design e ajuste incrementais, o que significava não apenas que eu precisava produzir um grande número de fórmulas, mas também que o design precisava ser especificado e implementado em estágios iterativos, em vez de tudo de uma vez.
Em segundo lugar, eu achava que a melhor maneira de criar um design inovador e bem-sucedido era começar com um conjunto ambicioso de novas ideias e, em seguida, construir e testar gradualmente essas ideias por meio de refinamentos sucessivos - primeiro criando um protótipo simples e, em seguida, desenvolvendo o produto real, um aspecto de cada vez. Em cada etapa do processo, devemos avaliar onde estamos, em comparação com onde queremos estar, e então priorizar o que fazer em seguida. Algumas de nossas ideias mais queridas teriam de ser abandonadas ao longo do caminho, mas, ao priorizar e melhorar constantemente, alcançaríamos um resultado bem-sucedido no final. (Aprendi e apliquei pela primeira vez os conceitos de refinamento sucessivo quando estudei ciência da computação na pós-graduação, na década de 1970. No entanto, décadas depois, vi muita sobreposição entre essas ideias e o conceito de "programação ágil").
Mas, primeiro, preciso projetar a estrutura subjacente do jogo e, por algumas semanas, isso me deixou perplexo. O OREGON original era baseado no conceito de "turnos", cada um representando exatamente duas semanas de tempo real. Essa estrutura simples foi bem adaptada ao seu propósito original - um jogo baseado em texto jogado em um teletipo -, mas foi mal adaptada às necessidades do novo jogo. Eu queria criar uma estrutura que estivesse intimamente ligada à geografia real da Trilha do Oregon e queria dar ao jogador um conjunto muito maior de oportunidades para tomar decisões - não apenas o que comprar e quanto comer. Logo ficou claro que eu teria que inventar uma estrutura completamente diferente para o novo jogo. Mas enquanto eu considerava uma ideia após a outra, nenhuma dessas novas ideias parecia funcionar.
Então, dividi o problema em partes e comecei a lidar com cada parte individualmente. Por fim, em um período de várias semanas, finalmente consegui gerar uma solução para cada problema. A nova estrutura resultante para A Trilha do Oregon foi baseado em sete conceitos-chave, nenhum dos quais estava presente no projeto de 1971:
Para vincular o novo design ao geografia real da Trilha do OregonSe você não tiver uma visão geral da trilha, a viagem consistirá em segmentos distintos de duração variável, cada um terminando em um marco importante e único ao longo da trilha. (De todas as muitas diferenças entre o produto de 1971 e o projeto de 1985, essa talvez seja a mais importante, em parte porque possibilitou muitas outras mudanças cruciais).
Um conjunto de módulos de atividade está disponível em cada marco. Em muitos casos, há uma atividade importante vinculada ao ponto de referência, como atravessar um rio ou comprar mercadorias em um forte.
Os pontos de referência são agrupados em zonas geográficas distintas, cada uma com seus próprios dados sobre clima, terreno e animais selvagens.
A maioria dos módulos de atividade é orientada por dados e contém randomização, proporcionando uma experiência diferente a cada vez que o módulo é usado. Por exemplo, toda vez que a atividade de caça é iniciada, ela usa os dados da zona para apresentar animais e terrenos apropriados para o local atual na trilha. Mas mesmo que o jogador cace na mesma zona várias vezes, a disposição do terreno será sempre única e os animais aparecerão em horários e locais imprevisíveis.
Além do ciclo de marco a marco, há um ciclo diário independente, que inclui todos os cálculos de gerenciamento de recursos (suprimentos, saúde, etc.) juntamente com os eventos aleatórios. Portanto, o ciclo computacional principal no projeto de 1985 é de um dia, em vez do ciclo de duas semanas usado no projeto original. Isso tem enormes ramificações para todos os cálculos e todas as interações.
Entre os pontos de referência, a jornada prossegue automaticamente, mas o usuário pode pausar a qualquer momento. (Esse foi um conceito especialmente importante, pois fornece ao usuário acesso a muitas atividades e eventos, sem interromper o jogo constantemente). No entanto, a jornada é pausada automaticamente se ocorrer um evento importante.
A pausa entre os pontos de referência fornece acesso a outro conjunto completo de módulos de atividade, alguns dos quais são diferentes das atividades disponíveis nos pontos de referência. (Por exemplo, você pode conversar com pessoas nos pontos de referência e pode caçar entre os pontos de referência).
Essa nova estrutura era muito diferente do design de 1971, o que me permitiu criar uma experiência muito mais rica para o jogador. No novo design, a relação entre os módulos de atividade era a seguinte:
Com essa estrutura altamente flexível servindo como espinha dorsal do novo produto, poderíamos agora planejar quais atividades estariam acessíveis durante a viagem entre os pontos de referência (A-F no diagrama) e quais atividades estariam acessíveis em cada um dos pontos de referência (G-L no diagrama). Cada um desses módulos distintos (representados pelos quatro retângulos e os 12 círculos) pode ser projetado e programado separadamente. Além disso, cada um dos meia dúzia de modelos de simulação matemática (não mostrados neste diagrama, mas que operam por baixo de tudo) também poderia ser projetado e programado separadamente.
Meus colegas de equipe ficaram entusiasmados com essa nova estrutura, então iniciei o longo processo de elaboração dos detalhes. Em primeiro lugar, com base em minha pesquisa e na de minha colega Shirley, preparei uma lista de pontos de referência candidatos. Em seguida, aplicando vários critérios de seleção, reduzi o conjunto para que a jornada consistisse em aproximadamente 16 etapas. Também introduzi o conceito de "pontos de corte", o que significa que, além da rota principal, o jogador às vezes teria a opção de seguir uma rota alternativa. Em seguida, comecei a trabalhar na criação de uma lista de possíveis módulos de atividades, produzindo sistematicamente "documentos conceituais" para todas as ideias mais promissoras.
Durante esse estágio de desenvolvimento do conceito, conversei bastante com meus colegas de equipe. Antes de redigir cada documento conceitual, eu geralmente discutia as ideias que tinha com meus colegas de equipe. Depois de redigir cada documento conceitual, eu o revisava com meus colegas de equipe para obter feedback adicional. O resultado é que, embora eu tenha sido o autor de todos os documentos conceituais, com exceção de um, as ideias contribuídas pelos meus colegas de equipe (Cheryl, John, Shirley e Bob) muitas vezes foram refletidas nos meus documentos. Isso foi especialmente verdadeiro no caso dos conceitos iniciais da atividade de caça, que Bob, John e eu elaboramos juntos.
Incorporação de seres humanos no design
No início do projeto, minha segunda maior prioridade - perdendo apenas para a incorporação da geografia real no produto - era incluir personagens humanos no design. O design de 1971 omitia o conceito de pessoas e, portanto, você percorria toda a rota de 3.000 quilômetros sem nunca encontrar ou interagir com outra pessoa. Eu queria mudar isso. Fiz um brainstorming de muitos conceitos distintos sobre como o jogador poderia interagir com personagens humanos ao longo do caminho - ou pelo menos estar ciente de outros humanos - e esperava sinceramente incluir quase todas essas ideias no produto final. Mas, à medida que o projeto avançava, tive que cortar alguns dos meus conceitos mais queridos, devido ao espaço limitado no disquete e ao orçamento limitado para projetar e construir o produto. No entanto, consegui incorporar quatro dos conceitos ao design, e cada um deles causou um grande impacto na "sensação humana" do produto de 1985:
- Antes de iniciar a viagem, você nomeia quatro outras pessoas que viajarão com você - geralmente familiares ou amigos. Cada membro do seu grupo de 5 pessoas está sujeito a doenças e acidentes. Enquanto você percorre a trilha, uma das principais metas é manter todas essas pessoas vivas e saudáveis. Se alguma delas adoecer ou morrer, será mencionada pelo nome. Essa coleção de conceitos foi um acréscimo crucial para o novo design.
- Ao comprar os produtos antes de iniciar a jornada, você entra em uma loja ("Matt's General Store") e interage com o proprietário da loja. Matt dá conselhos úteis enquanto você faz suas compras.
- Na verdadeira Trilha do Oregon, as pessoas tendiam a se reunir em cada um dos pontos de referência. Essas pessoas incluíam não apenas outros viajantes, mas também nativos americanos, comerciantes locais e soldados. Portanto, em cada ponto de referência do jogo, o jogador pode conhecer e conversar com três pessoas diferentes, cada uma delas oferecendo uma perspectiva interessante sobre suas experiências. Além disso, muitas dessas conversas fornecem dicas úteis sobre como sobreviver à jornada. (Infelizmente, devido ao espaço limitado em disco, não foi possível incluir fotos desses personagens).
- Se você conseguir chegar até o Oregon, a lista de pontuações mais altas será preenchida com os nomes de pessoas reais que fizeram a viagem até o Oregon ou que serviram como exploradores iniciais na região.
Graças à designer gráfica líder, Charolyn Kapplinger, as pessoas também aparecem em muitos dos gráficos de grandes marcos. Isso também contribui significativamente para o lado humano do design.
Meu maior arrependimento em relação a A Trilha do Oregon é que tive de abandonar a maioria das minhas ideias de interações complexas e diferenciadas com os nativos americanos. Vários desses módulos foram incluídos nos conceitos de design que escrevi. Entretanto, algumas das ideias mais simples chegaram ao produto final. Por exemplo, é muito mais provável que você tenha sucesso na travessia do rio Snake se contratar um índio local para guiá-lo, o que também aconteceu na trilha real do Oregon.
Outras prioridades principais
Outra prioridade máxima para mim foi incluir travessias de rios - um aspecto fundamental da experiência da Oregon Trail que estava faltando no projeto original. Escolhi um conjunto de travessias representativas - um pequeno subconjunto do número real de travessias feitas pelos viajantes na trilha. Em cada rio, o jogador deve escolher entre vários métodos de travessia, levando em conta as condições atuais da travessia. Um modelo de simulação altamente detalhado está subjacente a esse módulo, controlando as condições atuais do rio (com base no clima recente, entre outros fatores) e também controlando as probabilidades de vários resultados, com base nas condições e na escolha do jogador de como atravessar. Os resultados são comunicados em uma animação de tirar o fôlego que deixa muitos jogadores na ponta da cadeira.
Outra de minhas prioridades era incluir mais duas atividades de "ação", além da caça. Logo modifiquei esse plano para que uma dessas atividades funcionasse como um quebra-cabeça lógico estendido, em vez de um jogo de ação. Essas duas atividades estariam associadas à etapa final da jornada até o Oregon, as últimas 160 milhas. O jogador poderia optar por descer o rio Columbia de rafting (a atividade de ação) ou pegar a Barlow Toll Road, sendo que nesse caso a atividade seria o desafio de levar a carroça para cima e para baixo no difícil terreno montanhoso ao longo da rota. Novamente, o espaço em disco e o orçamento nos forçaram a fazer cortes, mas uma versão reduzida do jogo de rafting acabou sendo incluída no produto.
E, por fim, outra prioridade era encontrar o maior número possível de maneiras de criar "rejogabilidade" no produto. Isso raramente havia sido uma preocupação para a MECC em qualquer produto anterior, porque todos esses produtos eram voltados para o mercado escolar. Para as escolas, onde o número de crianças era muito maior do que o de computadores e o tempo de acesso era altamente limitado, a maioria dos produtos da MECC foi projetada para que o valor total do produto pudesse ser experimentado em um curto período de tempo. Mas para o mercado doméstico, eu precisava projetar um produto que uma criança pudesse visitar várias vezes - e que ainda fosse interessante após 20, 30 ou 40 horas de jogo. Para incentivar a repetição, incorporei uma longa lista de recursos e detalhes ao novo design:
O fator motivador inicial - idêntico ao motivador do produto original - é sobreviver a toda a jornada até o Oregon. Como no original, a maioria dos jogadores falha na primeira tentativa, mas eles percebem que é possível melhorar. Assim, eles continuam tentando, fazendo cada vez melhor na maioria das tentativas, até que finalmente conseguem chegar ao Oregon.
Assim que o jogador chega ao Oregon pela primeira vez, uma surpresa é revelada: ao sobreviver até o Oregon, o jogador recebe uma pontuação. Essa pontuação é baseada em vários fatores distintos, que são claramente discriminados. Assim, exatamente no momento em que o jogador atinge o objetivo inicial - chegar ao Oregon -, um novo objetivo altamente motivador é revelado: obter uma pontuação muito melhor.
O jogador também vê que a lista de pontuações mais altas é pré-preenchida com nomes - e a maioria dessas pessoas tem pontuações mais altas do que as que o jogador alcançou. Essa lista inicial cria uma referência clara pela qual você deve se esforçar - subir cada vez mais na lista até finalmente ultrapassar a pontuação máxima da lista (a do explorador Stephen Meek).
À medida que o jogador busca obter pontuações mais altas, fica evidente que é necessário tentar as condições iniciais mais difíceis - viajar como carpinteiro (com menos dinheiro) ou fazendeiro (com ainda menos dinheiro), em vez de viajar como banqueiro. Embora seja mais difícil chegar ao Oregon quando se tem menos dinheiro, você recebe mais pontos por seus esforços.
O novo jogo tem muito mais opções e abordagens alternativas para você explorar do que o jogo original. Com o tempo, muitos jogadores se interessam em explorar essas alternativas. E se eu começar em um mês diferente? E se eu mudar o ritmo ou as rações? E se eu parar para descansar de vez em quando? E se eu conversar com muito mais pessoas para obter conselhos? E se eu atravessar cada rio de bote em vez de tentar atravessar qualquer um deles? E se eu caçar menos (o que consome um dia de tempo no novo projeto) e fizer mais compras - ou vice-versa? E se eu carregar um número maior de peças sobressalentes do vagão? E se eu pegar a Barlow Toll Road em vez de fazer rafting no rio Columbia - ou vice-versa?
Como no jogo original, alguns jogadores vão querer jogar várias vezes só para caçar. E, para isso, eu queria que o novo jogo de caça fosse desafiador e atraente. Todos esses fatores - e vários outros que incluí no design - resultaram em um jogo com um grau muito alto de rejogabilidade. Sem essa característica, o jogo não teria sido muito bem-sucedido no mercado doméstico.
Os modelos matemáticos
Tanto no jogo original de 1971 quanto no novo design de 1985, a simulação é conduzida por um conjunto de fórmulas matemáticas vinculadas a variáveis de estado. Cada variável de estado rastreia o valor atual de alguma quantidade importante. No projeto de 1971, havia exatamente oito variáveis de estado:
- Caixa (em dólares)
- Alimentos (em dólares)
- Munição (o número de balas)
- Roupas (em dólares)
- Suprimentos diversos (em dólares)
- Bois (em dólares)
- Distância percorrida até o momento (em milhas)
- Data atual (incrementada por saltos de duas semanas)
Observe que não há variável de estado para a saúde no produto de 1971. Portanto, sua saúde no turno atual não depende de forma alguma da sua saúde no turno anterior. O jogo termina se você morrer, e você pode morrer em qualquer um dos seguintes estados:
- Você fica sem comida e passa fome.
- Você fica sem "suprimentos diversos" e acaba ficando doente (o clima frio e a falta de roupas aumentam a probabilidade de ficar doente). A lógica era que, toda vez que você ficasse gravemente doente, precisaria ter remédios ou morreria.
- Você fica sem dinheiro e adoece. A lógica era que toda vez que você ficasse gravemente doente, deveria pagar um médico ou morreria.
- Você fica sem balas e é atacado por "cavaleiros hostis" que o massacram.
Eu discordava totalmente da ideia por trás de três dessas quatro condições de fim de jogo - somente morrer de fome fazia sentido para mim. O ano em que eu ambientei o jogo (1848) foi muito antes da invenção dos antibióticos modernos. Os medicamentos disponíveis naquela época tinham pouco efeito sobre as doenças comumente contraídas ao longo da Trilha do Oregon. Portanto, não fazia sentido que todas as doenças fossem 100% curáveis com remédios e 100% fatais sem remédios.
Da mesma forma, não fazia sentido que você sempre pudesse encontrar um médico disponível em qualquer lugar da trilha e que sempre morresse sem um médico, mas sempre vivesse se um médico estivesse presente - e que um médico nunca, jamais, tratasse você de graça. Por fim, acabei eliminando totalmente a medicina e os médicos do projeto.
Também discordei dos frequentes ataques de bandidos, animais selvagens e "cavaleiros hostis" no jogo original - e da necessidade de expulsar todos eles atirando neles. Nada disso estava de acordo com minha pesquisa histórica sobre a Oregon Trail. Portanto, removi todas essas interações do projeto.
Para o novo design, reimaginei completamente como o modelo de simulação subjacente deveria funcionar. Parte dessa alteração foi necessária devido à minha mudança de incrementos de tempo de duas semanas para incrementos de tempo de um dia. Mas a maior parte da mudança foi motivada pelo desejo de oferecer um modelo muito mais rico e também por uma visão completamente nova do que deveria desencadear a morte dos cinco membros do grupo. O novo jogo incluiria um modelo de saúde complexo que empregava diversas variáveis de estado diferentes, permitindo que o jogo acompanhasse a saúde geral do grupo diariamente, bem como o estado de recuperação de cada membro do grupo de quaisquer acidentes ou doenças.
Outra mudança importante foi a inclusão de um modelo complexo de clima e tempo, com base nos valores reais mensais de temperatura média e precipitação em vários pontos da trilha. (No jogo original, o mês do ano não afeta o clima.) À medida que o jogador percorre a trilha, o clima de cada dia é baseado no mês atual e na localização atual do jogador na trilha. A simulação recupera a temperatura média correspondente e adiciona ou subtrai um desvio aleatório. A simulação também obtém as chances de chuva e gera condições que podem ser secas, chuvosas ou muito chuvosas (se o tempo estiver muito frio, a neve substitui a chuva).
Em vez de um único modelo de simulação, projetei os seguintes modelos interligados, cada um consistindo de várias ou muitas fórmulas matemáticas interligadas:
- Clima e tempo
- Saúde
- Progresso na trilha
- Suprimentos (dinheiro, alimentos, bois, balas, roupas e peças de reposição)
- Travessias de rios
- Sistema de pontuação
Acabei com um enorme conjunto de variáveis de estado e um enorme conjunto de fórmulas matemáticas. Com tantos detalhes afetando uns aos outros, eu sabia que teria de fazer muitos ajustes finos na jogabilidade à medida que testássemos o jogo. Especialmente nos últimos três meses de desenvolvimento do produto, eu ajustou todas as fórmulas e valores iniciais para produzir um equilíbrio cada vez melhor na jogabilidade.
O novo conjunto de conceitos básicos
Até o final de julho de 1985, A Trilha do Oregon estava completo e pronto para ser lançado. Para nossa alegria, o produto foi um sucesso instantâneo. Além de se tornar bastante popular no mercado doméstico, logo se tornou o produto de software educacional mais onipresente nas escolas norte-americanas. Nosso novo jogo, juntamente com suas versões sucessoras, gerou milhões de dólares para os proprietários da MECC nos anos seguintes. (A MECC havia começado como uma agência estatal, mas depois foi vendida a investidores privados). Embora essas riquezas não tenham chegado até as pessoas que projetaram e construíram o jogo, ficamos muito satisfeitos ao ver o que havíamos realizado: a criação de um produto de grande sucesso que acabou se tornando um jogo clássico e um ícone cultural.
Ao projetar e criar essa versão completamente nova do A Trilha do Oregon não foi um processo direto e linear. Em meus primeiros documentos de design, propus e considerei todos os tipos de ideias, das quais apenas algumas chegaram ao produto final. Quando lançamos o jogo, os seguintes recursos inovadores foram incorporados:
Detalhes geográficos reais. O jogo OREGON original não incluía quase nenhum detalhe geográfico. Nenhum rio, montanha, forte ou outro ponto de referência era mencionado pelo nome. Um dos principais objetivos do meu novo design era incorporar muita geografia real, entrelaçada ao longo do jogo, ilustrada com gráficos coloridos atraentes.
Ciclo de viagem baseado em marcos. O OREGON original empregava um ciclo de jogo muito simples de duas semanas, sem nenhum ponto de referência. Dividi a rota principal em 16 segmentos, cada um começando e terminando com um ponto de referência famoso. Em cada ponto de referência, e também entre os pontos de referência, o jogador toma muitas decisões que não estavam disponíveis no jogo original.
Ciclos diários contínuos. A jornada até o Oregon normalmente leva cerca de 150 dias. Eu precisava incorporar um ciclo diário ao design, para que eventos cruciais pudessem ocorrer em qualquer dia da jornada e para permitir que o jogador acompanhasse os suprimentos diariamente. Para evitar que o jogo seja interrompido várias vezes, ele continua no "piloto automático" entre os pontos de referência, até que o jogador o interrompa ou ocorra um evento importante.
Escolhas quanto à rota. O OREGON original apresentava a Trilha do Oregon como um caminho único e contínuo, sem ramificações ou opções de rota. Introduzi uma situação mais realista em que o jogador precisa ocasionalmente tomar uma decisão sobre o caminho a seguir - e essa decisão pode ter consequências muito importantes para o jogador.
Travessias de rios. No OREGON original, não havia rios nem travessias. Tornei as travessias de rios uma característica importante do novo jogo. Em cada travessia, o jogador deve tomar decisões cruciais, com base nas condições atuais, que são fortemente afetadas pelo clima recente, que difere a cada jogada do jogo.
Uma atividade de caça reimaginada. No OREGON original, você caça digitando a palavra "BANG". Nosso objetivo era transformar a atividade de caça em um verdadeiro jogo de estilo arcade baseado em habilidades, incorporando o terreno real em que você está caçando, como pradaria, montanhas ou deserto. Da mesma forma, as espécies de animais que você encontra são baseadas no local da trilha em que você se encontra no momento.
Um sistema de pontos. No OREGON original, não há sistema de pontos. Para criar um alto nível de repetibilidade no produto, criei um sistema de pontos que está intimamente ligado ao nível de dificuldade que você escolher. Além disso, como outro motivador, a lista de pontuações mais altas é preenchida previamente com um conjunto de nomes históricos que abrangem uma ampla gama de pontuações.
Membros da família. No OREGON original, há pouca menção de que outras pessoas estão viajando com você. Para tornar a experiência mais pessoal, meu projeto exige que cada jogador forneça quatro nomes adicionais como companheiros de viagem. Se você tomar decisões erradas ou tiver uma maré de azar, membros da sua família ou do seu grupo morrerão.
Conversar com as pessoas. Não há sistema de conversação no OREGON original. Em meu novo projeto, permito que o jogador converse com as pessoas ao longo do caminho. Esse é um método importante para obter dicas úteis e descobrir detalhes históricos e geográficos de interesse. Além disso, isso faz com que o jogo pareça muito mais humano.
Jogo de rafting no rio. O OREGON original não menciona o rafting no rio Columbia, o que considerei uma parte fascinante da história, além de uma ótima oportunidade de incluir outro jogo de arcade no produto. Portanto, criamos o jogo de rafting no rio, embora em uma versão mais simples do que a que havíamos planejado originalmente.
Túmulos. Outro recurso famoso que adicionamos é a capacidade de criar uma lápide para você depois de morrer. Esse interlúdio bem-humorado compensa o fato de o jogador não conseguir concluir a jornada. Mas a verdadeira vantagem é que armazenamos os dados da lápide no disco do jogo, para que o próximo jogador que usar o mesmo disco possa ver a lápide.
Um modelo de saúde detalhado. O OREGON original não monitora a saúde do jogador de um turno para o outro. Meu novo projeto incluiu um modelo de saúde contínuo para todo o grupo, além de monitorar doenças e lesões individuais. O clima, as rações alimentares e o ritmo têm efeitos cumulativos sobre a saúde do grupo, que pode melhorar ou diminuir com o tempo.
Um modelo meteorológico detalhado. O OREGON original não incluía um modelo meteorológico verdadeiro, com estações e dados vinculados a várias zonas climáticas distintas. (O original tinha apenas duas zonas climáticas e nenhuma estação.) No novo jogo, o programa calcula o clima todos os dias, com base no mês e no local atuais. Isso, por sua vez, afeta muitos outros fatores, como saúde, travessia de rios, disponibilidade de água e assim por diante.
Gerenciamento robusto de recursos. Meu novo design ofereceu muitas novas maneiras de o jogador gerenciar seus recursos, incluindo: 1) ajustar o ritmo da viagem, 2) comprar tipos específicos de peças de reposição, 3) descansar a qualquer momento para melhorar a saúde do grupo, 4) negociar com outros viajantes para adquirir recursos essenciais e 5) comprar bois adicionais nos fortes.
Uma tela de viagem cativante. A tela de viagem do produto de 1985 - com um pequeno boi e uma carroça animados - tornou-se a representação icônica de toda a história do A Trilha do Oregon jogo. A combinação de elementos nessa tela é altamente memorável e eficaz.
Matt's General Store. No jogo original, você nunca interagia com as pessoas. No design de 1985, apresentamos a Matt's General Store. Matt é o simpático proprietário da loja que o ajuda com suas compras, fornecendo conselhos úteis sobre o que você deve comprar e quanto deve comprar.
Doenças específicas. No jogo original, se você ficar doente, a doença nunca é mencionada. (Depois que você morre, a pneumonia pode ser mencionada.) Para o novo design, incorporei cinco doenças ou sintomas frequentemente mencionados pelos viajantes na Oregon Trail: febre tifoide, cólera, sarampo, disenteria, exaustão e febre. Curiosamente, uma dessas cinco doenças capturou a imaginação popular e se tornou um grande meme. ("Você morreu de disenteria.")
Níveis de dificuldade. Para incentivar a repetição, criei três níveis de dificuldade no jogo. Escolhi três profissões distintas para representar os três níveis de dificuldade: banqueiro, carpinteiro e agricultor. Essas escolhas também se tornaram um meme.
Negociar com pessoas. A qualquer momento entre os pontos de referência, o jogador pode tentar trocar itens com os transeuntes. Isso pode ser bastante útil em determinadas circunstâncias, especialmente se uma peça crucial da carroça estiver quebrada. Entretanto, esse módulo é uma pálida sombra do sistema de comércio que eu pretendia incluir. Mais tarde, incluí o sistema de comércio completo e robusto no jogo Lewis e Clark ficaram em casa.
Opções para descansar ou mudar o ritmo. O jogador pode optar por acelerar ou desacelerar o ritmo, ou parar completamente para descansar por alguns dias. Essas decisões representam uma grande troca entre a saúde do grupo e o progresso na trilha.
Música de época. Em cada ponto de referência ao longo do caminho, você pode ouvir uma melodia diferente. Além disso, cada melodia é uma música real que era popular na época da Oregon Trail. Infelizmente, essa inovação pode ser mais irritante do que útil, especialmente no Apple II, que não tem controle de volume.
Juntas, essas 21 inovações resultaram em uma experiência muito diferente em comparação com as versões anteriores do jogo. O novo jogo era mais longo, com um conjunto muito mais rico de oportunidades para a tomada de decisões. Ele também permitia que os jogadores tivessem sucesso de mais de uma maneira, usando várias estratégias e técnicas de jogo possíveis. Isso foi essencial para o meu objetivo de tornar o jogo tão atraente para as meninas quanto para os meninos, além de agradar a uma gama mais ampla de gostos. No final, o novo jogo provou ser imensamente popular entre um público extremamente amplo.
Obviamente, outra grande diferença é que o OREGON original era um jogo baseado em texto, enquanto o design de 1985 era repleto de gráficos coloridos. A decisão de incluir gráficos foi uma necessidade óbvia, não uma inovação. Por outro lado, algumas de nossas decisões sobre como incluir os gráficos foram de fato inovadoras. Para o jogo de 1985, incorporamos o máximo de detalhes gráficos que pudemos colocar no disco do Apple II, incluindo a tela de viagem animada, as travessias de rio animadas, o jogo de caça, o jogo de rafting e um gráfico em tela cheia para cada um dos pontos de referência.
De vez em quando, encontro um artigo on-line que sugere que a versão de 1985 do Apple II de A Trilha do Oregon era essencialmente idêntico ao jogo original de 1971, exceto pela adição de gráficos coloridos. Essa afirmação é tão ridiculamente imprecisa que me deixa completamente perplexo. Na verdade, a maioria dos recursos e detalhes que as pessoas associam ao jogo foram inventados para o produto de 1985. Por outro lado, meu novo design nunca teria sido criado se não fosse pelo grande sucesso do original. Além disso, a versão original introduziu sete conceitos-chave nos quais se basearam todas as versões posteriores do produto. Mas depois que meu design de 1985 foi lançado, todas as versões subsequentes trataram os 21 novos conceitos principais desse design como parte do núcleo essencial do design original. Da mesma forma, muitos dos detalhes menores do projeto de 1985 também foram incorporados às versões posteriores.
Por que o processo foi bem-sucedido
No final, atingimos e superamos todas as metas desse projeto, exceto pelo fato de que o cronograma e o orçamento foram um pouco mais longos do que havíamos previsto. No entanto, o produto foi concluído a tempo para o lançamento no mercado doméstico no outono de 1985, conforme planejado. Fiel às metas, o produto se tornou um grande sucesso, não apenas no mercado doméstico, mas também no mercado escolar.
Sem dúvida, tivemos alguns contratempos e desvios ao projetar, construir e testar A Trilha do Oregon. E, no entanto, de modo geral, o processo foi bem-sucedido. Analisando os detalhes do projeto, vejo várias lições sobre como planejar e iniciar um novo projeto:
1. Procure obter muitas contribuições, mas não sucumba ao projeto por comitê.
Eu queria que todos os membros da equipe de produtos expressassem seus pensamentos e contribuíssem com ideias. Entretanto, um comitê raramente produzirá um bom design, nem poderá tomar decisões rapidamente. Portanto, nos estágios iniciais do design, comecei com uma fase divergente, quando as ideias são geradas, seguida por uma fase convergente, quando as ideias são reduzidas. Muitas pessoas podem e devem participar da fase divergente, mas não mais do que três pessoas devem participar da fase convergente de um módulo específico. Depois que os conceitos vencedores são selecionados, a maior parte do trabalho de design ainda está por vir, e a maior parte desse trabalho será feita por indivíduos. Mas durante todo o projeto, os membros da equipe fornecem feedback regular uns aos outros. E em pontos importantes do projeto, é solicitado feedback de pessoas de fora da equipe e são realizados testes com usuários. Dessa forma, mantemos o equilíbrio entre obter ideias de muitas pessoas e, ao mesmo tempo, tomar decisões com muito poucas pessoas.
2. Crie o design em estágios de refinamento sucessivo.
Antes de tentar projetar A Trilha do OregonQuando você está criando o produto, achei importante definir as ideias de alto nível, começando com as metas: Por que estamos criando este produto? Quem é o público-alvo? Quais serão nossos critérios de sucesso? Em seguida, propus uma estrutura geral para o produto, juntamente com os principais módulos e recursos. Depois disso, definimos cada um dos módulos e recursos em um nível médio de detalhes - o suficiente para comunicar como cada um deles funcionaria. Por fim, eu detalhei todos os detalhes de cada módulo e recurso. Enquanto isso, à medida que o produto tomava forma - primeiro como protótipos e depois como módulos de código reais -, eu continuava a fazer melhorias no design. Cada tela passou por sucessivas ondas de análise para melhorar o layout, o texto e a usabilidade, e as equações matemáticas subjacentes passaram por rodadas de ajustes para melhorar a jogabilidade. Duvido que fosse possível projetar tudo primeiro, em um único documento enorme, antes de começar a trabalhar na construção do produto. A tentativa de criar um documento enorme no início teria sido um desperdício, na melhor das hipóteses, e catastrófico, na pior.
3. Crie protótipos.
Embora seja útil desenhar esboços das telas propostas, um protótipo fornece informações adicionais. O primeiro objetivo da prototipagem é a "visualização", permitindo que as pessoas tenham uma visão do produto final, mesmo que seja apenas em sua forma bruta. Em um segundo estágio, o protótipo pode ser parcialmente interativo, permitindo que as pessoas sintam o gostinho de jogar o jogo finalizado. Esses dois estágios fornecem informações úteis para ajustar o design relativamente cedo no projeto, certamente muito mais cedo do que se tivéssemos esperado por uma versão beta antes de mostrá-la a qualquer pessoa.
4. Teste os protótipos e a versão inicial do software com os usuários.
É certamente útil quando os colegas de equipe e outros colegas avaliam os protótipos, mas isso por si só não é adequado. Também é fundamental investigar como os usuários reais reagem ao produto - o mais cedo possível no ciclo de desenvolvimento. Não importa o quanto os designers sejam experientes e perspicazes, sempre haverá surpresas quando os usuários reais experimentarem o produto. Essas surpresas variam de pequenos detalhes a problemas muito maiores. Para A Trilha do OregonEm uma das pequenas surpresas, as crianças não entenderam a palavra "outfits" (roupas), que mudei para "sets of clothes" (conjuntos de roupas). Uma surpresa de nível médio foi que muitos jogadores ficaram confusos com as telas em que você nomeia os membros do grupo, por isso revisei essas telas. E o problema mais importante que descobrimos foi que a tela de viagem no teste alfa não prendia o interesse dos jogadores. Por isso, redesenhamos essa tela, que se tornou a tela mais famosa do produto.
5. Priorize constantemente o que precisa ser feito em seguida.
Em quase todos os projetos em que trabalhei, tivemos que reduzir os planos em algum momento, seja de forma sutil ou drástica. Esse é um dos principais motivos para você priorizar os vários componentes. Sempre enfatize desde o início os módulos e os recursos que provavelmente estarão no produto final.
Os riscos são outro fator a ser considerado. Qualquer projeto tem riscos, que estão ligados a incógnitas. Para reduzir os riscos, é fundamental que você explore as incógnitas no início do projeto. Alguns riscos são baseados em tecnologia: esse módulo será rápido o suficiente? Podemos fazer com que tudo caiba no disco? Alguns riscos são baseados no usuário - Os usuários conseguirão concluir essa tarefa complicada com êxito? Os usuários entenderão o significado e os detalhes dessa tela crucial? As prioridades no início do projeto são projetar e criar protótipos ou módulos de prova de conceito que abordem as principais incógnitas, aumentando assim as chances de sucesso.
Foi exatamente isso que fizemos com A Trilha do Oregon. Nos estágios iniciais, decidimos o que era mais importante ilustrar com o protótipo interno. Em seguida, decidimos quais recursos eram mais importantes para testar com crianças e os incluímos na versão alfa. Imediatamente depois disso, priorizamos todos os módulos e recursos planejados para o produto, partindo do princípio de que nem tudo seria incluído no produto final. Desde o estágio inicial, também elaboramos planos de tecnologia e realizamos testes de tecnologia para lidar com os riscos técnicos.
Resumo e agradecimentos
Ao longo da minha carreira, trabalhei em inúmeros projetos de software. Na grande maioria desses projetos, tenho todos os motivos para me orgulhar dos resultados, embora também esteja ciente de certos detalhes que poderiam ter sido melhorados. Entretanto, com exceção de A Trilha do Oregon-e, em um grau menor Comedores de números-Nenhum desses projetos resultou em um produto que se tornasse realmente famoso, embora alguns deles (especialmente os aplicativos baseados na Web que projetei para empresas) tenham sido de fato muito usados.
O resultado é que me sinto grato por qualquer fama que meus produtos tenham alcançado. Sou particularmente grato por ter tido a oportunidade de trabalhar no *The Oregon Trail* e pela combinação de circunstâncias que permitiram que o produto se tornasse um sucesso tão extraordinário. Sou grato por ter trabalhado com colegas altamente talentosos e dedicados, cuja colaboração desempenhou um papel enorme no sucesso do resultado. (Meus principais colaboradores foram Charolyn Kapplinger, John Krenz, Shirley Keran, Bob Granvin e Roger Shimada). Sou grato à MECC por ter me designado para esse projeto como projetista principal e líder do projeto - e por ter me dado a liberdade de conduzir o projeto como eu considerava adequado (na maior parte do tempo). Sou grato por Don Rawitsch, Bill Heinemann e Paul Dillenberger terem inventado a primeira versão brilhante do jogo, que deu origem a todas as versões subsequentes. E sou grato pelo fato de que milhões de pessoas puderam jogar e se divertir com esse jogo - e que muitas delas se lembram dele com carinho depois de todos esses anos.
R. Philip Bouchard passou 32 anos projetando softwares de computador, 18 dos quais voltados para softwares educacionais. Ele foi o principal designer dos jogos do Apple II A Trilha do Oregon e Os "destruidores de números". Você pode ler mais sobre suas experiências de design em blogonde este artigo foi originalmente publicado.