O SCUMM pode ser considerado simplesmente "um dos" mecanismos de videogame, mas esse mecanismo causa quase tantos sentimentos quanto os jogos criados com base em ele.

Falando da era de ouro da aventura da LucasArts, você não pode ignorar o mecanismo SCUMM, "Script Creation Utility for Maniac Mansion" ("utilitário de criação de scripts para Maniac Mansion"), que foi usado nos jogos mais lembrados de todos os tempos, como Full Throttle , Day of the Tentacle , Sam e Max Hit the Road , e, claro, Maniac Mansion .

O SCUMM foi escrito por Aric Wilmunder, juntamente com o renomado designer de jogos Ron Gilbert, proporcionando assim a oportunidade de criar esses jogos. Wilmunder e o jornalista Mike Bevan entraram em contato recentemente por e-mail e discutiram o SCUMM e as histórias em torno dele. O artigo apresenta fragmentos selecionados dessa conversa, registrados a partir das palavras de Wilmunder.

Decidimos que era importante transmitir as palavras de Wilmunder, porque o SCUMM não é apenas um mecanismo ou tecnologia. Para muitos desenvolvedores, essa era uma maneira de transmitir sua visão artística a milhares de pessoas em um dos períodos mais memoráveis ​​da história dos videogames.

Evolução do motor

Um dos recursos que distinguiu a LucasArts da maioria dos outros desenvolvedores foi o fato de muitos de nós virmos de mainframes, por isso desenvolvemos ferramentas e compiladores nas estações de trabalho da Sun e, em seguida, criamos equipamentos que nos permitiam baixar código e dados para as plataformas desejadas. Tudo começou com o Atari 800 e, em seguida, Ron [Gilbert] foi contratado para trabalhar com o C64; portanto, um sistema semelhante foi criado para esta plataforma.

A vantagem mais importante era que poderíamos desenvolver ferramentas em C ou, como no caso do SCUMM, usar o YACC para processar e marcar o código. A maioria dos desenvolvedores usava a mesma máquina para escrever e executar código; portanto, suas ferramentas usavam os recursos de apenas uma plataforma.

Após os primeiros anos de desenvolvimento de produtos para o PC, o próprio PC se tornou tão poderoso quanto nossas primeiras estações de trabalho; assim, um a um, começamos a migrar nossas ferramentas e abandonamos gradualmente as estações de trabalho da Sun.

A evolução da oportunidade começou muito cedo. Eu fui o primeiro desenvolvedor interno trabalhando em um PC e, na época, as ferramentas e os compiladores eram muito rudes. Por exemplo, compiladores C, em caso de erros, produziram descrições muito "detalhadas". No PC, você pode receber uma mensagem como “Arquivo: walk.c Linha: 409 Erro: 4004”, após o qual você precisava entrar no código e descobrir qual era o problema, ou obter o manual e transformar o código de erro em algo mais compreensível. Às vezes, as descrições de erro também eram confusas. Como não tínhamos bons editores para escrever código em um PC, usei editores na Sun e depois transferi arquivos. Quando ocorreram erros no PC, recompilei e depurei o código na estação de trabalho Sun. Isso me incentivou a escrever um código mais limpo que funcionasse em duas máquinas muito diferentes desde o início.

Havia muitas dificuldades adicionais no PC, porque os controles, sons e gráficos eram completamente diferentes. Por exemplo, os ratos nem sempre eram um equipamento padrão; portanto, o controle foi projetado para um mouse, joysticks ou teclado. Isso simplificou a transferência do mecanismo de jogo para outras plataformas, porque o gerenciamento tornou-se modular. Para som, suportamos o alto-falante interno, também parece ser uma placa de som CMS (antecessora de Adlib), além de um sistema de som para computadores Tandy. Os gráficos também eram modulares porque apoiamos os monitores Hercules em preto e branco, gráficos CGA de quatro cores, EGA de 16 cores, VGA no modo de 16 cores e Tandy Graphics em outro modo gráfico. Para implementar isso, todos os gráficos foram renderizados em um buffer de memória e, em seguida, procedimentos muito especializados copiaram o buffer na placa de vídeo. Utilizamos o sistema chamado “retângulos sujos”, que rastreia as áreas que foram atualizadas, e copiamos apenas as partes necessárias da tela.


