Is it possible to create an emergent system in an MMO where the interactions and needs of the NPCs (in the form of independent AIs) can lead to quests on the epic scale?

I don’t know the answer to that question, but I have a few thoughts about this topic, which might help the reader to come to their own conclusions.

So, what I want to talk about here are the following:

• What makes an adventure ‘Epic‘
• Requirements and limitations of the AI system
  • The NPC AI in separation
  • The problems with numbers
  • Simulation of the masses
  • Emergent behaviour
• The place of the epic adventure in the game

I might need to slice this up a bit and write a handful of articles instead of just one, but I hope it will worth reading them.

What makes an adventure ‘Epic’

To be somewhat cheeky, let’s say that from the Lotro perspective “epic quest” means that you have to travel four times as much as with a normal quest. Jokes aside, I’d rather not use existing MMOs as role models for this. Instead, let’s find some examples in literacy.

The first one being Beowulf. He is a scandinavian hero, who fights a demon, then the demons mother to save the people of a kingdom. Later, he becomes the king, and – as an old man – sets out to fight a dragon. He slays the dragon, and gets a mortal wound. On the wikipedia it is described as “Beowulf is considered an epic poem in that the main character is a hero who travels great distances to prove his strength at impossible odds against supernatural demons and beasts.” We can now see that Turbine got it right about the travelling part, but the impossible odds part is somewhat lacking.

The second one is a fantasy story. Fantasy literacy is usually full of epic adventures and pathos, so it’s a very good starting point. In our case, the one I want to use as an example is a part of the “Nine Prices in Amber”. Sorry for the spoilers, but be assured, when reading the whole series, you will still find a lot of wonders and surprises.

So, Prince Corwin, our main character – with the help of his brother – gathers an army to conquer the castle of his father from the usurper. To get to the castle, they need to go up a stair with a thousand steps to a plateau, where every step is defended by a soldier. At this point their army is already demolished, leaving only a handful mercenaries. The two brothers and their small company begin their ascent, the mercenaries first, then Corwin’s brother. The brother then falls down from the stairs, and Corwin throws a deck of magic cards after him – which would have been his only chance of survival. Corwin alone continues the fight, and actually makes it to the plateau, where he loses the fight, and gets imprisoned. (Believe me, the original is much more enjoyable than this succinct description of the events)

Why do I consider this epic? Well, looking into it, we find common elements – impossible task, long journey – and something that is also present in Beowulf, but less apparently: a just cause. Also, in both cases, there is the notion of self sacrifice – Beowulf dies for his people, Corwin saves his brother, and because of that he gets imprisoned. On the other hand, Beowulf’s story ends well – his death is not futile, in the end he saves his people from the dragon. (Corwin’s story doesn’t end here.. but his fate gets much worse by the end of the first book.)

I was thinking about a good third example (we need three of anything, because that is the magic number) and one good example I found is the biblical story of David and Goliath. I’m pretty sure everyone is familiar with it, but still, here’s a short recap: Goliath is a giant of a man, who is challenging the army of Saul for forty days. On the fortieth day, David, a boy, goes there for some reason, hears Goliath’s challenge, and answers it. Without wearing armour, he goes out to the field, and kills the giant using a sling and a stone. No long journey this time (I knew it’s not required! ) but again, impossible challenge, just cause. No self sacrifice either, not more than what the task requires, actually. What is particularly interesting here, is that David didn’t win because of his supernatural skill or strength. Instead, he used his wit to meet the challenge. Outsmarting your enemy is a common motive in the epic stories, let’s just think about the challenges of Hercules, or Loki, the trickster.

So, let’s collect the list:

• Just cause: The hero must have a motive that is not selfish, something that serves the public well-being
• Impossible challenge: Something that is (or seems) impossible for the average woman or man.
• Long journey: If travel itself is more than just a click of a button, a long journey can be the challenge in itself.
• Self sacrifice: Failure often means death
• Need of thinking: The solution might require more than physical prowess

In the context of MMOs, putting the player in mortal danger is not as serious as it is in real life – given that in most MMOs death is not much more than a temporary annoyance. One way to solve this problem is to exchange mortality with finality: the player can try to do the quest only once, and that’s it. Failing the quest is final, there is no retry. Also, physical prowess is an in-game feature, while the thinking is done by the player, sitting in front of the computer.

