Awalé Programmeerwedstrijd

Dus als een partij afgelopen is, kan een crash, verkeerde functie-aanroep of wat dan ook geen roet meer in het eten gooien, als je in gewonnen positie staat?

Is de einduitslag nog ergens beschikbaar? In de logs lijken alle partijen van het toernooi nog in de initialized-state http://test.tjipchallenge...64fc2bd4cf46004899980.xml

Ik zou ook nog wel een aantal partijen willen terugzien en de eindstand inderdaad.

Ik vond het erg leuk gisteren! De techniek had iets beter gekund, maar gelukkig werkte uiteindelijk alles met een mooie combinatie van last-minute hacks, handmatig starten/stoppen van programma's en score bijhouden met pen en papier.

Doordat er verschillende goede programma's meededen was het was nog erg spannend. Jammer dat er geen tijd was voor een volledige competitie (er is uiteindelijk een halve competitie gespeeld) maar desondanks zaten er een paar mooie partijen tussen.

Ik zou ze ook graag de partijen nog eens terug zien, niet in de laatste plaats omdat mijn programma in één van de partijen een ongeldige zet deed die ik niet kon verklaren (en dat kan ik niet uitstaan)! Overigens heb ik voor geïnteresseerden mijn programmacode ook online gezet: HTML source of awale.zip. (Ik denk dat eigenlijk alleen AI.java interessant is.)

Leuk om je code te zien, is een stuk beter leesbaar dan de mijne ben ik bang Hoop dingen lijken heel erg op wat ik ook gedaan heb. Heb ook een long als bord gebruikt, ook negatieve waardes voor ongeldige zetten ook een statische variabele voor de gegeten zaden. Ik durfde het alleen niet aan om erop te vertrouwen dat er nooit meer dan 31 seeds in een vakje komen, dus daar is mijn code iets ingewikkelder door geworden.

Heb verder tot 4 plies diep move ordering gedaan met korte searches, en heb een transposition table gebruikt, en Joost had een 18-ply openingsboek gemaakt waardoor we de eerste zetten heel snel en toch goed konden doen (na 8 seconde opstarttijd om em te unzippen )

Een "fout" waar ik pas heel laat achter kwam was dat ie op het eind weleens het partijeinde op een cruciaal moment over het hoofd wist te zien. Als hij bijvoorbeeld met 21-22 achter stond en zag dat ie 2 stenen kon slaan in 5 zetten maar ook zag dat ie op dezelfde manier na een rondje ook later die 2 stenen kon slaan dan zag ie dat als even goed, maar verloor vervolgens omdat er een herhaling van de stelling kwam. Door de evaluatie-functie te veranderen van alleen de geslagen stenen naar 100*[geslagen stenen]+[resterende searchdepth] was dat opgelost, en gaf ie ook hogere waardes aan paden waarin ie eerst voorstond en het later weggaf dan andersom, wat volgens mij ook wel gunstig is.

Jouw methode firstNonEmptyField lijkt trouwens eerder het tegenovergestelde te doen, wat een ongeldige zet zou verklaren, maar volgens mij roep je die alleen aan als je de tegenstander kan uithongeren, en naar wat ik me van de partij herinner was dat toen niet het geval.

quote:

vdeboer schreef op zondag 30 september 2007 @ 23:21:
Ik durfde het alleen niet aan om erop te vertrouwen dat er nooit meer dan 31 seeds in een vakje komen, dus daar is mijn code iets ingewikkelder door geworden.

Door die aanname kan het rondzaaien van alle zaden met één enkele optelling afgehandeld worden. Als er niets geslagen wordt (wat meestal zo is) is daarmee ook de zet afgelopen. Als je dan op overflow moet checken wordt het allemaal veel ingewikkelder. Dat paste niet in mijn strategie van zo snel mogelijk in plaats van slim zoeken. Neemt niet weg dat ik 'm wel erg mooi vind; je kunt zo alle toestanden heel compact representeren.

