Centro RPG Maker

Post-Mortem escrito por Ray Muzyka – CEO da BioWare e co-produtor executivo de Baldur's Gate II (http://www.gamasutra.com/view/feature/131493/baldurs_gate_ii_the_anatomy_of_a_.php)

---

Introdução

A apenas dois anos atrás Baldur's Gate foi lançado, sendo o resultado demais de 90 homens em um ano de trabalho, um número de inexperientes, porem talentosos e criativos indivíduos aqui da BioWare. A BioWare foi uma desenvolvedora canadense com apenas um título produzido (Sharttered Steel) com créditos antes de Baldur's Gate.


Publicado pela Black Isle Studios (divisão interna de RPGs da Interplay Productions), Baldur's Gate foi o próximo em uma linha de RPGs famosos, onde incluía o venerável Bard's Tale e o altamente respeitado Fallout, ambos desenvolvidos pela Black Isle. Baldur's Gate bateu as probabilidades e se tornou um sucesso da crítica e comercial (conseguiu conquistar praticamente todos os prêmios das categorias de RPGs para computadores e alguns prêmios de jogo do ano, vendendo 1,5 milhões de unidades.).

Após o sucesso de Baldur's Gate, começamos a desenvolver Baldur's Gate II, e provou que a mágica do jogo original não só poderia ser repetida como poderia transformar um jogo que já era bom em algo melhor ainda.


O desafio

Construir uma exímia sequência, não é nem de perto uma tarefa fácil como pode parecer. Enquanto estávamos fazendo BG2, nós sabíamos que todos estariam olhando cuidadosamente para o resultado, comparando-o com muitos outros jogos que utilizaram nossa tecnologia, a Infinity engine, como o Baldur's Gate, Icewind dale e Planetscape: Torment (os dois últimos desenvolvidos pela nossa Publisher Black Isle, após licenciarmos a engines para estes propósitos) nós tínhamos muito trabalho pela frente.

Ao desenvolver uma sequência, você deve começar com a filosofia certa, o objetivo era deixar o jogo melhor e não apenas fazer o mesmo jogo novamente. Você também precisa de um mecanismo para quantificar seus erros prévios e aprender através deles, se você não descobrir o que fez de errado da última vez, provavelmente não vai consertar o problema.

Aqui na BioWare, nós aprendemos a fazer analises minuciosas de review de projetos já finalizados para analisar tanto os pontos fortes e fracos das áreas de desenvolvimento. A melhor forma de começar uma sequência é analisar e melhorar em cima do processo utilizado no original. No caso do original Baldur's Gate, nós achamos que não tivemos o tempo adequado para atingir nossas metas de design, nós estávamos desenvolvendo a Infinity Engine enquanto adicionávamos conteúdo para o jogo. Isso levou a uma extrema pressão para que houvesse áreas simples e game design idem. Com Baldur's Gate II, nós resolvemos permitir que designers tivessem um tempo adequado para que permitisse o jogo atingir seu potencial máximo. Nós aprendemos a analisar nossos projetos prévios, aprender com nossos erros, e aplicar essas soluções para todos os nossos em andamento e novos projetos.




Fazer uma lista de Features

Parte de qualquer plano de design deve ser criar uma lista de features. Graças a licença de AD&D em Baldur's Gate II, nós tínhamos dezenas de possíveis features que poderíamos adicionar ao jogo. Sendo esse o caso, nosso desafio é determinar quais features devemos adicionar. Tivemos dois caminhos, o primeiro era fazer uma lista interna (gerada pela BioWare e nossa Publisher Black Isle/Interplay) do que é viável e razoável, considerando nossa engine, e o segundo é perguntar aos fãs o que eles gostariam de ver. Felizmente no caso de BG2, um número considerável de fãs no Newsgroups já fizeram muito do trabalho para nós, e compilaram uma lista do o que eles gostariam de ver em uma possível sequência. Essa lista nos deu uma ideia do o que nossos fãs mais hardcores estavam esperando, e nos ajudou a apontar-nos na direção correta, a lista das features mais importantes que chegamos à conclusão se parece com essa:

