"Engine" pro skriptovatelné RPG

[Peta]

Zdravím,

připravuju si svůj projekt a jsem momentálně v situaci kdy si designuju jak to bude celé vypadat. Pokud budu mluvit v termínech UML, tak jsem u class a component diagramu. Vůbec není teď důležité v čem to bude implementované, o čem to bude ani nic podobného, kdyby však někdo chtěl přece jen vědět tak finálně to napíšu v C# a využiju XNA. (tolik mých pět centů k tématu z jiného threadu: proč nepoužíváme frameworky ).

Takže a kde je můj "problém". Chci aby bylo možné drtivou většinu událostí v mém světě popsat pomocí skriptů. S tím že budu mít skripty které se budou provádět jednou za čas (řekněme obchodníci budou jednou denně obnovovat zboží ve svém krámě) nebo okamžitě. Taky ale potřebuju skripty, které budou po spuštění závislé na dění ve světě - tady to začíná být komplikovanější takže vysvětlím na ilustrativním příkladu: hráč vykřikne nadávku na osobu stojící na druhé straně obrazovky. Spustí se skript kdy má osoba dojít k hráči a dát mu pěstí. Jde mi o to, že skript musí počkat, až osoba dojde k hráči a až pak mu dát pěstí. Plánuju mít nějakou třídu "SkriptExecutor" která bude skripty provádět - takže samozřejmě by se mohla zablokovat a neprovádět další příkazy dokud nedostane od objektu nějak oznámeno, že už provedl chůzi a může se pokračovat. Jenže se samozřejmě může stát že bude potřeba spustit jiný skript než tam ta postava dojde a zabržděný "SkriptExecutor" by to nedovolil. Další věc je, že bych rád, aby se na "reakci objektu" čekalo jen určitou dobu. Opět příklad: hráč je filuta a cestu k sobě zaminuje. Osoba na minu šlápne a umře, takže nikdy k němu nedojde a nebude se konat rvačka.

Snad je můj záměr pochopitelný Několik nápadů jak problém vyřešit mám (třeba udělat každý skript svým vlastním exekutorem), ale vše má své nevýhody a něco mi nepřijde moc elegantní. No a teď s čím chci poradit - tak pokud někdo ví jak tohle dobře implementovat, rád si ho vyslechnu a podle dobré rady se zařídím. Nicméně je tu i možnost že to A) dost dobře nejde B) je to příliš náročné. Je jasné že v obou případech se budu muset něčeho vzdát - osekat svůj záměr/featury RPG. To není problém, nechci samozřejmě strávit rok implementací super-mega skriptovacího enginu. Radši se vzdám krásných featur, ale pak si aspoň budu jist že to zvládnu naimplenetovat v rozumném čase a bude to fungovat tak jak se naplánovalo.

Za jakékoliv podnětné nápady díky. Pokud máte doplňující otázky, sem s nimi, je možné že jsem zapoměl zmínit něco podstatného.
_________________
Když je Ti smutno, otoč se tváří ke slunci a všechny stíny padnou za Tebe.

[MD]

A Krkal C by se ti nehodilo? Asi to umi vse, co od toho chces, ale je to stale jeste ve vyvoji, takze bys byl takovy prerelease tester. Nech si ale poradit i neco jineho, at se mas mezi cim rozhodovat.

http://www.ceske-hry.cz/forum/viewtopic.php?t=1011
_________________
- play with objects - www.krkal.org -

[OndraSej]

Peta> Asi bych popřemýšlel o rozdělení skriptů na dvě skupiny - jednak na skripty jako krátké prográmky a jednak na skripty jako posloupnosti akcí pro postavičky (de facto něco jako krátké scénáře).

Rozdíl jasný:
- první typ by dělal takové ty krátké věci jako doplňování zboží u obchodníků, testoval, jestli došlo k určité události a hlavně spouštěl a jinak obhospodařoval ty druhé. Šly by psát v nějakém rozumném programovacím jazyce (co je rozumný jazyk nechám na tobě, já bych bral LISP )
- druhý typ by byla v zásadě jen posloupnost "dlouhotrvajících" ale primitivních akci typu "jdi na pozici ...", "jdi k postavě/objektu ...", "řekni ...", "bojuj s ...".

Výhoda tohohle řešení je, že skripty druhého typu jde celkem jednoduše v prakticky libovolném místě přerušit (aniž by ses musel bát, že něco rozbiješ), zatímco skripty prvního typu budou relativně krátké a můžou běžet celé bez přerušení (takže je nebude potřeba složitě synchronizovat a řešit dlouhotrvající příkazy). S tím, že u skriptů prvního typu by mělo být možné nasadit na různá místa jako triggery skripty prvního typu.