Arik Wilmunder

Comunicação sobre SCUMM

SCUMM era uma linguagem compilada. Por exemplo, o comando walk dr-fred to laborator-door converteu o comando Walk em um comando de byte único. O byte seguinte determinou para qual ator ou caractere esse comando era e o objeto da porta do laboratório foi convertido em um número de byte duplo, ou seja, o comando inteiro foi reduzido para quatro bytes de dados. Se você não sabe, um byte é uma parte da memória do computador que pode conter um valor numérico de 0 a 255. Como podemos ver, uma linguagem marcada é muito eficaz. O intérprete nunca soube qual ator foi agredido; era apenas o número do ator, por isso sempre tentamos evitar a tarefa difícil de qualquer informação específica sobre o jogo diretamente no intérprete.

A única exceção a essa regra em Maniac era a cor com a qual o ator exibia o texto ...

Ao desenvolver o Maniac , tivemos algumas exceções à regra de que o intérprete nunca deveria ter codificado os valores do jogo. Nele, eu precisava especificar as cores usadas pelos atores e a cor da exibição de suas frases. O código fonte incorporou esses valores no intérprete. Depois de portar o Maniac para PC e antes do lançamento de Zak McKracken , dois novos comandos foram adicionados para que esses valores pudessem ser controlados a partir de scripts. "Set-actor-talk-color" e "set-actor-color" removeram comandos específicos do jogo do intérprete para que o script controlasse tudo.

Estou falando de um intérprete, então vamos dar uma olhada mais de perto. Um intérprete é um programa iniciado por um usuário final. Inicializa gráficos e sons, lê arquivos do disco e interpreta scripts nesses arquivos para executar o jogo. Quando o jogo foi lançado, renomeamos o intérprete para “Monkey.exe” ou “Dig.exe”, mas durante o desenvolvimento essa ferramenta foi chamada SPUTM, que significa “SCUMM Presentation Utility (tm)”. Na verdade, o nome não é uma marca registrada (TM), mas apenas queremos nomeá-lo como outro fluido corporal.

SCUMM, ou Utilitário de criação de script para Maniac Mansion, era uma ferramenta para marcar scripts e combinar todos os recursos do jogo em arquivos que lançamos em discos. A versão SCUMM usada para Maniac deve conter aproximadamente 80% das equipes usadas em jogos subseqüentes, como Full Throttle . Depois de concluir o desenvolvimento da linguagem, os comandos mais importantes nunca mudavam. "Andar em direção ao relógio" e "caminhar com a motocicleta" eram essencialmente os mesmos.

Multitarefa SCUMM

Provavelmente a parte mais proeminente do SCUMM foi a multitarefa. Isso significava que vários scripts poderiam ser executados ao mesmo tempo. Você pode criar um relógio de parede no escritório de Zach McCracken e animá-lo. Havia um script simples e muito simples, especialmente para o relógio, que dizia ao mecanismo de animação para mudar uma imagem de relógio para o próximo, instruía o mecanismo de som a reproduzir o som do tique-taque e, em seguida, ordenou que o script fosse “adormecido por 1 segundo” e repetiu as ações. Os comandos Sleep foram enganosamente simples que informavam ao sistema que o script estava completo e que você precisa voltar depois de algum tempo e continuar executando o script a partir do ponto em que a saída foi executada. O sono espera um período especificado.

Havia também o recurso "Wait". Era frequentemente usado quando um ator era ordenado a ir a um objeto ou virar na direção certa. O script simplesmente instruiu o ator a sair, depois deu o comando "esperar pelo ator", que mergulhou o script no modo de suspensão até o ator atingir o ponto desejado ou virar na direção certa. Isso nos permitiu escrever roteiros em um estilo muito linear, refletindo a sequência de ações que o ator teve que realizar.

Todo o tipo de ferramentas úteis com nomes repugnantes

