Etharnion RPG 1.0 - new version

[rhdbisgrt]

@rhdbisgrt:

Główny moduł dzięki temu może bez problemu dostać się do każdego takiego elementu, dostęp do niektórych mają również inne moduły (np. Dialog ma dostęp do questów żeby móc zmieniać ich stan).

Ok, ale mozesz powiedziec specjalnie dokładniej jak jest  ze wzajemna widzialnoscia tych obiektów?
Pytam głownie po temu ze sam na codzień pisze w c, nie uzywam OOP znam go słabo i jestem ciekaw jak to ludzie robia.. Czy te kontenery masz dostepne globalnie, inicjowane w aplikacyjnym init ?czy tez robisz jakas bardziej ograniczona widzialnosc i dostep robisz rozdajac jakies wskazniki - i jak ?

Co do questów i dialogów - Jak sprawdzasz czy dany quest jest wykonany czy tez nalezy go wrzucic na liste podjetych questow? O ile pamietam jak ja pisalem jakies questy (zaczatkowe co prawda bo nigdy jakos wiele questow nie pisalem)  to byly one mocno zaszyte w kodzie dlatego tez ew troche dzwi mnie sposob ich wydzielenia do osobnego kontenera (czy tez sa one tak jak mysle wydzielone tylko czesciowo i mechanika questow jest zaszyta w grze a tylko czesc danych jest w kontenerze questow?

Co do czarow - mozesz powiedziec jakie pola ma obiekt typu czar ? co tam jest pozycja i czas w ramkach do znikniecia z planszy ? Czary obslugujesz w jakis jednolity sposob czy kazdy odzielnym kodem i co to mw wykonuje?

[Mr. Spam]

[Adam27]

Zwykłe include'y - jak np. Dialog potrzebuje znać informacje o questach, daję mu #include "Quest.h", a w tym pliku jest już zadeklarowany globalnie  extern vector<Quest*> quests więc nie ma żadnego problemu z widocznością.

Każdy quest na liście ma swój stan - na początku nieaktywny. Potem, podczas gry, gdy Dialog dostanie do wykonania polecenie np. accept(QUEST_NAZWA_QUESTA), mapa asocjacyjna znajduje po tym identyfikatorze tekstowym numer questa w kontenerze, i wykonywana jest metoda quests[index]->accept(), dzięki czemu quest przyjmuje stan aktywny, a w grze pojawia się informacja o nowym zadaniu. Same informacje o tym kiedy dany quest ma zostać przyjęty, kiedy zakończony itp. są w osobnych plikach, głównie w pliku dialogów, gdzie właściwie dzieje się prawie cała akcja gry.

[rhdbisgrt]

A co do czarów? I jeszcze jedno pytanie: jaka czesc mniej wiecej kodu w tych 16tysach odpowiada za sprawy zwiazane z renderingiem a jaka jest nie zwiazana z renderingiem ? I z ciekawosci tez- ktory kod uwazasz byl trudniejszy do napisania ten z renderingiem czy reszta?

[hfjh]

A jak wyglądał edytor świata?

[Adam27]

@rhdbisgrt:

Czar posiada następujące pola: typ (bo są pociskowe i obszarowe), pozycję, prędkość, zasięg, obrażenia, id postaci która go wywołała i wskaźnik na inny czar który zostanie stworzony gdy ten czar zacznie z czymś kolidować - czyli np. wybuch kuli ognia gdy ta w coś uderzy.

Jeśli za sprawy związane z renderingiem uznać też rysowanie wszystkich okien itp. to zdecydowanie ta część była trudniejsza, jako że masę wartości musiałem hardkodować i było to dość męczące. A poza tym, takie rzeczy jak oświetlenie, system cząsteczkowy itp. pisałem po raz pierwszy, poznawałem dopiero shadery i uczyłem się ich używać, więc na pewno sporo czasu mi to zajęło. Ale nie żałuję, teraz mam dzięki temu +100 do skilla i +1000 doświadczenia ;P Jeśli chodzi o objętość w kodzie, na oko rendering zajmuje ~3/4 (licząc rysowanie okien).


@hfjh:

Edytowanie kafelków, stawianie, przesuwanie, obracanie obiektów, rysowanie ścieżek, definiowanie waypointów dla AI - i tyle ;P Takie rzeczy jak pozycje postaci itp. ustawiałem ręcznie bo nie chciało mi się implementować tego w edytorze.
PS. udało się przejść? ;)

