Chyba jednak z planu regularnego pisania nici, ale cóż…
Wydaje mi się, że jednym z ciekawszych miejsc w grze jest obsługa wielu trybów rozgrywki. Miałem niezłą zagwozdkę jak to ładnie i elastycznie zorganizować. Do aktualnego stanu dochodziłem dość długo, lecz pierwszą implementację, bardzo podobną do tej, mam już od dawna. Wydaje mi się, że nie wyszło mi to najgorzej, acz chwilowo nie bardzo mogę powiedzieć, czy tak rzeczywiście jest – na razie zaimplementowany jest tylko „klasyczny” model rozgrywki. Czytaj dalej…
Tak, udało się. Zebrałem się w końcu by napisać co nieco o moich bojach z GUI. Założenia były proste: jak najmniej kodu do napisania, a samo GUI miało być wydajne i proste w użyciu. Przez ponad 2 miesiące zmieniła mi się koncepcja, jak to ma wyglądać. Czy na dobre – nie wiem. Chwilowo wszystko wskazuje na to, że projektowanie poszło w dobrym kierunku(wydajność – niekoniecznie). 
Ale zacznijmy od początku…
Ostatnimi czasy produkcja gry jest jeszcze mniej dynamiczna, niż to było wcześniej. Niestety, to spowolnienie będzie dłuższe niż myślałem, ale w końcu wszystko wróci do normy 
Coraz bardziej doskwierała mi mnogość przestrzeni nazw w silniku. Były one często bardzo małe – jedna, dwie klasy + kilka wyliczeń to maks. Takie rozwiązanie, mimo iż bardzo złe nie jest, dobre też nie. Postanowiłem dziś zabrać się za uporządkowanie i złożenie wszystkiego w logiczną całość.
Na pierwszy ogień poszło oddzielenie modułu głównego od graficznego. Wszystko(z wyłączeniem IRenderableComponent i ich kolekcji), co miało jakikolwiek związek z grafiką przeniosłem do przestrzeni nazw Graphics i tam to sensownie(przynajmniej tak mi się wydaje) porozdzielałem.
Pozbyłem się również bezsensownych jedno- lub dwuklasowych przestrzeni nazw. ResourcesManager, ScreensManager i PhysicsManager poszły w niepamięć. Zostały scalone i dołączone do głównej przestrzeni nazw silnika. Tak samo komponenty, które nie są związane bezpośrednio z grafiką, zostały umieszczone w jednej przestrzeni nazw – Components.
Ostatnio zająłem się GUI(o czym w następnym odcinku) i brak renderera dał o sobie znać. Zostałem prawie, że zmuszony, do tego by go napisać. Po kilku chwilach przeglądania, jak jest zbudowane XNA(kilka pomysłów jest żywcem wziętych od niej) skodziłem prototyp. Jest naprawdę minimalistyczny, ale o to mi chodziło – ma tylko unifikować rendering i umożliwiać ewentualnie w miarę łatwo przejść na inny sposób wyświetlania.
Ostatnimi dniami(ściślej: dniem 
) pisałem serializacje/deserializację danych, do których ma dostęp użytkownik. Już od dłuższego czasu myślałem jak to zrobić, by było dobrze. Było to jednym z głównych czynników zaprojektowania gry tak, a nie inaczej. Na „pierwszy raz” postanowiłem napisać ładowanie nacji z plików. Nad formatem zserializowanych danych nie myślałem długo – do tego świetnie nadaje się XML. Może jest lekko „ociężały”, ale ma świetne wsparcie .NET Frameworka i akurat w tym zastosowaniu ta ociężałość nie będzie jakoś bardzo widoczna. Czytaj dalej…
Po dość krótkiej refaktoryzacji silnika(wrócę do niej później – teraz nie mam pomysłu jak zmienić niektóre rzeczy) wróciłem do pisania gry. Kolejny etap – obsługa zasobów(ale nie tych opisywanych wcześniej przeze mnie, tych bardziej „growych”). Miałem już koncepcje jak je zrobić, lecz po dłuższym zastanowieniu było by ono trudniejsze w implementacji niż mi się na początku wydawało.
Pomysł był taki: każdy zasób posiada oddzielną klasę, która może być stosowana jako kontener na np. zasoby gracza jak i pojedyncze paczki niesione przez robotnika-zbieracza. Sprowadzało się to do wielu małych klas, w których jedyną zmienną była wartość. Nie było to złe rozwiązanie, lecz tylko skomplikowałoby zarządzanie nimi.
Rozwiązanie, w trakcie którego implementacji jestem, nie używa żadnych odrębnych typów do opisu zasobów – wszystkim zarządza kolekcja-słownik zasobów przechowując parę id+wartość. Jest to rozwiązanie o tyle dobre, że wystarczy ta jedna klasa do zrobienia wszystkiego – przechowywania kosztów jednostek i tego, co gracz posiada. Jedynym „problemem” będzie przechowywanie tego, jako „ładunek” przy zbieraczach. Trzeba będzie przechowywać identyfikator zasobu i wielkość ładunku osobno… albo użyć KeyValuePair! I problem rozwiązany.
Zostawiłem jednak interfejs opisujący zasób – przyda się przy przechowywaniu opisów
Aktualnie mam zaimplementowaną samą kolekcję(ale też brakuje jej kilku ułatwień), bez użycia jej, ale wprowadzenie tego do „życia” zbyt trudne nie będzie.
Moja ekscytacja pierwszą „publiczną” wersją gry minęła, mogę chłodno spojrzeć na to, co do tej pory zrobiłem. Ogólnie rzecz biorąc, jest dobrze, nawet bardzo dobrze, bo wszystko działa tak jak miało działać. Niestety, z łatwością wykorzystania i możliwościami poniektórych modułów jest gorzej – trzeba to zmienić. Na pierwszy ogień idą interfejsy, możliwościami zajmę się później(gdyż na razie nie bardzo mam pomysł jak rozwiązać część rzeczy).
Zaczynając pisać grę byłem nastawiony na jej możliwie największą modowalność. Gdy użytkownicy będą mogli ją zmienić istnieje szansa, że „przeżyje” ona więcej niż tydzień(jeśli w ogóle powstanie, ale w to nie wątpię, za bardzo mi teraz na tym zależy) Postanowiłem więc, że wszystko, na co tylko wpadnę będzie można zmienić w stosunkowo łatwy sposób. Nie inaczej stało się z jednostkami. Gracz będzie mógł tworzyć własne jednostki, a nawet całe nacje. Tylko jak to dobrze zrobić? Czytaj dalej…
W tym tygodniu nie napisałem za wiele kodu. Większość czasu spędziłem na przemyśleniach związanych z architekturą gry. I tak oto trzy razy zmieniałem prawie całą architekturę. To, co jest teraz prawie w ogóle nie przypomina tego, co opisałem w mojej poprzedniej notce. Czytaj dalej…
Koniec obijania się – odpocząłem po tym tygodniu, zaklimatyzowałem się w szkole – mogę wrócić do „normalnej pracy”
Na wstępie chciałbym złożyć życzenia wszystkim programistom z okazji Dnia Programisty, który przypada na 256 dzień roku. Niech kod, który wyjdzie spod waszych dłoni nie zawiera błędów, niech bugi nie mnożą się ponad potęgę, niech wydajność nie nastręcza problemów i, co najważniejsze, byście czerpali radość z tego, co robicie
Nadszedł ważny moment w mojej pracy nad grą – trzeba ją zacząć. Do tej pory skupiałem się głównie na silniku(lub tym „czymś”, co próbuje go imitować, bo wiem, że silnikiem to nie jest, ale lubię tą nazwę ) by mieć na czym oprzeć grę. Teraz zaczynam pisać ją. O ile silnika nie projektowałem, gdyż nie byłem przekonany co będzie zawierać(i jak to będzie wyglądać – raz przydało mi się używanie TDD ) o tyle grę, ogólnie, bo ogólnie, mam zaprojektowaną.
Pisząc manager zasobów obsługujący podmianę plików „na gorąco”(w trakcie działania programu) wykorzystałem klasę System.IO.FileSystemWatcher. Kod managera nie jest skomplikowany, ot, gdy coś się zmieni w folderze z zasobami, sprawdzamy czy zostało załadowane i, jeśli tak, zwalniamy i ładujemy ponownie, rozwiązanie może nie najlepsze, ale działa i nie potrzeba ingerencji w kod zasobów. Oczywiście lepiej by było jakby wymieniane były same dane a nie wszystko(włącznie z np. zasobami OpenGL), ale wymagałoby to dość dużej ilości dodatkowego kodu(i ingerencji w interfejs zasobów).
Zaraz po zaimplementowaniu pierwszej jego wersji miałem problem – zasoby się nie zwalniały ani nie ładowały(a przynajmniej nie wyświetlały). Zabrałem się za debugowanie… Okazało się, że problem nie do końca leżał po mojej stronie. Kontekst OpenGL jest thread-specific(przypisany do wątku) i wywołanie jakiejkolwiek funkcji OpenGL bez uczynienia kontekstu aktualnym(wglMakeCurrent, glXMakeCurrent) na wątku skutkowało błędem InvalidOperation. Rozwiązać to mogłem przez tymczasowe przypisywanie kontekstu do wątku i powrót do stanu sprzed zaraz po zakończeniu operacji, lecz takie rozwiązanie nie dość, że wymagałoby dużych nakładów kodu i zmian we wszystkich klasach, które używają OpenGL to zabezpieczyłoby mnie tylko przed tym jedynym błędem.
Postanowiłem napisać coś na wzór main_thread_callback_manager. Zapewnia ona wykonanie się dodanej funkcji w głównym wątku aplikacji(a więc w tym, w którym został utworzony kontekst OpenGL czy w przyszłości inne konteksty, np. OpenAL). I tak oto powstała klasa MainThreadCallbacksManager.
Implementacja jest prosta aż do bólu – obsługuje dodawanie callbacków(wywołuje metodę Add na wewnętrznej liście) i ich wywoływanie(pętla po wszystkich callbackach i ewentualne usunięcie już nieużywanych). Wszystko byłoby okej, gdyby nie to, że wymusza ona wywołanie metody Call gdzieś w głównym wątku. I właśnie to jest najbrzydsze w jej implementacji. Niestety, nie mam pomysłu jak to rozwiązać inaczej(może Wy macie?) i, dopóki nie znajdę innego sposobu, będzie tak jak jest.
- Inne (6)
- Kingdoms Clash.NET (37)
- Implementacja (2)
- Projektowanie (17)
- Programowanie (20)
