[alg] botwar Bespreking *

[glrfndl]

Is er trouwens iemand die een goede, crossplatform library kent voor sockets?

gewoon java gebruiken

[MisterData]

jnijboer schreef op 28 november 2002 @ 08:58:
[...]

gewoon java gebruiken

Kan ik wel, en er is ook een JS-parser voor (Rhino, ook van Mozilla), maar c++ is sneller en ook portable mits je goede libs gebruikt

Ik vond het zowieso al niet zo'n lekker idee om in een taal die al in een VM draait nog maar es een VM te gaan draaien

[ Voor 19% gewijzigd door MisterData op 28-11-2002 09:06 ]

[El_Quedro]

goed...

ik kan niet alles constant volgen.. en het wordt mij een beetje warrig

[MisterData]

El_Quedro schreef op 28 November 2002 @ 09:24:
goed...

ik kan niet alles constant volgen.. en het wordt mij een beetje warrig

Nog maar even een samenvatting dan:
- Het wordt een tunrbased tankspel, en dmv sockets verbindt iedere bot met de server
- mietje heeft al code voor een eventuele server staan
- ik ben bezig met een wrapper waarmee je je bot kan coden in JavaScript en je je niet bezig hoeft te houden met socket gezeur enzo. Is vooral handig als je je puur wil concentreren op de logica van de bot en als je geen echte programmeertaal kent.

duidelijk zo?

[xychix]

MisterData schreef op 28 november 2002 @ 08:30:
[...]
Ik ben bezig met een progsel waarmee je je bot zelf in JavaScript kunt schrijven, en dan heb je geen ingewikkelde scripts nodig, hoef je ook niet met sockets te klooien

dat progsel word in c ?? kan ik dan de dat "progsel"ook inzien ?? ik wil mijn bot in c / C++ gaan bouwen...

hoe kun je dat progsel nou maken als je nog geen interface hebt ???

[ Voor 10% gewijzigd door xychix op 28-11-2002 10:23 ]

[wacco]

