www.warsztatgames.fora.pl

SnowyMan

Mi się ta mapka widzi tak:
3 warstwy kolejno: pod, na tym samym poziomie i nad graczami
teren byłby w pierwszej warstwie, imo wygodnie byłoby traktować każdy kafel jako obiekt chociażby po to żeby móc go animować ale nie sądzę by było to wydajne.

Odnośnie edytora to można go zrobić na tysiąc i więcej różnych sposobów, niech piszący edytor przedstawią swoją wizję a my się postaramy dostosować (and this is only my opinion). Co myślicie?

Will

Nie widzę sensu robić nawet żadnych kafli, wystarczy podzielić level na 2 typy normalny obiekt gry(gracz, przeszkoda, przeciwnik itp) i terrain. Jaki cel jest właściwie w ustawianiu całości jako kafle? Ogranicza tylko możliwości ustawienia obiektów. Co do łączenia edytora z silnikiem to napisanie wrappera w c++/cli to tak jakby podwójna robota i utrudnione debugowanie bo na 3 osoby. Jeśli większości to pasuje dla mnie no problem. Warto by było się zastanowić czy po prostu nie przesyłać messages przez sockety.

SnowyMan

@Will ale mienia chodzi o to by po prostu teren był złożony z kafli a nie jednej wielkiej bitmapy, obiekty nie muszą się w te kafle wpasowywać ^^ No i co z obiektami nad graczami? np. ptaki albo mgła w przypadku otwartych terenów, co z wybuchami? głupio by było gdyby jeden mech sobie wybuchł a obok stał drugi i cała animacja eksplozji odtworzyłaby się pod nim bo byłby później rysowany ^^ Trzecia warstwa jest jak dla mnie niezbędna, chyba, że chcecie kolejkować rysowanie (ale wtedy po co w ogóle warstwy) ?

nobody

W sumie komunikacja przez sockety może się udać. Nawet można by się pokusić o zupełne zrezygnowanie z jakiejkolwiek innej komunikacji z silnikiem za pomocą C++/CLI (acz, tu już w niektórych przypadkach grunt grząski mógłby być). Jeszcze trochę nad tym pomyślę.

Ad. teren:
Proponuje teren zorganizować nie jako kafle, lecz tak jak jest to zazwyczaj zrobione w grach 3D. Czyli jakieś tekstury terenu + odpowiednie maski by wiedzieć "ile oraz jakiej tekstury ma być w danym miejscu na terenie". W ten sposób uzyskalibyśmy łatwy w edycji teren, łatwy do wyrenderowania (quad + shader) i dosyć spore możliwości.

Xirdus

@SnowyMan: a ja właśnie myślę, że jedna wielka bitmapa byłaby dużo lepsza. W końcu mapa nie będzie zbyt duża - chodzi o napieprzanie się, a nie szukanie nawzajem.

SnowyMan

Ok, jak wolicie Smile

nobody

@Xirdus: Mógłbyś jakoś upakować całą stronę techniczną gry (jak zorganizowany jest teren, ile warstw itd.) w jeden papier? Nie mam na myśl oczywiście takich rzeczy jak np. komunikacja edytor-silnik, ale same technikalia gry.

SnowyMan

Ja jeszcze proponuję wyrzucić metodę load() z IResource, gdyż jak wiadomo shadery ładuje się najczęściej z dwóch (lub więcej) plików i nie będzie jak wpasować ich w IResource ^^ I jeszcze pytanko, ten IResource jest już finalny i nikt nie chce nic w nim zmieniać (oczywiście oprócz wywalenia metody load())? Bo jeśli tak to chciałbym już zacząć pisać implementację klas gfx_Effect i gfx_Texture w oparciu o ten interface Smile

edit.
aha no i wtedy w ResManagerze trzeba by przeładować metodę addResource() albo zrobić ją dla zmiennej liczby argumentów.

nobody

Btw. stworzyłem wstępną propozycję formatu mapy: [link widoczny dla zalogowanych]

Wkrótce także postaram się wyprodukować papier (nieduży) w którym pobieżnie opiszę filozofię działania edytora (będziecie mogli dorzucić jakieś pomysły, powiedzieć co jest failem projektowym itd.) Edytor już powoli piszę, ale trzeba poczekać, aż będę miał więcej czasu.

[Edit] A i postanowiłem dodać w projekcie obsługę dowolnej liczby warstw. Nie powinno to znacznie skomplikować kodu, a stała liczba warstw może czasem przeszkadzać.

[Edit2] Zapomniałem, jaka jest wasza opinia odnośnie takiego formatu mapy? Może lepiej byłoby połączyć tablicę tekstur i tablicę skryptów (oraz ew. jakieś kolejne tablice w przyszłości) w jedną tablicę zasobów?

nobody

Podgląd na wstępny projekt edytora: [link widoczny dla zalogowanych]

Trochę mało czasu ostatnio, a do tego w ten weekend pewnie go też za dużo nie będzie + to, że w środę wyjeżdżam na szkołę zimową (jakieś 10 dni) powoduje, że w najbliższym czasie czasu mieć nie będę. Prawdopodobnie zyskam go, gdy 3 klasy będą miały matury.

SnowyMan

Tak a propo wolnego czasu -> od soboty do czwartku będę za granicą więc musicie mi wybaczyć nieobecność.

Will

jw, w obecnym tygodniu i następnym mam taki zapier.., że nie wiem za co się złapać. Niech każdy kto ma czas pracuje nad swoją częścią. Tak właściwie to proponuje oficjalny początek pisania na 1 marca. Dobrze by było aby autor pomysłu jakaś rozwijał swoją idee tak aby informacji było coraz więcej.

hashedone

A więc piszemy od 1 marca (oczywiście kto może pisze już Wink

). A jako że na warsztacie padła już obietnica gry (gatunku i uniwersum), trza będzie skończyć, coby dumę zachować.
Od siebie - jestem ogólnie ostatnio zajęty, ale mógł bym już coś pisać. Na AI mi się jeszcze wydaje za wcześnie (żeby testować musi się dać je pod coś podpiąć), więc jeśli ktoś potrzebuje wsparcia przy innym module może napisać na PW (póki co będę pisał szkielecik AI na ile się da). Wyjątkiem jest tu edytor (sory nobody, nie znam na tyle C# Razz

).

Will

@hashedone zawsze możesz sobie testować na jakimś swoich framework'u jakieś testy AI a potem się przeżuci.

Zrobiłem space na assembli: [link widoczny dla zalogowanych]
Podawać maila to wyśle zaproszenia.

hashedone

hash [dott] deb [at] gmail [dott] com

W kwestii testowania AI - i co tak przetestuję? Wyszukiwanie ścierzek? Razz

AI musi być rozwijane zgodnie z mechaniką, bo jest silnie zależne od balansu mechaniki gry (dopóki nie będę wiedział jak bardzo i w jakich sytuacjach opłaca się zmniejszyć moc na działku nie jestem w stanie tego szacować w AI).