[Java RMI]realtime spelletje

[py.mosjuh]

ik moet voor een opdracht op school een spelletje maken (no problems hier).. echter moet het een distributed applicatie worden die als eis gebruik moet maken van Java RMI. ook leuk enzo maar het is niet een simpele turn based applicatie.. wij willen een soort van deathmatch pacman maken en daarvoor zou ik het liefst gewoon een socket gebruiken...

ons idee... zorgen dat een speler zich aanmeldt bij een spel, er is hiervoor geen server; elke speler weer de rest van de spelers te vinden.. het is de bedoeling dat er elke interval van x msec (bijv 10 of 100) een aantal positie gegevens wordt gestuurd van speler A naar alle spelers die hij kent (die spelers passen de positie, snelheid, kijkrichting) van A dan aan in hun GUI..

als ik (als newbee RMI ventje) probeer een speler obj over te sturen (met naam, kleur etc) krijg ik geen problemen.. die speler heeft dan een variable posData wat een eigen gemaakte class is. die is netjes serializable zodat die ook over gestuurd kan worden.. ik wil dus die posData elke x msec hebben van speler A (ik ben dan ff speler B ofzo).. speler A verandert zijn posData de ganse tijd maar speler B (ik dus) kan slechts de 1e waarde van dat kreng zien (kreng = speler A)..

heeft iemand enig idee hoe ik beste deze opzet kan uitproggen of heeft iemand een betere opzet etc.. plz help me!

[Alarmnummer]

Tip: probeer een beetje het RMI gebeuren te vergeten. Stel interfaces op tussen de players en de game. Maak hiervan implementaties (die dus allemaal op verschillende threads draaien). Daarna kan je mbv het proxy design pattern RMI erin plaatsen. Hierdoor heeft je ontwerp verder niets te maken met de gebruikte middleware.

[py.mosjuh]

Alarmnummer schreef op 02 december 2002 @ 15:55:
Tip: probeer een beetje het RMI gebeuren te vergeten. Stel interfaces op tussen de players en de game. Maak hiervan implementaties (die dus allemaal op verschillende threads draaien). Daarna kan je mbv het proxy design pattern RMI erin plaatsen. Hierdoor heeft je ontwerp verder niets te maken met de gebruikte middleware.

het is ook de bedoeling om rmi dusdanig te implementeren zodat we het makkelijk (desnoods) kunnen vervangen... echter snap ik momenteel de ballen van RMI dus ik zou graag antwoord willen op:

hoe krijg ik de communicatie tussen 2 spelers dusdanig zodat ze van elkaar elke gewenste keer de methoden kunnen aanroepen en de nieuwste data terug krijgen die op dat moment op de server geldt

(dank voor snelle reactie trouwens )

[Alarmnummer]

py.mosjuh schreef op 02 december 2002 @ 16:05:
[...]

het is ook de bedoeling om rmi dusdanig te implementeren zodat we het makkelijk (desnoods) kunnen vervangen...

Dan moet je echt kijken naar het Proxy design pattern. Die is hier echt ideaal voor.

echter snap ik momenteel de ballen van RMI dus ik zou graag antwoord willen op:

In principe hetzelfde als je bij normale objecten ook doet, alleen kan je bij iedere methode dus een RemoteException voor de kiezen krijgen. Afgezien daarvan is het niet verschillend.

hoe krijg ik de communicatie tussen 2 spelers dusdanig zodat ze van elkaar elke gewenste keer de methoden kunnen aanroepen en de nieuwste data terug krijgen die op dat moment op de server geldt

Hoe zou je het doen zonder RMI? Als je dat hebt uitgevonden, dan kan je RMI er zo inzetten mbv het Proxy design pattern (trust me). En verder zijn de keywords: MVC en observer/observable

[ Voor 5% gewijzigd door Alarmnummer op 02-12-2002 16:12 ]

[py.mosjuh]

Alarmnummer schreef op 02 december 2002 @ 16:11:
[...]

Dan moet je echt kijken naar het Proxy design pattern. Die is hier echt ideaal voor.


[...]

