Pierwszy cel...

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.

Miło pierwszy post mieć okazję napisać..

Czyli podstawowa sprawa, to przygotowanie pracującego systemu, który działa jeszcze bez załogi - zacząć należy bez ludzi jeszcze i dosyć fundamentalnie... Tak to widzę (póki co).

Po przylocie na Marsa mały reaktor jądrowy po umieszczeniu w odpowiednim miejscu zaczyna produko-
wać metan - paliwo potrzebne do podróży powrotnej. Do przebiegu procesu wykorzystuje
przywieziony w zbiornikach wodór oraz pobierany z atmosfery marsjańskiej CO2.

Przygotowanie takiego bazowego systemu, będzie już całkiem wyzywające a pokaż już sporo pytań. Pierwsze dwa, które przychodzą mi do głowy:

  • jak dużo fizyki/rzeczywistości trzeba użyć
  • jak taktować system - problem systemu kontroli czasu

Czekam na uwagi. Ponieważ czasu nie mam wiele (będę się starał 1/48 doby poświęcać co dwa dni) - z góry przepraszam za późne odpowiedzi w dyskusji!

Witam,

Tekst, który przytoczyłeś dotyczy Etapu I, a my mamy projektować bazę z Etapu II. Pomyłka ta jest jednak spowodowana moim niedociągnięciem i od razu widzę, że zapomniałem o czymś ważnym, a mianowicie o wstępie do projektu, który zawierałby zestawienie podstawowych informacji o projekcie VMB i był wyraźnie widoczny dla zainteresowanych projektem.

Zaniedbanie to naprawiłem i wprowadzenie do projektu znajduje się tutaj:
http://vmb.skyfigure.com/node/96.
Wprowadzenie to pozwoli na szybkie zorientowanie się, czym projekt VMB jest i na czym polega.

Odpowiedź na pierwsze pytanie znajdziesz w powyższym wprowadzeniu.

