QuakeC - QuakeC

QuakeC
Paradygmat imperatywne ( proceduralne ), uporządkowane
Zaprojektowany przez John Carmack
Deweloper Oprogramowanie id
Po raz pierwszy pojawiły się 1996
Dyscyplina pisania statyczny , mocny
Główne wdrożenia
Kompilator Quake C, FastQCC, FTEQCC, QCCx, GMQCC
Wpływem
C

QuakeC to skompilowany język opracowany w 1996 roku przez Johna Carmacka z id Software do programowania części gry wideo Quake . Korzystając z QuakeC, programista może w dużym stopniu dostosować Quake do swoich potrzeb, dodając broń, zmieniając logikę i fizykę gry oraz programując złożone scenariusze. Może być używany do kontrolowania wielu aspektów samej gry, takich jak elementy sztucznej inteligencji, wyzwalacze lub zmiany poziomu. Quake silnik był tylko silnik gry używać Quake C. Następujące silniki wykorzystywały moduły gier DLL do dostosowywania napisane w C i C++ od id Tech 4 w górę .

Przegląd

Źródło QuakeC do oryginalnej logiki gry id Software Quake zostało opublikowane w 1996 roku i służyło jako podstawa do modyfikacji, takich jak przechwytywanie flagi i inne. Kod źródłowy QuakeCa jest kompilowany przy użyciu narzędzia o nazwie qcc do kodu bajtowego przechowywanego w pliku o nazwie progs.dat . Programiści modyfikacji Quake'a mogli następnie opublikować swój kod bajtowy progs.dat bez ujawniania swojego kodu źródłowego. Większość modów do Quake'a została opublikowana w ten sposób.

QuakeC pozwolił silnikowi Quake zdominować kierunek gatunku strzelanek pierwszoosobowych . Dzięki pomysłowi Carmacka, by przedłużyć życie gier wideo poprzez dodanie nieograniczonej możliwości rozbudowy (rozszerzalność odegrała już dużą rolę w Doomie ), powstała ogromna społeczność internetowa graczy i programistów, a wiele nowoczesnych gier wieloosobowych jest rozszerzalnych w jakiejś formie.

QuakeC jest znany jako interpreted, ponieważ podczas uruchamiania Quake nieustannie interpretuje plik progs.dat.

Ograniczenia i kolejne rozwiązania

Składnia z Quake C opiera się na tym, w języku programowania C , tłumacząc swoją nazwę, ale nie wspierać wdrażanie nowych typów, struktur, tablic lub jakiegokolwiek odwoływania inny niż „podmiot” typu (która jest zawsze odniesienie). QuakeC cierpi również z powodu faktu, że wiele funkcji wbudowanych (funkcje prototypowane w kodzie QuakeC, ale faktycznie zdefiniowane w silniku gry i napisane w C) zwraca ciągi w tymczasowym buforze ciągów, który może przechowywać tylko jeden ciąg w danym momencie. Innymi słowy, konstrukt taki jak

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

zakończy się niepowodzeniem, ponieważ drugie wywołanie to ftos(które konwertuje wartość zmiennoprzecinkową na łańcuch) nadpisuje łańcuch zwrócony przez pierwsze wywołanie, zanim funkcja SomeFunction będzie mogła coś z nim zrobić. QuakeC nie zawiera żadnych funkcji obsługi ciągów znaków ani funkcji obsługi plików, które po prostu nie były potrzebne w oryginalnej grze.

Większość gier wideo w tamtym czasie miała swoją logikę napisaną w zwykłym C/C++ i skompilowaną do pliku wykonywalnego, co jest szybsze. Utrudnia to jednak społeczności tworzenie modów i sprawia, że ​​proces przenoszenia gry na inną platformę (taką jak Linux ) jest bardziej kosztowny.