Hoe doe je dat overflow checken trouwens, heb je daar een slimme manier voor, of ga je toch het hele veld rond en bij elk zaadje checken of je overflow krijgt?

quote:

Door de evaluatie-functie te veranderen van alleen de geslagen stenen naar 100*[geslagen stenen]+[resterende searchdepth] was dat opgelost, en gaf ie ook hogere waardes aan paden waarin ie eerst voorstond en het later weggaf dan andersom, wat volgens mij ook wel gunstig is.

Dat tweede weet ik niet, maar het lijkt me dat zo'n evaluatiefunctie de stabiliteit van je zoekalgoritme niet ten goede komt (en het is dan sowieso geen nul-som-spel meer). Geeft dat geen problemen als je waarden wil opslaan in je transpositietabel? Of compenseer je daar voor?

(Ik heb het iets anders opgelost, namelijk door bij iteratief zoeken weer te beginnen bij de beste zet van de vorige keer, en die alleen te vervangen als er een duidelijk betere zet is. Daardoor krijgt een zet die sneller voordeel oplevert de voorkeur boven een zet die evenveel waard is, maar waarvoor dat pas later duidelijk wordt.)

quote:

Jouw methode firstNonEmptyField lijkt trouwens eerder het tegenovergestelde te doen, wat een ongeldige zet zou verklaren, maar volgens mij roep je die alleen aan als je de tegenstander kan uithongeren, en naar wat ik me van de partij herinner was dat toen niet het geval.

Ik had daar sowieso een fout in; regel 67 (board >>= 5) ontbrak helemaal! Dat had ik gisteren tijdens de wedstrijd ook gezien (en heb ik dus vanmiddag aangepast). Maar waarom denk je dat 'ie het tegenovergestelde doet? In mijn bord-representatie zijn de laagste vijf bits veld 0 (het meest linker veld van de huidige speler) dus volgens mij klopt 'ie zo wel (hoewel ik het niet getest heb). Maar ik denk ook niet dat dat hét probleem was. Als je nog wat verdachts ziet, laat het vooral weten!

Ik vond het ook erg leuk om de code te lezen, en heb me suf gezocht naar een bug. Volgens mij is firstNonEmptyField trouwens wel goed gecode. Uiteindelijk heb ik wel een bug gevonden in de move-methode, regel 92:

091 // TODO: cache values for (field + count%11)%12?
092 for (field = (field + count%11)%12; field >= 6; field -= 1)

Om het slaan-gedeelte af te handelen wordt field hierin het veld waar het laatste zaadje wordt geplaatst in een beurt. Dat is althans de bedoeling. Maar als count, het aantal zaadjes dat in het beginkuiltje zit, nou 11 of 22 is, dan wordt het naar-veld, hetzelfde als het van-veld, terwijl het juist 11 stappen verder zou moeten zijn (of 1 terug). Nou levert dat meestal niet een probleem op, omdat 1 stap terug vaak je eigen bordhelft is en je dan sowieso niet kunt slaan.
Maar áls je veld nul speelt en áls er 11 of 22 zaden in zitten en áls er na het spelen 2 of 3 zaden in veld 11 terechtkomen, dan wordt verzuimd om die te slaan (en evt andere zaden in velden 10,9,...).

Dit zou best wel eens de bug geweest kunnen zijn, waardoor het bord bij jou anders werd, en je een illegale zet speelde. Die TODO is zo wel wat wrang.
Je had trouwens gister zelf al een bug gevonden in je code, was dat deze? Of was dat een andere?

Overigens wel toevallig dat je testpartij vanwege lang nadenken was afgebroken dmv een illegale zet op veld 5 waar nul zaden op waren. Nu had je weer illegaal op veld 5 vanwege nul zaden, maar dit keer dus je eigen code. (Gister overwoog ik nog serieus de optie dat die malafide client nog runde en die de verkeerde zet deed. Maar je had al verteld dat je bordrepresentatie anders was.)


edit: Ah, die bug die je gister gevonden had was dus wat anders.