Jeśli idzie o drugie pytanie (problem systemu kontroli czasu), to wydaje mi się, że aktualizacja świata wirtualnej bazy, jako gry (a nie zaawansowanej symulacji), za pomocą demona CRON (http://pl.wikipedia.org/wiki/Cron_(Unix)) mogłoby wystarczyć. Trudno mi obecnie powiedzieć z jakim okresem wywoływać crona oraz jak zasobożerny będzie.
Nie wiem na ile jest to dobre rozwiązanie, dlatego czekam na uwagi.

Nie wiem czy dobrze rozumiem co masz na myśli przez taktowanie systemu. Myślę że chodzi Ci o to co jaki czas "przeliczać" stan bazy w grze. Rozumiem też że projekt tej gry ma być zaczątkiem bardziej naukowego symulatora bazy. Wydaje mi się że jest pewna różnica w taktowaniu symulacji i gry. W grze zależy to w dużej mierze od tego jaka to gra:

- gra turowa - cały model przeliczany jest raz na turę, ewentualnie raz na kilka tur (patrz RedDragon), następnie gracz dokonuje modyfikacji parametrów systemu przez podjęte decyzje, itd...
- gra w czasie rzeczywistym - cały model przeliczany jest co jakiś stały okres czasu będący minimalnym kwantem czasu w grze, np co jedną sekundę. Użytkownik może się logować do systemu w dowolnym momencie i podejmować decyzję na bazie zasobów jakie zostały wytworzone w czasie jego nieobecności (patrz: Ogame)

Natomiast w symulacji wcale nie chodzi o to żeby odbywała się ona w czasie rzeczywistym, tylko o to żeby odbywała się ona jak najszybciej, by móc przetestować maksymalnie dużo scenariuszy w jak najkrótszym czasie. Tutaj spotkałem się z następującym podejściem:

Dzielimy model symulowanego systemu (w tym przypadku bazy marsjańskiej) na część "liniową" i na zdarzenia. Część liniowa to wszystkie te przewidywalne i obliczalne w dowolnym horyzoncie czasowym zjawiska. Np. wiemy że reaktor produkuje energie z mocą 15kW. Więc jesteśmy w stanie obliczyć ile energii wytworzy za godzinę, lub dowolną inną ilość czasu. Tak samo wiemy ile energii zużywa urządzenie produkujące metan i ile metanu wytwarza. Mogą to być oczywiście bardziej skomplikowane zależności niż (moc*czas), ale ogólnie są jakąś funkcją zależną jedynie od obecnego stanu elementu i czasu jaki upłynie. Zdarzenia natomiast są losowe, występują z pewnym prawdopodobieństwem i wpływają na parametry systemu. Jest to np awaria systemu chłodzenia reaktora, która powoduje jego nagrzewanie się. Taktowanie takiej symulacji odbywa się w następujący sposób:

1. Mamy początkowy stan systemu w czasie t0
2. Na podstawie prawdopodobieństw wszystkich możliwych zdarzeń obliczamy dla każdego z nich kiedy wystąpi dane zdarzenie (np awaria reaktora za 3 tyg 2 dni i 3 godziny)
3. Ustawiamy wszystkie zdarzenia w kolejności w jakiej wystąpią w kolejce
4. Sprawdzamy jakie jest najbliższe zdarzenie (np reset komputera sterującego reaktorem za 2 dni i 15min)
5. Obliczamy jaki będzie stan systemu w momencie tego zdarzenia (czyli idziemy o jeden takt dalej)
6. Przeliczamy jaki wpływ będzie miało zdarzenie na parametry systemu (np komputer przejdzie w stan awaryjny i reaktor będzie pracował z połową mocy wytwarzając mniej energii)
7. Sprawdzamy czy w wyniku tego zdarzenia nie wystąpią jakieś dodatkowe zdarzenia (np wyliczamy że z uwagi na umiejętności i inne czynniki członek załogi dokona naprawy komputera za 5 godzin)
8. wracamy do punktu 3

Osobiście nie lubię gier internetowych w czasie rzeczywistym bo zmuszają do regularnego logowania się. Lepsze jest podejście turowe. Jednak z uwagi na to że projekt ma ewoluować (dobrze rozumiem?) w symulację z prawdziwego zdarzenia proponuję następujące, mieszane podejście turowo-symulacyjne:

Użytkownik codziennie, powiedzmy o północy dostaje jeden "dzień" w czasie gry. Jeśli się nie zaloguje do systemu to te dni mu się zbierają (może do jakiejś rozsądnej wartości, powiedzmy 2 tyg). Gra działa w trybie symulacyjnym, ale dla gracza wygląda jak turowa. Po zalogowaniu klika przycisk "Następna tura". System przelicza kiedy wystąpi jakieś zdarzenie na które gracz może zareagować i wyskakuje komunikat w stylu: "Minęło 3h 23min, w tym czasie wyprodukowano tyle a tyle paliwa, tyle a tyle energii, itd Komputer właśnie wykrył spadek ciśnienia wewnątrz modułu mieszkalnego". Następnie gracz podejmuje jakieś decyzje, wpływając na parametry systemu i ewentualnie generując jakieś nowe, przyszłe zdarzenia. Klika "Następna tura" i cały proces się powtarza aż do wykorzystania czasu w grze jaki ma (koniec ostatniego zgromadzonego dnia). Jak już wyklika cały dostępny czs to musi poczekać do następnej północy aż otrzyma nowy dzień w grze.

Moim zdaniem takie podejście z jednej strony unika nudy w grach turowych w których np. przez jakiś czas nic się nie dzieje, a z drugiej nie zmusza do ciągłego logowania do gry. Poza tym taka gra dałaby się łatwo przerobić w bardziej złożoną symulację.

Problem w tym, że - jak przedstawił Zarząd Mars Society Polska - gra będzie opierała się na współpracy ośmioosobowych zespołów w pojedynczych bazach. Oznacza to, że jeśli jeden członek zespołu nie będzie logował się przez dwa dni i te dwa dni mu się zbiorą, a inni będą logowali się codziennie - to wystąpią spore problemy ze zsynchronizowaniem działań całej załogi.

Zakładamy rozgrywkę w czasie rzeczywistym, 1:1

Proponuję 2 rodzaje sesji:

1. Rozrywkowa, wówczas gracz nie musi siedzieć "kołkiem" i część działań awatara może zostać zaprogramowana (np. "dzisiaj naprawiasz od 13 do 14;30, potem jesz, potem pielęgnujesz agrokulturę"). Oczywiście w każdej chwili można to zrobić ręcznie.
"Repertuar" czynności będzie dość ograniczony (prawdopodobnie około 20 czynności w 1 wersji gry). Jeśli coś idzie nie tak i pojawia się alert, gracz dostaje powiadomienie SMSem i musi się wlogować i zareagować lub odpowiedzieć SMSsem. W sytuacjach kłopotliwych może upoważnić administratora lub innego gracza do chwilowego sterowania awatarem.

2. Symulacyjna - gracz jest "dyspozycyjny" przez cały czas. To już podejście bardziej "zawodowe" i rozwojowe. Także może automatyzować czynności, ale musi być cały czas wlogowany.

Zarząd Mars Society Polska
www.marssociety.pl

Jeżeli rozgrywka ma być prowadzona w czasie rzeczywistym i ma być to jak najbardziej realistyczna symulacja, to trzeba pamiętać o tym, że Mars 'daje nam' dodatkowe 36 minut w ciągu doby. I w zależności od wybranej ścieżki możemy odpowiednio 'wydłużyć' czas w grze (przykładowo 1 godzina czasu rzeczywistego to 1 godzina i 1,5 minuty w grze), albo pozostawiamy model 1:1 i przygotowujemy graczy na niespodziankę, że co jakiś czaś pory dnia na zewnątrz i w grze nie będą się zgadzały.

O tym czy projekt VMB ma być grą czy symulacją piszę tutaj: http://vmb.skyfigure.com/node/96

Jestem za tymi założeniami. Jestem za tym, żeby zasób obiektów, interakcji i parametrów był dość ograniczony (np. około 30 obiektów, do 10 interakcji, około 20 parametrów). Tak naprawdę nie będzie konieczne pisanie szczegółowego scenariusza w takim środowisku, bo on się sam logicznie ułoży.

Podstawowym problemem dla graczy będzie nie tyle umiejętność interakcji z programem, co odpowiednie zaplanowanie własnych działań, po ustaleniach z innymi graczami. Proponuję więc - proste środowisko i nacisk na faktyczną komunikację między graczami, coś jak w Travianie w obrębie sojuszu: gracz musi zarówno dbać o swój stan psychiczny, fizyczny itp (EGOIZM lub instynkt samozachowawczy), jak i skutecznie pracować na rzecz grupy.
Wyłonią się przywódcy, pojawią się tarcia i kompromisy, to może być ciekawe.

Grywalność osiągnie się przez przetestowanie różnych wielkości parametrów (czyli dynamikę gry). Ważne, żeby w programie zachować możliwość szybkiej zmiany tych wielkości i przełączenie z trybu o wysokiej grywalności na tryb o wysokim realiźmie. W ten sposób pracujemy wciąż na jednej wersji programu.

Zarząd Mars Society Polska
www.marssociety.pl

Moim zdaniem zawarta pod tym linkiem odpowiedź na to pytanie brzmi "gra i symulacja w jednym":

"W chwili obecnej głównym zadaniem, stojącym przed projektantami Wirtualnej Bazy, jest położenie głównego nacisku na projekt VMB, jako gry online z jak najlepszą grywalnością oraz stworzenie podstawowego mechanizmu symulacji bazy ()"

Wydaje mi się że bardzo trudno będzie stworzyć taką mieszankę "dwa w jednym". Chyba jedynym sposobem na to żeby to zrobić jest takie projektowanie interfejsów wewnątrz programu i jego struktury, żeby łatwo było wymienić moduły uproszczone pisane na potrzeby gry na te przeznaczone do symulacji. Z tym, że nie wiem czy to by się w ogóle opłacało.

Sposób projektowania programów symulacyjnych, jaki opisałem, można także wykorzystać do symulacji w czasie rzeczywistym 1:1 , jeśli tylko przewidzi się możliwość sztucznego "taktowania" go np co jedną sekundę. Dla poważnej i złożonej symulacji może to być problem, bo obliczeń może być naprawdę sporo, ale może taka wymienność modułów pomiędzy ich prostymi i realistycznymi wersjami byłaby pomocna.

Mam też wrażenie miałem trochę co innego na myśli przez termin "symulacja bazy". Chodzi o symulację urządzeń, pomieszczeń i znajdującej się wewnątrz aparatury i jej funkcjonowania, czy o taki mały pokój społecznościowy, oparty o niezbyt skomplikowaną grę ?

To można jakoś pogodzić: generalnie mamy pokój, a symulowane są także obiekty i instalacje bazy, ale niezbyt liczne - może do 20 różnego rodzaju obiektów (System podtrzymywania życia, zasilanie, uprawy, łączność, sanitariat, chłodnie, siłownia, komputer, lab biologiczny, lab geologiczny, warsztat, śluzy, ambulatorium, schron, sterownia itp). Traktowane mniej więcej jako pojedyncze obiekty. Nie każda śrubka osobno.

m

Zarząd Mars Society Polska
www.marssociety.pl

Dokładnie o to ma chodzić w podstawowej symulacji gry!

Gdy przyjdzie czas na poważną symulację, wtedy rozbudujemy te systemy.

Jestem za tym rodzajem sesji:
1. Rozrywkowa, wówczas gracz nie musi siedzieć "kołkiem" i część działań awatara może zostać zaprogramowana (np. "dzisiaj naprawiasz od 13 do 14;30, potem jesz, potem pielęgnujesz agrokulturę"). Oczywiście w każdej chwili można to zrobić ręcznie.

Okresowe logowanie do gry w celu wykonania zadań (swoich, innych członków załogi lub wspólnych)
Użytkownicy logują się do swojej bazy kiedy mają na to ochotę. Wiadomo, muszą się logować co jakiś czas, aby wykonać swoje zadania i sprawdzać czy nie pojawiły się nowe.
Przykład: Jeśli nie wykonasz jakiegoś zadania, a inni członkowie załogi nie mieli czasu albo nie byli w stanie wykonać go za ciebie, wówczas oberwie się całej załodze, bo np. woda w obiegu będzie brudna. Oj dostaniesz naganę. Może załoga zacznie z Tobą inaczej postępować. Lepiej więc wykonywać swoje zadania - chodzi przecież o Życie oraz że jest się za nie odpowiedzialnym u reszty załogi!

Wykonywanie zadań
Na wykonanie zadania potrzebny jest określony czas. Będzie on zależeć od obiektów uczestniczących w zadaniu oraz czynności. Np.
obiekt 1 -> człowiek,
obiekt 2 -> rośliny w module agrokultury,
czynność -> pielęgnacja (ogólnie, nie interesuje nas teraz, czy to podlewanie, czy zmiana składu chemicznego w glebie).
Następuje akcja:
obiekt 1 <-> czynność <-> obiekt 2

Przykład
Twoim zadaniem jest przeprowadzenie pielęgnacji roślin. Twoje samopoczucie/zdrowie nie jest najlepsze. W ostatnich dniach mało sypiałeś, było dużo awarii. Ponieważ rośliny mają się dobrze (widzisz to na urządzeniach pomiarowych) nie trzeba za wiele robić. Normanie, czynność ta zabrałaby 60 minut, ale że roślinki czują się dobrze, to można się uporać z zadaniem w 40 minut. Niestety, źle się czujesz, będzie szło wolniej, całość zajmie 60 minut. Przy okazji wzrasta ryzyko, że coś źle zrobisz. Jeden z parametrów obiektu "roślinki" może się pogorszyć. A Tobie i tak parametr zdrowia zmaleje, bo jesteś przemęczony, a tu trzeba pracować!

Czas na wykonanie zadań
Proponuję czas rzeczywisty. Jeśli coś ma zająć 2 godziny, to tyle musi to trwać. Twój Awatar jest zajęty, nie może wykonywać innych zadań. Widzisz pasek stanu, który odlicza czas do końca zadania. Oczywiście możesz przerwać wykonywaną czynność. Wtedy zadanie jest wykonane np. w 50%, czyli pracowałeś 1 godzinę i tyle samo trzeba na dokończenie zadania. Musiałeś jednak wykonać inne zadanie. Do poprzedniego wrócisz później. Spanie to też zadanie, trwa np. 6 godzin.

Co możesz robić podczas wykonywania zadania?
1) Możesz zobaczyć co robią inni, Sprawdzić komputer pokładowy lub różne pomiary, przeglądnąć i napisać wiadomości, wziąć udział w głosowaniu demokratycznym dotyczącej jakieś sprawy, poczytać encyklopedię edukacyjną bazy w Toruniu i Wirtualnej itp. itd.
2) Po prostu się wylogować i zalogować np, kolejnego dnia. Zadanie będzie już wykonane (a może nie, bo była awaria), a Ciebie i Twoją załogę czekają nowe wyzwania!

