Vezérlés + gui + hálózat

Vezérlés + gui + hálózat
2009-04-11T14:17:12+02:00
2009-05-10T15:44:23+02:00
2022-11-13T14:00:35+01:00
barii86
Sziasztok!

egészen konkrétan egy hálózaton játszható társasjátékot írok, ahol a szerver nem dedikált, hanem játékos
na már most, az a kérdésem, hogy hogyan kéne azt megoldani, hogy normálisan, objektum-orientált módon menjenek a dolgok?
szóval valahogy úgy gondoltam, hogy a vezérlés objektumben megmondom a játékosnak, hogy ő jön, akkor ha ő lokális játékos, akkor a gui-n a gomb kattintható lesz, ha hálózatos, akkor elküldöm neki, hogy ő jön, aztán majd ő megoldja
ehhez a vezérlésből példányosítom a GUI-t, a hálózatot, meg a játékos objektumokat

na most jön a kérdés: hogyan kéne ezt megoldani rendesen?
most úgy van, hogy mindennek átadok mindent konstruktorban, a hálózatos játékosnak a hálózatot, a lokálisnak a gui-t, aztán ha a helyi játékos a gombra nyom, akkor a gui action-je a vezérlésben hív meg egy metódust, meg a hálózatos játékos is
de ettől konkrétan elhányom magam. szóval azért azt biztos meg lehet oldani normálisan is.
hogyan lehet ezt java-ban emberi módon megírni?

köszönet előre is
barii

UI:
még annyit az egészhez, hogy mivel több hálózatos játékos lehet, mindegyik egy külön szál. és a hálózatos objektumben van egy while(true) ciklus, az figyeli, hogy jött-e be valami, mert a játékban alul van egy chat rész is, oda meg ugye bármikor jöhet üzenet
Mutasd a teljes hozzászólást!
Először is, mint fentebb említették, moduláris felépítés és absztrakciós rétegek a két fontos alapfogalom egy komplex rendszer felépítésénél. Ezen a ponton a google a barátod, a hely kicsi, és a meglévő közeg sem tökéletes bővebb kifejtéshez.

Ajánlanám a következő design patternek alapos átnézését és megértését, mielőtt komolyabb szinten beleszaladnál a dologba, sok időt spórolhatsz meg:

Proactor Pattern
Active Object Pattern
Observer Pattern
Proxy Pattern
Facade
Chain of Responsibiltity

Felépítésére Én is a sugaras server-client designt ajánlanám. (kulön szerver, külön kliensalkalmazás, a kliensek a szerveren keresztül kommunikálnak egymással)

Az OO design alapja egy jó hierarchia, ahol átlátható, melyik rétegek vannak egy szinten, és melyik rétegek épülnek egymásra. Egy ilyen alkalmazás kifejlesztése a gomboz a kabát kategória is lehet, ugyanis az aszinkron hálózati kommunikáció, a szakadásvédelem, kliensazonosítás, UpNP ügyeskedés és miegymás idővel úgy ki tudja nőni magát - nem méretben, fejlesztési és tesztelési időben -, hogy tulajdonképpen maga a játék eltörpül mellette. Készülj föl lelkiekben, hogy egy kliens-szerver kommunikációs réteget a legundorítóbb tesztelni és debuggolni - na jó, ez nem teljesen igaz, de benne van a top 10ben nálam -, viszont ha egyszer jól megírod, akkor azt pár évig simán alá tudod tolni bárminek. Szóval szvsz először kezd a chat megvalósításával, külön, de a generikus kommunikációs rétegre alapozva, azzal könnyen tudod majd tesztelni az alapokat.