• Maior Resolução (800x600 para cima);
  
• Suporte 3D para placas gráficas;
  
• Não pausar dialogo no Multiplayer;
  
• Painéis de drop off na interface;
  
• Múltiplos kits de novos personagens (sub-classes) para todas as classes;
  
• Movimento mais rápido do personagem;
  
• Dual wielding das armas;
  
• Mais detalhes nas animações (mais frames) e nos personagens;
  
• Inclusão dos monstros mais famosos do AD&D, incluindo o mais famoso de todos, o Dragão;
  
• Magias até o 9º nível;
  
• Jornal Dinâmico, mapa anotável;
  
• Modo Deathmach;
  
• Interação entre personagens em par com Final Fantasy;
  
• Romance entre personagens;
  
• Caminhos entre bem e mal, permitindo uma interpretação do papel do alinhamento;
  

Nós adicionamos diversas features, incluindo uma nova raça (o meio-orc) e três novas classes (feiticeiro, monge e o bárbaro) mais uma myriad de kit de personagens, poucas features tiveram que ser cortadas ou não foram implementadas da maneira que funcionasse da forma que gostaríamos.


Uma coisa que não fizemos, foi ranquear as features em classes simples como essencial, importante, menos importante, etc. Quando se fala em fazer uma decisão de features, nós decidimos manter o máximo que conseguimos mas nós não tínhamos um acordo em qual lista ou quais mecânicas para resolver. Felizmente estávamos utilizando uma engine bem madura a qual aviamos desenvolvido, então adicionar coisas foi relativamente fácil. Entretanto, não posso dizer que todas as decisões foram escolhidas.

Deathmatch foi uma feature que deveria ter sido cortado, mas que persistiu até o final do projeto. Ficou obvio que a data de envio do projeto teria de ser adiada para que o deathmatch fosse colocado no jogo. Considerando que o código do multijogador é o mais frágil da engine, e que o feedback da equipe de QA não foi positivo, nós relutantemente decidimos corta-lo.

Não pausar dialogo foi a mais problemática, no início do projeto foi cortado devido ao limite de tempo, no começo de 2000 decidimos coloca-la novamente, devido que a quantidade de dialogo estava fazendo o multiplayer ficar frustrante. Olhando para trás, isso foi provavelmente a decisão errada. Grande parte do diálogo foi escrito pensando que o jogo pausa durante os diálogos, nós tivemos que criar um sistema hibrido onde diálogos críticos seriam pausados e os demais não. Essas mudanças no código do multijogador criaram muita instabilidade e levou muito dos programadores a trabalharem até tarde.

A lição que aprendemos incluía a necessidade de se realizar uma lista das features, ranqueá-las em ordem de importância e também anotar quais features deveriam ser cortadas. Também aprendemos que não deveríamos voltar a trás de nossas decisões, reconsiderar algo que afeta o desenvolvimento deve ser apenas considerado se for algo crucial para o jogo e então após isso cuidadosamente considerado.


As linhas-guias de Design

Uma coisa que definitivamente não queríamos fazer com Baldur's Gate II é cometer alguns dos mesmos erros de design do jogo original. Como grande parte da equipe é formada por novatos, e considerando que muitas das nossas (autores) memorias não estavam muito claras, decidimos criar uma serie de linhas-guias. Enquanto cada departamento tinha sua própria linha guia, a do level design era de longe a maior de todas, onde era a área onde BG2 tinha o maior espaço para melhorias. Abaixo, uma versão simplificada da lista utilizada por nossos designers:

Regras básicas de design:

