Schaak applet

[Verwijderd]

Dag mensen.

Ik ben bezig met een site met een hele grote database met schaakpotjes erin. Het verloop van een potje staat in een string, en met die string is het vrij makkelijk om het hele verloop te bepalen. Nu wil ik natuurlijk graag dat mensen potjes kunnen gaan bekijken. Hier zijn meerdere mogelijkheden voor en ik heb er niet heel veel ervaring mee dus ik vraag jullie mening.

Er zijn een paar obvious oplossingen:

Java

Java kan wel, wordt vrij vaak voor zulke dingen gebruikt alleen heb ik een beetje een afkeer van Java en is het volgens mij vrij traag.

PHP

Elke zet gewoon met PHP genereren is code technisch voor mij het makkelijkst maar dit gaat zulke slome taferelen opleveren dat me dit niet echt de bedoeling lijkt. Voor elke zet een nieuwe request, alles weer inladen, no thanks.

Javascript

Dit lijkt me eigenlijk persoonlijk de beste oplossing. Je kunt de .js file mooi cachen, alleen de functie aanroepen met een string, die string haal je uit je DB met je php script waar je de JS ook mee uitpoept. Je kunt d.m.v. images verplaatsen ze mooi laten zien en ernaast een list hebben met zetten waar je doorheen kunt gaan.

Flash

Nul ervaring met flash, maar volgens mij kun je hier wel grafisch mooie dingen mee doen. Ik ga me hier nog wat meer in verdiepen, ik zou het altijd later nog kunnen omgooien.

Wat is jullie voorkeur in zo'n geval? Waarom?

[BtM909]

Er is geen voorkeur. Kies de taal die het dichtste bij je ligt en het beste bij dit probleem past. PHP valt af (als volledige engine), Java heb je afkeer tegen, Flash heb je nul ervaring mee, dus blijft JS over

[Verwijderd]

BtM909 schreef op donderdag 08 november 2007 @ 10:52:
Er is geen voorkeur. Kies de taal die het dichtste bij je ligt en het beste bij dit probleem past. PHP valt af (als volledige engine), Java heb je afkeer tegen, Flash heb je nul ervaring mee, dus blijft JS over

Ok, wel duidelijk Maar het is niet zo dat ik wat over het hoofd zie en dat javascript stiekem toch niet handig is voor zoiets? Ik heb ook niet veel ervaring met javascript maar daar moet ik wel uit zien te komen. Het zou alleen een beetje zonde zijn als ik 20 uur met een applet loop te prutsen en dan blijkt dat hij echt enorm haperig loopt op een dual core

[NMe]

Het hangt er natuurlijk vanaf hoe lang die strings zijn en hoe goed jij je code schrijft, maar wat je wil kan best gemaakt worden in Javascript. Het is niet per se de meest gangbare optie, maar het kán wel. Java zou overigens wel beter zijn, denk ik. Vanwaar die afkeer? Volgens mij is het trouwens ook allang niet meer zo traag als het ooit was, zeker niet sinds Java 5.

[Verwijderd]

Javascript , dan heeft de site Utrechtschaakt een mooie oplossing.

[Verwijderd]

-NMe- schreef op donderdag 08 november 2007 @ 11:22:
Het hangt er natuurlijk vanaf hoe lang die strings zijn en hoe goed jij je code schrijft, maar wat je wil kan best gemaakt worden in Javascript. Het is niet per se de meest gangbare optie, maar het kán wel. Java zou overigens wel beter zijn, denk ik. Vanwaar die afkeer? Volgens mij is het trouwens ook allang niet meer zo traag als het ooit was, zeker niet sinds Java 5.

Die afkeer komt van pogingen tot leren van 12 jaar geleden dus dat is niet echt een zinnig argument, ik weet het. Maar daaruit komt natuurlijk wel weer dat ik er nauwelijks ervaring mee heb. Maar misschien moet ik er wel eens naar kijken.