Juntamente com o SCUMM e o SPUTM, havia muitas outras ferramentas que desenvolvemos para a criação de jogos. O SPIT era um editor de fontes simples para criar diferentes formatos de texto para diferentes partes da interface. A caixa de diálogo na parte superior da tela pode ter uma fonte, a outra pode ser usada para a tela de salvar o jogo e a terceira para comandos verbais da interface na parte inferior da tela (Walk-To, Pick-Up, Look At, etc.). O FLEM era uma ferramenta gráfica usada para gerenciar salas. Foi possível marcar objetos em uma sala, seu status (portas fechadas ou abertas) e, assim, criar áreas definindo os locais disponíveis para os atores em movimento. O FLEM também permitiu visualizar planos de recorte, que eram camadas que escondiam um ator que ia além de objetos ou superfícies. Em Maniac, havia apenas uma superfície, mas nos jogos subseqüentes poderia haver até três aviões, atrás dos quais o ator poderia se esconder.


Mansão maníaca

MMUCUS foi assistente do FLEM. O MMUCUS recebeu a imagem da sala e os dados dos objetos, os dados dos planos de recorte e áreas nas quais você pode andar, e os compactou em um arquivo de “sala” contendo todas essas informações. Isso foi importante porque a conexão dos dados compactados permitiu que os criadores do script fizessem alterações rápidas no script, após o que era necessário compilá-lo para que as alterações entrassem em vigor. O arquivo da sala permaneceu inalterado, sendo alterado apenas ao adicionar objetos ou alterar áreas disponíveis para movimento.

BYLE é a nossa ferramenta de animação original usada para desenhar e animar atores. O BYLE tinha um mecanismo de animação simples que poderia ser programado para alternar a animação de um quadro para outro. Além disso, ele entendeu a “direção”, ou seja, era possível mudar o lado em que o ator se virou. Foi possível compactar os atores de várias maneiras, e isso nos permitiu fazer animações muito simples e rápidas, como no início de Day of the Tentacle, ocupar pouco espaço e, para personagens multicoloridos, por exemplo, Ben Throttle, outro método de compressão necessário apenas com 16 ou 32 cores. Com o tempo, tínhamos necessidade de animações mais complexas; portanto, uma nova ferramenta CYST foi desenvolvida, que usava o mesmo formato de dados, mas o gerenciamento de imagens grandes foi bastante simplificado.

Por um tempo muito curto, tivemos uma ferramenta chamada SMEGMA. Um dos programadores teve um bebê e ele nos disse que a primeira descarga intestinal do bebê consiste nessa substância. Aconteceu que ele estava enganado, e a substância é chamada de mecônio (mecônio). Não descobrimos o que é Smegma, apenas gostamos do nome. Mas uma vez que eles verificaram o significado da palavra, e depois de alguns dias eles mudaram o nome. Você provavelmente pode imaginar que ficar ao nosso lado na sala de jantar era bastante desagradável, discutimos SCUMM, BYLE, MMUCUS, FLEM e assim por diante. [Nota trans .: um dos valores da escória é semente, bile é bile, muco é muco, FLEM é consoante com catarro é catarro.]

Atualização SCUMM

O SCUMM é criticado por não fazer mudanças revolucionárias e, em vez disso, foi gradualmente aprimorado. Um exemplo claro disso são os gráficos. Começamos suportando gráficos de 16 cores na resolução de 320x200. Com o aumento do número de placas gráficas, passamos para 256 cores e uma resolução de 640x480. No sistema de som, começamos com o alto-falante interno da IBM e mudamos para o som estéreo de transmissão multicanal. Os caracteres que costumavam ter apenas alguns pixels de altura agora podiam crescer para quase toda a altura da tela. As interfaces também evoluíram: da interface inicial com comandos verbais à interface do usuário complexa com base em ícones semelhantes ao estilo moderno do Mac.

