Zarys scenariusza

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.

Na Book Page dostępny jest dokument z zarysem propozycji uproszczonego scenariusza ogólnego, zapraszam do dyskusji.

mj

Propozycja założeń scenariusza VMB
Wersja 1.0

Symulacja dążąca do zgodności z rzeczywistymi symulacjami misji marsjańskich planowanych w Bazie Marsjańskiej pod Toruniem.

Toruń, 15.07.2009

I. Kilka założeń ogólnych

- Gra online, multiplayer, bez botów
- Do 8 graczy w 1 sesji + administrator
- 1 gracz = 1 awatar

- Gracze w bazie są w nieustannym kontakcie z administratorem, który stanowi „centrum kontroli misji”, czyli Ziemię. Stopniowo tworzona będzie aplikacja administratora (AA)

- 2 rodzaje sesji: A) rozrywkowa - gracz nie musi być dyspozycyjny przez cały czas oraz B) symulacyjna - gracz musi być do dyspozycji na przez cały czas symulacji

- Charakterystyka postaci, gracz może wybrać umiejętności i specjalizacje (parametry) swojej postaci, ale tworząc postać po rejestracji musi zdać prosty test z danej dziedziny. Wynik testu określi parametry jego postaci. Zupełni dyletanci będą musieli się doszkolić. Ma to na celu zachowanie poważnego podejścia graczy do symulacji.

- Możliwość programowania prostych zadań awatarów, wykonywanych automatycznie, z powiadamianiem gracza porzez SMS o alertach. Czyli postać żyje swoim równoległym życiem, informuje o sytuacjach kryzysowych i w każdej chwili może zostać „przejęta” przez gracza.

- Podstawowe parametry techniczne do ustalenia: ilość czynnych pokoi gry, kwestia interfejsu (aplikacja kliencka czy przeglądarka) itp.

II. Engine gry

Programowanie obiektów (patrz lista obiektów)
Programowanie parametrów obiektów (patrz lista parametrów)
Programowanie interakcji między obiektami (patrz lista interakcji)
W skrócie OPI

III. Środowisko symulacji

- Wnętrze bazy i obszar marsjański otaczający bazę.
- 2-poziomowa kapsuła orbitera stojącego w pobliżu bazy i wnętrze orbitera,
- Warstwy pod powierzchnią gruntu (wykop, szyb)
- Warstwy atmosfery ponad bazą (dla obiektów latających)
- Wnętrze pojazdu MPV (łaziki i pojazdy latające traktowane jako obiekty).

IV. Rozgrywka, interfejs i engine graficzny, z podziałem na stadia rozwojowe projektu

1. Implementacja OPI, grafika izometryczna, podział na sześcienne pola, 10 warstw (wykop głęboki, wykop płytki, poziom gruntu, fundament bazy/obiekty gruntowe 1, parter bazy/obiekty gruntowe 2, 1 piętro bazy/obiekty gruntowe 2, 2 piętro bazy, obiekty gruntowe 3, dach bazy/obiekty gruntowe 4, atmosfera 1, atmosfera 2), schematyzm graficzny, rozgrywka turowa (stadium 1 jest opcjonalne)
2. Implementacja OPI, grafika pseudo 3D: rzut izometryczny bez podziału na pola, określona „głębokość i wysokość” mapy, schematyzm graficzny, rozgrywka w czasie rzeczywistym. 2 opcje: A) preferowana symulacja uproszczona, bez akcji typu „rzuć”, „wystrzel” i B) symulacja z fizyką Marsa.
3. Implementacja OPI, grafika 3D FPP, określona „głębokość i wysokość” mapy, rozgrywka w czasie rzeczywistym. Realizm graficzny środowiska – poziom realizmu zależny od zaawansowania prac projektowych. Dopuszczalny pewien schematyzm graficzny awatarów graczy. 2 opcje: A) preferowana symulacja uproszczona, bez akcji typu „rzuć”, „wystrzel” i B) symulacja z fizyką Marsa.

V. Zalety i wady poszczególnych stadiów

W przypadku stadium 1 łatwo jest rozwiązać kwestie obecności obiektów w danej lokacji: na danym polu znajdować się może np. „podłoga”, „tlen”, „awatar”, „zestaw narzędziowy” i „promieniowanie”. Trudniej to rozwiązać w przypadku rezygnacji z podziału mapy na pola, szczególnie w dziedzinie obiektów takich jak tlen. Granice zasięgu obiektów rozwiązać można prosto poprzez układ współrzędnych. Jednak koncentracje obiektu mogą stanowić problem. Wprowadzenie parametru „ciśnienie” jest zbytnim skomplikowaniem symulacji, dlatego dla tlenu, promieniowania i podobnych obiektów należy przyjąć obecność lub nieobecność interakcji „Zaatakuj” ;).

