massiv-devel Mailing List for Massively multiplayer game middleware

Ahoj,
dival jsem se na ty tasks na krave a vidim, ze Boovie se na nic neupsal, hm
tak to by mohl promyslet, jak bude vypadat generator object factories, ktery
uz taky celkem nutne bude potreba.

Provedl jsem nejake zasadni zmeny v object model, ktere umoznuji uz se do
toho pustit:
- Object je nyni tez Property, coz znamena to, ze kdyz je potreba property
inicializovat,
   nerozlisuje se mezi typy property, to vyresi sam prekladac, staci zavolat
init().
   Tohle nyni funguje spravne i na MEMBER OBJECT PROPERTIES.
- Az budou hotove nove serializatory, dodaji se jen vhodne metody do
properties

Co teda potrebuje generator znat:
- zakladove tridy daneho typu (jejich nazvy)
- jmena vsech properties, na typu nezalezi

Co generator musi generovat (viz test_objects.cpp):
vymyslet nazev factory, zaregistrovat ji do ClassManager,
naimplementovat create(), clone(), apod. klasicky
naimplementovat for_each_property_do() nasledovne:
    - pro kazdy atribut vygenerovat radku:
        invoke_operation( operation, nazev_atributu );
    - pro kazdou zakladovou tridu ziskat jeji factory (pomoci
ClassManager::get_factory( typeid( BaseClass ) )
      a aplikovat for_each_property_do() rekurzivne
Pokud se generuje factory pro template, vygeneruje se factory jako template
se stejnymi parametry
jako ma ten typ; ostatni bude fungovat samo.

[ promyslet: nektere predem zname operace (jako init()) by bylo vhodne
naimplementovat
  do factory natvrdo; tj. vedle for_each_property_do() udelat v podstate
stejne metodu
  init_properties(), ktera se lisi od te for_xxx() jen v tom, ze misto
  invoke_operation() vola primo predem znamou operaci
(nazev_atributu.operace()),
  coz se obejde bez virtualnich funkci ]

Hm, takze by se do toho mohl nekdo pustit.

-- Markoid

Cau, 

Jelikoz jsou Velikonoce, bude schuzka az +-14 dni (presne
8.4.2002) Je to dostatek casu na to, aby se konecne dodelaly 
(pripadne vubec zacaly!) tyto ukoly, ktere jsou jiz v "todo"
listu docela dlouho:
- Dodelat config variables (Marekus). Myslim, ze by nemel byt 
problem dodelat do 8.4.
- Udelat sitovou vrstvu (Octa) - navrh interfacu, implementace 
reliable posilani paketu pres udp (asi ala Quark), ... 
Do pondelka 8.4. by mohla byt zakladni cast site hotova (~opsani 
z quarka?).
- Vsichni do 8.4. uz by meli umet zkompilovat massiv pomoci
mkgenu a pouzivat cvs (checkout, commit, update). To se tyka
hlavne Hafa, o kterem zatim nemam zpravy jak daleko postoupil
s rozchozovanim cvs a mkgenu.
- Pro reseni problemu nemusite cekat na schuzku, ale klidne 
pouzijte maila.

Dalsi todo:
- (Octa) Kouknout do Cryptolibu, zda uz ma primo v sobe nejake 
kompresni veci (stoupa rikal, ze tam zahlid zlib ci neco podobneho),
neb mozna budeme chctit kompresi a cryptovani soucasne, tak jestli 
to cryptolib nahodou uz nema v sobe.
- (Haf, Marekus) - Popremyslejte nad versovanim souboru.
Co to presne znamena: Klient vyuziva ruzne soubory pri pripojeni
do simulace - vlastni kod (asi *.dll) a data (obrazky, zvuky, ...). 
Pri pripojeni do simulace se musi otestovat, zda ma vsechny 
potrebne soubory a zda je ma aktualni verse. Pokud ne, musi se 
z patchovaciho serveru stahnout aktualni verse souboru.
O tohle se ma starat nejaky versovaci system nad soubory.
Co po nem chceme (to me ted napadlo, neznamena to, ze to musi
byt, ale treba zda to ma vubec cenu apod.):
1/ Nejak si pamatovat verse u souboru (mimo x uvnitr?).
2/ U souboru nejenom versi, ale dalsi attributy (napriklad ze
soubor muze byt i starsi verse, a stahnout se muze az behem hry,
kdyz bude potreba).
3/ Aby prenos mezi klientem a updatovacim server byl minimalni
pri testovani, zda ma klient aktualni verse souboru. Taky vlastni
navrh zpusobu prenaseni dat versi pres sit (nezavisly na os).
4/ Moznost rucniho updatu - tzn. nejenom aby se vsechno stahnulo
pri spusteni klienta, ale aby mel uzivatel moznost nejak si 
stahnout jinak (ftp,...) a naistalovat si to rucne bez nutnosti
pripojit se na sit. Zde jde spis o to, ze kdyz administrator
prida nejakou novou texturu, tak aby se treba vygeneroval 
automaticky nejaky soubor, ktery si muze uzivatel stahnou rucne
treba z ftp. Taky by bylo fajn spojovani vice versi dohromady
("vytvor updatovaci soubor pro verse 3.3 az aktualni").
5/ Aby nebylo prilis mnoho souboru (velka zatez na filesystem).
Treba groupovani souboru, ktere se dlouho nezmenily do 
jednoho fyzickeho souboru?
6/ A dalsi veci si clovek muze vymyslet.

- (Haf, Marekus) - Popremyslet, ktere oblasti byste chteli delat
v massivu (sit, zalohovani, graficky engine, reprezentace mapy, 
servery (login, updatovaci/patchovaci, archivacni,...), clientske 
kody (zpracovani inputu,...), versovani souboru, vlastni ukazova 
hra, ...).

- S Markoiodem a Stoupou (a s sebou :-) jsem mluvil, takze to tady 
nebudu opisovat znova (Stoupa - "targety" mkgenu, 
serializatory; Markoid - dodelat strasne efektivni implementaci 
grafu pointeru (pokud to teda uz neni)).

Jinak sna kravi web sem narychlo splacal nejake ukoly (tasks),
kde chci postupne vytvorit presnejsi plan toho co se ma delat, 
nez jen aktualni "od schuzky ke schuzce", zatim to tam je jen 
tak pro informaci.


Layout:
- Navrhuju aby se deklarace, ze metoda je virtualni, psala u vsech 
trid zdedenych od nejakeho predka A, ktery ji ma jako prvni virtual,
i kdyz to C++ explicitne nevyzaduje.


Poznamky ohledne objektu (asi jen pro Markoida :)

Nejak jsem presvedcil Stepana, ze to je ok delat tu frontu udalosti
v shadow kopii tak jak ji delam. Este to trosku predelam, ale
co se tyce pouzivani, tak je to takhle:
Ten kdo zada freeznuty stav objektu, dostane freeznuty stav
ale bez fronty udalosti (lepe receno nema pravo delat neco 
souvisejici s udalostmi). Freeznutou frontu udalosti si vyzada jinou 
funkci, ktera vrati pouze seznam id udalosti, coz je veskera 
informace, kterou kdokoli potrebuje vedet o stavu udalosti (samotne 
udalosti jsou jine freeznute objekty, na ktere si muze hamtat pres 
jejich id, pokud chce).

Uff, pro dnesek by to stacilo,

Petr

Cau, 
Zitra se kona schuzka jako obvykle v 17.20.
Petr

Abych to shrnul,
Object muze byt but v aktivnim ci latentnim stavu.
Aktivni znamena, ze je je zaregistrovan u manageru a navic
je i normalne simulovan (je naplanovan u manageru).
Latentni znamena, ze je pouze zaregistrovan u manageru, ale neni
planovan (i kdyz obsahuje nejake udalosti).
Pokud se ma zaregistrovat aktivni objekt, jednak se zaregistruje
Manager::register_object() a pak se musi explicitne
aktivovat Manager::activate_object().

Pri duplikaci objektu (te normalni), se objekt registruje ativni,
pri freeze duplikaci se shadow kopie dela latentni, aby se nesimulovaly jeji
udalosti.
Dalsi latentni objekty jsou napriklad repliky (jelikoz nemame predikci).

Pri freeze duplikaci se dela kopie i cele fronty udalosti.
Pri normalni duplikaci se novy objekt udela s prazdnou frontou.
Je na tom, kdo vola duplikaci, aby naplanoval pro duplikovany objekt
udalosti, pokud chce.

Fronta udalosti nejakeho objektu bude nejaka heap, ktera bude obsahovat
cas + ObjectPointer na objekt udalosti. To ze je to ObjectPointer
zaruci spravne grupovani objektu, aby se prenasely objekty ve fronte
spolu s hlavnim objektem.
Pri vyvolani udalosti z fronty se jednak otestuje, zda objekt udalosti vubec
jeste existuje, pokud ano tak se nejak "spusti" (vyvolani metody na
na cilovem objektu "dosla ti zprava" versus vyvolani metody na objektu
udalosti "byl jsi dorucen").

Otazkou je, jak udelat killovani udalosti z fronty. Tzn. objekt
si naplanuje nejakou udalost, a po case ji chce zrusit driv nez
se vyvola. Tento "pointer" do fronty udalosti musi mit vlastnosti property.
Otazkou je jak vlastne ukazovat na udalosti do fronty, aby se tohle dalo
prenaset (a po prenosu to ukazovalo tam kam ma). Pokud se zaruci, ze se
heap prenese a na druhe strane se identicky zrekonstruje, stacil by asi
jen opravdu index.

Petr

Cau,

zamyslel jsem se nad tim, co by mel umet IDL parser.
V zasade jsou dve moznosti:

1) v IDL bude nejak jednoduse popsana kazda trida vsectne presnych typu
vsech atributu + informace
    o kvantovani, presnostech,...;
    nekde v generatoru bude tabulka popisujici serializace: [typ] ->