Zdecydowanie realtime a nie tury. Plus - jak Mateusz wspomniał - lista ToDo dla awatara. Można dać w niej parametr "nie dłużej niż" (to dla malkontentów hehe) czyli "pielęgnuj rośliny [aż skończysz] (czyli do 100% wykonania czynności - to raczej wersja oparta o wartość jakiegoś parametru przedmiotu, na którym wykonywana jest czynność, niż czas trwania czynności) jednak [nie dłużej niż] 2 godziny (następnie przejdź do kolejnej czynności na liście)". Należy przewidzieć wentyl bezpieczeństwa, który zadziała automatycznie jeśli gracz nie jest zalogowany, żeby nie dopuścić do sytuacji, kiedy awatar umiera z wycieńczenia podczas podlewania roślin :D Instynkt samozachowawczy (w tym przypadku natychmiastowa regeneracja poprzez sen) ma priorytet nad wszelkimi innymi zadaniami. Dodatkowo - jeśli awatar skończył czynności z listy i jest w dobrej formie, a użytkownik nie zalogował się, aby wydać kolejne polecenia - pozostali użytkownicy powinni mieć prawo wydania poleceń awatarowi. Do rozważenia pozostaje czy na drodze głosowania, czy może lepiej aby polecenie było z jakiejś okrojonej listy (aby wykluczyć polecenia, które mogą negatywnie wpłynąć na awatar - czyli nie można będzie wydać awatarowi, którego użytkownik nie jest zalogowany, polecenia naprawy uszkodzonego reaktora hehe).
Jeśli chodzi o aktualizowanie stanu obiektów, to - moim zdaniem - należałoby podzielić wszystkie obiekty na dwie kategorie: obiekty "leniwe" oraz obiekty "aktywne". Obiekty "leniwe" mogłyby aktualizować swój status dopiero w momencie bezpośredniego odwołania się do nich, lub - ewentualnie - mogłyby się aktualizować automatycznie w przypadku, gdy znajdują się w pobliżu dowolnego awatara (lub dowolny awatar znajduje się w ich pobliżu). Obiekty "aktywne" aktualizowałyby się w każdym takcie gry/symulacji. Przykładowo, jeśli założy się, że obiekt A po osiągnięciu pewnego stanu właściwości X generuje zdarzenie Ę (na przykład postęp jakiejś analizy - kwestia do dalszej dyskusji - chodziło mi tylko o zasygnalizowanie pewnej możliwości), to owa właściwość X powinna być aktualizowana niezależnie od faktu, czy którykolwiek z awatarów znajduje się w pobliżu obiektu A. Ograniczyłoby to obciążenie systemu, gdyż ogromna większość obiektów byłaby obiektami "leniwymi" - poza ewidentnymi działaniami IRT, wynikającymi z interakcji awatara z otoczeniem, cała reszta może odbywać się cyklicznie w tle.

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

