www.warsztatgames.fora.pl

Will

-Core
Ogólnie mój pomysł na budowę całości. Proponuje zastosować system komponentowy dla całej budowy gry tzn. każdy obiekt gry byłby instancja klasy podobnej do tej:

PsichiX

a co z RTTI? siedziałem juz nad jednym dużym projektem i RTTI dało nam dużo ułatwień przy dziedziczeniu i sprawdzaniu z jakim obiektem mamy do czynienia

SnowyMan

-Renderer

@Will Małe poprawki, co powiecie na coś takiego?

Will

@SnowyMan Cały kram z przygotowywaniem draw listy polega na tym, że nie ma żadnego interfejsu IRenderable. Ty dostajesz suche dane. Czyli face+transformacje+materiał z jakim mają zostać wyrenderowane. Czcionki, które należą do gui będą renderowane osobno np z innego viewa. Nie ma potrzeby pakować żadnego Effect itd. Dostajesz materiał id a efekt/shader pobierasz sobie z bezpośrednio z mgr. Możesz sobie wszystko posortować według materiału czy robić inne cuda.

Klasa viewa może wyglądać tak:

PsichiX

taki, że jak robisz obiekty dziedziczące po GameObject, to czasem będziesz chciał sprawdzać, czy dany GameObject jest typem np. przeciwnika, przeszkody itp. chyba, że chcecie robić bez dziedziczenia, a każdy gameobject miałby w sobie jakoś zapisane te informacje

SnowyMan

@Will Czyli w gruncie rzeczy to co dostaję w RenderCommand to przekształcenia do wykonania, id materiału (na podstawie którego będę mógł sobie wybrać shader z RM) oraz sprite'a... czyli VBO i id tekstury w RM? Nie jestem pewien czy dobrze cię zrozumiałem więc znów mnie popraw jeśli musisz ^^

PsichiX

jest sobie VBO, który trzyma sobie bacza meshy, render command zawiera liczby oznaczające przedział vbo (lub ibo, które sortujemy do zoptymalizaowania renderingu setu meshy o tym samym materiale), który trzeba wyrenderować.
refki:
[link widoczny dla zalogowanych]
[link widoczny dla zalogowanych]
[link widoczny dla zalogowanych]
[link widoczny dla zalogowanych]

Will

SnowyMan

Ok, dzienks, załapałem koncepcję. Jak już ogarniemy cały plan to będę wiedział co i jak pisać Smile

PsichiX kiedyś już dałeś mi te linki i jak wtedy tak i teraz nie potrafię tego ogarnąć :/ Nie robimy zresztą Crysis'a żeby tak kombinować z wydajnością, im prościej będzie tym lepiej.

PsichiX

ok, byleby nie wyszedł z tego znowu sfml, bo konstrukcja zaczyna go właśnie przypominać ;p a to "im prościej", to ja już przerobiłem w xenonie 1 - walnij potem masę danych do przetrawienia, to się renderer nie pozbiera (wersja wstępna X2 i webgl używała vbo per object), a druga sprawa, że lepiej mu renderować sety danych niżeli obiekty po kolei - mniej draw calli, tym lepiej. uwierzcie - wiem, o czym mówię. jak trzeba, to mogę zająć się renderingiem baczy, a Wy będziecie mu tylko wskazywać, co ma renderować, a co nie, jak to pokazał will Wink

mogę się zgłosić do review renderingu, jak już zrobicie.

Will

To nie jest konstrukcja im prościej tylko dobrze przemyślana struktura świetnie sprawdzająca się przy silnikach 3d i doskonale przystosowana do dzielenia całości na osobne wątki. Taki system komponentowy stosowany jest choćby przez NaughtyDog o ile się nie mylę i wiele innych silników. Jest niewiarygodnie wydajny jeśli chodzi o pamięć, wręcz kochany przez cache. Draw calli będzie tak mała ilość jak to tylko możliwe, całość render commandów jest wręcz banalna do posortowania a dzięki jakiemuś preprocessingowi można dzięki temu też łatwo wykryć co warto upchać w static meshe(choć to już przy tak małym projekcie zupełnie nieopłacalne).

SnowyMan

Hmm to co jeszcze jakieś pomysły? Może zrobimy już szkielecik? ^^ Podstawowe struktury, klasa RM i interface zasobów? Niech ktoś się zajmie już edytorem i opracujmy sobie jakiś format dla map kafelkowych, bo lekki zastój się zrobił :/ Aha, jeszcze chciałem powiedzieć, że możliwe, iż niedługo będę leciał do Londynu więc zniknę na jakiś tydz i ktoś będzie musiał mnie zastąpić.