[rhdbisgrt]

@rhdbisgrt:

Czar posiada następujące pola: typ (bo są pociskowe i obszarowe), pozycję, prędkość, zasięg, obrażenia, id postaci która go wywołała i wskaźnik na inny czar który zostanie stworzony gdy ten czar zacznie z czymś kolidować - czyli np. wybuch kuli ognia gdy ta w coś uderzy.

Jeśli za sprawy związane z renderingiem uznać też rysowanie wszystkich okien itp. to zdecydowanie ta część była trudniejsza, jako że masę wartości musiałem hardkodować i było to dość męczące. A poza tym, takie rzeczy jak oświetlenie, system cząsteczkowy itp. pisałem po raz pierwszy, poznawałem dopiero shadery i uczyłem się ich używać, więc na pewno sporo czasu mi to zajęło. Ale nie żałuję, teraz mam dzięki temu +100 do skilla i +1000 doświadczenia ;P Jeśli chodzi o objętość w kodzie, na oko rendering zajmuje ~3/4 (licząc rysowanie okien).

A jeszcze pytanie co do spraw renderingu: wszystko tu jest chyba dwuwymiarowe, animacje masz pewnie w postaci atlasow, wyswietlasz  wszystko w postaci quadów na jednej plaszczyznie z? Jak sie robi (z grubsza) takie efekty jakie masz czyli to swiatlo i te cienie o jakich mowa ? (nie gralem ale obejrzalem filmik, gra zdecydowanie b ciekawa i muza tez zdecydowanie calkiem niezla :/)

[Adam27]

Tak, 2D, atlasy z klatkami animacji.
Światła rysowane są do pełnowymiarowej tekstury, na to nakładane są cienie, potem przy rysowaniu mapy wartość koloru z tekstury ze światłami mnożona jest przez kolor tekstury mapy. Ale do tego potrzeba shaderów, czyli OpenGL w wersji co najmniej 2.0.

[rhdbisgrt]

Tak, 2D, atlasy z klatkami animacji.
Światła rysowane są do pełnowymiarowej tekstury, na to nakładane są cienie, potem przy rysowaniu mapy wartość koloru z tekstury ze światłami mnożona jest przez kolor tekstury mapy. Ale do tego potrzeba shaderów, czyli OpenGL w wersji co najmniej 2.0.

Tak mi sie zdawalo ze tam zwykle sprite'y + mnozenie moze wchodzic w gre, ale nie bylem pewien czy to by tak dosyc dobrze wyszlo.
A sam ekran to jest tyle quadów ile tili mapy plus odzielne quady dla obiektow na mapie, elementow gui, czy jakos inaczej :> ? Co do tych cieni to jak ogladalem filmik to nie zwracalem uwagi i nie kojarze tych cieni, nie kojarze tez wogole jak mozna robic cienie na dwuwymiarowej mapie :? co tam zaslania co i rzuca cien, dane sprite'y po prostej?, to tez liczy sie na shaderach? tnx za ciekawe wyjasnienia

[Adam27]

Quadów jest tyle ile widać, nie może być inaczej. Cienie powstają jak jest światło i stoi obok np. beczka albo ściana która je przysłania, głupio by było gdyby światło w środku pomieszczenia oświetlało również wszystko na zewnątrz. Na shaderach liczy się pozycję wierzchołków i kolor piksela - ale to nie temat na wyjaśnianie do czego one służą. Obliczenia cieni, na podstawie wierzchołków obiektów, realizowane są w kodzie.

[rhdbisgrt]

Quadów jest tyle ile widać, nie może być inaczej. Cienie powstają jak jest światło i stoi obok np. beczka albo ściana która je przysłania, głupio by było gdyby światło w środku pomieszczenia oświetlało również wszystko na zewnątrz. Na shaderach liczy się pozycję wierzchołków i kolor piksela - ale to nie temat na wyjaśnianie do czego one służą. Obliczenia cieni, na podstawie wierzchołków obiektów, realizowane są w kodzie.

OK, nie do konca zrozumialem z tymi cieniami (wiem jak to mozna zrobic normalnie - normalnie to bym wyslal prostą ze swiatlem i urwal na przeszkodzie - ale nie kojarze jak to sie robi na shaderach) - No ale ok, niewazne.

