Czy warto wpisać na twardo dane ras i postaci w grze w kodzie źródłowym?

0

Tworzę dla zabawy grę tekstową typu monstersgame/ogame itp. Chcę stworzyć np. rasy postaci, ludzie/elfy/orki itd.
Teraz nasuwa mi się pytanie, bo mam doświadczenie w game dev ale prawie zerowe w programowaniu stron, czy powinienem hardcodować te rasy postaci z ich parametrami w kodzie? Ja osobiście odpowiedziałbym że nie, i mam pomysł stworzenia konta admina i panelu admina gdzie będę mógł modyfikować i tworzyć nowe rasy i nadawać parametry, tylko tu pojawia mi się lampka, że w kwesti zabezpieczenia jest tutaj ryzyko, bo shackowanie konta admina umożliwi dowolne modyfikowanie świata gry, i ew. trzeba będzie zrobić backup bazy danych, ale że nie mam doświadczenia to przychodzę z pytaniem do was, jaka praktyka jest dobra?

1
ProgramistaPralki napisał(a):

Tworzę dla zabawy grę tekstową typu monstersgame/ogame itp. Chcę stworzyć np. rasy postaci, ludzie/elfy/orki itd.
Teraz nasówa mi się pytanie, bo mam doświadczenie w game dev ale prawie zerowe w programowaniu stron, czy powinienem hardcodować te rasy postaci z ich parametrami w kodzie?

Na początek tak. I zostawiłbym tak przez długi czas.

ProgramistaPralki napisał(a):

Ja osobiście odpowiedziałbym że nie, i mam pomysł stworzenia konta admina i panelu admina gdzie będę mógł modyfikować i tworzyć nowe rasy i nadawać parametry, tylko tu pojawia mi się lampka, że w kwesti zabezpieczenia jest tutaj ryzyko, bo shackowanie konta admina umożliwi dowolne modyfikowanie świata gry, i ew. trzeba będzie zrobić backup bazy danych, ale że nie mam doświadczenia to przychodzę z pytaniem do was, jaka praktyka jest dobra?

Wiem, że może Ci się wydawać że zrobienie tego "konfigurowalnym" będzie bardziej elastyczne, ale nie będzie. To będzie bardzo duży, i można powiedzieć niepotrzebny narzut.

Jak masz wpisane dane postaci i ras "na twardo" w kodzie, to ile Ci zajmie zmiana ich? Kilka sekund + recompile. A teraz jak długo będziesz budował ten panel admina, ile case'ów wymyślisz które "dobrze byłoby dodać"? Szkoda czasu.

Wpisz na stałe w kodzie i programuj dalej.

0
Riddle napisał(a):
ProgramistaPralki napisał(a):

Tworzę dla zabawy grę tekstową typu monstersgame/ogame itp. Chcę stworzyć np. rasy postaci, ludzie/elfy/orki itd.
Teraz nasówa mi się pytanie, bo mam doświadczenie w game dev ale prawie zerowe w programowaniu stron, czy powinienem hardcodować te rasy postaci z ich parametrami w kodzie?

Na początek tak. I zostawiłbym tak przez długi czas.

ProgramistaPralki napisał(a):

Ja osobiście odpowiedziałbym że nie, i mam pomysł stworzenia konta admina i panelu admina gdzie będę mógł modyfikować i tworzyć nowe rasy i nadawać parametry, tylko tu pojawia mi się lampka, że w kwesti zabezpieczenia jest tutaj ryzyko, bo shackowanie konta admina umożliwi dowolne modyfikowanie świata gry, i ew. trzeba będzie zrobić backup bazy danych, ale że nie mam doświadczenia to przychodzę z pytaniem do was, jaka praktyka jest dobra?

Wiem, że może Ci się wydawać że zrobienie tego "konfigurowalnym" będzie bardziej elastyczne, ale nie będzie. To będzie bardzo duży, i można powiedzieć niepotrzebny narzut.

Jak masz wpisane dane postaci i ras "na twardo" w kodzie, to ile Ci zajmie zmiana ich? Kilka sekund + recompile. A teraz jak długo będziesz budował ten panel admina, ile case'ów wymyślisz które "dobrze byłoby dodać"? Szkoda czasu.

