Lista parametrów awatara

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.

Warto sporządzić listę parametrów awatara (postaci, którą steruje gracz).

- Imię i nazwisko (stałe)
- Wiek (stałe)
- Posiadana wiedza: medycyna, meteorologia, biologia [dotycząca uprawy roślin], gastronomia, geologia, mechanika [dotycząca naprawiania]; (na początku ustalane; potem możliwe rozwijanie np. czytając książkę nt. geologii, spadania póki co raczej nie trzeba przewidywać)
- Kondycja (na początku ustalane; systematyczny trening powoduje wzrost, natomiast nieczęste wykonywanie czynności fizycznych powoduje spadek)
- Zmęczenie fizyczne (każda czynność [oprócz leżenia, czytania, spania, jedzenia] powoduje wzrost, natomiast wspomniane w nawiasie kwadratowym powodują spadek parametru)
- Zmęczenie psychiczne (czytanie, zdobywanie i wykorzystywanie wiedzy powoduje wzrost, natomiast reszta czynności powoduje spadek parametru)
- Potrzeba skorzystania z WC (wzrasta systematycznie przez cały czas, spada podczas wizyty w WC)
- Poczucie higieny (wzrasta podczas mycia się, spada podczas wykonywania prac fizycznych)
- Samopoczucie (wzrasta podczas kontaktu z rodziną, pozytywnych rozmów z innymi członkami załogi, spadek podczas długiego przebywania w samotności, kłótni z załogą)
- Stan żołądka (wzrasta podczas spożywania posiłku, systematycznie spada przez cały czas)
- Aktualna pozycja (w trzech osiach - x, y oraz z względem całego środowiska; potem, według danych z tabeli z tych wartości można ustalić w czym przebywa)

O, idziemy do przodu. Z kilkoma parametrami osobiście bym dyskutował, a kilka dodał.
Zastanawiam się, czy dobrym rozwiązaniem nie jest przypadkiem zrównanie w prawach awatara i pozostałych obiektów bazy. Czyli sporządzenie listy wszystkich parametrów wszystkich obiektów (skały, zestawu narzędziowego, krzesła, skafandra, powietrza, wody itp), z tym że dany obiekt może mieć w niektórych miejscach wpisane 0. (np. skała będzie miała kondycję psychiczną 0, ale będzie taką samą kategorią fizycznych obiektów, jak awatar. Przez to nie musimy traktować awatara w oderwaniu od reszty świata. Jego interakcje ze środowiskiem są takie same, jak np. interakcja obiektu-promieniowanie z obiektem-roślina.

Zarząd Mars Society Polska
www.marssociety.pl

Moim zdaniem - to nie jest zbyt dobry pomysł. Ucierpi przede wszystkim wydajność, ponieważ każdy kamień będzie miał po 30 czynników, choć faktycznie używane będzie tylko kilka.

Co do polemizowania: przecież po to powstał ten temat :). Musimy dopracować listę, ponieważ ta którą podałem jest tylko wstępną wersją, stworzoną w ledwie 10 minut.

Przygotowuję wstępną listę >>wszystkich<< obiektów w grze, wychodzi koło 150-200, mają na razie luźno nadane kategorie, ale to tylko w celach porządkowych. Obiekty obejmują więc naturę, elementy bazy stałe, przedmioty przenośne, elementy bazy ruchome (drzwi, manipulatory), pojazdy i zasoby. "Repertuar" wyposażenia nie jest zbyt rozbudowany.

Już ciekawym eksperymentem będzie nadanie tym przedmiotom realnych mas i zsumowanie - będziemy mieli pierwszy szacunek masy całej misji. Wiadomo, że każda misja kosmiczna musi być "jak najchudsza".

Zarząd Mars Society Polska
www.marssociety.pl

Na razie taka lista. W załączniku zalążek pliku XLS zawierający całe środowisko - czyli także arkusze z interakcjami (relacjami) i parametrami. Zacząłem powoli wypełniać reguły współwystępowania obiektów w tej samej lokacji (0/1), ale to bardzo wstępna symulacja, będzie wymagać wielokrotnej weryfikacji.

W pliku obiekty podzielone są na kategorie, ale kategorie nie są wiążące.

