Teoretyczny model obiektu

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.

Model teoretyczny to konstrukcja hipotetyczna odwzorowująca dany rodzaj rzeczywistości w sposób uproszczony, sprowadzający jej cechy do związków najistotniejszych.

Jak powinien wyglądać model obiektu VMB?

W wątku http://vmb.skyfigure.com/node/101 pojawiło się kilka propozycji. Jedna z nich dotyczy przydzielania obiektów do danej kategorii.

"...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."

Tak sobie myślę, że może warto spojrzeć na obiekt z punktu widzenia bazy danych, bo i tak będzie trzeba zrobić reprezentację obiektu w bazie danych. Trzeba stworzyć odpowiednie tabele i relacje między nimi.

Propozycja tabel (szkic):
- Tabela "object" - kolumny: "id", "nazwa".
- Tabela "interaction" - kolumny: id, nazwa. (?)
- Tabela "category" - kolumny: id, nazwa. (?)
- (?)

Jeżeli możecie to proszę o zmianę lub robudowę.

Chciałbym w tym miejscu zasygnalizować zainteresowanym programowaniem, że opis tworzenia modeli w Djano znajduje się w Djangobook, Chapter 5: Models (http://www.djangobook.com/en/2.0/chapter05/).

Wydaje mi się, że lepszym podejściem byłoby:

w bazie danych mamy obiekty wraz z wszystkimi parametrami, jedna tabela to jeden rodzaj obiektów (tabele mają rózne kolumny, gdyż rózne obiekty mają różne parametry). Plusy to szybkość, łatwość obsługi z programu (obiekt w programie do obiektu w bazie będzie mapowany 1 do 1), minusem jest to ze mamy tyle tabel ile kategorii obiektów (może być problem jeśli ilość kategorii będzie bardzo bardzo duża).
Druga możliwość to jedna tabela objecs i druga tabela objects_attributes, i dynamiczne łączenie obiektów z atrybutami. Mniej tabel (tylko 2, niezależnie od ilości kategorii), ale większy bałagan i nie tak banalne już łączenie obiektów w bazie z obiektami w programie.

Interakcje trzymałbym raczej w kodzie programu, jako cechy obiektów (a w zasadzie kategorii). Byłyby wtedy jawnie do niego przywiązane (albo dodane do tej właśnie kategorii, albo kategoria otrzyma tą interakcje poprzez dziedziczenie z kategorii nadrzędnej).

slawek

Co jeśli byśmy zrezygnowali z Kategorii obiektów? Zrobilibyśmy tabelę Obiekty, tabelę Czynności_na_obiekcie, tabelę Czynności_przez_obiekt, tabelę Atrybuty Obiektu, itp. a następnie łączenie tabel.

Np. Obiekt 5 ma atrybuty: 1, 3, 8, 14 i można na nim wykonać Czynności: 4, 7, 26, on sam może wykonać czynność 3, 26
itd.

Szybko można sprawdzić w jakiej relacji jest dany obiekt z innymi za pomocą czynności i atrybutów.

1) Dlaczego baza danych?
2) Gdzie w owej bazie (i w jakiej formie) osadzony byłby kod wykonywalny konkretnego zdarzenia dla obiektu?
3) Dlaczego nie obiekty jako klasy (opisane językiem skryptowym) z wykorzystaniem interfejsów? W bardzo łatwy sposób można by było modyfikować/rozszerzać obiekty danej klasy poprzez dziedziczenie.

Mam nadzieję, że wetknąłem kij w mrowisko :)

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

Kod VMB jest pisany w Pythonie, a dostępność Wirtualnej Bazy przez internet jest zapewniona dzięki Django framework, który także jest napisany w Pythonie.
Django korzysta z architektury MVC (ang. model-view-controller, model-widok-kontroler). Prościej: w tym sposobie tworzenia stron kod odpowiedzialny za definiowanie i dostęp do danych (model) jest oddzielny od logiki biznesowej (kontrolera) oraz od interfejsu użytkownika (widoku).

Wszystko stanie się jasne, po zapoznaniu z pierwszymi rozdziałami w książce Django:
Polska wersja: http://django.wikidot.com/
Oryginał po angielsku: http://www.djangobook.com/