całkiem fajne, ale raczej praktycznie nie do zrealizowania :)
Czas rzeczywisty jest niemożliwy, tak czy siak będą to tury. Różnica polega tylko na tym, ile te tury będą trwać. W grach na komputerze to pewnie 1/10000 sekundy, u nas to może być minimalnie tyle, ile będzie potrzebował system na przeliczenie wszystkiego w najgorszym przypadku. Im bardziej skomplikowany świat, bardziej rozbudowane interakcje, więcej przedmiotów do śledzenia, tym tury będą musiałby być dłuższe. Dlatego w części gier online przeliczenie stanu występuję raz na dobę (red dragon, erepublik), w jakiś rannych godzinach bo tyle trwa. Wiadomo że tam jest inna skala (kilkanaście - kilkadziesiąt ludzi grających), ale tam obiektów do przeliczenia nie jest wcale tak dużo. Każdy z graczy ma kilka akcji tak naprawdę, przelicza sie je hurtem i hurtem aktualizuje. Przy opcji iluśset przedmitów i ilość_drużyn*8 zawodników którzy mogą wykonywać akcję + działanie administratora dorzucającego efekty, zadania itd, można założyć że osiągamy podobny jeśli nie większy stopień skomplikowania.

Może warto byłoby przygotować najpierw prostą makietę systemu, jeden użytkownik, kilka przedmiotów, kilka interakcji, prosty scenariusz. Fragment większej całości. Będzie wtedy można próbować wdrażać takie mechanizmy jak własnie listy zadań, próba jak najbardziej zbliżenia całosci do czasu rzeczywistego itd. Bo narazie to wróżenie z fusów, mi też brakuje doświadczenia od strony programowania takiej gry, być może rzeczy które wydają mi się chwilowo nieosiągalne (albo osiągalne dużym nakładem mocy serwera) da się zrobić inaczej i tak naprawdę nie będzie z tym problemu. Taki prototyp pozwoliłby odpowiedzieć na wiele pytań i dałby szanse aby ubić kilka teorii już w zarodku :)

slawek

Jak najbardziej jestem za stworzeniem makiety! Również jak najbardziej jestem za czasem rzeczywistym a nie turami - aktualizowanie stanu raz na dobę, czy nawet raz na godzinę odpada :) Zaczynam poważnie martwić się, czy wybrana technologia jest w stanie zapewnić to, o czym z Mateuszem dyskutowaliśmy omawiając założenia projektu. Jeśli już na początku trafiamy na jakąś ścianę, nie wróży to dobrze na przyszłość. Powtórzę się, ale poproszę jeszcze raz - zastanówmy się, proszę, czy jeszcze nie pora zrobić to w C++. Będę chciał o tym z Wami porozmawiać podczas sierpniowego spotkania - mam swoje argumenty, z uwagą wysłucham Waszych :)

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

z webowej w django na c++, to całkowicie inna bajka. Tak naprawdę plusy i przewagi django to:
- zadziała u każdego na każdym urządzeniu z każda przeglądarką, bez instalacji
- stworzenie porównywalnej funkcjonalnie aplikacji to jakieś 1/100 podobnego czasu w c++.

C++ zasadniczo nie ma ograniczeń jako takich, no ale to właśnie coś za coś, czas na zaprogramowanie takiego rozwiązania (a tak samo jak przy django, nie ma gwarancji czy to co wyjdzie będzie miało jakikolwiek sens i do czegokolwiek się przyda) rośnie niesamowicie. Nawet przejście na wyższy poziom (chociażby c#) to i tak będą kilogramy dodatkowych założeń (obsługa połączenia obiektów do bazy danych, stworzenie protokołu pomiędzy klientami a serwerem, synchronizacja, warstwa graficzna, zabezpieczenie tego).

Wtedy z projektu, którego po zaprojektowaniu, dałoby się stworzyć w miare działającą wersję w miesiąc w 1-2 osoby, powstanie projekt który faktycznie będzie mógł spełniać wszystkie te wymogi, ale raczej nastawiałbym się na rok zabawy w dużo większym gronie

slawek

Biblioteka Django pozwala tworzyć elementy interfejsu webowego przez proste wywoływanie metod. Interfejs gry w przeglądarce mamy, że tak powiem, załatwiony już na wstępie. Główne zadanie to napisać Pythonową aplikację, która wyrzuci wszystko do interfejsu. Jeśli chcielibyśmy wystartować z C++, to musielibyśmy się mocno zastanawiać, jak stworzyć interfejs webowy. Nie będę kwestionował możliwości jeżyka C#, bo wiadomo że ma ogromne. Tutaj chodzi o cel i narzędzia, których trzeba użyć do jego osiągnięcia. Python na pewno nie wyręczy C# przy tworzeniu oprogramowania dla urządzeń, a C# nie zastąpi Pythona w środowisku internetowym.

Google używa Pythona dla wielu zadań oraz w aplikacjach Google Groups, Gmail i Google Maps oraz w silniku wyszukiwarki. Youtube, NASA, Yahoogroups to inne przykłady. To tylko w zastosowaniu webowym. Więcej zastosowań http://en.wikipedia.org/wiki/List_of_Python_software
Tak na marginesie Google pracuje nad przyspieszeniem Pythona nawet do 5 razy. Projekt nazywa się "unladen-swallow" http://code.google.com/p/unladen-swallow/

Wybrane technologie Django i Python nadają się do środowiska, w którym będziemy projektować.
Mam nadzieję, że przekonałem :-)

