Firebase Realtime Database multiplayer autóverseny játékhoz?
2020-10-16T00:49:51+02:00
2020-10-16T19:00:59+02:00
2022-07-20T13:16:58+02:00
  • Szóval most kezdenél szárnypróbálni a valódi teljesítmények világában, és már rájöttél, hogy a hagyományos cuccok nem lesznek jók. Eddig oké. Egyáltalán volt eszed megérteni - nagyon sokaknak nincs.

    A számaid alapján becsülten 50 konkurens user-nél végződik a db kiszolgálási teljesítménye, azt a számot vissza tudom igazolni, a gyakorlatban általában stimmel. Ha mindennel a db-t akarod nyaggatni, és adsz neki temérdek sok write-back cache ram-ot, kb ott lesz a korlát. Azért is van, hogy a játék szerverek memóriába olvasnak fel mindent, és aktív időszakban memóriában dolgoznak az adatokkal, nem használnak külön szervert az adat kezeléshez. Úgy nincs overhead a szerver-szerver kommunikációra. Ami a háttértárolókat összesen terheli, az a user profil adatok beolvasása, és kimentése.  Ahányszor egy user belép a dungeon-be, vagy kilép onnét, az aktuális játékosok mindegyikét mentened kell azokon a pontokon. Egyedül azt a terhelést nem lehet megúszni, de elég sok ram-mal (meg szünetmentes táp és társai) 5k konkurens user-ig ki tud szolgálni egy hagyományos hdd is, ssd talán 15-20k-ig. Mindaz per szerver. Normál esetben még a hdd korlátját sem éred el.

    Amit továbbmenőlegesen végig kellene számolnod, hogy legrosszabb esetet feltételezve ha 8-an vannak egy szobában, és mindenki eseményeit mindenkinek elküldöd, akkor mennyi hálózatot eszel per szoba (8 player). A logikai adatokhoz majd hozzá kellene adnod a titkosítást is. Apró csomagok esetén worst case számolj logikai adatforgalom x3 mennyiséggel. Nem, nem vicc. A kimenő titkosított forgalomra nagyjából 15 megabit per sec sávszélesség egységenként számolj egy cpu ghz-et is, mert a titkosítás sincs "ingyen".

    Ami a hálózatot illeti, dedikált szerverekkel kicsit olcsóbb. A dedikált szerverekhez árulnak olyasmit, mint garantált sávszélesség, de ingyen is adnak valami "maradék"-ot, és ha ügyesen balanszírozol, az is elég tud lenni. Használj kicsi teljesítményű szervereket, azok a relatíve költség hatékonyak, mert olcsó szerveren elég csak kevés playert kiszolgálni ahhoz, hogy költséghatékony maradjon, és a kevés playerhez elég tud lenni a kevés hálózat, a hagyományos hdd, meg az a kevés ram, ami kommersz szerverekben lenni szokott. A cpu lesz a legszűkebb keresztmetszet - az szokott lenni. Ha szerver farmra kell egy tipp, irány az ovh farm (ovh.com).

    A tapasztalatból tanulás esetére azt mondanám, nem lesz elég gyors. Ha most kezdesz ismerkedni a szuperszámítógép építési problémákkal, olyan nagyon sok buksiba begyömöszölni való fog a nyakadba szakadni, hogy a gyakorlatból tanulni meg mindazt egy emberöltő nem lesz elég hozzá. Csak és kizárólag tapasztalatból tanulni azoknak való, akiknek nehéz a fejük a megértéshez. És nekik nem ezt a témát javasolnám, hanem inkább valami mást. Épelmjű fejlődéshez muszáj absztrakt módon is tanulnod - kvázi feltételezésekből. Az lesz a tehetség próbája, hogy később absztrakt tanulással elsajátított ismeretekből képes leszel-e a gyakorlatban bármi működőképeset alkotni, vagy sem. Csak akkor állj neki, ha biztosan érzed magadban az erőt. Minden más esetben időpocsékolásnak fog bizonyulni.

    Kellemes szórakozást
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    // Unity 3D, C#

    Olyan kérdésem lenne, hogy szerintetek a Firebase Realtime adatbázisa használható olyan játékokhoz, mint mmo fps stb., vagy mint például egy multiplayer autóversenyzős játékhoz?
    Azért ragaszkodom valamennyire ehhez (ha lehetséges), mert a játék maga Firebase alapú, de egyszerű egyjátékos dolgokról van szó, nem valós idejűről, egyszerű írás és olvasás az adatbázisból. Tehát használom az Auth, Storage, Firestore rendszereket, de a játékba beletennék egy kis multiplayer dolgot is, egyfajta minigames.

    Tehát a játékosok csatlakozhatnak egy szobához, az elmélet nagyon egyszerű, maximum 4-8 játékos, első játékos létrehoz egy szobát amihez a többiek csatlakoznak, majd ehhez egy listener van beállítva, bármely pozícióváltozást elküldi a szervernek, amelyet minden a szobában tartózkodó játékos azonnal megkap, ezek után Vector3.Lerp stb. segítségével az ellenfél autója a kívánt helyre kerül.
    Ezt egyelőre úgy teszteltem, hogy a legkisebb pozícióváltozást is küldtem a szervernek, ami másodpercenként kb. 20-at jelentett, a telefonomon irányítottam, a laptopon Unity Editorban pedig folyamatosan azonnal láttam a változást, tehát elviekben működik a dolog.

    A kérdésem az, hogy a Firebase Realtime adatbázis szerintem nem erre lett kitalálva. :D Tehát oké, hogy realtime, akár a chat üzenetek, azonnal megjelenik stb., de nem arra, hogy 10.000 user másodpercenként 20 adatot küldjön gondolom..
    Már csak abból gondolom, hogy 2 felhasználónál elértem az adatbázisban a 4% peak-et, és 100%-nál teljesítményproblémák lehetnek, na most a firebase tud kezelni 100.000 users/adatbázis, tegyük fel nekem van 10.000 online vagy csak 1.000, ha kettőnél ezt műveltem, akkor ki tudja mi lesz.

    (Persze a másodpercenként 20 az lehet sok, lehet elég lenne 2-3, hiszen úgyis Vector3.Lerp és Quaternion.Lerp-el készítem a mozgást a position és a rotation értékekre, de ettől még valami nem oké az biztos..)

    Szóval a kérdés, hogy eleve ez a rendszer használható-e erre a célra?
    Megmondom őszintén, még soha nem készítettem ilyesmi multiplayer játékot, a játék magában is van interakció egymás között, de az nem ilyen valós idejű, arra tökéletes a Firestore írás olvasás. De mivel az egész firebase alapú, jobban örülnék ha ez is firebase alapú lenne, ha megoldható persze.
    Vagy esetleg más multiplayer szerver erre a célra?
    Próbáltam a photonengine-t, ami nem rossz, költségekben olcsóbb és drágább is, tehát 0,1 $ / GB a forgalom, ami a Firebase esetében 1 $ / GB, bár a Firebase-nél csak a forgalom után kell fizetni, photonnál az online userek 0,29 $ / hó / user, ami igaz tartalmaz 3 GB forgalmat / felhasználó, de nem hiszem, hogy kihasználnák azt az userek. 

    Nyugodtan leüvölthetitek a fejem, hogy a firebase realtime nem erre a célra lett kitalálva, csak mondjatok akkor okosságokat, mert ha más rendszert választok, azt a 2 rendszert vagy összekötöm valahogy, vagy független lesz és csak a játékosok adatait küldöm session stb. ellenőrzés nélkül, tehát biztonságügyileg kicsit bonyolultabb, ha egy firebasetól független rendszert használok. 

    De ha nem is erre lett kitalálva, egyébként nagyon jól működik, tényleg amit a telefonomon csinálok a gépen is ugyanaz látszik. 
    Mivel ez egy minigames a játékon belül, nem egy olyan fontos tényező, hogy ennek annyira fantasztikusnak kell lennie, hogy soha nem laggolhat, nyílván számolni kell egy lassabb internetkapcsolattal, de mint mondtam, ebben a témában nagyon kezdő vagyok, de kezdetnek szeretnék valami használhatót azért összedobni, meg mint mondtam, a játék maga nem erre épül. Jobban szeretek a tapasztalatból tanulni, mint ezer oldalnyi dokumentációkat olvasni, gyorsan összedobtam és működik is, csak hát hozzáértők véleménye is érdekel, mert azt látom, hogy ez így tuti nem lesz jó.. szerintem.. :D

    Ötletek, miért jó miért rossz a firebase, milyen egyéb megoldások lehetnek.

    Köszönöm a segítséget.
    Mutasd a teljes hozzászólást!
abcd