|

CORE WARS
Pewnie większość czytelników grała kiedyś w jakiegoś FPP. Zatem nie jest wam obcy również deathmatch. Jednak jeśli ktoś nie wie o co chodzi (są tacy???), to tak w skrócie: deathmach polega na tym, że kilka(naście) osób walczy ze sobą "każdy na każdego". Na podobnym pomyśle opierają się tzw. "core wars" (wojny rdzeniowe). Z tym, że nie mamy tutaj super grafiki wykorzystującej wszystkie możliwości najnowszych akceleratorów, ani genialnej muzyki. Nie mamy również masy broni i zakręconych w chińskie osiemnaście map. I tu pewnie większości nasunie się pytanie: to w takim razie jak się walczy? Otóż do walki zamiast railguna wykorzystujemy programy. I to nie pisane w jakimś tam C czy innym Pascalu. Programy do wojen rdzeniowych pisze się w czystym Assemblerze lub Redcode (modyfikacja Assemblera stworzona specjalnie na potrzeby core wars) i pochodnych (np. CoreWars). Pojedynki rozstrzygają specjalne programy, które jednocześnie czuwają nad tym, aby walczące procesy nie spowodowały niestabilności systemu (mimo, iż zazwyczaj i tak jest to mało prawdopodobne - walki odbywają się na komputerach z Unixem, który posiada wbudowane mechanizmy zwiększające stabilność).
Walka takich programów polega, podobnie jak w FPP, na wykończeniu wszystkich przeciwników. W tym celu trzeba najpierw ich zlokalizować, a potem "zabić". W poszukiwaniu wrogów programy kopiują się po całej dostępnej pamięci lub rozpoczynają nowe wątki (tzn. jakąś część programu jest kopiowana do innego miejsca w pamięci i tam rozpoczyna samodzielną działalność). To drugie rozwiązanie ma jednak jedna istotna wadę - spowalnia działanie wszystkich wątków danego programu (zwanego również procesem). Dzieje się tak, ponieważ każdy z procesów, ma do wykorzystania określoną ilość zasobów procesora, które trzeba podzielić miedzy wszystkie jego wątki. Do zabicia jakiegoś programu wykorzystuje się to, przez co Windows się tak często wiesza - brak ochrony pamięci. Zadanie polega na tym, żeby wrogiemu programowi umieścić w pamięci pustą instrukcję, tzw. data 0. Kiedy program spróbuje ja wykonać, spowoduje błąd i w efekcie "umrze". Można również w kod wroga wstawić jakąś instrukcję, która też spowoduje jego śmierć (np. polecenie wykonania komórki pamięci, o której wiemy na pewno, że zawiera data 0). W niektórych pojedynkach (tj. nadzorowanych przez programy posiadające taką opcje) możliwe jest drugie zakończenie walki. Otóż jeśli w pojedynku istnieje możliwość ograniczenia ilości wątków uruchomionych przez dany program, to wystarczy wroga zmusić do rozmnożenia się (np. przez wrzucenie mu odpowiednich instrukcji w kod).
Ale napisanie działającego programu to nie wszystko. Program musi być jak najmniejszy. Dlaczego? Ano żeby było trudniej trafić (ciężko było to wymyślić, nie ;))! I tu przychodzi nam z pomocą bardzo istotna umiejętność każdego programisty. Chodzi o optymalizację kodu. Generalnie chodzi o to, żeby to co można zapisać w jakiejś ilości instrukcji, zrobić krócej i bez zmiany w działaniu. Jest to chyba najtrudniejsza (oprócz wymyślenia jak program ma działać ;)) rzecz w całym pisaniu wojownika! Wielkość kodu jest na tyle istotna, że niektórzy rezygnują z jakiejś części programu, aby tylko go maksymalnie zmniejszyć.
Mam nadzieje, ze po przeczytaniu tego tekstu ktoś, kto do tej pory zajmował się jedynie rąbaniem w Q3 czy UT zainteresuje się trochę bardziej kształcącą rozrywką, jaką niewątpliwie są wojny rdzeniowe. Nie ćwiczą one jedynie refleksu i umiejętności szybkiego klikania myszą, a pisanie programów rozwija logiczne myślenie (szczególnie jak coś nie chce działać ;)) i inne przydatne umiejętności. Poza tym satysfakcja z rozłożenia jednego przeciwnika w core wars jest dużo większa niż całego tysiąca w jakiejś tam strzelaninie. Serdecznie zachęcam do głębszego zainteresowania tematem i pisania własnych wojowników. Może wojny rdzeniowe, które swą świetność przeżywały na początku lat 90. znowu powrócą do łask?
Golish
e-mail: golish@inetia.pl

Copyright (c) 1999 - 2000 NoName |
|