edit2: ah, het gebeurt natuurlijk ook als je tegenstander zo'n zet doet. Vanwege je negamax, wat ik ook had. Ik zal eens kijken of ik mijn code ergens kan posten. Maar het blijft natuurlijk een zeldzame zet, die dan net voorkomt in de partij waar je met winst de top3 op gedeeld eerste plaats zou kunnen brengen.

mstassen wijzigde dit bericht 01-10-2007 00:43 (9%)

quote:

mstassen schreef op maandag 01 oktober 2007 @ 00:17:
Ik vond het ook erg leuk om de code te lezen, en heb me suf gezocht naar een bug. Volgens mij is firstNonEmptyField trouwens wel goed gecode. Uiteindelijk heb ik wel een bug gevonden in de move-methode, regel 92:

091 // TODO: cache values for (field + count%11)%12?
092 for (field = (field + count%11)%12; field >= 6; field -= 1)

Om het slaan-gedeelte af te handelen wordt field hierin het veld waar het laatste zaadje wordt geplaatst in een beurt. Dat is althans de bedoeling. Maar als count, het aantal zaadjes dat in het beginkuiltje zit, nou 11 of 22 is, dan wordt het naar-veld, hetzelfde als het van-veld, terwijl het juist 11 stappen verder zou moeten zijn (of 1 terug).

Geweldig! Ik moest nog even goed nadenken voordat ik doorhad wat je bedoelde, maar volgens mij is dit het inderdaad. Sterk gespot. Ik denk dat het zo wel klopt:
Java:

1	for (field = (field + (count - 1)%11 + 1)%12; fields >= 6; field -= 1)

(Of ik had die posities moeten precalculaten zoals de TODO suggereert, maar ik denk niet dat dat qua performance veel verschil gemaakt zou hebben).

quote:

Je had trouwens gister zelf al een bug gevonden in je code, was dat deze? Of was dat een andere?

Dat was de fout in firstNonEmptyField().

quote:

ah, het gebeurt natuurlijk ook als je tegenstander zo'n zet doet. Vanwege je negamax, wat ik ook had.

Inderdaad; in principe kan die bug ook nog wel andere potjes beïnvloed kan hebben, ook als dat veld niet daadwerkelijk gespeeld is, simpelweg omdat m'n AI aan bepaalde zetten in bepaalde situaties een verkeerd gevolg koppelt. (Aan de andere kant is de situatie met een veelvoud van elf zaden op het eerste veld wel vrij zeldzaam.)

quote:

Maar het blijft natuurlijk een zeldzame zet, die dan net voorkomt in de partij waar je met winst de top3 op gedeeld eerste plaats zou kunnen brengen.

Ja, en vervelend dat ik het niet eerder tegenkwam (maar zo gek is dat niet, want de random speler op de testserver gaf ook niet echt aanleiding om grote stapels op te bouwen). Waarschijnlijk was het slim geweest om ook tegen mezelf te testen (of tenminste niet alléén op de testserver) maar ik ben er ook niet heel uitgebreid mee bezig geweest na de eerst opzet.

Overigens lijkt het me behoorlijk waarschijnlijk dat zonder die illegal move Vincent en Joost ook gewoon gewonnen zouden hebben, want ik verloor bijvoorbeeld ook van Ed van Doorn (mijn enige andere verliespartij, geloof ik) waar zij wél van wonnen. Maar het blijft jammer om juist de match tegen de beste tegenstander zo te moeten eindigen. Ik ben in ieder geval blij dat ik nu een clue heb wát er überhaupt misging.

betekent
if((board&31) == 0)
dan niet dat het veld leeg is? Als jullie allebei denken dat ie klopt zal ik wel ergens iets helemaal verkeerd lezen

