Podstawowa makieta systemu gry

Uwaga! Ta strona może zawierać nieaktualne już informacje o projektowaniu VMB z użyciem Python oraz Django CMS (jako początkowych założeń projektu). Obecnie VMB jest projektowane przez Drupal CMS, PHP, jQuery, itp. Informacja na ten temat.

Zachodzi potrzeba stworzenia prostej, bardzo ograniczonej makiety systemu gry, aby stworzyć pierwszy model wyjściowy do dalszej rozbudowy.

czyli co potrzebujemy :

Z projektowych rzeczy:

Wybierzmy 3-7 podstawowych kategorii, do których przypiszmy 5-10 obiektów. Dobrze jakby na tych obiektach można było wykonywać jakieś działania, żeby posiadały kilka atrybutów

Avatar - interakcje z tymi obiektami co wyżej, kilka-klikanaście parametrów.

Scenariusz - mimo że będzie to prosty i ubogi świat to fajnie jakby spełniał jakiś prosty scenariusz.( może naprawa i przeżycie do czasu pełnej naprawy czegoś)

Z technicznych:

Czy ktoś ma dostępny jakiś serwer na którym moglibyśmy to potestować? Mogę podesłać co byśmy na nim potrzebowali na chwile obecną.
Czy ktoś posiada jakieś umiejętności graficzne lub ma znajomego grafika który mogłby tutaj pomóc? Wygląd niby nie jest ważny ale jak już sie zabieramy to fajnie jakby podstawy były dobrze zaprojektowane.

slawek

Serwer jest. Muszę tylko wszystko zorganizować. Dam znać na dniach.

Niedługo damy też kod pod system kontroli wersji (więcej: http://vmb.skyfigure.com/node/83 oraz http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html)

Czy ktoś posiada jakieś umiejętności graficzne lub ma znajomego grafika który mogłby tutaj pomóc? Wygląd niby nie jest ważny ale jak już sie zabieramy to fajnie jakby podstawy były dobrze zaprojektowane.

Ja mogę zająć się grafiką oraz szablonem 'template system' (http://www.djangobook.com/en/2.0/chapter04/).
Tylko, że na początek, robimy bardzo skromnie. Najważniejsze będą elementy interfejsu użytkownika, czyli pasek stanu, kolumna z atrybutami awatara oraz obiektów itp. Sama strona może być na tym etapie biała.

bardzo dobrze:)

Serwer powinnien spełniać kilka warunków conajmniej : dostęp przez ssh, dostęp do Crontab, zainstalowany python (najlepiej 2.5), dobrze jakby było django zainstalowane (conajmniej 1.0.2, a najlepiej 1.1), mod_wsgi w serwerze apache (tak będzie chyba najszybciej działać).

Launchpad wygląda ok, nie mam doświadczenia z Baazarem, ale myśle damy rade:)

Grafika na początku to faktycznie, chodzi o pare zakładek, kilka tabelek z atrybutami, więc w sumie to nie jest problem na chwile obecną, falstart z mojej strony :)

Zostaje serwer...

slawek

Co do zakładek - przyjmijmy pełną symulację, a więc załóżmy, że gracz zna swoje parametry, bo jest podłączony do biomonitora. Ale żeby poznać np. parametry innego obiektu albo ilość zasobów w bazie nie włączamy zakładki interfejsu, tylko awatar idzie do komputera, magazynu albo bierze do ręki zestaw analityczny i dopiero wtedy udostępniają się te dane (czyli jest to zakładka "wyświetlacza używanego aktualnie przedmiotu", a nie zakładka managera bazy). Nie róbmy managera, w którym jakiś nadrzędny byt czuwa nad bazą i w każdej chwili zna każdą jej myśl :). Niech się gracze napracują trochę. Bo czasem zdobycie jakiegoś rodzaju informacji może być sprawą życia i śmierci - to jest właśnie element "walki" w grze.

Zarząd Mars Society Polska
www.marssociety.pl

W całej rozciągłości popieram. Idźmy w stronę gry przygodowej niż w stronę "Liga Polska Manager" :)

$FM->Read("First_chapters"); w moim przypadku generuje błąd :D

...awatar idzie do komputera, magazynu albo bierze do ręki zestaw analityczny i dopiero wtedy udostępniają się te dane (czyli jest to zakładka "wyświetlacza używanego aktualnie przedmiotu", a nie zakładka managera bazy)

Dokładnie!

