Dialogi w grze 2D RPG

Cześć!
Pracuję nad systemem dialogów do mojej gry 2D RPG i mam pewien problem. Chciałbym zaimplementować dialogi, ale nie jestem pewien, jaki format najlepiej sprawdzi się w tego typu grze. Rozważam różne opcje, ale nie znalazłem w internecie żadnych przykładów, które by mnie satysfakcjonowały. Czy ktoś mógłby doradzić, jakie podejście byłoby optymalne do tworzenia dialogów? Zastanawiam się nad tym, czy użyć prostych plików tekstowych, czy może spróbować czegoś bardziej zaawansowanego. Jakie są Wasze doświadczenia i co polecacie?
Poniżej zamieszczam kod z którego obecnie korzystam.

class DialogueOption {
public:
	std::wstring text;
	short nextDialogueID;

	DialogueOption(int nextDialogueID, std::wstring text) {
		this->nextDialogueID = nextDialogueID;
		this->text = text;
	}
};

class Dialogue {
public:
	short id;
  	std::wstring text;
	std::vector < DialogueOption > options;

	Dialogue(short id, std::wstring text) {
		this->id = id;
		this->text = text;
	}

	void addOption(short nextDialogueID, std::wstring text) {
		options.push_back(DialogueOption(nextDialogueID, text));
	}
};

Jakkolwiek je zaimplementujesz, to koniecznie dodaj szybki skip.

A na początek może zobacz jak działają dialogi w RPG Maker:

Najprościej byłoby obejrzec jakiś tutorial modderski z RedKita albo innego Creation Engine i zobaczyć jak oni to zaimplementowali.

tBane napisał(a):

Czy ktoś mógłby doradzić, jakie podejście byłoby optymalne do tworzenia dialogów?

To zależy głównie od wymagań projektowych — Ty robisz projekt w formie hobby, więc możesz eksperymentować.

Najpierw powinieneś określić to jak te dialogi mają być przeprowadzane, czyli czy dialog ma być liniowy, czy interaktywny, z możliwością rozgałęziania (wybranie kolejnego dialogu na podstawie wyboru gracza, np. odpowiedzi na pytanie enpeca). Po drugie, jeśli dialog może się rozgałęziać, to czy dana gałąź ma być zawsze możliwa, czy muszą być spełnione konkretne wymagania (np. gracz musi posiadać jakiś przedmiot). I wreszcie, czy dany dymek dialogowy ma być dostępny zawsze, czy tylko określoną liczbę razy (np. tylko raz, albo tylko do momentu wykonania jakiegoś questa).

To wszystko (a nawet więcej) najpierw należy określić, zanim zacznie się klepanie kodu.

Jeśli chodzi o dane dialogów, to pojedynczy dymek powinien być opisany kilkoma danymi:

• unikalne ID, najlepiej liczbowe,
• tekst do wyświetlenia na ekranie.
• ID kolejnego dialogu, po zakończeniu aktualnego (0 jeśli to jedyny/ostatni dymek).

Jeżeli system dialogów ma być interaktywny, to trzeba mieć dane na temat odpowiedzi i możliwych rozgałęzień:

• liczba określająca możliwe odpowiedzi (0 jeśli to dialog liniowy),
• tablica odpowiedzi, w której każda komórka zawiera:
  • tekst odpowiedzi do wyświetlenia na ekranie,
  • ID kolejnego dialogu, po wybraniu tej opcji (0 jeśli to jedyny/ostatni dialog).

To jest minimum, ale w zależności od tego jak zaprogramujesz system dialogów, możliwe, że będziesz potrzebował więcej informacji. Aby nie utrudniać sobie zabawy (w końcu robisz to hobbystycznie), dane na temat wszystkich dialogów możesz trzymać w pliku tekstowym — najlepiej w znanym formacie (np. JSON, bo ma prostą składnię i wspiera drzewiastą strukturę). Taki plik łatwo możesz modyfikować.

Jeśli masz zamiar (a zapewne tak jest) wykorzystać interaktywne dialogi, to od razu zastanów się nad tym, jak ten system zaimplementować, aby z jednej strony silnik nie tylko potrafił te dymki wyświetlać, ale też reagować na wybory użytkownika (czyli wykonać konkretny kod po wybraniu przez użytkownika konkretnej opcji w dialogu). Dla przykładu, enpec pyta gracza czy chce przedmiot, ten wybiera opcję Yes i enpec mu ten przedmiot daje i ew. kontynuuje dialog — w momencie, w którym gracz wybiera opcję Yes, silnik wywołuje handler wybrania opcji tego dialogu i dodaje przedmiot do ekwipunku.