Oczywiście też jestem za stworzeniem prostej makiety systemu.

Otwieramy nowy wątek dla makiety: http://vmb.skyfigure.com/node/110

Na razie jeszcze nie jestem przekonany, ale to nic - w niczym to nie przeszkadza ;) Myślę, że na sierpniowej nasiadówce wystarczy mi 10 minut intensywnej rozmowy z Wami, żeby przekonać się do Django (jako rozwiązania dobrego dla projektu). Do Pythona nie muszę - jest świetny (na ile zdążyłem się zorientować przeglądając dokumentację hehe).

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

Tu najgorsze ze nie django a sam protokół http jest problemem. Czegokolwiek byśmy nie użyli, a co będzie działać po http będzie cierpieć na te same problemy. Sam jestem ciekawy do jak krótkiej tury uda nam się zejść, trochę poszukałem i za bardzo nie ma systemów pisanych w django które by działały w pseudoczasie rzeczywistym.

slawek

Dlatego pierwotnie myślałem o UDP :) Widziałem, że Python ma moduł Socket, więc prawdopodobnie (nie znam Pythona) jest możliwość komunikacji w oparciu o protokół UDP. Jednocześnie spodziewam się, że sprawa nie jest do rozwiązania w oparciu o Django. Ale spokojnie - być może bardzo dobrym pomysłem jest zbudowanie pierwszego modelu w oparciu właśnie o Django, żeby zobaczyć co w ogóle w trawie piszczy :) Jednak na razie bronię się przed myślą, że wersja finalna ma mieć tak ograniczoną - z racji architektury - funkcjonalność :)

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

Podstawowa sprawa, której potrzebujemy w dyskusjach, to starać się utrzymać w tematyce wątku (nawet bez moderatora). Temat, w którym piszemy, dotyczy w zasadzie pomiaru czasu/sterowania czasem i zagadnienia mocno powiązanego - symulować bardziej, czy mniej.

Dyskusja Django vs. reszta świata nie na miejscu.

Link przesłany przez Bartka: http://vmb.skyfigure.com/node/96 zdaje się sprawę rozwiązywać, dodatkowe posty (tematyczne) zbiegają do konkluzji: warstwa sprzętu (instalacje bazy) jest uproszczona, czas płynie w sposób ciągły (oczywiście przez ciągle rozumiemy taktowanie jakąś jednostką).

Pierwszy cel

Czy możemy zatem myśleć, że Pierwszy cel zdefiniowany jest jako przygotowanie
warstwy sprzętowej bazy (Hardware)? Baza powinna funkcjonować (przynajmniej przez pewien czas, np. dopóki pracuje reaktor) nawet bez żyjących w niej ludzi. Możemy uruchomić program i po zalogowaniu monitorować parametry stanu (ilość tlenu, woda, etc.), przygotować system powiadomień (SMSy, majle, wiadomości Jabbera). Później, dojdzie możliwość interakcji ze sprzętem, każdy z graczy (Peopleware) będzie miał dobudowywane możliwości wpływania na zmiany parametrów stanu obiektów fizycznych - ustalone i zaprogramowane zostaną sposoby interakcji i gra zostanie uruchomiona.

Podsumowując, podstawowe zasady tworzenia takiej warstwy sprzętowej mogłyby się zawierać ogólnie w trzech punktach:

  • istnieją obiekty fizyczne nieożywnione (np. instalacje bazy), których ewolucję (zmiany parametrów stanu w czasie) modelujemy pewnymi regułami (trochę losowo a trochę deterministycznie), reguły te mogą (i czasami muszą) uwzględniać stan innych obiektów fizycznych
  • wersja podstawowa gry zakłada niedużą ilość takich obiektów i proste reguły, ale pamiętamy o tym, że w przyszłości możemy chcieć to komplikować
  • obiekty ewoluują zgodnie z 'ciągłym' upływem czasu (implementacja 'upływu czasu' może być realizowana - i pewnie będzie, za pomocą CRONa)

Jeśli trafnie udało mi się podsumować temat, może warto byłoby teraz określić podstawowe instalacje/przedmioty, które będą zaprogramowane a następnie określić ich atrybuty (parametry stany, reguły opisujące ewolucję)?

Jeśli mamy zaczynać od najprostszych rzeczy, to proponuję zbudować na początek "środowisko" złożone tylko ze ścian ograniczających pomieszenia, powietrza wewnątrz, uprawy jako całości i paru prostych urządzeń. Gra byłaby dla ośmiu osób, które mogłyby:
- poruszać się po pomieszczeniach, klikając po kolei którędy awatar ma iść (na planszy pojawiałaby się np. pulsująca zielona kropka z imieniem awatara i aktualnymi pozycjami innych awatarów)
- podchodzić do paneli kontrolnych urządzeń (klikanie na czerwone kropki z nazwami paneli); po kliknięciu z boku okna ukazywałby się dany panel kontrolny i tam można będzie wydawać proste polecenia, np. zwiększ moc reaktora
- w module agrokultury byłby po prostu jeden panel, na którym prosta procedurka wyświetlałaby stan upraw losowo generujący wzrost na poszczególnych grządkach, można by też regulować ilość dostarczanego nawozu i wody
- logowanie i wylogowywanie następowałoby z przypisanej graczowi "kajuty" w module mieszkalnym
- w module badawczym, na panelu głównego komputera można by wczytywać po prostu strony internetowe, bez wnikania w opóźnienia czy takie tam różne
- generalnie, w środowisku działyby się losowe awarie systemu podtrzymywania życia (trzeba wyjąć skądś jakąś część, zanieść do warsztatu, naprawić i zamontować z powrotem), trzeba pisać dzienne raporty, np. stan upraw czy odczyt warunków na zewnątrz bazy (generowanych losowo) - będą za to punkty
- i to na tyle :) będzie też dostępny chat, na którym można pogadać z innymi zalogowanymi

Myślę, że więcej na razie nie potrzeba. Na tej podstawie, zalogowani twórcy gry (pewnie sobie zarezerwujemy tych pierwszych 8 miejsc ;) będą mogli dyskutować i ulepszać rozwiązania, sprawdzając co jak działa w praniu.