In principe hetzelfde als je bij normale objecten ook doet, alleen kan je bij iedere methode dus een RemoteException voor de kiezen krijgen. Afgezien daarvan is het niet verschillend.


[...]

Hoe zou je het doen zonder RMI? Als je dat hebt uitgevonden, dan kan je RMI er zo inzetten mbv het Proxy design pattern (trust me). En verder zijn de keywords: MVC en observer/observable

thx m8.. ik zal er eens mee gaan stoeien.. best klote dat dat allemaal als voorkennis wordt beschouwd terwijl ik die hele voorkennis module nooit heb gezien..

[Tuinhark]

Trouwens, persoonlijk zou ik er voor kiezen een centrale server te gebruiken die alles regelt. Op die manier houd je alles functioneel ook een beetje gescheiden.

Zo heb ik dat met een project-opdracht ook eens uitgevoerd op school (maar dan turn-based ).

Moet trouwens verder even opmerken dat ik _ERG_ slecht ben in het ontwerpen van games (geen aanleg enzo ), dus het kan maar zo blijken dat deze aanpak totaal niet geschikt is voor wat je wilt. Het is nogal een andere aanpak dan wat jij voorstelt heb ik het idee, dus kijk eerst maar even verder dan deze opmerking.

[morpheus]

Tuinhark schreef op 02 december 2002 @ 20:15:
Trouwens, persoonlijk zou ik er voor kiezen een centrale server te gebruiken die alles regelt. Op die manier houd je alles functioneel ook een beetje gescheiden.

Ik denk dat die persoon bij mij op school zit... aangezien ik dezelfde opdracht doe

Eis was dat er GEEN server aanwezig was.
Meerdere RMI-spellen op 1 pc konden spelen.
Spelers elkaar konden zoeken in een subnet.

Maar dat doet verder niet af aan zijn probleem

* morpheus die ook RMI aan het doorspitten is

[ Voor 4% gewijzigd door morpheus op 03-12-2002 11:30 ]

[morpheus]

[editten - niet quoten]

[ Voor 92% gewijzigd door morpheus op 03-12-2002 11:30 ]

[Glimi]

morpheus schreef op 03 December 2002 @ 11:29:
Eis was dat er GEEN server aanwezig was.
Meerdere RMI-spellen op 1 pc konden spelen.
Spelers elkaar konden zoeken in een subnet.

Geen server, als in server PC?
Want je hebt slechts twee opties dan:
• 1 client stiekem een server laten draaien, de clients sturen daar hun verzoeken heen, controle vindt daar plaats ed ed.
• Geen van de clients draait een server, maar sturen messages naar elkaar. Controle van moves ed bevindt zich dan op de client, wat cheaten wel makkelijk maakt

Speel je zonder server, dan zie ik het voordeel van RMI niet echt in. Ik zou dan eens kijken naar P2P aangezien iedereen toch gelijk is dan in het netwerk.
Voor java P2P: www.jxta.org

[morpheus]

Glimi schreef op 03 december 2002 @ 11:44:

[...]

Geen server, als in server PC?
Want je hebt slechts twee opties dan:
• 1 client stiekem een server laten draaien, de clients sturen daar hun verzoeken heen, controle vindt daar plaats ed ed.
• Geen van de clients draait een server, maar sturen messages naar elkaar. Controle van moves ed bevindt zich dan op de client, wat cheaten wel makkelijk maakt

Speel je zonder server, dan zie ik het voordeel van RMI niet echt in. Ik zou dan eens kijken naar P2P aangezien iedereen toch gelijk is dan in het netwerk.
Voor java P2P: www.jxta.org

Tja... dat heb je he, met opdrachten van school. Soms heb je dan strakke richtlijnen hoe iets gemaakt moet worden.

Het gaat er dus om dat de spellen tegelijk client en server zijn. Ze sturen elkaar de veranderde eigen posities op. Cheaten is niet aan de orde, het gaat om het leereffect

Enige waarvoor je in eerste instantie een server zou willen, is dat je elkaar moet opzoeken. Met 1 server in een subnet is dat makkelijker als ieder spel zelf het hele subnet laten afzoeken