• O jogador deve sempre sentir que SUAS ações o estão levando-o para o sucesso. Ele deve sentir que através de suas decisões e ações, ele estará resolvendo puzzles ou batalhas.
• O jogador deve sentir que suas ações afetam o ambiente, suas ações fazem uma pequena diferença em como as coisas funcionam no mundo do jogo. Suas ações têm consequências.
• Quando projetado, deve sempre levar em consideração os caminhos do bem e do mal, a história deve mudar de acordo com o alinhamento do jogador.

Design da História:

• A história deve sempre ter o foco no jogador. O jogador é o elemento principal da história e conflitos devem ser resolvidos por ele.
• É importante o jogador ficar informado sobre o progresso do vilão, isso pode ser feito através de cenas de corte durante a transição de capítulos, ou interagindo com o jogador na main quest de tempos em tempos.
• É importante ter um Twist na história (mais de um se possível). Assim é feita uma revelação ao jogador o que permite ele reavaliar o que está acontecendo na história. Todos os Twists devem envolver o jogador, Twists onde o jogador descobre por si também são bons.
• É importante manter o final do jogo um pouco aberto, especialmente se uma sequência ou pacote de expansão estão sendo planejados.

Design do Ambiente:

• O mundo do jogo deve ser dividido em capítulos. Cada capitulo deve ter aproximadamente o mesmo tamanho em termos de tamanho e exploração. Cada um deve ter um objetivo obvio, mas um que o jogador pode conquistar da maneira que achar melhor.
• Algumas áreas devem ser marcadas como centrais. Essas áreas são geralmente cidades ou lugares similares onde o jogador vai retornar muitas vezes, áreas centrais devem mudar de acordo com as mudanças no ambiente.
• O jogador deve sempre sentir que está explorando áreas importantes, isso significa que áreas devem ter uma sensação única de arte.
• Não é uma boa ideia fazer o jogador mover de área com muita frequência, isso começa a ficar irritante, plots devem ficar dentro do limite de uma única área.
• É bom mostrar lugares e objetos que o jogador não pode utilizar ou acessar, mais tarde, esses objetos ficaram disponíveis.

Design de sistemas do jogo:

• Um sistema de recompensa inteligente deve ser criado. O jogador deve ser recompensado várias vezes durando o percurso do jogo, essas recompensas podem vir em forma de experiência, itens, recompensa na história, novas magias, novos monstros, nova arte, romances, etc.
  
• É importante que o jogador possa personalizar seu personagem, isso significa que ele deve sentir que o personagem que ele está jogando é ele mesmo.
  
• É importante que o mundo reflita as formas como o jogador personalizou seu personagem.
  

Linha-guia dos escritores:

• Sem palavrões modernos, isso exclui palavrões "inferiores" como maldição, inferno, vadia, bastardo.
  
• Cada nódulo de diálogo (pedaços de diálogo) deve ser limitado para duas linhas. Apenas em raras exceções são permitidas mais de duas linhas.
  
• Todas as reações dos personagens deve ter apenas uma linha quando aparecem no jogo, não deve ter motivos para elas serem maiores que isso.
  
• Tente não utilizar sotaques em diálogos, em certos personagens (Elministers, tipos de marinheiros) estão tudo bem, mas devem ser evitados.
  
• Quando utilizando as escolhas do jogador, tente manter o número visível de escolhas para três, dois ou quatro está tudo bem, mas apenas quando necessário.
  
• Quando um NPC fala diretamente com o jogador, isso deve ser anotado para propósitos de script, outros diálogos devem ser incluídos para quando alguém diferente do jogador principal fala com esse personagem.
  
• Dialogo aleatório deve ser evitado, ou deve ser usado com sabedoria. Plebeus devem ter apenas algumas linhas de diálogos aleatórios, mas deve haver vários cidadãos diferentes para se conversar.
  

Tem alguns pontos muito importantes a se falar sobre as linhas-guias, primeiro de tudo, elas são um WIP, e a versão que você vê aqui não é a versão que utilizamos no início do desenvolvimento, segundo, utilizamos isso como linhas-guias e não como leis absolutas. Se uma situação ditasse que as linhas-guias não deveriam ser seguidas, e se fazia sentido não seguir, os designers tinham a amplitude necessária para seguir seus objetivos criativos. Algumas vezes isso funcionava, outras nem tanto.


