QuakeC - QuakeC

QuakeC
Paradigma imperativo ( procedimental ), estruturado
Projetado por John Carmack
Desenvolvedor id Software
Apareceu pela primeira vez 1996
Disciplina de digitação estática , forte
Implementações principais
Compilador Quake C, FastQCC, FTEQCC, QCCx, GMQCC
Influenciado por
C

QuakeC é uma linguagem compilada desenvolvida em 1996 por John Carmack da id Software para programar partes do videogame Quake . Usando o QuakeC, um programador é capaz de personalizar o Quake em grandes extensões, adicionando armas, mudando a lógica e a física do jogo e programando cenários complexos. Ele pode ser usado para controlar muitos aspectos do próprio jogo, como partes da IA, gatilhos ou mudanças no nível. O motor Quake era o único motor de jogo a usar o QuakeC. Os motores a seguir usaram módulos de jogo DLL para personalização escritos em C e C ++ a partir da id Tech 4 em diante.

Visão geral

A fonte QuakeC para a lógica de jogo original do id Software Quake foi publicada em 1996 e usada como base para modificações como capture the flag e outras. O código-fonte do QuakeC é compilado usando uma ferramenta chamada qcc em um bytecode mantido em um arquivo chamado progs.dat . Os programadores das modificações do Quake poderiam então publicar seu bytecode progs.dat sem revelar seu código-fonte. A maioria dos mods Quake foi publicada dessa forma.

O QuakeC permitiu que o motor Quake dominasse a direção do gênero de tiro em primeira pessoa . Graças à ideia de Carmack de estender a vida do videogame adicionando capacidade de expansão ilimitada (extensibilidade já desempenhou um grande papel em Doom ), uma enorme comunidade de jogadores e programadores da Internet surgiu e muitos jogos multiplayer modernos são extensíveis de alguma forma.

O QuakeC é conhecido como interpretado porque, conforme o Quake é executado, ele interpreta continuamente o arquivo progs.dat.

Limitações e soluções subsequentes

A sintaxe do QuakeC é baseada na linguagem de programação C , explicando seu nome, mas não suporta a implementação de novos tipos, estruturas, arrays ou qualquer tipo de referência que não seja o tipo "entidade" (que é sempre um referência). QuakeC também sofre com o fato de que muitas funções embutidas (funções prototipadas no código QuakeC, mas na verdade definidas dentro do motor de jogo e escritas em C) retornam strings em um buffer de string temporário, que pode conter apenas uma string por vez. Em outras palavras, uma construção como

SomeFunction (ftos (num1), ftos (num2));

irá falhar porque a segunda chamada para ftos(que converte um valor de ponto flutuante em uma string) sobrescreve a string retornada pela primeira chamada antes que SomeFunction possa fazer algo com ela. O QuakeC não contém nenhuma função de manipulação de strings ou funções de manipulação de arquivos, que simplesmente não eram necessárias para o jogo original.

A maioria dos videogames da época tinha sua lógica de jogo escrita em C / C ++ simples e compilada no executável, o que é mais rápido. No entanto, isso torna mais difícil para a comunidade criar mods e torna o processo de portar o jogo para outra plataforma (como Linux ) mais caro.

Apesar de suas vantagens, a escolha de implementar a lógica do jogo usando uma linguagem de script e interpretador personalizados foi retirada do mecanismo Quake II de próxima geração em favor do código C compilado devido à inflexibilidade geral do QuakeC, a lógica de jogo cada vez mais complexa, o desempenho a ser obtida ao empacotar a lógica do jogo em uma biblioteca de links dinâmicos nativa e a vantagem de aproveitar a comunidade, ferramentas, materiais educacionais e documentação de uma linguagem de programação já estabelecida.

Distribuir código nativo criou novas preocupações de segurança e portabilidade. O bytecode QuakeC ofereceu poucas oportunidades para travessuras, enquanto o código nativo tem acesso a toda a máquina. O bytecode QuakeC também funcionava em qualquer máquina que pudesse rodar o Quake. Compilar para código nativo adicionou uma barreira adicional de entrada para desenvolvedores de mod novatos, porque eles estavam sendo solicitados a configurar um ambiente de programação mais complicado . A solução final, implementada pelo motor Quake III , foi combinar as vantagens do QuakeC original com as vantagens de compilar C para código nativo. O compilador lcc C foi estendido para compilar o C padrão em bytecode, que pode ser interpretado por uma máquina virtual de maneira semelhante ao QuakeC. Isso resolveu os problemas de segurança, portabilidade e cadeia de ferramentas, mas perdeu a vantagem de desempenho do código nativo. Isso foi resolvido compilando ainda mais o bytecode em código nativo em tempo de execução nas máquinas com suporte.

Compiladores modificados e extensões de linguagem

Um descompilador e um recompilador foram lançados por Armin Rigo (chamados DEACCe REACCrespectivamente). Esses programas foram feitos por meio do processo de engenharia reversa e, provavelmente, foram publicados antes do lançamento do qcc.

A id Software lançou o código-fonte de qccseu compilador QuakeC, junto com o código QuakeC original em 1996. Versões modificadas logo surgiram, incluindo Jonathan Roy's fastqcce Ryan "FrikaC" Smith's FrikQCC . Essas funcionalidades adicionadas, otimizações e aumentos de velocidade de compilação.

Em 1999, quando a id Software lançou o código do motor do Quake sob a GNU General Public License (GPL), o funcionamento do interpretador de bytecode foi examinado e novos compiladores QuakeC foram lançados, como JP Grossman qccxe uma nova versão do FrikQCC. Esses compiladores aproveitaram os recursos recém-descobertos de uma maneira compatível com versões anteriores, de modo que o bytecode ainda pudesse ser interpretado corretamente por mecanismos Quake não modificados. Os novos recursos incluem matrizes, ponteiros, inteiros, para loops e manipulação de strings.

Com o código-fonte do mecanismo Quake agora capaz de ser alterado, outros recursos foram adicionados ao QuakeC na forma de novas funções integradas. Recursos há muito desejados pelos codificadores QuakeC finalmente alcançaram a realização, já que o QuakeC agora tinha funções de manipulação de arquivos e strings, buffers de strings aumentados, mais funções matemáticas e assim por diante. No entanto, os programadores que aproveitaram essas mudanças perderam compatibilidade com versões anteriores do mecanismo Quake não modificado.

Xonotic desde a versão 0.7 usa ocompilador gmqcc .

Cliente QuakeC

Alguns motores Quake aprimorados (notavelmente Darkplaces e FTEQW) têm suporte para uma extensão do QuakeC regular (agora comumente referido como QuakeC do lado do servidor) que permite scripts do lado do cliente apenas do motor Quake. Isso é especialmente útil para GUIs, HUDs e quaisquer efeitos visualmente pesados ​​que não precisam ser simulados no servidor e transferidos pela rede.

Veja também

Referências

links externos