Zoals ik het nu heb ingericht bestaat die string uit 3 tekens per zet, dus gemiddeld iets van 300 tekens. Aangezien de tekens niet aangepast worden en het alleen maar een spelverloop laat zien leek me Javascript wel een redelijke oplossing. Wat zijn in dit geval dan de voordelen van Java? Een van de nadelen is natuurlijk wel de nodigheid van een geinstalleerde Java, al zal dat niet erg van belang zijn.

EDIT: Ja zoiets als die applet bedoel ik, alleen genereert deze alles op basis van de zetten, bij mij gaan er ook nog een paar bits per zet mee voor de soort actie om sneller te kunnen genereren wat er nou echt gebeurt is, zoals een gewone zet, een roccade, slaan, en passant slaan enzovoorts. Dit zou de tijd om in een keer naar zet 60 te gaan wel moeten verkorten.

[ Voor 13% gewijzigd door Verwijderd op 08-11-2007 11:48 ]

[Verwijderd]

Verwijderd schreef op donderdag 08 november 2007 @ 11:28:
[...]


Die afkeer komt van pogingen tot leren van 12 jaar geleden dus dat is niet echt een zinnig argument, ik weet het. Maar daaruit komt natuurlijk wel weer dat ik er nauwelijks ervaring mee heb. Maar misschien moet ik er wel eens naar kijken.

Zoals ik het nu heb ingericht bestaat die string uit 3 tekens per zet, dus gemiddeld iets van 300 tekens. Aangezien de tekens niet aangepast worden en het alleen maar een spelverloop laat zien leek me Javascript wel een redelijke oplossing.

JavaScript is zeker een redelijke oplossing. Is het een commercieel iets? Ik ben namelijk bezig met een JavaScript based schaakspel als persoonlijk expirimentje. Het zou niet moeilijk moeten zijn om het te modificeren zodat het een string kan afspelen. Ik zal later vandaag wel even wat online zetten zodat je het kunt zien. Wat mij betreft kun je die code gewoon gebruiken.

Hoe ziet zo'n string eruit trouwens?

[Verwijderd]

@Dzy 3 tekens per zet ?
Dan moet je toch ff opnieuw gaan redeneren. Wat nu als er 2 paarden naar hetzelfde veld kunnen ?

[Verwijderd]

Het is nu nog een persoonlijk experimentje, maar het is wel de bedoeling mocht het ooit af komen het een beetje commercieel te maken, in ieder geval wat ads om de server kosten er uit te halen en misschien wel meer.

De bedoeling van de site is een hoop potjes van bekende schakers in een database te gooien, te kunnen zoeken op spelers, openingen, toernooien e.d. Reacties geven op items, commentaar leveren bij potjes, waarom iemand zoiets doet of wat hij beter had kunnen doen.

Zoals ik het nu heb is het het volgende formaat:

1e byte: De plek waar vanaf hij zet.
2e byte: De plek waar het stuk naar toe gaat.
3e byte: Type actie. Gewone zet, stuk slaan, en passant slaan, rocceren, een bit erbij voor of je iemand schaak zet.

Zo kun je ze makkeijk naar tekens formen die JS begrijpt, die gewoon in de database gezet kunnen worden en waarmee je in de database redelijk makkelijk kunt zoeken op openingen.

EDIT: @al_sole: Zoals je hier kunt lezen is 3 tekens genoeg Met 3 tekens bedoel ik gewoon bytes. Dus elke zet neemt 3 bytes van de string in beslag. En met een zet bedoel ik 1 zet van wit of van zwart. Narrenmat is dan dus 4 zetten, en niet 2.

[ Voor 11% gewijzigd door Verwijderd op 08-11-2007 12:08 ]

[Verwijderd]

als je dan naar zet 60 gaat ga je de tekenreeksen tellen i.p.v. lezen in de string, lijkt me langzamer maar ik ben maar een rookie

[Verwijderd]

Je moet hoe dan ook de zetten door gaan berekenen om naar zet 60 te gaan behalve als je bij elke zet de state op slaat wat echt enorm veel data zou worden dan. Nu zet je uiteraard de string aan het begin van de applet om in makkelijk bruikbare zetten, maar die string is wel makkelijker in de database. Kun je ook mooi met een LIKE "zet1zet2zet3zet4%" naar openingen zoeken.

