[Notícia] Eric Lindstrom fala com a Game developer Magazine

    Compartilhe
    avatar
    Joana
    Admin
    Admin

    Feminino Número de Mensagens : 177
    Idade : 28
    Localização : Inglaterra
    Pontos : 222
    Data de inscrição : 03/02/2009

    [Notícia] Eric Lindstrom fala com a Game developer Magazine

    Mensagem por Joana em Sex 26 Jun 2009, 02:17

    Lara's Backpack

    Tomb Raider: Underworld
    Postmortem

    Eric Lindstrom
    Game Developer Magazine




    O que correu bem

    1. O longo alfa. Ao marcar uma longa publicação do alfa, fomos capazes de lidar com problemas pré-produção e para também nos preparar para uma versão Beta mais curta dando-nos mais tempo para adicionar detalhes a tempo no final. O que valeu a pena a respeito da produção de arte e é a razão principal pelo qual o jogo tem um visual bom. Também recuperamos de uma grande quantidade de falta de design que foi continuada da pré-produção, e quando chegamos ao código, conseguimos colocar todas as funções principais a tempo. Outra coisa que fizemos correctamente durante a longa fase foi ter múltiplas reduções. Como era o nosso primeiro título "next-gen" e repetidamente subestimamos os problemas de complexidade. Muitas das vezes iríamos encontrar-nos para além da margem, necessitando de uma redução com espaço que sobrasse, apenas para encontrarmo-nos com a mesma situação dentro de um mes ou dois. O jogo foi desenhado para suportar redução, visto que no final do jogo ficaram apenas todos os recursos e áreas originalmente planeados, apenas uma forma mais pequena e ligadas umas às outras de diferentes maneiras. Conseguimos reduzir o escopo ao cortar bocados da árvore por todo o lado, mas mantendo-a intacta.

    2. O foco. Quando se faz uma sequela, produzir um jogo como o anterior com apenas algum conteúdo diferente e alguns novos recursos é um erro comum e fácil de se fazer. Apesar do facto de que tínhamos algumas novas e significantes metas, como por exemplo fazer com que o caminho fosse menos linear e trazendo exploração á vontade, quase caímos nesta armadilha. Muitos na equipa viram que precisava-mos de um ponto de foco adicional para ambos acelerar a equipa e para utilizar técnicas únicas de propostas de vendas para o jogo. O resultado disto foi o conceito de uma exploração de puzzles épica. Fazer dispositivos em grande escala no jogo, e áreas com múltiplas camadas de puzzles ligados, deu ao jogo uma expressão excepcional, mesmo comparado com os jogos anteriores, e isso deu-nos forca para dispensar trabalho de produção pelo jogo. Isto levou a criação de uma sub-equipa devotada apenas a estes puzzles, que se provou complicado de construir. Enquanto talvez teria sido melhor ter planeado isto desde o início, o facto é que nós vimos uma preocupação a crescer, criando esta sub-equipa especial, devotando mais pessoas e recursos para isso e atribuindo um produtor dedicado foi um exemplo do quão bem resolvemos os problemas inesperados no desenvolvimento.

    3. Flexibilidade de produção. Embora tenha sido complicado de redireccionar significantemente a grandeza que Tomb Raider: Underworld era, fizemos bastantes mudanças bem sucedidas quando nos confrontamos com colapsos durante o processo de produção. Começamos por pensar que sabíamos a melhor maneira para desenhar uma selva em ruínas, baseadas em lições que aprendemos dos jogos anteriores, mas a realidade confundiu-nos uma vez mais, e fizemos alterações de acordo. Um exemplo claro e relacionado ao design e are de níveis. Concordamos que seria critico ter as disciplinas a funcionarem em sintonia do dia um para fazer ambientes que seriam divertidos, bonitos e credíveis. Nos jogos anteriores começamos com design-generado de blocos de mesh, levando para a geometria que foi extremamente difícil de tornar em ruínas plausíveis, ou em túmulos lindamente arquitectados que não puderam fornecer uma escalada divertida ou autoria própria de jogabilidade. A nossa solução foi juntar designers de níveis e artistas de ambiente por localização no mundo; tais como México ou Tailândia, e tê-los a trabalhar em conjunto, interagindo na arquitectura do ambiente fazendo ambos divertidos e próximos esteticamente. Enquanto isto nos guiava para a direcção certa, muitos dos nossos processos não funcionaram. Mas a nossa vontade de aceitar esta realidade que as iniciais tentativas falharam, deu-nos uma óportunidade de aprender, e permitiu-nos dar passo de alterar a organização da produção em progresso, muitas das vezes, várias vezes. No final, os nossos métodos de produção não eram perfeitos, mas eram superiores ao que tínhamos pensado que veríamos desde o início

    4. Métricas. Num jogo como Tomb Raider: Underworld, onde o jogador pode interagir com tantos elementos diferentes no ambiente e de tantas maneiras, as métricas eram extremamente importantes. Desde o básico de tirar Lara Croft da grelha e eliminar a grande camada de controlos que a impediam de evoluir na personagem fluente que temos hoje. Tomb Raider: Legend sofreu alterações nas distâncias dos saltos, parâmetros de bordas e outras métricas, até a fase final do desenvolvimento, resultando em várias horas de trabalho para ambos designers e artistas (foi bastante duro para os artistas), e estávamos determinados a evitar tal coisa neste novo jogo.
    Os nossos designers de níveis e sistemas colaboraram para estabelecer métricas para cada aspecto para a interacção do jogador até que um Set. completo fosse definido na fase inicial do desenvolvimento. Algumas alterações foram feitas mais tarde, e foram encontrados buracos que precisavam de ser tapados, mas com todo só nível que mantivemos e ao reenforcar métricas sem grandes alterações significantes foi um grande melhoria das passadas tentativas. Se não fosse for este sucesso, a quantidade de jogo, seria significantemente reduzida.

    5. Sanidade. Muitas das pessoas que trabalham em jogos nunca estiveram num projecto tão grande, em termos de tamanho de equipa, grau de coordenação e de tamanho de momentos de jogo que teriam que ser inseridos no jogo. Adicionado a paixão investida de pessoas tão talentosas na qualidade do jogo final, e a mistura poderia ter sido explosiva. Sim, houveram diferentes opiniões, muitas das vezes fortes, e certamente ouve stress que chegasse para uma ocasional fúria, mas o degrau de profissionalismo era extremamente alto, e isto teve um grande impacto positivo na produção, em maneiras que eram bem mais do que apenas pessoas a darem-se bem. Quando reduções tinham que ser feitas, quando o trabalho tinha que ser refeito ou posto de parte, ou processos alterados quando necessario, maturidade era grande e o ego era baixo. Não tínhamos birras sobre tentar tirar ou elementos favoritos de alguém. Toda a gente permaneceu racional durante o projecto, mesmo até nos dias infernais de tentar resolver os bugs antes da data de submissão. Projectos com nível menor de stress haviam destruído equipas e amizades, e é por isso que isto merece estar na lista do que correu bem - porca usa de um projecto assim, navegando muitas e longas tentativas e atribulações intactas contribuindo tanto para este sucesso como qualquer outro elemento.


    Última edição por Joana em Qua 09 Set 2009, 12:25, editado 2 vez(es)
    avatar
    Joana
    Admin
    Admin

    Feminino Número de Mensagens : 177
    Idade : 28
    Localização : Inglaterra
    Pontos : 222
    Data de inscrição : 03/02/2009

    Re: [Notícia] Eric Lindstrom fala com a Game developer Magazine

    Mensagem por Joana em Ter 08 Set 2009, 20:18

    O que correu mal

    1.Tecnologia partilhada. No início de Tomb Raider: Underworld, a Crystal Dynamics como um estúdio decidiu apostar nas maravilhas de desenvolvimento interno: uma robusta e poderosa base de código partilhada que seria utilizada como ponto de partida de todos os jogos futuros. Este motor seria mantido por engenheiros dedicados que iriam fornecer uma funcionalidade comum que os nossos jogos precisariam, enquanto equipas de rogramadores focavam-se especificamente em recursos dos jogos. O estúdio acreditava que por causa de Tomb Raider Underworld e da base de códigos partilhada ser baseada no código de Tomb Raider Legend, os esforços seriam combinados mesmo com a nossa data limite para a produção já apertada.

    Muito talento no trabalho dos programadores foi dado no código partilhado, incluindo muitos dos quais teriam trabalhado em Tomb Raider Legend, por isso habilidade não era um problema. O maior problema acabou por não ser ambição a mais ou dependências complicadas (embora fosse mesmo problemas, mas não os maiores) Os problemas eram muito relacionados com a propriedade e as prioridades. Numa equipa, quando os horários não são cumpridos e precisamos de colocar as coisas dentro do tempo, toda a equipa se junta, e redefinem a sua missão, e fazem quaisquer mudanças colectivas são precisas para trazer a produção de novo a tempo.

    Mas o grupo de tecnologia partilhada não estava presente na equipa. Enquanto e patente era de servir as equipas, também teria que servir varias equipas com necessidades conflituosas. Do ponto de vista de cada equipa, o grupo de tecnologia partilhada era um esquema de programadores que não faziam relatórios ao nosso engenheiro. Foi uma dependência enorme que nos apenas poderíamos influenciar via petição e persuasão, e frequentemente não poderiam até marcar uma data devido a falta de visibilidade do seu progresso. Sabíamos desde o inicio que baseando Tomb Raider Underworld num incipiente e envolvendo uma base de código seria um risco enorme, uma grande armadilha.

    Então porque e que caminhamos para esta armadilha com os nossos olhos bem abertos? Na altura, parecia um potencial que seria mais útil do que perigoso, mesmo sabendo que há riscos, e que tínhamos as pessoas certas a trabalhar no problema, por isso avançamos com essa tecnologia partilhada e fizemos o nosso melhor sabendo que alguns dos desafios que enfrentámos poderia render mais eficiências mais tarde. Ultimamente, no entanto, alguns dos nossos medos troaram-se realidade, já que pensamos que teríamos uma melhor habilidade de passar os nossos riscos.

    2. Refacturação. Uma das tarefas iniciais de engenharia, envolveu refacturar o código de jogo, de modo a torná-lo mais robusto e capaz de aceitar novas funcionalidades. Este esforço foi importante para expandir eficientemente o conjunto de recursos, mas não foi compreendido no momento, que refacturar significava desmontar o motor de jogo, e monta-lo de novo de tal maneira que se tornou impossível de jogar durante algum tempo.

    A equipa de design antecipou um momento de conforto enquanto trabalhavam nas diferentes camadas do jogo, experimentando diferentes interacções, criando diferentes ambientes de setup, e explorando novas características que não haviam sido possíveis em Tomb Raider Legend.
    Mas a esperança de uma pré-produção desapareceu quando este sistema falhou. Os atrasos habituais e os deslizamentos na agenda apenas prolongaram este problema, durante o qual partes do motor estariam espalhadas por todo o lado, mas o problema agravou-se quando tivemos que passar para a produção, focando-nos mais na versão Alpha, sem ter-mos funções principais a funcionar.

    Tudo isto teve um efeito terrível no design que tinha sido feito anteriormente, um esforço que durou todo o tempo até ao final da produção. Fundamentalmente, tudo isto foi um problema de falta de comunicação, que é um problema comum em todos os projectos. Combatemos este problema desde o início, e dado o tamanho do nosso trabalho de produção, fizemos um óptimo trabalho, mas este problema em particular foi único no quão irreversível se tornou. Melhorar a comunicação da equipa é tentar obter melhor informação directamente, mas tão importante como isso, rapidamente endereçar má comunicação quando tal acontece, assim nunca mais iremos considerar tal um dos tais problemas comuns repetidos. Não se pode apanhar tudo, e o esforço da refacturação escapou-se pelos dedos, e uma vez começado, não poderíamos olhar para trás. Foi particularmente um mau exemplo de falta de comunicação, e tivemos que o controlar. No inicio, tempo precioso da equipa de deisng foi desperdiçado, e o jogo final teria um visual bastante melhorado se tivéssemos encontrado este problema desde o início.

    3. Pré-produção. A nossa pré-produção foi afectada pelos dois problemas anteriores – O esforço da tecnologia partilhada e como refactorar mecânicas anteriormente jogáveis, poderão tornar o jogo inútil – mas no tínhamos a opção de alterar a data de saída do jogo. Isto significa que o tempo de pré-produção seria inferior ao que tínhamos planeado anteriormente para as áreas principais.

    Primeiro, deparamo-nos com algo parecido ao que aconteceu quando Tomb Raider Legend estava a ser produzido, com designers a criar camadas baseado nas métricas, onde as mecânicas seriam ambas jogáveis até mais tarde. Embora isto seja pura violação de uma prática profissional de design, sentimos que o problema seria contido, porque a equipa de design tinha acabado de fazer um jogo Tomb Raider com várias mecânicas semelhantes, por isso, poderíamos passar longo tempo sem eles. Mas a situação estava longe de ser optimista.

    Segundo, pondo de parte a portabilidade de Tomb Raider Legend na Xbox 360, este seria o nosso primeiro projecto para o que seria então, consolas de nova geração. Acabou por se mostrar bem mais complexo e bem mais cheio de conteúdo do que teríamos antecipado, e por causa da nossa capacidade de criar camadas estava comprometida na pré-produção, não poderíamos testar, medir ou alterar coisas adequadamente, da equação da produção. Porque precisávamos de entrar em produção numa determinada data, para obter uma oportunidade razoável de importar a tempo, acabamos a pré-produção antes de termos uma compreensão adequada da nossa necessidade e compreensão de arte e processos de produção, e tão criticamente, antes de acabarmos a conduta e a estoutra de suporte que iríamos precisar mais tarde para importar arte. Tínhamos também falta de pessoal em algumas áreas devido a parte da equipa estar ainda a trabalhar em Tomb Raider: Anniversary. No final foi como se tivéssemos planeado uma fase de conceitos, uma fase de protótipo e uma fase de pré-produção, mas na prática, apenas fizemos alguns conceitos, alguns protótipos e então passamos logo para a produção, antes de acabarmos a pré-produção. Muita desta pressão veio da colisão entre ambição e capacidade, sendo agravado pela diferença entre ter um jogo no papel que queres ter, e saber que a data de produção indica que não podes pela data prescrita, mas não querer alterar nenhum deles.

    No momento, e durante o projecto, sabíamos que era arriscado irmos até á próxima fase de produção, antes de completar a fase anterior, no entanto foi o que fizemos. Isto era um dos erros que se repetiam, por isso, fizemos? Dissonância cognitiva e parte da resposta. Pensamento positivo, é outra parte. Mas principalmente, num mundo imperfeito, todos os riscos que corres é um risco que poderá falhar, e no final de todas as tentativas, acabas por ter de explicar apenas os riscos que tomaste e não correram como planeado, tal como este.

    4. Actos de deuses. Esta é a categoria que alguns postmortems nomeados de “Demos a mais” ou outros problemas que vêem da equipa do exterior. Certamente tínhamos problemas de demonstrações a mais, mas esses eram apenas uma entrada para uma classe de problemas que nos deixariam em pior situação. Demos eram particularmente problemáticos, porque tentamos evitar este problema desde o início. Nos exigimos horários a longo prazo para as demos, e acabamos por os receber. Recusamos rebaixarmo-nos a alguns pedidos para demos que não estavam previstos, e isto foi homenageado pelo director. Mas havia algumas rasteiras, onde alguns dos demos fora de horário foram acomodados devido a várias circunstâncias. Por vezes deparávamo-nos com dilemas onde marketing deu-nos a escolha de um demo em particular, á custa de duas semanas de tempo de produção, parecia uma escolha favorável a longo prazo para o sucesso do produto. Havia histórias a mais de grandes jogos desaparecerem no mercado, ignorando a importância dos demos e das pré-produções.

    Sim, estes demos frequentemente resultam na redução da qualidade do produto, e sim distraem o foco da equipa, mas no final, embora seja doloroso, e melhor fazer a demo. Este é o perfeito exemplo de caminhar para uma armadilha de olhos abertos, cometendo o erro - que sabias que irias cometer – mas tal acontece repetidamente, mas a resposta não é recusar os demos, ou planeá-los melhor, a resposta é fazer um jogo que não esta completo apenas na recta final.

    Tivemos também bastantes altos e baixos durante o projecto, mas especialmente nos líderes: perdemos o nosso director de arte no meio da produção: não para outra companhia, mas para outro tipo de industria, logo não havia muito que poderíamos fazer para o parar. Perdemos também a nossa designer líder no final da produção quando ela deu á luz; também algo que não poderíamos alterar (mesmo se quiséssemos, o bebé é lindo!). E o mais trágico, o nosso designer de níveis faleceu imprevistamente durante a primeira parte da produção. Essas pessoas eram os nossos elementos-chave, não apenas porque eram inteligentes, mas porque estas pessoas tinham feito parte do sucesso de Tomb Raider: Legend, e logo saberiam automaticamente o que fazer neste tipo de jogos. Pessoas como eles são raras, porque os jogos Tomb Raider são complicados de fazer por várias razoes, e no nosso projecto, eram pessoas insubstituíveis. Compensamos estas perdas com pessoas na equipa, dando-lhes novas responsabilidades, e algumas dessas pessoas fizeram um trabalho extraordinário e salvaram-nos. Sem dúvida que iríamos ter uma melhor e facilitada produção se não fossem estas perdas.

    5. Retoques. Sim nos tentamos de mais. É natureza humana tentar alcançar o mais longe possível, e pensar que o braço e mais comprido do que parece, mas alguns jogos são mais sensíveis de pesar do que outros. Se fizeres um jogo Sudoku, podes fazer grelhas até o tempo acabar, mas com jogos com recursos interligados, não esquecendo um início, meio e fim, e muito mais complicado de medir correctamente, e ainda mais complicado de alterar a escala durante a produção. Há histórias de sucesso com respeito ao nosso escopo, e com reduções, conseguimos chegar a versão Beta, mas na análise final, tentamos de mais, e acabamos por necessitar de o fazer e trabalhamos o mais possível para terminar tudo o que era necessário com a melhor qualidade.

    A razão pela qual a escala acabou por distanciar o nosso prazo, foi principalmente porque subestimamos a complexidade de um jogo para Nex-gen, e não passamos tempo suficiente na pré-produção. A maior casualidade de querer de mais num jogo não era o tempo que tínhamos para o acabar – tínhamos muito menos tempo em jogos anteriores – e não foi o caso de deixarmos partes do jogo inacabadas, desde que não haviam buracos na experiencia. O maior dano foi um elemento que era bastante importante para nós: tomar conta de pequenos detalhes. Acolchoamos os nossos horários durante tempo indefinido, de modo a termos tempo para retocar o jogo.

    Complexidades inesperadas no desenvolvimento de nex-gen, juntamente com a comunicação de toda a equipa, uma equipa maior do que o estudo já mais tinham visto, cada vez mais consumida no tempo dos retoques. Isto mostrou que o tempo para retocar o jogo e mais importante do que pensávamos, embora este seja um dos repetidos cenários onde nos questionamos “o que correu mal”, porque lidamos com uma nova classe de desconhecimento. Isto não será o caso daqui para a frente, no entanto, a equipa deve de estar equipada para a próxima vez, evitando os problemas habituais de não agendar tempo de retoques suficiente.


    Última edição por Joana em Qua 09 Set 2009, 12:25, editado 4 vez(es)
    avatar
    Joana
    Admin
    Admin

    Feminino Número de Mensagens : 177
    Idade : 28
    Localização : Inglaterra
    Pontos : 222
    Data de inscrição : 03/02/2009

    Re: [Notícia] Eric Lindstrom fala com a Game developer Magazine

    Mensagem por Joana em Ter 08 Set 2009, 20:36

    Dados do jogo

    Produtora: Eidos
    Desenvolvedor: Crystal Dynamics
    Número de producao: 84 pessoal interno, 15 contractados, nao incluindo o pessoal de tecnologia partilhada
    Tempo de producao: Dois anos e meio
    Datas de lancamento: 18 de Nomevro - USA; 21 de Novembro EU,
    Hardware: Quadcore, com sistemas operativos de 64 bits, 4GB ram, RAID 1.
    Software: Turle rendering package, bableflux, Perforce, MotionBuilder, Maya 8.0, Zbrush, Photoshop, Bink, FMOD, Test Track Pro.
    Plataformas: Xnox360, PS3, PC, Wii, PS2, e Nintendo DS
    avatar
    ♦Vini Raider♦
    Aventureiro
    Aventureiro

    Masculino Número de Mensagens : 58
    Idade : 18
    Localização : ♦Londrina♦
    Pontos : 66
    Data de inscrição : 23/04/2009

    Re: [Notícia] Eric Lindstrom fala com a Game developer Magazine

    Mensagem por ♦Vini Raider♦ em Qui 10 Set 2009, 17:19

    Desculpa nao responde nao tenho coragem le tanto da pra resumi? mrgreen clown
    avatar
    Joana
    Admin
    Admin

    Feminino Número de Mensagens : 177
    Idade : 28
    Localização : Inglaterra
    Pontos : 222
    Data de inscrição : 03/02/2009

    Re: [Notícia] Eric Lindstrom fala com a Game developer Magazine

    Mensagem por Joana em Seg 14 Set 2009, 14:27

    tudo bem, nao tens que ler =) está ai para quem quiser, quanto a resumir, já deu imenso trabalho em traduzir,podes apenas dar uma passagem de olhos se estiveres verdadeiramente interessado =)
    avatar
    gabrielpedroni
    Explorador
    Explorador

    Masculino Número de Mensagens : 29
    Idade : 25
    Localização : Vila Velha - ES
    Pontos : 10
    Data de inscrição : 30/01/2009

    Re: [Notícia] Eric Lindstrom fala com a Game developer Magazine

    Mensagem por gabrielpedroni em Sex 25 Set 2009, 00:32

    Nossa que confusão! '-'
    Fazer um game é bem mais trabalhoso que imaginei '-'
    Mas será que é tão difícil assim, a ponto de terem que se preocupar tanto com detalhes e tals, e esquecer da duração de um game (ñ digo que detalhes não importam! Nunk, importam e muito mesmo!) Mas será que as pessoas estão conseguindo acompanhar mesmo a evolução da tecnologia? Será que o prazo que é muito curto? (o capitalismo atrapalhando um trabalho polido?!)...
    avatar
    Joana
    Admin
    Admin

    Feminino Número de Mensagens : 177
    Idade : 28
    Localização : Inglaterra
    Pontos : 222
    Data de inscrição : 03/02/2009

    Re: [Notícia] Eric Lindstrom fala com a Game developer Magazine

    Mensagem por Joana em Sex 25 Set 2009, 07:21

    é mesmo, acho que tentaram facilitar, mas no final ficou ainda mais complicado do que esperavam. Também nao sabia o trabalho que dava, mas parece que a CD passou por erros que até os novatos sabiam que iria dar problemas.
    Espero que apredam para o próximo jogo.
    avatar
    Bruno Croft
    Raider
    Raider

    Masculino Número de Mensagens : 123
    Idade : 22
    Localização : santo andré - SP
    Pontos : 68
    Data de inscrição : 01/02/2009

    Re: [Notícia] Eric Lindstrom fala com a Game developer Magazine

    Mensagem por Bruno Croft em Seg 26 Out 2009, 22:44

    gente do céu, q trabalho, e fizeram isso em um ano, e o game só tem 8 fases, magina te tivesse mais.
    avatar
    Rana Croft
    Moderador
    Moderador

    Feminino Número de Mensagens : 55
    Idade : 22
    Pontos : 65
    Data de inscrição : 28/03/2009

    Re: [Notícia] Eric Lindstrom fala com a Game developer Magazine

    Mensagem por Rana Croft em Qui 12 Nov 2009, 17:15

    Coitados... DEpois vem a pirataria e derruma os caras que fizeram tantas coisas para o jogo ser lançado. Acho que toda arte tem concenquecias, quando se pinta um quadro algumas horas o artista deseja mudalo mas é tarde de mais.
    avatar
    ♦Vini Raider♦
    Aventureiro
    Aventureiro

    Masculino Número de Mensagens : 58
    Idade : 18
    Localização : ♦Londrina♦
    Pontos : 66
    Data de inscrição : 23/04/2009

    Re: [Notícia] Eric Lindstrom fala com a Game developer Magazine

    Mensagem por ♦Vini Raider♦ em Qua 18 Nov 2009, 15:14

    Nao Vou Deixar De concordar com a Rana Very Happy
    avatar
    Joana
    Admin
    Admin

    Feminino Número de Mensagens : 177
    Idade : 28
    Localização : Inglaterra
    Pontos : 222
    Data de inscrição : 03/02/2009

    Re: [Notícia] Eric Lindstrom fala com a Game developer Magazine

    Mensagem por Joana em Sex 04 Dez 2009, 15:59

    Bruno Croft escreveu:gente do céu, q trabalho, e fizeram isso em um ano, e o game só tem 8 fases, magina te tivesse mais.

    se nao estou em erro, Underworld foi feito em 3 anos =)
    avatar
    Jéssica Croft
    Doppëlganger
    Doppëlganger

    Feminino Número de Mensagens : 68
    Idade : 21
    Localização : são paulo
    Pontos : 126
    Data de inscrição : 13/09/2009

    Re: [Notícia] Eric Lindstrom fala com a Game developer Magazine

    Mensagem por Jéssica Croft em Sex 11 Dez 2009, 11:46

    So que não temos dinheiro para comprar verdadeiro se pelo menos ele baixacem o preço acho que eu so ia comprar verdadeiro

    Conteúdo patrocinado

    Re: [Notícia] Eric Lindstrom fala com a Game developer Magazine

    Mensagem por Conteúdo patrocinado


      Data/hora atual: Qui 14 Dez 2017, 17:58