Awatar
Regolit
Kamień
Depozyt1
Depozyt2
Depozyt3
Lód wodny
Lód suchy
Krater mały
Meteoryt
Osuwisko
Rynna
Pył
Wiatr
Promieniowanie
Eksplozja - moduł
Ogień - moduł
Światło słoneczne
Atmosfera Marsa
Sygnał radiowy
Sygnał innego typu
Roślina jadalna 1 - moduł
Roślina jadalna 2 - moduł
Roślina jadalna 3 - moduł
Roślina użytkowa 1 - moduł
Roślina użytkowa 2 - moduł
Zbiornik z chlorellą
Zbiornik kompostowy
Zestaw analityczny geo
Zestaw analityczny bio
Zestaw analityczny meteo
Zestaw ambulatoryjny
Zestaw do pomiarów technicznych
Komputer z dużym ekranem
Zestaw siłowni
Maszt zewnętrzny duży z systemem łączności i uniwersalnych czujników
Projektor ścienno-sufitowy
Ściana działowa - moduł
Ściana sztywna - moduł
Ściana elastyczna - moduł
Podłoga - moduł
Okno sztywne - moduł
Okno elastyczne - moduł
Blat standardowy - moduł
Koja
Blat niski
Szafka 1
Szafka 2
Lodówka
Chłodnia
Zbiornik ciśnieniowy duży
Bateria słoneczna
Akumulator duży
Zestaw kuchenny
Zestaw warsztatowy
Generator prądu na metan
Reaktor nuklearny
Węzeł energetyczny główny
Węzeł energetyczny pomocniczy
Terminal usługi - zasilanie
Przewód energetczyny - moduł
Reaktor Sabatiera
Przewód reaktora Sabatiera - moduł
Główny węzeł systemu wymiany ciepła i odzysku energii
Pomocniczy węzeł systemu wymiany ciepła i odzysku energii
Terminal wejścia systemu wymiany ciepła
Terminal usługi - grzanie
Terminal usługi - chłodzenie
Generator prądowy systemu odzysku energii
Przewód systemu wymiany ciepła i odzysku energii, ciepły - moduł
Przewód systemu wymiany ciepła i odzysku energii, zimny - moduł
Węzeł główny systemu wodnego
Węzeł pomocniczy systemu wodnego
Terminal usługi - woda
Przewód wodny - moduł
Węzeł główny systemu wody odpadowej - oczyszczalnia
Węzeł pomocniczy systemu wody odpadowej
Terminal wejścia systemu wody odpadowej
Terminal wyjścia - nawóz
Terminal wyjścia - woda czysta
Przewód systemu wody odpadowej - moduł
Węzeł główny ciśnieniowego systemu wymiany powietrza
Węzeł pomocniczy ciśnieniowego systemu wymiany powietrza
Terminal wejścia - powietrze niezdatne
Terminal usługi - powietrze do oddychania
Węzeł główny awaryjnego systemu ciśnieniowego
Węzeł pomocniczy awaryjnego systemu ciśnieniowego
Przewód awaryjnego systemu ciśnieniowego
Terminal dwudrożny awaryjnego systemu ciśnieniowego
Przewód dwudrożny awaryjnego systemu ciśnieniowego
Filtr uniwersalny
Węzeł główny systemu automatyki, kamer i czujników (przewodowy i bezprzewodowy 2 w 1)
Węzeł pomocniczy systemu automatyki, kamer i czujników (2 w 1)
Terminal wejścia - kamera
Terminal wejścia - zespół czujniów
Terminal usługi - wyjście danych
Terminal usługi - sterownik automatyki zainstalowanej
Terminal usługi - połączenie sterownnika automatyki zdalnej z systemem łączności
Główny komputer
Komputer awaryjny
Sieć przewodowa - przewód
Sieć przewodowa - węzeł
Sieć bezprzewodowa - węzeł
Węzeł główny systemu łączności
Węzeł pomocniczy systemu łączności
Terminal łączności bezprzewodowej
Terminal łączności przewodowej
Przewód łączności - moduł
Gaśnica
Skafander
Wiertnica
Kopaczka
Zestaw terenowy geo
Zestaw terenowy bio
Zestaw terenowy meteo
Kamera
Zestaw komunikacji i nawigacji lokalnej
Ręczny zestaw pielęgnacyjny agro
Zestaw medyczny
Zestaw narzędziowy (naprawczy)
Komputer
Wózek ręczny
Zasobnik ręczny elastyczny
Zestaw do sprzątania
Zestaw kosmetyczny
Materiał burzący
Pojemnik mały
Pojemnik duży
Krzesło
Fotel
Leżak
Fotel podwójny
Podnośnik ręczny
Taśma klejąca
Akumulator mały
Zestaw spożywczy
Zbiornik ciśnieniowy mały
Drabinka uniwersalna
Łuk elektryczny
Tworzywa zapasowe
Gleba 1
Gleba 2
Gleba 3
Gleba 0
Nawóz
Odpady organiczne
Odpady nieorganiczne
Tlen
Dwutlenek węgla
Domieszki azotowe
Metan
Tlenek węgla
Woda
Para wodna
Żywność świeża
Leki
Krew
Żywność konserwowa
Wodór
Próbka bio
Próbka geo
Próbka med.
Energia
Kamień - zasób
Ceramika
Próbka meteo
Dane opracowane
Dane posiadane
Dane surowe bio
Dane surowe geo
Dane surowe med.
Dane surowe meteo
Węgiel
Piasek
Materiał roślinny elastyczny
Materiał roślinny sztywny
Nasiona 1
Nasiona 2
Nasiona 3
Nasiona 4
Nasiona 5
MPV
Skarabeusz
AMPB
Balon
Piłka zdalna
Orbiter
Kultywator
Zrobotyzowane ramię duże
Zrobotyzowane ramię małe
Drzwi działowe
Drzwi hermetyczne

