Wpisy dotyczące mojego projektu – Kingdoms Clash.NET

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).

Czytaj dalej…

Nie mam w zwyczaju opisywać dokładniej co się dzieje z projektem – jeśli ktoś jest bardziej zainteresowany to wystarczy przeglądać od czasu do czasu projekt na GitHubie. Lecz dziś postanowiłem zrobić wyjątek z okazji dojścia do „przełomowego” momentu. Mam zaszczyt pokazać światu wersje pre-pre-alpha 0.1 gry Kingdom’s Clash.NET! Proszę się nie spodziewać jakichś rewelacji, to tylko swego rodzaju tech-demo, którym się po prostu musiałem pochwalić.

Gra nie jest wymagająca – obsługuje się ją dwoma(+2 – strzałki) klawiszami:

• A – tworzenie jednostki pierwszego gracza
• L – tworzenie jednostki drugiego gracza
• Strzałki lewo/prawo – poruszanie kamerą

Aby bardziej zrozumieć jak to działa zachęcam do pobrania kodu źródłowego.

Kingdom’s Clash pre-pre-alpha 0.1

Gra do poprawnego działania wymaga .NET Framework w wersji 4.0, dostępnego do pobrania TUTAJ.

Wczoraj wieczorem przysiadłem chwilę i poszperałem w sieci co trzeba zrobić, by debugger Visuala ładnie „wyświetlał” obiekty naszych klas(np. po najechaniu na niego myszką, w okienku Watch). Gdy jeszcze moim głównym językiem był C++ też zapragnąłem mieć coś takiego. Niestety, w przypadku programowania natywnego nie jest to takie łatwe(trzeba pisać wtyczki lub zmieniać plik autoexp.dat, o tym może kiedyś napiszę) lecz tutaj sprowadza się to do dodania atrybutów(lub przeładowania pewnej metody) do klas/pól/właściwości, czyli jest bajecznie proste Czytaj dalej…

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…

Ostatnie kilka dni przesiedziałem nad samą fizyką. Nie implementowałem jej(w sposób nie-testowy) w grze, gdyż najpierw musiałem poznać tą bibliotekę i opracować „jak to zrobić”. Całe szczęście Box2D jak i Farseer Physics używa się przyjemnie i nie miałem większych problemów z ogarnięciem ich.

Przy pierwszym starciu z silnikiem przejrzałem jego „Hello World”(albo raczej „Hello World” Box2D) i napisałem „coś na wzór”(czyt. przepisałem to jeszcze raz ) swojego – oczywiście wszystko w konsoli. Potem zabrałem się u przepisałem to, co napisałem wcześniej, pod mój „silnik”. Hurra! Działa. Co prawda były błędy, ale tylko w wyświetlaniu(nie wiedziałem do końca wtedy „jak to działa”, teraz już wiem ciut więcej). Niestety, był to błąd. Zacząłem implementować poruszanie się jednostek. I, ogólnie rzecz biorąc, nie działało to tak jak chciałem. Niby się wszystko ruszało, kolizje były, ale a to tu coś się przesmykało, to tu „skakało”(choć to „wyłączyłem”), to się ruszać nie chciało. Nie wiedziałem, o co chodzi. Czytaj dalej…

Silników fizycznych mamy całą masę: Box2D, Bullet, Havok, PhysX, Newton Game Dynamics. Część jest OpenSource, część darmowa tylko do zastosowań niekomercyjnych, niektóre tylko komercyjne. Część 2D, cześć 3D. Część stosunkowo mało rozbudowana(np. pierwsze dwa z mojej listy), część to ogromne biblioteki(te komercyjne). Niestety, większość nie posiada rozwijanych wrapperów lub portów dla .NET, które by nie wymagały XNA.

Przeszukując czeluści Internetu natrafiłem na kilka wartych uwagi projektów. Większość bazowała na już istniejących rozwiązaniach(głównie Box2D, ale znalazł się też porty Bullet), lecz również na XNA, co przekreślało ją w moich zastosowaniach(a nie mam ochoty portować biblioteki na nie-XNA). Oto ich lista:

• Box2D.XNA – próbowałem stworzyć jej port pod bibliotekę matematyczną OpenTK, lecz nie potrafiłem doprowadzić tego do prawidłowego działania(nie liczyło kolizji)
• BulletX – port Bullet pod XNA, nawet nie sprawdzałem

Na moje szczęście znalazło się też kilka, które nie wymagają XNA(lub mają porty i pod niego). A były to:

• Box2DX – na początku wydawała mi się najlepszym wyborem, lecz niestety używa niebezpiecznego kodu, co również ją skreśliło
• Farseer Physics – zbudowany na podstawie Box2D.XNA, lecz biblioteka sama w sobie nie wymaga XNA(!)
• Physics2D.Net – biblioteka ta nie bazuje na żadnej, jest napisana od podstaw w C#

Mam dylemat, co do wyboru pomiędzy Farseer Physics i Physics2D.Net. Ta pierwsza bazuje na sprawdzonym rozwiązaniu(może nie przeze mnie, ale jednak) i ma dość pokaźną dokumentacje(włączając w to oryginalną dokumentacje Box2D) w porównaniu do Physics2D. Nie skreślam tej drugiej, lecz po pobieżnym przejrzeniu kodu nie przypadła mi do gustu i zostaję przy Farseer Physics.

Od kilku dni myślałem jak zorganizować fizykę. Dziś zabrałem się za implementacje. Cofam to, co powiedziałem kiedyś o MainThreadCallbacksManager, od dziś ta część silnika jest najbrzydsza(do tego nie działa w stu procentach poprawnie)

Rozwiązanie, które zastosowałem, nie jest ani ładne, ani wydajne, ani idealne. Lecz działa. Niestety, nie jest to moim priorytetem i wolę posiedzieć przy tym dłużej i zrobić to tak by miało ręce i nogi. Po przemyśleniach nad sensem własnej implementacji i krótkiej przygodzie z takową, stwierdzam, że nie mam na to ochoty Wykorzystam do tego jakiś gotowy silnik fizyczny oszczędzając sobie dzięki temu wielu problemów. Problem jest jeden: nie znam żadnego silnika fizycznego dla .NET, który nie wymaga XNA. Muszę przeszukać czeluści Internetu… A może Wy mi coś polecicie?

Zacząłem pisać grę. I to nie „na żarty”. Ku mojemu zaskoczeniu i początkowym problemom(nie wiedziałem, za co się zabrać) idzie całkiem sprawnie. Po kilku godzinach przemyśleń „od czego zacząć” zacząłem pisać… Na początku przygotowałem sobie przykładową klasę nacji i jednostki, co od razu pozwoliło mi poprawić interfejsy, które wykorzystywały. Zaraz po zaimplementowaniu nie użyłem ich, bo… nie widziałem jak Od razu wyświetlić? Nie mam jak, a zresztą, po co? Postanowiłem przerzucić się na chwilę na coś innego – mapy. Czytaj dalej…