Pytalem bo bardzo mnie ciekawilo jak to (tego rodzaju gra) wyglada od srodka, Bez takiego wgladu wydaje sie to trudne do zrobienia, (ze trudnosci, i ze byoby skomplikowane do zrobienia) ale widze ze nie jest az tak zle.

Jakby co to moge wniesc kiedyś jakas kontrybucje i podrzucic kiedys jakis kawalek kodu jakbym akurat miał na temat albo coś:> , ale to tylko mowie tak ogolnie, bo projekt mi sie podoba - niezle to jest. :>

[Adam27]

Pojawiła się nowa wersja 1.1, niosąca ze sobą głównie poprawki bugów i drobne udoskonalenia. Dokładna lista zmian w pliku ReadMe. Zapis gry z wersji 1.0 jest oczywiście kompatybilny z nową wersją.

Gra do pobrania na stronie: http://etharnion.cloudserv.tk
Projekt na Warsztacie: http://warsztat.gd/projects/etharnion

Pozdrawiam.

[Adam27]

Udostępniłem kolejną wersję gry oznaczoną numerem 1.2. Wersja ta, podobnie jak poprzednia, niesie ze sobą głównie kilka poprawionych błędów oraz usprawnienia mające na celu umilić rozgrywkę :) Pełna lista zmian w pliku ReadMe.

http://etharnion.cloudserv.tk

Pozdrawiam.

[kula]

Po pierwsze chciałbym Ci pogratulować, bo gra jest naprawdę niezła.

Mam jednak parę uwag, którymi chciałbym się podzielić:
- nieruchoma kamera zawieszona nad postacią sprawdziłaby się doskonale w przypadku grania w kwadratowym oknie, ale w przypadku monitora w proporcjach 16:9 (obecnie to już chyba standard) widok w pionie jest mocno ograniczony, więc fajne byłoby dodanie wychylenia kamery np. przy oddalaniu kursora od środka ekranu
- mógłbyś też rozważyć usunięcie z dolnej części ekranu trapezu w którym wyświetlają się statystyki NPC'ów i wyświetlać go jedynie wtedy, gdy jest potrzebny (co wpłynęłoby też na zwiększenie widoczności w pionie)
- przydłby się sprint (wiem, że jest w postaci miksturek, ale to dość drogi "usprawniacz" rozgrywki) aktywowany np. jedynie przy schowanej broni albo gdy postać nie prowadzi walki, a więc taki, by nie wpływał na balans walk, a jednocześnie rozwiązał problem bardzo wolnego przemieszczania się bohatera
A z mniejszych niedociągnięć:
- po najechaniu kursorem nad NPC'a zasłoniętego dachem nadal wyświetlają się jego statystyki
- podłogi w pomieszczeniach dziwnie się wyświetlają przy odpaleniu gry w niskiej rozdzielczości (brak mipmap?)
- będąc w menu głównym po naciśnięciu klawisza 'm' program się sypie

Pozdrawiam.

[ShadowDancer]

- mógłbyś też rozważyć usunięcie z dolnej części ekranu trapezu w którym wyświetlają się statystyki NPC'ów i wyświetlać go jedynie wtedy, gdy jest potrzebny (co wpłynęłoby też na zwiększenie widoczności w pionie)

Już chyba lepiej by było walnąć pionowy hud.

- przydłby się sprint (wiem, że jest w postaci miksturek, ale to dość drogi "usprawniacz" rozgrywki) aktywowany np. jedynie przy schowanej broni albo gdy postać nie prowadzi walki, a więc taki, by nie wpływał na balans walk, a jednocześnie rozwiązał problem bardzo wolnego przemieszczania się bohatera

Myślę, że kamienie teleportacji dość przyjemnie rozwiązują ten problem.

[Adam27]

Dzięki za feedback :)

Grę tworzyłem na monitorze 16:10 i testowałem także na 16:9, ale nie zauważyłem problemu związanego z małym obszarem widoczności w pionie.

Co do sprintu, poza miksturkami są, tak jak powiedział ShadowDancer, kamienie teleportacyjne. Mapka jest na tyle mała, że myślę, że trochę wolniejsze poruszanie się postaci nie stanowi poważnego problemu.

Co do bugów, dzięki za zgłoszenie, wszystkie zostały naprawione.

Pozdrawiam.