Ik heb dit zo opgelost, het blijft in 1 long staan en kan dus nog steeds met 1 optelling geupdate worden. Ik moet inderdaad het bord aflopen om te checken op overflow, maar doe dit alleen als er een veld met 24 of meer seeds is (een veld met zowel het 16 als het 8 bit op 1). Dit komt al zo weinig voor dat het nauwelijks trager wordt. (Die laatse for-loop had ws makkelijk uitgeschreven kunnen worden, maar de doMove functie was al lang de bottleneck niet meer)
code:

//opvragen overflow buffer
if(seeds>=24)
{
     //add 4*store (bit 60,61,62) to the number of seeds
     seeds+= (board>>58)&28;  
}

... doe zet ...

//checken op "overflow" na de zet
if((board&bits16)>0 && (((board&bits8)<<1)&(board&bits16))>0)
{
    for(int i = 0 ; i < 12 ; i++)
    {
         if(board==(board|b28[i]))
         {
               board &= ~four[i];   //4<<5*i
               board += store;      //1<<60
               break;
         }
    }
}

Het blijft met die evaluatie-functie nog steeds een zero-sum spel, want de tegenstander rekt dus liever het moment waarop jij slaat, of zal verkiezen eerder te slaan ipv later. -101 voor jou impliceert nog steeds +101 voor de tegenstander. De reden dat ik denk dat dit beter is is vanwege het horizon-effect, als jij als laatst geslagen hebt is de kans groot dat de tegenstander de volgende wordt (althans tegen een goede tegenstander) omdat slaan je bordpositie vaak verslechterd. Dus ook als je het niet kan zien, is het fijner als jij eerst slaat en de ander daarna. Het zal meerdere redenen gehad hebben, maar na deze verandering won ie van mn testprogramma op (fixed) diepte 22, terwijl ie daarvoor nooit van diepte 20 kon winnen. Hij verloor ook niet meer van lagere zoekdieptes, wat ie daarvoor af en toe nog wel deed (erg irritant )

Het lijkt wel heel erg toeval dan inderdaad dat het net tegen ons misging, want dit had in ieder partij kunnen gebeuren. Misschien kunnen ze onze programmas nog eens tegen elkaar laten spelen, ik ben ook wel benieuwd naar een volledige competitie van de top 6 of zo omdat kleurvoordeel nog best wat uit kon maken en de top volgens mij behoorlijk aan elkaar gewaagd was.

quote:

vdeboer schreef op maandag 01 oktober 2007 @ 11:26:
betekent
if((board&31) == 0)
dan niet dat het veld leeg is? Als jullie allebei denken dat ie klopt zal ik wel ergens iets helemaal verkeerd lezen

Erm, het was laat blijkbaar. Je hebt helemaal gelijk; die was dus nog fout. Het begint me steeds meer te verbazen dat het nog zo goed ging zaterdag met alle bugs die er nu nog uitgevist worden.

quote:

Ik heb dit zo opgelost, het blijft in 1 long staan en kan dus nog steeds met 1 optelling geupdate worden. Ik moet inderdaad het bord aflopen om te checken op overflow, maar doe dit alleen als er een veld met 24 of meer seeds is (een veld met zowel het 16 als het 8 bit op 1). Dit komt al zo weinig voor dat het nauwelijks trager wordt. (Die laatse for-loop had ws makkelijk uitgeschreven kunnen worden, maar de doMove functie was al lang de bottleneck niet meer)

[knip: code]

Ah, dat ziet er wel mooi uit. De overhead valt zo inderdaad wel mee.

quote:

De reden dat ik denk dat dit beter is is vanwege het horizon-effect, als jij als laatst geslagen hebt is de kans groot dat de tegenstander de volgende wordt (althans tegen een goede tegenstander) omdat slaan je bordpositie vaak verslechterd.

Klopt. Dat probleem ben ik ook meer bij dit soort programma's tegengekomen.

quote:

Het lijkt wel heel erg toeval dan inderdaad dat het net tegen ons misging, want dit had in ieder partij kunnen gebeuren.

Klopt, maar ik heb ook het idee dat het grote-stapels-bouwen iets is wat vooral voorkomt bij twee goede spelers (die allebei niet makkelijk stenen weggeven), dus eigenlijk is het wel logisch dat het juist in die partij optrad.