No a nebo použij Krkal C, UnrealScript, nebo nějaký jiný jazyk, co už tohle má vyřešené. A přinejmenším s tím Unrealem by sis ušetřil práci i na grafickém engine
_________________
http://trionteam.net

[Peta]

Mě napadlo i zkusit třeba jazyk LUA, ale pořád koketuju s myšlenkou navrhnout si to radši jednodušší a nakódit si to z větší části sám v práci mě jeden kolega navedl na docela zajímavou myšlenku (pojmout celý problém jako AI objektů (svět je taky objekt)). Zkusím to promyslet vypadá to docela dobře, když si trošku poupravím vyžadované featury.
_________________
Když je Ti smutno, otoč se tváří ke slunci a všechny stíny padnou za Tebe.

[MD]

Ja jeste doplnim par veci k tomuhle temetu. Mam zkusenosti s tim, jak to funguje v Krkal C, tak treba se to bude Petovi hodit (nebo nekomu jinemu)

Zatim jsem se setkal s dvema pristupy jak tohle resit:
1) Dlouho zijici metody. Do skriptu muzete davat prikazy typu sleep(60s), volani typu "DojdiNaMisto", ktera se vrati az po provedeni cinnosti, ci "CekajAzSeStane(obj)". A kde jsem to videl: Simula, Unreal Script, WME

2) Synchronizace pomoci udalosti. Motody musi koncit v co nejkratsim case (temer okamzite). Zadny sleep, zadne cekani na cokoli uvnitr metod neni povoleno. Misto toho system zasila zpravy (udalosti), kdyz se neco stane (jednotka dojde na misto urceni) a objekty mohou udalosti obslouzit. Videl jsem v: Krkal C, Game Maker, windows API. Zpravy mohou posilat i metody hernich objektu, pricemz si urci cas doruceni. Teda metoda posle zpravu, ktera se ma dorucit za 100ms, zprava se v systemu zaradi do fronty zprav a volajici metoda pokracuje ve sve cinnosti, ukonci se a pak za 100ms se pripadne vyvola obsluha one udalosti. Syntaxe Krkal C tohle umoznuje delat primo, jinde to vetsinou museji obchazet pres objekt Timer. (Pozn. ony i systemy v 1) pouzivaji udalosti, jen to na nich neni 100% zalozeno)

To co psal OndrSej o rozdeleni metod (scriptu) na kratke a dlouhe je dobrej postreh. Myslim ze treba Unreal Script tohle rozlisuje a dokaze se chovat k jednotlivym typum metod ruzne. Proste o tech dlouhych metodach je potreba vedet a obcas je potreba je killnout (kdyz prestanou mit platny target, kdyz se okolni situace zmeni, umrou objekty). V Krkal C jsou metody vzdy kratke. To co je dlouhe, jsou zpravy, ktere cekaji ve fronte na svuj cas. Zprava je nezavisla entita, pamatuje si odesilatele, adresata a seznam argumentu. Opet ve svete se muze stat, ze zprava prestane mit smysl a je treba se s tim umet nejak vyporadat:

-Adresat umre nebo nema implementovanou potrebnou obsluhu zpravy - tady je to jednoduche: system proste zpravu nedoruci.
-Adresat muze zpravu odmitnout na zaklade toho, ze uz je ve stavu, ve kterem zprava pozbyva smyls. Pr.: Zprava "OtevriSe" je zbytecna pro objekt Dvere, ktere uz jsou otevrene.
-Objekt muze pozadat o killnuti zpravy, ktera ztrati smysl. (Krkal umoznuje killovat konkretni zpravu nebo zpravu patrici do nejake mnoziny) Pr. Urazim NPC, to se rozhodne ke me dobehnout a dat mi do drzky. Rekneme, ze beh je automaticky uspesny a vzdy bude trvat 1s. Pak muzeme odstartovat beh a zaroven si poslat zpravu ZmlatHo, ktera se ma dorucit za 1s. Ale, kdyz se stihnu behem te sekunty omluvit, tak je vhodne zpravu killnout. Tohle je bezpecnejsi, nez nastavovat stavy, protoze ja se mohu omluvit a hned pote NPC opet urazit. Pak by byly na ceste dve zpravy a obe by dorazily, takze NPC by me zmlatila i za to prvni, prestoze uz jsem se omluvil.