Em retrospectiva, teria sido de grande ajuda terminar esse conjunto de guias no início do projeto e não em seu termino. Algumas decisões foram feitas no início do desenvolvimento de Baldur's Gate II que não seguiam as linhas-guias e que não poderiam ser desfeitas. O mais notório foi no capítulo 2 do jogo, o capitulo incluía um seguimento de história similar aos outros, porem o jogador poderia acessar todas as sub-quests especificas de classe. Isso potencializou uma diminuição de todos os outros capítulos porque o jogador poderia gastar 60 horas fazendo essas sub-quests, nós precisávamos colocar sub-quests em um ponto onde todos os jogadores poderiam acessa-las igualmente, mas o resultado final é que isso inchou uma secção inicial do jogo, no final não tinha nada que poderíamos fazer para consertar esse erro, então nós simplesmente só poderíamos trabalhar em volta disso.

Outro grande problema relacionado a área da restrição de programação estabelecidos no início do projeto não ser seguido por todos os casos em outros departamentos (design e arte). Por exemplo, nós tínhamos um tamanho máximo que arquivos de áudio poderiam ter, e um tamanho máximo (tanto em área como em número de frames) para um conjunto de efeitos de magias, bem como um tamanho máximo de áreas de seis por seis de 640x480 e um número máximo de personagens por área, em alguns casos isso não foi seguido o que levou a cortes nos frames em algum ponto do jogo. Isso levou a um esforço de optimização frenética para ter o jogo rodando suavemente, próximo do final do desenvolvimento do jogo, quando se tinha pouco tempo disponível nem para identificar as áreas problemáticas como para corrigi-las.

A lição que aprendemos aqui é de estabelecer linhas-guias, seguir elas e ao mesmo tempo refinar as guias conforme o desenvolvimento andava.


Melhore a Pipeline

Um dos elementos mais importantes de qualquer processo de desenvolvimento é a arte e o conteúdo da pipeline. A pipeline é o meio em que artistas e designers colocam o conteúdo em seu jogo. Essencialmente a pipeline de Baldur's Gate II continuou sendo a mesma que a do Baldur's Gate original. Em BG1 a pipeline começou um pouco nebulosa, mas se solidificou concretamente ao final da operação do jogo. Com Tales of Sword Coast (expansão de BG) nós tivemos outros quatro meses para refinar completamente o processo de criação.


Existem quatro divisões básicas da pipeline de Baldur's Gate: Features de programação, filmes, animações dentro do jogo e fases do jogo. O maior e mais complexo é a pipeline das fases do jogo, voltando para BG2, nós tínhamos um processo de oito estágios que seguimos ao criar as fases. O processo de criação era:

• Designers mapeavam uma área e escreviam uma descrição.
  
• Artistas desenhavam um concept isométrico da fase.
  
• Modelos eram criados dos concepts.
  
• Os modelos eram colocados dentro da fase e era colocado a textura.
  
• Os níveis eram enfeitados com pequenos objetos como mesas e barris, a iluminação era feita, e qualquer ajuste final eram feitos.
  
• A peça de arte era entregue aos designers para que o clipping, luminosidade, height e search map possam ser finalizados.
  
• Criaturas, itens, armadilhas e gatilhos eram todos adicionados na fase.
  
• E o script do nível era finalizado.
  