Uma das etapas importantes foi a integração do mecanismo INSANE, um sistema de vídeo desenvolvido para o Rebel Assault. Inicialmente, contratei Vince Lee para trabalhar em uma versão de um dos jogos SCUMM para Amiga, mas ele rapidamente provou suas habilidades de programação em várias plataformas. Enquanto trabalhava no SCUMM, ele me viu fazendo o trabalho de isolar as principais partes do sistema dependentes da máquina para simplificar a portabilidade para outros computadores. Enquanto desenvolvia o INSANE, ele tentou levar essa abordagem para um novo nível e adicionou a capacidade de transmitir e ramificar vídeos, por isso consideramos muito importante implementar esse sistema no SCUMM. O acelerador total foi o primeiro passo nesse processo. Graças às trilhas sonoras de rock and roll de Gone Jackals, quando alguém começou o jogo na sala ao lado, outros rapidamente o perceberam. O motor do acelerador era claramente imperfeito: quando o INSANE foi iniciado, o sistema SCUMM teve que ser interrompido. Portanto, entre o Throttle e o Monkey 3, tentei integrar totalmente esses dois sistemas. Joguei fora o sistema de vídeo e cursor original, até o sistema de fontes, de modo que o SPUTM foi executado em cima do INSANE. Acabamos colocando mais e mais ovos em uma cesta, mas os benefícios eram enormes. Por exemplo, se eu adicionasse suporte para japonês ou coreano, os produtos no mecanismo Rebel Assault e os produtos no SCUMM poderiam suportar japonês e coreano.

Multiplataforma impressionante

Graças à facilidade de portabilidade, os jogos SCUMM rodavam em mais de uma dúzia de sistemas e cerca de uma dúzia de idiomas. Começamos com o Commodore 64, havia um PC IBM, Atari ST, Amiga, um console Nintendo de oito bits, Fujitsu Towns, [Fujitsu] FM Marty, CD da Sega, CD Sega, CDTV, Mac e recentemente também adicionamos o iPhone ao iPad. Nada mal para um sistema desenvolvido há 25 anos.

Com projetos como o ScummVM, escritos por fãs do intérprete SCUMM, é possível o suporte a novas plataformas. Foi a Ilha dos Macacos que foi escolhida como um dos cinco jogos em exibição no Museu Smithsonian de Arte Americana e provando que uma boa história costuma ser mais importante que a nova tecnologia dos jogos de um dia.

Nem todo mundo sabia que o SCUMM também era a base de muitos jogos educacionais populares, como Putt-Putt , Freddi Fish e Spy Fox , além da série Backyard Baseball / Football / Soccer , desenvolvida pela Humongous Entertainment. Se você olhar para dentro, poderá encontrar as mesmas equipes e quase o mesmo código dos irmãos LucasArts.

Learning SCUMM

Naquela época, todos os designers também eram programadores, então o SCUMM, embora fosse único em muitos aspectos, era bastante simples de aprender e codificar. Durante Maniac ou Zak , o mecanismo não tinha um manual, mas antes do Monkey, um grupo de 6 a 8 novos criadores de scripts foi contratado. Um guia foi escrito para eles e treinamento semanal (Scumm University, "Scumm University"). Nos cursos, Ron pegou o jogo mais recente, excluiu tudo, exceto uma sala, e colocou objetos mostrando as capacidades do mecanismo.

Novos criadores de scripts ("estiletes") começaram nesta sala e aprenderam o básico. Por vários dias, eles foram ensinados a adicionar novas salas, criar áreas de movimento. Alguns tinham habilidades artísticas e criaram suas próprias animações, outros estavam envolvidos em escrever diálogos. Normalmente, até o final da semana, já tínhamos um bom entendimento das habilidades que os "golpistas" tinham, após o que os líderes de vários projetos escolheram quais deles trabalhariam em seus projetos.

Parece-me que a primeira "Universidade de Scumm", ou "Scumm U", começou com uma interface padrão com verbos. Um dos primeiros projetos sempre foi a análise da interface. Portanto, geralmente um ou dois criadores de scripts começaram fazendo o sistema funcionar. Por falar em "barracas" de treinamento, lembro-me que uma vez foi realizada no Ranch [George Lucas Ranch]. Todos se reuniram no terceiro andar do edifício principal. Os escritórios de George ficavam no segundo andar, então eles precisavam se comportar muito bem.


Segredo da ilha dos macacos

Vantagem SCUMM

