Czy warto wdrażać mechanikę / zasady gry oddzielnie od głównego kodu?

Nie jestem pewien, czy pasuje do zakresu tej społeczności, czy też powinien przejść do Stackoverflow.

Załóżmy, że chcę, aby moja gra była łatwa do rozszerzenia w jej rdzeniu, tzn. Chcę, aby wiele osób, nawet bez przyzwoitej wiedzy programistycznej, mogło nie tylko modyfikować istniejące zasady, ale nawet dodawać do niej zupełnie nową mechanikę. Sam nie jestem dobrym programistą, ale jestem gotowy do nauki, potrzebuję tylko kilku wskazówek i zapewniam, że da się to zrobić.

Myślałem o tym, czy jest możliwe / wykonalne w jakiś sposób zaimplementować mechanikę gry niezależnie od głównego kodu narzędzia? Mam na myśli, że w grach stołowych mamy te zasady, które nie zawierają faktycznych algorytmów wszystkich działań, ale raczej opisują niektóre protokoły i ograniczenia, silnie odwołując się do kontekstu każdego takiego elementu. Czy można zrobić coś podobnego do gry na PC, np. Opisać wszystkie zasady w bardzo wysokim poziomie, łatwym do odczytania (i zmiany) przez ludzki język programowania, który jest następnie „konsumowany” i analizowany przez kod narzędzia w działająca instancja mechaniki gry?

To naprawdę wydaje się, że muszę napisać własny język i kompilator)), czego oczywiście nie będę w stanie zrobić. Ale może jest łatwiejsze podejście do problemu?

Do Twojej wiadomości: moim językiem wyboru dla kodu narzędzia będzie Python 3.x

Mówiąc ogólnie, łatwość rozbudowy dowolnego systemu zależy od stopnia, w jakim jego podsystemy są ściśle lub luźno sprzężone . Zazwyczaj im luźniej sprzężone są podsystemy, tym łatwiej jest je modyfikować, ponieważ są odizolowane i niekoniecznie wymagają pełnego zrozumienia systemu jako całości.

Nic nie jest za darmo - taki system zazwyczaj wymaga więcej zasobów (różne kombinacje czasu, pieniędzy i umiejętności) do zbudowania. Stopień rozciągliwości, który opisałeś, uderza mnie bezpośrednio w poziom umiejętności, które przypisałeś sobie. Można to zrobić, ale tworzenie oprogramowania, które opisałeś, jest bardzo trudnym przedsięwzięciem.

Najbliższe mi rzeczy, o których wiem, to Vassal (który jest o wiele bardziej programistyczny niż opisałeś) lub tworzenie modu do tabletop Simulator (który w większości zależy od interakcji człowieka w celu interpretacji i egzekwowania dowolnych reguł gry).

Myślałem o tym, czy jest możliwe / wykonalne w jakiś sposób zaimplementować mechanikę gry niezależnie od głównego kodu narzędzia?

Jest to absolutnie możliwe. Jednym ze sposobów często używanych w grach jest skryptowanie Lua .

Z powiązanego artykułu:

Lua został pierwotnie zaprojektowany w 1993 roku jako język do rozszerzania aplikacji, aby zaspokoić rosnące zapotrzebowanie na dostosowywanie w tamtym czasie.

Wiele gier korzysta z Lua. (Chciałbym utworzyć link, ale reputacja nowego użytkownika ogranicza liczbę moich linków).

Skrypty Lua można skompilować w czasie wykonywania. Oznacza to, że mogą to być (na przykład) pliki tekstowe znajdujące się w katalogu „skryptów” gry, które można łatwo edytować za pomocą moddera. Twoja gra ładuje je i uruchamia.

Widziałem skrypty Lua określające właściwości jednostek w grze. Oto przypadkowy przykład z TA Spring.

Ale chcesz „opisać wszystkie zasady”. Jest to teoretycznie możliwe, ponieważ Lua jest pełnym językiem, ale problem polega na tym, że musisz być wystarczająco przewidziany, aby podstawowy kod gry wiedział, że szuka skryptów rozszerzających jego zachowanie.