W przypadku stadium 3 dążymy do całkowitej, maksymalnie wiernej integracji VMB z rzeczywistym projektem bazy. Jest to bardzo korzystne ze względu na możliwość łączenia prac inżynieryjno-projektowych nad obydwoma projektami: wirtualnymi i rzeczywistym. Zarazem daje możliwość tworzenia założeń technologicznych aktualnie nierealnych w rzeczywistości z powodu ograniczeń finansowych lub wykonawczych.

Dodatkowo aplikacja administratora gry VMB (AA) dla stadium 3 wykazuje wysoką zgodność z aplikacją do obsługi systemów rzeczywistego habitatu.

VI. Fabuła-misja

Wersja pierwsza gry dotyczy tylko symulacji funkcjonowania bazy. Nie jest to symulacja całości przebiegu misji (ze startem z Ziemi, lądowaniem itp.), ani kolonizacji Marsa. Rozgrywka zaczyna się od przybycia 8-osobowej załogi do marsjańskiego habitatu. Habitat wylądował już wcześniej i rozłożył się automatycznie. Załoga przybyła na pokładzie orbitera i przywiozła ze sobą reaktor Sabatiera do produkcji paliwa na powrót. Jest to luźna adaptacja założeń planu Mars Direct.
Przy konstruowaniu fabuły, należy uwzględnić główne cele planowanej rzeczywistej misji marsjańskiej:

- Przeżycie załogi
- Zabezpieczenie powrotu
- Zbieranie danych

To warunki zwycięstwa w grze.

Symulacja nie przewiduje: rozbudowy bazy, eksploatacji zasobów na dużą skalę, lotów orbitalnych, wytwarzania nowych rodzajów obiektów przez graczy (jedynie przez administratora).

