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…

Kolejnym pomysłem jaki przyszedł mi do głowy były budynki. Niesie on jednak za sobą pewne niebezpieczeństwo – wprowadzenie budynków, które by „tworzyły” jednostki poza zamkiem, zerwałoby z założeniem, że to zamek jest „wszystkim”. Dlatego mam duże wątpliwości, czy takie rozwiązanie byłoby dobre, lecz pewnie dla testów wprowadzę je.

Nie mam jednak wątpliwości co do budynków bardziej „pasywnych” – wszelkiego rodzaju mury, mosty(do np. przechodzenia przez zbiorniki wodne), wieże obronne – one na pewno nie zmienią diametralnie rozgrywki a wprowadzą nowe możliwości. Wymusi to(albo i nie… ) na graczach stosowanie nie tylko taktyk ofensywnych, ale i defensywnych. Umożliwi granie tylko jednym „rodzajem” jednostek(np. tylko naziemnymi) a wieże będą załatwiać wszystkie inne(jeśli takowe wprowadzę – więcej w następnej notce o pomysłach).

W pewnym sensie wprowadzenie ich umożliwi mi dodanie nowego trybu rozgrywki, który przypominałby(albo nawet był) gry typu tower defense. Gracz nie miałby możliwości konstruowania jednostek(z wyłączeniem „zbieraczy”), jedynie wieżami musiałby zniszczyć zamek przeciwnika. Drugi gracz musiałby zrobić to tak samo. Ewentualnie przeciwnik miałby do dyspozycji tylko jednostki, bez budynków i walczyłby przeciwko samym wieżom. Na ile takie rozwiązanie byłoby grywalne nie wiem, ale na pewno nie zaszkodzi w przyszłości go wypróbować.

Ostatnio miałem małą przerwę w rozwijaniu silnika – z przyczyn nie do końca zależnych ode mnie miałem naprawdę mało czasu, lecz wszystko wróciło już do normy i teraz regularnie będę pisał, wolno bo wolno, grę(a i notek powinno pojawić się więcej).

No dobra, nie pierwsze tylko trzecie w moim wypadku, ale poprzednie się nie liczą, bo skończyło się na utworzeniu najprostszego okna

Czym jest OpenTK? Jest to binding OpenGL, OpenAL i OpenCL pod .NET. Aktualnie jest w wersji 1.0 RC1 i obsługuję Otwarty GL w wersji 3.2, OpenAL
1.1 i OpenCL 1.0. Do tego posiada dość rozbudowaną bibliotekę matematyczną(która mam nadzieję wystarczy mi) obsługującą wektory, macierze, kwaterniony i struktury opisujące krzywe Béziera.

Posiada kilka klas-kontrolek, które ułatwiają integracje z już istniejącymi programami, np. GLControl dla Windows Forms, GLWidget dla GTK# i, podobno, kontrolkę dla WPF(lecz ja jej nie znalazłem).

Dla gier stworzona jest specjalna klasa GameWindow – całe okno jest przeznaczone tylko dla OpenGL, daje to nam najlepszą wydajność i usuwa zbędne rzeczy ze „zwykłych” form. To właśnie jej będę używał i to ją szerzej opiszę w dzisiejszym poście. Czytaj dalej…

Kolejnym pomysłem który przyszedł mi do głowy są mapy. Urozmaiciłoby to rozgrywkę i może nakłoniłoby do opracowywania strategii pod daną mapę.

Składałaby się one z wierzchołków ułożonych „jeden za drugim”. Pozwoliłoby to tworzyć różnego rodzaju wzgórza, doliny itp. Te „urozmaicenia” oddziaływałyby na jednostki – pod górkę miałyby mniejszą prędkość, z – poruszałyby się szybciej.

Każdy wierzchołek miałby też przypisany typ terenu, który dawałby bonusy jednostkom na nim. Dzięki temu mapy przestałyby być też monotonne(w sensie kolorystyki). Zamiast samej zieleni czy brązu pojawiłyby się inne kolory.

Np.