Drugi przypadek to walidacja — czy dialog o zadanym ID w ogóle może być wyświetlony. Dla przykładu, chcesz zrobić wymianę przedmiotu z enpecem. Enpec może zapytać gracza czy chce się zamieć, ale może to zrobić tylko jeśli gracz faktycznie ma konkretny przedmiot w ekwipunku. Jeśli gracz nie ma przedmiotu do wymiany lub już tej wymiany dokonał, to dialog dotyczący tej zamiany nie może być wyświetlony.

Potrzebujesz więc dwóch typów handlerów. Pierwszy dotyczy sprawdzenia czy dany dialog może być otwarty (czy są spełnione warunki do jego wyświetlenia) oraz drugi, do obsługi wyboru odpowiedzi przez gracza (reakcja na wybór gracza).

Jeśli skorzystasz z systemu dialogów interaktywnych, to ich obsługa może być hardkodowana, pół-hardkodowana lub zupełnie niezależna od silnika:

1. Hardkodowany — dane wszystkich dialogów oraz ich handlery zaimplementowane są w całości w kodzie źródłowym. Wszystkie dymki dialogowe oraz wszystkie handlery są znane w trakcie kompilacji.

2. Pół-hardkodowany — dane dialogów trzymane są poza kodem źródłowym (np. w pliku tekstowym), ale kod obsługi odpowiedzi gracza (reakcji na wybór odpowiedzi) jest zaimplementowany w silniku. W ten sposób ułatwisz sobie implementację, a dzięki temu, że dane dialogów są w zewnętrznych plikach, łatwo będziesz mógł zapewnić wsparcie języków interfejsu (jeden plik tekstowy to zestaw dialogów dla danego języka naturalnego — jeden plik dla angielskiego, jeden dla polskiego, jeden dla japoństkiego itd.).

3. Niezależny — dane wszystkich dialogów znajdują się w zewnętrznych plikach, a handlery odpowiedzi znajdują się w plikach skryptów (np. Lua). To jest najlepsze rozwiązanie, bo w pełni elastyczne i pozwala na modyfikowanie dialogów w dowolnym momencie, również w trakcie działania gry. Minusem jest masa pracy do wykonania, bo trzeba silnik gry przystosować do obsługi skryptów.

Jeśli nie interesuje Cię w pełni profesjonalne i elastyczne rozwiazanie (czyli skrypty obsługi dialogów), to w zależności od tego czy planujesz wspierać języki interfejsu (angielski, polski, niemiecki itd.), wybierz pierwsze lub drugie rozwiązanie. Pamiętaj też, że wsparcie wielu języków interfejsu oznacza, że ta sama konwersacja może się składać z różnej liczby dymków. Wszystko dlatego, że np. ta sama linijka tekstu w języku angielskim wymagać będzie pięciu słów, ale już w języku polskim wymagać będzie dziesięciu i trzeba ją będzie rozbić na dwa dymki. Będziesz miał większą ilość ID poszczególnych dymków, ale tę samą ilość ID możliwych odpowiedzi, więc wystarczy tylko jeden zestaw handlerów.

A co z handlerami odpowiedzi? Możesz to zrobić w formie lookup table. Każda komórka takiej tablicy zawierać będzie pointery na funkcje obsługi — jeden sprawdzający czy dymek może być wyświetlony, drugi z kodem reakcji na wybór użytkownika (null jeśli dialog nie wymaga walidacji i/lub tylko wyświetla tekst, bez opcji wyboru). Ale możesz to też zrobić w formie jednej funkcji, czyli wszystkie dialogi obsłużyć w jednym miejscu. Tak zrobił twórca Undertale, czyli zaimplementował gigantyczny blok switch dosłownie z tysiącami caseów.

Kiedy już zrobisz to wszystko, dopiero wtedy zajmij się interfejsem, czyli tym jak ma dymek wyglądać na ekranie, jak go renderować, jak go animować, jak go obsługiwać urządzeniami wejścia itd.