< Poprzedni rozdział | Następny rozdział >
Praca nad kodem gry sprowadza się do napisania silnika gry, po którym dodam obsługę kampanii i potyczek. Silnik gry od razu będzie pisany pod architekturę Amigi, celem zachowania dużej szybkości działania, a zarazem uproszczenia sobie pracy.
Rysowanie będzie odbywać się za pomocą Blittera oraz procesora. Procesor będzie przygotowywać dane planarne na podstawie danych chunky, zaś zadaniem Blittera będzie kopiowanie tych danych w obrębie pamięci graficznej (czyli będzie kopiować obiekty Blittera). Celem jest działanie z pełną prędkością 50 klatek na sekundę na komputerze Amiga z procesorem M68020 oraz kośćmi AA i 2MB CHIP RAM nawet przy natłoku elementów dynamicznych na planszy. Zostanie to uzyskane dzięki współpracy trzech procesorów Amigi i rysowaniu zsynchronizowanym z promieniem wizji.
Ekran będzie utworzony za pomocą mechanizmu własnych View, celem niskopoziomowego dostępu do pamięci graficznej i Copperlisty. W celu zsynchronizowania silnika wykorzystane zostanie przerwanie Coppera, które będzie sygnalizować Task główny kiedy promień osiągnie odpowiednią pozycję. Task główny będzie czekać na różnorakie inne wydarzenia, np. o zmianie statusu klawiatury, bądź myszy, ale będzie robić to w odpowiedniej kolejności według pilności wydarzeń czekających na obsługę.
Dla przykładu handler input.device będzie wysyłał komunikaty do Tasku głównego zawierające informacje o naciśniętych klawiszach, bądź ruchu myszy. Zmiana położenia myszy będzie dokonywana jeszcze w przerwaniu, zaś Task główny dostanie w większych odstępach informację o zmianie położenia myszy. Ma to na celu zwolnienie Tasku głównego z obowiązku obsługi myszy.
Zarezerwowane będą trzy bufory ekranu zajmujące po jednym ekranie. Bufory będą przełączane naprzemiennie (w trzecim buforze będzie renderowana następna pozycja poprzez przesunięcie obecnej pozycji i dorysowanie nowego wiersza/kolumny).
Przesuwanie będzie odbywać się w tle za pomocą funkcji QBlit(), która rysuje asynchronicznie. Z kolei rysowanie Bobów będzie odbywać się na bieżąco za pomocą zsynchronizowanych operacji Blittera.
Mapa będzie zapisana w formie macierzy kafli, które będą buforowane w pamięci graficznej Amigi.
Gra będzie pisana w całości w asemblerze, ale będzie udostępniać pomocniczy język skryptowy, mający na celu realizację pewnych zagadnień wysokopoziomowych, które chce się łatwo podmieniać z poziomu gry, a nie kodu. Szczegóły jeszcze do ustalenia.
Projekt jest obszerny. Naturalnym podziałem są kwestie techniczne oraz zagadnienia silnika gry strategicznej. Gra będzie uzależniona od architektury Amigi, czyli procesor M680x0 oraz kości AA będą wymagane, a zarazem będzie korzystać z tych rozwiązań systemu, które zapewnią kompatybilność pomiędzy różnymi modelami Amig (graphics.library). Gra wykorzysta możliwości koprocesorów Amigi (Copper, Blitter) i nie będzie wymagała zbyt dużo czasu procesora do obsługi grafiki.
Gra nie będzie celowała zatem w architekturę RTG, jako że celem jest działanie na Amidze 1200 wyposażonej w oryginalne układy graficzne. Spoiwem silnika i kwestii technicznych jest rysowanie elementów mapy. Powstaną odpowiednie funkcje, które będą animowały ekran i przekształcały stan gry w obraz na monitorze. Będą to procedury zoptymalizowane pod kątem jak największej oszczędności czasu procesora głównego i koprocosorów odpowiedzialnych za grafikę.
Sporządźmy zatem pierwszy, ramowy plan obrazujący skalę projektu. O ile grafika będzie importowana z plików zewnętrznych o tyle pewne zagadnienia techniczne będą zrealizowane od razu, jak np. konsola poleceń, dzieki której będzie można wpływać na stan gry, odczytywać parametry, przetestować silnik itp. Wykorzystam console.device, jako że udostępnia gotowe funkcje obsługi konsoli.
Własny obraz będzie ładowany później, kiedy trzeba będzie przejść do testów graficznych typu sprawdzenie poprawności wyświetlania. W każdym razie będzie to nieco później.
Jako pierwszy duży punkt obierzmy utworzenie silnika mapy z obsługą w konsoli. Podpunktami będzie realizacja poszczególnych składników silnika, jak: plansza, na której toczy się bitwa wraz z elementami na tej planszy, drzewko technologiczne oraz statystyki obiektów, później mechanizmy obsługi obiektów, jak ruch jednostek, animacja wybuchów, obsługa budynków i na koniec system dowodzenia obiektami na polu bitwy przez gracza - człowieka oraz gracza - komputer.
Jako drugi punkt warto zrobić całą otoczkę wokół silnika mapy, czyli "opakowanie silnika". Dotyczy to wyświetlenia mapy, panelu dowodzenia, wydarzeń i akcji mających na celu wprowadzenie dynamiki do rozgrywki itp.
Trzecim punktem będzie realizacja aspektu graficznego. Zaś czwartym punktem będzie opakowanie tego wszystkiego w kampanię i potyczki, czyli różne sposoby na rozgrywkę. W tym miejscu warto wprowadzić również wspomniany na początku język skryptowy, np. w celu układania kampanii.
Na deser zostawię sobie resztę rzeczy, czyli dźwięki i muzykę.
Plan ramowy pracy
Autor strony: Robert Szacki, Ostatnia modyfikacja artykułu: 04.04.2017