Ostatnimi dniami bardzo dużo siedziałem nad GUI. Postanowiłem, że i jego serializację napiszę(niech żyje data driven development!). Nie zaszkodzi mi. Tak więc usiadłem do pisania. Na pierwszy ogień poszła serializacja tylko kilku kontrolek, coby się nie przemęczać. Szybko skleciłem jakiś prototyp. Działa. Tylko… Jak to wszystko połączyć w jedną, spójną całość, by np. nie trzeba było dodatkowej obsługi „zdarzeń”? Miałem wielki problem, co z tym fantem zrobić. Całe szczęście kiedyś, dawno temu, bawiłem się chwilę WPF i Silverlight, które to do budowania UI używa XAML-a. A on przecież to wszystko(a nawet więcej) ma! Czytaj dalej…

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.

Od moich pierwszych bojów z OpenTK minęło już trochę czasu. Mogę powiedzieć, że wiem, jak się nim posługiwać. Na początku biblioteka ta wydawała mi się idealna, niestety, wraz z nabywaniem doświadczenia odkrywałem coraz to różniejsze niedoróbki. Jedną z najbardziej denerwujących i najbardziej zignorowanych przeze mnie była obsługa wejścia. OpenTK udostępnia nam szereg klas, by, z założenia, móc wygodnie pobierać informacje od użytkownika. Niestety, tylko z założenia.

Czytaj dalej…

Patrząc z perspektywy (krótkiego) czasu, najwięcej go spędziłem nad dopracowaniem obsługi kolizji. Jak nie trudno się domyśleć, są one oparte na zdarzeniach, tzn., gdy jakaś kolizja zajdzie(np. jednostka <-> teren, jednostka <-> jednostka) wysyłane jest przez bibliotekę zdarzenie. Rozwiązanie nie jest może idealne, ale nie widzę za bardzo innego rozwiązania. I nie bardzo mam wyjście stosować inne Czytaj dalej…

Minęło 10 tygodni, odkąd zacząłem pisać Kingdoms Clash.NET(krótki opis). Czy były to tygodnie owocne? Na pewno. Na początku zastanawiałem się, czy uda mi się ukończyć przez ten czas grywalną wersję. Teraz mogę z czystym sumieniem powiedzieć, że mi się udało. Przedstawiam wam wersję 0.1 Kingdoms Clash.NET! Czytaj dalej…

W poprzednim odcinku skupiłem się raczej na grze(i jak ją można ulepszyć) niż na, jak tytuł wskazywał, serializacji. Tak szczerze powiedziawszy to o grze samej w sobie jest bardzo mało wpisów, więcej jest o tym, czego użyłem, początkach z bibliotekami czy bojami z silnikiem. Przyznam, że nie wiem, czym to jest do końca spowodowane, możliwe, że gra jest od strony technicznej mało ciekawa

Na początku miałem zamiar opisać wszystkie znane mi sposoby na to, lecz po przemyśleniach stwierdziłem, że jest to bez sensu. W Internecie jest już tyle tekstów na ten temat(np. MSDN), że nie ma potrzeby, bym powielał to, co już jest. Opiszę natomiast to, czego ja użyłem i dlaczego akurat tego. Czytaj dalej…

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.