Uma das maiores vantagens do SCUMM foi a alta velocidade de prototipagem. O designer teve idéias para salas e locais e, em seguida, o artista de fundo começou a fazer esboços. Quando um número suficiente de esboços estava pronto, eles foram digitalizados, adicionados muito rapidamente e conectados usando o SCUMM. Geralmente, poucas semanas após o início do processo de design, já havia várias dúzias de salas, às vezes eram apenas esboços a lápis. Pegamos atores de outro jogo e começamos a montá-los. Às vezes, a sala precisava ser revertida ou redesenhada, se não se encaixasse muito bem, mas você ainda podia criar um protótipo de uma grande parte do jogo.

Agora, os criadores de roteiros poderiam criar áreas preliminares de movimento para que o ator pudesse se mover pela sala, os artistas de fundo poderiam começar a converter os esboços nos gráficos finais, e os animadores começariam a trabalhar na animação dos personagens. Como os personagens finais ainda estavam em processo de criação, nesse estágio de desenvolvimento, você poderia passear em uma sala de Full Throttle , a lápis, mas os jogos Guybrush dos jogos Monkey Island poderiam substituir o personagem principal. Tais substituições permitiram aos projetistas experimentar e fazer alterações e melhorias com custos de mão-de-obra muito baixos.

Longa vida SCUMM

Acho que nenhum de nós pensou que os jogos SCUMM estivessem conosco por tanto tempo. Trabalhei no sistema por cerca de doze anos, e me esforcei constantemente para preparar o código para uso a longo prazo, testando-o no maior número possível de plataformas. Ao desenvolver no Windows, testei-o no Windows NT, mesmo que não fosse uma das nossas plataformas de destino. Mas o NT exigia padrões de código mais rígidos. Portanto, se o jogo funcionasse no NT, as chances eram de que funcionasse em futuros sistemas operacionais Windows.

Eu também tentei evitar truques muito frequentes no código que poderiam causar falhas nos computadores do futuro. Por exemplo, você pode escrever código com alteração automática, mas com certos tamanhos e tipos de cache do processador, isso levará à falha.Portanto, em vez disso, escrevi cinco ou seis variações ligeiramente diferentes de um procedimento, cada uma delas especialmente otimizada para uma situação específica. Por exemplo, havia muitas versões do código de renderização de ator. Se o ator estava no modo de tela cheia e não estava escondido atrás de outros objetos, usei uma versão do código. Se o ator foi além da borda esquerda ou direita da tela, eu fiz uma versão diferente. Escalar o ator era outra versão. Parece que havia oito variações na aparência de um ator, e eu tinha oito versões do código, cada uma delas otimizada para a execução mais rápida da tarefa. Além disso, originalmente escrevi código em C para fazê-lo funcionar e otimizar. Em seguida, reescrevi o código na linguagem assembly para obter a velocidade máxima. Código C era convenientequando desenvolvemos o SCUMM para outros computadores, porque os desenvolvedores poderiam executar esse código e ele funcionou, após o qual foi possível fazer sua otimização.

Scumm 2.0 Zak . Maniac 1.0, Zak — 2.0, Monkey — 3.0, Indiana Jones and the Last Crusade — - 3.0 3.1. , . , . 256- Indiana Jones . , 256- , .

Ron trabalhou com intérpretes por um tempo. Ele desenvolveu novas equipes que poderiam ser adicionadas ao Commodore Basic, e fez a engenharia reversa desse sistema. Ao criar o Maniac, ele pensou que essa seria a melhor abordagem, e Chip Morningstar tinha experiência em trabalhar com compiladores de idiomas; portanto, o idioma foi desenvolvido principalmente graças à sua cooperação. A ironia é que Chip estava trabalhando no projeto Habitat na época., no qual, em vez do código interpretado, fragmentos do código assembler 6502 eram suportados, que eram alterados e movidos para a memória. A falha de qualquer um desses fragmentos causou a falha de todo o sistema. Por outro lado, o SCUMM usou apenas cerca de 80 comandos, e os comandos foram compactados em bytes com valores de 0 a 255. Se o valor do comando era maior que 80, o sistema relatou um erro, portanto, o SCUMM pôde rapidamente deixar claro que estava executando comandos incorretos . E o Habitat simplesmente "caiu", e era muito difícil rastrear erros nele. Penso que, em retrospecto, Chip decidirá usar uma linguagem interpretada.