xychix: je moet ff hier kijken:
http://brick.bitpit.net/~marcelk/2002/icfp2002/main.c
das een inzending van iemand van die icfp2002 competitie (voor z'n pagina, knip main.c ff van de link af ) die heeft em volledig in c geprogd, met duidelijke functies voor sockets en spul. Moet je wel op weg helpen. En ik denk dat het ook linux portable is, want dat was volgens mij het idee van die compo.

[El_Quedro]

MisterData schreef op 28 november 2002 @ 10:20:
[...]


Nog maar even een samenvatting dan:
- Het wordt een tunrbased tankspel, en dmv sockets verbindt iedere bot met de server
- mietje heeft al code voor een eventuele server staan
- ik ben bezig met een wrapper waarmee je je bot kan coden in JavaScript en je je niet bezig hoeft te houden met socket gezeur enzo. Is vooral handig als je je puur wil concentreren op de logica van de bot en als je geen echte programmeertaal kent.

duidelijk zo?

Tnx men

[xychix]

wacco schreef op 28 November 2002 @ 10:58:
xychix: je moet ff hier kijken:
http://brick.bitpit.net/~marcelk/2002/icfp2002/main.c
das een inzending van iemand van die icfp2002 competitie (voor z'n pagina, knip main.c ff van de link af ) die heeft em volledig in c geprogd, met duidelijke functies voor sockets en spul. Moet je wel op weg helpen. En ik denk dat het ook linux portable is, want dat was volgens mij het idee van die compo.

ga ik eens bekijken.,.. (als ik tijd heb)

ik heb eerder hier ook een source gepost, TCP/IP connecties opzetten is het probleem niet. aleen de interface, welke commando's in xml/messenger style etc. daar doel ik op!

[wacco]

Mja, das dus nog niet duidelijk, lolbroek das de hele discussie.
Dat hangt namelijk af van hoe het spel exact gaat worden, en hoe het protocol er dan uit gaat zien. En dat laten we voorlopig even aan mietje over.

[MisterData]

xychix schreef op 28 november 2002 @ 10:23:
[...]

dat progsel word in c ?? kan ik dan de dat "progsel"ook inzien ?? ik wil mijn bot in c / C++ gaan bouwen...

Het 'progsel' zal waarschijnlijk open-source worden ja Maar je hebt er nix aan als je je bot in c/c++ wil schrijven, simpelweg omdat dit alleen maar een laag is tussen JavaScript en sockets.

hoe kun je dat progsel nou maken als je nog geen interface hebt ???

Omdat ik alleen een soort raamwerk maak, zodat je de logica van de bot in JavaScript kunt doen en niet hoeft te zeuren met sockets enzo.

[.oisyn]

MisterData: ik wil je verzoeken de editknop () vaker te gebruiken

[wacco]

misterdata is gewoon een beetje z'n gemiddelde posts per dag aan het boosten
alleen jammer dat ie dat zo nodig in dit draadje moet doen

mietje: je had al wat draaien? Kan je mij een tijdelijk ip/poort doormailen? Ik wil namelijk wat dingen experimenteren.
En je bent ook een beetje spooky bezig qua code, laat eens wat zien

[MisterData]

.oisyn schreef op 28 November 2002 @ 16:39:
MisterData: ik wil je verzoeken de editknop ([afbeelding]) vaker te gebruiken

Ik ga het proberen.

wacco schreef op 28 November 2002 @ 17:59:
misterdata is gewoon een beetje z'n gemiddelde posts per dag aan het boosten
alleen jammer dat ie dat zo nodig in dit draadje moet doen

posts genoeg hoor Kvin het niet echt een 'status' hebben ofzo....

mietje: je had al wat draaien? Kan je mij een tijdelijk ip/poort doormailen? Ik wil namelijk wat dingen experimenteren.
En je bent ook een beetje spooky bezig qua code, laat eens wat zien

Inderdaad, de laatste reactie van mietje was 1 pagina geleden

[wacco]

Die één pagina geleden komt gewoon omdat jij zoveel loopt te posten

[MisterData]

wacco schreef op 28 november 2002 @ 18:39:
Die één pagina geleden komt gewoon omdat jij zoveel loopt te posten

Ik post tenminste wat nuttige dingen _{achteraf gezien is dit toch een uitzondering}

[ Voor 12% gewijzigd door MisterData op 28-11-2002 18:46 ]

[Verwijderd]

Hehe relax, ik moet ook afentoe werken voor de kost

Ik heb niet veel nieuws te rapporteren, behalve dat ik de collision detection herschreven heb. Het blijkt dat ik de tijd van een collision toch exact moet berekenen (dat is duur), anders wordt het te onnauwkeurig.

Verder zal het nog wel ff duren voor de server helemaal af is, een weekje of 2 minimaal schat ik. Ik moet dat ding in de anvonduren en de weekends in elkaar zetten...

Ik heb wel nog een aanzetje voor jullie (vreemd dat daar nog niemand mee gekomen is): hoe lang moet een serverframe duren? Het maakt nogal een verschil of je 10x per seconde of 1x per seconde de kans krijgt om je tankje te besturen. (Ik praat hier dus over servertijd, dus hoe lang een speelbeurt in de "spelwereld" duurt, niet hoe lang een client erover mag nadenken.)

[wacco]

Mja, dat hangt ook weer van een hoop af.

Hoe groot is de maxbuffer? maxsnelheid? Eigenlijk alle waarden... zolang ze maar een beetje in evenwicht zijn.

offtopic:
wil er best over nadenken, maar eerst simpsons (bbc2)

[MisterData]

Verwijderd schreef op 28 November 2002 @ 18:53:
Hehe relax, ik moet ook afentoe werken voor de kost

Ik heb niet veel nieuws te rapporteren, behalve dat ik de collision detection herschreven heb. Het blijkt dat ik de tijd van een collision toch exact moet berekenen (dat is duur), anders wordt het te onnauwkeurig.

Verder zal het nog wel ff duren voor de server helemaal af is, een weekje of 2 minimaal schat ik. Ik moet dat ding in de anvonduren en de weekends in elkaar zetten...

Ik heb wel nog een aanzetje voor jullie (vreemd dat daar nog niemand mee gekomen is): hoe lang moet een serverframe duren? Het maakt nogal een verschil of je 10x per seconde of 1x per seconde de kans krijgt om je tankje te besturen. (Ik praat hier dus over servertijd, dus hoe lang een speelbeurt in de "spelwereld" duurt, niet hoe lang een client erover mag nadenken.)

Ik begrijp hieruit dat je nog wel even bezig bent met de server-logica zelf? Kun je alvast wat duidelijkheid geven over welke 'acties' een tank allemaal kent? Dan wil ik wel een protocol specificeren Ik ben toch bezig met een soort van client...

wacco schreef op 28 November 2002 @ 19:02:
Mja, dat hangt ook weer van een hoop af.

Hoe groot is de maxbuffer? maxsnelheid? Eigenlijk alle waarden... zolang ze maar een beetje in evenwicht zijn.

offtopic:
wil er best over nadenken, maar eerst simpsons (bbc2)

Als je het slim maakt dan zorg je dat dat protocol de waarden pas at-runtime doortstuurt naar de client. Zo kun je altijd nog wisselen van buffergrootte. Maw, het bepalen van de buffergroote en max snelheid is in dit stadium IMHO niet belangrijk

[wacco]

duh... maar de var die mietje suggeerde past in dit rijtje. Als je een stap zet, hoe lang duurt het dan weer (dus hoe ver ben je bijvoorbeeld doorgereden) tot je een nieuwe stap mag maken?

[MisterData]

wacco schreef op 28 November 2002 @ 19:25:
duh... maar de var die mietje suggeerde past in dit rijtje. Als je een stap zet, hoe lang duurt het dan weer (dus hoe ver ben je bijvoorbeeld doorgereden) tot je een nieuwe stap mag maken?

Zoals gezegd heb je te maken met een beperkte voorraad energie. Hoe meer energie, hoe verder je kan doorrijden. Je moet dus ook niet uitgaan van tijd (natuurlijk wel een limiet op de denktijd van de client), maar van energie. 10 pixels rijden kost een tank bijvoorbeeld 5 energiepunten. Pas als de client aangeeeft dat hij niet meer energie wil verbruiken/dat hij klaar is met z'n beurt dan is de volgende bot aan de beurt.

Je kan ook besluiten dat een client slechts 1 'beweeg'-commando mag gebruiken per beurt.

_{of blaat ik nu complete onzin uit?}

[ Voor 5% gewijzigd door MisterData op 28-11-2002 19:33 ]

[.oisyn]

Verwijderd schreef op 28 November 2002 @ 18:53:
Hehe relax, ik moet ook afentoe werken voor de kost

Ik heb niet veel nieuws te rapporteren, behalve dat ik de collision detection herschreven heb. Het blijkt dat ik de tijd van een collision toch exact moet berekenen (dat is duur), anders wordt het te onnauwkeurig.

als je interesses hebt in vormen van spatial partitioning die hiervoor goed zijn geef je maar een gil, dat soort topics zijn er te weinig op GoT imho

[TheOneLLama]

.oisyn schreef op 27 november 2002 @ 18:05:
[nohtml]
[...]
juist wel, wat voor extra nut heeft zo'n commando volgens jou? Zie bijvoorbeeld het voorbeeld van Soultaker. Als je de netwerkkabel eruit trekt treedt er een timeout op, zelfs zonder dat je data probeert te versturen of ontvangen, zo zit het TCP protocol nou eenmaal in elkaar. En dat kun je dus detecteren

Hoe kom je erbij dat er een timeout zou optreden als je de physieke link verbreek in een TCP/IP connectie (de stekker eruit dus) en geen data verstuurd?
Je kan rustig die stekker eruit trekken en em na 3 jaar weer erin doen, als je maar geen data hebt verstuurd doet ie het nog gewoon hoor.

Wat overigens niet wegneemt dat het voorgestelde protocol nogal raar is, en dat voor zover ik weet het MSN protocol behoorlijk anders is.

[MisterData]

TheOneLLama schreef op 28 november 2002 @ 20:42:
[...]


Hoe kom je erbij dat er een timeout zou optreden als je de physieke link verbreek in een TCP/IP connectie (de stekker eruit dus) en geen data verstuurd?
Je kan rustig die stekker eruit trekken en em na 3 jaar weer erin doen, als je maar geen data hebt verstuurd doet ie het nog gewoon hoor.

Wat overigens niet wegneemt dat het voorgestelde protocol nogal raar is, en dat voor zover ik weet het MSN protocol behoorlijk anders is.

I know, het MSN protocol werkt ook nog met trialid's enzo. Voorbeeldje:

code:

C: VER 1 MSNP5 MSNP4 MSNP3 CVRO
S: VER 1 MSNP5
C: INF 2
S: INF 2 MD5
c: USR 3 I [e-mail]
s: USR 3 S 3234234234.234234234
c: USR 3 S 23234e23f234ac700234aebc
s: USR 3 OK

Enzovoort..... Waar het mij om gaat, is dat het protocol gewoon als volgt is opgebouwd:

• Ieder commando een nieuwe regel
• Alle informatie per commando gescheiden met een spatie (makkelijk parsen met strtok() en dergelijke)

Het hoeft dus niet te lijken op het MSN protocol.... het moet alleen maar makkelijk te implementeren zijn.

Hieronder even een ideetje over hoe het protocol er ongeveer uit moet gaan zien:

code:

c
c BOT MisterData MijnBot1
s BOT OK
.....
s YOURTURN [energie] [aantal andere bots] [enz]
c MOVEFORWARD 10
c HEADING 90
c FIRE
c ENDTURN
.....
s DIE OtherUser OtherWeakBot
s JOIN AnotherUser AnotherBot
.....
c STAT
s STAT [botnaam #1] [botnaam #2]
....
s DEFEATED-BY OtherUser OtherUserBotName

Of iets dergelijks....

[ Voor 17% gewijzigd door MisterData op 28-11-2002 20:57 ]

[.oisyn]

[nohtml]

TheOneLLama schreef op 28 November 2002 @ 20:42:
[...]


Hoe kom je erbij dat er een timeout zou optreden als je de physieke link verbreek in een TCP/IP connectie (de stekker eruit dus) en geen data verstuurd?
Je kan rustig die stekker eruit trekken en em na 3 jaar weer erin doen, als je maar geen data hebt verstuurd doet ie het nog gewoon hoor.

uhm ja, je verstuurt toch data? Die OK is tenslotte een antwoord daarop (die dus niet nodig is, want de TCP implementatie zorgt ervoor dat er een ACK pakketje wordt verstuurd), en als je alleen wacht op data dan moet je een timeout mechanisme inbouwen

[TheOneLLama]

MisterData schreef op 28 November 2002 @ 20:51:
[...]

I know, het MSN protocol werkt ook nog met trialid's enzo. Voorbeeldje:

Bedoelde niet zozeer dat dat er trialid's of wat ook inzitten, meer dat het wat packet georienteerder is (tenminste, op basis van wat ik hier GoT gezien heb). Dus aantal bytes, dan de data. Een heel groot verschil in de implementatie natuurlijk

Enzovoort..... Waar het mij om gaat, is dat het protocol gewoon als volgt is opgebouwd:

• Ieder commando een nieuwe regel
• Alle informatie per commando gescheiden met een spatie (makkelijk parsen met strtok() en dergelijke)

Zet er gelijk ff bij welke bij welk type linefeed je wilt gebruiken en mogelijk ook welke encoding.

Het hoeft dus niet te lijken op het MSN protocol.... het moet alleen maar makkelijk te implementeren zijn.

Tja, wat is niet gemakkelijk te interpreteren? Dit protocol is al behoorlijk verbose, dus waarom niet gelijk XML?

Ik zou het zelf allemaal over Jabber heengooien, maar ja, dat ben ik dan weer

[TheOneLLama]

.oisyn schreef op 28 november 2002 @ 21:03:
[nohtml]
[...]
uhm ja, je verstuurt toch data? Die OK is tenslotte een antwoord daarop (die dus niet nodig is, want de TCP implementatie zorgt ervoor dat er een ACK pakketje wordt verstuurd), en als je alleen wacht op data dan moet je een timeout mechanisme inbouwen

Dat die OK voor de datatransport laag overbodig is ben ik met je eens (voor het protocol lijkt het me geen slecht idee overigens, dat het via TCP/IP aangekomen is wil nog niet zeggen dat de server het (correct) heeft verwerkt).

Het ging me meer om wat je zei:
Als je de netwerkkabel eruit trekt treedt er een timeout op, zelfs zonder dat je data probeert te versturen of ontvangen, zo zit het TCP protocol nou eenmaal in elkaar.

In welke context ik het ook plaats, het klopt gewoon niet

Het probleem in dit topic is natuurlijk bidirectionele data uitwisseling: als je niks hebt om te sturen en zit alleen maar te wachten op data van de server, hoe weet je dan of de verbinding er nog is? Jou tekst wekt de suggestie dat TCP/IP dat netjes aan je gaat melden (wat dus niet zo is).

Zeker in deze situatie is dat nogal een probleem, stel dat een speler aan de beurt is en verbinding kwijtraakt, de spelers client detecteerd het (die heeft immers data te versturen) maar de server denkt alleen: wat doet die gast lang over z'n beurt! De andere spelers denken: zou ie verbinding kwijt zijn? of zou ik verbinding kwijt zijn?(heb immers niks te versturen) of is ie gewoon traag?

Buiten dit probleem vind ik het nogal een wazig protocol omdat buiten de transport laag nogal wazig is, state-based, beetje asynchroon en dat zonder confirmaties van je acties. Behalve bij het inloggen, en dan is het ook niet a-synchroon en is er wel een confirmatie

[wacco]

Géén xml. Harstikke zinloos, al die <info> tags. Worden er toch alleen maar uitgemikt door iedereen. Zeg nou zelf:

<fire>100,200</fire> (of hoe je het er ook uit wilt laten zien)
of
FIRE 100:200

Scheelt een _hoop_ coden, en dat hebben we nou net nodig.

[cobratbq]

Het is dus duidelijk dat het nog wel even duurt eer dat de server helemaal klaar is. Kunnen we niet alvast een soort van taakverdeling maken voor de kleinere klusjes?
We moeten eigenlijk alvast gaan brainstormen over welke functies we allemaal in gaan bouwen. Dan kunnen wij met een paar man al vast wat kleine functies gaan schrijven.
Want als we 2 weken moeten wachten, ben ik bang dat er al een aantal mensen afvallen.

Als we een opsomming maken van alle bruikbare functies, dan kunnen we misschien iets regelen...

[wacco]

Mja, ik ben ook niet helemaal blij dat we een beetje zitten te wachten... zoveel werk is een server proggen toch niet? Kunnen we niet gewoon eens een protocol uitdenken (met z'n allen)? En functies, zoals cobratbq al zei.

[TheOneLLama]

wacco schreef op 28 november 2002 @ 21:45:
Géén xml. Harstikke zinloos, al die <info> tags. Worden er toch alleen maar uitgemikt door iedereen. Zeg nou zelf:

<fire>100,200</fire> (of hoe je het er ook uit wilt laten zien)
of
FIRE 100:200

Scheelt een _hoop_ coden, en dat hebben we nou net nodig.

Ik zeg toch ook niet dat je je eigen XML parser moet maken???
NOFI, maar dat je <fire>100,200</fire> neerzet geeft al aan hoe weinig kaas je van XML gegeten hebt.

Je code wordt alleen maar kleiner hoor, vooral als je slim gebruikt maakt van beschikbare tools. Voor zo'n wedstrijdje heb je misschien niet alles nodig zoals gestructureerde data etc. maar zou je zoiets als dit programmatje wat verder gaan uitbreiden kom je al in de problemen. Aangezien het voorgestelde protocol toch al vrij verbose is en kennelijk gemak voorop staat zou XML totaal geen onlogische keuze zijn, voor degene die het kunnen niet in ieder geval. Voor de mensen als jou, die er geen (genoeg) ervaring mee hebben zou het vrij leerzaam zijn natuurlijk. Maar misschien is dat weer een te grote achterstand om mee te beginnen. Het is in in ieder geval niet meer coden.

[MisterData]

TheOneLLama schreef op 28 November 2002 @ 21:17:
[...]


Bedoelde niet zozeer dat dat er trialid's of wat ook inzitten, meer dat het wat packet georienteerder is (tenminste, op basis van wat ik hier GoT gezien heb). Dus aantal bytes, dan de data. Een heel groot verschil in de implementatie natuurlijk

OK, ik snap wat je bedoeld.

[...]


Zet er gelijk ff bij welke bij welk type linefeed je wilt gebruiken en mogelijk ook welke encoding.

Mij lijkt als linefeed \r\n gewoon het handigst. Encoding: UTF-8?

[...]

Tja, wat is niet gemakkelijk te interpreteren? Dit protocol is al behoorlijk verbose, dus waarom niet gelijk XML?

Ik zou het zelf allemaal over Jabber heengooien, maar ja, dat ben ik dan weer

XML is IMHO nog veel werk. Als ik met SAX een XML-doccie wil parsen dan ben ik al 20 regels code verder in Java. Met strtok ben je zo klaar

[MisterData]

cobratbq schreef op 28 november 2002 @ 22:08:
Het is dus duidelijk dat het nog wel even duurt eer dat de server helemaal klaar is. Kunnen we niet alvast een soort van taakverdeling maken voor de kleinere klusjes?
We moeten eigenlijk alvast gaan brainstormen over welke functies we allemaal in gaan bouwen. Dan kunnen wij met een paar man al vast wat kleine functies gaan schrijven.
Want als we 2 weken moeten wachten, ben ik bang dat er al een aantal mensen afvallen.

Als we een opsomming maken van alle bruikbare functies, dan kunnen we misschien iets regelen...

Goed idee. Even een lijstje wie wat aan het doen is:

Wie doet wat?
mietje	server schrijven
MisterData	JS-wrapper
...	Protocol verzinnen
...	grafische spectator client?

Ik stel voor dat we het lijstje hierboven steeds bijwerken, dan hebben we alles op 1 plek

[cobratbq]

En we moeten een lijstje maken met alle functies van de tank erin.
Zodat degene die het protocol verzint met onverwachte dingen rekening kan houden.

[.oisyn]

[nohtml]

TheOneLLama schreef op 28 November 2002 @ 21:41:
In welke context ik het ook plaats, het klopt gewoon niet

daar heb je helemaal gelijk in!

MisterData schreef op 28 november 2002 @ 22:24:
[...]


Goed idee. Even een lijstje wie wat aan het doen is:

Wie doet wat?
mietje	server schrijven
MisterData	JS-wrapper
...	Protocol verzinnen
...	grafische spectator client?

Ik stel voor dat we het lijstje hierboven steeds bijwerken, dan hebben we alles op 1 plek

ik wil de grafische spectator wel doen (3d ), maar tot aan de kerstvakantie heb ik er iig geen tijd voor... dus het ligt er een beetje aan wanneer de server af is enzo

[ Voor 67% gewijzigd door .oisyn op 28-11-2002 22:47 ]

[wacco]

Ik weet het, m'n xml skillz zijn knudde
En verder stel ik voor om gewoon te breaken op \n. Das wel zo makkelijk. Namelijk maar één character. Dan kan je gewoon buffer vullen, en dan uitlezen, breaken op die chars en dan bekijken wat je aan info binnengehaald heb.

[TheOneLLama]

MisterData schreef op 28 november 2002 @ 22:18:
Mij lijkt als linefeed \r\n gewoon het handigst. Encoding: UTF-8?

Klinkt goed

XML is IMHO nog veel werk. Als ik met SAX een XML-doccie wil parsen dan ben ik al 20 regels code verder in Java. Met strtok ben je zo klaar

Nou ja, ik hou het er maar op dat als ik zo'n soort opdracht moet doen ik op het einde minder of evenveel code overhou Maar misschien is het om een zo breed mogelijk publiek aan te spreken dan maar beter geen XML te gebruiken..

[Creepy]

TheOneLLama schreef op 28 november 2002 @ 22:16:
[...]
Ik zeg toch ook niet dat je je eigen XML parser moet maken???
NOFI, maar dat je <fire>100,200</fire> neerzet geeft al aan hoe weinig kaas je van XML gegeten hebt.

Je code wordt alleen maar kleiner hoor, vooral als je slim gebruikt maakt van beschikbare tools. Voor zo'n wedstrijdje heb je misschien niet alles nodig zoals gestructureerde data etc. maar zou je zoiets als dit programmatje wat verder gaan uitbreiden kom je al in de problemen. Aangezien het voorgestelde protocol toch al vrij verbose is en kennelijk gemak voorop staat zou XML totaal geen onlogische keuze zijn, voor degene die het kunnen niet in ieder geval. Voor de mensen als jou, die er geen (genoeg) ervaring mee hebben zou het vrij leerzaam zijn natuurlijk. Maar misschien is dat weer een te grote achterstand om mee te beginnen. Het is in in ieder geval niet meer coden.

Het gaat hier om vrij simpele communicatie tussen een server en een client. Een paar strings parsen is een stuk makkelijker en sneller dan een XML document.

Je eigen source code word er misschien kleiner door (wat ik overigens ook betwijfel), omdat je gebruik maakt van reeds bestaande dingen om de XML uit te lezen, maar je executable zal er groter en (relatief) trager door worden.

Waarom zou je voor zoiets al dit XML gaan gebruiken? Mij ontgaat het "voordeell" van XML in dit geval me totaal!

[ Voor 3% gewijzigd door Creepy op 28-11-2002 23:15 ]

[TheOneLLama]

Creepy schreef op 28 november 2002 @ 23:14:
[...]
Het gaat hier om vrij simpele communicatie tussen een server en een client. Een paar strings parsen is een stuk makkelijker en sneller dan een XML document.

Je eigen source code word er misschien kleiner door (wat ik overigens ook betwijfel), omdat je gebruik maakt van reeds bestaande dingen om de XML uit te lezen, maar je executable zal er groter en (relatief) trager door worden.

Waarom zou je voor zoiets al dit XML gaan gebruiken? Mij ontgaat het "voordeell" van XML in dit geval me totaal!

Omdat ik de situatie omdraai misschien:
Je hebt een protocol uitermate geschikt voor bv. dit soort simpele data uitwisseling, met genoeg flexibiliteit om alles te realiseren wat je wilt voor dit spel, met relatief gezien ongeveer dezelfde overhead als iets als een hier voorgesteld protocol, met een eindeloos aantal tools en libraries.

Waarom dan nog de moeite doen om voor ieder programmatje wat je gaat schrijven je eigen ad-hoc protocol inelkaar flansen? Of je er nou 10 regels code meer of minder mee krijgt maakt me niet eens uit. Of dat je executable 100kb groter of kleiner wordt.

Ik denk dat niemand echt hard kan maken dan XML niet geschikt is voor dit soort werk. Maar dat het als je niet gewent bent ermee te werken een drempel kan zijn zal ik niet ontkennen.

[Soultaker]

MisterData schreef op 28 november 2002 @ 08:37:
Is er trouwens iemand die een goede, crossplatform library kent voor sockets? Ik heb tot nu toe altijd gewerkt met JNetLib van Nullsoft en met wxWindows maar de eerste is een beetje brak (kan niet met proxyservers overweg enzo) en de tweede is te groot vrees ik... iemand een goed alternatief?

In principe was GNet wel een aardig initiatief, maar ik geloof dat er niet heel actief aan ontwikkelt wordt momenteel. De huidige features zijn waarschijnlijk wel goed genoeg voor het doel waarvoor het nu gebruikt moet worden. Het is in ieder geval beter dan aparte code schrijven voor *nix en Windows (wat de twee variaties zijn waar je in de praktijk rekening mee moet houden).

[Soultaker]

TheOneLLama schreef op 28 November 2002 @ 23:49:
Ik denk dat niemand echt hard kan maken dan XML niet geschikt is voor dit soort werk. Maar dat het als je niet gewent bent ermee te werken een drempel kan zijn zal ik niet ontkennen.

Daar snijd je de kern van de zaak aan. XML leren beheersen is niet eenvoudig (hoe vaak je ook zegt dat XML eenvoudig is; het principe is dat wel, maar de libraries, standaard-API's en verschijningsvormen zijn dat niet). Daarbij elimineer je met XML uitsluitend de gegevensoverdracht, die in dit geval heel simpel is.

Door XML als formaat voor gegevensoverdracht te gebruiken, heb je nog geen protocol gedefinieerd. Daarvan kun je wel een deel vastleggen in een DTD, maar dat betekent niet dat het protocol op zichzelf verzonnen moet worden en door alle deelnemers moet worden bekeken.

Hoewel XML een mooie techniek is, lost het hier dus geen fundamentele problemen op. De gegevens die heen en weer gestuurd worden zijn simpele getallen en tekenreeksen waarvan eenvoudig geëist kan worden dat ze (onder andere) geen spaties of newlines mogen bevatten. Ook is er hier geen sprake van een hiërarchisch gestructureerd datatype, dat met XML uitstekend te beschrijven is.

Vanwege mijn ervaring met CORBA, zou ik kunnen aandragen dat dit een nog meer geschikte basis is voor de communicatie, omdat alle communicatie over sockets overbodig gemaakt wordt. Voor een enigszins ervaren programmeur is dit zeker waar en is het ontwikkelen van een CORBA server naar aanleiding van een gegeven interface definitie zeker makkelijker dan het ontwikkelen van een systeem op basis van een op tekst of XML gebaseerd protocol over TCP sockets, maar ik kan niet redelijkerwijs verwachten dat alle potentiële deelnemers in staat zijn om CORBA servers te schrijven (ondanks de grote portabiliteit, maar simpelweg door het gebrek aan parate kennis) of bereid zijn om zich in die materie te verdiepen.

Mijn punt is dus, dat het beheersen van XML min of meer net zo veel tijd kost als het beheersen van CORBA: allebei ruimschoots meer dan nodig is voor het schrijven van een simpele applicatie op basis van een op tekst gebaseerd protocol. Dit is technisch gezien wellicht niet de beste oplossing, maar gezien de ervaring van de deelnemers en de doelstelling van de wedstrijd wel de meest geschikte. Naar mijn mening, dus.

_{Disclaimer: ik verplicht mij met dit bericht niet tot deelname!}

[.oisyn]

Soultaker: dus je doet mee?

Maar even serieus, we kunnen lang en breed discussieren over hoe de data getransporteerd wordt (plain text, XML, binary, ...), maar dat doet er op het moment nog weinig toe... Eerst maar eens specificeren WAT er verstuurd moet worden. Dat het makkelijk moet zijn hoeft in principe ook nog niet eens. Mensen zouden bijvoorbeeld een algemene interface kunnen maken voor verschillende talen, en anderen die minder verstand hebben van sockets/whatever kunnen die interface weer gebruiken. Een soort van client framework dus zeg maar. En dan het is natuurlijk niet verplicht om zo'n framework te gebruiken voor de taal waarin jij je bot wilt maken, als je zelf je protocol afhandeling wilt doen mag dat natuurlijk ook. Maar op die manier creeer je wel een mogelijkheid voor mensen die minder verstand hebben van het op een bepaalde manier communiceren (of dit nou via CORBA, COM of gewoon socket communicatie is) om toch mee te doen

[xychix]

TheOneLLama schreef op 28 november 2002 @ 23:49:
[...]


Omdat ik de situatie omdraai misschien:
Je hebt een protocol uitermate geschikt voor bv. dit soort simpele data uitwisseling, met genoeg flexibiliteit om alles te realiseren wat je wilt voor dit spel, met relatief gezien ongeveer dezelfde overhead als iets als een hier voorgesteld protocol, met een eindeloos aantal tools en libraries.

Waarom dan nog de moeite doen om voor ieder programmatje wat je gaat schrijven je eigen ad-hoc protocol inelkaar flansen? Of je er nou 10 regels code meer of minder mee krijgt maakt me niet eens uit. Of dat je executable 100kb groter of kleiner wordt.

Ik denk dat niemand echt hard kan maken dan XML niet geschikt is voor dit soort werk. Maar dat het als je niet gewent bent ermee te werken een drempel kan zijn zal ik niet ontkennen.

Ik ben ook VOOR xml ! al is het alleen al ivm de beschikbare tools (die ik overigens nog nooit gebruikt heb... ik doe het vaak met een eigen functie ik heb gewoon nog nooit uitgezocht hoe die tools werken.

Met xml weet je gewoon hoe de opmaak van het proocol is, bij andere methodes ben je altijd afhankelijk van onderling afgesproken scheidingstekens ed.

een XML conversatie kun je een willekeurige persoon (*met een beetje IT capaciteiten) voorleggen en hij zal het snappen, bij een eigen oplossing zul je heb eerst ui moeten leggen wat wat is !

Xml = zeer makkelijk te loggen (omdat alle tools er al zijn)

[Creepy]

TheOneLLama schreef op 28 November 2002 @ 23:49:
[...]


Omdat ik de situatie omdraai misschien:
Je hebt een protocol uitermate geschikt voor bv. dit soort simpele data uitwisseling, met genoeg flexibiliteit om alles te realiseren wat je wilt voor dit spel, met relatief gezien ongeveer dezelfde overhead als iets als een hier voorgesteld protocol, met een eindeloos aantal tools en libraries.

Waarom dan nog de moeite doen om voor ieder programmatje wat je gaat schrijven je eigen ad-hoc protocol inelkaar flansen? Of je er nou 10 regels code meer of minder mee krijgt maakt me niet eens uit. Of dat je executable 100kb groter of kleiner wordt.
[...]
Ik denk dat niemand echt hard kan maken dan XML niet geschikt is voor dit soort werk. Maar dat het als je niet gewent bent ermee te werken een drempel kan zijn zal ik niet ontkennen.

Ik zeg ook niet dat het er niet voor geschikt is, ik denk alleen dat het overkill is.
Het idee begon als een "simpel" tank spel. Nu word er al gesproken over communicatie met XML en word er geprobeerd de ene na de andere mooie feature in het spel te stoppen.

Drie jaar terug hoorde je nagenoeg NIEMAND over XML. Tegenwoordig als het over opslag en communicatie van data gaat wordt er ontzettend snel geroepen XML en word er verder niet nagedacht over andere alternatieven (die nog best wel eens geschikter zouden kunnen zijn dan XML). XML is in, cool, new etc. en word naar mijn idee teveel gezien als DE oplossing. Met al die mooi tools lijkt het ook nog eens simpeler dan bijv het verzenden van 1 regel text. LIJKT simpeler, want als je het echt gaat implementeren zal blijken dat het net niet zo simpel is als dat het lijkt.

Ik ben dagelijks voor mijn werk met XML bezig... dus een drempel is het voor mij niet.

[Creepy]

xychix schreef op 29 November 2002 @ 06:39:
[...]
Met xml weet je gewoon hoe de opmaak van het proocol is, bij andere methodes ben je altijd afhankelijk van onderling afgesproken scheidingstekens ed.

Gaat het alleen om de scheidings tekens?? Want het protocol moet zoals ik hier boven ook al heb verteld nog gewoon bedacht worden.

een XML conversatie kun je een willekeurige persoon (*met een beetje IT capaciteiten) voorleggen en hij zal het snappen, bij een eigen oplossing zul je heb eerst ui moeten leggen wat wat is !

Je zult nog steeds het protocol moeten uitleggen. En dat moet met simpele strings ook. Als iemand met een beetje IT capaciteiten richting de programmeerkant geen strings kan parsen, dan kan deze persoon beter UIT de IT gaan, of het erg snel leren.

Xml = zeer makkelijk te loggen (omdat alle tools er al zijn)

Als je communicatie met simpele regels tekst doet, kan je die strings zonder enige bewerking loggen. Je XML zal je om moeten zetten naar een iets beter te loggen formaat.

[ Voor 3% gewijzigd door Creepy op 29-11-2002 08:32 ]

[MisterData]

.oisyn schreef op 29 November 2002 @ 02:17:
Soultaker: dus je doet mee?

Maar even serieus, we kunnen lang en breed discussieren over hoe de data getransporteerd wordt (plain text, XML, binary, ...), maar dat doet er op het moment nog weinig toe... Eerst maar eens specificeren WAT er verstuurd moet worden.

Daarvoor moeten we dus op mietje wachten.

Dat het makkelijk moet zijn hoeft in principe ook nog niet eens. Mensen zouden bijvoorbeeld een algemene interface kunnen maken voor verschillende talen, en anderen die minder verstand hebben van sockets/whatever kunnen die interface weer gebruiken. Een soort van client framework dus zeg maar. En dan het is natuurlijk niet verplicht om zo'n framework te gebruiken voor de taal waarin jij je bot wilt maken, als je zelf je protocol afhandeling wilt doen mag dat natuurlijk ook. Maar op die manier creeer je wel een mogelijkheid voor mensen die minder verstand hebben van het op een bepaalde manier communiceren (of dit nou via CORBA, COM of gewoon socket communicatie is) om toch mee te doen

Een paar posts terug heb ik gezegd dat ik bezig ben met een JavaScript-framework, dus de logica kan ik JavaScript en de socket-zut handelt mijn framework af CORBA en COM ben ik zelf niet zo'n voorstander van, vraag me niet waarom. Ik denk zelfs dat er veel mensen hier in de P&W zijn die niet eens weten wat COM/CORBA inhoudt.

[MisterData]

Soultaker schreef op 29 November 2002 @ 01:55:
[...]

In principe was GNet wel een aardig initiatief, maar ik geloof dat er niet heel actief aan ontwikkelt wordt momenteel. De huidige features zijn waarschijnlijk wel goed genoeg voor het doel waarvoor het nu gebruikt moet worden. Het is in ieder geval beter dan aparte code schrijven voor *nix en Windows (wat de twee variaties zijn waar je in de praktijk rekening mee moet houden).

Hmm, ik ga denk ik gewoon JNetLib gebruiken (www.nullsoft.com) dat schijnt ook onder Linux te werken. Eerst maar es de discussie hierboven afwachten

[xychix]

Ergens moet je ook gewoon met de tijd meegaan

oud = fixed length velden (mainframe COBOL85 data verwerking)
Comma-seperated = de C tijd...
XML = nu C/C++ Java etc.

de 2 oudere methoden werken ook nog perfect, ik zeg dus niet dat xml de eeuwige oplossing is. et is nu net zo mooi en goed als separated data (dus met een ; of een , ) destijds was !

[TheOneLLama]

Soultaker:

[...]

Daar snijd je de kern van de zaak aan. XML leren beheersen is niet eenvoudig (hoe vaak je ook zegt dat XML eenvoudig is; het principe is dat wel, maar de libraries, standaard-API's en verschijningsvormen zijn dat niet). Daarbij elimineer je met XML uitsluitend de gegevensoverdracht, die in dit geval heel simpel is.

Werken met XML, als je het eenmaal kan, is echt vrij simpel. En zo moeilijk is het nou ook niet om te leren. Dat vind ik dan in ieder geval

Door XML als formaat voor gegevensoverdracht te gebruiken, heb je nog geen protocol gedefinieerd. Daarvan kun je wel een deel vastleggen in een DTD, maar dat betekent niet dat het protocol op zichzelf verzonnen moet worden en door alle deelnemers moet worden bekeken.

Ook als je ervoor kiest om met komma's whatever te werken moet je natuurlijk nog een protocol verzinnen. XML is het transport protocol. Met XML weet je zeker dat je transport protocol flexibel genoeg is om er alles mee te kunnen, en dat het toch simpel blijft om mee te werken, te debuggen, etc.

Hoewel XML een mooie techniek is, lost het hier dus geen fundamentele problemen op. De gegevens die heen en weer gestuurd worden zijn simpele getallen en tekenreeksen waarvan eenvoudig geëist kan worden dat ze (onder andere) geen spaties of newlines mogen bevatten. Ook is er hier geen sprake van een hiërarchisch gestructureerd datatype, dat met XML uitstekend te beschrijven is.

Natuurlijk los je met XML fundamentele problemen op! Nee niet al je fundamentele problemen. De enige taal die ik ken die dat kan is JehovaScript.

Om in dit geval nog voordat de basis van de server af is en functionaliteit goed en wel gedefineerd is te gaan eisen dat er geen newlines, spaties etc. mogen voorkomen vind ik nou juist het rare.

..knip..

Mijn punt is dus, dat het beheersen van XML min of meer net zo veel tijd kost als het beheersen van CORBA: allebei ruimschoots meer dan nodig is voor het schrijven van een simpele applicatie op basis van een op tekst gebaseerd protocol. Dit is technisch gezien wellicht niet de beste oplossing, maar gezien de ervaring van de deelnemers en de doelstelling van de wedstrijd wel de meest geschikte. Naar mijn mening, dus.

Zoals ik al zei, wat mij betreft hoeft er hier geen XML gebruikt te worden. Maar alleen omdat het de drempel verlaagt voor wie mee wil doen. Niet omdat je met XML langer bezig zou zijn, het veel meer code zou kosten, het onnodig is voor een project als dit (stel dat dit geen wedstrijdje zou zijn maar een applicatie binnen een bedrijf).

Ik ben overigens wel van mening dat de drempel voor XML net wat lager is, en dat CORBA alsnog wat minder support heeft onder de verschilldende talen en platformen. Wat dat betreft kun je CORBA leren meer vergelijken met XML-RPC of SOAP leren lijkt mij.

xychix:

Ik ben ook VOOR xml ! al is het alleen al ivm de beschikbare tools (die ik overigens nog nooit gebruikt heb... ik doe het vaak met een eigen functie ik heb gewoon nog nooit uitgezocht hoe die tools werken.

Bedoel je dat je je hele eigen XML parser geschreven hebt? benieuwd aan hoeveel % van de XML standaard ie voldoet dan

Met xml weet je gewoon hoe de opmaak van het proocol is, bij andere methodes ben je altijd afhankelijk van onderling afgesproken scheidingstekens ed.
een XML conversatie kun je een willekeurige persoon (*met een beetje IT capaciteiten) voorleggen en hij zal het snappen, bij een eigen oplossing zul je heb eerst ui moeten leggen wat wat is !

Precies, dat is het fundamentele probleem wat XML (ook in dit geval) oplost

Creepy

Ik zeg ook niet dat het er niet voor geschikt is, ik denk alleen dat het overkill is.
Het idee begon als een "simpel" tank spel. Nu word er al gesproken over communicatie met XML en word er geprobeerd de ene na de andere mooie feature in het spel te stoppen.

Met XML hoef je je in ieder geval geen zorgen te maken dat welke feature je ook wilt een aanpassing van je transport protocol betekend. Je zou jezelf moet vragen, is er een reden om niet XML te gebruiken? (kost het teveel tijd? is het te langzaam? is het te moeilijk? limieteerd het je mogelijkheden?) Ik zou zeggen nee, maar ik ben niet de enige hier, er zijn ook mensen voor wie XML wel een drempel is (of het kennelijk niet eens zijn) dus helaas voor diegene die het in XML wouden dan.

Drie jaar terug hoorde je nagenoeg NIEMAND over XML.

Dat valt wel mee. Op GoT zou het wel wat minder vaak zijn voorgekomen ja. Wel hoor je nu eindeloos veel meer mensen over XML.

Tegenwoordig als het over opslag en communicatie van data gaat wordt er ontzettend snel geroepen XML en word er verder niet nagedacht over andere alternatieven (die nog best wel eens geschikter zouden kunnen zijn dan XML). XML is in, cool, new etc. en word naar mijn idee teveel gezien als DE oplossing.

Tja, als ik dingen hoor als iemand die een PHP script aanroept, de boel naar XML converteerd, dan met een ander PHP script weer terugconverteren en in MySQL stoppen...
Van mij hoef je echt niet overal XML te gebruiken..

Met al die mooi tools lijkt het ook nog eens simpeler dan bijv het verzenden van 1 regel text. LIJKT simpeler, want als je het echt gaat implementeren zal blijken dat het net niet zo simpel is als dat het lijkt.

Het gaat in dit geval niet om het sturen van een regel tekst. Ik zie in de voorgestelde structuur gelijk enkele dingen die je mogelijkheden beperken of het implementeren lastiger zouden maken (gegroepeerde data bv).

Het is echt maar goed dat het hier om een eenmalig wedstrijdje met net toevallig deze specificaties gaat waar verder nooit een uitbreiding op komt. Voor het leerzaamheids aspect zou je natuurlijk alsnog XML kunnen gebruiken, maar dat geeft de mensen met ervaring misschien een voorsprong.

[CyeZ]

xychix schreef op 29 november 2002 @ 08:56:
oud = fixed length velden (mainframe COBOL85 data verwerking)
Comma-seperated = de C tijd...
XML = nu C/C++ Java etc.

Lijkt me dus een goede reden om GEEN XML te gebruiken. Voor C++ en Java zijn er inmiddels wel XML libraries, voor oudere talen vaak niet.
Verder is het natuurlijk gigantische overkill om voor zoiets simpels xml te gaan versturen. Het is
- meer data om te versturen
- lastiger en langzamer om te parsen

Een simpel textformaat als:

code:

c: move up
c: fire
c: scan
s: enemy +2 -1
s: obstacle +1 +1

is voor zo iets goed genoeg, niet lastig te implementeren als je geen xml library ter beschikking hebt en het zorgt ook nog eens voor minder netwerk verkeer.
Verder is natuurlijk zowiezo de hele discussie over xml/plaintext/random ander formaat nogal nutteloos zolang niet besloten is WAT in het protocol beschreven moet worden.

Het handigste is als we gewoon rustig afwachten waar mietje mee komt. En verder gewoon de hele xml/textfile laten rusten voorlopig.

[Verwijderd]

Hoi hoi.. Ik lees hier iets over Server/Client spel waarmee je je bot kan programmeren... ffkes wat vraagjes

1. Is er al een website over?
2. Misschien enige info al over de interface (Server Client)?
3. Kan ik misschien helpen (Ben zelf Perl/Delphu guru en C/C++ kan ik ook wel)

Mijn mail is: te zien in mijn profile

[ Voor 7% gewijzigd door Verwijderd op 29-11-2002 11:51 ]

[wacco]

Ik ben extreem tegen XML. Ik heb geen zin om een hele meuk code in c te moeten proggen (of er nou functies en libs voor zijn of niet, ik moet ze nog steeds aanroepen) omdat het er alleen maar een beetje leesbaar uit moet zien. We hebben het hier over een enorm simpel spelletje mensen! Zoiets als het volgende werkt perfect:

- onderdelen worden gescheiden door een spatie
- einde regel is een \n.
- alles wordt doorgegeven als chars, dus een 0 in m'n verhaal is eigenlijk iets van char(66) (never mind het nummertje, weet ik niet uit m'n hoofd)

En dan:
- d'r zijn een paar vaste commando's, die bevestigd worden met de waarden.
FIRE waarde1 waarde2 //1 is kracht, 2 is schild/move
MOVE waarde1 waarde2 //1 is richting, 2 is energie (snelheid)
TURN waarde1 //turret draaien, misschien nog waarde2 als we afspreken dat het energie kost
MINE
SCAN waarde1 //hoeveel energie naar scan, dus hoe ver
INFO //vraag om aditionele info, ga ik zometeen op in
- deze worden bevestigd met: (zelfde volgorde)
FIRE AWAY óf FIRE FAIL waarde //waarde is error-getal (1: te weinig energie beschikbaar, 2: moet ik nog bedenken, net zoals 3,4, etc)
MOVE waarde1 waarde2 //waardes zijn nieuwe positie, als ze niet gewijzigd zijn van waar je was is er waarschijnlijk wat anders aan de hand, maar dat krijg je dan straks te horen (info... heb geduld)
TURN DONE óf TURN FAIL (als energie te weinig, als het energie kost...)
MINE AWAY waarde1 óf MINE FAIL //waarde1 is aantal mijnen nog over, fail als dat dus al nul was.
SCAN waarde1 waarde2 waardenachterelkaar * n //1 en 2 zijn x en y van een vierkant, en dat zijn de uiterste boundaries van je scan. Je krijgt maar van een cirkel, dus alle 'loze' ruimte in het vierkant (buiten de cirkel dus) wordt als een 0 doorgegeven. Verder 1 is gladde grond, 2 is ruwe grond, 3 is tank, 4 is mijn (als je die ziet... do ya see those?) 5 is etc etc). Dan krijg je dus in lange strings je veld door. Like: 11122111<spatie>11222211 en dat is dan van links naar rechts, rij voor rij.
INFO wordt opgeroepen als de AI klaar is met z'n zetten en graag de additionele info wilt, en dat zijn dan z'n eigen vars. Bijvoorbeeld, er is een explosie geweest. Dan is z'n schild afgezwakt en ziet ie dat doordat die var minder is geworden. De server geeft een WAIT als nog niet iedereen z'n beurt heeft gemaakt, en de waarden nog niet bekend zijn. Je bot moet dan gewoon bljiven luisteren totdat hij alsnog het volgende binnenkrijgt:
INFO botnaam posx posy schild buffer snelheid richtingxbeweging richtingybeweging turretrichting (en desnoods nog een paar die ik nu vergeet)
Je kan ook in plaats van een INFO een DIED krijgen, dan ben je dus history. (met eventueel nog extra vars die je vertellen hóe je eraan ging, who am I to deside) De verbinding met de server wordt dan ook gekickt, of als er nog een ronde gespeeld gaat worden krijg je een re-connect (zie verderop)

De infotag krijg je als het jou beurt is. Dus na de infotag kan je meteen weer jou zetten doen. Voor de infotag moet je dus wachten, en kunnen andere bots hun actie ondernemen.

Dan is er voor spectators die alleen maar info krijgen het volgende:
alle botnaam infostrings, en dan ook nog de extra strings:
NEW MINE waarde1 waarde2 id //mijn wordt geplaatst op x,y, wordt later naar verwezen via id
NEW FIRE waardex waardey waarde3 waarde4 id //er wordt iets afgevuurd, vanaf x,y met kracht en schildwaarden (zie FIRE commando), id is weer voor later
DIE id //fire, of mijn gaat af en is history
BOT DIES //bevestiging dat bot eruit gekickt wordt, spectator had dat zelf ook al kunnen afleiden uit voorgaande commando's, maar better safe than sorry

Tot slot, de connect en re-connect (het eerste aan het eind ):
Server neemt alle connecties aan, en dan wil die van client iets horen. Dat is:
CONNECT botnaam //botnaam is voor de stats, moet van te voren via GoT duidelijk zijn gemaakt bij de organisators, zodat ze jou bot herkennen. Gewoon in het topic melden dus, en ff bevestigd krijgen in hetzelfde topic.
Server schopt dan volgende terug:
OK óf de verbinding wordt gekickt als het een onzinconnectie (portscanner, whatever) is.
Bij OK moet je je programma gaan laten luisteren naar het kanaal. Op een gegeven moment zal de server een game starten, met bijvoorbeeld een paar geconnecte bots.
Als het wachten langer blijkt te duren dan verwacht, kan er een PING PONG event door de server worden afgevuurd. Je krijgt dan PING binnen, en wordt geacht PONG te zeggen, om vervolgens weer lekker te blijven luisteren.
GAME jouxwaarde jouywaarde waardex waardey stings * n //game wordt gestart. Eerste twee vars vertellen waar je begint in het veld, de andere vars werken hetzelfde als het scan command, en geven je een eerste look van je nieuwe wereld om je heen, zodat je wat te bestuderen hebt totdat je je INFO string krijgt en wat mag gaan doen.

Het veld van het spel is vast, zodat je aan het begin van je bot een array kan maken waarin het veld altijd past. (dit kan dynamisch, maar wordt lastig voor beginnende proggers, vast veld veldgrootte is beter). We kunnen ook doen dat het veld kleiner is dan de maximale grootte, maar dan moeten we wel ff afspreken wat de maximale grootte is.

Bij het commando DIED wordt er een waarde doorgegeven. Dus zo:
DIED waarde
waarde is 1 of 2. 1 betekend: connectie wordt gekickt, een goede middag toegewenst, 2 betekend de vraag of je nog ff wilt blijven hangen, dan wordt er nog een ronde gestart.
WAIT OK moet je terugsturen als je idd wilt blijven hangen voor nog een ronde (binnen een minuut, dus je kan dit manual beslissen) óf
WAIT NO als je er mee wilt kappen. De server schopt dan de connectie.
Na WAIT OK wordt je geacht weer te gaan luisteren, en eventueel te pingpongen.

Het kan zijn dat ik nog wat vergeten ben, maar als voorstel voor protocol denk ik dat ik wel zo'n beetje alles heb.
Voor programmeerprobleempjes om dit allemaal te verwerken ben ik natuurlijk beschikbaar (ik geef c of qbasic voorbeelden)

PS, ik bendenk me nu dat je waarschijnlijk ook wel de stand wilt weten in de gespeeld rondes, en je stand in de competitie. Dit zijn waarden die doorgegeven kunen worden bij DIED en de OK van de CONNECT.

Okeej, barst maar los!

[wacco]

Dit hierboven is dus een protocolvoorstel mensen! Mietje, laat ook eens wat horen!

Scoutboy, welkom op GoT! Leuk dat je mee wilt doen. Maar ik zou wel even je emailadres weghalen, daar kan misbruik van gemaakt worden. In je profile kan je em ook zetten, maar dan wordt ie weergegeven als plaatje en kunnen spiders er niks mee.
Verder is dit dus een discussie over het opzetten van een nieuwe contest, dus alles wat jij denkt dat handig is in onze competitie mag je hier posten. Wees creatief!

offtopic:
sorry dat dat protocol zo'n lang verhaal geworden is, ik lul te veel

[ Voor 10% gewijzigd door wacco op 29-11-2002 11:42 . Reden: woei wat een verhaal! ]

[TheOneLLama]

wacco schreef op 29 November 2002 @ 11:37:
Ik ben extreem tegen XML. Ik heb geen zin om een hele meuk code in c te moeten proggen (of er nou functies en libs voor zijn of niet, ik moet ze nog steeds aanroepen)

Je hebt geen zin om functies aan te roepen?
Ik durf te wedden dat als je expat zou gebruiken je design er ook nog eens beter op zou worden.

omdat het er alleen maar een beetje leesbaar uit moet zien. We hebben het hier over een enorm simpel spelletje mensen!

Het is niet veel meer werk, het is niet moeilijk om te lezen (als je dat wel vind pak je een tool, heb je nog syntax highlighting ed ook )
XML is enorm simpel.

Maar de reden dat jij en anderen er op tegen zijn lijkt me genoeg reden om het niet te doen.

_{Is het te laat om voor te stellen het geheel over Jabber te gooien? Dan heb ik in 4 regels m'n verbinding+secure authenticatie, in 10 regels kan ik verschillende games browsen, in 5 regels m'n eigen icon transferen... en.. uhm.. waar ging het spelletje ook al weer over?}

[Verwijderd]

Welke attributen heeft een tank allemaal?
tot nu toe zie ik:
X , Y
Energy
TurnAngle
HP

En wat nog meer?

[wacco]

[rml]mietje in "[ alg] botwar Bespreking *"[/rml]
Daar wordt het spel grotendeels uitgezet. Een hoop nog onduidelijke dingen zijn daarna gevraagd, en besproken. Gewoon vanaf die post een beetje globaal bijlezen. Waarschijnlijk covert dat wel de meeste vragen.

[cobratbq]

Dus ... samenvatting:

wacco schreef op 29 november 2002 @ 11:37:
FIRE waarde1 waarde2
MOVE waarde1 waarde2
TURN waarde1
MINE
SCAN waarde1

INFO
- FIRE AWAY óf FIRE FAIL waarde
- MOVE waarde1 waarde2
- TURN DONE óf TURN FAIL
- MINE AWAY waarde1 óf MINE FAIL
- SCAN waarde1 waarde2 waardenachterelkaar * n

Verwijderd schreef op 29 November 2002 @ 12:00:
Welke attributen heeft een tank allemaal?
tot nu toe zie ik:
X , Y
Energy
TurnAngle
HP

MisterData schreef op 28 November 2002 @ 22:24:

Wie doet wat?
mietje	server schrijven
MisterData	JS-wrapper
In onderhandeling	Protocol verzinnen
(misschien .oisyn)	grafische spectator client?

Even kort samengevat zodat er een duidelijk overzicht is.

Wat dat XML betreft. Ik vind dat geen goed idee. Als je ziet hoe simpel de functies zijn dan is XML helemaal niet nodig.
Ik geef de voorkeur aan de plain-text protocolletje. Dat is voor iedereen goed te volgen en het is gewoon makkelijker omdat er toch niet veel info doorgegeven hoeft te worden.

[Verwijderd]

Maak een abstractie omschrijving van de protocol data units die je wilt versturen. Daarna ga je kijken hoe je ze gaat versturen (encoden) in bijvoorbeeld een bytearray,xmliets, ( of whatever het meeste stemmen oplevert) met een bepaalde encoding.

general pdu
byte[0/1] protocol version
byte[1/2] pdu type
byte[x-y] pdutype specifieke informatie
byte[n] extra info, eventueel crc?

Dan kun je op basis van deze template bijvoorbeeld een joinpdu, leavepdu, turnpdu e.d. gaan verzinnen. Als dat gedaan is kun je gezamelijk voor elke taal protocol entities maken die 1. connectie maken 2. pdu's filteren die niet voldoen aan crc, version, unknown pdutype, pdutype min/max length etc. 3. pdu's ontvangen en omzetten naar abstract pdu's (classes/structures) en 4. functies leveren (de service interface) met als argument een abstract pdu die deze encode en naar de server verstuurt.

Zo hoeft niet iedereen de implementatie van het protocol zelf te maken en zal het de meeste mensen zelfs al jeuken hoe de implementatie van de protocol entity is zolang er maar handige member functies zijn om het te gebruiken.

eventueel zou je het nog kunnen opbouwen in twee layers, waarin de onderste layer de connectie maakt en simpele datapdu's verstuurt en de bovenste layer (welke door de client gebruikt wordt) die daarbovenop een robowar-service levert.

Het is maar een standaard aanpak, maar wel eentje die meestal veel problemen uit de weg ruimt en het hele project iets bereikbaarder

Eventueel wil ik ook wel helpen met de specificatie van de protocol layer(s) en de implementatie in java. Maargoed misschien is er wel meer animo voor strings versturen die iedereen fijn zelf wil gaan analysen

[NDF82]

Idd, geen xml, het lijkt mij in ieder geval het leukste als er zoveel mogelijk mensen mee kunnen doen (moeten ze natuurlijk ook willen ) dus de communicatie moet niet onnodig moeilijk gemaakt worden. Het gaat immers om het bedenken van ai voor je bot.

[ Voor 1% gewijzigd door NDF82 op 29-11-2002 12:57 . Reden: typo ]

[farlane]

Lijkt me dat je het beste een protocol dat al bestaat en werkt aanpast aan je behoeften ( Bijv Modbus/TCP oid )

T'is redelijk simpel, compact en het belangrijkste, het werkt.

[ Voor 23% gewijzigd door farlane op 29-11-2002 12:58 ]

[Verwijderd]

Mijn protocolvoorstel: keep it simple! Dus voorstel general specs:

• elk commando beinhoudt een cleartext regel, afgesloten door '\n'.
• verschillende velden in een commando worden gescheiden door een of meer spaties en/of tabs.
• Elk commando begint met één letter die het commandotype aangeeft.
• Verdere velden zijn double precision waardes met een precisie van 12 cijfers achter de komma.

Client protocol:

• G <richting> <energie> // Beweeg de tank
• S <energie> // Meer energie naar het schild
• V <richting> <energie> <energie> // Vuur een projectiel af
• R <energie> // Doe een radarscan

<richting> is daarbij een een double van -Pi tot Pi (radialen)

Over he serverprotocol wordt nog niet veel gesproken, en heb ik ook nog niet echt nagedacht. Er moet bv. een deelprotocol komen om de spelers te identificeren.

[.oisyn]

MisterData schreef op 29 november 2002 @ 08:51:
Ik denk zelfs dat er veel mensen hier in de P&W zijn die niet eens weten wat COM/CORBA inhoudt.

ik zei ook niet dat we dat moesten gebruiken, ik nam het slechts als voorbeeld. Wat ik wel zei is dat deze discussie op dit moment nogal onzinnig is zolang we nog niet eens weten WAT er verstuurd gaat worden

[farlane]

Een voorstelletje:

Commando Frame:

[DestID][SrcID][Commando][DataCount][......Data.......]


- [DestID] is het ID van een deelnemer waarvoor het bericht bestemd is ( server, andere client, broadcast )
- [SrcID] je eigen ID ( uitgereikt door de server )
- [Commando] is commandonummer
- [DataCount] aantal databytes dat volgt
- [...Data....] de data die bij het commando hoort

Als je een response wilt sturen kun je een vergelijkbaar bericht terugsturen

[SrcID][DestID][SrcCommando][DataCount][....Data....]

Waarbij
[SrcCommando] het commando is waarop gereageerd wordt en [Data] de data die wordt gevraagd of een NACK oid.

[ Voor 3% gewijzigd door farlane op 29-11-2002 13:06 ]

[Verwijderd]

..

[SrcID][DestID][SrcCommando][DataCount][....Data....]

Waarbij
[SrcCommando] het commando is waarop gereageerd wordt en [Data] de data die wordt gevraagd of een NACK oid.

Dat soort contraints horen in principe in je protocol opgenomen te zijn, niet in je dataunits..

[ Voor 5% gewijzigd door Verwijderd op 29-11-2002 13:10 ]

[farlane]

Verwijderd schreef op 29 november 2002 @ 13:09:
[...]


Dat soort contraints horen in principe in je protocol opgenomen te zijn, niet in je dataunits..

Welke constraints ?

[Verwijderd]

Eumz, mensen, keep it simple! Aangezien de game een client/server model heeft, ga je niet rechtstreeks met tegenstanders communiceren. Dat zou ook alleen maar de mogelijkheden tot valsspelen vergroten (samenwerken).

Verder wordt het nu al duidelijk dat je met XML nooit zo eenvoudige protocolspecs kunt schrijven als gewoon cleartext, line-oriented. Daarnaast ben ik bang dat er toch echt talen zijn zonder XML library; we hebben pagina's lang zitten bakkeleien of we wel sockets of pipes mogen gebruiken, en nu wordt er opeens een zeer zware lib geintoduceerd?

[Creepy]

farlane schreef op 29 november 2002 @ 13:06:
Een voorstelletje:

Commando Frame:

[DestID][SrcID][Commando][DataCount][......Data.......]


- [DestID] is het ID van een deelnemer waarvoor het bericht bestemd is ( server, andere client, broadcast )
- [SrcID] je eigen ID ( uitgereikt door de server )
- [Commando] is commandonummer
- [DataCount] aantal databytes dat volgt
- [...Data....] de data die bij het commando hoort

Als je een response wilt sturen kun je een vergelijkbaar bericht terugsturen

[SrcID][DestID][SrcCommando][DataCount][....Data....]

Waarbij
[SrcCommando] het commando is waarop gereageerd wordt en [Data] de data die wordt gevraagd of een NACK oid.

Waarom zou je je DestID en SrcID opnemen???? Dat word al geregeld door het IP protocol (aangezien er met sockets gewerkt gaat worden).

[Verwijderd]

/me doet nog een poging...

We werken met TCP sockets, en de server is niet zo brain-damaged dat hij na een beurt niet meer weet welke socket met welke speler verbonden is. Je hoeft dus geen lowlevel protocol te schrijven! Het gaat er puur en alleen om hoe de commando's van de client naar de server (en vice versa) er uit moeten zien zodat ze zo eenvoudig mogelijk te parsen zijn.

[farlane]

Creepy schreef op 29 november 2002 @ 13:18:
[...]

Waarom zou je je DestID en SrcID opnemen???? Dat word al geregeld door het IP protocol (aangezien er met sockets gewerkt gaat worden).

Je zou dan de server als 'router' kunnen gebruiken als je direct van client1 naar client2 wilt communiceren ( Als je dat zou willen heet dat )

[wacco]

Idd, alleen de server kletst met iedereen. Dus als de server iets te versturen heeft naar een persoon, dan doet ie dat wel naar dat persoon alleen. En dan bedoel ik:

code:

'VB code
Private Sub Ws_ConnectionRequest(ByVal requestID As Long)
Ws.close 'stoppen met luisteren op deze winsock
Ws.Accept requestID
status.Caption = "connected met iemand!"
End Sub

en dan iets van een array oid meerdere accepten (verbinding niet closen) en dan via requestID specifiek aanspreken of meerdere winsocket-dims die allemaal een user accepteren.

edit:

te laat, never mind

[ Voor 7% gewijzigd door wacco op 29-11-2002 13:32 ]

[Verwijderd]

/me draait communication breakdown van Led Zeppelin (echt waar )

[wacco]

Maarreh, mietje, heb je nou al -iets- van code? Geef eens een link

[Creepy]

Verwijderd schreef op 29 november 2002 @ 13:31:
/me draait communication breakdown van Led Zeppelin (echt waar )

Heel sterk

[farlane]

Verwijderd schreef op 29 november 2002 @ 13:26:
/me doet nog een poging...

We werken met TCP sockets, en de server is niet zo brain-damaged dat hij na een beurt niet meer weet welke socket met welke speler verbonden is. Je hoeft dus geen lowlevel protocol te schrijven! Het gaat er puur en alleen om hoe de commando's van de client naar de server (en vice versa) er uit moeten zien zodat ze zo eenvoudig mogelijk te parsen zijn.

Wat jij wilt is van tevoren vastleggen hoeveel en welke parameters elk commando heeft.

Dat is een nobel streven, echter je protocol moet het wel toelaten om later nog makkelijk iets toe te voegen aan een bepaald commando.

Die ID's in het frame zijn niet noodzakelijk, maar wel handig mocht het een langduriger project worden ( Wie weet is het een success ).

Verder is het voor de deelnemers in de communicatie makkelijker om te weten hoeveel data hij moet lezen. Als je zou besluiten om toch binaire data te gaan communiceren is dit helemaal makkelijk.

[wacco]

farlane schreef op 29 November 2002 @ 13:40:
Wat jij wilt is van tevoren vastleggen hoeveel en welke parameters elk commando heeft.

Dat is een nobel streven, echter je protocol moet het wel toelaten om later nog makkelijk iets toe te voegen aan een bepaald commando.

want?
Zolang maar vast staat hoe het spel eruit moet gaan zien, en zodra er een server + testclient is waarmee uitgebreid getest is, zodat alle 'oeps vergeten' dingetjes eruit zijn. En dan pas is er een definitief protocol. Iedereen die dus de 'beta' al heeft zitten implementeren in z'n bot is stom bezig.

[Verwijderd]

De code is nu zover dat ik een gesloten simulatie kan draaien. Ik begin nu met het implementeren van het spelers-interface, waarna de objecten echt bestuurbaar worden. Zodra als dat goed loopt publiceer ik de code voor review. Daarna moet er nog een socket-interface gebouwd worden, waarna de server v0.1 klaar zou moeten zijn...

[Creepy]

farlane schreef op 29 November 2002 @ 13:40:
[...]
Wat jij wilt is van tevoren vastleggen hoeveel en welke parameters elk commando heeft.

Dat is een nobel streven, echter je protocol moet het wel toelaten om later nog makkelijk iets toe te voegen aan een bepaald commando.

Eehh... bij het ontwikkelen van software zou dit de normaalste zaak van de wereld moeten zijn. EERST nadenken en ontwerpen, DAN pas beginnen met de implementatie.

Die ID's in het frame zijn niet noodzakelijk, maar wel handig mocht het een langduriger project worden ( Wie weet is het een success ).

Eehh.. ik snap nog steeds niet waarom die ID's handig zijn? Dit is echt iets wat het IP protocol voor je regelt.

[Sponge]

Hmm, is het niet slimmer om "FIRE, DIED" e.d. gewoon als een constante te gebruiken?

Verder vroeg ik me af of we nu gewoon strings gaan versturen of Bytedata, laatste zou efficenter zijn, eerste makkelijker cross-language, denk ik.

[MisterData]

Waar ik net ook aan zat te denken, kunnen we niet gewoon XML-RPC gebruiken? Het lijkt me dat daar wel een makkelijke API voor bestaat * MisterData gaat es zoeken of dat kan
_{maar nu nog niet, ik moet nog een sinterklaas-surprise afmaken}

[LordLarry]

MisterData schreef op 29 november 2002 @ 15:09:
Waar ik net ook aan zat te denken, kunnen we niet gewoon XML-RPC gebruiken? Het lijkt me dat daar wel een makkelijke API voor bestaat

SOAP

[MisterData]

LordLarry schreef op 29 november 2002 @ 15:13:
[...]

SOAP

Ik dacht altijd dat XML-RPC simpeler was dan SOAP? SOAP is inderdaad ook een optie (zit standaard in .NET voorzover ik weet)

[Verwijderd]

Note to self: ze lezen toch niet wat je schrijft... Als jullie een XML protocol willen dan vind ik dat best, alleen ga ik persoonlijk niet de moeite nemen om dat te implementeren, dat mag dan iemand anders doen. Ik vind het nl. extreme overkill en zie er het nut niet van in.

[MisterData]

Verwijderd schreef op 29 november 2002 @ 15:15:
Note to self: ze lezen toch niet wat je schrijft... Als jullie een XML protocol willen dan vind ik dat best, alleen ga ik persoonlijk niet de moeite nemen om dat te implementeren, dat mag dan iemand anders doen. Ik vind het nl. extreme overkill en zie er het nut niet van in.

Dat lijkt me geen probleem, genoeg programmeurs hier Welke taal ben je trouwens in bezig? C++?

[wacco]

ik in c, en xml is geen extreme overkill, its HUGE overkill
En strings overschoppen houd het makkelijk, kan je gewoon je data als string uitlezen, opsplitsen, bekijken, en dan bepalen wat vars zijn.

Dingen als dit moeten juist enorm simpel gehouden worden, dus geen bytestreams, xml, en ander fancy stu-uff. We gingen hier een competitie houden wie de beste AI kan schrijven, en dan moet de communicatie voor een beginneling niet meer programmeertijd dan een uurtje innemen.

[MisterData]

wacco schreef op 29 november 2002 @ 15:21:
ik in c, en xml is geen extreme overkill, its HUGE overkill
En strings overschoppen houd het makkelijk, kan je gewoon je data als string uitlezen, opsplitsen, bekijken, en dan bepalen wat vars zijn.

Dingen als dit moeten juist enorm simpel gehouden worden, dus geen bytestreams, xml, en ander fancy stu-uff. We gingen hier een competitie houden wie de beste AI kan schrijven, en dan moet de communicatie voor een beginneling niet meer programmeertijd dan een uurtje innemen.

De absolute beginneling kan mij JS framework gebruiken straks

[Verwijderd]

MisterData schreef op 29 November 2002 @ 15:16:
Dat lijkt me geen probleem, genoeg programmeurs hier Welke taal ben je trouwens in bezig? C++?

Welke? Welke anders?
_{uiteraard C++}

[Verwijderd]

Het begint er goed uit te zien, maar ik heb nog wat puntjes van zorg:

- Waarom in godsvredesnaam XML? Ik zie het voordeel er echt niet van in en het parsen maakt m'n code lelijker en een stuk trager. Het is een in geen enkel geval simpeler, met een simpele split() ben je er al uit op een text-based manier.
- Is het niet simpeler om een 4 graden (lees: 0, 90, 180, 270) graden draai-systeem te maken?

O ja, de client commando's zijn wel bekend gemaakt door mietje, maar nog niet die die de server teruggeeft. Is daar iets over te zeggen?

edit:
Hoe snel. Ik ben een reactietje aan het bedenken en er zijn al weer 4 andere reacties bij

[ Voor 11% gewijzigd door Verwijderd op 29-11-2002 15:34 ]

[farlane]

Creepy schreef op 29 november 2002 @ 14:15:
Eehh... bij het ontwikkelen van software zou dit de normaalste zaak van de wereld moeten zijn. EERST nadenken en ontwerpen, DAN pas beginnen met de implementatie.

Ik zei toch ook dat het een nobel streven was om eerst over je implementatie na te denken ?
Jij doet net alsof er nooit een versie groter dan 1.0 van software/protocollen/whatever wordt uitgebracht, en als dat wel het geval is dat men er niet over heeft nagedacht.

[...]

Eehh.. ik snap nog steeds niet waarom die ID's handig zijn? Dit is echt iets wat het IP protocol voor je regelt.

[selfquote]
Je zou dan de server als 'router' kunnen gebruiken als je direct van client1 naar client2 wilt communiceren ( Als je dat zou willen heet dat )
[/selfquote]

[ Voor 4% gewijzigd door farlane op 29-11-2002 15:41 ]

[MisterData]

* MisterData de samenvatterman:

Attributen van een tank

Energie	van 0 tot 100
HP	ook 0 tot 100
Heading	0-360
X
Y

Acties van een tank:

Move	param: hoeveel pixeltjes
Fire	param: eventueel sterkte van de kogel?
Suicide	geen uitleg nodig denk ik
Scannen	moet een lijstje teruggeven met robots in de buurt, hun afstand en heading.
Rotate	heading instellen, param: een getal tussen 0 en 360

Deze lijst moeten we dus nog even aanvullen. Als we alles hebben, kunnen we er een protocol bij maken

[ Voor 10% gewijzigd door MisterData op 29-11-2002 15:44 . Reden: tabel mooier gemaakt :) ]

[NDF82]

LordLarry schreef op 29 november 2002 @ 15:13:
[...]

SOAP

SOAP, ok, hier heb je alvast een wsdl

XML:

  <?xml version="1.0" encoding="UTF-8" ?> 
- <wsdl:definitions targetNamespace="urn:botwars" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="urn:botwars" xmlns:intf="urn:botwars" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <wsdl:types /> 
  <wsdl:message name="moveResponse" /> 
- <wsdl:message name="moveRequest">
  <wsdl:part name="in0" type="xsd:double" /> 
  <wsdl:part name="in1" type="xsd:int" /> 
  </wsdl:message>
  <wsdl:message name="radarScanResponse" /> 
  <wsdl:message name="fireResponse" /> 
- <wsdl:message name="fireRequest">
  <wsdl:part name="in0" type="xsd:double" /> 
  <wsdl:part name="in1" type="xsd:int" /> 
  <wsdl:part name="in2" type="xsd:int" /> 
  </wsdl:message>
  <wsdl:message name="increaseShieldEnergyResponse" /> 
- <wsdl:message name="increaseShieldEnergyRequest">
  <wsdl:part name="in0" type="xsd:int" /> 
  </wsdl:message>
- <wsdl:message name="radarScanRequest">
  <wsdl:part name="in0" type="xsd:int" /> 
  </wsdl:message>
- <wsdl:portType name="BotwarWebservice">
- <wsdl:operation name="move" parameterOrder="in0 in1">
  <wsdl:input message="intf:moveRequest" name="moveRequest" /> 
  <wsdl:output message="intf:moveResponse" name="moveResponse" /> 
  </wsdl:operation>
- <wsdl:operation name="increaseShieldEnergy" parameterOrder="in0">
  <wsdl:input message="intf:increaseShieldEnergyRequest" name="increaseShieldEnergyRequest" /> 
  <wsdl:output message="intf:increaseShieldEnergyResponse" name="increaseShieldEnergyResponse" /> 
  </wsdl:operation>
- <wsdl:operation name="fire" parameterOrder="in0 in1 in2">
  <wsdl:input message="intf:fireRequest" name="fireRequest" /> 
  <wsdl:output message="intf:fireResponse" name="fireResponse" /> 
  </wsdl:operation>
- <wsdl:operation name="radarScan" parameterOrder="in0">
  <wsdl:input message="intf:radarScanRequest" name="radarScanRequest" /> 
  <wsdl:output message="intf:radarScanResponse" name="radarScanResponse" /> 
  </wsdl:operation>
  </wsdl:portType>
- <wsdl:binding name="BotwarsSoapBinding" type="intf:BotwarWebservice">
  <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" /> 
- <wsdl:operation name="move">
  <wsdlsoap:operation soapAction="" /> 
- <wsdl:input name="moveRequest">
  <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:botwars" use="encoded" /> 
  </wsdl:input>
- <wsdl:output name="moveResponse">
  <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:botwars" use="encoded" /> 
  </wsdl:output>
  </wsdl:operation>
- <wsdl:operation name="increaseShieldEnergy">
  <wsdlsoap:operation soapAction="" /> 
- <wsdl:input name="increaseShieldEnergyRequest">
  <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:botwars" use="encoded" /> 
  </wsdl:input>
- <wsdl:output name="increaseShieldEnergyResponse">
  <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:botwars" use="encoded" /> 
  </wsdl:output>
  </wsdl:operation>
- <wsdl:operation name="fire">
  <wsdlsoap:operation soapAction="" /> 
- <wsdl:input name="fireRequest">
  <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:botwars" use="encoded" /> 
  </wsdl:input>
- <wsdl:output name="fireResponse">
  <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:botwars" use="encoded" /> 
  </wsdl:output>
  </wsdl:operation>
- <wsdl:operation name="radarScan">
  <wsdlsoap:operation soapAction="" /> 
- <wsdl:input name="radarScanRequest">
  <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:botwars" use="encoded" /> 
  </wsdl:input>
- <wsdl:output name="radarScanResponse">
  <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:botwars" use="encoded" /> 
  </wsdl:output>
  </wsdl:operation>
  </wsdl:binding>
- <wsdl:service name="BotwarWebserviceService">
- <wsdl:port binding="intf:BotwarsSoapBinding" name="Botwars">
  <wsdlsoap:address location="http://localhost:8000/axis/services/Botwars" /> 
  </wsdl:port>
  </wsdl:service>
  </wsdl:definitions>

[ Voor 22% gewijzigd door NDF82 op 29-11-2002 15:45 ]

[Verwijderd]

Wat me opvalt is dat mensen telkens hun eigen ideen over het protocol naar voren brengen, terwijl mietje al een heleboel dingen geimplementeerd heeft (zie zijn protocol een paar pagina's terug). Mischien moet het protocol eerst maar eens uitgevochten worden...

LordLarry schreef op 29 November 2002 @ 15:13:
[...]

SOAP

Als er nou iets is wat niet wat niet portable is De discussie van pagina 2 komt weer terug... Sockets of iets anders? Zo blijf je natuurlijk bezig! Ik hoopte dat de strijd gestreden zou zijn en dat er sockets gebruikt zouden worden.

[MisterData]

Verwijderd schreef op 29 november 2002 @ 15:59:
Wat me opvalt is dat mensen telkens hun eigen ideen over het protocol naar voren brengen, terwijl mietje al een heleboel dingen geimplementeerd heeft (zie zijn protocol een paar pagina's terug). Mischien moet het protocol eerst maar eens uitgevochten worden...


[...]


Als er nou iets is wat niet wat niet portable is De discussie van pagina 2 komt weer terug... Sockets of iets anders? Zo blijf je natuurlijk bezig! Ik hoopte dat de strijd gestreden zou zijn en dat er sockets gebruikt zouden worden.

Dat we sockets gaan gebruiken staat al vast hoor SOAP is totaal niet te vergelijken met sockets. SOAP is de taal die kan worden gesproken over een socket. En dan maak je alsnog gebruik van TCP/IP Mietje heeft alleen maar een simulatie geimplementeerd, en het protocol moet nog komen

[NDF82]

Ik dacht eigelijk dat het al vast stond nl:

• sockets
• plain text
• COMMAND <parameter>, <parameter>, ... \n

[MisterData]

NDF82 schreef op 29 november 2002 @ 16:02:
Ik dacht eigelijk dat het al vast stond nl:

• sockets
• plain text
• COMMAND <parameter>, <parameter>, ... \n

Als we daar met z'n allen mee kunnen leven staat dat vast Ik denk idd dat dat de makkelijkste manier is.

[Creepy]

farlane schreef op 29 November 2002 @ 15:40:
[...]
Je zou dan de server als 'router' kunnen gebruiken als je direct van client1 naar client2 wilt communiceren ( Als je dat zou willen heet dat )
[/selfquote]

Hmm.. als je met andere tanks wilt communiceren zul je daar een andere oplossing voor moeten verzinnen denk ik, want voor pure communicatie tussen server <-> client is het alleen maar extra overhead.

Maar goed.. dit was mijn laatste reply in dit topic. Mocht er echt nog een GPC uitkomen dan hoor ik het vanzelf wel. Op het moment lijkt het allemaal veel te ver te gaan (SOAP gebruiken *proest*.. dan hebben we plainttext -> xml -> soap -> eigen protocol, hoeveel lagen wil je nog toevoegen?).

Als het straks doorgaat hebben we een <insert random buzzword here> ondersteunend botwar spel waar niemand een client voor gaat schrijven Maar goed..

_{Sterkte mietje!}

[Creepy]

farlane schreef op 29 November 2002 @ 15:40:
[...]
Jij doet net alsof er nooit een versie groter dan 1.0 van software/protocollen/whatever wordt uitgebracht, en als dat wel het geval is dat men er niet over heeft nagedacht.

[...]

Eehh.. hoezo doe ik dat? Bugfixes zorgen ook voor een hoger versie nummer. En extra features, daar kan je in je bestaand ontwerp al rekening mee houden of je bestaande ontwerp voor aanpassen om daarna je al bestaande produkt aan te passen.

Het komt op mij over dat jij een idee hebt, het meteen gaat implementeren en problemen e.d. pas op te lossen en er echt over na te denken as you go. Het scheelt een HOOP tijd (zeker bij grote projects wat dit nog niet eens is) om EERST na te denken. Al die ellende die je krijgt omdat je van te voren niet (goed) hebt nagedacht is de moeite waard om te voorkomen. (standaard software engineering principes dus.. eerst ontwerpen, dan pas beginnen.. dat je een prototype maakt, of wat dingen uitprobeerd voordat je gaat ontwerpen moet kunnen natuurlijk).

(kon het toch niet laten om te reageren hierop)

[MisterData]

Kunnen we even kappen met ruzieen? Het is geen uber-belangrijk project hoor Wat boeit dat als we een week later klaar zijn Ga liever coden, in plaats van zeuren

[wacco]

D'r valt (nog) niets te coden

Verwijderd schreef op 29 november 2002 @ 15:59:
Wat me opvalt is dat mensen telkens hun eigen ideen over het protocol naar voren brengen, terwijl mietje al een heleboel dingen geimplementeerd heeft (zie zijn protocol een paar pagina's terug). Mischien moet het protocol eerst maar eens uitgevochten worden...

Bedoel je niet dat protocol dat ik tikte? Ik heb mietje geen protocol zien tikken, alleen maar regels van het spel.
Protocol staat dus vast? (hoofdlijnen)

360 graden is leuker. Houd het een beetje complex. Het moet niet te simpel worden.

[farlane]

Creepy schreef op 29 november 2002 @ 16:44:
[...]

Eehh.. hoezo doe ik dat? Bugfixes zorgen ook voor een hoger versie nummer.

Mee eens, maar daar doelde ik natuurlijk niet op.

En extra features, daar kan je in je bestaand ontwerp al rekening mee houden of je bestaande ontwerp voor aanpassen om daarna je al bestaande produkt aan te passen.

Dat is toch precies wat ik probeer te bereiken ? Maak je protocol zo dat er later makkelijk aanpassingen op kunt maken, dat was mijn bedoeling.

Het komt op mij over dat jij een idee hebt, het meteen gaat implementeren en problemen e.d. pas op te lossen en er echt over na te denken as you go. Het scheelt een HOOP tijd (zeker bij grote projects wat dit nog niet eens is) om EERST na te denken. Al die ellende die je krijgt omdat je van te voren niet (goed) hebt nagedacht is de moeite waard om te voorkomen. (standaard software engineering principes dus.. eerst ontwerpen, dan pas beginnen.. dat je een prototype maakt, of wat dingen uitprobeerd voordat je gaat ontwerpen moet kunnen natuurlijk).

Ten dele waar. Ik denk eerst na over het ontwerp, ga ontwerpen en daarna implementeren. Vervolgens kom ik er over het algemeen achter dat ik bepaalde
situaties niet voorzien heb en bedenk daar ter plekke een oplossing voor.
Vervolgens wordt het ontwerp aangepast aan de praktische situatie.
Volgens mij kun je van tevoren ( zeker niet bij grote projecten ) niet alle ontwerpbeslissingen maken, omdat je niet alles kunt voorzien.

(kon het toch niet laten om te reageren hierop)

Ik ook niet.

[.oisyn]

MisterData schreef op 29 November 2002 @ 16:46:
Kunnen we even kappen met ruzieen? Het is geen uber-belangrijk project hoor Wat boeit dat als we een week later klaar zijn Ga liever coden, in plaats van zeuren

als mensen dat 2 pagina's geleden nou eens deden... dat gezeik over structuur wat totaal nog niet van belang is

[Verwijderd]

ik ga helemaal akkoord wat er tot nu toe al allemaal beslist is

zo simpel mogelijke communicatie tss server en client

het is en blijft de bedoeling om AI te schrijven voor de bot, laten we het niet extra moeilijk maken, want ik heb het voorgevoel dat er velen dit onderschatten, mij lijkt het niet zo geweldig simpel om zo maar even een bot neer te zetten die op zen eentje intelligente beslissingen kan maken

als je dan ook nog de rest moeilijk gaat maken, gaan er velen afkappen