[YopY]

Ik zou voor Java gaan. Met Java kun je (in mijn mening) veel eenvoudiger geavanceerde functies toevoegen, zoals animatie, bladeren door een potje, of, als je wilt, zelfs de gebruiker de mogelijkheid geven tot het zelf spelen van een potje. Java geeft zeer goede mogelijkheden tot abstractie van een potje schaken.

Het is wel zo dat het een paar weken kan duren voordat je het helemaal onder de knie hebt, afhankelijk van je ervaring met OO in PHP en programmeren in het algemeen, en afhankelijk van hoeveel tijd je erin investeerd.

Javascript zou ook een mogelijkheid zijn, maar dan zit je weer met andere problemen - weergave, transitie van een zet naar de andere, enzovoort. Veel hiervan moet je zelf uit zien te vinden, terwijl Java veel meer al ingebouwd heeft voor dit soort zaken.

Het is een afweging tussen een web app en een 'echte' app. Beide hebben zo hun voor en nadelen.

[Verwijderd]

Ik heb heel veel ervaring met PHP programmeren en genoeg met OO programmeren. Dat zou in principe dus geen barriere opleggen. Het is sowieso handig om nieuwe dingen te leren dus dat is geen obstakel. Tijd hoeft niet zo nodig het probleem te zijn. Spelletjes zelf spelen zodat je ze kunt toevoegen aan de database is uiteraard heel handig, dat was ook later de bedoeling maar alleen maar handig dat dat sneller gaat hierlangs. Ik ga eens kijken wat ik allemaal nodig heb om java te gaan beginnen. Dan ga ik de afweging maken.

Bedankt

[RobIII]

Verwijderd schreef op donderdag 08 november 2007 @ 12:06:
1e byte: De plek waar vanaf hij zet.
2e byte: De plek waar het stuk naar toe gaat.
3e byte: Type actie. Gewone zet, stuk slaan, en passant slaan, rocceren, een bit erbij voor of je iemand schaak zet.

Ik heb maar even vluchtig het topic bekeken (sta op het punt om te vertrekken) maar a) waarom een byte? en b) type actie (byte 3) volgt toch automatisch uit 1 en 2? Of ben ik nou gek?

[Verwijderd]

RobIII schreef op donderdag 08 november 2007 @ 14:53:
[...]

Ik heb maar even vluchtig het topic bekeken (sta op het punt om te vertrekken) maar a) waarom een byte?

Zo kan ik ze meegeven in een leesbaar character die je dus via een get mee kan geven, normaal in een database kan storen, kunt copy/pasten via wat voor manier dan ook, etc. Aangezien je 8x8 plekken op een bord hebt zou je dan op 6 bits uitkomen om het precies erin te storen dus dat zou dan 4 bits per zet schelen. Er een hele byte van maken scheelt een hoop gezeur, maar dit was essentieler voor Javascript dan voor Java denk ik.

b) type actie (byte 3) volgt toch automatisch uit 1 en 2? Of ben ik nou gek?

Klopt bijna. Maar zoals ik al aangaf zorgt dit voor snellere processing omdat je nu makkelijk kunt aangeven wat voor soort actie het is zonder de zet te gaan evalueren. Nu kun je gewoon afhankelijk van de actie stukken weglaten of de toren ook verzetten bij een roccade. En een heel klein beetje gek ben je wel ja, want hier kan ik ook in storen welk stuk ze nemen bij een pion die de overkant bereikt. Al is dit natuurlijk 99% van de tijd een koningin

EDIT: Ik ben een beetje met Java aan het klooien maar ik kan met Java ook mooi met MySQL klooien, waarmee ik dus mijn games veel mooier kan opslaan in een database. Gewoon los de zetten erin zetten met een foreign key naar de game table. Zo kan ik mooier gaan filteren op openingen en game states. Al gaat die met die game states OF heel veel ruimte in mijn database OF heel veel processor kracht op mijn server innemen. Daar moet ik even over denken maar een evt. oplossing zou wel zijn dat je een betaalde account van een paar dollar per maand kunt nemen, net zoiets als bij tweakers en dat je dan gemachtigd bent te zoeken op game states. Maar ik raak een beetje offtopic (nouja off-huidige-subject).