AttachmentSize
VMB Environment 0.1.xls41 KB

Zarząd Mars Society Polska
www.marssociety.pl

Wydaje mi się, że najlepszym pomysłem były by faktycznie kategorie obiektów. Dużo łatwiej wtedy zapisywać i projektować interakcję między nimi (np wiadomo że kamień nie może podnieść drugiego kamienia, człowiek natomiast może).
Tylko że znowu wychodzi tutaj rozróżnienie na dwie wersje projektu:
-wersja w przeglądarce musiałaby tych kategorii mieć skrajnie niewiele, obiekty takie musimy przechowywać w bazie danych (żeby osiągnąć wydajność która pozwala faktycznie coś zasymulować), a każdy zestaw atrybutów (czyli w sumie każda odrębna kategoria) to inny obiekt, zatem inna tabela w bazie danych.
-w wersji c++ sprawa wygląda dużo lepiej. Możemy stworzyć drzewko dziedziczenia rodzajów obiektów (kategorii), poczynając od kilku elementarnych i w obiektach pochodnych dodawać kolejne atrybuty i właściwości. Przykładowy ciąg który daje nam awatara: przedmiot materialny -> przedmiot żywy -> sterowany przez gracza -> awatar.
W takim wypadku jako przedmiot materialny obiekt otrzyma takie cechy jak masa, wymiary. Jako przedmiot żywy takie cechy jak : czy_zyje, energia, ciepło, potrzeby. Jako sterowany przez gracza otrzyma funkcje pozwalające na sterowanie nim, jak i atrybuty takie jak zdobyte punkty. Podobnie tworzyć można by zjawiska, zaczynając od przedmiot niematerialny-> itd itd

slawek

Oczywiście całość oprogramowania będzie (bo musi być) napisana w języku obiektowym.

Avatar powinien zatem (bo musi) być obiektem dziedziczącym bo bazowej klasie, po której dziedziczyły będą również wszystkie inne obiekty bazy.

A i słusznie :) polemizujmy.
Może to rzeczywiście obniży wydajność? Chyba, że sporządzi się ogólną tabelę wszystkich obiektów, włącznie z awatarem i zamiast 0 wpisywać się będzie po prostu X albo coś takiego i engine od razu będzie wiedział, że musi ignorować ten parametr w obliczeniach? A nadal mamy wspólną macierz całego środowiska.

Takie rozwiązanie ma wg. mnie jedną podstawową zaletę - w takim środowisku można dowolnie budować nowe obiekty, dodawać je w kolejnych wersjach gry, bez potrzeby zmiany engine. Nie trzeba tworzyć nowych kategorii obiektów, bo jest tylko jedna kategoria dla wszystkich.

Zarząd Mars Society Polska
www.marssociety.pl

"Chyba, że sporządzi się ogólną tabelę wszystkich obiektów, włącznie z awatarem i zamiast 0 wpisywać się będzie po prostu X albo coś takiego i engine od razu będzie wiedział, że musi ignorować ten parametr w obliczeniach?"

Z wydajnością, nie chodziło mi o prędkość obliczeń, lecz o reprezentację w pamięci. Wydaję mi się, że każdy obiekt będzie miał 30 czynników zaalokowanych w pamięci, choć używanych będzie kilka.

Z drugiej strony: można by użyć np. dynamicznych tablic. To jest:
- boolean tablica_dostepnych[30] //które czynniki są używane, a które nie (1 = używany; 0 = nieużywany)
- dynamiczna_tablica //tablica inicjowana na taki rozmiar ile jest używanych czynników

W sumie to to jest do obejścia. Jeszcze nie wiem jak z możliwościami Pythona, ale w C++ na pewno można to zrealizować.

Witam, jestem tutaj nowy, postaram się naświetlić parę problemów z technicznego punktu widzenia.