Pomimo swoich zalet, wybór implementacji logiki gry przy użyciu niestandardowego języka skryptowego i interpretera został porzucony z silnika Quake II nowej generacji na rzecz skompilowanego kodu C ze względu na ogólną nieelastyczność QuakeC, coraz bardziej złożoną logikę gry, wydajność zyskane dzięki pakowaniu logiki gry do natywnej biblioteki dołączanej dynamicznie oraz korzyści płynącej z wykorzystania już istniejącej społeczności, narzędzi, materiałów edukacyjnych i dokumentacji języka programowania.

Dystrybucja kodu natywnego stworzyła nowe problemy z bezpieczeństwem i przenośnością. Kod bajtowy QuakeC nie dawał wiele okazji do psot, podczas gdy kod natywny ma dostęp do całej maszyny. Kod bajtowy QuakeC działał również na każdym komputerze, na którym można było uruchomić Quake'a. Kompilacja do kodu natywnego stanowiła dodatkową barierę wejścia dla początkujących programistów modów, ponieważ proszono ich o stworzenie bardziej skomplikowanego środowiska programistycznego . Ostatecznym rozwiązaniem, zaimplementowanym przez silnik Quake III , było połączenie zalet oryginalnego QuakeC z zaletami kompilacji C do kodu natywnego. LCC kompilator C przedłużono do opracowania standardowej C w postaci kodu binarnego, który może być interpretowany przez maszynę wirtualną , w sposób podobny do Quake C. Rozwiązanie to rozwiązało problemy związane z bezpieczeństwem, przenośnością i łańcuchem narzędzi, ale straciło przewagę wydajności kodu natywnego. Zostało to rozwiązane przez dalsze kompilowanie kodu bajtowego do kodu natywnego w czasie wykonywania na obsługiwanych maszynach.

Zmodyfikowane kompilatory i rozszerzenia językowe

Dekompilator i rekompilator zostały wydane przez Armina Rigo ( odpowiednio nazwane DEACCi REACC). Programy te powstały w procesie inżynierii wstecznej i najprawdopodobniej zostały opublikowane przed wydaniem programu qcc.

id Software wydany źródła qcc, ich Quake C kompilatora, wraz z oryginalnym kodem Quake C w 1996 roku zmodyfikowane wersje wkrótce powstały, w tym Jonathan Roya fastqcci Ryan „FrikaC” Smitha FrikQCC . Te dodatkowe funkcje, optymalizacje i przyspieszenie kompilacji.

W 1999 roku, kiedy id Software wydało kod z silnika Quake'a na licencji GNU General Public License (GPL), zbadano działanie interpretera kodu bajtowego i wydano nowe kompilatory QuakeC, takie jak JP Grossman qccxi nowa wersja FrikQCC. Te kompilatory wykorzystywały nowo odkryte funkcje w sposób zgodny z poprzednimi wersjami, dzięki czemu kod bajtowy mógł być nadal poprawnie interpretowany przez niezmodyfikowane silniki Quake'a. Nowe funkcje obejmują tablice, wskaźniki, liczby całkowite, pętle i manipulację ciągami.

Wraz z możliwością zmiany kodu źródłowego silnika Quake , do QuakeC dodano kolejne funkcje w postaci nowych wbudowanych funkcji. Funkcje od dawna wyczekiwane przez programistów QuakeC w końcu zostały zrealizowane, ponieważ QuakeC miał teraz funkcje obsługi plików i ciągów, powiększone bufory ciągów, więcej funkcji matematycznych i tak dalej. Jednak programiści korzystający z tych zmian stracili wsteczną kompatybilność z niezmodyfikowanym silnikiem Quake.

Xonotic od wersji 0.7 korzysta zkompilatora gmqcc .

QuakeC po stronie klienta

Niektóre ulepszone silniki Quake (zwłaszcza Darkplaces i FTEQW) obsługują rozszerzenie zwykłego QuakeC (obecnie powszechnie określanego jako QuakeC po stronie serwera), które umożliwia skryptowanie silnika Quake tylko po stronie klienta. Jest to szczególnie przydatne w przypadku GUI, HUDów i wszelkich wizualnie ciężkich efektów, które nie muszą być symulowane na serwerze i przesyłane przez sieć.

Zobacz też

Bibliografia

Linki zewnętrzne