W załączniku propozycje "plansz". Mogę coś pokombinować w ten deseń, żeby były wyraźniejsze. I można programować! :D

--
Wojtek

AttachmentSize
plansza1.jpg371.49 KB
plansza2.jpg378.57 KB

W załączniku propozycje "plansz". Mogę coś pokombinować w ten deseń, żeby były wyraźniejsze...
Nie ma takiej potrzeby, plansze są tutaj: http://vmb.skyfigure.com/node/93

Chodziło mi konkretnie o tło tej najprostszej wersji :)

Dzisiaj rano stworzyłem w pół godziny takie cuś, co wrzuciłem w PDF-ie w załączniku. Tu jest wszystko co trzeba do podstawowej "rozgrywki", czyli:
- poruszamy się po planie bazy, po prostu kilkając wybrane pomieszczenia (żeby nie było zbyt prosto można tak zrobić, żeby z pomieszczenia gdzie aktualnie jesteśmy dało się kliknąć tylko w drzwi a potem już na korytarzu tylko w drzwi (lub śluzy) które posiada ten korytarz); "ikonka" awatara pojawia się w wybranych miejscach (lub przesuwa, nie wiem jak z programowaniem tego)
- klikamy na ikonkę panelu, np. CENTRUM KONTROLI w module centralnym i wyświetla się po prawej stronie graficzka danego panelu z aktywnymi przyciskami, można już tam coś podziałać, albo odczytać komunikaty
- obok panelu jest też chatbox (to ta playlista winampa, hehe, posłużyłem się wzorami skinów, bo to najprościej :D) chatbox jest oczywiście zawsze aktywny
- aha, zapomniałem jeszcze o okienku, gdzie będzie wyświetlany aktualny status naszego awatara, np. stan wskaźników, ilość punktów, itp.

No i tyle :D Można sobie chodzić, klikać, gadać...

Eeeee, czy mógłby ktoś albo usunąć te dwie plansze które wcześniej wrzuciłem, albo zwiększyć limit załączników, bo nie mogę wrzucić PDF-a?

No i tyle :D Można sobie chodzić, klikać, gadać...
Gdyby to było takie łatwe...

...albo zwiększyć limit załączników, bo nie mogę wrzucić PDF-a?
Już powinno działać, a jeśli nie to daj znać.

Poruszamy się po planie bazy, po prostu kilkając wybrane pomieszczenia...
...z pomieszczenia gdzie aktualnie jesteśmy dało się kliknąć tylko w drzwi a potem już na korytarzu tylko w drzwi (lub śluzy) które posiada ten korytarz...; "ikonka" awatara pojawia się w wybranych miejscach...

To jest jedno z podejść do problemu poruszania się po bazie, inne może być z wykorzystaniem widoków aksonometrycznych: http://vmb.skyfigure.com/node/111#comment-136

Jeśli idzie o dyskusję na temat poruszania się po bazie, przejdź do wątku: http://vmb.skyfigure.com/node/112

OK, działa, dzięki :)

Na tej planszy umieściłem niezbędne minimum do podstawowej rozgrywki. Nie wiem czy da się to prosto zaprogramować, ale składa się to tylko z wczytywania grafik w odpowiednim miejscu i odpowiednim momencie, oraz wyświetlania tekstu także w odpowiednim miejscu i momencie. Z grafik jest tylko: obraz tła, okno chatboxa i około 4-5 paneli poszczególnych urządzeń - robota na 1 dzień, mogę się tym zająć. A jak będzie z programowaniem tego?

AttachmentSize
okno_gry_VMB.pdf261.86 KB

Jak będzie z programowaniem to obecnie dyskutujemy, ale już teraz można powiedzieć, że roboty będzie na wiele miesięcy.

Ja bym nie rozgraniczał 2 rodzajów mapy: czyli sytuacyjnej, takiej, jak przedstawiłeś Wojtek na bazie planu Janka i interaktywnej, czyli takiej, na której gracz bezpośrednio wykonuje jakieś działania.
Jeżeli ograniczymy się do mapy sytuacyjnej, znowu nie będziemy mieli podstaw do tego, żeby się przesiąść na 3D w kolejnej wersji. A dwa rodzaje map 2D są moim zdaniem niepotrzebne. Rzut sytuacyjny można wykonać przez skalowanie, coś jak w Sim City?

m

Zarząd Mars Society Polska
www.marssociety.pl

Nie temacie w pełni, ale: mam wrażenie, że 'płaski' (http://drupal.org/project/flatcomments) system komentarzy ułatwi nawigację po postach..

Uważam, że takie proste rozwiązanie (w sensie szkicu Wojtka) jest OK. Pamiętajmy, że szczegóły template'u możemy zmieniać w każdej chwili w oderwaniu od reszty warstw systemu (o ile oczywiście się odpowiednio o to zadba), więc po tej pierwszej fazie, kiedy będą gotowe podstawowe systemy bazy: prosta warstwa sprzętowa i główne elementy interface'u dla gracza, będzie można pomyśleć o urozmaiceniu.

Na pierwszy rzut oka wydaje mi się, że łatwiej będzie (programowo) poradzić sobie z widokiem prostej planszy 2D - na starcie najwięcej kłopotu sprawi i tak niewidoczny środek oprogramowania. Przy tworzeniu 'makiety' gry zatem, może nie warto komplikować dodatkowo wyglądem? Prawdopodobnie i tak już na starcie nie obędzie się
bez JQuery (lub innego JavaScriptowego frameworka), co zresztą wcale nie jest wadą, ale pewnie będziemy chcieli minimalnie komplikować, więc moim zdaniem 2D mapka na razie jako główny wygląd jest OK.

Te widoki aksonometryczne są faktycznie ładne... Możne je dołączyć jako fajne w startowej wersji jako zajawki - widoczne gdzieś w grze - powiedzmy jesteśmy w widoku na planszy gdzieś w jakimś module, a w panelu z boku pojawiają się ładowane AJAXem wymmienne obrazki 3D (mamy dostępnego Sketchupa i pewnie wiele innych programów, więc chętni marsjańscy architekci mogą puszczać wodze...)

.. mapek, interfejsu itd, i sam zaczynam się zastanawiać czy django to dobry pomysł w takim przypadku. I mówiąc django mam na myśli cokolwiek opartego na protokole http i przeglądarce. Zaczyna się pojawiać grafika i działania na niej (najprostsze, ok, to się uda, ale im będą cięższe rzeczy tym większy problem różnic pod przeglądarkami i w ogóle osiągania prostych efektów), połowa założeń traci sens jeśli się okaże ze jesteśmy zmuszeni robić turę co np 2 minuty.
Grafika jest jeszcze do przeskoczenia (javaScriptowe silniki są coraz bardziej wydajne, biblioteki takie jak jquery dają duże możliwości za stosunkowo mały nakład czasu), tak to że będzie działać to na http jako strona, powoduję ograniczenia które do pewnego momentu będzie można przeskakiwać, ale nagle ściana będzie już za wysoka. Http to protokół bezstanowy, wejście na nowy link poowduje że serwer nic nie wie o poprzednim stanie, wszystkie obiekty muszą być wczytywane, sprawdzane, wrzucane do pamięci od nowa. Są sesje i ciasteczka, ale to nie zadziała przy 200 rozbudowanych (nawet średnio) obiektach. To co jest banalnie proste i samo się wręcz narzuca przy tym projekcie (trzymamy świat w pamięci, obiekty raz tam załadowane już tam siedzą, operacje są szybkie, interakcja jest szybka, symulacja czasu rzeczywistego faktycznie taki przypomina, bo tura trwa przykładowo sekundę) praktycznie przekreśla wszystko to czym jest i do czego wykorzystuje się protokół http.
Dlatego gry online wyglądają i przedstawiają sobą to co przedstawiają, czyli w sumie rozbudowane excele, proste akcje, dużo współczynników, ale nie ma tam rozbudowanej grafiki, interakcji w czasie rzeczywistym między ludźmi (bardziej skomplikowanej niż przekazanie kilku liczb).
Jak to mówią, albo rybki albo pipki :)