(Some might argue that completing an epic quest it’s only hard for the first player, then he writes everything down on the wiki, and everybody will be able to finish the quest easily after that. In our case it’s not a valid argument, because the quest is not scripted, it is emerging from the interaction of NPCs, thus it is never the same. But even in a scripted system you can say that the first one to solve this quest will get the epic reward, everyone else will get the normal reward. This is not a perfect solution, but this problem is not the one either that I want to solve.)

To put it simply, our emergent system must be able to

• Either identify quests/tasks/jobs/adventures for which several of the above are true
• Or specifically generate quests with the above-mentioned qualities

In the next few blog post I’ll look at the AI perspective, as well as how the epic adventure can be part of the game world. Stay tuned.

(2:55:33 PM) Bond: néha elképzelem, mit szólna Angelday Józsi, ha meglátná a blogom napi látogatottságát
(2:55:45 PM) Bond: szolid felröhögésre számítanék
(2:55:49 PM) EV: [robi] mert?
(2:56:29 PM) Bond: az egész blogomon van 401 hozzászólás.. ezt sztem ő kb. 1 nap alatt produkálja 1-1 bejegyzésével
(2:56:38 PM) Bond: Today: 50 hits and 18 unique.
(2:56:57 PM) EV: [robi] és abból az 50-ből 5 te vagy?
(2:57:13 PM) Bond: hát 5 vsz én, de kb. 30 sztem robot
(2:57:42 PM) Bond: hozzátéve, hogy a rendszeres olvasóim általában readerben olvassák a bejegyzéseket
(2:57:48 PM) Bond: mindkettő, ha jól tudom

Az IT-ban elkövethető egyik legnagyobb hiba, amikor egy legacy rendszer portolásánál annak valamelyik funkcióját újratervezzük, esetleg más rendszerbe helyezzük át, és ezzel a megoldással elbukunk valamit, amit a rendszer – esetleg nem dokumentáltam – biztosított a felhasználók számára.

Vegyünk egy példát a való életből: A Google erősíti az integrációt a Reader és a Plus között, kimozgatja a redundáns szociális funkciókat a Readerből, és azt ajánlja, hogy hozzunk létre a Plus-on egy olyan kört, aminek az a neve, hogy Reader, legyenek benne ugyanazok, akik minket követnek most és amit eddig readerben megosztottunk volna, azt osszuk meg inkább oda.

Rendben, so far so good, ezzel még azt is nyerem, hogy lehet Reader Szakmai, Reader Vicces, Reader akármilyen csoportom, és nekik az adott témát osztom meg, ez fasza.

De átfogalmazom: ÉN mondom meg, hogy kinek osztok meg mit. Eddig az volt, h ha valakinek tetszett a stílusa meg a megosztásai, akkor elkezdtem követni (ilyen volt pl. Martina). Mostantól ez úgy megy, hogy elkezdhetek neki kuncsorogni, hogy “légyszi vegyél fel a megosztó körödbe”. Persze, látom, amiket megoszt publikusra, de a reader körét már nem, amig fel nem vesz oda.

A másik probléma a chaff. Egy csomó ember megoszt egy csomó szemetet. Státuszt updateelnek arról, hogy kibe szerelmesek, mit olvasnak, milyen finom volt a tea, mi az aktuális politikai állás. Ez engem nem érdekel. Én arra vagyok csak kíváncsi, hogy milyen érdekes cikkeket olvastak. Ha megtehetném, csak arra iratkoznék fel, amit a reader csoportjának osztott meg, de ezt én ugye nem tudom.

Még reménykedem benne, hogy ez valakinek a Google-nél is eszébe jutott – elég sok okos ember dolgozik ott, hátha – de kicsit félek, hogy nem.

A Turbine, mostani kedvenc MMO-m, a Lotro gazdái, egy új contestet hirdetett meg: Küldjünk be képeket arról, hogy hol találkoztunk a fehér kézzel.