A ted co s tim behem? Je jasne, ze beh se muze protahnout, ci neskoncit vubec (vykouzlim do cesty barieru, teleportuju se mimo dosah). Pak je asi na miste nejake chytrejsi rozhodovani pomoci stavu. Takze si zapamatuju, ze jsem poradne nasranej. Muzu si i poslat zpravu (traba s casem 1minuta), ktara zpusobi, ze se trochu zklidnim. Dale v nejakych vyznamnych momentech se budu rozhodovat podle okolni situace a podle stavu, co udelam. Treba kdyz skonci onen beh a ja mam sveho nepritele nadosah, muzu se rozhodnout, ze mu dam pesti. Provede se to a ja opet vyhodnocuju. Tentokrat zjistim ze mi to nepritel pekne tvrde vratil, takze jsem jeste vice nasranej, ale musim si zachranit kejhak, takze se dam na utek...

Tohle se musi programovat opatrne, aby tam nebyly neprerusitelne akce. Typicky: utok, ktery nema zadny vysledek, spis naopak to vypada, ze velmi rychle umru, ale ja utok neprerusim, neutecu.

V zasade jsou oba pristupy (1) dlouhe metody vs 2) zpravy) ekvivalentni. Ja mam zpravy radsi, protoze jim vice rozumim, zda se mi to prehlednejsi a deterministictejsi. Kdyby 1) napriklad bylo opravdu implementovano pomoci threadu (coz zdaleka nemusi), tak nikde neni zaruceno, ktery thread se dostane ke slovu drive a co se stane prvni. Nechteny nedeterminismus je nejvetsi zlo A dalsi zla :
- Deadloky. U 1) mohou nastat klasicke deadlocky kvuli synchrionizaci (1 ceka na 2 a zaroven 2 ceka na 1). I u 2) mohou vznikat deadlocky diky spatne funkci stavu. Treba se rozhodnu otevrit dvere a behem teto akce odmitnu reagovat na cokoli jineho. Jenze, nez to stihnu udelat, tak nekdo vyhodi ony dvere do vzduchu a postavicka je vecne zasekla...
- Nekonecne cykly. I kdyz programuju sebelepe jsou sitace, kdy cyklum nezabranim. Pr. mam naslapnou podlahu, ktera muze neco udalat. V editoru ji nastavim tak, ze pri stlaceni odstrani konkretni kamen. Pri uvolneni ho zase vrati. A co se stane, kdyz ten kamen nastrkam nad tu podlahu? Stlaci se, kamen zmizi, uvolni se, kamen se objevi, stlaci se... Reseni je rozlozit cyklus do casu. Tedy objeveni a mizeni kamenu provedu s urcitym mirnym zpozdenim, tim padem se mi nezasekne cela hra.

Jeste implementacni poznamka: Pokud suspendnu dlouho trvajici metodu (sleep), musim si zapamatovat jeji stack. U zprav si zapomatovavam argumenty zprav, ty jsou dane volajicim a byva to mene dat (neni tam vsechen ten balast ze stacku). V Krkalovi mam diky zpravam mezi takty (a obcas i jindy) naprosto prazdny stack. Tohle vyhodna situace se da vyuzit jako vhodny okamzik k ulozeni hry nebo ke spusteni garbage collectoru.
_________________
- play with objects - www.krkal.org -

[adragon]

ja muzu poskytnout nahled, jak se tyto situace resi v agentovych technologiich.

Agent je program, ktery zapouzdruje vnitrni reprezentaci sveta a nejake chovani a s ostatnimi agenty / prostredim komunikuje pomoci zprav. Agenti se znaji pomoci identifikatoru a ne pres adresy v pocitaci.

Zpravy jsou asynchronni, nemusi byt dobredu znam prijemce zpravy. O doruceni zprav se stara specialni agent, ktery je znam agentovemu systemu a u nejz si mohou agenti zaregistrovat odebirani zprav.

Aby se agenti nemuseli dopredu napevno znat, existuje v prostredi dalsi agent (Zlute stranky), kde agenti inzeruji jake poskytuji sluzby a mohou se domluvit na nejake spolecne akci.

Prostredi lze realizovat take agentem - zmenu stavu prostredi lze oznamit zpravou stejne tak agent prostredi muze menit svuj stav na zaklade zprav akteru.

Perzistence agentu (napr. pro ulozeni hry)
slaba - ulozi se stav agenta a uktualni chovani se spusti odznova
silna - agent se obnovi presne v tom stavu jako driv bezel.