Wpisz na stałe w kodzie i programuj dalej.

Osobiście uważam że wygodniej i szybciej będzie hardcodować, no ale np. tworząc w przeszłości gry, raczej tworzyłbym osobne edytory np. przedmiotów, i nigdy nie przyszłoby mi do głowy tworzenie ich w kodzie, no ale też i w tym przypdku będzie bezpieczniej.

0
ProgramistaPralki napisał(a):

Osobiście uważam że wygodniej i szybciej będzie hardcodować, no ale np. tworząc w przeszłości gry, raczej tworzyłbym osobne edytory np. przedmiotów,

Ale po co? Napisanie takiego edytora to jest prawdopodobnie wysiłek podobny jak napisanie samej gry. Serio, nie potrzebujesz czegoś takiego.

Jeśli chcesz pisać edytor, to znajdź istniejącą grę w której ludzie tworzą postaci (np IcyTower) i do tego zrób edytor - i wtedy Twoim głównym celem będzie zrobienie edytora, a nie gry. Natomiast jak chcesz zrobić swoją grę - to rób swoją grę, i albo wpisz na stałe elementy w kodzie źródłowym, albo skorzystaj z istniejących edytorów.

3

Dlaczego od razu zakładasz, że ktoś Ci się włamie na konto admina?

  1. Małe szanse, żeby Twoja gra stała się na tyle popularna, żeby ktoś z odpowiednimi umiejętnościami się nią zainteresował i łamał zabezpieczenia.
  2. Oprogramowanie serwerowe jest na tyle rozwinięte, że ewentualny włam wynikałby z Twojego zaniedbania.
0
Spine napisał(a):

Dlaczego od razu zakładasz, że ktoś Ci się włamie na konto admina?

  1. Małe szanse, żeby Twoja gra stała się na tyle popularna, żeby ktoś z odpowiednimi umiejętnościami się nią zainteresował i łamał zabezpieczenia.
  2. Oprogramowanie serwerowe jest na tyle rozwinięte, że ewentualny włam wynikałby z Twojego zaniedbania.

Ja tylko trenuje tworzenie aplikacji webowych, i moje założenie jest spowodowane nauką dobrych praktyk, bo publikować tego nie zamierzam.

1

Możesz te parametry wpisać do bazy danych i ładować przy starcie aplikacji, wtedy możesz je łatwo zmieniać bez ponownej kompilacji i deploymentu.

0
AbcDefGhi napisał(a):

Możesz te parametry wpisać do bazy danych i ładować przy starcie aplikacji, wtedy możesz je łatwo zmieniać bez ponownej kompilacji i deploymentu.

Ogarniam trochę interakcję z SQL Server studio/ Azure. Masz na myśli działanie bezpośrednio na tych aplikacjach w celu utworzenia tych parametrów?

1

Może być to co mówisz, albo najprostsze rozwiązanie na początek czyli serializacja do pliku np XML, JSON itd.

1
AbcDefGhi napisał(a):

Może być to co mówisz, albo najprostsze rozwiązanie na początek czyli serializacja do pliku np XML, JSON itd.

Najprostsze, to jest zahardkodzić.

0

Akurat dziwnym zbiegiem okoliczności siedziałem teraz przy serwerze gry od paru dni i grałem w nią na swoim priv servie i tam wszystko z bazy danych do memory database wczytywane.
A do clienta wyexportowane do pliku akurat w binarej formie strukturami, ale to samo można było by osiągnąć jsonem.

Ale w grze i tak masz jakieś postacie, to pewnie jakaś klasa reprezentuje i trzymasz np. różne id potworów w memory database, gdzie każdy element to obiekt jakiś.
To łatwo można zrobić refleksję z i do pliku wszystkich pól obiektów, jak będziesz chciał dodać nowe potwory i ich lokalizacje respawnu, to nie będziesz musiał całej gry rekompilować, tylko dodasz obiekt.
Nowy id potwora, nazwa, x, y, z, ścieżka do textury, pkt expa itp.
I na początku gry ładujesz ten plik json, robisz na każdym elemencie refleksję do obiektu i dodajesz do bazy w pamięci, uzyskasz open/close principle z solid.
Łatwo do clienta i serwera będziesz mógł dodać nowego potwora, tak że serwer będzie wiedział gdzie ma respić i ile expa dawać, a client będzie wiedział jaką teksturę wyświetlić i jak się nazywa potwór.
Dane id i nazwa muszą być takie same, bo serwer poinformuje clienta, że położeniu przeciwnika i jego id to client będzie wiedział co wyświetlić i gdzie.

