Wątek: System zadań w grze.

Hej

Zastanawiam się w jaki sposób napisać system zadań, który zminimalizowałby edycję kodu gry.

Tzn. dodawanie nowego zadania nie wiązałoby sie z edycją plików - nie mówie tutaj o zupełnym braku, ale wolałbym, żeby ingerencja była jak najmniejsza.

Pewnie trzeba zrobić w bazie tabele z zadaniami i Npc'tami.

Ale co dalej? Dzięki z góry za pomoc. Nie oczekuje kodu, wystarczy tylko teoria.

Zależy jakie zadania i do jakiej gry. Jednak raczej do każdego zadania musisz mieć przygotowane "zaplecze", tzn. kod który będzie coś podliczał, sprawdzał etc. Nie da się (albo ja jestem za głupi) zrobić żadnego konkretnego zadania nie ingerując w kod gry. Np. zniszcz 3 statki. I co z tego że będziesz miał w bazie dane ile statków ma zniszczyć i ile zniszczył jak kod nie będzie po zniszczeniu statku podliczał zniszczone_statki+=1, a potem nie będzie sprawdzał czy zniszczone_statki==3...

Zależy od systemu zadań. Jeżeli chodzi o zadania w stylu Gladiatus to np:

ID gracza
ID zadania [short int, 1 to np "Zabij" 2 to "Zdobądź".. //może to też być proste słowo "KILL"/"BRING"/"TALK" potem sprawdzasz switch/case czy jak sobie chcesz..
Licznik / Warunek
Czas rozpoczęcia [możliwość zadań czasowych, patrzysz na aktualny czas i porównujesz ile minęło, czy się spóźnił czy nie].

Licznik nie musi być liczbą, może być czymś w stylu: 1-0-1-0-0-1;
Co można łatwo rozdzielić [np. funkcja explode w PHP] i nam daje tablicę:
{1, 0, 1, 0, 0, 1}
co możemy interpretować jako prawda/fałsz, spełnienie określonego warunku lub też jako konkretne liczby.

Roboty w plikach i tak zawsze będzie, ale im więcej potworów/przedmiotów/zadań ma własne ID tym lepiej, bo potem można z tego korzystać w prosty sposób.

Ogólnie sposobów jest wiele, to też zależy od tego jak skomplikowane, rozbudowane są zadania. O tych, o których mówię - nie jest trudne wykonanie, bo nie wymaga fabuły.

Jak już pisano - to zależy od struktury twoich zadań.
Jeśli twoje zadania są z jednego szablonu tzn. zabij - x y - razy i przynieś z sztuk w to każde zadanie możesz sprowadzić do jednego rekordu w bazie danych. Jedna tabele na potopy zadań, a druga na rozpoczęte zadania dla każdego z graczy. Wady: brak jakiejkolwiek elastyczności.

Jeśli zadania potrafisz przedstawić w postaci drzewa, gdzie węzłami są kolejne rozgałęzienia w drzewie "decyzji". Do takich wezłów dołączasz z innych tabel wymagania by osiągnąć dany cel. Możesz sobie takie drzewo zmapować do relacyjnej bazy danych Jest to dość dobrze opisane, choć nie takie trywialne jak poprzedni punku. Wady: średnia elastyczność (wszystkie cele muszą być jednego typu lub bardzo podobne), duża elegancja. Możesz też pokombinować z typami celów i np. dziesiątkami tabel dla dziesiątków typów celów (słaba wydajność zewnętrznego złączania tylu tabel). Ewentualnie trzymać jakieś dodatkowe informacje rozróżniające "udaj się do karczmy" od "wytnij wrogów x". Jeszcze większą swobodę da ci baza no-sql (jakaś grafowa), która pozwoli ci bardzo łatwo łączyć zadania z cegiełek i pozwoli na zapętlenia (w relacyjnych bazach bardzo źle się symuluje grafy cykliczne, ale jest to możliwe). Wady: ciężko znaleźć coś "dla opornych" na ten temat.

Pamiętaj, że możesz używać serializacji i funkcji eval. Dzięki temu możesz wygodni zapisywać obiekt zadania i przywracać go kiedy będzie ci potrzebny. Będziesz wtedy mógł trzymać w bazie obiekty zadań poskładane z fragmentów zaimpelmentowanych w kodzie. De facto oddzielisz w ten sposób kod zadań od kodu programu jednocześnie mając pełną swobodę. Moim zdaniem bardzo wygodnie rozwiązanie do zapamiętywania "postępów" graczy, ale nieelegancie do tworzenia w ten sposób zadań. Wady: niemożliwe (bardzo trudne) wyciąganie wniosków o tym kto jak daleko doszedł i co mu zostało z poziomu bazy danych.

matips albo moze po prostu zrobic sposobem ktory opisales jako "brak jakiejkolwiek elastyczności" ale zrobic to madrzej niz ty przedstawiles i dzieki nieszablonowemu mysleniu uzyskac elastycznosc tego sposobu. Blednie okresliles ten sposob i blednie zinterpretowales pojecie tabeli w tym wypadku. Brak elastycznosci wprowadzaja pozostale rozwiazania ktore podales.

Radze uzywac rozwiazania numer jeden poniewaz jest BARDZO ELASTYCZNE wlasnie ze wzgledu na zwolnienie bazy danych z roznorakich zadan laczenia tabel. Tworzenie nowych typow zadan dzieki temu byloby bardzo latwe i w zasadzie przyjemne poniewaz nie posiadamy wtedy zadnych narzucen odgornych ze strony bazy danych. W zasadzie mamy kontener na nasze dane jakiego tylko chcemy typu

Czy to "nieszablonowe" myślenie polega na trzymaniu w bazie, w każdej entce typu zadania oraz listy argumentów dla konstruktora? Mi się to wydaje nieelastyczne, bo co jeśli będziemy chcieli wymyślić zadnie o 10 parametrach, a w bazie mamy tylko 7 kolumn? Wtedy będziemy musieli zrobić dodatkowe 3 i mieć dużo pustych pól w pozostałych rekordach. Jeśli nie takie rozwiązanie, to w jednym polu tekstowym trzymasz zserializowaną tablicę argumentów.
Po drugie nie jesteś w stanie takiej tabeli łączyć z czymś innym - co jeśli w polu parameter1 masz liczbę 13 to bez przeanalizowania pola taskType nie wiesz czy powinieneś wyciągąć dane potwora o id = 13, czy może chodzi o gracza o id = 13. Z drugiej strony widziłem już rozwiązania gdzie dla każdego pola było pole z nazwą tabeli do której jest "kluczem" obcym.

Sam sobie odpowiadasz na pytania i mnozysz problemy ponad norme.

Jak masz 7 kolumn a potrzebujesz 10 to dodajesz 3 kolumny. Mozesz zastosowac system cachowanie w tym wypadku i jesli bedzie za duzo pustych pol w tabeli to trzymasz te pola zserializowane w ostatniej kolumnie tabeli. Nic nie stoi na przeszkodzie zeby struktura takiej tablicy byla dynamicznie dostosowywana do ilosci roznorakich zadan.

Po drugie nie jesteś w stanie takiej tabeli łączyć z czymś innym - co jeśli w polu parameter1 masz liczbę 13 to bez przeanalizowania pola taskType nie wiesz czy powinieneś wyciągąć dane potwora o id = 13

Od czego mamy pliki php?

I tabela powinna miec strukture "par1, par2, par3... parN" dzieki czemu to kontroler zajmuje sie tym ktory parametr czemu odpowiada.

Tak, ale wtedy nie potrzebujesz rozdzielać zmiennych na par1, ... parN. Jeśli par1 jest to np. dla zadnai zabij_coś par1 to ID_potwora, to by wyświetlić użytkownikowi informacje o potworze musisz najpierw wyciągać ten rekord, zinterpretować typ zadania i dopiero wtedy możesz dopytywać bazę danych o opis potwora. Nie widzę żadnej przewagi takiego rozwiązania nad polem z kodem PHP trzymającego coś w stylu: new tajemneZadanie("jakiś opis", 13, 998, 43)

Jesli nie widzisz przewagi to nie wiem dlaczego to napisales zamiast poczytac pare kursow. Masz racje, po co komu baza danych ^^

Par1 może być varcharem.

K-356-4-7

$obv = explode("-"; "K-356-4-7)
switch.. case.. K = kill, zabij; F = fetch, find, przynieś; T = talk, porozmawiaj..
getMonsterById(356) - > name;
echo Pokonano: getMonsterById($obv[2]) - > name; $obv[3] . "z" . $obv[4]

Coś w tym stylu. ;d
Zabij getMonsterById(356)


explode ftw, funkcja przeciwna to implode, więc nie ma problemu z zapisaniem tego znowu do bazy danych..
zależy od stopnia skomplikowania zadań..


NIGDY nie trzymaj potworów w bazie danych.. To idiotyzm. W bazie danych nie trzymałbym stałych rzeczy, po co Ci zbędne zapytania..