Załoga przybywa do bazy i mając do dyspozycji mapę, pewne zasoby, narzędzia, źródła wiedzy (dane), łączność z Centrum Kontroli na Ziemi (CK), zasoby ukryte na mapie musi:
- uruchomić bazę i sprawdzić stan techniczny bazy (po kolei aktywować poszczególne obiekty, poprzez zmianę parametrów)
- uruchomić przywiezioną na pokładzie orbitera instalację do produkcji paliwa metanowego (po kolei aktywować poszczególne obiekty, poprzez zmianę parametrów)
- doglądać instalacji (po kolei aktywować poszczególne obiekty, poprzez zmianę parametrów)
- zabezpieczyć działanie systemu podtrzymywania życia (kontrolować parametry obiektów)
- zabezpieczyć odpowiednią ilość zasobów drogę powrotną (aktywować obiekty)
- uruchomić program badawczo-produkcyjny: agrokulturę (aktywować obiekty, kontrolować ich parametry
- uruchomić program badawczy: zbieranie danych (patrz niżej)
- reagować na zagrożenia fizyczne, medyczne, psychiczne itp. (kontrolować parametry obiektów).

„Centrum kontroli” może dosyłać transporty z nowym wyposażeniem i zasobami, czyli administrator może tworzyć i wprowadzać nowe obiekty do gry w czasie jej trwania. Administrator może także bez wiedzy graczy tworzyć obiekty w środowisku Marsa (umieszczać obiekty „cenna próbka”, „cenny zasób”, „meteoryt”, „osuwisko” itp.) Odbywa się to według ustalanych reguł i z ograniczeniami zbliżonymi do rzeczywistych uwarunkowań wysłania misji marsjańskiej. Zakłada się także np. możliwość zerwania łączności i podobne sytuacje na linii habitat-CK. Oczywiście struktura obiektowa daje możliwości stałego udoskonalania i rozbudowywania świata z sesji na sesję.

VII. Program badawczy „zbieranie danych”

Dane są parametrem obiektu. Można wydzielić kilka kategorii danych, np. dane geologiczne, dane biologiczne, dane techniczne, dane medyczne. I tak obiekt-okruch skalny będzie miał wysoki parametr-dane biologiczne i wysoki-dane geologiczne, a niski parametr-dane techniczne i niski parametr-dane medyczne. Odwrotnie: obiekt-zestaw narzędziowy będzie miał wysokie dane techniczne, a niskie pozostałe parametry. Obiekt-człowiek będzie miał wysoki parametr danych medycznych.
Należy także wprowadzić kategoryzację danych na dane nowe (czyli zdobyte przez badania na Marsie) i dane posiadane (czyli znane już ludzkości, chociaż niekoniecznie znane awatarowi). Dane są zasobem. Dane ‘posiadane’ mogą być przez gracza używane np. do rozwiązywania problemów technicznych lub podnoszenia własnych parametrów, ale zajmuje to czas.

Jedną z miar sukcesu misji jest ilość przesłanych do CK nowych danych (w jednostkach). Dane gromadzone są w obiektach-komputerach, czyli stanowią parametr obiektu-komputer. Komputer to w praktyce jedyny obiekt, który może mieć wysokie współczynniki danych technicznych, medycznych, geologicznych i biologicznych jednocześnie. Do CK przesyłać można surowe dane lub zwielokrotniać ich ilość poprzez opracowywanie ich na obiekcie-komputer lub obiekcie-zestaw analityczny. W zależności od ilości nowych danych zgromadzonych w obiektach-komputer lub przesłanych do CK na mapie aktywowane są nowe zasoby danych (lub dodawane przez administratora). Symuluje to geometryczny wzrost zdobywanej wiedzy i doskonalenie metod badawczych.

VIII. Życie postaci

Żeby uniknąć znużenia gracza, można wprowadzić opcję zautomatyzowania przede wszystkim „przyziemnych” czynności, takich jak sen, jedzenie i czynności fizjologiczne, chociaż należy je uwzględniać – są istotne dla symulacji. Należy też wprowadzić możliwość programowania czynności postaci, takich jak siedzenie przy komputerze w celu opracowania danych, kopanie dołka, czy ćwiczenia na siłowni.

Stosunkowo łatwo jest symulować stan fizyczny awatara, który jest bezpośrednim skutkiem interakcji z różnymi obiektami. Jednak stan psychiczny, istotny parametr symulacji, jest trudniejszy. Nie wiadomo, czy miałby to być stan psychiczny żywego gracza, siedzącego na fotelu i co najwyżej irytującego się w skutek rozmów ze współgraczami, którzy nie mają ochoty naprawić ubikacji w bazie, czy też zupełnie sztuczny parametr awatara. Należy rozważyć moderację korespondencji między graczami lub zobowiązać ich do używania emotikonów lub skali nastroju podczas komunikacji z innymi graczami. To odpowiednio wpływałoby na stan psychiczny awatara. Dodatkowe czynniki, które mogą wpływać na parametr stanu psychicznego awatara to np. częstotliwość kontaktu ze „światem zewnętrznym”, satysfakcja z wykonanych zadań, świeże pożywienie (agrokulutra), ilość czasu spędzona na relaksie, ćwiczeniach itp., a także negatywny wpływ częstych wypadków, stanu zdrowia lub zmuszenia do wykonywania czynności, w których awatar ma niski poziom parametru umiejętności.

Z czasem, w bardziej zaawansowanych wersjach gry, mechanizm ten może zostać rozbudowany.

IX. Łączność między graczami i łączność graczy z CK

Proponowane rozwiązania to VOIP, aktywny gdy gracz jest dostępny, czat symulujący rozmowy w grze, komunikacja e-mailowa i czatowa dostępna przez komputery awatarów.
Proponowana jest także łączność graczy ze światem zewnętrznym (Internetem), wysyłana „z bazy”, symulująca komunikację z rodzinami na Ziemi itp. Otrzymywanie takiej komunikacji może pozytywnie wpływać na parametr Stan psychiczny awatara. Ponadto w jednym miejscu bazy dostępna będzie tablica ogłoszeń/forum, na którym gracze dokonywać mogą wpisów odnośnie funkcjonowania bazy (zostawiać sobie wiadomości).

X. Informacje o obiektach

Oprócz umieszczonych w enginie parametrów każdy obiekt może mieć też wyświetlaną etykietę z edytowalnymi informacjami, co symuluje szkolenie odbyte przez „astronautę” na Ziemi (czyli przykładowo, obiekt Ściana będzie miał etykietę zawierającą informacje o materiale i specyfice, a także notatkę dodaną przez innego gracza „element nadwerężony, naprawiany, zachować ostrożność). Obiekt Okruch skalny będzie miał etykietę z podstawowymi informacjami geologicznymi, których awatar „dowiedział” się na Ziemi. Etykiety mogą być także edytowane przez administratora.

XI. Awatary zdalnie sterowane

Wiele obiektów bazy jest zdalnie sterowanych. Są to łaziki, kamery, wysięgniki itp. Sterowanie nimi powinno odbywać się w sposób podobny do sterowania awatarem gracza, jednak po aktywowaniu przez awatara gracza odpowiedniego terminalu sterowania (obiektu) na obszarze mapy. Wówczas „kamera” gracza przełącza się na widok awatara zrobotyzowanego. Ponieważ to rozwiązanie może być bezpośrednio rozwinięte w system sterowania faktycznymi robotami, wymaga dalszej analizy.

XII. Kolejne etapy tworzenia scenariusza gry to:

- Sporządzenie listy obiektów
- Sporządzenie listy interakcji
- Sporządzenie listy parametrów
- Sporządzenie opisów obiektów, interakcji i parametrów.
- Sporządzenie tabeli dozwolonych i niedozwolonych interakcji między obiektami, zawierającej informacje o modyfikacji parametrów (macierz wielowymiarowa?).
- Analiza teoretyczna działania engine i propozycja scenariuszy składowych misji
- Wybór rozwiązań graficznych
- Stworzenie zarysu mapy

Autor: Mateusz Józefowicz,
Oparte na założeniach rozwojowych projektu Bazy Marsjańskiej pod Toruniem.

AttachmentSize
VMB Proposal public.odt53.9 KB

Zarząd Mars Society Polska
www.marssociety.pl

Świetnie, taki zarys jest bardzo potrzebny. Myślę jednak, że 2. i 3. wariant interfejsu znacząco wybiega ponad możliwości Pythona, a przede wszystkim gry internetowej w przeglądarce.

Moim zdaniem warto zacząć od razu od wariantu numer 3. Obecne narzędzia (C++ oraz Ogre3D) sprawiają, że zaprogramowanie trójwymiarowej grafiki na porządnym poziomie jest banalne - potrzebni są jedynie graficy zdolni stworzyć odpowiednie modele i ich oteksturowanie.

"Proponowana jest także łączność graczy ze światem zewnętrznym (Internetem), wysyłana „z bazy”, symulująca komunikację z rodzinami na Ziemi itp."

Odległość między Marsem i Ziemią wynosi około 4 minuty świetlne. Przypominam, że posługiwanie się internetem polega na 1. wysłaniu żądania od klienta; 2. odpowiedzi serwera na żądanie klienta. Oznacza to, że trzeba czekać conajmniej 8 minut na załadowanie się strony. Myślę, że to niespecjalnie sprzyja komunikacji internetowej z Ziemią...

Skoro jestem już przy tym elemencie. Warto uwzględnić w symulacji, że komunikacja Ziemia - Mars także będzie przebiegać w takim tempie. Po wysłaniu wiadomości, admin dostaje ją 4 minuty później. Odpowiedź admina dochodzi także 4 minuty później od wysłania takiej odpowiedzi.

Odległość między Ziemią a Marsem zmienia się i opóźnienie komunikacyjne wynosi zależnie od niej 3 - 22 minut. Czekanie na odpowiedź 44 minuty pewnie będzie na marsie dość uciążliwe!

"Skoro jestem już przy tym elemencie. Warto uwzględnić w symulacji, że komunikacja Ziemia - Mars także będzie przebiegać w takim tempie. Po wysłaniu wiadomości, admin dostaje ją 4 minuty później. Odpowiedź admina dochodzi także 4 minuty później od wysłania takiej odpowiedzi."

A dokładnie :), trzeba zanotować. Ponadto ta odległość się zmienia cyklicznie, 4 min. to średnia. Należałoby wprogramować wzajemne położenie planet i długość opóźnienia.

