[C#/*] Ontwerp gamespy-like programma.

[Verwijderd]

Op het moment ben ik bezig met een programma dat informatie van gameservers moet kunnen halen (naam van de server, map, aantal spelers, spelers die er spelen, etc).

Iedere soort gameserver waar je informatie vandaan wil halen, moet je op een andere manier benaderen: als je informatie van een quake3 server wil krijgen, moet wat anders sturen als je bij een Half-Life server zou moeten. Ook de response die je krijgt van een server hangt af van het spel dat de server host.
Nu heb ik dit tijdelijk opgelost door gewoon 1 class te maken die je kunt gebruiken om informatie van een server te kunnen halen. De class gebruikt vervolgens 2 andere classes om de regels van de server en de spelers op de server te kunnen opslaan. De basis class die alle informatie van de server haalt, heeft bepaalde methods. Zo gebruik ik 1 methode om alle basis informatie van een server te halen, 1 methode voor de regels en 1 voor de spelers (bij Half-Life moet je 3x een packetje sturen naar de server: voor de basis info, spelers en regels).

Wat ik naar de server moet sturen en wat ik met de respons van de server moet gaan doen hangt dus van het speltype af en ik gebruik op dit moment een if-else statement om te kijken welk spel je informatie vandaan wil halen. Dit kan misschien best als je maar 3 speltypes ondersteunt, maar als je dit wil uitbreiden, naar bijvoorbeeld 10 speltypes, dan zit het niet zo overzichterlijk in elkaar.

Zelf dacht ik aan een plugin voor ieder speltype. Voordeel: Iedereen zou eigelijk een spel zelf kunnen toevoegen zonder dat ze afhankelijk van mij zijn. Nadeel: Je krijgt X dll's voor X speltypes dat je support.

Hoe zouden jullie dit ontwerpen, zodat je in de toekomst op een nette/slimme manier nieuwe spellen zou kunnen toevoegen om te ondersteunen?

[Verwijderd]

Kijk hoe ze het in Qstat gedaan hebben?

[whoami]

Hmmz...
1 class maken waar je dan voor ieder spel een andere class van inherited.

[Alarmnummer]

Zoals Whoami zegt zou je dit kunnen oplossen mbv polymorphisme en aangezien ze allemaal aan een bepaalde 'interface' moeten voldoen, zie ik niet in waarom het ontwerp daardoor zou vertroebelen.

En verder zou je ervoor kunnen kiezen om centraal op een server alle spel classes te plaatsen, en op het moment dat daar behoefte aan is, kan dit opgehaald worden en gebruikt worden. Hierdoor kan je net zoveel spellen ondersteunen als nodig is.

[Verwijderd]

Ik zou een soort van configuratie-taal bedenken, waarin je in een plain-text formaat de manier waarop je die servers moet aanspreken kan instellen. Dat zou als voordeel hebben dat je een 'plugin' kan maken, zonder dat je een compiler hoeft te hebben (en moet kunnen programmeren).

Het moeilijke is wel dat je taal de mogelijkheden van de huidige en nieuwe spelletjes moet ondersteunen, en dus heel generiek moet zijn.

[Qwerty-273]

Inderdaad.. een centraal punt waar je 'updates' van speltypes kan neer zetten.

Dus 1 dat bestand (of dll) met al jouw goed gekeurde spellen er in, en dan daarnaast dus de mogelijkheid om eigen spellen toe te voegen door middel van plugins. En bij opstart dat het programma (aanvinkbare optie) checkt of er een neieuwe versie beschikbaar is.

Al kom je dan wel op een gegeven moment misschien tegen het probleem van dat het dat bestand dan te groot wordt.

[Qwerty-273]

Trouwens wat ik me net loop te bedenken. dit is natuurlijk allemaal IP gebaseerd. Wat nou als je een LAN hebt met alleen IPX/SPX ? misschien is daar ook een ondersteuning van belang al is een LAN wel weer beperkt met gameservers maar toch misschien een idee met weinig moeite.

[Verwijderd]

RIKZ schreef op 05 september 2002 @ 13:47:
Trouwens wat ik me net loop te bedenken. dit is natuurlijk allemaal IP gebaseerd. Wat nou als je een LAN hebt met alleen IPX/SPX ? misschien is daar ook een ondersteuning van belang al is een LAN wel weer beperkt met gameservers maar toch misschien een idee met weinig moeite.

Het gaat op dit moment eigelijk alleen om internet based spellen

[Alarmnummer]

RIKZ schreef op 05 september 2002 @ 13:45:
Inderdaad.. een centraal punt waar je 'updates' van speltypes kan neer zetten.

Dus 1 dat bestand (of dll) met al jouw goed gekeurde spellen er in, en dan daarnaast dus de mogelijkheid om eigen spellen toe te voegen door middel van plugins. En bij opstart dat het programma (aanvinkbare optie) checkt of er een neieuwe versie beschikbaar is.

Al kom je dan wel op een gegeven moment misschien tegen het probleem van dat het dat bestand dan te groot wordt.

Waarom zou je alles moeten downen? Je check eerst of op de pc een versie voor een spel aanwezig is. Als dit zo is dan kijk je of op de server een nieuwere staat, dan ga je alleen de files die nodig zijn (dus alleen een paar classes) ophalen van de server. Als er geen plugin nodig is dan haal je ook alleen de nodige classes op.

Het is niet nodig om een hele brok op te halen. En verder kan je toch ook in c# classes ter plekke inladen? (Kan met java wel).

[Verwijderd]

Op dit moment heb ik polymorphism toegepast, en het werkt zoals het werken moet. Op dit moment zou ik bvb kunnen doen:

C#:

ServerInfo x = new Q3(..);

Nu vroeg ik me af of het mogelijk is om deze instantie dynamisch te creeën: in het voorbeeld hierboven gebruik ik Q3, maar in mijn eigen app. hangt dit speltype af van een enum waarde.

Ik zou dit kunnen oplossen doormiddel van een switch statement, maar is het niet mogelijk om dit ook op een andere, betere manier op te lossen?

[whoami]

Waarom zou het niet goed zijn om dat via een switch op te lossen?

code:

Game g;

switch ( SpelType)
{
  case Quake    : g = new QuakeGame();
                    break;
  case HalfLife :  g = new HalfLife();
                    break;
         
...
}

Edit: WTF is er mis met die uitlijning binnen code-tags?

[Alarmnummer]

Volgens mij gaat er in je ontwerp echt nog iets fout omdat je geen switches nodig zou moeten hebben (daarom heb je polymorfisme)

code:

interface Game{
    void doYourThingies();
}

class Quake implements Game{
    void doYourThingies(){//check frag level;}
}

class StripPoker implements Game{
    void doYourThingies(){//check agel;}
}

class Casino implements Game{
    void doYourThingies(){//infect system with spyware;}
}

En je kan gewoon een 'game' downloaden. Je maakt dan van die class een instantie. En daarop roep je dan aan: doYourThingies() en het doet dan wat het moet doen.

[whoami]

Alarmnummer: hij moet toch op een bepaald moment een object aanmaken? Om te weten van welk type dat object moet zijn kun je toch een switch gebruiken?

[Alarmnummer]

Ik heb intussen denk ik wel in de gaten wat er misgaat

Jouw client gaat naar de server en wil graag voor een bepaalde spel een 'game' class hebben. De server stuurt deze class terug (kan dus een Quake,StripPoker, Casino of iets anders zijn). De client die krijgt deze class binnen. Van deze class moet een instantie gemaakt worden en daarna kan je gewoon op die instantie doYourThingies aanroepen.

[edit]
voor de duidelijkheid heb ik object vervangen door class

[TheOneLLama]

Ik zou per spel dynamisch een paar classes dynamisch laden,

denk hierbij aan
- een server-provider (die een lijst met alle beschikbare servers voor dat spel kan ophalen)
- een server-query (die info over 1 server van dat spel kan opvragen, of info daarover bevat)
- eventueel een server queryer queryer (die een server-query kan uitvoeren)
- een gamelauncher (die het spel opstart)

Dit in combinatie met interfaces voor:
de serverprovider, serverqueryer, gamelauncher (natuurlijk)
een server
het "programma zelf" (evt. meerdere interfaces)

kom je al een eind. Ik kan je overigens gelijk aanraden om het "queryen" van games non-blocking te maken (meest effectief is ook non-blocking IO gebruiken denk ik, maar dat lijkt me vooral een keuze voor de plugin ontwikkelaar. Vandaar de server queryer queryer, dan kan deze zelf kiezen. Je kan natuurlijk wel de plugin developers op weg helpen, door een (aantal) abstract plugin classes mee te leveren of via de interface van je porgramma hulpmiddelen aan te bieden).

Non blocking dat betekend dus dat het aanroepen van de function om een server te queryen zelf geen waarde terug geeft maar dat als een query klaar is er een function wordt aangeroepen op een object wat je meegeeft in je eigen aanroep.

[Verwijderd]

Hmm misschien moet ik het ietsje uitgebreider uitleggen:
* Ik heb een programma dat van meerdere servers (dat een speltype draait dat mijn prog support) informatie kan halen.

* Mijn progje heeft tabbladen voor ieder spel dat ik support. In een xml file staan bepaalde gegevens van de games, waar je de meeste waardes van mag veranderen, en bepaalde niet (zoals de naam van het spel, want anders kan ik dit niet converten naar mijn enum van speltypes).

Per tabblad moet ik dus ook een instantie creeën, zodat je servers kunt queryen. Dit alles werkt perfect, alleen is nu het probleem dat ik niet precies weet hoe ik een instantie dynamisch kan creeën per tabblad, voor het spel.

Per tabblad zou ik, zoals whoami al aangaf, een switch statement kunnen gebruiken, of ik zou een statische methode kunnen aanmaken in de basis class, zodat ik zou kunnen doen:

C#:

ServerInfo x = ServerInfo.CreateFromEnum(myGameType);

[Verwijderd]

TheOneLLama schreef op 05 september 2002 @ 15:39:
Non blocking dat betekend dus dat het aanroepen van de function om een server te queryen zelf geen waarde terug geeft maar dat als een query klaar is er een function wordt aangeroepen op een object wat je meegeeft in je eigen aanroep.

Ik maak gebruik van delegates en voor iedere server die ik refresh, maak ik een thread aan, zodat het programma "niet hangt voor een tijdje".

[Alarmnummer]

Zo gauw je met een switch statement gaat werken zit je vast aan een beperkt aantal spellen. Je kan alles perfect oplossen mbv polymorphisme.

[Verwijderd]

Alarmnummer schreef op 05 september 2002 @ 15:35:
Volgens mij gaat er in je ontwerp echt nog iets fout omdat je geen switches nodig zou moeten hebben (daarom heb je polymorfisme)

code:

interface Game{
    void doYourThingies();
}

class Quake implements Game{
    void doYourThingies(){//check frag level;}
}

class StripPoker implements Game{
    void doYourThingies(){//check agel;}
}

class Casino implements Game{
    void doYourThingies(){//infect system with spyware;}
}

En je kan gewoon een 'game' downloaden. Je maakt dan van die class een instantie. En daarop roep je dan aan: doYourThingies() en het doet dan wat het moet doen.

Stel nu dat ik een enum waarde heb: MijnEnum.Casino -> hoe zou jij dan ervoor zorgen dat je de class Casino instantieert? (is dat correct Nederlands? )

[whoami]

Alarmnummer schreef op 05 september 2002 @ 15:57:
Zo gauw je met een switch statement gaat werken zit je vast aan een beperkt aantal spellen. Je kan alles perfect oplossen mbv polymorphisme.

Ook het creeëren van de objecten?

[Alarmnummer]

De class die wordt opgehaald van de server! De client maakt van deze class een instantie. Aangezien deze class aan een bepaalde interface voldoet kan de client op deze instantie gewoon methodes aanroepen.

En op de server zou dit perfect in een hashmap geplaatst kunnen worden. Je bent dus absoluut geen switch/enum nodig.

[Alarmnummer]

Even in pseudo code.

//de client die krijgt het gameclass object binnen (downloaden)
Class gameClass = getClass("Quake");

//van deze class object maak je een instantie..
Game game = (Game) gameClass.createInstance()

//en nu kan je er iets op aanroepen:
game.doYourThingies();

Het zal die client verder worst zijn of het een Quake of Casino spel is.

[Verwijderd]

Alarmnummer schreef op 05 september 2002 @ 16:01:
De class die wordt opgehaald van de server! De client maakt van deze class een instantie. Aangezien deze class aan een bepaalde interface voldoet kan de client op deze instantie gewoon methodes aanroepen.

En op de server zou dit perfect in een hashmap geplaatst kunnen worden. Je bent dus absoluut geen switch/enum nodig.

Hmmm? De server is gewoon een spel wat informatie terug geeft als ik het een bepaalde string stuur, bvb:
Ik stuur -> \xFF\xFF\xFF\xFFgetstatus\x00
Ik krijg <- \xFF\xFF\xFF\xFFServer naam\x00map naam\x00etc\x00

Nadat ik een string stuur, krijg ik dus 'een raar pakketje' waar ik vervolgens de nodige info uit haal en gebruik in mijn class.

[Alarmnummer]

Dat zou je ook kunnen doen, maar dynamisch classes inladen is veel flexibeler.

Je zou zelfs dynamtisch de schermen helemaal op kunnen laten bouwen, zodat ieder spel zijn eigen schermen heeft (met zijn eigen gui functionaliteit dus).

[Verwijderd]

Alarmnummer schreef op 05 september 2002 @ 16:09:
Dat zou je ook kunnen doen, maar dynamisch classes inladen is veel flexibeler.

ohhhhh wacht, sorry , jij bedoelt nog steeds dat ik 1 centrale server op zou kunnen zetten die de clients van bepaalde classes voorziet. Ik dacht telkens dat je het steeds over de gameserver had, ipv de server die ik eventueel zou moeten opzetten.

Dat is opzich een erg aardig idee, alleen zou iedere client dus telkens verbinding moeten maken met de server als de client een ander soort spel wil refreshen, of misschien wel per server?

Verder is het denk ik voor mij ook niet haalbaar, aangezien ik niet in het bezit ben of kan komen van een server die clients kan voorzien hiervan op dit moment.

Als ik dus toch 1 applicatie wil maken, zonder een server die de clients van enige informatie voorziet, hoe zou ik dan dit laatste probleem kunnen oplossen (van welke inherited class ik een instantie moet creeën)?

[Alarmnummer]

Het kan toch als klein servertje (hoeft denk ik niet veel bijzonders te zijn) te draaien naast de gameserver?

[edit]
of is die gameserver niet van jou?

[zeroxcool]

Sorry dat ik het zeg, maar waarom het wiel opnieuw uitvinden? Qstat gewoon overnemen?

[Alarmnummer]

En om een instantie te maken zou ik dus gebruik maken van een factory, waarbij je op basis van een string bv een game object kan aanmaken. In deze factory kan dat gebeuren met een hashmap ofzo.

code:

Game create(String gameName){
    String className = getClassNameForGameName(gameName);
    Class gameClass = classLoader.getClass(className);
    return (Game)gameClass.createInstance();
}

[Verwijderd]

Alarmnummer schreef op 05 september 2002 @ 16:20:
Het kan toch als klein servertje (hoeft denk ik niet veel bijzonders te zijn) te draaien naast de gameserver?

[edit]
of is die gameserver niet van jou?

Het progje moet van allerlei servers informatie kunnen opvragen.. Dus van zon 30.000 servers die HalfLife draaien, etc

[Alarmnummer]

Trouwens je hoeft verder niets met subclasses te doen als ze alleen in simpele data verschillen (dus een gelijke logica). Je zou dan gewoon 1 class kunnen maken die je vult.

[Verwijderd]

Alarmnummer schreef op 05 september 2002 @ 16:43:
Trouwens je hoeft verder niets met subclasses te doen als ze alleen in simpele data verschillen (dus een gelijke logica). Je zou dan gewoon 1 class kunnen maken die je vult.

Dat is wat ik eerst had, maar dan wordt het erg onoverichterlijk in die class wanneer je bvb 10 games support (reken er maar op dat je dan een class hebt van erg veel regeltjes )

[Alarmnummer]

Maar als ze niet in logica verschillen dan kan je met 1 class n games supporten zonder dat er in die class aanpassingen gedaan hoeven te worden.

[TheOneLLama]

Verwijderd schreef op 05 september 2002 @ 15:56:
[...]
Ik maak gebruik van delegates en voor iedere server die ik refresh, maak ik een thread aan, zodat het programma "niet hangt voor een tijdje".

Een delegate is ook goed natuurlijk.. je gebruikt nu een thread per server? Non blocking IO is misschien sneller. Of bedoel je met "server" 1 bepaalde game? (1 thread die alle halflife servers refreshed bijvoorbeeld).

Verder zou ik met interfaces werken en het liefst ook nog met dynamische class loading Dan kunnen andere mensen plugins schrijven voor jou programma, + met een goed OO design (bijv. zoals ik het net even opsomde) kun je later makkelijk en goed extra's inbouwen (ook voor de plugins). Het lijkt me wat flexibler als ergens gewoon een switch neergooien in ieder geval
Maar is het natuurlijk jou programma dus uiteindelijk jouw keuze

[Verwijderd]

TheOneLLama schreef op 05 september 2002 @ 17:06:
[...]


Een delegate is ook goed natuurlijk.. je gebruikt nu een thread per server? Non blocking IO is misschien sneller. Of bedoel je met "server" 1 bepaalde game? (1 thread die alle halflife servers refreshed bijvoorbeeld).

Verder zou ik met interfaces werken en het liefst ook nog met dynamische class loading Dan kunnen andere mensen plugins schrijven voor jou programma, + met een goed OO design (bijv. zoals ik het net even opsomde) kun je later makkelijk en goed extra's inbouwen (ook voor de plugins). Het lijkt me wat flexibler als ergens gewoon een switch neergooien in ieder geval
Maar is het natuurlijk jou programma dus uiteindelijk jouw keuze

Op dit moment moet ik dat nog allemaal uitwerken (ik add een server nu door in het programma op 1 plek even een methode aan te roepen). Ik ga er zometeen waarschijnlijk voor zorgen dat ik X simultaneous servers kan refreshen per gametype, en dus X threads zal krijgen. Zodra een server is refreshed refresht hij vervolgens de volgende server die in de queue wacht, zodat je constant X servers refresht en dus steeds X threads hebt tijdens het refreshen. (Dit was mijn plan iig.)

Verder kijk ik nu naar dynamic classloading en dit is misschien toch wel een erg aardig idee Is het slordig/dom om per game een plugin (dll) te maken dat vast zit aan een interface? Het uitwerken ervan zal namelijk erg gemakkelijk worden voor zover ik het nu kan overzien

[TheOneLLama]

Verwijderd schreef op 05 september 2002 @ 17:13:
[...]


Op dit moment moet ik dat nog allemaal uitwerken (ik add een server nu door in het programma op 1 plek even een methode aan te roepen). Ik ga er zometeen waarschijnlijk voor zorgen dat ik X simultaneous servers kan refreshen per gametype, en dus X threads zal krijgen. Zodra een server is refreshed refresht hij vervolgens de volgende server die in de queue wacht, zodat je constant X servers refresht en dus steeds X threads hebt tijdens het refreshen. (Dit was mijn plan iig.)

Non blocking IO is waarschijnlijk effectiever dan threads.. maar aangezien je toch niet teveel servers tegelijk wilt refreshen omdat bandwith beperkt is kan het wel (hoewel als je op een 100mbit lijntje zit ofzo..). threads is lekker makkelijk dat wel

Verder kijk ik nu naar dynamic classloading en dit is misschien toch wel een erg aardig idee Is het slordig/dom om per game een plugin (dll) te maken dat vast zit aan een interface? Het uitwerken ervan zal namelijk erg gemakkelijk worden voor zover ik het nu kan overzien

Slordig/Dom zou ik het niet noemen.. eerder netjes/verstandig

edit:
Natuurlijk wel er op letten dat je geen dingen dubbel gaat programmeren, om dat te verkomen kan je een soort "basis" plugin maken die je extend, of je kan die functionaliteit in het programma zelf zetten en (het liefst via een interface) "aanbieden" aan je plugin in de functie waarmee je de plugin aanspreekt.

[ Voor 0% gewijzigd door TheOneLLama op 05-09-2002 18:11 . Reden: toevoeging en "snetjes" ]

[Verwijderd]

TheOneLLama schreef op 05 september 2002 @ 18:04:
Slordig/Dom zou ik het niet noemen.. eerder netjes/verstandig

Ok

TheOneLLama schreef ook op 05 september 2002 @ 18:04:
edit:
Natuurlijk wel er op letten dat je geen dingen dubbel gaat programmeren, om dat te verkomen kan je een soort "basis" plugin maken die je extend, of je kan die functionaliteit in het programma zelf zetten en (het liefst via een interface) "aanbieden" aan je plugin in de functie waarmee je de plugin aanspreekt.

Ik maak een interface en deze biedt ik aan de plugins aan, zo weet mijn programma ook precies welke methodes hij kan aanroepen etc.

[Alarmnummer]

En wat ik persoonlijk erg handig vind is de volgende structuur:

code:

interface Plugin{
     //methodes.
}

abstract class AbstractPlugin implements Plugin{
      //data en methodes die alle plugins waarschijnlijk 
      //toch met elkaar moeten delen
}

abstract class EenPlugin extends AbstractPlugin{
}

Op deze manier heb je de vrijheid van de interface en toch niet onnodig veel code.

[Verwijderd]

Hmm, ik heb een soort gelijk probleem moeten oplossen. Ik ben bezig met een FTP server in C# waarbij de implementatie van de commando's in een aparte assembly is ondergebracht. Deze assembly wordt dynamisch ingeladen en alle klassen worden geinspecteerd. Nu heb ik het met attributen opgelost. Dan krijg je zoiets als dit:

code:

[FTPCommandAttribute("USER")]
public class FTPUserCommand : FTPCommand
{
    public override void Execute(string parameters, User user)
    {
        // doe iets
    }
}

[FTPCommandAttribute("PASS")]
public class FTPPasswordCommand : FTPCommand
{
    public override void Execute(string parameters, User user)
    {
        // doe iets anders
    }
}

Zo kun je dus een library met al die specifieke 'game' klassen maken. Deze klassen kun je dwingen om over te erven van jouw basis klasse of interface.
Volvolgens laad je de assembly in, en laat je een GameFactory klasse oid, afhankelijk van de meegeleverde string, de juiste klasse teruggeven.