Sajnos a contest csak az USA-ban él, de azért vettem a fáradtságot, és összedobtam egy pályázatot, ha más nem, az ő szórakoztatásukra. Úgy sejtem, ha ott élnék, akkor is lennének jogi problémák körülötte, de remélem, abból nem lesz baj, ha itt a blogon leközlöm.

Ha mégis, akkor számítsatok rá, hogy el fog innen tűnni.. A megtekintéshez kattints (RSS-ben meg automatikusan megjelenik)

more…

Néhány hónappal ezelőtt mondtam Grétának, hogy nem veszek Kindle 3-t, inkább megvárom a Kindle 4-et, azt viszont szeretnék. Ok, mondta ő, és ennyiben maradtunk. Tovább használtam a pár éves Sony PRS-505-t, néha morcogtam, hogy milyen lassú, és vártam, h legyen Kindle 4.

Lett. Pontosabban lett Kindle Light (nem ez a neve, de tulajdonképpen..), Kindle Fire, meg ígéret a Kindle Touchra. A Fire-t alapból kilőttem, mert nincs szükségem tabletre, aztán hosszan gondolkoztam, hogy mi legyen. A touchos ötlete tetszett, de azt mondták, IR-t használ a touchoz, ami egy kicsit gyanús nekem (úgy sejtem, durván hazavágja a készenléti időt), ráadásul még csak előrendelhető vagy egy hónapig. A Light jó darab lenne, és úgy is voltam vele, hogy veszek egyet, de aztán azt olvastam egy review-ban, hogy a cheap az mindenhol jól látható (avagy olcsó húsnak igen híg a leve is), és a kindle 3-hoz képest erős visszalépés ez a darab. A Kindle 3 meg Kindle 3, azt mondtam, h nem veszek, ugyebár..

Jelenleg halogatok. Inkább nem veszek Lightot, hanem megvárom a Touch-ot, elolvasom a reviewkat, meglátom, hogy tényleg olyan hosszú-e a készenléti idő, mint mondják (és ha igen, nincs-e cserébe egy olyan probléma, h a touch lemegy standby-ba, és lassan ébred..) és úgy általában, mit mondanak róla az emberek. És persze megnézem, lesz-e Kindle DX európában, esetleg Kindle DX light..

Meglátjuk. Lehet, hogy ez a generáció sem ugorja meg azt a lécet, ami a Sony lecseréléséhez kell. Lehet, hogy várok még egy generációt, vagy kettőt, amíg megjelennek az e-inkes színes olvasók.

Halogatni szabad

Az elmúlt hetekben pályafutásom egyik legérdekesebb feladatával foglalkoztam a munkahelyen. Konkrétumokat nem akarok írni, de egy Amazon-os példával szemléltetem, miről is van szó.

Tegyük fel, hogy az Amazon be akar vezetni egy újféle rendezést: Ha a felhasználó úgy keres, hogy nem specifikálja, mi szerint akar sorbarendezni, akkor egy relevancia szerinti sorbarendezést kap.

Az első feltétele ennek, hogy meghatározzuk, a user milyen szegmens része: Ha korábban főleg technikai kütyükre keresett, akkor vsz. fiatal férfi, míg ha babaruhákat és melltartót vásárolt, akkor jó eséllyel családanya.

A következő lépés annak a meghatározása, hogy melyik szegmens mit szeret és mit nem. Ha például mobiltelefonokat nézünk, akkor a nerd-öt technikailag orientált férfit jobban érdekli a felbontás, mint a készenléti idő, míg a családanya inkább egy ütés, por és víz (nyál) álló telefont értékel, ami túléli a gyerekek támadását.

A fentiek meghatározása után elkészítjük az első komponenst, ami minden szegmenshez meghatároz egy ratinget az adott dologra. Pl. minden egyes telefonra megmondja, hogy az első szegmensnél a felbontásra kap X pontot, az ütésállóságra meg Y pontot, így az össz ratingje X+Y, és ez így tovább a többi szegmensre. Utána már csak annyi dolgunk van, hogy ha valaki rákeres a mobiltelefonokra, akkor – ha kb. tudjuk, ő milyen szegmensben van – akkor a találati listát az adott szegmenshez kapcsolt rating érték alapján csökkenő sorrendbe rendezzük (feltételezve, h a nagyobb rating a jobb).