Outra vantagem das linguagens interpretadas é a fácil migração entre diferentes plataformas de hardware. O intérprete foi escrito em código C convenientemente portátil e é analisado de maneira muito simples por meio de um conjunto de marcadores de comando. Outra grande vantagem foi que o jogo inteiro era de dados. Ao desenvolver para novas máquinas, sabíamos que todos os dados estavam corretos; portanto, tínhamos que trabalhar e procurar erros apenas em uma quantidade muito pequena de código.

Trabalhe com o inimitável Ron Gilbert

Trabalhar com Ron foi incrivelmente divertido. Aqui estão algumas histórias ...

A maioria dos nossos gráficos iniciais foi criada pela tecnologia da arte tradicional. Lápis, canetas, papel e erros aleatórios foram corrigidos com uma faca Exacto. Uma vez, Ron tirou uma das lâminas e brincou com ele em sua mesa por vários dias. Ele costumava manter uma faca entre os dentes com uma lâmina saindo da boca ao escrever código. Um dia ouvi um suspiro alto, me virei e vi sangue pingando no chão da mão de Ron. Depois que ajudei a enfaixar meu braço, ficamos preocupados com a possibilidade de tétano, então liguei para minha esposa e pedi a Ron para tomar uma injeção. O cabelo de Ron caiu no rosto e ele esqueceu que tinha uma lâmina entre os dentes, fez um movimento com a mão para alisar o cabelo e enfiou a lâmina na palma da mão. Depois disso, as facas não deixaram o departamento de arte.

***

Em outra ocasião, Ron e eu trabalhamos à noite em um prédio no Kerner Boulevard, próximo ao Industrial Light & Magic, e tivemos uma séria discordância sobre como implementar o fragmento de código. Ron e eu muitas vezes trabalhamos até as dez para as onze da noite, então conhecíamos bem os limpadores. Um deles, mais tarde, tornou-se editor de filmes. Bem, naquela noite eu tinha certeza de que minha solução para o problema estava correta, Ron tinha certeza de que sua abordagem era melhor, por algum motivo a disputa gradualmente cresceu e terminou em uma competição de gritos. Finalmente, Ron se levantou, pareceu me repreender, saiu e bateu a porta com todas as suas forças. Acho que pensei em me livrar dele e voltei a escrever código. Cerca de cinco minutos depois, Ron voltou e calmamente disse: “Ok, terminamos com isso. Agora vamos descobrir como resolver esse problema. "Dentro de alguns minutos, já tínhamos retornado ao quadro e trabalhado na solução, ouvindo com mais atenção um ao outro. Como resultado, criamos uma solução híbrida que emprestou o melhor de ambas as nossas idéias. Ron era um verdadeiro mestre da colaboração.

***

Além disso, no início do desenvolvimento, um de nossos funcionários deveria fazer uma apresentação no clube de informática em Berkeley. Como não tínhamos prazos sérios, entramos em um carro para atravessar a ponte Richmond-San Rafael e assistir à apresentação. No meio do correio, Ron viu um carro parado na parada de emergência, então eu parei. Foi nosso funcionário, ele pegou um pneu furado. Ele não tinha roda sobressalente e a minha não servia, mas ele não queria sair do carro, então ele nos deu duas caixas de disquetes e pediu uma apresentação.

Não tínhamos plano de desempenho, apenas CDs. Então, quando eles nos apresentaram, eu comecei a retirar os discos e baixar tudo o que encontrei no computador, enquanto Ron fazia um discurso completamente improvisado. Enquanto estava na faculdade, Ron trabalhava no rádio e fazia parte do "time da manhã", então ele se sentiu como um peixe na água. Eu nunca gostei de falar em público, mas era bom em mostrar demos de programas. A apresentação foi muito bem recebida e voltamos para casa inspirados. Estávamos de bom humor na manhã seguinte, até as dez horas, até que nosso funcionário apareceu. Ele estava com raiva, e não conseguimos entender o porquê. Cobrimos a bunda dele, e a platéia ficou satisfeita. Aconteceu que no corredor havia um amigo de nosso funcionário. Quando perguntado se a demonstração de alguma parte específica foi exibida, descobriu-se que não era.Não sabíamos o que havia nos discos e provavelmente perdemos. Em vez de nos agradecer, o funcionário pensou que sabotamos intencionalmente sua demonstração.

