Serializacja i właściwości

Przez serializację rozumiem zapis obiektów do postaci strumienia bitów w celu poźniejszego odtworzenia obiektów. Serializacja według mnie jest bardzo przydatna, chociaż na #warsztatcie mało popularna.

Właściwości są tworem pozwalającym operować na składowych obiektów odwołując się do nich np przez nazwę ( łańcuch znaków ).

Jak to działa?
U mnie gdy chcemy aby klasa mogła zostać zserializowana oraz posiadała właściwości należy zaimplementować 2 funkcje oraz użyć 2 makr.

Pseudo kod wygląda mniej więcej tak :
/// h
class CFoo : public CObject { /// CObject jest klasą bazowa silnika
DECLARE_CLASS(CFoo, CObject, Flags)
protected:
int m_SomeVar;
CObject* m_OtherObject;

public:
virtual void Serialize(CStream* Stream);
static void Initialize();
};

/// cpp
IMPLEMENT_CLASS(CFoo);

void CFoo::Serialize(CStream* Stream) { // Wszystkie ważne dane
Stream->Serialize(&m_SomeVar);
Stream->Serialize(m_OtherObject);
};

void CFoo::Initialize() {
ADD_PROPERTY(m_SomeVar, EPT_INT);
};

to by było na tyle jeśli chodzi o implementacje dla danej klasy.
Przykładowe użycie systemu właściwości może wyglądać tak :
CFoo* Instance = new CFoo();
int Value = 666 ;
Instance->GetProperty("m_SomeVar")->SetData(&Value);

Jeśli zaś chodzi o serializację to można to zrobić tak :
CStream FileStream;
FileStream.RegisterObject(Instance);
FileStream.SaveToFile("Objects.BOS");

Do otworzenia obiektów wystarczy:
FileStream.LoadFromFile("Objects.BOS");

więc nie ma dużo pisania a użyteczne jest to bardzo :)
Dodam że oczywiście odtwarza to wszystkie zależności także po odtworzeniu obiektów z pliku czy pamięci m_OtherObject z Foo nadal będzie wskazywał na obiekt który wskazywał przy zapisie ( Obiekt a nie adres pamięci ).

O Wirtualnym systemie plików

VFS bo tak zwiemy Virtual File System jest tworem używanym od bardzo dawna w wielu produkcjach. W grach retailowych bardzo często spotykamy się z tym iż content gry zawiera się zaledwie w kilku dużych plikach, są to właśnie archiwa VFS'u. Co przemawia za używaniem VFS'u ?? Otóż jest kilka plusów :

