[GM:S] CIVE

[sunflower]

Ostatnimi czasy po powrocie do pracy nad grami z okazji GMDuela zaczęłam sobie konstruować taki system, co to pomagałby mi z różnymi elementami gry. W końcu po rozważaniach takich i owakich wyodrębniłam cztery elementy, które byłyby szczególnie przydatne z różnorakich względów, co do których nie jestem pewna czy jeszcze je pamiętam, ale pewnie w trakcie tworzenia jeszcze je sobie przypomnę. ^^'

 

System powstaje w GM:Studio, zaś wszelkie komentarze do niego są w języku angielskim. Jest ku temu kilka powodów:

- obcokrajowcom pewnie też mogłoby się przydać

- nie ma bawienia się z polskimi znakami, które może są, a może ich nie ma

- wychodzę z założenia, że jak komuś opłaca się płatna wersja GM:S (która jest wymagana do prawidłowego działania systemu, choćby z powodu limitu obiektów, o ile się nie mylę), to pewnie i w języku wyspiarzy coś tam kojarzy (choć akurat to założenie nie jest do końca pewne...? ^^')

 

Sporo części jest nadal w budowie, i choć sporo zostało ukończone, nadal zostało sporo drobnych rzeczy do dorobienia (np. dokomentowanie co niektórych miejsc, destruktory, wstrzymywanie i wznawianie ciągów poleceń, co jest kluczowe dla dialogów RPGopodobnych itp.), a poza tym jakaś przykładowa gierka, a i pewnie podczas użytkowania mogą wyniknąć jakieś paskudne błędy; póki co testowałam tyle, żeby sprawdzić, czy to, o co mi głównie chodziło działa tak jak powinno, a nie chce mi się wymyślać wszystkich rodzajów niebezpiecznych sytuacji; jeśli to to naprawdę jest komuś potrzebne, to ten ktoś to zrobi i błąd sam wypłynie.

 

 

Efekty dotychczasowej pracy można ściągnąć tutaj: https://gmclan.org/up6455_4_CIVE_Example_gmx.html

Na razie to to nie wygląda na zbyt wiele (ot, taka tam konsolka na której pojawiają się wyniki potrójnych rzutów kością), ale to głównie dlatego, że jeszcze nie dodałam mechanizmu wstrzymywania i wznawiania ciągów poleceń, a poza tym zrobienie aplikacji testowej pokazującej możliwości poszczególnych funkcji samo w sobie nie jest rzeczą łatwą.

 

 

A jakie komponenty wchodzą w skład mojego silnika? Są to:

 

Kontroler poleceń - przechowuje u siebie wątki mogące wywoływać poszczególne sekwencje, a także drzewa składające się z ciągów poleceń. Istotną cechą jest możliwość przechowywania poleceń, które mogą zostać wywołane w dowolnym późniejszym momencie i w odpowiednich grupach (w zależności od kontekstu mogą to być fragmenty algorytmu sztucznej inteligencji, linie dialogowe itp.). Parametry poleceń mogą być także uzyskiwane w trakcie wywoływania (np. uzyskanie obecnego imienia postaci albo losowego numeru).

Kontroler poleceń korzysta ze "zdarzeń" (w rozumieniu tutejszego kontrolera zdarzeń); w istocie każde polecenie jest informacją o zdarzeniu, które należy wywołać.

 

 

Kontroler zdarzeń - właściwie to ze zdarzeniami ma głównie tyle wspólnego, że tak to sobie nazwałam. Pozwala na przypisanie skryptowi i jego parametrów odpowiedniej nazwy, np. można przypisać "gadanie" do skryptu "mowa" z parametrem "gadula" i "rozmawianie" do skryptu "mowa" z parametrem "rozmowca". Albo coś.

Jeśli skrypt ma działać prawidłowo jako "zdarzenie", powinien korzystać z odpowiedniej notacji; w szczególności, arg(n) zamiast argumentN i args_count() zamiast arguments_count. To dlatego, że podczas wywoływania skryptu nie da się przekazać bliżej nieokreślonej liczby argumentów jako kolejne parametry innego skryptu.

 

 

Kontroler instancji - umożliwia rejestrację instancji pod odpowiednimi nazwami; nazwy te wykorzystuje się m. in. do wybrania odpowiedniego obiektu wywołującego zdarzenie (np. wywołanie zdarzenia "leci" przez instancję obj_kos powoduje wywołanie tego przez rzeczonego kosa, a wywołanie "rakieta.leci" - przez obiekt nazwany rakietą).

 

Kontroler zmiennych - umożliwia gromadzenie zmiennych w specjalnie przeznaczonej drzewopodobnej strukturze. Szczególnie przydatne, jeśli zmiennych jest od groma i chciałoby się je uporządkować, a przeglądanie mapy 1000 zmiennych w celu znalezienia tej jednej też nie brzmi specjalnie fajnie.

 

Konsola - nie wchodzi w skład głównego systemu, ale jest bardzo praktyczna jeśli chcę sobie posprawdzać wartości, a akurat nie mam ochoty na zasiewanie kodu okienkami typu show_message; wówczas zasiewam go printami. Niby i jedno i drugie zaśmieca kod, ale taka konsolka może przedstawić to wszystko naraz i pozwala do tego wrócić w miarę dowolnym momencie.

 

Jakieś pytania, uwagi, życzenia? Warto nad tym dalej pracować? ^^'

[kaszan88]

Cudnie skomplikowałaś opisy komponentów :D

Na dzień dobry " przechowuje u siebie wątki mogące wywoływać poszczególne sekwencje, a także drzewa składające się z ciągów poleceń" i już jestem zdezorientowany :D

 

Myślę, że w opisie Kontrolera Instancji chciałaś powiedzieć coś innego. Chodzi tam o to, że do instancji jakiegoś obiektu np. ptaszek można odwołać się poprzez jego nazwę a nie id tak?? :) W opisie lepiej byłoby napisać obj_wrobel.leci i obj_kos.leci. Widać wtedy, że to instancje tego samego obiektu. Rakieta i ptaszek mają wspólne cechy, ale na pewno nie mogą być tym samym obiektem :D

 

