Nowy Hawski

• Pracuję od kwietnia 2010 w Gamelion Studios w Szczecinie.
• Dlatego teraz mieszkam w Szczecinie.
• Moja nowa strona domowa: Creative Works of Hadrian Węgrzynowski
• Bloga jako takiego nie będzie

Webdev, świnie i roboty

Witam po kolejnej, najdłuższej jak dotąd w historii tego devbloga przerwie. Nie pisywałem, bo przede wszystkim nie miałem czasu ze względu na kampanię wrześniową. Jednakże przez pewien czas zajmowałem się webdevem i tak oto zrobiłem stronę firmy Biuro Polska.

Wracając do głównego tematu. Zaprzestałem na jakiś czas prac nad podczepianiem Pythona do silniczka, na rzecz stworzenia konkretnej gry. Kolejny raz zaczynam kolejny projekt, nie kończąc poprzedniego. Jednakże, wcześniej kodziłem, praktycznie rzecz biorąc, bez jasno wytyczonego celu. Gra ma roboczy tytuł "Świnie i roboty" ("Pigs & Robots") i będzie dość prostą grą 2d z oryginalnym gameplay'em. Nie będzie należeć do gatunku gier ze wszystkim oprócz zlewu kuchennego.

Tak z grubsza. Gracz wcielając się w rolę ordynarnej świni będzie poszukiwał trufli z pomocą wirtualnego nosa wirtualnej świni. Lecz na drodze ku zwycięstwu stawać mu będą złe roboty z kosmosu. Brzmi dziwnie? O to chodzi ;)

Czy to oznacza, że zaczynam od początku? Nie. Bazując na kodzie i doświadczeniach nabytych przez ostatnie "projekty" framework jest już gotowy. Zostało kilka błędów do poprawienia, ale praktycznie to co jest wystarcza mi już do rozpoczęcia prawdziwej pracy.

A gra jest tworzona z myślą o jej wydaniu. Zobaczymy co z tego wyjdzie ;]

Python i małe sprostowanie

Zamierzałem napisać komentarz w poprzednim poście, ale sporo informacji bardziej na posta się nadaje.

Stara opinia o Pythonie jak słusznie zauważył SirMike w komentarzu jest bardzo stara :) Prawdę mówiąc patrząc na datę - rok 2000 w moim umyśle wydał się odległy o jakieś 2-4 lat ;) Taka mini blokada umysłowa, potem ten komentarz uzmysłowił mi, że przecież faktycznie to aż 8 lat :)

Własnego języka skryptowego nie zamierzam robić. Choć nie wytłumaczyłem do czego mi ten parser ;) Parsuje po prostu własny format plików opisu, bo np. XML jak dla mnie jest nadmiarowy. Inspiracją był po trosze Python, oczywiście nie jest to ostateczny kształt:

class brzydal(Movable):
  float stopien_brzydactwa = 0.5
  str dialog = "nie lubi!"
  int wielkosc
  bool spi = false
  script zachowanie = "brzydal.py"
variant duzy_brzydal:
  stopien_brzydactwa = 1

Po przejrzeniu co rynek oferuje wśród języków skryptowych wybór padł na to samo o czym myślałem od (prawie) zawsze - na Pythona. A jego użytkownikiem będę ja ;) Muszę przyznać, że mam zakusy na przedwczesną optymalizację i czasem marnuję grube godziny na poszukiwanie idealnego rozwiązania, żeby się okazało, że to co znalazłem na początku jest tym czego szukałem ;)

Parsowanie i skrypty

Implementacja Data-Driven ciąg dalszy ;)

Niezastąpiony framework do robienia parserów: Boost Spirit. Jak wiele innych bibliotek Boosta całość znajduje się w nagłówkach, więc nie ma potrzeby linkowania dodatkowych bibliotek. W skrócie umożliwia on definiowanie gramatyki języka bezpośrednio w kodzie c++. Prosty przykład:

rule<> keywords = str_p("class")
  | "variant"
  | "scene"
  | "bool"
  | "float"
  | "int"
  | "str";
rule<> symbol = lexeme_d
  [
    ((alpha_p | '_')
    >> *(alnum_p | '_'))
      -keywords
  ];

Wzięty z mojego kodu. Ten kawałek kodu to zasada na symbole (czyli wg. mojej skromnej wiedzy nazwy deklarowane przez nas). Dopuszczamy takie symbole jak w c++. Pierwszy znak to litera (alpha_p) lub (|) dolny myślnik. Kolejnych (>>) znaków może być 0 albo więcej (*) i mogą one być literą lub cyfrą (alnum_p) lub dolnym myślnikiem. Nie może również konfliktować z słowami kluczowymi, więc na końcu od możliwego wyniku odejmujemy keywords.

Kolejną biblioteką Boosta jaką wykorzystałem jest Boost Iostreams, również w nagłówku. Umożliwia ona proste tworzenie własnych strumieni. Ja wykorzystałem ją do zrobienia strumienia czerpiącego z PhysicsFS. Przykładowy kod, który znalazłem.

Generalnie przekonałem się również (wreszcie?) do używania std::stringa, zamiast standardowego const char*, m.in. ze względu na jego automatyczne współdzielenie referencji, prostotę i co było dla mnie najważniejsze - unordered_map tworzy hashe z niego automatycznie.