Na przykład możesz opracować grę karcianą, która umie szukać kart w katalogu „skryptów / kart”. To świetnie nadaje się do dodawania nowych kart lub edytowania istniejących. Ale jeśli później zechcesz rozszerzyć swoją grę o miniatury na siatce, będziesz musiał edytować kod podstawowy - żadna ilość błahostek Lua nie doprowadzi cię tam sama.

Uwaga: wychowuję Luę, ponieważ wiem, że jest powszechnie stosowana zarówno w grach, jak i oprogramowaniu do dostosowywania. Nie sugeruję, że jest to jedyne rozwiązanie, ani najlepsze dla potrzeb pytającego.

Istnieje ciągłość podejść i to, czy któreś z nich jest warte, będzie zależeć od tego, co próbujesz zrobić. W szczególności, jaką kontrolę chcesz zaoferować tweakerowi?

Na krańcowym końcu kontroli możesz po prostu pozwolić ulepszającemu zmodyfikować kod całej gry. W tym momencie zasadniczo opublikowałbyś kod narzędzia i co najmniej jeden przykład tego, jak go używać. Tweaker może zużywać tyle lub tyle kodu, ile chce.

Podejście, które oferuje nieco mniejszą kontrolę, to jakoś „zamrozić” kod narzędziowy (powiedzmy, kompilując go wcześniej) i pozwolić tylko ulepszającym wypełniać określone funkcje (wywołania zwrotne), ograniczając to, co mogą zrobić. W zależności od tego, co chcesz zrobić, to podejście może przybierać różne formy. Powszechną metodą byłoby umieszczenie całej części wyświetlacza w kodzie narzędziowym / głównym i wszystkich elementów mechanicznych w części podlegającej modyfikacji. Możesz też chcieć zachować część mechaniki w części „zamrożonej”, ponieważ gracze raczej nie chcą ich zmieniać, lub ich zmiana jest zbyt skomplikowana.

Na niskim kontinuum kontinuum pozwala tylko modyfikatorom zmieniać wartości w ustalonym zakresie. Przykładem może być plik danych, który pozwala wybrać kolory rzeczy w grze. Możesz jednak skorzystać z tego podejścia i nadal oferować wiele możliwości dostosowywania. Byłoby możliwe zdefiniowanie wyboru funkcji i umożliwienie komponentom dostosowywania ich tworzenia wywołań zwrotnych z poprzedniego podejścia, ale nie zezwalając im na definiowanie nowych. A może pomijasz część kompozycji i po prostu oferujesz skończony wybór.

Szczegóły wszystkich tych podejść i tego, który z nich pasuje do twojego przypadku użycia, zależą od rodzaju podstawowej gry, którą chcesz stworzyć, i od tego, ile kontroli chcesz zrezygnować. Należy pamiętać, że gry komercyjne zazwyczaj używają tylko drugiej i trzeciej metody, ponieważ pierwsza pozwala graczom tworzyć całkowicie oddzielne gry, co powoduje skomplikowane problemy z licencjonowaniem. Należy zauważyć, że ponieważ podejścia te stanowią kontinuum, drugie podejście może również wprowadzić te problemy.

Jest absolutnie możliwe oddzielenie reguł systemu od kodu, który je stosuje. Wolę tak ustrukturyzować swój kod w przypadku złożonych projektów, ponieważ ułatwia to dodawanie nowych reguł lub zmianę reguł później bez wprowadzania błędów w systemie bazowym. Błędy w silniku reguł można znaleźć szybciej niż błędy w systemie, w którym reguły i inny kod są mieszane razem higgledy-piggledy, ponieważ ten sam silnik reguł jest używany w kółko przez każdą regułę.

To, czy warto, zależy od złożoności systemu. Jakbym nie zawracał sobie głowy Pac-Manem, ale nie wyobrażam sobie pisania Dwarf Fortress w jakikolwiek inny sposób.

To zdecydowanie wykonalne. Jeśli warto, zależy od twoich celów.

Nie musisz wymyślać własnego języka ani pisać kompilatora, aby to działało.

Jeśli chcesz, aby twoja gra była łatwa do rozszerzenia, prawdopodobnie dobrym pomysłem jest skorzystanie z niej.

Prawdopodobnie dla ciebie jest więcej pracy, przynajmniej krótkoterminowo, aby stworzyć zrozumiałe systemy i ułatwić modyfikację.