Na czym polega Kontroler Zmiennych?? Chodzi w nim o to, że mogę do niego zapisać np zmienną z jakiegoś obiektu?

 

Kontrolera Poleceń nie rozumiem ani troszkę :)

 

Mam kilka pytań, ale nie wiem, czy chce Ci się na nie odpowiadać ;)

 

Zabawne, że użyłem 800 razy więcej emotek jak Ty xD

[sunflower]

Ja korzystam z emotek, ale takich co mi się nie zamieniają na obrazki. :<

 

Co do kontrolera instancji, to tak jak mówisz, możesz odnosić się do instancji poprzez nazwę zamiast przez ID; w szczególności, inne komponenty mogą się dobierać do tej instancji przez jej nazwę.

 

 

To co wtedy chciałam opisać kosem i rakietą, to na czym polega interakcja kontrolera zdarzeń i kontrolera instancji. Dla przykładu, mamy trzy instancje obiektu obj_kos, nazwane np. "wrona", "koliber", "pingwin", tak żeby się nie myliło. Oprócz tego jest też instancja obj_rakieta, nazwana "RAKIETA". Załóżmy, że zdarzeniu "lot" przypisano skrypt machnij_skrzydlami dla obj_kos, a zdarzeniu "lot" przypisano skrypt odpal_silniki. Poza tym przykład zawiera skrypt cevents_call, który pozwala na wywołanie odpowiedniego zdarzenia. Oto co będzie się działo:

- wywołanie cevents_call("lot") przez dowolną instancję obj_kos spowoduje, że rzeczona instancja wywoła skrypt machnij_skrzydlami

- wywołanie cevents_call("lot") przez dowolną instancję obj_rakieta spowoduje, że ta instancja wywoła skrypt odpal_silniki

- wywołanie cevents_call("wrona.lot") spowoduje, że instancja obj_kos nazwana "wrona" wywoła machnij_skrzydlami, nawet jeśli samo cevents_call zostało wywołane np. przez rakietę

- wywołanie cevents_call("RAKIETA.lot") spowoduje, że instancja obj_rakieta nazwana "RAKIETA" wywoła odpal_silniki, nawet jeśli samo cevents_call zostało wywołane przez kosa nazwanego kolibrem

Czyli w ogólności:

- to co jest przed kropką to nazwa instancji, która ma wywołać zdarzenie, rozpoznawana przez kontroler instancji

- to co jest po kropce to nazwa zdarzenia do wykonania

- jeśli nie ma kropki, to nazwa zdarzenia jest tym, co podano, a instancja która wywołuje zdarzenie jest tą samą, co wywołuje cevents_call

- cevents_call jest na tyle móndry, że rozpoznaje rodzaj obiektu, do którego należy wołająca instancja (określona wyżej wymienionymi sposobami), i na jego podstawie wie, który skrypt wywołać (czyli nie każe kosowi odpalać silników czy rakiecie machać skrzydłami)

 

 