slawek

Całkowicie podzielam Twoje uwagi, Sławku. Nie chcę w tej chwili dyskutować czy Django, lub co zamiast Django - mam nadzieję, że o tym pogadamy wyczerpująco na spotkaniu :) Nie znam wielu nowych technologii, nie wiem czy dla C++ lub C# nie ma przykładowo gotowych engine-ów gier, które zdjęłyby z programistów konieczność pisania wszystkiego od gołej ziemi (przynajmniej w zakresie obsługi grafiki - sprite'y, blitting itd). Jedno wiem na bank - potrzebujemy platformy szybkiej, wydajnej, pozwalającej bezproblemowo zrealizować założenia projektu (jednymi z których są realtime-owość, interaktywność oraz atrakcyjność graficzna), oraz dającej gwarancję, że na pewnym etapie rozwoju projektu nie natrafimy na ścianę nie do przeskoczenia. I nie chodzi mi tu o brak umiejętności, lecz o ograniczenia wybranej technologii. W związku z faktem, że się powtarzam, deklaruję nie napisać już ni pół słowa na ten temat - aż do naszego spotkania ;)
Aha, w przypadku tego projektu w założeniach nie było statycznych teł i linków do klikania [proszę nie rozumieć tego jako wyrzut/zarzut/cokolwiek o negatywnym zabarwieniu - proszę traktować to stwierdzenie wyłącznie informacyjnie] :)

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

Ja jako kompletnie VMB postronna osoba (prawdopodobnie wiem na temat projektu najmniej) uważam, że decyzja dotycząca wyboru techonolgi (desktop/web_inteface) jest mocno dyktowana następującym faktem: ludzie z zewnątrz znacznie chętniej zainteresują się projektem, jeśli wystarczy im do tego przeglądarka internetowa. Ludzie z zewnątrz, którzy wcale nie muszą być graczami.

Oczywiście, problemy które podnosisz są istotne (jestem w biegu i niestety nie mogę teraz się ustosunkować, jako zwolennik jednak webowej koncepcji, a myślę że sensowne kontrargumenty da się przedstawić) i dyskusja web/desktop jest uzasadniona tymi własnie sprawami..

ale chyba kluczowe pytanie: kto będzie z tego korzystał?

Ja tez jestem jak najbardziej zwolennikiem webowej wersji, szybkość tworzenia, łatwość dostępu i możliwości korzystania na praktycznie wszystkich platformach (również mobilnych), same zalety.
Tylko że niestety to nie jest magiczne cudo i nie jest do wszystkiego. A patrząc na główne założenia nie będzie tu pasować, bardzo szybko zacznie ograniczać i męczyć.

Więc tak naprawdę są 3 wyjścia:
- webowa gra przy tych założeniach, ale prędzej czy później (według mnie prędzej, ale nie mam doświadczenia akurat przy tworzeniu czegoś co miałoby działać w pseudo rzeczywistym czasie) pojawi się naprawdę potężny problem którego już nie da sie przeskoczyć
- desktopowa aplikacja - wiadomo, nieograniczone możliwości, ale projekt dużo trudniejszy, efekty też po dłuższym czasie, możliwość tego że tak naprawdę powstanie projekt dla sztuki.
- webowa gra, ale przy innych założeniach, diametralnie innych niestety :(

slawek

Też piszę na ten temat tutaj: http://vmb.skyfigure.com/node/112#comment-154

Chciałbym podkreślić, że zaproponowana przeze mnie wersja jest tylko testowo-demonstracyjna i ma za zadanie jedynie przetestować "w praniu" tak podstawowe sprawy jak zwykłe operowanie grafikami czy minimum interakcji pomiędzy awatarami i środowiskiem.

Z własnego doświadczenia wiem, że jeśli nad czymś pracuję, to najpierw robię wersję totalnie banalną i minimalnym kosztem, żeby sprawdzić jak poszczególne elementy ze sobą współgrają i jak to wszystko "w kupie" wygląda. Zwykle wtedy przekonuję się, że koncepcję całości i tak muszę przebudować patrząc ten uproszczony model. Zapewne tak też będzie w przypadku tej gry. Na razie wszyscy jesteśmy pełni pomysłów i dopóki chociaż jednego nie zrealizujemy, to możemy dyskutować w powietrzu do przyszłej zimy :)

Słusznie zapytał sebzur - kto z tego będzie korzystał?