Jedną z gier, która to robi, jest Rimworld (nie mam przynależności) i możesz zobaczyć i nauczyć się z tego, jak to zrobili, po prostu umieszczając wiele danych gry i mechanikę w plikach XML, które są w folderach gry, aby każdy mógł je zobaczyć i modyfikować. Rdzeń / silnik gry został wykonany przy użyciu Unity.

Istnieje również możliwość dalszego rozszerzenia / pogłębienia gry przez faktyczne kodowanie, wiem o tym mniej, ale możesz się dowiedzieć, patrząc na forum modów.

Możliwość modyfikacji sprawia, że ​​gra jest bardziej interesująca dla wielu osób i myślę, że przyczyniła się do jej sukcesu. Pozwala także twórcom oprogramowania na wprowadzanie dowolnych modyfikacji do podstawowej wersji gry, co przyspiesza rozwój i ulepsza grę, ponieważ otrzymują pomoc od wielu osób i mogą zdecydować się na rzeczy oparte na co jest popularne, co wydaje się działać itp.

I oczywiście, szczególnie dla małego niezależnego studia, mają setki ludzi wymyślających i testujących je, co jest pracą, której nie mogliby wykonać sami, ani prawdopodobnie nie zatrudnić do pracy.

Możesz przyjrzeć się projektowaniu obiektowemu . Python ma na to dobre wsparcie.

Grube książki są o tym pisane, co może być przerażające, gdy jesteś nowy, ale główne zasady są dość łatwe.

Chodzi przede wszystkim o to, że identyfikujesz, z jakimi obiektami pracujesz. Nie mówisz, o jakiej grze myślisz, ale takie rzeczy jak gracz, potwór, przedmiot, wyposażenie, broń, zbroja i tak dalej są typowymi przedmiotami.

Jeśli chcesz różnych typów gier, prawdopodobnie będziesz chciał obiektu gry, który dba o warunki zwycięstwa i tym podobne. Być może także obiekt mapy?

Czasami nie jest jasne, czy coś zasługuje na przedmiot, czy nie, np. Uszkodzenie. Jeśli nie spowodujesz uszkodzenia obiektu, kod będzie prostszy, ale uczynienie go obiektem ułatwia dostosowanie.

Podklasa: Zarówno broń, jak i pancerze są wyposażeniem. Urządzenia są przedmiotami. Prawdopodobnie istnieją inne rodzaje przedmiotów. Prawdopodobnie przyda ci się zdefiniowanie klasy Combatant, której gracze i potwory są podklasami.

Chodzi o to, że na przykład broń będzie miała wiele cech wspólnych ze wszystkimi innymi typami przedmiotów, będzie miała wagę, rozmiar i inne podobne właściwości.

Tak więc podklasowanie pozwala powiedzieć, że „Broń jest podobna do innych Przedmiotów, ale dodatkowo można ją wykorzystywać, wpływają na zadawane przez nią obrażenia itp.”

Podklasowanie pozwala także twórcom modów powiedzieć: „Mój nowy typ broni jest podobny do broni standardowej, tyle że ...”

Następnie musisz zdecydować, który obiekt jest odpowiedzialny za co. To nie jest tak proste, jak się wydaje, i powinieneś się nad tym zastanowić. Niewłaściwe wybory nie wpłyną znacząco na podstawową grę, ale utrudnią dostosowanie.

Dopóki majsterkujesz samemu, możesz zmieniać rzeczy, ale w momencie, gdy udostępnisz coś publicznie, wprowadzanie zmian staje się znacznie trudniejsze! Ludzie będą tworzyć mody, które zależą od tego, że rzeczy są takie, jakie są teraz. Nawet błędy. Ludzie będą pisać mody, które zależą od błędów pozostających w kodzie. Jeśli zmienisz rzeczy, te mody się zepsują, a moby linczu pojawią się w twoim domu.

Na przykład:

Gracz uzbrojony w Broń atakuje Potwora noszącego wiele Pancerzy. Odbywa się to w określonym trybie gry i na określonej mapie.

Obaj Walczący mogą posiadać Umiejętności takie jak Trafienie Krytyczne i Unik.

Który obiekt jest za co odpowiedzialny?