[py.mosjuh]

het is dus inderdaad de bedoeling dat er een spel wordt gemaakt zonder een centrale server welke alle spelservers registreerd (je moet dus gaan scannen op servers) vervolgens mag je wel een server draaien voor 1 spel maar als die server er in ons geval mee kapt willen wij dat de rest van de spelers wel kunnen door spelen.. vandaar dat we ervoor gaan om alle spelers elkaar te laten kennen..

kheb het nu zover dat 2 spelers gegevens met elkaar uitwisselen.. niet op een nette manier maar het werkt..

kan iemand mij nog iets van die rmiregistry uitleggen? hoe dat werkt etc?

[Tuinhark]

Begin nou eerst dan maar met een simpel voorbeeldje waarin WEL duidelijk een client en server zijn te onderscheiden. Daar zijn er zat van te vinden. Als dat eenmaal duidelijk is ga je verder kijken.

Je zegt dat je alle hosts alle andere hosts wilt laten 'kennen'. Nou, dan zul je volgens mij een client-server (CS) connectie moeten onderhouden naar alle andere hosts. Wordt lekker ingewikkeld en uitgebreid. Voor zover ik weet kun je niet broadcasten met RMI, dus je zult bv in het geval van 4 hosts, alle hosts 3 connecties moeten laten onderhouden. Daarbij moet je ook gaan opletten dat host A niet een connectie met host B gaat opzetten als host B al een connectie naar A had gemaakt.

Hoeveel tijd heb je voor deze opdracht staan btw?

[py.mosjuh]

Tuinhark schreef op 07 December 2002 @ 13:56:
Begin nou eerst dan maar met een simpel voorbeeldje waarin WEL duidelijk een client en server zijn te onderscheiden. Daar zijn er zat van te vinden. Als dat eenmaal duidelijk is ga je verder kijken.

Je zegt dat je alle hosts alle andere hosts wilt laten 'kennen'. Nou, dan zul je volgens mij een client-server (CS) connectie moeten onderhouden naar alle andere hosts. Wordt lekker ingewikkeld en uitgebreid. Voor zover ik weet kun je niet broadcasten met RMI, dus je zult bv in het geval van 4 hosts, alle hosts 3 connecties moeten laten onderhouden. Daarbij moet je ook gaan opletten dat host A niet een connectie met host B gaat opzetten als host B al een connectie naar A had gemaakt.

Hoeveel tijd heb je voor deze opdracht staan btw?

ik heb een simpel voorbeeld waarin het wel werkt zelf gemaakt maar zodra ik het uitbreid gaat ie moeilijk doen.. en dan vooral met de registry enzo (maar daar kom ik zo op)

thx voor de info.. er staan nu nog 6 weken voor (incl deze week) dus heb nog wel ff maar ik wil een erg leuk ding maken dus ik ben er nog wel erg druk mee..

kheb het nu zover dat ik speler A kan starten, B kan A vinden op een vast gegeven registry (heb de naam van speler A gebonden in de registry met:

code:

Naming.rebind(sNickname, oSelf);

)
B kan disconnecten en reconnecten alleen als ik A afsluit (B gaat lekker door) kan A op zijn beurt B niet meer vinden bij een restart van A.. beetje vaag allemaal.. komt bij dat ik netjes alles toesta met een policy file:

code:

grant { permission java.security.AllPermission;  };

maar zodra ik probeer om een andere port te binden dan de standaard 1099:

code:

Thread registry = new Thread() {
    public void run() {
        try{
            LocateRegistry.createRegistry(1099);
        }catch(Exception e){
            System.out.println(e);
        }
    }
};
registry.start();

krijg ik een "mooie" connection refused error..

code:

java.rmi.ConnectException: Connection refused to host: 192.168.0.4; nested exception is:
java.net.ConnectException: Connection refused: connect

als ik dan probeer om niet middels een Thread de registry te starten maar via rmiregistry in een aparte console werkt het geheel al helemaal niet meer.. anyone?

[ Voor 5% gewijzigd door py.mosjuh op 09-12-2002 14:32 ]