15 maja 2011 roku ruszyły prace nad wersją 0.70. Dokładny opis funkcjonalności tej wersji znajduje się tutaj. Przybliżona data ukończenia: Jesień 2011
Na pierwszy ogień idą poprawienie generatora map i zmiana formatu zapisu plansz. Przy obecnej strukturze modyfikacja mapy przez gracza (np. wycinanie drzew, budowa osad i miast) jest niemożliwa, poza tym stara wersja tego narzędzia działa bardzo wolno, co również ulegnie poprawie.
Przy okazji prac nad programami narzędziowymi opublikowałem opis metody której używam do podziału mapy na regiony. Napisałem również o kompresji grafiki.
W tym artykule chciałem opisać sposób w jaki kompresuje grafikę (czyli głównie bitmapy) w moim projekcie. Pomysł polega na odpowiednim wykorzystaniu formatów png i jpg.
1. Stosowane Formaty:
JPG – stratna kompresja bez przeźroczystości.
PNG (RGBA) – format z kompresją bezstratną i kanałem alfa
PNG (z paletą kolorów) – format z tablicą kolorów (do 256 kolorów w tym kolor przeźroczysty)
2. poprawa kompresji dla PNG (RGBA)
Najprostszym sposobem na poprawienie kompresji np. serii ikon jest wrzucenie ich do jednego obrazka w formacie PNG i zapamiętanie pozycji zajmowanych przez ikony. Ponieważ format PNG stosuje kompresje wierszową najlepiej rozkładać je horyzontalnie.
Przykładowo w Gizarmie są 22 ikonki zasobów. Każda ikona zapisana jest w PNG-24, posiada przezroczystość.
Ikonki bez kompresji zajmują 34 556 bajtów, po zastosowaniu metody plik obrazu i plik z koordynatami zajmują 25 987 bajtów. Kompresja poprawiła się o około 25%.
3. Kompresja stratna z kanałem alfa
Czasami może się zdarzyć, że nie zależy nam na bezstratności kompresji obrazu, ale z drugiej strony potrzeba obsługi przeźroczystości. W tym wypadku dobrze sprawdza się zapisanie obrazu w JPG i dodatkowo maski przeźroczystości w oddzielnym obrazie PNG z paletą barw (zazwyczaj nie trzeba pamiętać 256 poziomów przeźroczystości, z moich doświadczeń wynika, że już 32 poziomy dają dobre rezultaty). Maskę zapisujemy w PNG ponieważ często ma ona gwałtowne przejścia od pełnej przeźroczystości do jej braku. Format JPG mógłby sprawić, że na takich ostrych granicach pojawiły by się artefakty.
przykład artefaktów na krawędzi maski przy zastosowaniu formatu JPG
Ponieważ obraz początkowo z kanałem alfa jest zapisywany do JPG, trzeba pozbyć się przeźroczystości.
Dla każdego punktu gdzie alfa!=1 alfa=0, żeby nie mieszać koloru tła z naszym obrazem.
Po drugie dobrze jest rozmyć nasz obraz na jego zewnętrznych krawędziach. Należy to zrobić ponieważ JPG miesza kolory jeżeli zmieniają się one gwałtownie, nasz obraz mógłby być zanieczyszczony tłem na krawędziach.
Przykład na podstawie obrazu domku
Na przykładzie 34 grafik domków wstępnie skompresowanych metodą z punktu 2. pokaże efektywność metody. Obraz w PNG zajmuje 328 887 bajtów, po kompresji obraz i maska zajmują 101 258 bajtów. Poziom kompresji obrazu jpg wynosi 0.5, maska posiada 32 kolory. Objętość grafiki zmniejszyła się ponad 3 krotnie przy niewielkiej stracie jakości.
Podczas tworzenia Gizarmy musiałem wymyślić metodę na znalezienie podziału mapy na regiony. Nie mogła to być regularna siatka, więc zadanie nie było trywialne. Udało mi się wymyślić algorytm który taki podział wyznacza i chciałem go tutaj opisać
Założenia:
Regiony powinny mieć nieregularny kształt.
Regiony powinny być podobnej wielkości
Rozkład regionów powinien uwzględniać lądy i morza, to znaczy nie może istnieć region wodno-lądowy.
Regiony nie mogą znajdować się poza dopuszczonym obszarem
Poniżej mapa określająca warunki dla regionów oraz efekt działania algorytmu
Opis obszaru dla regionów
Znalezione regiony
Moja metoda jest inspirowana bakteriami (jakimiś amebami). Ameby żyją na planszy i żywią się cukrem. Cukier ma pewien losowy rozkład na całej planszy. Ameby mogą zajmować nowe terytoria (rozrastać się) i zżerać się nawzajem.
Plansza symbolizuje ląd który dzielimy na obszary, a kiedy ameby zajmą cały obszar planszy, kształt ich ciał utożsamiamy z obszarami których szukamy.
Koniec bajeczki, algorytm:
Na początku zdefiniuje funkcje oceny opłacalności rozrostu ameby N na jakiś punkt k. Punkt k nie należy do N, ale sąsiaduje z N
ocena = wsp1*[liczba punktów zajmowanych przez amebę N w okolicy punktu k] + wsp2*[liczba punktów zajmowanych przez inne ameby w okolicy punktu k] + wsp3*[odległość k od punktu początkowego ameby N] + wsp4*[natężenie cukru w punkcie k] +
(jeżeli punk k jest pusty + BONUS_PUSTOSCI)
Rozrzucam punkty początkowe ameb na całej planszy w sposób losowy, ale tak aby odległość dwóch dowolnych punktów <Rmin
Wstawiam ameby które początkowo mają kształt okręgów o r<Rmin
Znajduje i zapamiętuje wszystkie punkty sąsiadujące z amebą
while (true) { Dla wszystkich ameb {
Spośród wszystkich punktów brzegowych ameby N znajduje ten o najwyższej ocenie (nazywam go k)
Jeżeli k jest pusty zajmij, continue
Jeżeli k zajęty przez amebe N\’ oblicz ocena(N\’,k)
Jeżeli ocena(N\’,k)<ocena(N,k) * wsp_drapieżności odgryź amebie N\’ punkt k
}
co n kroków sprawdź czy ameby mają spójny kształt, jeżeli jakaś nie ma usuń części nie mające połączenia ze swoimi punktami początkowymi
}
W mojej symulacji do osiągnięcia zadowalającego efektu wystarczało 5000 – 10000 iteracji tego algorytmu.
Na złomowisku znaleźć można grafiki, które zrobiłem w przeszłości na potrzeby tego lub innego projektu, ale z różnych powodów ich nie użyję. Grafiki można pobrać i wykorzystać wedle uznania :).
W tym dziale będę zamieszczał grafikę (ikony, sprajty, …), które miały być użyte w Gizarmie, ale z różnych powodów nie zostaną. Może komuś się przydadzą.
Grafiki które wykorzystałem przy pisaniu pewnej gry. Są to głównie sprajty drzew i krzewów w 4 odmianach (po jednej na pore roku). Część jest wyciągnięta z Heroes II.
W dniu 30 marca 2011 ukończona została wersja 0.64. Była to pierwsza wersja gry która poddana została testom z udziałem większej ilości użytkowników.
Testy prowadzone były w kwietniu i maju 2011 przez ponad 10 graczy. W tym czasie do gry zalogowali się oni około 750 razy.
Chciałem oficjalnie podziękować wszystkim testerom Gizarmy. Dzięki wam mogłem znaleźć i naprawić wiele błędów w grze oraz zweryfikować użyte rozwiązania. Wasze zainteresowanie dało mi bardzo dużo motywacji do dalszej pracy nad projektem.
Ta strona jest o wiele młodsza niż sam projekt. Zacznę więc od opowiedzenia historii Gizarmy.
Projekt jest prowadzony od jesieni 2007 roku, jednak na wiosnę 2009 roku zmieniłem koncepcje gry, kod został w całości przepisany a grafika prawie w całości podmieniona. To co jest teraz jest kontynuacją pomysłu z 2009 roku.
Poniżej przedstawiam obrazkową historię rozwoju projektu:
Pierwsze przymiarki do mapy głównej
Główny ekran gry
Widok miasta
Wizualizacja budynków w mieście
Poprawiona wersja ekranu głównego gry
Alternatywny widok miasta (kolejna wersja)
Po wielkim refaktoringu z 2009 roku
Poprawiony podział na regiony – od tego się zaczęło
Poprawiony wygląd mapy
widok miasta
widok miasta po retuszu
okienko postępu budowy
Najnowsza wersja 0.65 z 26 kwietnia 2011
ekran główny gry
widok miasta
okienko rozpoczęcia budowy
Informacje na temat projektu można znaleźć również na warsztat.gd