Nie ma na to jednej właściwej odpowiedzi. Wiele zależy od tego, na jakie dostosowanie chcesz zezwolić.

Jeśli nigdy nie wołasz obiektu (np. Mapy), obiekt ten nie może w żaden sposób zmienić ataku.

Po podjęciu wszystkich tych decyzji udokumentuj je . Napisz „Podręcznik Moddersa”, który dokładnie wyszczególnia, jakie metody można modyfikować w każdym obiekcie, jakie parametry przyjmują, co powinny zwrócić itd., Itd., Itd.

Powodzenia!

Prostym sposobem na uzyskanie podstawowego wsparcia dla tego byłoby rozdzielenie większości wartości liczbowych na jeden lub więcej osobnych plików tekstowych, aby umożliwić zainteresowanym osobom dostosowanie ich do zapomnienia.

Na przykład wspomniałeś o grach stołowych; jeśli masz grę opartą na D&D, możesz mieć weapon_damageplik zawierający linie takie jak Battleaxe: 1d12. Twój kod narzędziowy odczytuje ten plik i za każdym razem, gdy zostanie wyrządzony przez Battleaxekod szkody, generate a number from 1-12, 1 time(s)doda go. Battleaxe: 4d6Zamiast tego poprawiono wiersz do przeczytania generate a number from 1-6, 4 time(s)i dodałem go. Podobnie, możesz mieć folder, Creaturesa wewnątrz masz plik dla każdego stworzenia, w tym linie takie jak AC: 12; następnie dodanie nowych plików do tego folderu stworzyłoby nowe stworzenia. Można to zrobić nawet dla klas postaci, typów terenu, mnóstwa rzeczy.

Ten styl dostosowywania bez kodu może być nadal bardzo wydajny i obejmować wiele elementów Twojej gry. Jednak tak naprawdę nie pozwala użytkownikowi na wprowadzanie zmian, które nie zostały wyraźnie określone. Na przykład, możesz pozwolić Sneak Attack: [damage]na to, aby otrzymać dowolną Istotę lub Klasę w celu dodania [damage]do dowolnego ataku, który spełnia warunki Ataku Podstępnego. Możesz nawet podać sposoby zmiany warunków, na przykład „za każdym razem, gdy atakujesz z ukrycia” lub „za każdym razem, gdy flankujesz” lub „kiedy masz przewagę”. Jeśli jednak użytkownik zdecyduje, że chce, aby ataki typu „ukradkiem” były „Kiedy wykonujesz rzut ataku, możesz również rzucić ukrycie wbrew postrzeganiu celu. Jeśli oba rzuty się powiodą, dodaj obrażenia ataku podstępnego”

Jeśli chciałeś, aby użytkownik mógł dodać do gry zupełnie nowe zachowanie bez potrzeby kodowania na tym samym poziomie co programista, to jak wspomnieli ludzie, zasadniczo szukasz silnika gry lub osobnego języka programowania. W przypadku modyfikacji, które nie wymagają znajomości kodowania, tekstowe pliki danych i struktury folderów mogą nadal zapewniać wiele opcji. Jeśli chcesz, aby użytkownicy zmodyfikowali więcej, musisz poprosić ich o naukę lub znajomość języka programowania.

[Jestem programistą od dziesięcioleci, ale nie mam doświadczenia w tworzeniu gier, więc może branża gier przyjmuje inne podejście, może z dobrych powodów ...]

Twoje podejście absolutnie ma dla mnie sens. Rdzeń zapewnia podstawowe funkcje, na których opiera się mechanika i reguły, więc jest to interfejs API, który ma być używany przez komponenty wyższego poziomu.

Podczas projektowania interfejsu API moją ulubioną wskazówką jest stworzenie języka, w którym chcesz wyrazić kod wyższego poziomu (oczywiście z ograniczeniami składniowymi twojego języka programowania).

Dobrym podejściem byłoby więc napisanie hipotetycznych reguł i mechaniki w taki sposób, w jaki chcesz je wyrazić (oczywiście przy użyciu składni Pythona), a tym samym dowiedzieć się, co chcesz, aby podstawowy interfejs API zapewniał regułom i mechanice warstwy.

I oczywiście polecam zajrzeć do skryptów istniejących gier, aby dowiedzieć się, co robią.