Jak już Potwora jako obiekt masz, to praktycznie już zrobiłeś to tak jakby miało to być z pliku ładowane bo to praktycznie za ciebie refleksje zrobią, gorzej w C++ bo tam refleksje są trochę gorzej rozbudowane, ale wszystkie języki mogą praktycznie 1-1 mapować jsona na obiekt, to możesz sobie tak łatwo załadować.

Tak z tego co widzę to kontrybuowanie i modyfikowanie istniejących otwarto źródłowych gier jest nawet ciekawe, można popatrzeć i rozwinąć do swoich potrzeb grę online.
Chodź jeśli jest dosyć stara to pewnie w C++ będziesz wszystko robił, a nowsze w C# to pewnie unity.

Nawet takie dodawanie do jsona nowego obiektu to możesz zrobić jakieś proste wczytanie wszystkich informacji potrzebnych żeby obiekt utworzyć i dopisanie do pliku.
Nawet jakimś konsolowym toolem, w dodatku takie toole są potrzebne, bo modderzy czy inni jak będą chcieli dodać nowy quest to skorzystają z twojego toola, który zapyta ich o informacje i ładnie doda do pliku, który zawiera informacje dla serwera i clienta.

1

Nie kombinowałbym zbyt mocno.

Np. możesz zrobić serializację swoich ras w grze do JSON i z powrotem.

Jeśli to zrobisz, to wtedy nawet mógłbyś część hardcodować, a część wgrywać z JSONa jeśli tak by było trzeba.

No i:

  • Jak często będziesz modyfikował te rasy?

  • Jak długo zajmuje kompilacja? (jeśli zbyt długo to może mieć sens już wydzielić te dane tak, żeby dało się zmienić bez ponownej kompilacji. A to dlatego, że żeby coś zmienić, zwykle trzeba to tweakować i ileś razy zmieniać, bawić się parametrami. Więc potrzebny jest szybki feedback, a nie czekanie na kompilację nie wiadomo ile)

  • Czy będziesz to robić tylko ty? (jeśli tak, to nie potrzebujesz w ogóle panelu admina, możesz to robić na swoim kompie, a potem zapisywać w odpowiednim pliku i wgrywać na serwer. Natomiast inna sprawa, jeśli użytkownicy również by mieli modyfikować rasy)

  • Czy chcesz dokonywać zmian ras na żywo w trakcie gry? (jeśli tak, to hardcoding może nie wystarczyć i przyda ci się sposób edycji w trakcie gry, a potem np. serializacja do JSONa, ew. nawet edytor ras mógłby generować kod w języku programowania, który by trzeba było przekleić do codebase'u, żeby zapisać zmiany - bo kto powiedział, że nie możesz połączyć dwóch podejść? Dynamiczny edytor w grze do dodawania ras, który na żywo by pokazywał podgląd, ale na koniec dnia wypluwałby kod języka programowania albo JSON itp. który byś sobie przekleił).

Albo zahardkodzić w sytuacji kiedy będziesz modyfikować te rasy rzadko (albo często, ale czas kompilacji nie jest problemem), i nie w czasie działania aplikacji. Pytanie więc czy chcesz mieć ogólną możliwość czasem zmiany czegoś (bardziej hardkoding), czy może ma być to bardziej dynamiczne (wtedy bardziej podejście edytora albo pliku konfiguracyjnego JSON itp.)

i ew. trzeba będzie zrobić backup bazy danych

No jeśli będziesz coś trzymał w bazie, to lepiej się naucz robić backupy bazy danych (w sensie nie ma co przyjmować postawy ojejku, backup bazy danych, nie umiem. Przecież ręcznie backup bazy można nawet sobie wyklikać w adminie bazy (chociaż na dłuższą metę lepiej to zautomatyzować).

1 użytkowników online, w tym zalogowanych: 0, gości: 1