1) baza danych aby trzymać stany obiektów, robiąc grę z interfejsem webowym trzeba mieć na uwadze że serwer może przykładowo zostać zrestartowany i stany muszą być gdzieś zapisane.
2) w mojej propozycji niebyłby, zdarzenia obiektów jako właściwości kategorii, czyli kod byłby zapisany w definicji kategorii (klas)
3) tak właśnie proponowałem :)

Co do propozycji Nobarte, własnie jest problem bo i tak kod tych funkcji musiałby być gdzieś zapisany. Łatwiej i wygodniej trzymać go i pilnować przy definicji kategorii ( czyli w djangowym modelu, który jako taki można dziedziczyć)

slawek

Dzięki, Sławku, za odpowiedź - pewne sprawy mi się wyjaśniły.

Nie kwestionowałem zasadności użycia bazy danych - jest niezbędna do przechowywania stanu gry (takie było założenie od samych narodzin pomysłu), jednak nie było dla mnie jasne w jaki sposób chcecie przechowywać całą logikę. I nadal nie jest :) Czy bierzecie pod uwagę możliwość (i czy taka istnieje w przypadku Django) przechowywania logiki obiektów w zewnętrznych plikach tekstowych na serwerze ? Nie znam Django ani Pythona - pewne moje pytania wynikają z tej nieznajomości, jednak - mam wrażenie - wiele z nich jest natury bardziej ogólnej, może nawet filozoficznej ;) Tu chodzi mi o zasadę - czy da radę zrobić to tak, jak funkcjonują skrypty Lua dla WoW? Wszystko, co dzieje się w czasie trwania jakiegokolwiek projektu, jest konsekwencją przyjętych na początku założeń. Im mniej przemyślane założenia, tym większy ból w zadzie później ;)
Proszę też o odpowiedź, czy aplikacje tworzone w Django działają na zasadzie, że dopiero zapytanie klienta generuje pewną akcję po stronie serwera? Czy też aplikacja na serwerze działa w czasie rzeczywistym, nieustannie aktualizując stany obiektów (przykład: avatar poza bazą z rozdartym EVA Suitem - tutaj ubytek "energii życiowej" odbywa się bez względu na fakt, czy użytkownik jest w ogóle zalogowany)? To wywołuje kolejne pytanie "filozoficzne" - czy można uszkodzić EVA Suit avatarowi, którego użytkownik nie jest zalogowany i nie może na to zareagować? ;)

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

Logikę obiektów zapisuje się raczej przy definicji modelu ( u nas modelem jest kategoria, czyli w sumie klasa która dziedziczy po klasie Djangowej, co daje nam dostęp do bazy danych). Te dane są zapisywane w plikach tekstowych na serwerze, tylko że są one że tak powiem głownym elementem działania systemu. Jeśli chodzi o to czy można dynamicznie dodawać fukncjonalności (czyli interakcje) do działającego systemu(nie wiem jak to wygląda w skryptach dla WoWa), to moja odpowiedź brzmi : być może :) W sensie wydaje mi się że teoretycznie tak, ale raczej interakcje będziemy trzymali w modelach i nie będą się one zmieniały. Dopisać je bez zmian czy zatrzymywania całego systemu można ( nie jest tak z elementami które mają odpowiedniki w bazie danych, bo trzeba je również tam nanieść).
Co do drugiej części pytania: zasadniczo działają tak jak piszesz, czyli zapytania klienta wywołują akcję na serwerze (bo tak działa protokół http i ogólnie takie jest założenie działania stron www). Ale ale, nic nie stoi na przeszkodzie, żeby na tej samej bazie w tym samym czasie w którym działania mogą wysyłać użytkownicy, nie działał skrypt który symulowałby działanie ciągłe. Byłby uruchamiany co 1,2,5,100 sekund (dowolnie), przeliczałby co trzeba, nanosił poprawki na stan obiektów w bazie i tak cały czas. A użytkownik dostawałby dane z ostatniego przeliczenia.
Musimy pamiętać że to jest gra i jako taka musi przyjąć dużo uproszczeń świata który ma opisywać. A granica między upraszczaniem a dokładnym odwzorowaniem jest tak naprawdę granicą kiedy to będzie jeszcze gra a kiedy sztuka dla sztuki, rozbudowany kalkulator który będzie w kólko liczył, poprawiał, przesuwał itd itd

pozdrawiam i mam nadzieje, że trochę wyjasniłem jak to w django wygląda. Jeśli dalej będzie to niejasne to zawsze mogę przygotować krótkie fragmenty kodu i na ich podstawie coś pokazać