No final do projeto encontramos diversos pontos fracos no procedimento. Achávamos que precisaria de uma maneira melhor de documentar as mudanças que eram feitas em uma fase durante o desenvolvimento. Nós tentamos deixar todos os documentos o mais atualizado o possível, mas com a quantidade de pessoas envolvidas, e o escopo do jogo, era praticamente impossível manter esses documentos precisos, alguns elementos da equipe trabalhavam de forma independente de outros – designers algumas vezes não interagiam adequadamente com artistas, resultando em elementos faltando em áreas do jogo e diferentes nomenclaturas entre arte e design, um grande problema se você considerar que BG2 tem uma considerável quantidade de áreas, criaturas e peças de arte. A melhoria na integração entre diferentes disciplinas (programação, arte, design, QA, áudio, etc.) é nosso objetivo agora para todos os nossos novos projetos. Por exemplo em Neverwinter Nights nós temos um database (chamado de editor de eventos) onde mantemos o controle de todas as mudanças em uma fase do jogo, então desenvolvedores de diferentes áreas podem simultaneamente saber que uma área especifica do jogo foi modificada.

Outro descuido do processo de level design de Baldur's Gate II, inclui a falta de uma fase de teste especifica (efetivamente o nono estágio de desenvolvimento de áreas). O teste da fase no início poderia ter nos ajudado a fazer mudanças e ajustes enquanto a fase ainda está em desenvolvimento, enquanto estava relativamente fácil de se modificar, ao invez de modificar quando já estava no estágio final de QA. Isso poderia ter modificado dinamicamente o processo de teste final, ao invés disso, nós só começamos a testar quando grandes porções do mapa estavam cheias de conteúdo. Enquanto Baldur's Gate II estava em desenvolvimento nós adicionamos um departamento de QA dentro da BioWare para que possamos testar o jogo mais cedo, ao contrário de tarde. Muito do suporte de QA foi fornecido pela nossa Publisher Black Isle/Interplay, enquanto alguns QA testers visitaram a BioWare nos últimos meses do projeto e o teste adicional que ocorreu na Black Isle/Interplay.

Interessantemente, nós fizemos um trabalho tão excelente em automatizar o processo de desenvolvimento das fases que não havia muito tempo para analisar um nível enquanto ele passava pelos estágios. Um designer mandava uma descrição de uma fase e já recebia arte finalizado e um mês depois pronto para o scripting, mas faltando algumas features chave (quase sempre uma porta). Tínhamos então que determinar se a omissão era importante o suficiente para se ter o trabalho de arte refeito, ou fazer qualquer ajuste para o trabalho de design se encaixar na arte finalizada. Novamente, isso cai no problema de integração de disciplinas que comentei anteriormente, algo que sempre vamos trabalhar em nossos futuros RPGs de grande escala.


Durante a produção de Baldur's Gate, adicionamos produtores de linha para ajudar os três produtores a manter a comunicação entre as equipes e controle das tasks. No final BG2 tinha um produtor de linha/designer designado a fazer builds do jogo e administrar os gigantescos recursos do jogo, e outro produtor de linha responsável por dezenas de bugs na lista de bugs. Adicionamos um terceiro produtor de linha no final do desenvolvimento para trabalhar com problemas de compatibilidade e ajudar a responder perguntas técnicas em nosso email de suporte.

Aprendemos a ter certeza de que todos os elementos da equipe estavam se comunicando e trabalhando como um grupo, ao invés de um bando de indivíduos!


Gerenciando o meio do projeto

Durante o desenvolvimento de qualquer projeto, não importa o quão legal, vai chegar uma hora que as pessoas que estão trabalhando vão começar a perder o gás e ficar cansadas. Esse período de inercia no meio do projeto deve ser gerenciado cuidadosamente, com muita atenção voltada aos indivíduos envolvidos. No caso de Baldur's Gate II, nossa situação estava um pouco complicada devido ao fato que tínhamos um novo projeto a caminho na forma de Neverwinter Nights (também com a Black Isle/Interplay como Publisher) na produção do outro lado da sala, e outro novo projeto na forma de nosso RPG do Star Wars (com a LucasArts como Publisher) também a caminho.

