Baza danych pod grę


#1

Chciałbym napisać bazę danych pod małą grę (tabelki pod rejestrację, parametry itemów, itemshop itd.) Baza by musiała współpracować z popularnymi silniami gier Unreal/Unity.

W jaki sposób mam to zrobić? Nie chodzi mi tu o tutoriale, a o wynik, tzn. w jakim formacie powinny być przechowywane dane, aby mogły zostać bezproblemowo pobrane przez silniki gier.
Rozumiem że tabelki prosto z “Excela” mi żaden silnik nie przyjmie.

Kiedyś zajmowałem się serwerem gry Metin2, były tam utworzone tabelki mysql, z których “jądro systemu” (skompilowany zestaw funkcji) sobie pobierało/zmieniało dane.

Gra powstała z 10 lat temu. Może jest już inny, lepszy sposób na zarządzanie danymi?


#2

Jeżeli to ma być dostępne z sieci to polecam Node.js + MongoDB
Robisz sobie REST API i z poziomu silnika robisz tylko requesty do niego, a w odpowiedzi dostajesz JSON’a, którego bezproblemowo obsłużysz w każdym silniku i języku.


#3

Ewentualnie API w ASP NET Core + Entity Framework + dowolna baza obsługiwana przez EF.


#4

Heheh no właśnie, podstawowe pytanie to: w jakim języku umiesz programować?


#5

heh no właśnie… w żadnym, kiedyś trochę w c++, ale długo tego nie robiłem i się zapomniało.

Dobra, dzięki za rady, postaram się coś własnymi siłami ogarnąć.


#6

Armata na wróbla.

Sensowny format danych to pliki CSV - czyli tableki bez syfu z excela związanego z formatowaniem i dynamicznymi obliczeniami.

Albo w ogóle google doca typu sheet i dać dostęp programiście,
przy okazji w innych arkuszach można sobie porobić proste wykresy, symulacje itd ipt.
ogarnięty programista wyeksportuje sobie to do dowolnego formatu.
A jak już będzie miał coś konkretnego to zasugeruje jak najlepiej robić updatey.
Google doci pamiętają wersje, i umożliwiają współpracę więc robią za system kontroli wersji dla ubogich i nie trzeba uczyć gita czy innego SVNa.

Dopiero jak masz konkretny projekt to dasz te CSVki programistom i wrzucą je do tego co gra potrzebuje…

Po kiego grzyba stawiać mongo czy własny serwer API RESTowego
bez projektu który będzie z tego korzystać?
Nie wiedząc nawet jakie są wymagania ani dostępne biblioteki…

W małym projekcie wkompilujesz te staty do konkretnego builda
w skrajnym przypadku generując kod z chamskimi statycznymi tabelkami obiektów jak tego będzie mało. (oczywiście skryptem żeby to łatwo updateować jak się wartości pozmieniają)
W dużym może być potrzebny jakiś system do A/B testów itp.
Prawie żaden projekt nie chce zabijać sobie bazy zapytaniami w runtime i jakiś cache tam będzie użyty.


#7

Baza nie ma żadnego znaczenia odnośnie gry i języka w jakim ta gra będzie napisana. Jeśli 10 lat temu robiłeś to w MySQL to kompletnie nic od tamtej pory się nie zmieniło.

Serwer baz danych z bazą postaw sobie w MySql jak się na tym znasz.

Do tego potrzebujesz Api czyli jakiś interfejs za pomocą którego gra będzie pobierała i zapisywała informacje w bazie danych.

Tu wybór języka API po stronie serwera do komunikacji z bazą danych jest spory C++, NodeJS, PHP, Perl, Python, golang, java, fortran, pascsal, cobol. lisp


#8

To może jeszcze raz:
Jaki cel projektowy chcesz osiągnąć wystawiając rzeczywistą bazę danych relacyjną czy noSQL do gry.
Już nie wspominając o opakowywaniu tej bazy w API zanim projekt jest na sensownym etapie dojrzałości.
I czy ten sam cel nie będzie lepiej osiągnięty google dociem.
Z którego dane się zrzuci jak już zapadną decyzje co w konkretnym projekcie będzie potrzebne.
Zwłaszcza jak gra będzie single player i nie powinna wymagać dostępu do neta…
Najprawdopodobniej nie będzie to utrzymywanie własnego serwera bazodanowego z własnym API.

Tylko właśnie jakiś prosty format typu plik CSV wrzucony gdzieś do gry.
Jak nie wygenerowany kod jakimś prostym skryptem - który weżmie tego google doca, i wygeneruje tabelki dla C++ czy innego C#, które opakowują dane w jakiś interfejs programistyczny żeby kod z tego korzystał, i wszystkie są wkompilowane bo i tak nie będą się zmieniać w konkretnym buildzie.

Jest ileś scenariuszy gdzie taka baza z API się przyda - np designer na żywo tweakuje staty zespołowi testerów - ale czy tu w ogóle jest taki scenariusz?