Ik ga het wel in Java doen. Ik leer het best snel

Wat zouden jullie doen? Een string met een bepaalde syntax of gewoon met een mooie tabel met zetten? Ik ben er nog niet helemaal over uit. Ik vind voor beide wel wat te zeggen.

[ Voor 27% gewijzigd door Verwijderd op 08-11-2007 15:47 ]

[YopY]

Geheugenverbruik valt best wel mee als je de process explorer even in de gaten houdt. Ik heb zelf programma's in Java geschreven die vele duizenden objecten aanmaken en beheren, en het geheugenverbruik gaat maar met een paar MB omhoog wanneer die objecten ingeladen worden.

Daarnaast vind ik dat argument van die extra byte voor het opslaan van het type zet een beetje... tsja. Computers, zeker als je het in een Java applet gaat doen (client-size) zijn zodanig snel dat de besparing die je hiermee oplevert waarschijnlijk minder dan een milliseconde is. Sterker nog, ik durf bijna te zeggen dat de tijd die het duurt om die extra byte in te lezen nog groter is dan de tijd die het duurt om te bepalen wat voor type zet het is. Ik bedoel, het is een aantal if-statements (als ik het goed heb), en als er iets is wat ondertussen wel snel is in programma's, dan zij het wel if statements.

Wat zouden jullie doen? Een string met een bepaalde syntax of gewoon met een mooie tabel met zetten? Ik ben er nog niet helemaal over uit. Ik vind voor beide wel wat te zeggen.

Beide . Nah, ik weet niet wat handiger is - qua verwerkingssnelheid maakt het waarschijnlijk niet zoveel uit. Voor het kopieren / plakken en (evt) uittypen van de gegevens is een string met een bepaalde syntax waarschijnlijk vlotter.

[ Voor 19% gewijzigd door YopY op 08-11-2007 16:18 ]

[Verwijderd]

Je hebt gelijk wat betreft die extra byte voor de zetten doen. In Java kun je het wel makkelijker bekijken. Toch blijft het argument van welk type de pion wordt wel overeind staan. Ik maak er wel eens een toren van, of af en toe een paard. Nu komt dat uiteraard niet vaak voor maar het hoort wel bij de regels van schaken.

Pak ik het hele geheel verkeerd aan of zit ik wel in de goede richting?

[Soultaker]

In principe ben ik het met BtM909 eens: neem gewoon wat je geschikt lijkt. Verder zijn HTML (PHP) en JavaScript wat lichter en algemener beschikbar dan Java en Flash, dus dat zou mijn voorkeur hebben.

Ik wil nog wel toevoegen dat ik niet denk dat PHP te traag is hiervoor. Het gaat om een keer een stuk of honderd zetten die je moet uitvoeren voor een request; dat is echt niet belachelijk veel als je site niet ontzettend druk bezocht wordt. Een belangrijker argument vóór JavaScript (in plaats van HTML gegenereerd met PHP) is dat het voor de gebruiker veel responsiever is. Als je voor elke zet een nieuwe pagina moet opvragen, is dat best wel vervelend.

[Alex)]

^^ wat Soultaker zegt

Als ik een potje schaken wil inzien, dan wil ik gewoon kunnen doorklikken zonder pageloads/postbacks... AJAX is dan een redelijke oplossing, maar het kan sneller. Gewoon alles preloaden en dan wisselen wanneer het nodig is...

[Verwijderd]

Alex) schreef op donderdag 08 november 2007 @ 20:12:
^^ wat Soultaker zegt

Als ik een potje schaken wil inzien, dan wil ik gewoon kunnen doorklikken zonder pageloads/postbacks... AJAX is dan een redelijke oplossing, maar het kan sneller. Gewoon alles preloaden en dan wisselen wanneer het nodig is...

Ja maar daarom moet je ook geen php gebruiken, daar was ik al wel uit. Ik ben nu een beetje aan het klooien met Java, ik verwacht binnenkort er wel eentje werkend te hebben. =)