Jeśli ma to być promocja eksploracji Marsa dla szerszej publiczności, to nie oszukujmy się, tacy ludzie zajrzą, pobawią się i przerzucą się na coś nowego. Takie mamy czasy. Nie ma więc sensu w takim przypadku robić wersji rozbudowanej, bo i tak ludzie (w sensie - większość) prędzej znudzi się niż dojdzie do końca. Na mój gust ta gra powinna zajmować około kilkunastu godzin czasu "do przejścia". Myślę, że lepiej żeby ktoś szybciej ją skończył, ale z sukcesem, niż zniechęcił się i zostawił niedokończoną.

Przytoczę z dokumentacji:

Celem Projektu Wirtualnej Bazy Marsjańskiej (VMB) jest stworzenie internetowej, wieloosobowej, edukacyjnej gry symulacyjnej online.

Na tej podstawie można stwierdzić, że odbiorcami projektu VMB Game będą gimnazjaliści i uczniowie szkoły średniej.

Takie mamy czasy. Nie ma więc sensu w takim przypadku robić wersji rozbudowanej, bo i tak ludzie (w sensie - większość) prędzej znudzi się niż dojdzie do końca.
Mnie - osobiście - nie interesuje większość (jestem Wodnikiem hehe). Czy chcemy robić projekt "pod publikę", czy rzecz bardziej ambitną? Chcemy adresować projekt do ogromnej rzeszy ludzi plastikowych ("Takie mamy czasy [...]"), czy też może ograniczonej liczby ludzi rzeczywiście zainteresowanych tematyką, którzy do gry podejdą z pasją?

Na mój gust ta gra powinna zajmować około kilkunastu godzin czasu "do przejścia".
To nie ma być gra, którą "się przechodzi". I na pewno nie w kilkanaście godzin.

Myślę, że lepiej żeby ktoś szybciej ją skończył, ale z sukcesem, niż zniechęcił się i zostawił niedokończoną.
Myślę, że lepiej zrobić kulinarny majstersztyk niż hamburgera. Wolę zostawić projekt niedokończony (bo nie wyklucza to poczynienia wielu ciekawych obserwacji i dojścia do ciekawych wniosków "po drodze") niż zrobić coś na szybko, co po prostu (i tylko) "będzie", bo chciało się szybciej skończyć. Szybkość ukończenia nie jest jednym z priorytetów projektu.

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

Abstrahując nieco od środka ciężkości kilku ostatnich postów (web/desktop) - pragmatyzm Wojtka do mnie przemawia.

I całkiem w temacie: bardzo zachęcam do przeczytania fantastycznej książki: Dreaming in Code. Może pomóc w wielu dyskusjach. :D

Też chciałbym, żeby powstał kulinarny majstersztyk (w końcu też jestem wodnikiem pełną gębą :D). Tylko że od zera tego nie stworzymy dysponując przecież ograniczonymi środkami (chociaż niczego nie przesądzam i z chęcią bym zobaczył, jak sprawiacie mi niespodziankę). Niestety, ostatnio mocno spragmatyziałem i zaczynam rozumieć dlaczego rzeczy małe w założeniu, które okazały się duże w praktyce są lepsze od dużych planowanych, które słabo wypaliły.

Wracając do tematu - jako pierwszy cel zróbmy banał na próbę, chyba nam nie zaszkodzi? Doświadczenie które zyskamy będzie bezcenne. Ta strategia nigdy mnie nie zawiodła i pozwoliła uniknąć wielu błędów.

Wracając do tematu - jako pierwszy cel zróbmy banał na próbę, chyba nam nie zaszkodzi? Doświadczenie które zyskamy będzie bezcenne. Ta strategia nigdy mnie nie zawiodła i pozwoliła uniknąć wielu błędów.
Nie jest to złe rozwiązanie, pod warunkiem, że będzie traktowane jako wprawka (lub - ciągnąc kulinarne analogie - przystawka), a co za tym idzie, nie będzie wersją publiczną. Byłoby to marketingowo słabe (ogólnie mówiąc) posunięcie :)

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

...dlatego w tym momencie odsyłam do źródła, jakim jest podstawowa makieta: http://vmb.skyfigure.com/node/110

Źródło zaczyna się od zdania:
Zachodzi potrzeba stworzenia prostej, bardzo ograniczonej makiety systemu gry, aby stworzyć pierwszy model wyjściowy do dalszej rozbudowy.
Sformułowanie "dalsza rozbudowa" budzi moje wątpliwości. Jeśli Django nie zostanie "klepnięte" jako właściwe narzędzie pracy, mam wrażenie, że owa makieta nie przyniesie nic, poza stratą czasu i pracy. Skoro makieta ma być rodzajem eksperymentu, to - jak każdy eksperyment, który ma przynieść miarodajne, uczciwe wyniki - powinna zostać wykonana na bazie założeń i narzędzi, które da się potem zastosować w większej skali. Nie da się przeprowadzić doświadczenia na dziesięciu królikach i wysnuć wniosku, że jego wyniki będą dotyczyć również tysiąca gołębi. Dlatego jestem jak najbardziej za zrobieniem prostej makiety, ale dopiero po ostatecznym wyborze technologii i narzędzi. Inaczej - uważam - będzie to co najmniej lekkomyślne. Czasem lepiej jest przez chwilę nie robić nic (tylko do spotkania!), niż robić coś bez sensu dla samej idei robienia.
Nie traktujcie, proszę, mojego uporu jako trollowania albo bicia piany - nie taki jest mój cel. Z uwagi na to, że pierwsze założenia projektowe były formułowane ponad 2 lata temu i wiele rzeczy mam przemyślanych i poukładanych, projekt traktuję nieco jak własne dziecko i na pewne kwestie trudno mi godzić się z marszu i bez dyskusji :)

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

Skoro makieta ma być rodzajem eksperymentu, to - jak każdy eksperyment, który ma przynieść miarodajne, uczciwe wyniki - powinna zostać wykonana na bazie założeń i narzędzi, które da się potem zastosować w większej skali.

Zgadzam się! Jednak nie możemy wykluczyć, że dopiero eksperyment ukaże nowe możliwości i założenia będzie trzeba zmienić.
Uważam także, że nadal musimy dyskutować na tematy mniej i bardziej potrzebne, tak aby mieć duży wachlarz koncepcji na spotkanie.

Dokładnie o to mi chodziło - przekąska. Wspomniałem nawet, że to my będziemy pierwszymi awatarami. Pobawimy się i będziemy mieli materiał do dyskusji.