quote:

Misschien kunnen ze onze programmas nog eens tegen elkaar laten spelen, ik ben ook wel benieuwd naar een volledige competitie van de top 6 of zo omdat kleurvoordeel nog best wat uit kon maken en de top volgens mij behoorlijk aan elkaar gewaagd was.

We kunnen ook de gameserver emuleren natuurlijk, of een Java interface definiëren analoog aan de gameserver en dan testen met wie wil (aangenomen dat alle geïnteresseerden met Java werken). Wel lastig als mensen in de tijd van de tegenstander willen denken.

ze zouden de source-code van de server beschikbaar stellen hoorde ik, dus dan zouden we die mss aan kunnen passen zodat we van thuis via internet kunnen spelen. Onze transposition table pikt namelijk ook al het geheugen in dat ie pakken kan, dus das dan ook nog een extra probleem als je 2 geheugen-intensieve programmas op 1 pc wil draaien.

en wat betreft dat grote-stapels bouwen, dat heb ik ons programma juist ook tegen zwakke spelers wel zien doen omdat ie daar dan enorme winsten mee kon halen, een sterke tegenstander laat je niet zomaar een hele rij stenen slaan op die manier... maar ik heb inderdaad ook wel de meeste bugs in potjes tegen een hoge zoekdiepte tegenstander gevonden omdat die dan toch wat meer de limieten van het algoritme opzoekt.

vdeboer wijzigde dit bericht 01-10-2007 12:43 (30%)

Wij willen, gezien het enthousiasme van alle deelnemers, het mogelijk maken dat mensen door kunnen gaan met het verbeteren van de engines.
We denken bijvoorbeeld aan een gameserver waarbij je kunt spelen tegen 1 van de zaterdag spelende engine (uiteraard met jullie toestemming). Of wellicht op 1 of andere manier dat 2 engines elkaar kunnen ontmoeten. Dit moeten we nog wel verder uitwerken.
Ik vond het (ondanks het gestress voor de wedstrijd ) zaterdag een erg leuke en leerzame dag. Ik heb een aantal keer met verbazing aangehoord hoever mensen zijn gegaan om hun engine te optimaliseren. De logfile viewer van Vincent was ook superhandig (ook voor ons )

We hadden meer dan 30 inschrijving, maar uiteindelijk bleven er 12 over. Dat niet iedereen mee kon doen was jammer. Dit lag mede aan de soap interface, die voor velen toch meer voeten in de aarde had dan dat we hadden verwacht. Van de andere kant hadden we ook niet veel meer deelnemers moeten hebben gezien de tijd en de mate van toernooiautomatisering .

Ik moet diegenen die de gespeelde potten terug willen zien helaas teleurstellen, die partijen zijn we kwijt. Blijkt dat door een samenloop van een onduidelijk 'manager'-gui en verkeerd bedacht procedure we bij het invoeren van een nieuwe ronde de vorige ronde overschreven.
Technischer:
Een toernooi is een object met daarin rondes, partijen en boarden, zeg maar zoals de xml eruit ziet die jullie voor een testpartij konden opvragen. Deze werd in 1 keer middels soap naar de server geschreven. Na het spelen van ronde 1 hadden we deze moeten teruglezen van de server voordat we de volgende ronde invoerden. Omdat we dat niet gedaan hebben schreven we bij elke nieuwe ronde de maagdelijke borden weer naar server. Dus slecht van ons (/mij), sorry daarvoor. (Ik ben blij dat de bug van Soultaker inmiddels gevonden is ).

De uitslag staat hier. We komen nog met een persbericht.

@vdeboer: Komen jullie allebei uit Delft? Dat willen we weten voor het persbericht. Stuur maar een dm.

Ah, goed dat de uitslag er iig nog is.
Wij komen allebei uit Delft ja. Misha spelt zijn naam trouwens zonder c