Trzeba wymyślić jakiś obiekt (bufor), w którym będą trzymane dane (albo obiekty), które są aktualnie dostępne dla Awatara, a co za tym idzie, mogą pojawić się w interfejsie. Interfejs będzie ten obiekt odpytywać, przy każdym wyświetleniu strony.
Może informacje te powinien posiadać obiekt Awatar i jego odpytywać o te dane.
Co o tym myślicie?

Na początek zakładamy, że wszystkie atrybuty obiektu będą wyświetlane. Nawet takie, które wymagają od Awatara użycia dodatkowych obiektów (np. przyrządu pomiarowego). Czyli Awatar wie wszystko o obiekcie przez jego dotknięcie. Myślę, że jest to dobre uproszczenie na teraz.

Chyba tak. A potem się założy jakieś filtry na te dane - czyli "narzędzia awatara".

Zarząd Mars Society Polska
www.marssociety.pl

A może po prostu założyć, że dla Awatara dostępne są obiekty, które ma przy sobie. Poponuję, aby każdy obiekt miał właściwość [tablicę] opisującą przedmioty, które obiekt zawiera, oraz właściwość prywatą, przy pomocy której można dla danego typu obiektu określić maksymalną ilość elementów tablicy. Przyda się to zarówno w przypadku Awatara (kieszenie i inne sloty), jak i w przypadku pojazdów (sloty na oprzyrządowanie) oraz budynków (wszystkie rzeczy znajdujące się w budynku). Ponadto dostępne dla Awatara powinny być również obiekty przy których stoi, zwrócony do nich przodem (do dyskusji, bo równie dobrze można przyjąć że przed Awatarem i po jego bokach). Nie trzeba będzie wówczas tworzyć kolejnego obiektu (bufora), gdyż dostępne interakcje i informacje o przedmiotach będą wprost wynikały z "osprzętowienia" Awatara oraz jego pozycji na mapie. Tak sobie gdybam :)

$FM->Read("First_chapters"); w moim przypadku generuje błąd :D

Czyli nie wiem, czy dobrze rozumiem, ale ja tworząc propozycję interakcji (wystarczy kilka), zakładałem tak:
Awatar "używa" przedmiotu (obiektu) w ten sam sposób, niezależnie czy ma go przy sobie (przenośny), czy przed sobą (stały). Przenośny i stały różnią się tylko lokacją w układzie odniesienia, czy jakoś...
Może go użyć w formie dozwolonej akcji pozytywnej ("działaj pozytywnie") i będzie to np. "lecz", jeśli stoi przy pacjencie, albo "napraw", jeśli stoi przy generatorze. Czyli skutek wynika nie z wyboru rodzaju interakcji, ale z właściwości samego obiektu. Nie można leczyć generatora.
Czyli każdy obiekt ma dozwoloną listę skutków, które bezpośrednio przekładają się na stan jego parametrów. Generator nie ma zdrowia i nie można go leczyć.
Ale zasada jest identyczna.

I to samo powinno tyczyć się samego awatara. Nie można go naprawić.
I oczywiście działa to także w drugą stronę - negatywne działanie.

?

Dobrze rozumiem?

Zarząd Mars Society Polska
www.marssociety.pl

Ależ oczywiście, że można leczyć generator - nazywa się to naprawą :D Akcja jest, de facto, ta sama - różnica polega jedynie na tym, że nazwa akcji w przypadku naprawiania innego Awatara brzmi "lecz", zaś w przypadku wszystkich pozostałych przedmiotów - "napraw" :) Nie przekombinowujmy - jednym warunkiem można sprawdzić, czy w menu ma być "lecz" czy "napraw" - wystarczy tylko stwierdzić do czego Awatar stoi zwrócony przodem. Dodatkowo dostępność akcji lecz/napraw powinna być uwarunkowana posiadaniem przez Awatara (w "kieszeni" - tu przypomnę, co pisałem o właściwości "zawiera" każdego z obiektów) apteczki lub zestawu naprawczego. Naturalnie nie da rady wykonać akcji "lecz" na innym Awatarze, posiadając w "kieszeni" tylko zestaw naprawczy - konieczna jest apteczka. Zatem - w sposób naturalny i automatyczny - kształtujemy ścieżkę postępowania dla użytkownika: jeśli chce naprawić cokolwiek, najpierw musi wziąć zestaw naprawczy, bo inaczej akcja "napraw" nie będzie dostępna. Jest to proste do zakodowania, a jednocześnie bardzo życiowe :) Można pokusić się o panel "inventory" - rzeczy, które Awatar ma przy sobie - wówczas akcja lecz/napraw (jak również wszelkie inne akcje, wynikające z użycia niesionego przedmiotu) byłyby akcjami przedmiotu, a nie Awatara. Krótko pisząc, wybierałoby się w panelu apteczkę, pojawiałyby się dwie dostępne akcje: 1. "lecz awatara, który znajduje się na przeciwko", oraz 2. "lecz siebie". Pozwoliłoby to uniknąć konieczności każdorazowego sprawdzania pełnego garnituru możliwych akcji - część z nich wynikałaby wprost z bezpośredniego działania użytkownika (w tym przypadku kliknięcie apteczki w panelu "inventory").