Aqui na BioWare nós gostamos de ter eventos mensais para toda a companhia, como ir ao cinema ou fazer um churrasco para dar um descanso e faze-los sair do escritório. Era a nossa forma de dizer que estamos trabalhando pela alegria, estamos fazendo jogos então devemos nos divertir.

Para especificamente a equipe de Baldur's Gate II nós gastamos muito tempo falando com as pessoas ao longo do projeto, especialmente no baixo-meio do projeto, para ter certeza que estávamos dando o devido suporte para as pessoas que estavam trabalhando "escravamente" no jogo. Também trocamos algumas pessoas, um dos pontos fortes de ser uma grande desenvolvedora é que temos diversos projetos arranjados em uma matriz da organização, e em qualquer ponto uma pessoa não se importaria em trocar de projeto. E também, algumas pessoas são mais "começadores" enquanto outras são "finalizadores", é importante entender cada indivíduo e dar as melhores tarefas para suas habilidades.

A lição que aprendemos foi que devemos nos precaver com o meio do projeto, a moral cai muito antes de subir novamente quando o projeto começa a ver a luz do fim do túnel.


Começo e encerramento

Em um projeto tão rico em conteúdo como Baldur's Gate II, nós não precisávamos nos preocupar em cortar conteúdo. Enquanto nós enviamos o jogo com quase todas as features que planejamos originalmente, nós começamos a cortar personagens e quests bem antes da fase de testes finais. E mesmo assim terminamos com mais de 200 horas de gameplay.

Em retrospectiva, deveríamos ter começado esse processo muitos meses antes. Um dos perigos do desenvolvimento de jogos é que os desenvolvedores têm a tendência de sempre adicionar conteúdo quando lhe é dado tempo. Eles não gastam naturalmente o tempo refinando e polindo o conteúdo, ao invés disso, mais tempo significa mais coisas. Por isso é sábio utilizar uma lista de prioridades das features para refinar o trabalho (claro que nossa lista é informal o que dificultou um pouco as coisas).

Nós aprendemos a olhar para o nosso prazo e ajustarmos nosso conteúdo de acordo. De diversas formas, qualidade é melhor que quantidade, apesar de Baldur's Gate II ter muito mais conteúdo que BG1, sua qualidade é superior, nós não nos tocamos de que estávamos colocando conteúdo de mais quando já era tarde demais!


Teste, teste, teste

Por conta de seu imenso tamanho, Baldur's Gate II é um pesadelo para os QA, isso somado ao fato que não fizemos muitos testes durante o desenvolvimento das fases. BG2 contém cerca de 290 quests distintas, algumas mais curtas (cerca de 20 minutos) outras bem longas (mais de uma hora), e cada quest deveria ser testada em modo singleplayer e multiplayer.


Durante o teste adotamos um método de sound task e reporte de bugs, introduzido por nós pelo Feargus Urquhart, diretor da Black Isle Studios e também por Chirs Parker e Doug Avery, nossos produtores da BIS (cada um deles ajudou o projeto de maneiras diferentes). Nós colocamos alguns quadros brancos na sala de teste e na área de design e listamos todas as quest nos quadros, colocamos um "X" do lado de cada quest. Chamamos as equipes de designers e de QA para testar em pares, cada par (um designer e um tester) tiveram a responsabilidade de cuidadosamente checar e consertar cada quest, após eles terem certeza que era aprova de bala, o "X" era removido do quadro. Levou cerca de duas semanas para limpar o quadro (na primeira vez).

Em adição ao teste de subquests, tínhamos um outro grupo de QA da BioWare (consistindo não apenas de um grupo de QAs como programadores juniors e designers) trabalhando no jogo em modo multijogador. Isso em adição a equipe de QA multiplayer da Interplay trabalhando no prédio da BioWare e cerca de 30 pessoas trabalhando no prédio da Interplay. A experiência que Baldur's Gate II reforçou foi que RPGs precisam de uma quantidade significante de QA para que seja um sucesso.