Ik vond het zaterdag een ontzettend leuke dag, ondanks dat mijn sh$%*tty programma niet eens meegedaan heeft . Gaat die re-match er nog komen? Of andere wedstrijden wellicht?

PS: ik sta niet in de ranglijst vermeld (Jaap van Wingerden) ???

NaliXL wijzigde dit bericht 01-10-2007 17:06 (16%)

quote:

NaliXL schreef op maandag 01 oktober 2007 @ 17:05:
Ik vond het zaterdag een ontzettend leuke dag, ondanks dat mijn sh$%*tty programma niet eens meegedaan heeft

Inderdaad, erg jammer dat je het niet goed werkend kreeg

quote:

Sjaaky schreef op maandag 01 oktober 2007 @ 15:22:
We hadden meer dan 30 inschrijving, maar uiteindelijk bleven er 12 over. Dat niet iedereen mee kon doen was jammer. Dit lag mede aan de soap interface, die voor velen toch meer voeten in de aarde had dan dat we hadden verwacht.

Misschien was het handiger geweest een interface (ik bedoel dus een echte interface zoals de taal Java die kent) te specificeren, zodat mensen alleen een klasse hoefden te schrijven die die interface implementeert, en dat jullie dan een stub aanleverden die de verbinding met de server regelt. Iets soortgelijks kun je ook voor C# doen. Dan zouden deelnemers er verder geen werk van hoeven maken.

Als je niet met SOAP bekend bent en uit moet gaan zoeken hoe al die libraries werken is het echt niet makkelijk. Ik kan me best voorstellen dat mensen daar over struikelden. Dat er nu mensen waren met vele megabytes aan libraries was ook niet echt makkelijk.

quote:

Ik moet diegenen die de gespeelde potten terug willen zien helaas teleurstellen, die partijen zijn we kwijt. Blijkt dat door een samenloop van een onduidelijk 'manager'-gui en verkeerd bedacht procedure we bij het invoeren van een nieuwe ronde de vorige ronde overschreven.

Ik was er al een beetje bang voor omdat jullie ze tijdens de wedstrijd ook niet konden vinden. Jammer, maar so be it.

Soultaker wijzigde dit bericht 01-10-2007 19:13 (9%)

quote:

Soultaker schreef op maandag 01 oktober 2007 @ 19:12:
Misschien was het handiger geweest een interface (ik bedoel dus een echte interface zoals de taal Java die kent) te specificeren, zodat mensen alleen een klasse hoefden te schrijven die die interface implementeert, en dat jullie dan een stub aanleverden die de verbinding met de server regelt. Iets soortgelijks kun je ook voor C# doen.

Ik weet niet of alle deelnemers afvielen vanwege de soap-interface. We hebben overwogen om gewoon een bestand te lezen en stdout te gebruiken, zoals gebruikelijk is tijdens de ACM ICPC en voorronden. Dan hadden we wel zelf iets moeten ontwikkelen om te communiceren met de gameserver. Wij werken als bedrijf veel met soap en webservices, dus was de keuze daarvoor al snel gemaakt.
Het idee was om mensen kennis te laten maken met soap. Maar dat het zo veel problemen op zou leveren hadden we niet voorzien. Als er nog een TJIP Challenge komt, gaan we hierin meer tegemoet komen.

In de praktijk merk ik vaak (los van soap overigens) dat je heel snel klaar kunt zijn met de basisfunctionaliteit en dat het interfacen met andere systemen dan voor de problemen zorgt. Zo heb ik een keer (wel soap) een legacy delphi 6 applicatie moeten laten praten met een .net webservice van microsoft die wse 2.0 attachments gebruikte. Natuurlijk geen bestaande delphi implementatie van te vinden. Om die zelf te implementeren vond ik te ver gaan. Toen heb ik maar een .net com component geschreven die delphi kon gebruiken. Dat leverde weer problemen op byte niveau op met structs, maar die problemen kon ik toen wel van 2 kanten oplossen.