slawek

Ale ale, nic nie stoi na przeszkodzie, żeby na tej samej bazie w tym samym czasie w którym działania mogą wysyłać użytkownicy, nie działał skrypt który symulowałby działanie ciągłe. Byłby uruchamiany co 1,2,5,100 sekund (dowolnie), przeliczałby co trzeba, nanosił poprawki na stan obiektów w bazie i tak cały czas...

Dyskusja na ten temat: http://vmb.skyfigure.com/node/99#comment-44

OK, rozumiem, że jedną z funkcji MarsBota byłby timing głównej pętli symulacji/gry.

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

Dziękuję za odpowiedź! Czy mógłbym Cię jeszcze poprosić o bardzo schematyczne przedstawienie (fragmentem kodu) definicji np. obiektu Rover? Kiedyś założenie teoretyczne było takie, że klasa Rover dziedziczy po klasie GroundVehicle, która z kolei dziedziczy po klasie Vehicle, która może być abstrakcyjna, lub dziedziczyć po klasie Object (już jako klasie wbudowanej języka programowania). Czy w Django jest to do zrobienia na zasadzie zdefiniowania klasy bazowej a następnie definiowania klas pochodnych z atrybutem (lub odpowiednikiem atrybutu) "inherits"? Bo jeśli nie, to może lepiej zrobić rzecz w C++?

Pozdrawiam! :)

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

W django obiekty którymi byśmy się posługiwali dziedziczą już po klasie Model, gdzie siedzą takie rzeczy jak obsługa bazy związanych z tym modelem itd, czyli u nas taka przykładowa definicja pewnie wyglądała by pewnie jakoś w stylu:

class Vehicle(models.model):
masa = FloadField()
Class meta :
abstract = true

class GroundVehicle(Vehicle):
nazwa = CharField()
ilosc_kol = IntegerField()

I obiekt Rover byłby obiektem klasy GroundVehicle i jako taki obiekt mógłby być zapisany w tabeli GroundVehicle, z odpowiednia masa (dziedziczoną z Vehicle), nazwa i ilością kół (które będzie miał jako obiekt GroundVehicle. W bazie zostanie utworzona tabela GroundVehicle o 3 kolumnach :masa, nazwa, ilosc_kol (do klasy vehicle tabela nie powstanie bo jest klasa abstrakcyjna i jako takich obiektów nie będzie).

Zasadniczo tak to wygląda, filozofia bardzo podobna jeśli chodzi o samo programowanie jak w c++, tylko założenie że robimy grę w oparciu o przeglądarkę definiuje głownie jak to będzie wyglądać. Plus jest taki, że stworzenie takiej gry w django to wydaje mi się 1/100 potrzebnego czasu do stworzenia gry o podobnej złożoności w c++.

pozdrawiam serdecznie

slawek

no coz, kod stracil troche na czytelnosci, głownie chodzi o to ze class Meta to nie jest zadna klasa tylko to jest poczepione pod klase vehicle

slawek

OK - już widzę jak to działa. Właściwości wszystkich klas, nie będących klasami abstrakcyjnymi, mają swoje odwzorowanie w stosownych tabelach bazy danych. Instancje poszczególnych klas są - jak sądzę - wierszami tabeli. Chytrze i elegancko. A co z metodami klas? W momencie, gdy zapadnie ostateczna decyzja o podzieleniu obiektów na kategorie (co będzie sensownym rozwiązaniem), pojawi się konieczność stworzenia różnych interfejsów dla różnych kategorii obiektów (choćby nawet jako subsety jakiegoś interfejsu "totalnego", bo nie ma sensu implementować metody "jedz" w przypadku zestawu do poboru próbek geo). Gdzie będzie zaszyta cała logika enginu?

Dziękuję za cierpliwość ;)

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

, dokładnie jak piszesz, obiekty to wiersze. Metody klas wrzuca się też przy definicji klas, czyli:

Class GroundVehicle(Vehicle):
[..]
def JedzDoProdzu(self, avatar, jak_dlugo_jechac):
avatar.pozycja += jak_dlugo_jechac * self.predkosc