Aktualnie zastanawiam się nad wyborem języka skryptowego. Od początku myślałem o Pythonie, ale po przeczytaniu tej, choć już starej, opinii zacząłem się zastanawiać, czy ten wybór będzie dobry. Poszukam jeszcze wbudowanych szybkich kompilatorów C (jak polecono w przytoczonym linku) i podejmę decyzję. Tworzenie własnego języka skryptowego nie wchodzi w grę :P

Dodatkowe linki na ten temat

• GDC 2002: Game Scripting in Python
• Multithreaded Game Scripting with Stackless Python
• Gecko! Embedded C++ scripting for your applications

Data-driven

No nic 2 m-ce minęły ;) W czerwcu nie pisałem, bo miałem sporo nauki

Jestem w trakcie solidnej restrukturyzacji kodu. Implementuje po troszę model data-driven. Nie ma co się za dużo rozwodzić, ale chciałbym podać kilka linków:

• A Generic Function Binding Interface
• A Data-Driven Game Object System
• "Building Object Systems" by Alex Duran (GDC 2003)
• "Object Systems" by Doug Church
• "Data-Driven Programming Made Easy" by Eric Malafeew (GDC 2005)

Od siebie może tylko dodam, że postanowiłem oprzeć się jednak na podejściu Object-based, ale z pewnymi naleciałościami Component-Based.

Pakowanie tekstur, geometrii, fonty i zarządzanie sceną - z grubsza zrobione.

Na wstępie wyjaśnię, że pod pojęciem pakowanie mam na myśli batching (chyba, w razie czego na końcu czeka refactoring ;)). Tak oto doprowadziłem do sensownego stanu te cztery wymienione w tytule rzeczy.

Od ostatniego postu przechodziłem też pewne problemy z NetBeansem, ale teraz wszystko jest już super (użytkownikom wcześniejszych wersji NB polecam upgrade do 6.1). Na dobrą sprawę poświęciłem jakieś 3-4 dni na kodowanie.

Pakowanie tekstur zrobiłem na podstawie artykułu o pakowaniu lightmap a po prawej widać moje wyniki. W lewym górnym rogu na ciemnoniebieskim tle widać teksturę czcionki tahoma o wielkości 18 pikseli zapakowaną na teksturze 256x128. Rendering czcionki sponsorowany jest przez bibliotekę FreeType ;). Na środku wypisany jest tekst. W lewym dolnym rogu można zaobserwować działanie zarządzania sceną - do litery 'F' doczepiony został znak '@'. Zobrazować może to też testowy kod wewnątrz menadżera sceny

// Litera 'F'
Entity *ent = createEntity();
ent->setMaterial(
    &Core::device()->font->Glyphs[70-Font::FIRST_CHAR]->mImage);
SceneNode *node1 = rootSceneNode()->createChild();
node1->setPosition(-320, -256);
node1->setRotation(1);
node1->attachObject(ent);

// Znak '@'
Entity *ent2 = createEntity();
ent2->setMaterial(
    &Core::device()->font->Glyphs[64-Font::FIRST_CHAR]->mImage);
SceneNode *node2 = node1->createChild();
node2->setPosition(100, 0);
node2->attachObject(ent2);

Oczywiście dostęp do znaków czcionki zostanie ograniczony. Testowo zrobiłem tak, ponieważ jeszcze nie mam zarządzania zasobami, ani nawet wczytywania grafiki.

Aktualnie będę pracował nad zarządzaniem zasobami i dopracuję interface pakowania tekstur, no i standardowo szlifowanie całości i dopieszczanie. Niestety zbliża mi się sesja, więc zmniejsza się ilość czasu jaką mogę poświęcić na kodowanie.

Jeśli ktoś chce zobaczyć bardziej jak to wygląda od strony kodu to może zajrzeć na SVN-a na sf.net. Jestem świadom średniej jakości mojego kodu, ale jest to po prostu bardzo wczesna wersja.

Publish-it-compo?

Wpadłem na pomysł na specjalną edycję compo (takiego chociaż jednoosobowego ;) ). Zasada jest prosta. Mamy zadany czas, np. 1 miesiąc. W ciągu tego miesiąca mamy zrobić grę, absolutnie dowolną, ale po tym miesiącu mamy zgłosić się do dowolnego wydawcy i gra ma zostać wydana (tu też można by limitować czas na wydanie). Gra może być totalnie mierna, ale musi dostać się na rynek. W takim compo każdy uczestnik, któremu udałoby się wydać grę w sumie by wygrywał. Można dodać jeszcze takie małe bonusy typu: wygrywa ten kto wcześniej wyda swoją grę, albo nawet głosowanie na najlepszą z wydanych gier. Możliwości jest sporo, ale idea przewodnia jest jedna - zrób i wydaj.

Byłaby to bardzo ciekawa edycja. Pomyślałem sobie, żeby może niedługo samemu w takiej brać udział, ale jako jedyna osoba ;) Bez skupiania się na ponownym wykorzystaniu kodu, albo toporności kodu. Miesiąc i gra z głowy, a nagroda całkiem namacalna :]

IGK'5 i 3 raz podium :P

Tak oto jestem po powrocie z IGK (wróciłem w poniedziałek :P). Znowu drużną zdobyliśmy podium, ale znowu nie na 1 miejscu. W sumie nie jest źle, bo pendrive mi się przyda ;) Nasza "gra" zajęła 3 miejsce i na razie nie podam do niej linka ani nie zaprezentuję screena. Za rok jedziemy po złoto! ;) A tak na marginesie to podium podobne do tego sprzed roku :]

Na forum jest dyskusja na ten temat.