Webbased chat & spel systeem ontwikkelen, welke taal?

[Verwijderd]

Ik heb met zowel de meest simpele als de meest exotische talen geprogrammeerd en kan in principe overal mee overweg. Momenteel ben ik bezig met de voorbereiding voor het maken van een spel+chat systeem. Na heel kort even experimenteren met php en database kwam ik er achter dat dit daar totaal ongeschikt voor is, oa omdat php stateless is en er geen betrouwbare manier is om php aan server initiated communicatie et doen (heb gekeken naar pollen, commet ed maar is niet fraai). Ik denk dat er met wat inzet wel wat van te maken is met php, maar dan kies ik toch liever een beter systeem.

Aan de client side draait een flash programma welke de mogelijkheid heeft om met sockets te werken. Ik moet echter voor de server side een efficient systeem kiezen om de communicatie te regelen en om wat simpele spellen in uit te programmeren die vervolgens de flash clients aansturen.

In eerste instantie zat ik te denken aan een linux daemon geschreven in c++. Omdat ik graag ontwikkel in windows dacht ik er over om wxWidgets te gebruiken (wx heeft mogelijkheden om sockets aan te sturen) zodat ik de code kan gebruiken onder een windows computer (ontwikkeling) en voor gebruik op een linux server neer te zetten. Voordeel is dat c++ efficient is en ik tegelijk voor windows als linux ontwikkel.

Alleen vind ik zelf c++ niet echt een "fijne" taal gezien de beperkte basis library en daarnaast is de documentatie van wxWidgets verre van optimaal. Om mijzelf een boel ergernis te besparen dacht ik er aan om misschien toch maar gebruik te maken van java. Ik heb zelf in een grijs verleden er ook mee gewerkt en ik heb het altijd als fijn ervaren omdat je out-of-the-box een lekker complete library hebt en een uitstekende documentatie. Maar, java zal echter wel meer resources vragen dan een c++ daemon. Maar daar weegt weer tegen op dat java er naar mijn mening beter voor geschikt is.

Mijn probleem is dat ik even de weg kwijt ben in het bos van alle java "technologien". Ik heb een uur gekeken op de java.sun.com site en daar staan echt een gigantische hoeveelheid van afkortingen ed en wordt alles heel formeel en vrij onduidelijk beschreven wat nou precies het sterke punt is van een bepaalde "technologie".

Wat ik me in het kort afvraag is:

- Is java voor mij inderdaad een goede keus om te gebruiken?
- Als ik java gebruikt, wat moet ik dan precies gebruiken (simpele java daemon, GlassFish, j2ee, netbeans, jsp) ?
- Hoe zit het met de licenties? Ik wil graag voorkomen dat ik dure licenties moet betalen en c++ icm wxWidgets is 100% vrij en grats. Ik zou dat graag ook zien voor een java alternatief.
- Als java niet geschikt (genoeg) is, is c/c++ & wxWidgets dan wel een goede basis?
- Is er misschien een nog betere optie? Ik heb al gedacht aan scripttalen als pearl ed, maar die zijn nog een stuk minder efficient als java en c++ en lijken mij daarom helemaal minder geschikt.

Overigens heb ik ooit wel eens gewone java programma's gemaakt en ook server side java software, ik kan me alleen niet meer scherp voor ogen halen wat nou ook al precies geschikt is voor wat. Als iemand mij even een duwtje kan geven in de goede richting dan kom ik er verder zelf wel uit.

Ps ik kan nog een hele uitweiding geven over wat het systeem precies moet doen ed, maar ik vond de post nu al meer dan lang genoeg .

[Herko_ter_Horst]

Wat het systeem moet doen is nog wel belangrijk voor de keuze van je taal/technologieen. Wat bedoel je bijvoorbeeld precies met "web-based"? Volledig in een browser draaiend? Alleen HTML/JavaScript (evt. AJAX)? Flash? Java applets/JavaFX? Of is "startbaar van een webpagina" meer de bedoeling (Java WebStart)?

Ik zou zonder gegronde reden niet zo gauw beginnen met een helemaal zelfgeschreven daemon. Er zijn genoeg standaard applicatie servers en/of networking frameworks die al heel veel problemen voor je oplossen.

Zonder verdere informatie denk ik overigens dat je je aan de keus voor Java als taal niet zo snel een buil zult vallen. Naast de rijke standaard libs zijn er ook heel veel (te veel?) libraries en frameworks voor diverse toepassingen. Afhankelijk van wat voor soort game+chat je precies wil gaan maken en hoe uitgebreid het uiteindelijk moet worden, zou je bijvoorbeeld eens kunnen kijken naar Java Game Server (Project Darkstar).

Disclaimer: ik heb de laatste 10 jaar vrijwel uitsluitend in Java gewerkt, dus ik heb misschien een "lichte" bias

[ Voor 24% gewijzigd door Herko_ter_Horst op 21-02-2008 16:28 ]

[killercow]

Precies,

Wat voor protocol wil je gebruiken?
Http is zowiezo stateless, daar doet je server niks aan,
Je data persistent houden op de server is wel nuttig, maar als je over http blijft kletsen hou je het stateless probleem.

Connecties leggen vanaf je server richting je client lijkt me niet wenselijk, andersom is makkelijker.