"potrzebni są jedynie graficy zdolni stworzyć odpowiednie modele i ich oteksturowanie."

Żeby było śmieszniej, to projekt Janka jest gotowym plikiem CAD. A Narwik zdrowo pociągnął kwestię realizacji animacji w oparciu o te projekty. To samo z pojazdem MPV
Więc generalnie dużo leży na talerzu i stygnie. Zdaje się, że raczej trzeba będzie niektóre sprawy upraszczać względem projektu technologicznego.

Zarząd Mars Society Polska
www.marssociety.pl

Polecam to: http://mars24.info/?key=2,,191

Janek Kotlarz jest autorem profesjonalnego oprogramowania do modelowania rzeczywistej powierzchni Marsa w oparciu o zdjęcia z Mars Reconnaisance Orbitera. Docelowo rozdzielczość oprogramowania wyniesie obiekty o wielkości 30 cm.

Jakoś logicznie się to układa, żeby z czasem generować mapy bezpośrednio na podstawie zdjęć z MRO i "symulować" na mapie zrobionej na bazie prawdziwego terenu :)

Trzeba byłoby uzyskać zgodę lub patronat ESA, uniwersytetu w Bernie, ale o to właśnie chodzi, żeby łączyć takie projekty.

Zarząd Mars Society Polska
www.marssociety.pl