Kontroler zmiennych przechowuje zmienne, które o ile dobrze wiem powinny się zachowywać w miarę globalnie. Przechowuje te zmienne w strukturze drzewiastej, albo plikowo-folderowej (gdzie folder to gałąź przechowująca zmienne i dalsze gałęzie, a plik to liść z nazwą i zawartością zmiennej). Na przykład tak mogłaby wyglądać struktura takiego drzewka zmiennych:

> ROOT

>> Ekwipunek

>>> Pierścienie

>>>> Lewy="jeden by wszystkimi rzadzic"

>>>> Prawy="nic"

>>> Bron="halabarda 5d6+3"

>>> Zbroja="koszula+4"

>> Questy

>>> Obecne

>>>> Olaboga="zostało 7 labogow"

>>> Skończone

>>>> CzyscicielKanalow="koniec"

Pogrubione są nazwy gałęzi, a pochylone nazwy zmiennych z wartościami. Zauważ, że gałąź "Ekwipunek" zawiera podgałąź "Pierścienie", ale też dwie swoje zmienne "Bron" i "Zbroja". W sumie to tak jak w jednym folderze może być ileś podfolderów i ileś plików bezpośrednio podlegających. ^^'

Taka struktura może okazać się pożyteczna przy tworzeniu większych projektów, np. RPGów (a przynajmniej tak mi się zdaje). Ponadto inne komponenty będą mogły się dobierać do tych zmiennych z nazwy, co bardzo się przydaje chociażby do generowania parametrów poleceń w trakcie wykonywania (np. chcesz w trakcie dialogu wyświetlić obecnie posiadaną broń, to wtedy jako jeden z parametrów podajesz nazwę zmiennej).

 

 

Napisałabym jeszcze o kontrolerze poleceń, ale to jest dość długa historia i żeby pokazać jakie zastosowania to to może mieć, to też musiałabym się nieco rozpisać. ^^'

A te pytania, które masz, to jakie są? O.o'

[kaszan88]

Nie czepiam się, ale pingwin czy wrona nie są kosem :lol: Mogą być instancją obiektu obj_ptaszek.

 

Moje pierwsze pytanie może zabrzmieć głupio. Ten silnik ma pomóc w debugowaniu i testowaniu aplikacji, czy ma być wykorzystany jako jej szkielet??

[sunflower]

Tak, pingwin i wrona nie są kosem. Dzięki specjalnemu pominięciu rozpoznawania znaczeń system całkowicie akceptuje, jeśli nazwa instancji nie ma specjalnego sensu w odniesieniu do nazwy obiektu, co umożliwia programistom kreatywne, nieskrępowane sztywnymi konwencjami pisanie kodu!1

 

Zasadniczo to, co zamierzam zrobić, to szkielet do budowy kolejnych, bardziej doprecyzowanych silników. Jak już uda mi się to zbudować, to pewnie okaże się, że potrzebuję kolejnych komponentów w zależności od gier, i wtedy być może będę te komponenty załączać jako osobne zestawy obiektów i skryptów. To, co teraz ma powstać, może się np. okazać bardzo praktyczne przy tworzeniu dialogów RPGowych, choć żeby takie dialogi dobrze wyświetlać, to wypadałoby z kolei zrobić kolejny komponent odpowiedzialny za pokazywanie dialogów (komunikując się z kontrolerem poleceń; przy rozpoczęciu dialogu kontroler poleceń ładuje do wątku zbiór kwestii dialogowych, każe je po kolei wyświetlać komponentowi dialogowemu, komponent dialogowy pyta o następne kwestie jeśli skończył z obecną, a po przejściu przez wszystkie kwestie dialog się kończy). Bardzo prawdopodobne, że zrobię też silniki skrojone pod bardziej szczegółowe rodzaje gier.

 

Więc odpowiadając nieco krócej na to pytanie: ten silnik ma być wykorzystano jako szkielet do szkieletów aplikacji, w pewnym sensie; sam z siebie nie stanowi czegoś co wystarczy do stworzenia gry, ale może okazać się bardzo praktyczny w wielu mniej lub bardziej znaczących zastosowaniach.

O ile nie piszę tego pod debugowanie/testowanie aplikacji, to zastosowanie też zostało poruszone - istnieje możliwość korzystania z konsolki, która przechowuje ostatnie logi i może je wyświetlić w razie potrzeby. Z doświadczenia wiem, że czasami takie printy lepiej działają niż np. takie show_message (choćby ze względu na możliwość przejrzenia poprzednich logów).