Sziasztok!
Egy összetett kérdésem lenne, ezért sem tudtam pontos címet megadni. Egy elég bonyolult játék fejlesztésén dolgozunk Unity-ben, amit 3 éve csinálunk (ebbe beletartozik a Unity, c# elsajátítása) előtte kizárólag php+mysql-el foglalkoztunk, lényegesen egyszerűbb téma volt, mint ez. A játék jelenleg úgymond 50% körüli készültség alatt van és eljutottunk odáig, hogy ténylegesen foglalkoznunk kell azzal, hogy a szerverrel milyen kommunikációt válasszunk.
A játékról: (általánosságban beszélek, nem konkrétan a mi játékunkról.) Képzeljünk el egy népszerű lövöldözős játékot, ahol a játékos regisztrál, feltöltheti egyenlegét, fegyvereket vásárolhat, rengeteg tulajdonság szint van, az egyenlegből küldhet át egyenleget más játékosnak, tehát rengeteg adatbázis művelet van, és a játék lényege persze, hogy miután mindennel elkészült, beléphet egy terembe, ahol más játékosokkal realtime játszhat. Nagyjából hasonló elven működik a miénk is, bár a játék teljesen más, de ez most ebből a szempontból lényegtelen.
Mivel korábban php-vel és mysql-el foglalkoztunk, így eleinte mi is így kezdtük felépíteni a játékunkat (aztán gondoltuk majd átírjuk a végleges nyelvre). Megjegyzés: a realtime dolgot egyelőre hagyjuk ki. Ami azt jelenti, hogy unity-ben elkészítettük magát a játékot, a játékos egy php fájlt meghívva regisztrálhat, mysql adatbázisban tárolódik minden, tud vásárolni, felhasználók profiljai között böngészni, ezek mind olyan dolgok, amikhez nem szükséges az azonnali realtime adatbázis, hiszen pusztán lekérdezésekről van szó, apróbb módosításokról az adatbázisban. A session kérdéssel még nem foglalkoztunk, hiszen valószínű, hogy az egész alapja át lesz írva. Kezdetleges terv, hogy bejelentkezéskor létrehozunk egy session ID-t, mely a játékoshoz van eltárolva, amit a unity megkap és minden további kéréskor ezt továbbítja a szervernek. Fontos tudni, hogy ezek mögött php-ben a backend nagyon fontos műveleteket ellenőríz, hogy valóban van-e annyi egyenlege, stb., tehát ha valaki meghackeli a kliens oldalt, akkor se tudjon semmilyen olyan műveletet végrehajtani, amit valójában nem szabad neki.
Ez így jelen formában működőképes is, de menjünk tovább.
Csatlakoznak egy "szobához", ahol mondjuk maximum 20 játékos tartozkódhat egyszerre. Firebase realtime szerver az első gondolatunk, természetesen már ez is elkészült, bár mivel a végleges szerver kommunikáció még nem áll rendelkezésre, nincs Firebase auth, ezért itt szimplán a felhasználó azonosítóját küldjük el a szervernek, amik alapján a játékosok tudnak mozogni, csinálni amit kell. Működőképes is, de itt még semmi biztonság nincs, hiszen nagyon könnyen hozzá lehet férni a realtime adatbázishoz mindenféle azonosítás nélkül.
Tehát összegezve, van 2 adatbázis, az egyik a felhasználók adatai, itt kerül végre a legtöbb módosítás saját és egymás között, plusz van egy realtime adatbázis, amihez a Firebase realtime rendszerét használnánk, itt tulajdonképpen a legfontosabb adatok a mozgás koordinátái, amik valós időben frissülnek az egy szobában tartózkodók között. De itt nem fontos, hogy kapcsolatban legyen az első adatbázissal. Vagyis, csak ritkán. Ami azt jelenti, hogy ha mégis szükség van rá, akkor szintén php-vel kapcsolódunk, hogy az első adatbázisból lekérdezzük a dolgokat, addig a játékos várakozik. Tehát egyfajta kommunikáció van közöttük a mozgáson kívül, de ott nem sürgős a válaszidő. Viszont itt nem maga a firebase rendszer csatlakozik az adatbázishoz, hanem a kliens az előbb említett módon, tehát még mindig két független szerverről van szó.
Viszont, szóba jön a biztonság kérdése. Ha a Firebase realtime szerver nincs kapcsolatban a másik adatbázissal, akkor nem tudunk meggyőzödni arról, hogy ténylegesen az az user küldi az adatokat, aki az első szerveren be van jelentkezve, mivel a realtime adatbázis nem tartalmazza a session id-t. Ez akkor jenne jó, ha magán a szerver csatlakozna a másik szerverhez, lekérdezni a sessiont.
Csak hogy még jobban értsétek, jelenleg tényleg nagyon egyszerű módon működik az egész, tehát unityben kiválasztja hogy pl. fegyvert akar vásárolni, akkor meghívja a fegyvervasarlas.php-t, elküldve az user id-t és a session_id-t, a php elvégez minden fontos műveletet, módosítja a dolgokat a mysql adatbázisban, majd visszaadja, hogy sikeres volt-e. A realtime dolog meg csak annyi, hogy elküldi a szervernek az azonosítóját meg a koordinátáját minden mozgás esetén, ezek meg frissülnek folyamatosan realtime egymás között.
Kétféle megoldáson gondolkodtunk:
1. Az egész Firebase alapú, tehát a felhasználók a Firebase auth segítségével regisztrálnak, és minden műveletet a Firebase rendszert meghívva végez el. Sajnos itt nem vagyunk nagyon tisztában a backend működésével, mert azt láttuk, hogy be lehet állítani jogosultságokat, ki mihez férjen hozzá, de nálunk például egy játékos módosíthat más felhasználó adatai között is (pl. ha egyenleget küld át.) Tehát ha az egész firebase alapú, akkor is legjobb lenne, ha például Go nyelven a backendet megírhatnánk, hogy biztonságos legyen a játék.
2. Marad így jelen formában, annyi különbséggel, hogy az első adatbázist és php-t átpakoljuk google cloud-ba, adatbázisnak Nosql, backendnek Go vagy nodejs, a gyorsabb kommunikáció érdekében. Realtime adatbázisnak használjuk továbbra is a Firebase realtime rendszert, viszont itt még mindig kérdéses, hogy amikor a realtime szerverhez kapcsolódunk, akkor az hogyan tudja visszaellenőrízni, hogy az adott azonosítóhoz az adott session_id tartozik a cloud-ban, és hogy anélkül ne engedjen semmit csinálni.
Jelenlegi rálátásunkból adódóan a második verzió tetszene a legjobban, mert így úgy gondoljuk, sokkal jobban tudjuk felügyelni, mi is történik, a biztonságra is jobban oda tudunk figyelni, számunkra ez még jobban átlátható. Ha az egész firebase, akkor tulajdonképpen a kliensben történik minden, a firebase oldalon meg tulajdonképpen ellenőrzi, van e jogosultsága, de nem vagyunk tisztában ott a backend tényleges működésével. Bár láttuk, lehetséges a firebase oldalon backend írására (https://firebase.google.com/products/functions), de mégis szeretnénk olyanoktól segítséget kérni, akik ebben már valamennyire jártasak, hogy miképpen valósítható ez meg optimálisan, és a jelenlegi működési elv nem hatalmas mértékű változtatásával.
Tisztában vagyunk vele, hogy ehhez még sokat kell megtudnunk az egész működéséről és tanulnunk, de eljött az idő, hogy ténylegesen foglalkoznunk kell ezzel is, hiszen a jelenlegi verzió nem maradhat. Még mindig úgy gondoljuk, legegyszerűbb ezt a php-t felpakolni google cloudba, esetleg átírni go-ra, esetleg nosql adatbázis és igazából készen is vagyunk, csak a realtime szerverhez való kapcsolódás biztonsági problémái a gond.
Ha valaki tud egyszerű, de jól működő megoldást, megköszönjük. :)