• Pustynia – -5% do szybkości poruszania się każdej jednostki naziemnej.
• Las – -10% do szybkości poruszania się jednostek nie-elfów(np.), one mają bonus +5% do prędkości ruchu w lesie. Dodatkowo każda jednostka znajdująca się w lesie ma +10% szans uniknięcie strzały(czy też innego pocisku).
• Woda – nie da się przejść bez specjalistycznego sprzętu(o tym w następnym poście o pomysłach)
• Bagno – jednostki będą mogły w nim ugrząźć(choć prawdopodobieństwo byłoby małe)

Na mapie mogłyby znajdować się też przeszkody. Np. w połowie stałby wielki mur, który trzeba by było zniszczyć przed inwazją na przeciwnika, przed samym zamkiem stałaby brama przez którą dałoby się przejść tylko w jedną stronę, aby przejść w drugą należałoby ją zrównać z ziemią.

Czy według Was, takie urozmaicenie zdałoby egzamin, czy też lepiej nie zaprzątać sobie nim głowy?

Postanowiłem sobie odpocząć od „projektowania” silnika(jeśli można to nazwać projektowaniem… ) i napisać klasę, która będzie mi udostępniać podstawowe informacje o komputerze i systemie operacyjnym, np.:

• wersję SO
• wersję CLR
• nazwę procesora, jego taktowanie i liczbę rdzeni
• ilość zainstalowanej pamięci RAM
• model karty graficznej, jej pamięć i wersję sterowników

Gdy pisałem coś podobnego w C++ do pobrania informacji o procesorze używałem asemblera i instrukcji cpuid, tutaj „nie ma tak dobrze”. Do pobrania informacji o karcie graficznej używałem OpenGL i glGetString, lecz zdobywałem ich tyle co kot napłakał.

Po krótkim poszukiwaniu dowiedziałem się jak to pobrać – WMI(i System.Environment ). Czytaj dalej…

Zacząłem już tematy typowo techniczne a nie napisałem prawie nic o samej grze(oprócz tego, że będzie wzorowana na Medieval Clash). Pragnę naprawić ten błąd. Czytaj dalej…

Już od dłuższego czasu przymierzałem się do poznania tej techniki tworzenia oprogramowania. Zawsze gdy tworzyłem oprogramowanie pisałem jakąś funkcjonalność i gdy uznałem, że to co napisałem działa przynajmniej w części tak jak powinno zabierałem się do testowania. I testowałem, testowałem, debugowałem, testowałem… Czasami na przetestowanie i poprawę, często głupich, błędów potrzeba było o wiele więcej czasu niż na „pierwszą implementację”(która zawsze wydaje się najtrudniejsza). Postanowiłem w końcu „coś z tym zrobić”. A nuż się uda i testowanie nie będzie takie męczące? Czytaj dalej…

Tak, stało się. Rozpocząłem pracę nad nowym, dużym(przynajmniej dla mnie) projektem.

Będzie to gra strategiczna bazująca na pomyśle Medieval Clash(opis na VG, niestety, strona autora nie działa) o jakże zacnej nazwie Kingdoms Clash.NET(nie wykluczam zmiany w przyszłości). W mojej głowie rodzą się jednak pomysły, które dość znacznie zmodyfikują rozgrywkę, nie będzie tak monotonna i nudna, ale o tym w przyszłych notkach. Mam zamiar napisać ją w całości w .NET, coby udowodnić sobie, że „da się to wykonać”*! Gra ma używać Open Toolkit Library, które jest portem OpenGL, OpenCL i OpenAL dla .NET jak i wiele innych, mniej istotnych, bibliotek(cobym miał o czym pisać ). Pierwszy raz będę używał DVCS jakim jest Git(hosting: GitHub) o którym też pewnie coś skrobnę.

Gra bierze też udział w konkursie „Daj się poznać!” organizowanym przez Macieja Aniserowicza. Do wygrania są naprawdę atrakcyjne nagrody(2x MSDN Ultimate!), tak więc zachęcam wszystkich do udziału.

Repozytorium

* – choć w sumie wiem, że się da. Widziałem już gry napisane w .NET lub Javie które były całkiem przyjemne.