Buďme upřímní:všichni rádi hrajeme hry, zejména na našich počítačích. Dokud se internet nerozšířil, většina z nás hrála počítačové hry sami, obvykle proti protivníkům s umělou inteligencí. Byla to zábava, ale jakmile jste si uvědomili, jak fungují herní mechanismy, hra ztratila většinu svého kouzla.
Rozvoj internetu posunul hry online. Nyní můžeme hrát proti lidským protivníkům a otestovat své schopnosti proti jejich. Už žádné zběžné hraní!
Pak se objevily masivní online hry pro více hráčů (MMO), které vše změnily. Tisíce hráčů se ocitly ve stejných herních vesmírech, soutěží o zdroje, vyjednávají, obchodují a bojují. Aby takové hry mohly být možné, byla zapotřebí struktura databáze, která by mohla uchovávat všechny relevantní informace.
V tomto článku navrhneme model, který zahrnuje nejběžnější prvky, které se v MMO hrách vyskytují. Probereme, jak jej používat, jeho omezení a možná vylepšení.
Úvod do datových modelů pro MMO hry
Dnes existuje spousta velmi populárních MMO her a zahrnují všechny druhy scénářů. Zde se zaměřím na strategické hry jako Ogame , Travian , Sparta :War of Empires a Imperia Online . Tyto hry jsou více o plánování, budování a strategii a méně o přímé akci.
MMO hry se odehrávají v různých vesmírech, jsou vizuálně odlišné a využívají více či méně odlišné herní možnosti. Přesto jsou některé myšlenky stejné. Hráči soutěží o místa, bojují o ně a vytvářejí spojenectví s ostatními hráči (a proti nim). Budují struktury, shromažďují zdroje a zkoumají technologie. Staví jednotky (jako jsou válečníci, tanky, obchodníci atd.) a používají je k obchodování se spojenci nebo k boji s protivníky. To vše musí být podporováno v naší databázi.
Tyto hry můžeme považovat za online deskové hry s mnoha indexovanými čtverci. Každý čtverec může mít mnoho různých akcí spojených s ním; některé akce budou zahrnovat více čtverců – např. když přesouváme jednotky nebo zdroje z jednoho místa na druhé.
Databáze je rozdělena do pěti hlavních oblastí:
Players / UsersAlliancesLocations and StructuresResearch and ResourcesUnits
Zbývajících sedm neseskupených tabulek souvisí s jednotkami a popisuje pozici jednotek a pohyby ve hře. Na každou z těchto oblastí se podíváme mnohem podrobněji, počínaje Hráči a Aliance .
Hráči a aliance
Hráči jsou bezpochyby nejdůležitější součástí každé hry.
player tabulka obsahuje seznam všech registrovaných hráčů účastnících se herní instance. Uložíme uživatelská jména, hesla a obrazovková jména hráčů. Ty budou uloženy v user_name , password a nickname atributy resp.
Noví uživatelé budou muset při registraci uvést e-mailovou adresu. Bude jim vygenerován a zaslán potvrzovací kód, na který odpoví. Aktualizujeme confirmation_date atribut, když uživatel ověří svou e-mailovou adresu. Tato tabulka má tedy tři jedinečné klíče:user_name , nickname a email .
Pokaždé, když se uživatel přihlásí, je do login_history stůl. Všechny atributy v této tabulce jsou samozřejmé. logout_time je specifický. Může být NULL, když je aktuální relace uživatele aktivní nebo když uživatelé ukončí hru (bez odhlášení) kvůli technickým problémům. V login_data atribut, uložíme přihlašovací údaje, jako je geografická poloha hráče, IP adresa a zařízení a prohlížeč, který používá.
Většina MMO her nám umožňuje spolupracovat s ostatními hráči. Jednou ze standardních forem hráčské spolupráce je aliance. Hráči sdílejí svá „soukromá data“ ve hře (online stav, plány, umístění jejich měst a kolonií atd.) s ostatními, aby mohli těžit ze spojeneckých akcí a pro zábavu.
alliance tabulka ukládá základní informace o herních aliancích. Každý z nich má jedinečný alliance_name které uložíme. Budeme mít také pole date_founded , která ukládá, kdy byla aliance založena. Pokud je aliance rozpuštěna, uložíme tyto informace do date_disbanded atribut.
alliance_member tabulka spojuje hráče s aliancemi. Hráči se mohou připojit a opustit stejnou alianci více než jednou. Z tohoto důvodu player_id – alliance_id pár není jedinečný klíč. Informace o tom, kdy se hráč připojí k alianci a kdy (pokud) odejde, budeme uchovávat v date_from a date_to pole. membership_type_id atribut je odkaz na membership_type slovník; ukládá aktuální úroveň práv hráčů v alianci.
Práva hráčů v alianci se mohou v průběhu času měnit. membership_actions , membership_type a actions_allowed tabulky společně definují všechna možná práva pro členy aliance. Tento model neumožňuje hráčům definovat vlastní úrovně práv v alianci, ale toho lze snadno dosáhnout přidáním nových záznamů do membership_type slovník a ukládání informací o tom, ke kterým aliancím se vztahují.
Abych to shrnul:hodnoty uložené v těchto tabulkách definujeme během počátečního nastavení; změní se, pouze pokud zavedeme nové možnosti.
membership_history tabulka ukládá všechna data týkající se rolí nebo práv hráčů v rámci aliance, včetně rozsahu, kdy byla tato práva platná. (Například by mohl mít na měsíc oprávnění „začátečník“ a od tohoto okamžiku „plné členství“.) date_to atribut má hodnotu NULL, protože aktuálně aktivní práva ještě neskončila.
membership_actions slovník obsahuje seznam všech akcí, které mohou hráči v alianci provést. Každá akce má svůj vlastní action_name a herní logika je postavena na těchto jménech. Můžeme očekávat hodnoty jako „zobrazit seznam členů“ , „zobrazit stavy členů“ a „odeslat zprávu“ zde.
membership_type slovník obsahuje jedinečné názvy akčních skupin používaných ve hře. actions_allowed tabulka přiřadí akce typům členství. Každá akce může být přiřazena k typu pouze jednou. Proto membership_action - membership_type pár tvoří jedinečný klíč pro tuto tabulku.
Umístění a struktury
Herní lokace jsou oblasti, kde hráči sbírají suroviny a budují stavby a jednotky. Některé hry mají předdefinovaný rozsah možných umístění, zatímco jiné mohou uživatelům umožnit definovat jejich vlastní umístění.
Ve 3D prostoru lze místa definovat pomocí souřadnic [x:y:z]. Pokud má hra předdefinovaný rozsah, nemusí hráčům povolit použití libovolného místa mimo rozsah [0:1000] pro všechny tři osy, takže jsme omezeni prostorem 1000 * 1000 * 1000.
Na druhou stranu možná chceme hráčům umožnit zadat přesné souřadnice jejich nového umístění – např. [1001:2073:4] – a chceme, aby to hra zpracovala za ně.
Seznam všech míst použitých v instanci naší hry budeme uchovávat v location stůl. Každé místo má svůj vlastní název, ale názvy nejsou jedinečné. Na druhé straně coordinates atribut musí obsahovat pouze jedinečné hodnoty. Souřadnice polohy jsou uloženy jako textové hodnoty, takže souřadnice pro 3D hry můžeme ukládat jako [112:72:235]. Souřadnice pro 2D hry lze uložit jako <1102:98>.
V některých hrách budou mít lokace řadu čtverců, které se používají k umístění struktur nebo jednotek. Tyto informace ponecháme v dimension atribut, což je textové pole. Dimenze může být jednoduše počet čtverců ve 2D nebo 3D mřížce. player_id atribut ukládá informace o aktuálním vlastníkovi daného místa. Může být NULL, když jsou lokace předem definovány a hráči soutěží o jejich obsazení.
structure tabulka obsahuje seznam všech staveb, které můžeme postavit na různých herních místech. Struktury představují vylepšení, která nám umožňují vyrábět lepší jednotky, provádět nové typy výzkumu, produkovat více zdrojů atd. Každá struktura použitá ve hře má svůj vlastní jedinečný structure_name . Nějaký možný structure_name hodnoty jsou „farma“, „rudný důl“, „solární zařízení“ a „výzkumné centrum“.
Můžeme očekávat, že každá struktura bude aktualizována několikrát, takže budeme ukládat také informace o její aktuální úrovni. Každý upgrade zlepšuje výkon struktur, takže produkuje více zdrojů nebo nám umožňuje používat nové funkce ve hře. Nemůžeme předem znát maximální úroveň upgradu, takže všechny věci související s úrovní (náklady, doba upgradu a výroba) definujeme pomocí vzorců. Všechny vzorce uložené v databázi jsou jádrem herních mechanismů a jejich úprava je zásadní pro rovnováhu hry a hratelnost obecně.
To je také případ upgrade_time_formula atribut. Příklad hodnoty pro toto pole je “
Ve většině případů existují požadavky, které musí být splněny, než hráči podniknou určité akce. Možná budeme muset dokončit definované množství výzkumu, než budeme moci stavět nové struktury nebo naopak. Úroveň výzkumu potřebnou k sestavení struktur uložíme do prerequisite_research stůl. Vztahy a úroveň struktury potřebná k zahájení různých výzkumů jsou uloženy v prerequisite_structure stůl. V obou tabulkách jsou cizí klíče research_id a structure_id jsou spárovány a tvoří jedinečný klíč. level_required atribut je jediná hodnota.
Tyto dvě tabulky, prerequisite_research a prerequisite_structure , tvoří také jádro hry.
Pro každou stavbu definujeme seznam předpokladů:další stavby a jejich minimální úrovně, které musí hráči mít, aby mohli začít stavět. Tato data uložíme do structure_required stůl. Zde structure_id představuje strukturu, kterou chceme vybudovat; structure_required_id je odkaz na strukturu(y) předpokladů a level je požadovaná úroveň.
structure_built tabulka ukládá informace o aktuálních úrovních struktury na daném místě. upgrade_ongoing atribut bude nastaven pouze v případě, že právě probíhá aktualizace, zatímco upgrade_end_time Po dokončení upgradu bude atribut obsahovat časové razítko.
structure_formula tabulka uvádí struktury a zdroje. Dvojice cizích klíčů k této tabulce tvoří její jedinečný klíč. Tato tabulka má také dva textové atributy obsahující vzorce s parametrem upgrade_time_formula . Potřebujeme je, protože musíme definovat zdroje vynaložené na budování každé struktury. Musíme také definovat produkci zdrojů po upgradu, pokud struktura generuje nějaké zdroje (tj. rudný důl bude produkovat
Výzkum a zdroje
Výzkum (nebo technologie) ve hrách je obvykle nezbytný pro vytvoření dalších funkcí. Bez určité úrovně výzkumu nelze stavět nové struktury nebo typy jednotek. Výzkum může mít také své vlastní požadavky. Jednou z nejběžnějších je úroveň dané struktury, obvykle nazývaná „výzkumná laboratoř“. Nebo možná hráči potřebují dokončit určitou úroveň výzkumu, než budou moci začít nový výzkum. Všechny tyto požadavky budou řešeny v této části. Níže najdeme datový model pro výzkum a zdroje:
research tabulka obsahuje seznam všech možných výzkumných akcí v naší hře. Používá stejnou logiku jako structure stůl. research_name atribut je jedinečný klíč tabulky, zatímco upgrade_time_formula pole obsahuje textovou reprezentaci vzorce časových požadavků na výzkum s parametrem upgrade_formula uloženy v research_formula tabulka.
Stejně jako u struktur definujeme seznam všech ostatních výzkumů a jejich úrovně, které musí být dokončeny, než začneme s dalším typem výzkumu. Tato data uložíme do research_required tabulka, kde research_id představuje požadovaný výzkum; research_required_id je odkaz na nezbytný výzkum a level je požadovaná úroveň.
Výzkum se týká jednotlivých hráčů a pro každého hráče – výzkum ch pair musíme uložit aktuální úroveň výzkumu hráče a všechny probíhající stavy upgradu. Tyto informace uložíme pomocí research_level stejným způsobem, jakým jsme použili structure_built tabulka.
Suroviny, jako je dřevo, ruda, drahokamy a energie, se těží nebo shromažďují a později se používají k budování staveb a dalších vylepšení. Seznam všech herních zdrojů uložíme do resource slovník. Jediným atributem je zde resource_name pole a je to také jedinečný klíč tabulky.
Abychom mohli sledovat aktuální množství zdrojů na každém místě, použijeme resources_on_location stůl. Opět platí, že pár cizích klíčů (resource_id a location_id ) tvoří jedinečný klíč tabulky, zatímco number atribut ukládá aktuální hodnoty zdrojů.
Jednotky a pohyby
Pro výrobu jednotek se používají zdroje. Jednotky lze použít k přepravě surovin, útokům na ostatní hráče nebo obecně k drancování a vypalování.
Seznam typů jednotek používaných v naší hře je uložen v unit slovník pouze s jednou hodnotou, unit_name; tento atribut je jedinečný klíč této tabulky. Některé běžné herní jednotky jsou „šermíř“, „bojový křižník“, „griffin“, „proudový stíhač“, „tank“ atd.
Musíme popsat každou jednotku specifickými vlastnostmi. Seznam všech možných charakteristik je uložen v characteristic slovník. characteristic_name pole obsahuje jedinečnou hodnotu. Hodnoty v tomto poli mohou zahrnovat:„útok“, „obrana“ a „body zásahu“. Charakteristiky jednotkám přiřadíme pomocí unit_characteristic vztah. Dvojice cizích klíčů unit_id a characteristic_id tvoří jedinečný klíč tabulky. Použijeme pouze jeden atribut, value , pro uložení požadované hodnoty.
research_unit tabulka obsahuje seznam všech výzkumných aktivit, které musí být dokončeny, než můžeme zahájit výrobu daného typu jednotky. unit_cost tabulka definuje zdroje potřebné k výrobě jedné jednotky. Obě tabulky mají jedinečné klíče složené z páru cizích klíčů (research_id nebo resources_id v kombinaci s unit_id ) a jedno pole hodnoty (cost). a level_required ).
A teď ta zábavná část. Produkce je zábavná, ale přesun jednotek a akce je ještě lepší. unit tabulkou, ale zde ji ponecháme, protože souvisí s jinými tabulkami.
Jednotky jsou buď umístěny na místě, nebo se pohybují mezi jednotlivými místy. Přidání player_id pole určuje, kdo je vlastníkem umístění nebo skupiny, která se mezi umístěními pohybuje.
Pokud jsou jednotky právě umístěny na daném místě, uložíme toto umístění a počet jednotek tam umístěných. K tomu použijeme units_on_location tabulka.
Když jednotky nejsou umístěny, pohybují se. Budeme muset uložit jejich výchozí bod a cíl. Kromě toho musíme definovat možné akce během pohybů. Všechny tyto akce jsou uloženy v movement_type slovník. type_name atribut je jedinečný, zatímco allows_wait atribut určuje, zda akce umožňuje čekání v cílovém bodě.
Můžeme přesunout jeden typ jednotky, ale téměř v každém případě přesuneme mnoho jednotek několika různých typů jednotek. Tato skupina bude sdílet společná data a my je uložíme do group_movement stůl. V této tabulce definujeme následující položky:
- hráč, který tuto akci zahájil
- typ akce
- počáteční bod
- cílový bod
arrival_timev cílireturn_timedo výchozího boduwait_timev cíli
return_time atribut může být NULL, pokud se jedná o jednosměrnou cestu, a wait_time je definován hráčem. Jednotky patřící do skupiny jsou definovány hodnotami uloženými v units_in_group stůl. Dvojice cizích klíčů units_id a group_moving_id tvoří jedinečný klíč tabulky. Počet jednotek stejného typu ve skupině je definován v number atribut.
Každý pohyb může přenášet zdroje z jednoho místa na druhé. Proto definujeme vztah many-to-many mezi group_movement a resource tabulky. Kromě primárního a cizího klíče resources_in_group tabulka obsahuje pouze number atribut. Toto pole ukládá množství zdrojů, které hráči přesunou z výchozího bodu do cíle.
Ve většině případů mohou hráči zavolat ostatním, aby se přidali k jejich dobrodružství. Abychom to podpořili, použijeme dvě tabulky:allied_movement a allied_groups . Jeden hráč zahájí společnou akci, která vytvoří nový rekord v allied_movement stůl. Všechny skupiny jednotek, které se účastní spojenecké akce, jsou definovány hodnotami uloženými v allied_groups stůl. Každá skupina může být přiřazena ke spojenecké akci pouze jednou, takže cizí klíče tvoří jedinečný klíč této tabulky.
Tento model nám poskytuje základní strukturu potřebnou k sestavení MMO strategické hry. Obsahuje nejdůležitější herní prvky:umístění, struktury, zdroje, výzkum a jednotky. Také je propojuje, umožňuje definovat prerekvizity v databázi a také ukládá většinu herní logiky do databáze.
Po naplnění těchto tabulek je definována většina herní logiky a neočekávali bychom, že budou přidány nové hodnoty. Téměř každá tabulka má jedinečnou hodnotu klíče, buď název funkce, nebo pár cizích klíčů. Změna charakteristik jednotek a vzorců produkce/nákladů nám umožní změnit rovnováhu hry v databázové vrstvě.
Jak byste změnili tento model? Co se vám líbí a co byste udělali jinak? Řekněte nám to v sekci komentářů!