Ik ben trouwens zelf ook bezig een soortgelijke wedstrijd te organiseren voor Stratego

Daar maken we zelf een client die kan praten met een java programma dat een interface implementeerd of met een native dll bestand dat dezelfde methodes bevat. Dit laat de deelnemers vrijwel helemaal vrij welke taal ze gebruiken en ze hoeven alleen een aantal methodes te implementeren. Nu is dat voor deze wedstrijd ook iets belangrijker omdat onze doelgroep vooral de bestaande programmas zijn die in allerlei talen geschreven zijn en we het voor de deelnemers zo laagdrempelig mogelijk willen maken.

http://www.strategousa.or...ratego_World_Championship

De finale van afgelopen zaterdag was een geslaagde dag! Ik heb het goed naar de zin gehad ondanks dat ik onderaan geeindigd ben.

Ik ben zelf wel een voorstander van het delen van de source code. Ik zal een link naar mijn source code (C#) voor het einde van de week hier op het forum plaatsen.

Soultaker: fijn dat je jouw source code online hebt gezet. Ga hier vandeweek eens een keer rustig voor zitten. Ik denk dat ik er een heleboel van kan leren!!

Zaterdag was het inderdaad gezellig, ik moest helaas eerder vertrekken ivm andere verplichtingen, toch wel jammer om te zien dat mijn programma het zo slecht heeft gedaan... maargoed, ik had ook niet veel meer verwacht, had de "AI" nog de avond er voor in elkaar geflanst .

quote:

Soultaker schreef op maandag 01 oktober 2007 @ 19:12:
Als je niet met SOAP bekend bent en uit moet gaan zoeken hoe al die libraries werken is het echt niet makkelijk. Ik kan me best voorstellen dat mensen daar over struikelden. Dat er nu mensen waren met vele megabytes aan libraries was ook niet echt makkelijk.

Als je Java gebruikt heb je 3rd party libraries helemaal niet nodig. Je kunt gewoon de WSDL importeren mbv wsimport, vervolgens een GameServer instantie maken en gaan met die banaan... hoeveel simpeler wil je het maken?

W4rlock wijzigde dit bericht 01-10-2007 23:59 (32%)

Ook ik vond de wedstrijd afgelopen zaterdag zeer geslaagd. Eigenlijk zou zoiets vaker georganiseerd moeten worden.

quote:

Als je Java gebruikt heb je 3rd party libraries helemaal niet nodig. Je kunt gewoon de WSDL importeren mbv wsimport, vervolgens een GameServer instantie maken en gaan met die banaan... hoeveel simpeler wil je het maken?

Als je het weet is het allemaal vrij eenvoudig inderdaad. Helaas staat wsimport niet echt bovenaan bij google, waardoor je er ook niet zomaar achter komt. Ik denk dat het een goed idee is om mensen hier wat mee te helpen door bijvoorbeeld een voorbeeld te geven.

quote:

Sjaaky schreef op maandag 01 oktober 2007 @ 20:26:
In de praktijk merk ik vaak (los van soap overigens) dat je heel snel klaar kunt zijn met de basisfunctionaliteit en dat het interfacen met andere systemen dan voor de problemen zorgt.

Ah. Eigenlijk was dat zaterdag ook het geval, met al die mensen (inclusief mezelf) die hun main loop niet goed hadden gestructureerd (eerst wachten op de server, dan inloggen, dan wachten op een ronde). Met puur de beschikbare methoden specificeren ben je er nog lang niet, en de hele interface specificeren is natuurlijk tricky ongeacht wat voor middleware je gebruikt.

quote:

W4rlock schreef op maandag 01 oktober 2007 @ 23:57:
Als je Java gebruikt heb je 3rd party libraries helemaal niet nodig. Je kunt gewoon de WSDL importeren mbv wsimport, vervolgens een GameServer instantie maken en gaan met die banaan... hoeveel simpeler wil je het maken?

Komt 'ie nu mee. Werkt dat wel met Java SE, of heb je daar EE voor nodig? Ik heb dat tooltje in ieder geval niet bij mijn JDK meegekregen.

Verder heb ik dat ook nergens kunnen vinden; ja, nu kan ik het wel vinden als ik op wsimport zoek, maar als je er niet mee bekend bent zijn dat soort dingen niet zo triviaal. Ik ram nu ook zo een CORBA client en server in elkaar als het moet, maar dat komt omdat ik er al uren tijd in heb gestoken (CORBA wordt over het algemeen als veel ingewikkelder dan SOAP beschouwd). Kortom: dat een professional het snel kan, betekent niet dat het voor iedereen makkelijk is.

Overigens vind ik het niet direct verkeerd dat er voor een SOAP interface gekozen was. Dit soort dingen uitzoeken en werkend krijgen is onderdeel van de uitdaging, en je had er weken de tijd voor. Het is echter wel jammer als een aantal mensen hierdoor helemaal niet mee konden doen.

quote:

Overigens vind ik het niet direct verkeerd dat er voor een SOAP interface gekozen was. Dit soort dingen uitzoeken en werkend krijgen is onderdeel van de uitdaging, en je had er weken de tijd voor. Het is echter wel jammer als een aantal mensen hierdoor helemaal niet mee konden doen.

Hoewel het inderdaad niet voor iedereen even makkelijk is, had je er inderdaad ruim een maand de tijd voor. Zelf heb ik ook nog een aantal vragen voorgelegd aan Corniel, waarop ik telkens binnen een aantal uren al antwoord heb gekregen. Tijdens de introductie-bijeenkomt is er ook aangegeven dat mensen contact op mochten nemen met Tjip bij problemen. Daarnaast was dit forum er ook nog eens. Het was dus voor iedereen die even doorzette prima mogelijk om die interface te implementeren.

Naar aanleiding van het feit dat we een aantal keer op 0-9 kwamen in het toernooi heeft Joost trouwens het openingsboek nog doorzocht op het grootste offer dat er in zat:

na de zettenreeks:
5 2 3 4 1 5 2 2 3 3 2 5 3 4 1 0

is dit de bordpositie
score: 0-10
1 11 0 0 1 10
0 10 1 1 1 2

de tegenstander staat dan maar liefst 10 punten voor. Op diepte 22 vind hij deze bordpositie echter ook +10 waard, en vanaf 24 zelfs +11, lijkt dus nog te kloppen ook

Iemand heeft het woord "re-match" in zijn mond gehad na de wedstrijd. Iemand al plannen gemaakt o.i.d.?

quote:

NaliXL schreef op woensdag 03 oktober 2007 @ 17:12:
Iemand heeft het woord "re-match" in zijn mond gehad na de wedstrijd.

Yep, we hebben plannen - de winnaars wilden een paper gaan schrijven geloof ik - en die willen vast ook partij-data hebben.

Daarnaast lijkt het ons ook heel leuk om wat meer te zien. Een toernooi is ook niet heel veel voor zoveel werk. Daarom mógen mensen een geupdate versie sturen. Vooral voor René Wareman en Jaap van Wingerden is dat dé uitgelezen kans, om hun engine echt te laten testen.

Als men dat doet, wel graag de aanlogprocedure als deze nog niet klopte. Hieronder in pseudo code wat we verwacht(t)en. (Ja dat hadden we veel eerder kunnen/moeten doen)
C:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

serverstate = proxy.GetServerStatus(); switch(surverstate) {     case Initializing:     case Loaded:         // Be patiant and try again.         break;     case: Finished:         // Stop trying.         break;     case Playing:          id = proxy.Logon("my name");                  // NOW Logon.         gamestate = proxy.GetMatchStatus(id);         switch(gamestate)         {             case None:             case Waiting:                 // Be patiant and try again.                 break;             case Won:             case Draw:             case Lost:                 // Game has ended, you may try again.                 break;             case Playing:                 startplayer = proxy.StartMatch(id);                 // Do moves, etc.         } }