Jeśli celem będzie stworzenie gry online przez przeglądarkę (czyli w sumie najprostsza możliwość), to nie maja zastosowania takie pojęcia jak dynamiczne tablice. Gra w przeglądarce charakteryzuje się tym, że mamy bazę danych (obiektów) i na tej bazie dokonywane są operacje. Wartości z tej bazy wyrzucane są dla użytkownika na dana stronę (wejdzie na strone z opisem jego awatara, z systemu pobierany jest obiekt awatar i jest on wysyłany do przeglądarki).
Przy symulacji wykonanej w np c++ (przykładowo wersja z grafika 3d), świat może faktycznie żyć w czasie rzeczywistym, interakcja między obiektami może ciągle trwać, to co będzie "widział" użytkownik będzie po prostu pojawiało mu się w okienku. Przy aplikacji internetowej niestety jest inaczej, bo to wejście na stronę powoduje wysłanie żądania otrzymania danych informacji (o np stanie przedmiotów, lub tego co awatar w danym miejscu widzi), które to informacje za chwilę mogą być nieaktualne. (pomijam specjalne technologie w których faktycznie dałoby się zrobić aktualizowanie samoczynne, ale mimo wszystko to i tak jest jakby sposób symulowania tych zapytań, dokonują się same).

slawek

A czy w ogóle możliwe jest traktowanie awatara inaczej niż reszty obiektów? Czy też interakcje muszą być takie same?

Jeśli traktowalibyśmy go odmiennie, trzeba byłoby sporządzić osobną listę interakcji awatar-obiekty i osobną obiekty-obiekty.

Nie wiem, które rozwiązanie jest lepsze, trzeba by oba "zważyć".

Natomiast dynamiczne tablice brzmią ciekawie.

Zarząd Mars Society Polska
www.marssociety.pl

1. Wszystkie obiekty tej samej kategorii
+ większa naturalność symulacji ze strony symulacji (wszystko "może" ze wszystkim)
- możliwe problemy z implementacją (niekoniecznie)
Trzeba byłoby zrobić: listę obiektów, listę parametrów obiektów, listę interakcji, tabelkę przedstawiającą które interakcje są dostępne dla których obiektów.

2. Obiekty podzielone na kategorie
+ mniej kombinowania z implementacją
- sztuczne rozgraniczenie pomiędzy awatarem i jego środowiskiem
Trzeba byłoby zrobić: listę kategorii, listę obiektów, listę parametrów obiektów dla każdej kategorii, listę interakcji dla każdej kategorii.

Prac będzie w obu przypadkach tyle samo. I w 1. i w 2. musimy zdefiniować, które interakcje są dozwolone dla których przedmiotów.

Żegnam, odezwę się ponownie dopiero w sierpniu. Mam nadzieję, że przez ten czas prace posuną się do przodu.

Opcja 1 byłaby trochę "upierdliwa" do rozwijania, przy dodaniu nowego obiektu, trzeba by sprawdzać wszystkie możliwe interakcje z wszystkimi pozostałymi obiektami.
Opcja 2 wygląda dużo lepiej, określamy jakiej kategorii jest nowy obiekt i jakie sam wywołuje interakcje (jeśli jakieś dodatkowe ma), a on sam z automatu wpada pod interakcje z innych obiektów, przez przynależność do kategorii.

Przy opcji drugiej pracy będzie dużo mniej, bo opisywać będziemy na kilku-kilkunastu kategoriach i ewentualnie przypadki szczegółowe, zamiast wałkować zawsze wszystkich obiektów w przypadku pierwszym

slawek

Opcja 2 wygląda dużo lepiej, określamy jakiej kategorii jest nowy obiekt i jakie sam wywołuje interakcje (jeśli jakieś dodatkowe ma), a on sam z automatu wpada pod interakcje z innych obiektów, przez przynależność do kategorii.

Ja już tu widzę sieci neuronowe. [Do zapamiętania. Może kiedyś przyda się ten pomysł, jeśli będziemy programować powyższą drogą.]

.. to taka bardzo specyficzna armata którą powinno się strzelać w bardzo specyficzny rodzaj zwierza, w 90% przypadków są bardziej odpowiednie sposoby kategoryzowania obiektów.

W tym wypadku po prostu i tak musimy dodać obiekt do jakieś kategorii, a jak już jest dodany, to nie potrzebujemy go ponownie kategoryzować :)

slawek

UWAGA! Proszę pamiętać, aby trzymać się tematu, a w razie potrzeby rozpocząć nowy wątek.

Ten wątek dotyczy: "Lista parametrów awatara".

Pojawiły się 2 oddzielne zagadnienia. Otwieram dla nich nowe wątki, przenieśmy tam dyskusje.
- Lista obiektów świata gry VMB: http://vmb.skyfigure.com/node/105
- Teoretyczny model obiektu: http://vmb.skyfigure.com/node/107