Eddig nem túl bonyolult a dolog. Itt jön azonban a csavarás: Mi van akkor, ha a user – pl. amiatt, mert a héten minden HTC telefonra 10% leértékelés van – hirtelen csak HTC-ket kezd el látni a találati listában? Ez számunkra nem olyan kívánatos, mert mi azt szeretnénk, ha a felhasználó sokfélét látna ott – ugyanis simán lehet, hogy az adott felhasználó titokban utálja a HTC telefonokat, és tulajdonképpen Samsungot szeretne, de ezt nem tette bele a keresésbe valamilyen okból. Ez az, amit nálunk shuffling-nek hívnak, azaz keverésnek: Fogjuk a találati listát, és átrendezzük úgy, hogy a találatok változatosak legyenek.

Az első megfigyelés az, hogy ezt a keverést mindenképpen a találati listán kell megcsinálnunk, mivel ez keresésenként változik, és látatlanban nem tudjuk előre átrendezni a hasonló találatokat. A felhasználói szokásokat ismerve az is elég valószínű, hogy nem kell az összes találatot átrendeznünk, hiszen a felhasználó ritkán néz meg két oldalnál többet. Az is fontos, hogy ha a keresés pl. egy adott gyártóra történt (mondjuk Samsung) akkor ne erőlködjünk azon, hogy a gyártók szerint is sorbarendezzünk. Hasonlóképpen, ha a listának mondjuk 95%-a ugyanaz a gyártó, akkor szintén értelmetlen a keverés. Továbbá, feltételezhetjük, hogy a vásárló számára értékesebb az, ha minél változatosabb a lista, tehát azt is jó lenne elkerülni, hogy kétféle dolgot váltogassunk (HTC, apple, HTC, apple), ha a listában van mondjuk Samsung és Motorola is.

Van itt azonban egy érdekes kérdés: Ha már 1x berendeztük aszerint, hogy ezek az elemek milyen jók a usernek, akkor most nem vágjuk ezt teljesen felül azzal, hogy megkeverjük? A válasz kettős: Igen, alaposan megbolygatjuk a sorrendet, és nem, nem teljesen vágjuk felül. Lehetőség szerint úgy kell rendeznünk, hogy a találatok az eredeti sorrendhez a lehető legközelebb maradjanak. Ennek az eszköze lehet az algoritmushoz hozzácsapott maximum mélység, ami arról szól, hogy megmondjuk, hogy az átrendezendő elemekre – ami mondjuk a találati lista első 100 eleme – definiálunk egy %-ot, hogy ennél messzebbről ne rángassunk fel elemet semmiképp.

Erre alkottam egy algoritmust, amelyre a következő dolgok igazak: A rekord 1 mezőjére vizsgál, aszerint ha 2 azonos rekordot talál, akkor a találati listából maximum a meghatározott mélységen belül elővesz egy olyat, ami eddig arányosan a legritkábban volt használva. Ugyanolyan ritkaság esetén az eredeti halmazban gyakrabban előforduló elemből vesz. Az algoritmus szekvenciális, a feldolgozott elemeket már nem változtatja, csak a még keveretlen listát.

Hogy néz ki a végeredmény? 15 elemre, 20%-os mélységgel (max 3 elem) az alábbi előfordulásokkal az alábbi eredményeket kapjuk: (bal oldalon az eredeti lista, jobb oldalon a kevert)

Value distribution:

HTC     : 60%
Apple   : 13%
Samsung : 26%

     Index   Make      Index   Make
      ------------------------------
       1, Samsung        1  Samsung
       2,   Apple        2    Apple
       3,     HTC        3      HTC
       4,     HTC        6  Samsung
       5,     HTC        4      HTC
       6, Samsung        5      HTC
       7,     HTC       10  Samsung
       8,     HTC        7      HTC
       9,     HTC       11    Apple
      10, Samsung        8      HTC
      11,   Apple        9      HTC
      12,     HTC       13  Samsung
      13, Samsung       12      HTC
      14,     HTC       14      HTC
      15,     HTC       15      HTC
Hosszabb listákra nyilván sokkal hatékonyabb, de szerintem így is látszik a különbség.