No final, encontramos e eliminamos cerca de 15 mil bugs em Baldur's Gate 2. Graças ao trabalho árduo de todos os envolvidos no Quality Assurance de BG2.

lição: teste antecipadamente! Nunca sabe se você vai ter o tempo adequado mais tarde.


A crise final

O último dia de trabalho do Baldur's Gate II foi estranhamente sereno aqui no escritório, nós não presenciamos aquele pânico que é na maioria das vezes quando vamos finalizar um jogo, mas nós certamente experimentamos um considerável estres enquanto montávamos os 21 candidatos finais em três dias. Após longas noites com a equipe jogando o jogo novamente e novamente, chegamos em um ponto onde montamos um candidato final e enviamos para os duplicadores!

Aprendemos a guardar um pouco de energia para a crise final, porque você vai precisar.


Pós-suporte

O último tópico deste texto é o suporte após o lançamento do jogo, nos recentemente percebemos que acreditamos em suporte pessoal para os compradores de nossos jogos. Apesar de sempre oferecermos o melhor apoio possível, foi apenas após o fim de BG2 que formalizamos isso como um dos objetivos da BioWare. Um grupo de produtores de linha, gerenciados pelos seus produtores, começaram a recentemente a dar o dever formal de fornecer muito rápido (mesmo dia ou mais próximo possível desse valor) apoio técnico para os fãs, seus objetivos são que as pessoas que compraram nossos jogos possam joga-los.

podemos contar com rotas padrões de suporte ao consumidor (e nós temos isso bem claro na forma de CS de nossos publishers da Black Isle/Interplay e LucasArts) mas também queremos ter o tempo para interagir diretamente com os compradores de nossos jogos. Alem do mais, quem é melhor para responder perguntas técnicas sobre o jogo do que as pessoas que trabalharam nele? Para o primeiro fim de semana após o lançamento, nós esquecemos de deixar alguém para o dever de ver as mensagens e suporte (bginfo@bioware.com) em email, então o CEO da BioWare fez o trabalho. Foi bem interessante ver as pessoas desconfiando se realmente eram nós que estávamos respondendo, alguns não acreditaram que iriamos nos importar em responde-los pessoalmente (e fizemos).

Porem uma das coisas mais importantes que aprendemos na indústria durante esses anos é o quão importante é dar suporte aos fãs que compram nossos jogos. Isso significa que lançar um jogo sem bugs, e estar disposto a ajudar as pessoas que tiveram problemas com nosso produto, seja em qualquer mídia que você pode pensar. Qual é o ponto de se fazer um jogo se você não tem certeza de que as pessoas podem joga-lo?


Sumario: O que funcionou bem:

• Tecnologia estável
  
• Equipe dedicada ao projeto
  
• Veteranos retornando ao projeto para melhorar sistemas que eles já haviam criado, assegurando a familiarização com o desenvolvimento da pipeline e engine
  
• Boa disciplina de projeto
  
• Quality Assurance (QA) no final do desenvolvimento
  

Sumario: O que poderia melhorar:

• Fragmentação da comunicação da equipe
  
• Inchaço no conteúdo (jogo grande demais)
  
• falta de QA no início do desenvolvimento
  
• Localização e coordenação pobre (tradução)
  
• Multijogador – dialogo não pausavel, sem personagens protagonistas
  

Conclusão

Em conclusão eu gostaria de agradecer a todo o pessoal que trabalhou em Baldur's Gate II, tanto na equipe de desenvolvimento como também a nossa publisher Black Isle Studios/Interplay, como qualquer jogo grande BG2 tem seus altos e baixos, mas no final estamos bastante orgulhosos de nosso trabalho. Esperamos que essa retrospectiva lhe forneça uma visão dos nossos métodos de desenvolvimento e lhe dê ideias tangíveis que você possa aplicar em suas próprias produções. No final é tudo sobre o jogo, se você se colocar diante de um esforço honesto você estará sempre satisfeito com o seu resultado.[/list][/list][/list]