A fejlesztéshez sok sikert
Mutasd a teljes hozzászólást!

  • Szia,

    Mit szólnál ahhoz, hogy kicsit átszervezed, csináld meg cliens-server architektúrába, nem kell dedikált szerverként futtatnod, a játékkal egy időben indítod a server-t is vagy amikor azt mondja a játékos, hogy ő szeretne a host lenni, majd localhost-ra csatlakozol... (De később az se lesz gond, ha dedikált szerver-t szeretnél)

    Meg csinálod a kommunikácios felületet mind a cliens és servernek, ami lehetne esemény vezérelt. Client ezen a felületen érintkezik a szerverrel, lehetne egy esemény, hogy én jövök, meg egy timeout amiket a server fog kiváltani....
    Szóval cliensnek nem kell tudnia, hogy ő a server ugyanúgy viselkedik mint máskor, a játékmenetet meg a server vezérli. A kommunikációs megvalósítást zárd egységbe, kliensek nem kell tudnia, hogy most épp TCP-n vagy egyéb máson keresztül történik a kommunikáció, akkor csináltad meg jól, ha tudod, hogy ezt a package-t kiszedve onnan újra tudnád használni (persze attól még tartozhat hozzá több objektum is...), tiszta-letisztult és egyértelmű legyen. GUI-ban meg példányosítod feliratkozol az eseményekre....

    egyelőre ennyi, ilyesmi segítségre gondolsz?
    robb83

    Mutasd a teljes hozzászólást!
  • Először is, mint fentebb említették, moduláris felépítés és absztrakciós rétegek a két fontos alapfogalom egy komplex rendszer felépítésénél. Ezen a ponton a google a barátod, a hely kicsi, és a meglévő közeg sem tökéletes bővebb kifejtéshez.

    Ajánlanám a következő design patternek alapos átnézését és megértését, mielőtt komolyabb szinten beleszaladnál a dologba, sok időt spórolhatsz meg:

    Proactor Pattern
    Active Object Pattern
    Observer Pattern
    Proxy Pattern
    Facade
    Chain of Responsibiltity

    Felépítésére Én is a sugaras server-client designt ajánlanám. (kulön szerver, külön kliensalkalmazás, a kliensek a szerveren keresztül kommunikálnak egymással)

    Az OO design alapja egy jó hierarchia, ahol átlátható, melyik rétegek vannak egy szinten, és melyik rétegek épülnek egymásra. Egy ilyen alkalmazás kifejlesztése a gomboz a kabát kategória is lehet, ugyanis az aszinkron hálózati kommunikáció, a szakadásvédelem, kliensazonosítás, UpNP ügyeskedés és miegymás idővel úgy ki tudja nőni magát - nem méretben, fejlesztési és tesztelési időben -, hogy tulajdonképpen maga a játék eltörpül mellette. Készülj föl lelkiekben, hogy egy kliens-szerver kommunikációs réteget a legundorítóbb tesztelni és debuggolni - na jó, ez nem teljesen igaz, de benne van a top 10ben nálam -, viszont ha egyszer jól megírod, akkor azt pár évig simán alá tudod tolni bárminek. Szóval szvsz először kezd a chat megvalósításával, külön, de a generikus kommunikációs rétegre alapozva, azzal könnyen tudod majd tesztelni az alapokat.

    A fejlesztéshez sok sikert
    Mutasd a teljes hozzászólást!
  • kb ilyesmire gondoltam, csak itt a kérdés az volt, hogy meg lehet-e ugy oldani, hogy egy objektum ne hívja a szülő metódusait. Mostanra találtam hozzá ezt-azt, change listenert a gombnyomáshoz, még majd a hálózatos részhez is meg kell ezt valósítani

    client-szerver volt eddig is

    ha minden igaz, akkor a nem-kell-tudnija rész is teljesül, van a szerver meg a szerver kommonikációja rész, és a kommonikásióban kicserélhetném a dolgokat...

    köszi
    Mutasd a teljes hozzászólást!
  • a patterneket majd átnézem

    kulön szerver, külön kliensalkalmazás van. konkrétan egy menüből fog eldőlni, hogy melyik indul

    a chat megvan. tényleg nem jó debugolni
    úfy csinálom, hogy pl a szerver a játék, a ckiens a chat, és a chat-tel begépelem a parancsokat, amiket tesztelni akarok
    Mutasd a teljes hozzászólást!
  • A gyermek ne hívogassa a szülő metódusait? Eventek és eventhandlerek.(observer pattern)
    Mutasd a teljes hozzászólást!
  • hát igen, közvetlenül ne hivja, hogy szulo.metodus(), hanem igy event-ekkel akartam, igen
    Mutasd a teljes hozzászólást!
  • Miert nem hasznalsz elore megirt frameworkokat?:)

    Lehet, hogy idiota otlet, de szerintem ami meg van azt megegyszer nem kell kitalalni ;)
    Mutasd a teljes hozzászólást!
  • pl mit?
    Mutasd a teljes hozzászólást!
  • The Apache Software Foundation

    Indulásként ezen az oldalon sok hasznos projekt van amit szabadon felhasználhatsz. Köztük van hálózati keretrendszer is ami nagyon ígéretes szerintem, sok projektben felhasználták már nagy sikerrel. Keresni kell
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd