[adiblol]

Do tej pory zajmowaliśmy się pierdołami. W przerwie od commitów (a może to tylko mi się svn zj**ał i nie widzę aktualizacji? ) spowodowanej rokiem szkolnym etc. postanowiłem poruszyć ten temat (tiaaaaa...)

Jak sama nazwa tematu wskazuje zajmować się będziemy architekturą, czyli czymś co jest konieczne do każdego dużego projektu programistycznego.

Zamknij więc te demoty, te komixxy, mistrzów i piekielnych też, które skrzętnie ukrywasz w drugim oknie przeglądarki gdy udajesz że szukasz na Wikipedii informacji o lasach tropikalnych. Zamknij też zminimalizowanego Minecrafta, i tak w końcu zginiesz (w grze oczywiście). Wersja ekstremalna: znajdź taki przełącznik z tyłu komputera, przełącz go na 0 a po 5 sekunach na 1 (możesz po krótszym czasie ale chyba nie chcesz spalić zasilacza bo wtedy już nigdy nie włączysz Minecrafta). Jeśli go nie ma to użyj zamiast tego takiego świecącego na czerwono przełącznika na listwie. Następnie włącz komputer i w przeglądarce nie przywracaj sesji tylko w czystym oknie wejdź na forum. Taaa, dobrze. Uporałeś się z czasomarnowaczami nowoczesnych technologii (por. http://eduwww.net/index.p...dzieja&Itemid=4 ).

Więc na takim systemie uruchom najnowszą wersję Colonization z SVN. Co widzisz? Lamerskie menu (to akurat pierdoła, więc nie będziemy jej poprawiać na coś mniej lamerskiego) a następnie lamerską mapę (płaszczyzna, tylko podtrzymujących słoni brakuje xD ) ze skrzynią w środku i skybox'a który ma przypominać góry. Można pewnym klawiszem utworzyć pojazd, który wisi w powietrzu (prawdziwie tibijska fizyka). Nawet nie wiadomo czy koła będą się poruszały jak powinny. Czy jeżeli umieścimy transporter to zostaną prawidłowo wczytane grupy tak abyśmy mogli animować chwytak? A może wystarczy jedna instrukcja a chwytak będzie animowany automatycznie (animacja w pliku z modelem)? Cały silnik fizyczny dziwnie działa - na skrzyni można się "osunąć" a stożek twardo blokuje przejście.

Kolejna sprawa - kod (hahaha!). Fragmenty łączące grę z silnikiem są skopiowane z neta niczym prace magisterskie studentów przedsiębiorczości i zarządzania. Plik CDeviceInfo.h najwyraźniej był tworzony na wzór API Micro$oftu. Po co duplikować kod dodając tylko literki L? Nie wystarczy normalny char*? Przecież UTF-8 jest kompatybilny z ASCII, po co komplikować? Czy nazw rendererów nie da się odczytać z Irrlicht'a?

Do czego zmierzam? Wszyscy się jarali (ja też) że już coś działa, a bazując na aktualnym kodzie można napisać co najwyżej single-player FPS-a z jednym nieruchomym wrogiem, ale za to z anaglifowym 3D (innowacja, sprzedajmy to!).

A więc jak to powinno wyglądać? No właśnie trzeba się zastanowić. (1) Musimy zaprojektować strukturę przestrzeni nazw i klas. Czym będzie rdzeń gry? Fizyki raczej nie będzie obsługiwał, więc co? Tylko zarządzanie obiektami? Synchronizację multiplayera? To dyskusje podobne do typu jądra przy tworzeniu OS-u (monolit, mikro czy hybryda?). (2) Jeżeli wykorzystujemy silnik fizyczny Irrlicht'a będzie on musiał działać także na serwerze. Jak zsynchronizujemy fizykę przy multiplayerze? Jak połączymy go z programowaniem i zdalną kontrolą robotów?

Z dotychczasowych propozycji wiem że mapy będą plikami 3D (mesh). Zuo, mhrok. Dlaczego? Jedną z cech decydujących o "otwartości" (hahaha) Colobota (pomijam otwartość kodu, hahaha) było użycie plików tekstowych do opisu poziomów. Dzięki temu ludzie mający ciekawe pomysły na fabułę, lecz nieumiejący obsługiwać Blendera czy 3Ds Max'a mogli tworzyć user levele. Mogli nawet nadawać "klimat" planetom dzięki wykorzystaniu własnych tekstur gruntu, mgły w wybranych miejscach etc. (3) Zastosujmy to też w Colonization! Dajmy wybór, czy mapa ma być bez obróbki ładowana z pliku (przyda się do scen indoor i np. do jaskiń) czy tworzona na podstawie heightmapy, opisu gruntu i opisów ozdób. Obiekty interaktywne *nie powinny* być w pliku środowiska! Podawałem już proponowaną strukturę, dawno dawno temu, o tu: http://www.colobot.cba.pl...topic.php?t=123 z tym że wtedy byłem jeszcze windowsiarzem i nie myślałem o multiplatformowych kontrolkach GUI.

GUI to kolejna ciężka sprawa. Czy interfejs *musi* być budowany na kontrolkach Irrlicht'a? Nie wyobrażam sobie edytora programów dla robotów. (4) Bardziej profesjonalnym sposobem byłoby zrobienie *kilku okien*, np. w GTK, w tym menu główne, edycja programu, projektowanie robotów (o ile wdrożymy ten pomysł) i, wreszcie, podgląd 3D.



Co do struktury klas: jak jeszcze lubiłem C# i próbowałem tworzyć CWorld, napisałem taki plik planet.cs: http://paste.debian.net/133643/
Struktura katalogów i plików wyglądała tak:

Kod:

. ./c-world.sln ./tests ./tests/interpolation ./tests/interpolation/interpolation.csproj ./tests/interpolation/AssemblyInfo.cs ./tests/interpolation/bin ./tests/interpolation/bin/Debug ./tests/interpolation/bin/Debug/interpolation.exe.mdb ./tests/interpolation/bin/Debug/c-world.dll ./tests/interpolation/bin/Debug/c-world.dll.mdb ./tests/interpolation/bin/Debug/interpolation.exe ./tests/interpolation/interpolation.pidb ./tests/interpolation/Main.cs ./AssemblyInfo.cs ./bin ./bin/Debug ./bin/Debug/c-world.dll ./bin/Debug/c-world.dll.mdb ./core ./Packages.mdproj ./c-world-core.pidb ./c-world.userprefs ./planet.cs ./c-world-core.csproj

(planet.cs chyba miał się ostatecznie znaleźć w core...)

Tym optymistycznym akcentem w postaci przykładu kodu kończę. Liczę na odpowiedzi. Nawet na trolling, o ile będzie konstruktywny (konstruktywny trolling? Istnieje w ogóle coś takiego?)


pozdr
adiblol

[ Dodano: 02-10-2011, 17:26 ]

Cytat:

Irrlicht is not a game engine, it only does graphics. For a game, you need a bit more, like sound output and maybe networking and physics

http://irrlicht.sourceforge.net/faq.html
Czyli fizykę robimy zewnętrznie? Hm...

[Wronq]

Jednym z ciekawszych pytań jest w jaki sposób będzie obsługiwany parser? Chodzi mi o to, co będzie co udostępniało jakiemuś obiektowi, który wypełnia instrukcje. To trzeba dobrze przemyśleć, żeby kicha nie wyszła na koniec, bo przeróbki mogą okazać się kosztowne, jeżeli z poziomu parsera będziemy się odwoływać do świata/plików/robotów itd.
Co proponujecie jako język skryptowy? C++? Czy na łatwiznę i jakieś lua?

[adiblol]

[Madman07]

Widzę ze adiblol się zna na rzeczy To ja wtrącę parę swych uwag:

Fizyka. Tutaj mozna bazować na rozwiązaniu Source'a od Valve. Robimy istny podział serwer - klient (nawet dla gry single player, choć wtedy i serwer i klient to jedna maszyna, chociaz można to traktować jako dwie połączone ze sobą). Serwer liczy całą fizykę. Klient bawi się renderingiem 3d + tzw. prediction czyli bawi się kawałkiem fizyki dotyczącym gracza. O ile w single player to nie problem, to w multi duży wpływ mają pingi. Dlatego serwer liczy swoją fizykę graczy, a kazdy z klientów ją poprawia, żeby zapewnić jak najlepszą interakcję. Tak mi się wydaje, trochę siedzę w source.

Mapy, mapy, mapy. Nie wiem jak reszta, ale ja tu wolałbym levele z 3ds maxa tudzież jakiegoś hammera, radianta w formacie 3ds, albo bsp. Heightmapy mają kilka wad - praktycznie 0 (zero!) możliwości zbudowania pięknego tzw. skybox 3d, który jest stworzony poprzez powiększenie pewnego fragmentu mapy (wraz z różnymi efektami (sprities etc) + zwyczajny skybox w tle). Następna wada to brak możliwości jaskiń, a myślę, ze wiele osób by chciała je mieć. Ponadto o ile moje rozumienie jest ok, w przpadku map bsp wszelkie lightmapy itp są skompilowane, co odciąża grafikę usera i daje więcej fps

Programowanie robotów mogło by być w lua IMHO ale to już zalezy od was. Wspominam ten język tylko dlatego, ze jest składniowo nieco łatwiejszy.

A i roboty. Tu się skłaniam pozycji, że poszczególne części robotów są łączone w kodzie i animowane. Trochę więcej pracy dla programistów, choć jest drugie wyjście. Tzw. poses. W source działa to w ten sposób, żr podczas przygotowywania animacji, definiujemy np. minimalne, maksymalne wychylenie i pozycje neutralną. Można wprowadzić wiele takich animacji (proces jest nieco skomplikowany, zajęło mi dokładnie dzień żeby skumać, jak to działa dla 2 animacji). Załóżmy, że zamknięcie chwytaka definiujemy za pomoca liczb z zakresu 0-1 (otwarty/zamkniety). Dzięki poses możemy płynnie regulować stopień otwarcia chwytaka bezpośrednio z kodu (bez jego mącenia dodawaniem poszczególnych części modelu ręcznie i przypisywaniem im właściwych pozycji) w zależności od chwytanego obiektu jednocześnie z zachowaniem odpowiedniej pozycji modelu kolizji. Jak się można domyślić takie coś się bardzo przyda, jeżeli bot stoi na stromym wzniesieniu a podnoszony obiekt lezy pod innym katem

Uff się rozpisałem...

[adiblol]

Jest jeszcze inne wyjście dot. animacji: wciągamy w to silnik fizyczny z tym że wtedy musimy precyzyjnie zaprojektować obiekt tak jak w realnym świecie. Później sterujemy z kodu gry tylko silnikiem elektrycznym/spalinowym/parowym xD/jonowym/whatever który porusza innymi częściami

Co do najwyższego poziomu abstrakcji: proponuję aby obiekty, ich właściwości etc. były pisane w Pythonie. W C++ tylko podstawy, np. lista obiektów, ich synchronizacja przez sieć, programowalność botów (tzn wykonywanie programów, nie że programy w C++...), integracja z silnikiem graficznym i fizycznym, dźwięk, i wszystkie "ogólne" sprawy które nie muszą być "modowalne".
A co w Pythonie? Wszystkie definicje obiektów. W każdym user levelu inne roboty będą na pewno ciekawym rozwiązaniem. Warunki zakończenia misji. Program uruchamiany równocześnie z misją który będzie mógł np. spawnować obcych.

WARNING WARNING WARNING!!! NIE WDRAŻAĆ IRRLICHTA DO JĄDRA GRY!!! Ma służyć tylko do wyświetlania. Nie chcemy go na serwerze, prawda?

Silnik fizyczny: np. Newton Game Dynamics. Istnieje gotowe rozwiązanie integrujące go z Irrlicht'em.

[Madman07]

@up, O ile takie rozwiązanie przynosi mi na myśl grę typu GMOD albo Spin Tires, o tyle nie sądze, że to było by coś fajnego :p

[adiblol]

Błagam, nie hardkodujmy listy obiektów w kodzie kompilowanym...

[Raptor]

[Thorin12]

Ew. można odrzucić poligony i zrobić Voxele D:

Gra będzie wtedy bardziej realistyczna ale też trudniejsza do kodowania...

(Wiem, nie znam się...)

[Madman07]

Nie mówiąc o liczeniu właściwości fizycznych silników. Ja tutaj nie mam zamiaru liczyć transmitancji operatorowych, i tak za dużo matlaba mam :p