Agentovy system
software, ktery poskytuje zakladni funkce pro vytvareni, spravu a komunikaci agentu. Muze byt distibuovan na vice pocitacich i platformach. Standard pro vytvareni techto systemu je FIPA

Reseni v agentove architekture JADE
Agent je objekt, ktery je spousten ve vlastnim vlakne a muze mit nekolik chovani.

Chovani je to same jako drive zminene "dlouhe metody", sklada se z nejakeho kodu, ktery se muze periodicky opakovat. Kod chovani by mel byt kratky, protoze agent muze mit vice chovani spustenych zaroven a v ramci jednoho vlakna je to reseno kooperativni multitaskingem. Chovani lze ruzne zretezovat (paralelni chovani, sekvencni, stavovy automat)

Bezici chovani muze ovlivnovat ostatni chovani agenta.

Osobne si myslim, ze je vhodne se timto inspirovat, kdyz je to vysledek let vyzkumu . Komunikaci bych resil zpravami. Vice vlaknum bych se spis vyhnul a predpokladal ze chovani bude kratke a tedy pujde zavolat postupne chovani vsech agentu. Chovani by melo mit moznost cekat nejakou dobu.

Zminovany problem bych resil tak, ze postava by byla implementovana agentem a mela by jedno chovani, ktere by cekalo na urazku, jakmile by takovou urazku zaslechla spustilo by se sekvencni chovani (prijit k postave / namlatit ji) a aktivovalo tez chovani reagujici na omluvu. Agent by mohl mit vnitrni stav, ktery by pri druhe omluve uz nereagoval. Zabiti agenta vede k tomu, ze se prestane provadet jeho chovani - bez problemu. Napadani agenta v prubehu chovani nekym jinym muze byt vyhodnoceno jako prechod do jineho stavu a je jen na agentovy zda si bude pamatovat predchozi urazku a po konci reakce se k ni vrati.

[MD]

Dotaz k agentum: asynchronni zasilani zprav znamena, ze nikde neni definovano, kdy k doruceni zpravy dojde? (In process zprava putuje podstatne rychleji nez zprava na vzdaleny pocitac). Je to agentove prostredi nejak taktovano? Je tam rizen globalni "cas"? (Pro hry je dulezite aby veci trvaly spravne dlouho)
_________________
- play with objects - www.krkal.org -

[adragon]

[Sosarian]

no myslím že na tohle jde využít C#, jestli ti nevadí že to není přimo scriptovací jazyk (tyhle scripty pak přez CSharpCodeProvider zkompilovat), jestli teda jde jen o to aby engine byl nějak oddělen od toho co se ve hře děje
veskutečnosti nechápu proč to nedělají všichni, takže tam bude asi nějakej zádrhel

když uděláš objekty pěkně aby se na nich volalo spoustu události typu
Objekt: PřiStoupnuti(Člověk kdo)
Člověk: PřiZaslechnutí(Člověk kdo, string text)

a AI bude fungovat tak že mu akorát dáš nějakou akci do seznamu akcí typu JdiNaMistoXY : Akce

pak teda ještě nějakej mechanismus na spouštení timerů


tak to možná bude dělat to co chceš, respektive takhle nějak to řeší RunUO (emulátor pro Ultimu Online, a zvládá pouštět dost komplikovaný "scripty" pro dost velkej počet hráčů, předpokládám že tobě stači jeden hráč)

[Peta]

Pěkná diskuze, díky za ni

2MD: pěkný rozbor - víc se mi zamlouvají taky ty události/zprávy... působí to přirozeněji a "objektověji" (Smalltalk). Nakonec jsem se ale rozhodl pro trošku jiné řešení, viz dále.

2Adragon: Pro mě jsou agenti zdá se trošku overkill možná to jde udělat i relativně jednoduše, ale vzhledem k tomu že s tímhle přístupem jsem se nesetkal tak pro mě nebude nejlepší volba se to "učit" naostro při vývoji

Jinak abych teda uvedl řešení kterým se asi vydám: v kostce jde o to, že každý objekt bude mít přiřazený skript (patrně v jazyku LUA) ve formě AI založené na stavovém automatu + pár vnitřních proměnných. To mi umožní mít tam ty "časované" i okamžité události a dovolí i docela slušnou variabilitu chování, aspoň doufám. Až se do toho ponořím hlouběji a promyslím to důkladně určitě se o výsledek podělím Momentálně ale nad tímhle nebádám, rýsuje se ještě jiný projekt který mě zaujal více (že Augi ).
_________________
Když je Ti smutno, otoč se tváří ke slunci a všechny stíny padnou za Tebe.