Daarnaast, wat moet je met widgets op je server? maak gewoon een 2e client (des noods ook in flash, of gewoon in php) die ook met je server process kletst en de admin commands uitvoert en data uitleest.

[Verwijderd]

Ik wilde dat er ook nog neerzetten maar ik vond mijn post al veel te lang .
Het idee is alsvolgt

Er moet een bordspel worden gemaakt mbv een flash client en in dat spel zijn ook oa chatrooms.
Het is belangrijk dat er een snelle responce is en heel snel pollen is gewoon veeel te veel belastend. Mijn idee is dus socket verbinding van de server naar de flash client te gebruiken. De server moet dus alle mensen die in een bepaalde chatroom zijn elke keer een nieuw bericht sturen wanneer iemand wat zegt. Ook moet de server alle geldige zetten steeds berekenen en naar de clients sturen en daarom is het belangrijk dat de taal redelijk efficient is (steeds analyseren van alle mogelijke zetten kost wat rekenwerk). De client is alleen een flash interface, die doet verder helemaal niets behalve tonen wat de server hem opdraagt.

En om te voorkomen dat je niet steeds de stelling in een spel uit de database moet opvragen bij elke zet wil ik een daemon gebruiken die alles gewoon in het geheugen onthoud.

[Herko_ter_Horst]

Sorry, ik had de TS iets te vluchtig gelezen: je hebt al een keus gemaakt voor de clients. Ligt die keus overigens vast?