1. Możliwość łatwego zakodowania contentu gry przed przywłaszczeniem( Która zresztą stosuje wielu programistów amatorów np Ja :P .
2. Możliwość efektywnego spakowania contentu i zaoszczędzenia miejsca.
3. Szybkość dostępu do danych.

Dla mnie najważniejszy jest punkt 1 i 3 , Szybkość pozyskania danych z archiwum VFS jest dużo większa niż posiadanie wielu małych plików i wczytywania każdego z nich.
VFS wcale nie jest trudny, ośmielę się stwierdzić iż wykonanie wygodnego VFS jest proste nawet dla nie zaawansowanych programistów.

Długa przerwa

Przez spory okres czasu nie umieszczałem na blogu nowych wiadomości, było to spowodowane 2 czynnikami:
1. Sporo czasu poświeciłem sprawom nie powiązanym z GameDevem.
2. Uważałem że nie ma sensu pisać tutaj o napisaniu jakiegoś nieznacznego kawałka kodu.

Xion mnie przekonał żebym jednak pisał o takich nawet dla mnie nie bardzo istotnych kawałkach kodu.

2D / 3D a grywalność

Witam!

Wielu programistów ( amatorów) zadaje sobie pytanie „pisać grę 2D czy 3D?”.
Cóż odpowiedź na to pytanie nie jest taka prosta, gra to nie tylko grafika, lecz bardzo wiele osób dzieli gry ze względu na grafikę. Respekt wśród innych gamecoderów w amatorskich zgrupowaniach zdecydowanie większy przypada tym, którzy tworzą gry 3D, mimo iż tak naprawdę niektóre gry 2D oferują dużo więcej rozrywki niż 3D.

Ważna kwestia przy wyborze pomiędzy 2D i 3D jest to czy piszemy sami czy mamy jakąś grupę, w której znajdują się artyści. Gra 2D jest mniej wymagająca, jeśli chodzi o liczbe osób ja tworzących. Popularne ostatnio są gry Casual, które opierają się na dobrym pomyśle i schludnym wykonaniu, większość popularnych casuali jest 2D. Lecz Casual to nie jest jedyne miejsce, w którym wiele projektów 2D króluje nad tymi 3D. Na rynku retailowym dla przykładu gry RTS, StarCraft jest grą 2D i mimo tego, iż został napisany wiele lat temu jest chyba najbardziej popularna gra RTS na świecie, inne gry RTS, które są 2D takie jak Np. AoE 1-2, AoM również nadal są bardzo popularne. Gry 2D maja zazwyczaj rysowana ręcznie grafikę, co powoduje bardzo dokładne dopasowanie elementów. Wiele osób uważa że wcześniejsze( 2D) wersje gier takich jak Warcraft/Age Of Empires są lepsze od nowych w pełnym 3D.

W grach przedewszystkim liczy się grywalność to, aby gracz grał w nasza grę jak najdłużej nie, dlatego ze nie może jej przejść, lecz dlatego ze bardzo go wciąga i się przy niej nie nudzi. Gracz kupując/ściągając nasza grę oczekuje ze zapewni mu ona rozrywkę na dłuższy czas a nie na pierwsza godzinę. Wysoki poziom grywalności w grze 2D łatwiej jest osiągnąć niż w 3D, można na przykład gameplay gry 2D oprzeć w całości o dobra fizykę, przykładem takiej gry jest Np. Gish. Gra, w której steruje się kulka smoły  jest ona na tyle wciągająca ze, gdy pierwszy raz ją zobaczyliśmy na warsztacie to złożyliśmy się w kilka osób na pełną wersje.


[Gish]

W grach 3D ciężko znaleźć taką oparta o fizykę, która wciąga na więcej niż 2-3 godziny. Jeśli ktoś zna jakiś dobry tytuł to niech mi da znać.

Wiele osób uważa, iż w 2D nie zrobi już nic nowego, nie rozwinie się, lecz jest to błąd. Nikt nie każe nam korzystać z standardowych granic myślowych. Można wymyślać jakieś ryzykowne, lecz innowacyjne rozwiązania, korzystać z shaderów, etc. Programistę ogranicza tylko jego wyobraźnia.

Ja osobiście głównie programuje w trójwymiarze, głównie, dlatego iż bardzo lubię technikalia, lecz na pewno napisze jeszcze jakieś rzeczy 2D w przyszłości, aczkolwiek nie będą to jakieś oklepane pomysły, ponieważ uważam ze zawsze trzeba dążyć do odkrywania innowacyjnych rozwiązań a nie do pisania dwutysięcznej wersji Mario.

Podsumowując, jeżeli pracujemy sami nad projektem, możemy spróbować zrobić grę 2D bądź oparta na dobrej fizyce bądź tez z jakimiś innowacyjnymi pomysłami. Zdecydowanie łatwiej będzie skończyć taki projekt niż kolejnego 3D RPG. Gdy pracujemy sami dobra grywalność w grze łatwiej będzie uzyskać w 2 wymiarach. Nie kończenie projektów spowodowane jest w 90 % przerostem ambicji nad umiejętnościami. Jeśli mamy zespól możemy spróbować napisać jakaś ciekawa grę 3D.

Sens pisania GUI

Witam!

GUI - graphic user interface, jeżeli przeprowadziło by się ankietę wśród programistów którzy pisali ( piszą ) swój Silnik, zapewne większość z nich powiedziała by iż zaimplementowali oni swój własny system GUI ( prawdopodobnie od zera ) .

Gdyby obejrzeć te jakże rożne implementacje GUI , u większości zauważylibyśmy nawiązania do systemowego GUI, mniejsze czy większe. Tak naprawdę większość silnikowych systemów GUI jest własną implementacją interfejsu systemu operacyjnego.

Należy zadać sobie pytanie czy naprawdę warto wyważać otwarte drzwi?
Czy warto pisać coś, co już jest napisane, i ma się bardzo dobrze?

W grze powinno być, GUI inne niż zwykłe systemowe, tak naprawdę ciężko znaleźć coś bardziej odrzucającego niż standardowe elementy GUI ( VCL etc.) wrzucone w ekran gry.

Wyobraźmy sobie jakaś profesjonalną grę z takim czymś:


Przydałoby się zaimplementować kilka standardowych kontrolek GUI, lecz tak naprawdę w 90 % przypadków wystarcza takie elementy jak Button, Scrollbar, ComboBox, ewentualnie jeszcze Edit. Większość programistów jak już się zabiera za pisanie własnego interfejsu to tworzy masę kontrolek, których tak naprawdę potem nie używa albo używa sporadycznie.

Zapewne większość myśli, że użyje swojego wypasionego GUI w Edytorach wszelkiej maści.
Prawda jest taka, iż pisanie większości typów Edytorów na własnym systemie GUI jest, co najmniej zbędne. Jeżeli ma to być Np. Edytor poziomów w grze 3D najzupełniej wystarczy tutaj systemowe GUI, Edytor cząsteczek? Również standardowe GUI radzi sobie bardzo dobrze. ( Edytory Unreal 3 Engine korzystają z wxWidgets, więc coś w tym jest)

Żeby moja opinia nie byłą gołosłowna postaram się sformułować kilka argumentów.

Argumenty Za:
- możliwość stworzenia Customowego systemu gui, takiego, jaki Nam pasuję.
- banalne zmienianie skórek.
- można powiedzieć, iż zaprogramowało się wypasione, GUI od zera :P

Argumenty Przeciw:
- marnowanie czasu na pisanie od zera czegoś, co zostało już napisane i ma się bardzo dobrze ( Wzorowanie na systemowym GUI)
- potrzeba stworzenia skórek ( chociażby jednej)
- pisanie wielu kontrolek, których tak naprawdę nie potrzeba ( znowu marnowanie czasu)
- Konieczność przyzwyczajenia się do customowego systemu GUI.

Edytorów nie tworzy się tylko dla Siebie, obsługa ma być prosta i przyjemna, aby w
Każdym momencie produkcji można było przekazać taki Edytor komuś innemu. Większość osób przyzwyczajona jest do systemowego GUI i każde odstępstwa w zachowaniach GUI edytora od tego standardu będą ciężkie do zaakceptowania. Używając customowego gui w Edytorze zmuszasz artystów do przestawienia się na twój system, co za tym idzie dłużej potrwa nim dana osoba opanuje wszystkie zachowania edytora, dłużej potrwa przygotowanie, contentu więc wydłużasz cykl produkcji.

Podsumowując:

Komplementarny system GUI tworzyć powinno się tylko wtedy, gdy wiemy, iż będzie nam potrzebny. Jeżeli nie planujemy pisać jakiegoś innowacyjnego edytora, nie ma sensu tworzyć sporej ilości customowych kontrolek. Do większości produkcji spokojnie wystarczy systemowe GUI czy chociażby jakaś biblioteka przenośna typu wxWidgets. Powinniśmy się starać zachować standard systemowego GUI gdyż ułatwi to prace osobom pracującym na naszych produktach. Starajmy się trzymać zasady KISS ( keep it short & simple). Czas, który zaoszczędzimy na wyważaniu otwartych drzwi możemy przeznaczyć na dopracowanie innych elementów naszej produkcji.

Btw. Zdarzyło mi się napisać 2 kompletne systemy GUI z pełną maścią kontrolek również zaawansowanych Np. PropertyGrid etc.

Kilka słów na wstępie

Witam !
Postanowiłem założyć blog ponieważ uznałem iż wygodniej mi będzie zamieszczać tu ewentualne informacje, screeny itp. niż na stronie domowej.

Więc na wstępie zamieszczam kilka screenów, filmików z moich poprzednich projektów.





Material Editor sample