nobody

Mogę się już w gruncie rzeczy brać za edytor (na tyle ile czas pozwoli).

Na chwilę obecną mógłbym tak właściwie zaprojektować wstępne UI oraz jakieś podstawowe funkcjonalności. Aby było coś więcej potrzebowałbym jakieś dokładniejsze informacje na temat formatu pliku, ogólnie sposób na mapę (czy korzysta z warstw, czy będzie używać kafli i takie tam) oraz wstępny interfejs renderera (najlepiej byłoby mieć od razu działający, ale mogę sobie na szybko coś dopisać pod interfejs).

Wstępne informacje na temat projektu edytora:

Technologia: C#/WPF (zdaje się, że wygrało większością głosów)
+ [link widoczny dla zalogowanych] (jeszcze z tego nie korzystałem, ale wydaje się fajną i darmową biblioteczką do dockable windows (jak to sensownie przetłumaczyć?))

Planowane funkcjonalności:
- to co każdy edytor powinien mieć (edycja mapy, właściwości obiektów itd.)
- wbudowany edytor skryptów
- możliwość edycji wielu map równocześnie
- odpalenie gry w edytorze
- możliwość edycji mechów (to IMHO warto by zorganizować jako plugin, by ułatwić użycie edytora w ewentualnych kolejnych projektach)
+ w sumie można by większość rzeczy związanych z daną grą zorganizować jako pluginy) (?)
- i może coś jeszcze Smile

Oprócz tego przydałby się jakiś SVN (niestety jeszcze z tego nie korzystałem, ale to jest raczej dosyć proste) i ew. czy ktoś jeszcze będzie brał udział w pisaniu edytora (oczywiście w tym wypadku nie mówię o pojedynczych taskach, tylko o tym jako o "głównej" profesji - chodzi o podstawowe omówienie projektu kodu.

[Edit]: Zrobiłem sobie mały test AvalonDock i to jest naprawdę fajne Wink

Will

Hmm.. na razie czekam na decyzje pozostałych osób bo jest kilka opcji do wyboru a jeśli będą problemy i ktoś będzie się upierał przy czymś co jest zajęte będzie kłopot.
Generalnie każdy może pisać sobie wewnętrzną bazę czyli core swojego parta bo są one niezależne od samego core mechaniki.

Przygotuje szkielet może w weekend, tak aby była baza i zrobię projekcik na assembli żeby można było dzielić się plikami.

@nobody to jest bodajże weifen. Uzywałem go do edytora dla ogre i sprawiał się bardzo dobrze więc nie powinno z nim być większych problemów.
Baze do renderingu możesz sobie napisać pod testy tylko jak chcesz robić kontaktowanie się edytora z silnikiem? tzn którą opcje wybierasz?

nobody

Edytor w gruncie rzeczy powinien być na tyle niezależny od silnika na ile się da. IMHO najwygodniej byłoby napisać jakiegoś pośrednika w C++/CLI, który udostępniałby tylko parę potrzebnych rzeczy. Czyli renderer i ew. jakieś specjalne rzeczy, które są wyjątkowe w tej grze (choć bardziej estetyczne byłoby traktowanie ich jako pluginów).

Wydaje mi się także, że dobrym pomysłem byłoby stworzenie w kodzie czegoś na kształt GameInstance (nazywajcie sobie jak chcecie), który dałoby się osadzić w oknie edytora na potrzeby odpalania gry w edytorze.

I w sumie jedno z najważniejszych pytań odnośnie edytora: W jakiej formie byłyby mapy? Ja widzę kilka pomysłów:
- Warstwa terenu oraz warstwa obiektów. Lub po prostu tylko warstwa obiektów i traktowanie terenu jak każdego innego obiektu (choć dla wygody pisania edytora lepiej byłoby teren traktować jednak oddzielnie). Teren dałoby się dowolnie malować teksturkami.
- To co wyżej, tylko zamiast malowalnego terenu jakieś kafle.
- Składanie mapy tylko z obiektów. Jakoś nie wydaje mi się to sensownym rozwiązaniem.

[Edit]: Jeszcze kilka rzeczy Wink

- Co myślicie o pluginowej budowie?
- GameObjecty według mnie warto by zrobić jako szablon obiektu z pliku (czyli szablon obiektu z pliku: jakie ma komponenty itd. Same podstawowe informacje). A w edytorze byłaby tylko możliwość zmiany właściwości obiektów + ew. jakiś prosty edytor szablonów.