Wat betreft de server: communicatie over HTTP ligt erg voor de hand. Een willekeurige Java application server c.q. servlet container (bijv. Apache Tomcat neemt je dan al heel wat werk uit handen. Hierop kun je applicaties deployen die geschreven zijn volgens de servlet- en JSP specs (onderdeel van Java Enterprise Edition).

[FragFrog]

Hoezo is PHP daarvoor ongeschikt?

* FragFrog is met bijna exact hetzelfde bezig waarbij de socket server geschreven is in PHP.

Screenshotje van huidige status: hier. Wat je ziet is een main connector service waar clients naar connecten, een authenticatie server waar authenticatie requests heen gaan (en response daarvan terugkomen) en een gameserver die via een link naar de connectserver controleert of iemand ook netjes ingelogd is en zoja de rest afhandelt qua chars en monsters etcetera.

Het is een persoonlijk project om een beetje te experimenteren met sockets, vandaar de losse authenticatie server (die eigenlijk overbodig is aangezien het enige wat'ie doet is een paar SQL queries uitvoeren, dat kan de connectserver ook nog wel), maar als proof-of-concept werkt het aardig. Laatste versie van de flash client is hier te vinden. Registratie zeurt wat, testlogin 'aapje' / 'blaat' zou moeten werken

Waarom ik voor PHP gegaan ben: 2 simpele redenen.

1. Ik ben goed in PHP. Een kleine 5 jaar spelen en ruim 5 maanden werken als eerst junior, daarna senior PHP coder leert je wel het een en ander en ondertussen kan ik de taal wel dromen - niet dat dat een enorme prestatie is, PHP is gewoon makkelijk. Dit stelt me in staat om me volledig te richten op het 'wat', niet het 'hoe'.

2. C++ is voor mij teveel gedoe om alles wat ik ermee wil simpel en snel te doen. Ik heb wel eens een socketserver geschreven in C++, maar om die vervolgens weer meerdere connecties tegelijk aan te laten kunnen was alweer een probleem, etcetera etcetera. Sowieso is mijn C++ kennis vrij laag en zijn dit soort applicaties wel typisch dingen waarbij je je volledig wil kunnen focusen op de opbouw van je programma en je niet teveel wilt miereneuken over hoe je bepaalde kleine dingetjes aan de praat krijgt.

Natuurlijk zijn er ook nadelen aan PHP gebruiken - zo is het ongetwijfeld trager dan een puur C++ oplossing en is het heel ingewikkeld om ook een GUI voor je server ermee te maken. Als je dan ook goed bent in C++ (of Java, of eigenlijk welke andere taal dan ook) zou ik je vooral aanraden daarmee verder te gaan. Maar als je wel goed bent in PHP en geen zin hebt een andere taal te leren is het absoluut mogelijk om daarin te doen wat jij wilt

[ Voor 3% gewijzigd door FragFrog op 21-02-2008 16:50 ]

[Hydra]

Verwijderd schreef op donderdag 21 februari 2008 @ 16:39:
Ik wilde dat er ook nog neerzetten maar ik vond mijn post al veel te lang .
Het idee is alsvolgt

Er moet een bordspel worden gemaakt mbv een flash client en in dat spel zijn ook oa chatrooms.
Het is belangrijk dat er een snelle responce is en heel snel pollen is gewoon veeel te veel belastend. Mijn idee is dus socket verbinding van de server naar de flash client te gebruiken. De server moet dus alle mensen die in een bepaalde chatroom zijn elke keer een nieuw bericht sturen wanneer iemand wat zegt. Ook moet de server alle geldige zetten steeds berekenen en naar de clients sturen en daarom is het belangrijk dat de taal redelijk efficient is (steeds analyseren van alle mogelijke zetten kost wat rekenwerk). De client is alleen een flash interface, die doet verder helemaal niets behalve tonen wat de server hem opdraagt.

En om te voorkomen dat je niet steeds de stelling in een spel uit de database moet opvragen bij elke zet wil ik een daemon gebruiken die alles gewoon in het geheugen onthoud.

Dat kan prima in Java, en dan gewoon in de 'basis' editie. Daarmee kun je zondermeer een simpele socket server bouwen die dit voor je regelt.

Een andere optie is om voor een webservice te gaan. Heeft als voordeel dat je geen problemen gaat krijgen met firewalls, maar heeft als nadeel dat HTTP staeless is, en je dus iets moet verzinnen om tijdig updates naar de clients te krijgen. Via een gewone TCP/IP verbinding is dat simpeler te realiseren.

[Verwijderd]

Niets ligt vast, ik mag alles zelf kiezen, maar GEEN dure licenties en het moet goed overweg kunnen met flinke belasting.

Waar ik mee zit is dat ik niet bij elke zet het spelbord uit een database wil opvragen, maar gewoon steeds vanuit het geheugen werken (1 spel kost weinig geheugen). Ik heb gekeken naar JSp's maar ik kreeg het idee daarbij dat het net als php, niet in staat is om data te bewaren, elke keer als een pagina wordt opgevraagd. En juist als je pakweg 200 spelers hebt en iedereen doet per 3 seconden 1 zet dan heb je dus alleen daarvoor al 70x p/s dat je een zet ontvangt van een client, de nieuwe opstelling moet analyseren en de nieuwe mogelijke zetten moet opsturen.

reden voor sockets is efficiency en omdat flash dat kan. Op andere manieren communiceren met flash is "lastiger". Ik ken geen flash maar dat is wat ik hoorde van de flash ontwikkelaar.. die zei sockets is veel beter (dan loadvar oid?).

reden voor deamon is dat alle data in het geheugen blijft. Natuurlijk wordt er wel wat data opgeslagen in de database maar dat is alleen aan het begin en einde van een spel.

Voor de rest ben ik redelijk vrij...

Wat jij zegt met tomcat + jsp (had ik al bekeken) leek me goed, behalve dan dat ik bang was dat het weer veel te zwaar zou worden voor de server. Zelf heb ik geen ervaring met de overhead van http communiocatie en de communicatie met sockets. Sockets leek me efficienter te werken, maar dat is nergens op gebasseerd.

Ik heb overigens wel even met apache gespeeld en kwam er achter als je flink wat pagina's opvraagt (met benchmark) dat die niet eens zo heel gek veel kan hebben. Daarnaast weet ik dat er voor (sommige) chatservers apparte efficientere webservers worden gebruikt dan apache (apache minder geschikt voor HEEL veel verkeer?) .

[Verwijderd]

FragFrog schreef op donderdag 21 februari 2008 @ 16:45:
Hoezo is PHP daarvoor ongeschikt?

Het is mogelijk in php, ben ik absoluut van overtuigd. Maar het zijn flink wat haken en ogen aan. Als je zoekt naar commet en php zie je wel wat oplossingen. Het werkt wel, maar fraai en betrouwbaar is het niet echt. Daarnaast vind ik 1 van de nadelen dat php debug omgeving lastig is om te instaleren (er is wat spul van zend maar dat crashte bij mij om de haverklap). Daarnaast is php niet strikt genoeg. Ik vind het heel vervelend dat je niet kan instellen dat een variabele eerst moet worden gedeclareerd voor gebruik. Zo zijn er nog wat van die kleine dingen die voor kleine projecten geen probleem geven, maar die bij grote projecten het een stuk lastiger maken vanwege alle vrijheden die je hebt. Daarnaast is php idd een stuk trager in het analyseren van alle mogelijke zetten. (Als ik een kans zag om het te doen in php had ik dat ook wel gedaan trouwens, voor kleine projecten is dat veel makkelijker dan c++).

EDIT
de reden dat ik c++ en wxwidgets wilde gebruiken is omdat c++ opzichzelf erg kaal is wat betreft de functionaliteit. Met wxwidgets wordt dat gedeeltelijk opgevangen (hoopte ik).

[ Voor 10% gewijzigd door Verwijderd op 21-02-2008 17:07 ]

[FragFrog]

Voor zover ik weet maakt Apache voor elke request een nieuwe thread aan. Dit zorgt voor redelijk wat overhead (omdat je dan ineens honderden processen hebt lopen) en in dusverre is het limterend. Aan de andere kant zorgt dat er wel voor dat processen niet op elkaar hoeven te wachten, dus voor HTTP is het doorgaans perfect

Als je trouwens toch voor een stateless oplossing willen gaan kun je met memcache ook alles in je servers werkgeheugen opslaan. Maar dan nog zul je voor elke request opnieuw een connectie moeten maken met de memcachedeamon, status opvragen, bewerking doen en status teruggeven, in zoverre ben ik het met je eens dat een daemon veel beter is.

Wat betrefd flash: ik sta er eigenlijk versteld van hoe simpel werken met sockets in flash is, ben er zelf zoals gezegd net wat mee aan het experimenteren geslagen en met de handleiding erbij is het prima te doen. Let er wel even op dat je tegenwoordig een policy file request krijgt met externe domainen, zo'n beetje het grootste struikelblok wat betrefd werken met sockets in flash begreep ik

//edit @ hierboven
Als je PHP's warning level op E_NOTICE zet zul je zien dat ook PHP verwacht dat je variabelen eerst initialiseert - om maar iets te noemen. Sinds PHP 5 is het ook eindelijk mogelijk goed OO te werken, grote projecten zijn daarmee helemaal niet meer een probleem. Qua zetanalyse durf ik zelfs te beweren dat PHP qua snelheid niet veel onder zal doen voor C++ aangezien het daar op gebouwd is. Het zijn juist de extra vertaalslagen (type casting etc) die het traag maken, maar voor wiskundige bewerkingen met ints is die overhead minimaal.

Stabiliteit durf ik dan weer geen uitspraken over te doen, wellicht dat je daar een punt hebt

[ Voor 23% gewijzigd door FragFrog op 21-02-2008 17:14 ]

[Verwijderd]

Memcache heb ik gelezen, zag er goed uit maar omdat het niet in mijn php zat en mijn herhaalde pogingen om php succesvol te compileren op linux eindigde in veel frustratie en weinig slaap, heb ik memcache laten varen. Maar zoals ik al zei, met een beetje goede wil is het wel werkend te krijgen (maar dan helaas voor veel minder clients dan bij java of c++ gok ik).

[Hydra]

FragFrog schreef op donderdag 21 februari 2008 @ 17:06:
Voor zover ik weet maakt Apache voor elke request een nieuwe thread aan.

V.z.i.w. maakt apache gebruik van een thread pool. Daar voor is die maxthreads config parameter.

Verwijderd schreef op donderdag 21 februari 2008 @ 17:10:
Memcache heb ik gelezen, zag er goed uit maar omdat het niet in mijn php zat en mijn herhaalde pogingen om php succesvol te compileren op linux eindigde in veel frustratie en weinig slaap, heb ik memcache laten varen. Maar zoals ik al zei, met een beetje goede wil is het wel werkend te krijgen (maar dan helaas voor veel minder clients dan bij java of c++ gok ik).

Ik zou, als het een optie is, zeker voor Java of C# maken. Daar kun je prima een dergelijke gameserver in bouwen zonder dat je iets van licenties moet kopen, het is snel zat, en je hebt een strongly typed taal waarin snel te ontwikkelen is.

[ Voor 55% gewijzigd door Hydra op 21-02-2008 17:13 ]

[FragFrog]

Hydra schreef op donderdag 21 februari 2008 @ 17:11:

V.z.i.w. maakt apache gebruik van een thread pool. Daar voor is die maxthreads config parameter.

I stand corrected Zat waarschijnlijk aan PHP threads te denken oid

[Herko_ter_Horst]

Even voor wat betreft Tomcat en JSP: JSP is slechts een "uitvoer" mechanisme (de View in het MVC model). Net als in PHP is mogelijk alle logica te integreren met de output, maar dit is niet de gewenste aanpak.

In het algemeen worden servlets gebruikt als "Controller". Hiermee ben je prima in staat ook buiten een request om data te bewaren en manipuleren.

Maar aangezien je meer op zoek lijkt naar een "multicast" oplossing is een HTTP server mogelijk toch niet de beste manier.

Ik zou eens serieus kijken naar Project Darkstar: http://www.projectdarkstar.com/

[Verwijderd]

Hydra schreef op donderdag 21 februari 2008 @ 17:11:
[...]


V.z.i.w. maakt apache gebruik van een thread pool. Daar voor is die maxthreads config parameter.

Ik zie nooit veel apache threads draaien (zelfs bij matige belasting) dus het lijkt me niet heel waarschijnlijk. Maar volgens mij is communicatie met een daemon veel efficienter als alles communicatie langs apache te laten lopen. Met apache ben je wel veelzijdiger natuurlijk, maar nu probeer ik zoveel mogelijk perfomance te halen want dat is van primair belang voor het slagen van het systeem.

PS
Ik heb nu al een heleboel constructieve opmerkingen gehoord, maar ik zit nog steeds met het probleem of:
klopt mijn redenering dat java hiervoor prima werkt?
Welke java stuff moet ik gebruiken/instaleren. Mijn gevoel zecht lekker simpel java daemon maken want daar weet ik wel raad mee. Als ik hele applicatie servers zelf moet instaleren zou dat kunnen tegenvallen misschien. En dan is er nog het puntje met licenties & java. De gekozen oplossing in java mag niet veel $$$ gaan kosten.

[Hydra]

Verwijderd schreef op donderdag 21 februari 2008 @ 17:18:
Welke java stuff moet ik gebruiken/instaleren. Mijn gevoel zecht lekker simpel java daemon maken want daar weet ik wel raad mee. Als ik hele applicatie servers zelf moet instaleren zou dat kunnen tegenvallen misschien. En dan is er nog het puntje met licenties & java. De gekozen oplossing in java mag niet veel $$$ gaan kosten.

Ik zeg toch net dat je dat met gewoon Java SE dat prima kunt bouwen? Dus een standalone game server?

[Herko_ter_Horst]

M.i. is Java prima geschikt voor wat je wilt doen.

Ook is het zonder meer mogelijk een simpel Java daemon te schrijven. Minder simpel is het om een schaalbaar en betrouwbaar Java daemon te schrijven.

M.b.t. de kosten: heel veel in Java is gratis en zelfs Open Source, of er is een gratis/Open Source variant van wat je wil (Project Darkstar is bijv. beschikbaar onder de GPL). Let wel: Open Source betekent niet persé dat je alles mag doen wat je wil. Maar wel dat het gratis is

Overigens m.b.t. het onderscheid tussen een "daemon" en "Apache": Apache httpd is ook "gewoon" een "daemon" natuurlijk. En reken maar dat daar flink aan geoptimaliseerd is om het efficient en schaalbaar te krijgen. Denk niet te simpel over het schrijven van een eigen daemon.

[ Voor 22% gewijzigd door Herko_ter_Horst op 21-02-2008 17:26 ]

[Verwijderd]

Ik zou, als het een optie is, zeker voor Java of C# maken. Daar kun je prima een dergelijke gameserver in bouwen zonder dat je iets van licenties moet kopen, het is snel zat, en je hebt een strongly typed taal waarin snel te ontwikkelen is.

C# lijkt me het beste (hoewel ik daar weinig ervaring mee heb), maar omdat mono slechts een gedeeltelijke port is van de microsoft versie (zoeits meende ik me te herinneren), en dit project gewoon niet langer dan noodzakelijk moet duren wil ik het liefst een beetje in de buurt blijven wat ik ken

Project darkstat zag er interessant uit tot ik zag dat het bij Release 0.9.5.1 is. Ik denk niet dat het een goed idee is om iets te pakken waarvan nog geen v1.0 van is . Hoewel dat wat zwartwit is, heb ik ook het idee dat een chatserver opzichzelf en een simpele game prima zelf te maken is in java. De tijd die ik bespaar met het gebruik van darkstat is niet zo veel denk ik als de tijd die ik nodig ga hebben om dat hele systeem te gebruiken. Voor 1 spel en een chat functionaliteit is dat misschien niet de moeite waard.

Dus nu zet ik mijn geld in op een java daemon welk ik maak met de gewone sdk? Ik had gelen dat de j2ee een hele java.net lib had ofzo (en nog wat van die dingen) heb ik dat ook nodig dan?

EDIT zodra ik een haalbare oplossing heb ga ik even netjes de kleine lettertjes lezen wat ik wel en niet mag doen

[ Voor 4% gewijzigd door Verwijderd op 21-02-2008 17:27 ]

[Hydra]

Herko_ter_Horst schreef op donderdag 21 februari 2008 @ 17:24:
Ook is het zonder meer mogelijk een simpel Java daemon te schrijven. Minder simpel is het om een schaalbaar en betrouwbaar Java daemon te schrijven.

Dat geldt niet specifiek voor Java. Volgens mij is het nog moeilijker een degelijke, schaalbare en betrouwbare daemon in C++ of PHP te bouwen. Ik denk dat het vooral belangrijk is dat het ontwikkeld wordt door iemand die weet waar 'ie mee bezig is.

Verwijderd schreef op donderdag 21 februari 2008 @ 17:26:
C# lijkt me het beste (hoewel ik daar weinig ervaring mee heb), maar omdat mono slechts een gedeeltelijke port is van de microsoft versie (zoeits meende ik me te herinneren), en dit project gewoon niet langer dan noodzakelijk moet duren wil ik het liefst een beetje in de buurt blijven wat ik ken

Waar gaat die gameserver op draaien? Linux?

Dus nu zet ik mijn geld in op een java daemon welk ik maak met de gewone sdk? Ik had gelen dat de j2ee een hele java.net lib had ofzo (en nog wat van die dingen) heb ik dat ook nodig dan?

Euh, lees je ff in over java socket programming? java.net bevat een aantal classes die je nodig gaat hebben ja, maar alles wat je nodig hebt zit in ieder geval in de Java SE. Ik raad je overigens wel aan om lazy naar een database te saven om te voorkomen dat een harde crash zorgt dat mensen hun info kwijt zijn.

[ Voor 48% gewijzigd door Hydra op 21-02-2008 17:29 ]

[Verwijderd]

Hydra schreef op donderdag 21 februari 2008 @ 17:27:
[...]


Dat geldt niet specifiek voor Java. Volgens mij is het nog moeilijker een degelijke, schaalbare en betrouwbare daemon in C++ of PHP te bouwen. Ik denk dat het vooral belangrijk is dat het ontwikkeld wordt door iemand die weet waar 'ie mee bezig is.

Met c/c++ kan je makkelijk nul pointers hebben, memory leaks en dat soort dingetjes. Met java kan je ook de mist in gaan, maar op de ene manier gebeurde dat bij mij stukken minder vaak dan met c++. Natuurlijk kan je er in c++ wel iets aan doen, maar java heeft het direct al. Dat is ook een reden dat ik liever java gebruik.

[Herko_ter_Horst]

Releasenummers zou ik niet zoveel waarde aan hechten, zegt tegenwoordig erg weinig meer over de kwaliteit van het product.

Als je toch zelf wilt gaan knutselen, heb je niets anders nodig dan SE (zoals hierboven ook al aangegeven). De java.net en java.nio packages in Java SE bevatten in principe alles wat je nodig hebt. Maar nogmaals: denk niet te licht over het maken van iets wat ook nog schaalbaar en stabiel is.

[Verwijderd]

Hydra schreef op donderdag 21 februari 2008 @ 17:27:

Waar gaat die gameserver op draaien? Linux?

Mag ik in principe beslissen, ik heb liever een linux server dan een windows server dus daar ga ik nu maar van uit. (waarschijnlijk debian of ubuntu server edition)

Euh, lees je ff in over java socket programming? java.net bevat een aantal classes die je nodig gaat hebben ja, maar alles wat je nodig hebt zit in ieder geval in de Java SE. Ik raad je overigens wel aan om lazy naar een database te saven om te voorkomen dat een harde crash zorgt dat mensen hun info kwijt zijn.

Uiteraard, ik heb me al helemaal suf gelezen in de soms matige wxWidgets documentatie, en daarna kwam ik pas op het idee om java te gebruiken. Had het al wel eerder overwogen maar toen wist ik niet dat ik de vrije hand had om de server volledig te gaan inrichten etc etc. Dus voordat ik me nu weer ga inlezen om er achter te komen dat java hier niet geschikt voor is... wilde ik het even vragen. Om je echt in te werken in de stof is ook een behoorlijke investering kwa tijd voor nodig helaas . Maar met jullie adviesen denk (ook?) ik dat java voor mij in dit geval veruit het beste is.

EDIT
Ik weet dat het niet heel makkelijk zal zijn om een goede schaalbare server te maken en zal me eerst goed verdiepen in de materie voordat ik ook maar 1 regel programma code schrijf . Ik heb nog wel 1 vraagje over de schaalbaarheid...
Stel.. (hypothetisch, en puur ter illustratie)
Ik wil de chat gedeelte loskoppelen van het game gedeelte om de load te balanceren. Ik las wat bij (ik dacht j2ee) over dat het daar makkelijk is om alles schaalbaar te hebben, te verdlelen op verschillende servers etc etc. Als ik graag in de toekomst servers wil toevoegen om de load op te delen. Kan ik dan helemaal overnieuw beginnen. Is het dan beter om met j2ee of 1 van die andere interessant klinkende afkortingen te gaan gebruiken? Als daar meer toekomst in zit vind ik het niet erg om me daar in te verdiepen.

[ Voor 24% gewijzigd door Verwijderd op 21-02-2008 17:41 ]

[Herko_ter_Horst]

"What is the best knife when you're alone out there in the jungle?"
- "The best knife by far is the one you have with you."

Oftewel: op zich zijn zowel C, C++, C# als Java geschikt om dit probleem mee op te lossen. Voor mijzelf zouden C, C++ en C# echter niet bruikbaar zijn omdat ik die "niet bij me heb": ik zou teveel moeite moeten doen om me de best practices and boiler plate eigen te maken, aangezien ik vrijwel uitsluitend met Java heb gewerkt de afgelopen tijd.

Je hebt een aantal voorkeuren aangegeven waardoor de keuzes wat beperkter zijn geworden. Als jij zelf inschat dat je met Java goed uit de voeten kunt: go your gang. Maar als je bijvoorbeeld veel beter thuis ben in C/C++, zou ik niet voor Java gaan (tenzij je graag Java ervaring op wil doen).

M.b.t. tot schaalbaarheid: veel frameworks en applicatie servers komen pas goed tot hun recht bij grote schaal. Voor probeerseltjes en kleinschalige hobbyprojectjes lijkt het vaak overkill. Dus als je echt serieus op schaal wilt gaan werken, zou ik daar zeker naar kijken.

[ Voor 15% gewijzigd door Herko_ter_Horst op 21-02-2008 17:48 ]

[Hydra]

Herko_ter_Horst schreef op donderdag 21 februari 2008 @ 17:44:
Je hebt een aantal voorkeuren aangegeven waardoor de keuzes wat beperkter zijn geworden. Als jij zelf inschat dat je met Java goed uit de voeten kunt: go your gang. Maar als je bijvoorbeeld veel beter thuis ben in C/C++, zou ik niet voor Java gaan (tenzij je graag Java ervaring op wil doen).

Inderdaad, hoewel ik wel vind dat iemand die C++ of C onder de knie heeft, vrij snel Java zou moeten kunnen leren. Dan is het verder vooral een kwestie van zorgen dat je wat leesvoer wat betreft Java socket programming onder ogen krijgt.

Verwijderd schreef op donderdag 21 februari 2008 @ 17:36:
Ik weet dat het niet heel makkelijk zal zijn om een goede schaalbare server te maken en zal me eerst goed verdiepen in de materie voordat ik ook maar 1 regel programma code schrijf . Ik heb nog wel 1 vraagje over de schaalbaarheid...
Stel.. (hypothetisch, en puur ter illustratie)
Ik wil de chat gedeelte loskoppelen van het game gedeelte om de load te balanceren. Ik las wat bij (ik dacht j2ee) over dat het daar makkelijk is om alles schaalbaar te hebben, te verdlelen op verschillende servers etc etc. Als ik graag in de toekomst servers wil toevoegen om de load op te delen. Kan ik dan helemaal overnieuw beginnen. Is het dan beter om met j2ee of 1 van die andere interessant klinkende afkortingen te gaan gebruiken? Als daar meer toekomst in zit vind ik het niet erg om me daar in te verdiepen.

Hoe je dit oplost heeft nauwelijks iets met de keuze voor Java of C++ te maken, maar alles met de applicatiearchtectuur. Zou je ons iets meer van een idee kunnen geven wat je precies van plan bent? Je zou sowieso het chat en de gameserver delen los kunnen koppelen. Wat me nog beter lijkt is 1 systeem te maken waarmee je een soort foyer creert. Dit heeft dan twee taken: A: een chatserver waar mensen bij mekaar kunnen komen om een game op te starten, en B: groepjes mensen toewijzen aan 1 van de game servers.

Op deze manier kun je de game servers gewoon repliceren, dus dan heb je bijvoorbeeld 1 foyer server en 1-X game servers, waaraan mensen toegewezen worden. Ten slotte wil je waarschijnlijk ook een database server, maar ik weet niet of je uberhaupt een bepaalde state op wil gaan slaan, daarvoor hebben we te weinig info.

[ Voor 57% gewijzigd door Hydra op 21-02-2008 17:50 ]

[Verwijderd]

Okay bedankt voor al jullie adviezen en hele snelle reacties, tijd voor mij om mijn java kennis eens even een opfris cursus te geven.

(Overigens heb ik van de meeste talen iig al geproeft en kan ik me de meeste vrij vlot mee werken ( c, java, js, haskell, prolog etc etc) dus in dit geval is het een beetje kiezen van welk instrument voor deze opdracht ik zal nemen).

[ Voor 47% gewijzigd door Verwijderd op 21-02-2008 17:52 ]

[Herko_ter_Horst]

Hydra schreef op donderdag 21 februari 2008 @ 17:47:
[...]

Inderdaad, hoewel ik wel vind dat iemand die C++ of C onder de knie heeft, vrij snel Java zou moeten kunnen leren. Dan is het verder vooral een kwestie van zorgen dat je wat leesvoer wat betreft Java socket programming onder ogen krijgt.

Het programmeren op zich zal wel lukken, daarvoor zijn de talen nauw genoeg verwant (kan soms ook verwarrend zijn). Maar hoe efficient je een serieuze applicatie kan schrijven is meer afhankelijk van kennis van beschikbare libraries, frameworks, voors en tegens van bepaalde aanpakken, die allemaal erg taal-afhankelijk zijn.

Als je de verkeerde tutorial over Java socket programming leest, zou je bijv. het bestaan van NIO kunnen missen, terwijl je als "ingevoerde" in de Java wereld dat soort dingen weet (misschien niet het beste voorbeeld, maar ik denk dat je begrijpt wat ik bedoel).

[Verwijderd]

Hydra schreef op donderdag 21 februari 2008 @ 17:47:
Hoe je dit oplost heeft nauwelijks iets met de keuze voor Java of C++ te maken, maar alles met de applicatiearchtectuur. Zou je ons iets meer van een idee kunnen geven wat je precies van plan bent? Je zou sowieso het chat en de gameserver delen los kunnen koppelen. Wat me nog beter lijkt is 1 systeem te maken waarmee je een soort foyer creert. Dit heeft dan twee taken: A: een chatserver waar mensen bij mekaar kunnen komen om een game op te starten, en B: groepjes mensen toewijzen aan 1 van de game servers.

Op deze manier kun je de game servers gewoon repliceren, dus dan heb je bijvoorbeeld 1 foyer server en 1-X game servers, waaraan mensen toegewezen worden. Ten slotte wil je waarschijnlijk ook een database server, maar ik weet niet of je uberhaupt een bepaalde state op wil gaan slaan, daarvoor hebben we te weinig info.

Inderdaad, het heeft niets te maken met mijn orginele ts, maar is een vervolg vraag van mijn zoektocht naar wat ik het best kan gebruiken.

Wat ik zelf had bedacht is dit:
In principe wil ik zo weinig mogelijk beperkingen. Stel er moet eens een spel aan worden toegevoegd, dan probeer ik mijn code.ontwerp hier op voorbereid te laten zijn mits dit makkelijk te doen is.

Wat er nu moet komen is 1 grote flash met de volgende functionalitet:
Een mogelijkheid om met (bv) 100 andere spelers in een chatroom te zitten en ze uit te nodigen voor een spel. In deze chatroom wordt er ook flink gepraat, en dat moet ook snel en prettig (weinig vertraging) werken.

Als je in een spel zit kan je ook met de andere speler praten en gasten kunnen ook joinen en praten natuurlijk.

Mogelijk wordt er ooit een spel aan toegevoegd, waar mogelijk moet ik hier rekening mee houden. Dan komen er extra chatrooms en een extra "ding" die het andere spel afhandelt.

Ik dacht als globaal ontwerp, 1 daemon die alle communicatie afhandelt en die elk bericht van een client doorstuurt naar een apparte functionele eenheid (thread/process ?). Deze functionele eenheid doet zijn ding en als die klaar is stuurt die indirect een bericht terug naar de goede clients .
De verwachtte belasting is zo groot (klein) dat het voorlopig prima mogelijk is in de meest extreme gevallen om alle spelgebeurtenissen op 1 server af te handelen en alle chat gedeeltes ook op 1 server. Dan heb je nog 1 server die de communicatie regelt naar en van alle clients dus in totaal 3 servers. Maar omdat het nu nog niet zo druk is, kan het nu nog allemaal op 1 server. Maar het hoeft niet zo te zijn dat je bv het chatgedeelte opzichzelf moet opdelen op 2 servers. Dus de schaalbaarheid komt overeen met het functioneel scheiden van de onderdelen. Dat is schaalbaar "genoeg" (voorlopig).

Dit is trouwens nog maar slechts een idee, er zal nog wel wat aan worden verandert.

Ik las over dat het makkelijk is om met [interessante java afkorting] makkelijk is om services en programmas te deplayen zodat je makelijk kan schalen etc. Heb ik dat misschien nodig als ik bijvoorbeeld mijn server gedeelte wil opdelen in 3 gedeeltes?

[ Voor 5% gewijzigd door Verwijderd op 21-02-2008 18:09 ]

[Verwijderd]

Herko_ter_Horst schreef op donderdag 21 februari 2008 @ 17:53:
[...]


Het programmeren op zich zal wel lukken, daarvoor zijn de talen nauw genoeg verwant (kan soms ook verwarrend zijn). Maar hoe efficient je een serieuze applicatie kan schrijven is meer afhankelijk van kennis van beschikbare libraries, frameworks, voors en tegens van bepaalde aanpakken, die allemaal erg taal-afhankelijk zijn.

Als je de verkeerde tutorial over Java socket programming leest, zou je bijv. het bestaan van NIO kunnen missen, terwijl je als "ingevoerde" in de Java wereld dat soort dingen weet (misschien niet het beste voorbeeld, maar ik denk dat je begrijpt wat ik bedoel).

Ik begrijp het helemaal, ik kan zien wanneer ik iets over het hoofd zie, maar als ik een prob heb met java zal ik iig eens even goed in de api zitten te spitten om te kijken of ik niet iets over het hoofd zie.

[Hydra]

Verwijderd schreef op donderdag 21 februari 2008 @ 18:02:
Wat er nu moet komen is 1 grote flash met de volgende functionalitet:
Een mogelijkheid om met (bv) 100 andere spelers in een chatroom te zitten en ze uit te nodigen voor een spel. In deze chatroom wordt er ook flink gepraat, en dat moet ook snel en prettig (weinig vertraging) werken.

Als je in een spel zit kan je ook met de andere speler praten en gasten kunnen ook joinen en praten natuurlijk.

Mogelijk wordt er ooit een spel aan toegevoegd, waar mogelijk moet ik hier rekening mee houden. Dan komen er extra chatrooms en een extra "ding" die het andere spel afhandelt.

Een chatserver schrijven is hoe dan ook triviaal.

Ik dacht als globaal ontwerp, 1 daemon die alle communicatie afhandelt en die elk bericht van een client doorstuurt naar een apparte functionele eenheid (thread/process ?). Deze functionele eenheid doet zijn ding en als die klaar is stuurt die indirect een bericht terug naar de goede clients .
De verwachtte belasting is zo groot (klein) dat het voorlopig prima mogelijk is in de meest extreme gevallen om alle spelgebeurtenissen op 1 server af te handelen en alle chat gedeeltes ook op 1 server. Dan heb je nog 1 server die de communicatie regelt naar en van alle clients dus in totaal 3 servers. Maar omdat het nu nog niet zo druk is, kan het nu nog allemaal op 1 server. Maar het hoeft niet zo te zijn dat je bv het chatgedeelte opzichzelf moet opdelen op 2 servers. Dus de schaalbaarheid komt overeen met het functioneel scheiden van de onderdelen. Dat is schaalbaar "genoeg" (voorlopig).

Ik snap niet hoe je op een dergelijke architectuur komt. Volgens mij heb je gewoon X gameservers waar 'games' op draaien. De flash client is dus verbonden met die game server, en die handelt gewoon de logica en communicatie af. Als je meer capaciteit nodig hebt kun je gewoon schalen door meer gameservers neer te zetten.

Je moet een dergelijk systeem paralleliseerbaar maken, en dat doe je niet door verschillende machines op mekaar te gaan laten zitten wachten. Ik zie niks in een apart systeem voor 'communicatie'. Hoe zie je dat voor je? Een foyer / chat server en dan X game servers werkt prima, als je componenten hebt die niet op mekaar gaan zitten wachten ben je vrijwel onbeperkt schaalbaar.

Dit is trouwens nog maar slechts een idee, er zal nog wel wat aan worden verandert.

Ik las over dat het makkelijk is om met [interessante java afkorting] makkelijk is om services en programmas te deplayen zodat je makelijk kan schalen etc. Heb ik dat misschien nodig als ik bijvoorbeeld mijn server gedeelte wil opdelen in 3 gedeeltes?

Euh, even m'n kristallen bol raadplegen:

het antwoord is: misschien.

Zo.

[Verwijderd]

Hydra schreef op donderdag 21 februari 2008 @ 18:19:
[...]

Probleem is dat ik niet weet hoe de belasting zal uitvallen dus ik weet ook niet hoe het op te delen. Ik zal het eerst moeten maken en testen waar de knelpunten zitten. Verder begrijp ik je post wel, ik moet zelf gewoon even in de documenten duiken. Ik kan verder ook niet echt goede vragen stellen als ik maar vaag weet waar ik het over heb. Ik weet nu dat ik heel goed java kan gebruiken en daar ging het mij vooral om .