, to tak przykładowo. Takie metody są dziedziczone dalej. Intefejsy faktycznie trzeba będzie stworzyć, ale oprócz naprawdę podstawowych funkcji, wydaje mi się że same interakcje będą możliwie najniżej w drzewie dziedziczenia (bo np metoda .zamontujDzialko będzie można wykonać tylko na obierkcie GroundVehicle i tylko przez obiekt kategorii avatar).

A i nie ma za co dziękować, pytania na razie proste, pisze wszystko z głowy więc i nakład czasu mały :)

slawek

Panowie, mam zasadnicze pytanie: czy użytkownik ma mieć możliwość kierowania awatarem jak w grze "planszowej" (generalnie chodzenie, używanie przedmiotów itp.), czy jedynie wydawania poleceń co awatar ma zrobić (np. "wykonaj badanie próbki" a awatar w sposób magiczny znajdzie się w module laboratoryjnym)? Jestem za pierwszym rozwiązaniem, nie mam tylko wiedzy, czy za pomocą wybranego narzędzia programistycznego jest to do zrealizowania. Wprowadzałoby to dodatkową złożoność w zakresie konieczności zaprogramowania bardzo podstawowej "fizyki" postaci, jak na przykład badanie kolizji z innymi przedmiotami lub architekturą, oraz - dodatkowo - problem komiwojażera w przypadku, kiedy awatar realizuje polecenia z listy ToDo. Z drugiej strony mocno podnosiłoby miodność zabawy.

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

Na początek wszystko upraszczamy.

Otwieram nowy watek:

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

wydaje mi się, że trzeba maksymalnie wszystko upraszczać. Opcja z chodzeniem jak w planszówce jest ciekawa, ale przy 200 obiektach to po prostu zarżnie serwer na amen. Aplikacje działające jako strony www, tak jakby nie mają pamięci. Każde wejście na kolejną stronę to nowa akcja, więc znowu trzeba wszystkie obiekty wyciągnąć z bazy, sprawdzić czy któreś na inne nie wchodzą, czy można się tam przenieść itd. I tak po każdym kolejnym kroku( nie do końca tak musi być, ale uogólniając).

Warto przejrzeć istniejące gry online (przez przeglądarkę, ale nie flash czy java, sam html), zobaczyć ile w nich jest zaimplementowanych akcji i zachowań i interakcji. I tak naprawdę na początku jesteśmy w stanie zaoferować jakąś część tego, chyba że są fundusze kilkuset złotych miesięcznie na serwery.

Dodawanie badania kolizji czy szukania drogi łącząc to z problemem komiwojażera - proszę dodać dwa zera na końcu miesięcznego kosztu i MOŻE udałoby się to zrobić żeby w miarę działało. może :)

slawek

Czy nie można pewnych obliczeń przerzucić na klienta? Serwer wysyła coś w rodzaju snapshota lokacji (nie ma potrzeby wysyłania całej mapy, bo awatar i tak nie wejdzie w interakcję z obiektem znajdującym się poza jego bezpośrednim otoczeniem), zaś klient zajmuje się podstawową "fizyką". Obawiam się, że sam "suchy" html będzie mało atrakcyjny...
Ja u podstaw widziałem to raczej jako osobne oprogramowanie dla klienta (obejmujące całość potrzebnej grafiki, skryptów, itp. itd.), zaś oprogramowanie serwera miało mieć za zadanie wyłącznie przechowywanie stanu gry/symulacji i kontrolowanie parametrów świata (np. obliczanie stężenia dwutlenku węgla wewnątrz stacji badawczej). Byłoby to o niebo bardziej wydajne rozwiązanie - w dużej mierze odciążałoby serwer. Projekt zmierza w nieco innym kierunku - za mało na razie wiem, żeby stwierdzić czy jestem tym zachwycony :)

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

Obawiam się, że sam "suchy" html będzie mało atrakcyjny...

Myślę, że na razie musimy podchodzić skromnie do gry VMB. "Suchy html" na początek wystarczy. Będzie naprawdę dobrze jak zaczniemy widzieć pierwsze strony. W założeniach Projekt VMB nie ma być grą "wodotryskiem", choć może kiedyś będzie, nie jest to bynajmniej naszym obecnym celem.