Awatar "używa" przedmiotu (obiektu) w ten sam sposób, niezależnie czy ma go przy sobie (przenośny), czy przed sobą (stały). Przenośny i stały różnią się tylko lokacją w układzie odniesienia, czy jakoś...

I tak, i nie. Przedmiot przenośny Awatar ma przy sobie - przedmiot ten nie ma lokacji, bo nie jest umieszczony na mapie. Jest za to (jako jedna z możliwych X pozycji) zawarty w właściwości (tablicy) "posiada" (lub "zawiera" - jak zwał tak zwał) Awatara (powinna być to jedna z zupełnie podstawowych właściwości klasy bazowej Obiekt). Zatem - każdorazowo - garnitur dostępnych akcji powinien być określany na podstawie lokacji Awatara (co ma przed sobą - okrojony zestaw poleceń typu idź, przesuń, podnieś - generalnie akcji, które nie wynikają z użycia niesionych przedmiotów) oraz lokacji i przedmiotów, które "posiada" (poprzez kliknięcie na dowolny niesiony przedmiot w panelu "inventory").

Proponuję również, żeby w przypadku Awatara nie ograniczać liczby niesionych przedmiotów ich ilością, lecz sumą mas. Ograniczenie ilością ma sens w przypadku pojazdu, gdzie można założyć, że dostępnych jest np. 5 punktów mocowania ładunku/oprzyrządowania. Co w żaden sposób nie zabrania podwieszenia do jednego z punktów mocowania jakiegoś zasobnika, który z kolei (ponieważ po bazowej klasie Obiekt dziedziczy również własność "zawiera") pozwoli zmieścić w nim np. 3 przedmioty :) Tutaj istotna uwaga - wprowadzając obiekt "pojemnik" będziemy również musieli wprowadzić wymiarowanie - nie można włożyć czegoś większego w coś mniejszego ;)

$FM->Read("First_chapters"); w moim przypadku generuje błąd :D

Ok, serwer jest - "sebzur" się tym zajmie.

Wstrzymujemy jednak dalsze działania, do czasu ustalenia technologii wykorzystywanych przez VMB, bo jest to jeszcze sprawa dyskusyjna.

Zobowiązuję się wstępnie podzielić nadesłane przez Mateusza obiekty na kategorie. Podział przedstawię Wam na sierpniowym spotkaniu, jako wyjście do wspólnej dyskusji - może uda się wprowadzić jakąś optymalizację zaproponowanego przeze mnie podziału. Pewne jest, że podział należy wykonać tak, aby możliwie najlepiej wykorzystać mechanizm dziedziczenia. Atrybuty obiektów łatwiej będzie wypisać dla grup. To samo dotyczy czynności.

W sprawach graficznych mogę coś pogmerać - w ramach skromnych umiejętności i czasu :) Wolałbym jednak nie robić tego całkiem samemu, bo - najnormalniej - nie udźwignę :D

$FM->Read("First_chapters"); w moim przypadku generuje błąd :D

to bym się skupił na obmyśleniu maksymalnie prostego scenariusza z daną ilością obiektów. Zrobienie takiej makiety to z 2-3 dni max, chyba nie ma co czekać z tym do spotkania.

slawek

OK, róbcie Panowie makietę, a ja sobie będę po cichu dłubał pełną listę obiektów. Wolę tak, bo na większej "populacji" pewne rzeczy narzucają się same, zaś wychodząc od zbyt małego zbioru zdarza się, że później trzeba "sztukować" i dorabiać na przysłowiowy "kijek i sznurek" ;)

$FM->Read("First_chapters"); w moim przypadku generuje błąd :D

Przemieszczenie się po bazie: http://vmb.skyfigure.com/node/112