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…

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

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?

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…