***


Ron Gilberg, Arik Wilmunder, Noah Falstein, por volta de 1985 (foto de Mobygames )

Na noite do terremoto de Loma Priet , Ron e eu tivemos que ir a São Francisco para encontrar sua namorada. As pontes estavam bloqueadas, vimos que um incêndio engoliu um quarto na área da Marina e precisávamos encontrá-lo. Minha esposa ficou muito alarmada, mas eu não queria deixar Ron sozinho. Estávamos prestes a sair de casa, mas o telefone tocou. Este era o amigo de Ron, ela entrou no ônibus para San Rafael e precisava ser levada.

***

Em algum momento, Ron deixou a LucasArts porque sua namorada teve que sair para ensinar na China. Nesse momento, eu estava trabalhando no Maniac Mansion para PC, então, quando conheci as partes escritas por Ron do código que não entendi, literalmente converti o código do assembler 6502 diretamente em C para que o sistema funcionasse mesmo que eu não percebesse o que estava fazendo. Esse código foi reescrito depois que Ron voltou, mas mesmo depois de anos, havia rumores sobre o código 6502 oculto no sistema.

***

No momento de sua partida, Ron emprestou seu novo Mazda RX7 a outro colega. Infelizmente, quando uma noite ele estava voltando para casa, um cervo atravessou a rua, o carro saiu da estrada e rolou sobre uma cerca com arame farpado. O corpo foi arranhado e o teto solar caiu. Antes da chegada de Ron, um colega reparou o corpo inteiro e repintou o carro. Ron não sabia do acidente e ficou surpreso porque o teto solar no teto parecia diferente para ele. Então um colega contou a ele o que aconteceu, Ron se acalmou e não ficou com raiva.

Meu amigo SCUMM

25 anos é muito tempo. Eu não acho que exista uma lista geral de todos os jogos que usaram o SCUMM, mas provavelmente houve 30 a 40 jogos diferentes entre LucasArts e Humongous. Eu sei - alguns designers acharam que o SCUMM limitava suas capacidades. Um deles disse que usar o SCUMM é como tentar mover um elefante com uma borracha.

Mas acho que o jogo mais popular desse designer foi escrito em SCUMM. Às vezes, as limitações no trabalho levam a uma concentração de esforços. O SCUMM foi projetado para fazer uma coisa e, se seu objetivo era criar ótimos anúncios, o SCUMM era definitivamente a melhor opção.

Eu joguei todos os jogos SCUMM muitas vezes, do começo ao fim, embora em The DigParece que perdi alguma coisa e não a toquei desde o início. Fiquei decepcionado por ter visto a solução para a maioria dos melhores quebra-cabeças com antecedência, durante o processo de desenvolvimento ou quando artistas e autores de roteiros trabalhavam neles. Perdi completamente alguns quebra-cabeças, porque conhecia a solução com antecedência e não precisava procurar pistas. Além disso, joguei jogos em vários idiomas e em máquinas diferentes, porque fui responsável pelas versões internacionais e pelo desenvolvimento de plataforma cruzada.



Minha resposta à pergunta sobre meu jogo favorito no SCUMM permanece a mesma por muitos anos. Eu sempre gosto e tenho mais orgulho do jogo mais recente em que estamos trabalhando. A cada novo jogo, tentamos ultrapassar os limites e fazer o que ninguém fez antes de nós. Eu sempre pensei: por que trabalhar se não dermos um novo passo na arte ou na tecnologia? Eu tenho momentos favoritos, por exemplo, a animação inicial em Day of the Tentacle ou o humor de Sam e Max , a música Full Throttle ou a capacidade de mover todos os três personagens maníacos . Cada conquista foi especial, mas todas elas, como crianças nativas, ocupam um lugar especial no coração.