Archiwum dla tagu architektura

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…

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…

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…

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…

Koniec teorii, czas na praktykę. Postaram się opisać teraz jak to wszystko zorganizowałem, czego użyłem i co przemawiało za tym, a nie innym sposobem.

Na wstępie chciałbym również uprzedzić, że pisanie w najbliższym czasie zwolni. Postaram się sukcesywnie pisać o projekcie i pisać go samego, lecz nowa szkoła robi swoje

Starałem się zaprojektować silnik tak, by był dość elastyczny i bardzo mały – zawierał tylko to, czego potrzeba i nic więcej. Wydaje mi się, że osiągnąłem to, co chciałem. Silnik, na dzień dzisiejszy, nie udostępnia wiele, lecz jest to na tyle solidna podstawa, by móc już pisać na tym grę(co mam zamiar w najbliższych dniach zacząć). Chciałem sprawdzić czy jest zdatny do użytku i napisałem na szybko bardzo prostą minigierkę(dostępną w repozytorium w gałęzi simple-game). Wynik jest zadowalający – działa tak jak powinno(po kilku poprawkach) i pisanie nie męczy Co prawda brakuje mu jeszcze wielu rzeczy, ale będę je dopisywał w miarę potrzeb. Czytaj dalej…

W każdej grze spotykamy się z menu, HUD-em, samym ekranem gry, menu in-game i innymi tego typu rzeczami. Sensowne zorganizowanie tego nie jest zbyt proste(a może jest, tylko trzeba to dobrze przemyśleć?) a jest to bardzo ważne. Jak to rozwiązać? Czytaj dalej…

Zarządzanie zasobami często jest ignorowane, co, przynajmniej dla mnie, jest błędem. Napisanie w pełni funkcjonalnego managera zasobów nie jest trudne, a przynosi wiele korzyści i ułatwia późniejszą pracę. Oczywiście pisanie go dla tylko kilku zasobów mija się z celem, ale gdy zasobów będzie więcej niż „trochę” ułatwi to nam ich ładowaniem/zwalnianiem. Czytaj dalej…

Decydując się na wydzielenie silnika poza grę(i stworzenie go quasi uniwersalnym) musiałem zdecydować jak on będzie wyglądać i co będzie oferował. Nauczony poprzednimi próbami pisania silnika w C++, które nie przetrwały nawet jednej mojej gry, postanowiłem, że będzie oferował on minimum możliwości, jakie powinien oferować silnik i będzie w maksymalnym stopniu korzystał z tego, co oferują mi zewnętrzne biblioteki. Postawiłem sobie też za cel, by wszystkie podsystemy mojego endżajnu były stosunkowo niezależne od pozostałych.

Jak na razie jestem zadowolony z tego, co napisałem – projekty(wszystkie 4) na dzień dzisiejszy mają 3940 linii, z czego tylko 2354 to kod a poszczególne podsystemy są niezależne od siebie w stu procentach(przynajmniej w interfejsach, w implementacji, dla ułatwienia dalszego pisania, musiałem je „połączyć”).

Stanąłem też przed ważnymi wyborami – jak rozwiązać rendering, jak zorganizować „ekrany” i przechodzenie pomiędzy nimi, zasoby, „obiekty gry”. To nie był mój „pierwszy raz”, więc miałem, marne, bo marne, pojęcie jak to może wyglądać i jak sprawuje się w działaniu. Przedstawię teraz te sposoby, na które wpadłem w czeluściach Internetu lub to, co sam wymyśliłem i tym samym rozpoczynam „cykl” o architekturze

Czytaj dalej…