[serializer]

    vygenerovani factory pro dany typ znamena rozvinout definici typu /
tridy podle zadanych (template) parametru.
    to obnasi nutnost rozumet template parametrum a stanovit si omezeni, co
se za parametry smi pouzivat;
    prakticky asi tezko libovolne C++ template parametry (napr. A<
&tabulka[20] >).

2) v IDL se jen popisou nazvy properties a base classes, ostatni se prenese
na prekladac C++;
    informace o replikacich by byly napsany primo do daneho typu;
    melo by fungovat vsechno, libovolne dedicnosti, template parametry;

    funkce pro serializaci serializovatelnych typu:
        serialize( Int32<parametry> & i );
        serialize( ... );

    ^^ v C++ pro kazdy serializovatelny typ overloadnuta funkce.

    funkce pro serializaci property:

        serialize( PPointer<parametry> & p );
        serialize( PVector<T> & v ) // T je serializable typ a pro jeho
serializaci se pouzije nektera z predchozich funkci
        {
        "for each item" serialize( v[i] );
        }

    vyhodou zde je to, ze je srozumitelne receno, jakym zpusobem se popisuji
replikacni parametry
    (-> jako template parametry serializable typu); to, ze generator
factories vubec nemusi rozumet typum
    a instanciovat ty tridy, staci mu nazvy properties; funguji vsechny
mozne template parametry,
    a je srozumitelne receno, jak jsou pojmenovany class factories.

    priklad:

    // nejaky objekt, ktery chceme spravovat

    template <class T>
    class O
        {
        T property;
        };

    // popis v IDL:
    template <class T>    // okopirovano z C++
    O = property;

    // vygenerovana factory:
    template <class T> // okopirovano z IDL
    class OFactory
        {
        static O * create()
            {
            return new O();
            }

        static void serialize()
            {
            serialize( property );
            // ^^ tady prekladac sam rozpozna typ property a pouzije
spravnou serializaci,
            //      nemusi to zjistovat generator
            }
        }

konstrukce objektu: OFactory<PInteger>::create(

poznamka na zaver:
    ve skutecnosti by od kazde funkce serialize bylo nekolik verzi
serialize,
    ktere bud provedou serializaci na sit, do souboru, nebo jinak.

Osobne jsem pro 2), zejmena proto, ze to neprinasi, zadne omezeni na to, co
si muze programator
ve scriptu napsat, jednoduse se prida novy typ property aniz by se muselo
delat neco s generatorem, ...

-- Markoid