.. tak naprawdę niezbyt. Na siłę się da ( django działa po stronie serwera, są języki które działają po stronie klienta w przeglądarce, takie jak np JavaScript), ale tak naprawdę to będzie jakaś masakra :) To nigdy nie było do tego projektowane, to jak budowanie budynków za pomocą łyzki i widelca. Teoretycznie się da, ale w sumie to bez sensu, bo to nie do tego narzędzia.
Jeśli już mowa o innych technologiach, to jest trochę ich pomiędzy c++ a django. Jest chociażby flash, który ma w miarę lekką grafikę, szybko się w nim pisze, działa po stronie klienta, ma możliwość łączenia się z serwerem, a dużo roboty w porównaniu do c++ odpada. Obliczenia co do stanów i tak muszą w części zostać na serwerze, ale już wyświetlanie możemy zrzucić na klienta co powinno serwer odciążyć.

slawek

Oczywiście, że Django + JS czy VBS to Frankenstein, poza tym kod do wykonania przez klienta musiałby być do niego wysyłany razem z każdą stroną - drastycznie podnosi to zajętość pasma. Flash z kolei jest lipny pod względem obliczeniowym - moduł Math praktycznie nie istnieje hehe i wszystkie potrzebne funkcje, które w każdym języku programowania są dostępne na dzień dobry, trzeba prototypować. Ale nawet gdyby, to dialog klient-serwer zawsze inicjowany jest przez klienta (nie wiem jak w AS3 - jeszcze nie niuchnąłem), a chodzą mi po głowie rzeczy, które wymagają socketów. Ale spokojnie - usiądziemy, pogadamy, ja się nie upieram :)

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

Teoretyczny model obiektu czy znowu dyskusja na temat języka? Jak już pisałem - starajmy się trzymać tematów, bo będzie bardzo nieczytelnie...

Odpowiadając na posta Bartka: nie po to Pan Bóg dał nam koncepcję ORMa, żebyśmy myśleli w kategoriach tabel bazodanowych. To raz.

Dwa (nawiasem mówiąc): cały temat można poprowadzić w ogóle w oderwaniu od konkretnego języka, trzymając się tylko paradygmatu OOP, bo jak piszesz, model teoretyczny obiektu VMB to:
konstrukcja hipotetyczna odwzorowująca dany rodzaj rzeczywistości w sposób uproszczony, sprowadzający jej cechy do związków najistotniejszych (chociaż zamieniłbym w tej definicji słowo "związków" na "elementów").

Ale oczywiście, znacznie wygodniej (i przede wszystkim -- sensownie) będzie oprzeć się na wybranym przez Ciebie rozwiązaniu (które popieram w pełni, całym sobą) i pisać od razu korzystając z pythonowej składni sięgajc do ORMa dostarczonego nam przez osoby takie jak Holovaty i Kaplan-Moss. Co wiąże się z prośbą:
wrzuć proszę geshi-filter. Będzie wygodnie.

Moje zdanie zatem, po przydlugawym wstępnie:
Rozumiem, że zagadnienie sprowadza się do zdefiniowania podstawowej klasy bazowej dla wszystkich obiektów istniejących w bazie (w bazie VMB a nie bazie danych). Klasa będzie definiowała:

  • parametry stanów wspólne dla wszystkich obiektów (jak n.p. masa, temperatura - co /jak świetnie zwrócił uwagę Mateusz/ pozwoli np. szacować masę całej bazy)
  • metody odpowiedzialne za zmianę tych parametrów w czasie (ewolucja/symulacja)
  • metody odpowiedzialne za implementację ewentualnej interakcji z innymi obiektami
  • metody abstrakcyjne, implementowane w klasach pochodnych, standaryzujące API

Tak?

Co wiąże się z prośbą: wrzuć proszę geshi-filter. Będzie wygodnie.

Rewelacja! Dzięki za info.
Moduł jest już zainstalowany i gotowy do użycia.
Informacje dotyczące formatowania dostępne są na formularzu podczas dodawania nowych treści.
Znajduje się tam także link do informacji o formatowaniu: http://vmb.skyfigure.com/filter/tips

Teoretyczny model obiektu czy znowu dyskusja na temat języka?
Teoretyczny model obiektu ORAZ dyskusja na temat języka. Na dyskusję na temat trafności wyboru języka, na tym etapie projektu nie jest jeszcze za późno :)

Tak?
Tak, oraz klas pochodnych, rozszerzających funkcjonalność klasy bazowej - klasa bazowa ma posiadać minimalny garnitur własności i metod, wspólnych dla wszystkich obiektów w grze/symulacji :)

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