Schaakgame implementeren: validatie front- en backend?

[MartenBE]

Als hobbyproject ben ik een schaakvariant voor 4 spelers aan het implementeren om met enkele vrienden online te kunnen spelen. Een soort eenvoudige lichess-variant dus. Nu gebruik ik TypeScript voor de frontend en Django Channels voor de backend. Er wordt aangeraden om altijd op de server de checks uit te voeren (bv. is een zet geldig) om er zeker van te zijn dat niemand de boel probeert te manipuleren. Aan de andere kant is het handig als ook de frontend zulke zaken kan controleren: dit vermijd foutieve requests aan de server en zorgt voor meer directe respons aan de gebruiker.

Het probleem zit er in dat er nog geen libraries bestaan voor dit spel. Ik heb een kladversie gemaakt voor de frontend, maar zou ook de regels moeten implementeren in python voor de backend. Dit lijkt me veel dubbel werk, dat problemen kan geven naar onderhoud later toe. Hoe los ik dit het beste op?

1. Implementeer de spellogica zowel in TypeScript voor de client, als in Python voor de server en onderhoud beide.
2. Implementeer de spellogica enkel in Python voor de server en wacht telkens op antwoord van de server.
3. Implementeer de spellogica enkel in Python en probeer dit ook te gebruiken in de frontend via Brython of dergelijke.

Dit probleem staat blijkbaar bekend als het "authoritive server problem", maar ik vind niet veel terug over deduplicatie in dit geval. Wat denken jullie ?

[chielsen]

Alternatief: gebruik node als backend zodat je de regels makkelijk kan hergebruiken?

[MarcoC]

Probeer de regels vast te leggen in een formaat zoals.JSON en implementeer een functie die jouw zelf bedachte formaat om regels vast te leggen implementeert in de backend. Laat de frontend vervolgens lekker voor wat het is totdat het echt nodig is. De frontend draait client-side en mag "kapot" gaan, het ergste wat kan gebeuren is een slechte gebruikerservaring.

[RobIII]

Het enige wat je nodig hebt is een soort IsValidMove($gameid, $move) waarbij ik even aanneem dat je de stukken en het spelbord ("het potje") opslaat in een "game" die je een ID geeft o.i.d. en uit je sessie haalt ofzo en in $move iets als "Qa7" stuurt (of weet-ik-veel hoe schaaknotatie werkt). Die functie returned true/false en kun je dan in je backend gebruiken en met een Ajax call ook in je frontend.

[Voor 22% gewijzigd door RobIII op 02-02-2021 17:23]

[Semyon]

RobIII schreef op maandag 1 februari 2021 @ 23:53:
Het enige wat je nodig hebt is een soort IsValidMove($gameid, $move) waarbij ik even aanneem dat je de stukken en het spelbord ("het potje") opslaat in een "game" die je een ID geeft o.i.d. en uit je sessie haalt ofzo en in [move]$move[/] iets als "Qa7" stuurt (of weet-ik-veel hoe schaaknotatie werkt). Die functie returned true/false en kun je dan in je backend gebruiken en met een Ajax call ook in je frontend.

Dat is z'n optie 2)
Maar dat heeft als nadeel dat je telkens moet wachten. Bijvoorbeeld een mouseover effect als je over een schaakstuk heen gaat dat de plekken van legale moves laat zien (zoals chess.com dat bijvoorbeeld doet, die hebben trouwens ook een 4 speler schaakspel!) is dat niet zo mooi meer.

[RobIII]

Semyon schreef op dinsdag 2 februari 2021 @ 00:00:
Dat is z'n optie 2)

Die las ik meer als een complete page(re)load.

Semyon schreef op dinsdag 2 februari 2021 @ 00:00:
Maar dat heeft als nadeel dat je telkens moet wachten.

Dat hoeft geen minuten of secondes te zijn natuurlijk. Een beetje request is onder de 100ms afgehandeld. En anders kun je nog altijd naar WebRTC/Websockets en weet-ik-veel kijken maar dan ga je IMHO overengineeren.

Semyon schreef op dinsdag 2 februari 2021 @ 00:00:
Bijvoorbeeld een mouseover effect als je over een schaakstuk heen gaat dat de plekken van legale moves laat zien (zoals chess.com dat bijvoorbeeld doet, die hebben trouwens ook een 4 speler schaakspel!) is dat niet zo mooi meer.

Dat was de vraag niet, maar ook hier geldt weer: dat is prima server-side "uit te rekenen" en te returnen in eoa JSON responsje in minder dan 100ms. We hebben 't hier niet over een schaakspelletje op Facebook schaal met miljoenen gebruikers op een 4GB shared hosting machientje he?

Als je geen zin hebt om zaken 2 keer te implementeren dan zul je ze dus maar 1 keer moeten implementeren en gezien server-side leading is zal het op z'n minst daar moeten werken. Met zaken als Blazor etc. trek je dat vrij makkelijk naar de client en met Typescript zou dat AFAIK ook moeten kunnen maar daar heb ik geen/amper ervaring mee i.c.m. Python/Django.

[Voor 14% gewijzigd door RobIII op 02-02-2021 00:10]

[MarcoC]

Semyon schreef op dinsdag 2 februari 2021 @ 00:00:
[...]


Dat is z'n optie 2)
Maar dat heeft als nadeel dat je telkens moet wachten. Bijvoorbeeld een mouseover effect als je over een schaakstuk heen gaat dat de plekken van legale moves laat zien (zoals chess.com dat bijvoorbeeld doet, die hebben trouwens ook een 4 speler schaakspel!) is dat niet zo mooi meer.

Het gaat er om wat je wilt bereiken:
1. Een goede gebruikerservaring? Dan implementeer je de ruling in frontend én backend (om manipulatie te voorkomen). Eventueel kan je ook iets met websockets verzinnen als je een minimale vertraging acceptabel vindt en geen zin hebt om logica tweemaal te implementeren.
2. Manipulatie voorkomen? Dan is validatie in de backend voldoende.

[Semyon]

RobIII schreef op dinsdag 2 februari 2021 @ 00:03:
[...]

Die las ik meer als een complete page(re)load.

Hij schreef "telkens"

RobIII schreef op dinsdag 2 februari 2021 @ 00:03:
Dat hoeft geen minuten of secondes te zijn natuurlijk. Een beetje request is onder de 100ms afgehandeld. En anders kun je nog altijd naar WebRTC/Websockets en weet-ik-veel kijken maar dan ga je IMHO overengineeren.

Het hangt er misschien af wat je er precies mee wil doen. Voor een "is deze zet goed" is een server call puik. Maar als je een mouse over effect will implementeren is die latency echt funest.

Ook als je server alleen "is move X" goed wil, maar je client wil "laat alle legale moves voor schaakstuk Y zien" (zoals chess.com dat doet) dan is je logica perhaps niet helemaal maar parallel.

Misschien hangt het er vanaf wat MartenBE er precies mee wil?

[Voor 12% gewijzigd door Semyon op 02-02-2021 00:16]

[Hydra]

Oh leuk! Ik heb jaren geleden exact dit gebouwd, in NodeJS + AngularJS. Met websockets.

Validatie in de front-end heeft over het algemeen een ander doel dan die in de back-end. Validatie in de front end is vooral bedoeld om en gebruiker te helpen; dus door een nette melding te geven dat iets niet mag, en waarom niet. In de back-end is het anders; daar mag data niet in een invalid state terecht komen. Vandaar dus dat suggesties om code te kunnen hergebruiken niet zo veel waarde hebben. Dus het argument dat je met Node in zowel de FE als de BE dezelfde code can gebruiken, gaat ook daar meestal niet op.

That said; schaak is wel een beetje een uitzondering op de regel omdat de validateregels daar vrij complex zijn, en je die meestal niet 2 keer wil implementeren. Ook 'genereer' je voor elk stuk elke mogelijke move. Wat je prima kunt doen is daar dus gewoon een call in je back-end voor maken; die code zal daar hoe dan ook al aanwezig zijn. Want in de front-end hoef je natuurlijk niet echt specifieke meldingen te geven. Je zou hoogstens in je UI weer kunnen geven waar een stuk naartoe mag.

[Hydra]

Semyon schreef op dinsdag 2 februari 2021 @ 00:10:
Het hangt er misschien af wat je er precies mee wil doen. Voor een "is deze zet goed" is een server call puik. Maar als je een mouse over effect will implementeren is die latency echt funest.

En toch werken heel veel user interfaces zo.

IMHO is die logica ook naar de front-end gaan brengen altijd nog een optie, maar een premature optimization. Dat soort dingen kan 'ie gaan doen als z'n site echt een commercieel succes gaat worden.

[Hydra]

MarcoC schreef op dinsdag 2 februari 2021 @ 00:05:
Eventueel kan je ook iets met websockets verzinnen als je een minimale vertraging acceptabel vindt en geen zin hebt om logica tweemaal te implementeren.

Via websockets gaat dit niet op magische wijze sneller. Maar het is hoe dan ook best wel een non-issue. Die 50ms ofzo heeft niemand last van in een schaakspelletje. Daarbij kun je ze in de FE ook cachen.

[matk89]

Precies wat Hydra zegt: implementeer het eerst maar back-end only en zie wat er gebeurt. Misschien juist wel voor een hobbyprojectje interessant om te zien wat voor latencies je gaat ervaren? Ik neem bovendien even aan dat je de front-end en back-end op dezelfde machine host? Dan heb je natuurlijk al helemaal geen netwerk overhead. Afhankelijk van je code quality van de front-end kan renderen meer tijd kosten dan het halen van je data bij de back-end.

Alternatief is dat je na iedere move confirmation voor alle stukken alle mogelijke zetten teruggeeft aan de front-end. Echt niet enorm veel data en de front-end heeft het in cache beschikbaar om te tonen wanneer nodig. Of, als je een oefening voor jezelf in cache invalidation wilt toevoegen: Check na een zet welke stukken mogelijk andere zetten mogen doen en vraag alleen die op van de back-end. Maar wederom: Dat is premature optimization en in dit geval wss niet nodig anders dan als oefening voor jezelf.

[MarcoC]

Hydra schreef op dinsdag 2 februari 2021 @ 08:08:
[...]


Via websockets gaat dit niet op magische wijze sneller. Maar het is hoe dan ook best wel een non-issue. Die 50ms ofzo heeft niemand last van in een schaakspelletje. Daarbij kun je ze in de FE ook cachen.

Websockets zijn wel degelijk sneller dan HTTP calls naar een backend.

[RobIII]

MarcoC schreef op dinsdag 2 februari 2021 @ 09:03:
[...]

Websockets zijn wel degelijk sneller dan HTTP calls naar een backend.

Als dat zo is (laten we dat even in 't midden laten), dan is de vraag: is die paar milliseconden merkbaar? Zo niet: boeie wat je kiest.

[rescla]

Ik ben niet heel thuis in het schaken, maar in de basis zitten er vaak wel verschillen tussen wat de frontend en de backend moet weten, en voor welk doel.

Het tonen van velden waar je mogelijk terecht kan komen is wat anders dan het valideren of een zet wel of niet had gemogen. Het laatste is ook een stuk sneller, aangezien je alleen hoeft te weten of het waar is of niet, in plaats van dat je een lijstje van mogelijkheden moet maken.

Voor de lol kan je het overigens ook zo opzetten dat je een consensus onder de spelers bereikt over wat de waarheid is. Als de meerderheid van de spelers (frontends) het eens is dat een zet mag, dan is het een valide zet. Je moet dan nog wel zorgen dat elke frontend maar 1x kan stemmen, en dat er een mechanisme is om de berichten uit te wisselen en te valideren. De backend is dan doorgeefluikt, alle code voor validatie zit aan de frontend.

Het helpt ook wel om een lijstje van (mogelijke) eisen/requirements te hebben en die op volgorde te zetten. Wil je bijvoorbeeld een leaderboard, volledige zethistorie per potje, ELO, etc. Als je al die historie niet nodig hebt kan je een client van de tegenstander ook gewoon laten checken of die zet volgens hem klopt. Of helemaal niet checken, sociale druk in een vriendengroep is ook een manier om eerlijkheid te garanderen.

Overigens heeft het ook niet zo veel zin om validatie te hebben als je nog geen zetten kan sturen naar elkaar. Dus ik zou gewoon beginnen met iets super simpels, zoals alleen zetten versturen en die op het scherm tonen. Misschien zelfs beginnen met alleen de notatie, dus meer alsof je via een chat zit te schaken. En daarna pas het programmatisch verwerken. Met andere woorden, Agile werken

[GrooV]

MarcoC schreef op dinsdag 2 februari 2021 @ 09:03:
[...]

Websockets zijn wel degelijk sneller dan HTTP calls naar een backend.

Misschien wel sneller maar niet bedoeld voor request/response berichten

[Bart2005]

Even afgezien van waar het komt: bij schaken genereer je sowieso (althans dat is gebruikelijk) een lijst met legale zetten voor de speler aan zet. Die kun je o.a. gebruiken in de interface om legale zetten met een stuk weer te geven, zorgen dat een stuk zonder legale zetten geblokkeerd is in de interface, en gewoon illegale zetten weigeren uit te voeren.

[MarcoC]

RobIII schreef op dinsdag 2 februari 2021 @ 09:31:
[...]

Als dat zo is (laten we dat even in 't midden laten), dan is de vraag: is die paar milliseconden merkbaar? Zo niet: boeie wat je kiest.

Dat klopt, ik zou die logica dan ook niet eens in de frontend implementeren. Veel gedoe voor weinig waarde.

[Hydra]

MarcoC schreef op dinsdag 2 februari 2021 @ 09:03:
Websockets zijn wel degelijk sneller dan HTTP calls naar een backend.

Want? Je hebt dezelfde round-trip tijd. Je back-end weet niet magischerwijs wat 'ie moet gaan sturen voordat je opdracht geeft. De overhead van het opzetten van de connectie, als die al niet in leven gehouden wordt, is niet voelbaar voor gebruikers.

WebSockets zijn gewoon complexer in het gebruik bij request-response en als je voor die extra complexiteit gaat, doe je dat neem ik aan voor meer dan de 2ms die het opzetten van een connectie eventueel kost.

[Voor 19% gewijzigd door Hydra op 02-02-2021 10:14]

[Hydra]

GrooV schreef op dinsdag 2 februari 2021 @ 09:43:
Misschien wel sneller maar niet bedoeld voor request/response berichten

Het kan wel hoor, het is alleen wat complexer. Ik heb zelf websockets gebruikt omdat het een multiplayer chess server was, en je client dus moves van de tegenstander gepushed moet krijgen. Dat is een argument om websockets te gebruiken. 'Snelheid' is dat niet.

[MartenBE]

Ow, veel reacties !

Het is een soort schaakvariant, maar de regels wijken daar sterk vanaf (andere soorten stukken en verplaatsingsregels). Bv. de paden van de stukken liggen niet vast, maar kunnen sterk afwijken. Je kan dus niet met simpele berekeningen op de coordinaten de mogelijke moves berekenen, er is path finding nodig. Er zijn dus ook heel veel mogelijke volgende zetten. Nu het is wat lastig om in te gaan op de spelregels, aangezien het gepatenteerd is en ik nog geen toestemming heb van de eigenaar om deze publiek te zetten (hij weet wel van het project).

Dat het sowieso in de backend moet, was ik al aan uit. Dus ik programmeer het spel sowieso in Python. Het zal ook sowieso met websockets gebeuren, zodat updates meteen van server naar client gaan bij de spelers (bij HTTP moet je anders de hele tijd pollen). Node zou ik graag willen vermijden omdat ik javascript geen aangename taal vind om in te werken (voor de client een noodzakelijk kwaad).

De logica in de frontend zou vooral dienen om de speler te helpen geen invalide zetten te doen om zo onnodig verkeer tussen client en server te vermijden. Ik had gehoopt om met behulp van brython ofzo de python code hiervoor te kunnen hergebruiken, maar ik vind daar niet zoveel van terug.

[Freeaqingme]

chielsen schreef op maandag 1 februari 2021 @ 23:42:
Alternatief: gebruik node als backend zodat je de regels makkelijk kan hergebruiken?

Als je dan al code zou willen hergebruiken, denk ik dat je anno 2021 hier echt niet per se Node voor hoeft te gebruiken. Ik zou dan eerder kijken naar Web-ASM (WASM), daarmee kan je zo ongeveer ieder mogelijke taal in de browser draaien.

[Mr. HTTP]

Freeaqingme schreef op dinsdag 2 februari 2021 @ 12:42:
[...]
Als je dan al code zou willen hergebruiken, denk ik dat je anno 2021 hier echt niet per se Node voor hoeft te gebruiken. Ik zou dan eerder kijken naar Web-ASM (WASM), daarmee kan je zo ongeveer ieder mogelijke taal in de browser draaien.

WebAssembly gebruiken is toch alleen logisch als je hardware/apparaten wilt aanspreken.. Voor een schaakspel heb je geen low-level code nodig...

[Freeaqingme]

Mr. HTTP schreef op dinsdag 2 februari 2021 @ 13:31:
[...]


WebAssembly gebruiken is toch alleen logisch als je hardware/apparaten wilt aanspreken.. Voor een schaakspel heb je geen low-level code nodig...

Dan zou ik me nog even inlezen. Het mooie aan WebAssembly is dat je het in nagenoeg iedere programmeertaal kan schrijven, en vervolgens middels een aparte compiler kan compileren naar WebAssembly. Je schrijft dus niet zelf Assembly.

[Mr. HTTP]

Freeaqingme schreef op dinsdag 2 februari 2021 @ 13:44:
[...]
Dan zou ik me nog even inlezen. Het mooie aan WebAssembly is dat je het in nagenoeg iedere programmeertaal kan schrijven, en vervolgens middels een aparte compiler kan compileren naar WebAssembly. Je schrijft dus niet zelf Assembly.

Het concept van WebAssembly is me inmiddels wat duidelijker. En onderstaande quote verwoord het goed.

Think about the cases where you need to use software outside of the browser: video games, video editing, 3D rendering, or music production. These applications do a lot of calculations and require a high degree of performance. That kind of performance is hard to get from JavaScript.

Het is dus praktisch gezien handig om onderdelen van je project in WebAssembly te doen waar JavaScript of Browser API's te kort schieten (qua performance bijv). Alles doen via de WebAssembly laag is overkill.

(Sorry voor deze off-topic-heid )

[Bart2005]

MartenBE schreef op dinsdag 2 februari 2021 @ 12:05:
Ow, veel reacties !
Je kan dus niet met simpele berekeningen op de coordinaten de mogelijke moves berekenen, er is path finding nodig.

Dit is bij gewoon schaken ook zo. Een zettengenerator heet dat. Je dient het bord te scannen op eigen/vijandelijke stukken/vrije velden. Dat levert een lijst semi-legale zetten. Vervolgens dienen die nog getest te worden op legaliteit (bij schaken of je je koning niet in schaak plaatst met de zet of de koning in schaak laat staan en of je door schaak heen rokeert cq schaak komt te staan). Niemand heeft gezegd dat het eenvoudig is. Maar zoiets heb je wel nodig en het lijkt het nuttigste als die in de interface zit.

[RobIII]

Bart2005 schreef op dinsdag 2 februari 2021 @ 15:04:
Maar zoiets heb je wel nodig en het lijkt het nuttigste als die in de interface zit.

Uh, het belangrijkst is dat 't in de backend zit. Daar vindt de (leidende) validatie plaats. In de frontend is 't geen vereiste maar een 'nice to have' (los van hoe belangrijk je 't subjectief vindt natuurlijk). Als je 't kan doen in 't frontend, en dan helemaal ook nog eens zonder dubbel werk te hoeven doen (hence 't topic van TS) dan is dat natuurlijk fijn.

[armageddon_2k1]

Freeaqingme schreef op dinsdag 2 februari 2021 @ 13:44:
[...]


Dan zou ik me nog even inlezen. Het mooie aan WebAssembly is dat je het in nagenoeg iedere programmeertaal kan schrijven, en vervolgens middels een aparte compiler kan compileren naar WebAssembly. Je schrijft dus niet zelf Assembly.

Kuch. Er zijn nog niet gek veel talen die goed WebAssembly als target hebben. Er missen nog veel features. Daarnaast is DOM manipulatie gewoon nog retetraag.

WebAssembly: Mooie techniek en beloftes, maar buiten hele specifieke use-cases om zou ik het nog even niet gebruiken.

[RobIII]

armageddon_2k1 schreef op dinsdag 2 februari 2021 @ 15:43:
[...]


Kuch. Er zijn nog niet gek veel talen die goed WebAssembly als target hebben.

Best wel wat hoor. Ook voor Python.

armageddon_2k1 schreef op dinsdag 2 februari 2021 @ 15:43:
Er missen nog veel features. Daarnaast is DOM manipulatie gewoon nog retetraag.

In dit geval hebben we 't niet over DOM manipulatie maar over de implementatie van een 'validatie' van "schaak"zetten. Een 'schaakengine' zo je wil.

armageddon_2k1 schreef op dinsdag 2 februari 2021 @ 15:43:
maar buiten hele specifieke use-cases om zou ik het nog even niet gebruiken.

Laten we hier nou net zo'n use-case hebben.

Verder ben ik zéker geen wasm expert, maar volgens mij ondersteunen alle zichzelf respecterende browsers 't al jaaaaren en trek ik die "missen nog veel features" dus een beetje in twijfel. Microsoft zet er met Blazer (o.a.) in ieder geval behoorlijk op in.

[Voor 17% gewijzigd door RobIII op 02-02-2021 15:53]

[Bart2005]

RobIII schreef op dinsdag 2 februari 2021 @ 15:38:
[...]

Uh, het belangrijkst is dat 't in de backend zit. Daar vindt de (leidende) validatie plaats. In de frontend is 't geen vereiste maar een 'nice to have' (los van hoe belangrijk je 't subjectief vindt natuurlijk). Als je 't kan doen in 't frontend, en dan helemaal ook nog eens zonder dubbel werk te hoeven doen (hence 't topic van TS) dan is dat natuurlijk fijn.

Nou ja als je in de interface kunt zorgen dat er geen illegale zetten gedaan kunnen worden dan hoef je denk ik niet te valideren. Maar misschien begrijp ik het niet goed. Als je een legale zettengenerator hebt gemaakt dan kun je die toch aan de voor- en achterkant gebruiken met dezelfde code? Dat lijkt me geen dubbel werk.

[RobIII]

Bart2005 schreef op dinsdag 2 februari 2021 @ 16:02:
[...]

Nou ja als je in de interface kunt zorgen dat er geen illegale zetten gedaan kunnen worden dan hoef je denk ik niet te valideren.

Never trust clients. Regel nr. 1 in client-server applicaties.

Bart2005 schreef op dinsdag 2 februari 2021 @ 16:02:
Maar misschien begrijp ik het niet goed. Als je een legale zettengenerator hebt gemaakt dan kun je die toch aan de voor- en achterkant gebruiken met dezelfde code? Dat lijkt me geen dubbel werk.

Daar gaat dit topic dus over. Je zou 't (bij wijze van) in Python in de backend kunnen implementeren, maar dat werkt niet in de browser; waardoor je 't dan (bijvoorbeeld) een tweede keer zou moeten implementeren in JS. De vraag van TS is dus: hoe voorkom je dat. En daar gaat 't al 't hele topic over

[Hydra]

Bart2005 schreef op dinsdag 2 februari 2021 @ 16:02:
[...]

Nou ja als je in de interface kunt zorgen dat er geen illegale zetten gedaan kunnen worden dan hoef je denk ik niet te valideren.

Het is geen 2005 meer. Valideren doen we in de back-end.

Edit: Ben jij de maker van Kallisto?

[Voor 6% gewijzigd door Hydra op 02-02-2021 16:27]

[armageddon_2k1]

RobIII schreef op dinsdag 2 februari 2021 @ 15:46:
[...]

Best wel wat hoor. Ook voor Python.


[...]

In dit geval hebben we 't niet over DOM manipulatie maar over de implementatie van een 'validatie' van "schaak"zetten. Een 'schaakengine' zo je wil.


[...]

Laten we hier nou net zo'n use-case hebben.

Verder ben ik zéker geen wasm expert, maar volgens mij ondersteunen alle zichzelf respecterende browsers 't al jaaaaren en trek ik die "missen nog veel features" dus een beetje in twijfel. Microsoft zet er met Blazer (o.a.) in ieder geval behoorlijk op in.

Je hebt gelijk hoor, maar ik kan je vertellen dat voor verschillende talen er gewoon een hele runtime ingeladen wordt. Dit geldt voor Blazor bijvoorbeeld en voor Python ook. Met Kotlin hebben we ermee geexperimenteerd maar dat is gewoon nog lang niet geschikt behalve voor een Hello World demo. En die is dan wel mooi 7MB.

Maar, het gaat gelukkig de goede kant op. Rust WASM is wel erg goed.

[Mr. HTTP]

Ik heb een paar jaar terug de flow voor een online Rummikub game uitgedacht. Zal vanavond eens kijken of ik dat nog ergens heb. Hoewel een ander spelletje heeft het technisch wel wat overlap zover ik even snel kan zien.

[Bart2005]

Hydra schreef op dinsdag 2 februari 2021 @ 16:25:
[...]


Het is geen 2005 meer. Valideren doen we in de back-end.

Edit: Ben jij de maker van Kallisto?

Dat laatste is inderdaad zo. Old school uiteraard. Maar wat @RobIII schreef: het moet blijkbaar in 2 talen... Dat vind ik geen vooruitgang heren. Je kunt dus niet 1 legale generator schrijven en die compileren zodat ie gebruikt kan worden aan de voor- en achterkant? Zo niet: dan is e.e.a. er niet eenvoudiger op geworden... Je zou toch verwachten dat dat wel zo is. Zoals opgemerkt heb ik niet veel verstand van die client- server zaken maar daar moet toch iets handigs voor bestaan.

Dat het aan de client-zijde moet gebeuren m.i. is dat dat de gebruiker inzicht kan verschaffen in de legale mogelijkheden d.m.v. een aantrekkelijke grafische presentatie. Maar misschien kan zoiets ook andersom.

[Bart2005]

Overigens is het zo dat ALS je het in 2 talen zou moeten doen ook niet echt een heksentoer. Je maakt dat 1 keer en ervan uitgaande dat de regels niet meer veranderen is dat gewoon klaar en hoef je er nooit meer wat aan te doen.

[Hydra]

Bart2005 schreef op dinsdag 2 februari 2021 @ 16:45:
[...]

Dat laatste is inderdaad zo. Old school uiteraard. Maar wat @RobIII schreef: het moet blijkbaar in 2 talen... Dat vind ik geen vooruitgang heren. Je kunt dus niet 1 legale generator schrijven en die compileren zodat ie gebruikt kan worden aan de voor- en achterkant? Zo niet: dan is e.e.a. er niet eenvoudiger op geworden... Je zou toch verwachten dat dat wel zo is. Zoals opgemerkt heb ik niet veel verstand van die client- server zaken maar daar moet toch iets handigs voor bestaan.

Nouja, niet om het een of andere. Maar als je er zo weinig van weet, waarom ga je dan zo stellig dit soort dingen roepen? Juist als 'ervaren' developer moet je weten wat je niet weet.

Het is niet so lastig namelijk; gewoon de moves berekenen in de back-end (want daar moeten ze sowieso zitten) en de client dat laten uitvragen. Maar daar waren we een aantal posts geleden al.

Dat het aan de client-zijde moet gebeuren m.i. is dat dat de gebruiker inzicht kan verschaffen in de legale mogelijkheden d.m.v. een aantrekkelijke grafische presentatie. Maar misschien kan zoiets ook andersom.

Dat kan dus prima door de client het gewoon aan de server te laten vragen.

[Mr. HTTP]

Bart2005 schreef op dinsdag 2 februari 2021 @ 16:45:
[...]

Dat laatste is inderdaad zo. Old school uiteraard. Maar wat @RobIII schreef: het moet blijkbaar in 2 talen... Dat vind ik geen vooruitgang heren. Je kunt dus niet 1 legale generator schrijven en die compileren zodat ie gebruikt kan worden aan de voor- en achterkant? Zo niet: dan is e.e.a. er niet eenvoudiger op geworden... Je zou toch verwachten dat dat wel zo is. Zoals opgemerkt heb ik niet veel verstand van die client- server zaken maar daar moet toch iets handigs voor bestaan.

Dat het aan de client-zijde moet gebeuren m.i. is dat dat de gebruiker inzicht kan verschaffen in de legale mogelijkheden d.m.v. een aantrekkelijke grafische presentatie. Maar misschien kan zoiets ook andersom.

Volgens mij hoeft het ook niet in twee talen, zal ook niet weten waarom.
Code aan beide kanten gebruiken moet ook gewoon kunnen (met wat uitzonderingen).

Ik kom er nog op terug maar mijn Rummikub flow had gewoon een domme presentatie laag, een back-end deed de check en gaf aan of de front-end dat visueel mocht renderen...

[Bart2005]

Hydra schreef op dinsdag 2 februari 2021 @ 16:50:
Nouja, niet om het een of andere. Maar als je er zo weinig van weet, waarom ga je dan zo stellig dit soort dingen roepen? Juist als 'ervaren' developer moet je weten wat je niet weet.

Was ik stellig? Dat was niet zo bedoeld dan. Ik heb volgens mij enkel beweerd dat het me handig leek in de interface wegens de feedback die je dan eenvoudig kunt leveren aan de gebruiker.

[Hydra]

Mr. HTTP schreef op dinsdag 2 februari 2021 @ 16:50:
[...]

Volgens mij hoeft het ook niet in twee talen, zal ook niet weten waarom.
Code aan beide kanten gebruiken moet ook gewoon kunnen (met wat uitzonderingen).

Nouja. Succes met het direct gebruiken van Python code in een web front-end. Dat gaat niet "gewoon kunnen".

[Mr. HTTP]

Bart2005 schreef op dinsdag 2 februari 2021 @ 16:53:
[...]

Was ik stellig? Dat was niet zo bedoeld dan. Ik heb volgens mij enkel beweerd dat het me handig leek in de interface wegens de feedback die je dan eenvoudig kunt leveren aan de gebruiker.

"Feedback eenvoudig kunt leveren"? Eenvoudiger dan wat? Met een real-time server opzet, is de latency je te hoog?

[Mr. HTTP]

Hydra schreef op dinsdag 2 februari 2021 @ 16:56:
[...]
Nouja. Succes met het direct gebruiken van Python code in een web front-end. Dat gaat niet "gewoon kunnen".

Ik opper voor een zo dom mogelijke front-end. Je kan toch gewoon alles in de backend doen, waarom al die zooi in de front-end? Maar ik ga wel verder reageren als ik meer tijd heb voordat we hier zo weer elkaar de ogen uitsteken om niets.

[Hydra]

Bart2005 schreef op dinsdag 2 februari 2021 @ 16:53:
Was ik stellig? Dat was niet zo bedoeld dan. Ik heb volgens mij enkel beweerd dat het me handig leek in de interface wegens de feedback die je dan eenvoudig kunt leveren aan de gebruiker.

Je zei dat je het alleen in de front-end wil hebben, en dat is gewoon sowieso fout in een client-server setup waar de client niet vertrouwd kan worden. En ik heb vanochtend om 8 uur al uitgelegd dat je prima gewoon een call vanuit de client naar de server op kan halen om voor een stuk de valid moves op te halen. Dus ik snap echt niet dat dit hele topic nu verzand in een rare "Kan je alle code in de front-end stoppen" discussie waar de TS echt geen fluit aan heeft.

[Bart2005]

Mr. HTTP schreef op dinsdag 2 februari 2021 @ 16:56:
[...]


"Feedback eenvoudig kunt leveren"? Eenvoudiger dan wat? Met een real-time server opzet, is de latency je te hoog?

Je kunt hem dan ook off-line gebruiken b.v. Kan handig zijn. Ik merk hier trouwens wel een mij wat te agressieve sfeer dus ik ben weg hier. Het moet wel leuk blijven. Ik dacht misschien handige input. Ik maakte al schaakprogramma's toen jullie nog in jullie vaders verrekijker zaten. De opzet wat triviale zaken als een legale zettengenerator betreft zijn nog gewoon hetzelfde. Maar blijkbaar wordt het als een geheel nieuw beest gezien als het via internet moet....

[Bart2005]

Hydra schreef op dinsdag 2 februari 2021 @ 17:00:
Dus ik snap echt niet dat dit hele topic nu verzand in een rare "Kan je alle code in de front-end stoppen" discussie waar de TS echt geen fluit aan heeft.

Dat doet het m.i. ook niet. Maakt mij geen bal uit waar je hem stopt. Maar ik was weer weg hoor.

[Hydra]

Bart2005 schreef op dinsdag 2 februari 2021 @ 17:01:
. Ik maakte al schaakprogramma's toen jullie nog in jullie vaders verrekijker zaten.

Juist een ervaren iemand zou het moeten kunnen hebben dat als hij een vrij grote fout maakt en daar op aangesproken wordt, daar van leert, en niet verongelijkt gaat zitten doen. Jij weet veel van schaak. Een hoop mensen hier weten veel van client-server architecturen. Als je van elkaar leert en ervoor openstaat dat je soms iets doms zegt, dan komen we er allemaal beter uit

[Hydra]

Mr. HTTP schreef op dinsdag 2 februari 2021 @ 16:59:
Ik opper voor een zo dom mogelijke front-end.

Ik ook, vandaar al vanochtend om dit gewoon puur op de back-end te doen en de client gewoon de back-end laten aanroepen. Dat is veruit de simpelste manier. En ik denk dat de simpelste manier ook voor de TS de beste is. Dus ik denk dat we het gewoon eens zijn hoor

[Voor 5% gewijzigd door Hydra op 02-02-2021 17:05]

[Freeaqingme]

armageddon_2k1 schreef op dinsdag 2 februari 2021 @ 15:43:
[...]


Kuch. Er zijn nog niet gek veel talen die goed WebAssembly als target hebben.

Los van de vraag of het klopt, maakt dat denk ik niet zo veel uit. Uiteindelijk hoef je het maar in 1 taal te doen. Als je taal van keuze het ondersteunt ben je er al dus

armageddon_2k1 schreef op dinsdag 2 februari 2021 @ 15:43:
[...]


Daarnaast is DOM manipulatie gewoon nog retetraag.

Je moet door een tussenlaag in JS door. Of die langzaam is, geen idee. Maar zelfs al zou 'ie langzaam zijn, is het dan echt merkbaar voor de user? Ik denk het voor iets als dit niet.

Niet dat het allemaal uitmaakt verder. Ik heb even gegoogled op 4 player chess. Het lijkt er op dat de meeste 4 player chess borden 160 vakjes hebben, en iedere speler heeft 16 stukken. Dat betekent dat er per speler per beurt maximaal 16*160-1=2559 opties zijn. Dat zijn er niet superveel om voor een computer met een enorm inefficient algortime uit te rekenen.

Daarom denk ik dat het makkelijkste is om aan het begin van iedere beurt aan de server te vragen 'welke stappen mag deze speler allemaal zetten?', en dat die een lijstje van toegestane stappen stuurt. Dat kost hoogstens een paar kb aan traffic, en het scheelt dat - zeker voor een eerste versie - je alleen maar de server versie hoeft te debuggen.

[RobIII]

Bart2005 schreef op dinsdag 2 februari 2021 @ 16:45:
Maar wat @RobIII schreef: het moet blijkbaar in 2 talen...

Lees mijn post nog eens goed Dat heb ik nergens gezegd; de vraag van TS was juist: hoe voorkom je dat je 't twee keer zou moeten schrijven (gegeven dat 't al één keer geschreven zou zijn in Python en je 't dus geen tweede keer wil doen én dat Python niet werkt in de browser)...

Bart2005 schreef op dinsdag 2 februari 2021 @ 17:01:
Ik maakte al schaakprogramma's toen jullie nog in jullie vaders verrekijker zaten.

Vast, maar dan niet geschikt voor online gebruik OF zo lek als een mandje

Bart2005 schreef op dinsdag 2 februari 2021 @ 17:01:
Maar blijkbaar wordt het als een geheel nieuw beest gezien als het via internet moet....

Onzin, de regels 'valideren' blijft hetzelfde. Maar regel 1 in client-server applicaties is dat je never-ever je client(s) vertrouwt. En dus heb je sowieso validatie in je backend nodig. Daar heb je dus al implementatie 1, geen ontkomen aan. De vraag: hoe voorkom je dat je een tweede implementatie moet schrijven? Nou, dat kan 1) door de server te raadplegen (AJAX request, Websockets, postduif, who-cares) OF 2) door de regels in een taal die OOK door je browser begrepen wordt (eigenlijk dus JS en dan houdt 't gauw op) te implementeren OF 3) door de regels te cross-compilen (van, zeg, een Python, naar WASM). Gezien TS aangeeft de implementatie al gedaan te hebben in Python valt de tweede optie dus al af (of TS moet opnieuw beginnen) en blijft 1 en 3 over.

Bart2005 schreef op dinsdag 2 februari 2021 @ 16:45:
Dat het aan de client-zijde moet gebeuren m.i. is dat dat de gebruiker inzicht kan verschaffen in de legale mogelijkheden d.m.v. een aantrekkelijke grafische presentatie. Maar misschien kan zoiets ook andersom.

De client kan gewoon aan de server vragen: hey, wat zijn de legale moves? Nul intelligentie in de client voor nodig. Het enige dat de client dan moet doen is zorgen dat de response van de server een beetje knap weergegeven wordt.

armageddon_2k1 schreef op dinsdag 2 februari 2021 @ 15:43:
Daarnaast is DOM manipulatie gewoon nog retetraag.

Het is schaak. We hoeven geen 60FPS te halen, wel?

[Voor 80% gewijzigd door RobIII op 02-02-2021 17:27]

[Bart2005]

RobIII schreef op dinsdag 2 februari 2021 @ 17:10:
Onzin, de regels 'valideren' blijft hetzelfde. Maar regel 1 in client-server applicaties is dat je never-ever je client(s) vertrouwd.

Ok dan. Mijn insteek (waarom ik reageerde op een post van TS) was eigenlijk alleen om even de input te geven dat er zoiets bestaat als een legale zettengenerator. En dat je die ook moet hebben. Waar je die dan stopt maakt mij niet uit.

TS schreef:

Het is een soort schaakvariant, maar de regels wijken daar sterk vanaf (andere soorten stukken en verplaatsingsregels). Bv. de paden van de stukken liggen niet vast, maar kunnen sterk afwijken. Je kan dus niet met simpele berekeningen op de coordinaten de mogelijke moves berekenen, er is path finding nodig. Er zijn dus ook heel veel mogelijke volgende zetten.

Wat heel speciaal klinkt maar dat niet is. En geen belemmering of reden om een voorkeur te hebben waar je hem stopt leek me. Het is vrij triviale code die al vele duizenden malen geschreven is. Verder leek het me handig om die dan (ook) in de interface te stoppen voor mogelijk off-line gebruik. Maar dat is misschien helemaal niet aan de orde.

Wel merk ik op dat e.e.a. in dit topic niet echt volgens de normale regels der beleefdheid verloopt, zelfs wat agressiviteit denk ik te proeven. Is misschien een manier om aan te geven: bemoei jij je er niet mee...

[BramV]

MartenBE schreef op dinsdag 2 februari 2021 @ 12:05:
Het zal ook sowieso met websockets gebeuren, zodat updates meteen van server naar client gaan bij de spelers (bij HTTP moet je anders de hele tijd pollen).

Je hebt ook nog zoiets als SSE, Server Side Events, iets eenvoudiger te implenteren dan Websockets.

[RobIII]

Bart2005 schreef op dinsdag 2 februari 2021 @ 17:28:
\Mijn insteek (waarom ik reageerde op een post van TS) was eigenlijk alleen om even de input te geven dat er zoiets bestaat als een legale zettengenerator.

Die heeft TS al - althans: die zal TS op z'n minst in de backend moeten implementeren. Dat is een gegeven. Dus, de daadwerkelijke implementatie daargelaten, aangenomen dat TS die al heeft: de vervolgvraag (en de insteek van 't topic van TS) is dan: hoe voorkom je dat je dat een tweede keer moet doen om 't OOK in 't frontend te kunnen doen.

Bart2005 schreef op dinsdag 2 februari 2021 @ 17:28:
Wat heel speciaal klinkt maar dat niet is.

Maar niet de vraag is...

Bart2005 schreef op dinsdag 2 februari 2021 @ 17:28:
En geen belemmering of reden om een voorkeur te hebben waar je hem stopt leek me.

Die is er dus - in zekere mate - wél. Je moet 't (als je het goed doet / wil doen) in de backend hebben. Basta.

Bart2005 schreef op dinsdag 2 februari 2021 @ 17:28:
Het is vrij triviale code die al vele duizenden malen geschreven is.

Again; dat is de vraag van TS helemaal niet (en daarnaast: jij hebt 't over 'gewone' schaak, TS heeft 't over een 'eigen' / 'andere' / 'aparte' variant die schijnbaar gepatenteerd is en nog in ontwikkeling is... dus ook hier: hoezo al "duizenden malen geschreven" en hoe weet jij zo zeker dat 't "vrij triviaal" is?)

Bart2005 schreef op dinsdag 2 februari 2021 @ 17:28:
Verder leek het me handig om die dan (ook) in de interface te stoppen voor mogelijk off-line gebruik.

Hence de vraag: hoe krijg ik dat óók in de interface zonder 2 keer een implementatie te moeten bouwen.

Bart2005 schreef op dinsdag 2 februari 2021 @ 17:28:
Wel merk ik op dat e.e.a. in dit topic niet echt volgens de normale regels der beleefdheid verloopt, zelfs wat agressiviteit denk ik te proeven.

Kom op zeg. Er is hier niemand voor rotte vis uitgemaakt. Dat je wat scherpere reacties krijgt omdat je steeds dwars door 't topic blijft fietsen door vragen te beantwoorden die niet gesteld worden of door 'ons jonkies' even te vertellen dat je 't allemaal zo goed weet (ik wil best geloven dat je koning schaakengine bent) lijkt me dan ook wel een piepklein beetje je eigen schuld.

[Voor 9% gewijzigd door RobIII op 02-02-2021 17:44]

[Bart2005]

Sorry maar behoorlijk autistisch allemaal. Het lijkt een soort strijd te zijn om de langste E-Penis. Het is alsof er software geschreven gaat worden van strategisch belang voor de wereldvrede in plaats van een spelletje. Hoe belangrijk is het nou helemaal? Mijn reacties waren bedoeld om de TS te helpen en niet om de overige haantjes hier te pesten.

Maar het lijkt alsof het draait om ontwerpkeuzes van levensbelang.. Hoe belangrijk wil je het maken en in hoeverre wil men gebruikers die input leveren schofferen?

En over die /andere/eigen/aparte/nog nooit vertoonde variant... Er bestaan al duizenden varianten op het schaakspel. Met honderden fantasiestukken en borden van allerhande grootte en vorm. Niks nieuws onder de zon. De principes van een legale zettengenerator blijven gewoon hetzelfde.

[Voor 21% gewijzigd door Bart2005 op 02-02-2021 17:46]

[Creepy]

Zullen we gewoon weer ontopic gaan ipv alleen randzaken er bij te gaan halen? Thanks.

[MartenBE]

RobIII schreef op dinsdag 2 februari 2021 @ 17:34:

Die heeft TS al - althans: die zal TS op z'n minst in de backend moeten implementeren. Dat is een gegeven. Dus, de daadwerkelijke implementatie daargelaten, aangenomen dat TS die al heeft: de vervolgvraag (en de insteek van 't topic van TS) is dan: hoe voorkom je dat je dat een tweede keer moet doen om 't OOK in 't frontend te kunnen doen.

[...]

Die is er dus - in zekere mate - wél. Je moet 't (als je het goed doet / wil doen) in de backend hebben. Basta.


[...]

Again; dat is de vraag van TS helemaal niet (en daarnaast: jij hebt 't over 'gewone' schaak, TS heeft 't over een 'eigen' / 'andere' / 'aparte' variant die schijnbaar gepatenteerd is en nog in ontwikkeling is... dus ook hier: hoezo al "duizenden malen geschreven" en hoe weet jij zo zeker dat 't "vrij triviaal" is?)


[...]

Hence de vraag: hoe krijg ik dat óók in de interface zonder 2 keer een implementatie te moeten bouwen.

Dit is inderdaad hetgene wat ik me afvraag. Dit spel is nog nooit digitaal geïmplementeerd, de kans is dus groot dat er nog bugs in komen. Graag zou ik alles onder unit tests willen steken, maar dit zowel in JS als Python implementeren lijkt me een enorme soep als er iets moet gewijzigd of toegevoegd moet worden. Dat het sowieso in de backend in Python moet zitten is duidelijk, maar als ik mijn client "fancy" wil krijgen, leek het me handig dat de client dit ook kan.

Bart2005 schreef op dinsdag 2 februari 2021 @ 17:42:
En over die /andere/eigen/aparte/nog nooit vertoonde variant... Er bestaan al duizenden varianten op het schaakspel. Met honderden fantasiestukken en borden van allerhande grootte en vorm. Niks nieuws onder de zon. De principes van een legale zettengenerator blijven gewoon hetzelfde.

Het lijkt uiterlijk op schaak, maar het is echt niet hetzelfde. De enige overeenkomst is dat het een schaakbordpatroon heeft (maar wel 9x9), maar eigenlijk stopt daar al het gelijk-verhaal. Ook liggen de zetten van stukken niet vast: bv. toren kan enkel links/rechts en dergelijke, dat is bij dit spel niet zo (vandaar de pathfinding). Vandaar dat het doorsturen van mogelijke zetten ook enorm groot of niet-performant kan uitvallen volgens mij. Het spel in kwestie is https://www.malkithegame.com. Wel een echte aanrader! Al meermaals gebeurd dat ik in 1 ronde dacht dat ik ging winnen, iemand kon uitschakelen, zelf ging verliezen of dat het gelijkstand ging zijn

[Bart2005]

Kunnen we ergens de spelregels bekijken? Wat ik vind is dat er prachtige sets worden aangeboden maar de regels zijn daar niet te vinden. Kan ik even inschatten of het heel anders is dan de andere talrijke varianten.

Over de problemen die je ondervindt wil ik wel meedenken in niet technische zin dan waar je het implementeert.

[Voor 20% gewijzigd door Bart2005 op 02-02-2021 18:21]

[MartenBE]

Bart2005 schreef op dinsdag 2 februari 2021 @ 18:18:
Kunnen we ergens de spelregels bekijken? Wat ik vind is dat er prachtige sets worden aangeboden maar de regels zijn daar niet te vinden. Kan ik even inschatten of het heel anders is dan de andere talrijke varianten.

Ik zal het eens navragen bij de beheerder of ik dit mag doen.

[Bart2005]

MartenBE schreef op dinsdag 2 februari 2021 @ 18:21:
[...]


Ik zal het eens navragen bij de beheerder of ik dit mag doen.

Het lijkt me nogal belangrijk dat als je een spel populair wilt maken je de spelregels zoveel mogelijk openbaar moet maken.

Je moet wel oppassen dat het spel niet een variant of kopie is van iets anders onder een andere naam. Daar zijn vele voorbeelden van bekend. Een voormalig opdrachtgever van mij, voor het computeriseren van een "zelfbedacht" bordspel is daarvoor ook aangeklaagd en heeft verloren. Hij had mij al betaald gelukkig.

[Voor 33% gewijzigd door Bart2005 op 02-02-2021 18:27]

[MartenBE]

Bart2005 schreef op dinsdag 2 februari 2021 @ 18:23:
[...]

Het lijkt me nogal belangrijk dat als je een spel populair wilt maken je de spelregels zoveel mogelijk openbaar moet maken.

Je moet wel oppassen dat het spel niet een variant of kopie is van iets anders onder een andere naam. Daar zijn vele voorbeelden van bekend. Een voormalig opdrachtgever van mij, voor het computeriseren van een "zelfbedacht" bordspel is daarvoor ook aangeklaagd en heeft verloren. Hij had mij al betaald gelukkig.

Dat begrijp ik, ik ben enkel een enthousiasteling en geen rechtenhouder, maar ik vraag het eens na

[Creepy]

Maaruh, dat heeft geen betrekking meer tot de originele vraag en dan hoort het topic ook niet meer in programming thuis. Welke regels het zijn maakt voor de originele vraag ook helemaal niet uit. Als je over de regels e.d. wilt discussieren en of je nu wel of niet aangeklaagd kan worden dan kan dat, maar open dan een topic ergens buiten de devschuur.

[Bart2005]

MartenBE schreef op dinsdag 2 februari 2021 @ 18:27:
[...]


Dat begrijp ik, ik ben enkel een enthousiasteling en geen rechtenhouder, maar ik vraag het eens na

Het gaat misschien wat off-topic van de "DevSchuur" maar is het een spel waar je spreekt van "perfecte informatie" zoals hier bedoeld:

Wikipedia: Perfect information

Of is er sprake van verborgen informatie? Want dan wordt een legale zettengenerator wat lastiger..

[Bart2005]

Creepy schreef op dinsdag 2 februari 2021 @ 18:39:
Maaruh, dat heeft geen betrekking meer tot de originele vraag en dan hoort het topic ook niet meer in programming thuis. Welke regels het zijn maakt voor de originele vraag ook helemaal niet uit. Als je over de regels e.d. wilt discussieren en of je nu wel of niet aangeklaagd kan worden dan kan dat, maar open dan een topic ergens buiten de devschuur.

Ja dat snap ik. Maar die kant gaat het wel op ook door de reacties van TS. Dus wat moeten wij doen volgens jou want het is m.i. best interessant maar dan niet hier w.s.

[Hydra]

Bart2005 schreef op dinsdag 2 februari 2021 @ 17:42:
Maar het lijkt alsof het draait om ontwerpkeuzes van levensbelang..

Dit is primair een forum dat gaat over software ontwikkeling. Dat staat ook vrij letterlijk boven in je browser. Als het gaat om client-server sofware ontwikkelingen, dan heb je bepaalden manieren waarop je iets doet. Er zijn in sommige gevallen bepaalde dingen waarbij er objectief hele slechte manieren zijn iets op te lossen.

Aan de client kant 'regels' checken, en niet aan de serverkant is er een van. Het is een van de grootste fouten die iemand kan maken. Het is ook iets wat vaak voorkomt, en vaak zie je dat bij 'echte' applicaties dan terug in het 8-uur journaal.

Als hier dan een beginner om hulp komt vragen, kunnen we het niet hebben dat een willekeurig persoon gaat roepen dat dat een goeie manier is. De reden dat jij zo'n 'heftige' reactie krijgt, is vooral omdat men wil voorkomen dat de desbetreffende beginner denkt dat dat inderdaad een optie is. De reactie die je krijgt is, lomp gezegd, evenredig aan hoe goed of slecht hij is. Het is niks persoonlijks; als jij een brilliante ingeving neergeschreven had, krijg je daar net zo goed een erg positieve reactie op.

Security is een enorm belangrijk onderwerp. En als hij het nu in een spelletje verkeerd doet, tja. Maar daar gaat het niet om. Iets wat je eenmaal verkeerd aangeleerd hebt, ga je daarna ook opnieuw verkeerd doen. Tenzij iemand je heel duidelijk zegt dat dat een enorm slecht idee is. En dat is echt het enige wat hier gebeurd is.

Dit is verder het laatste wat ik er over ga zeggen (want best offtopic) maar ik vond het belangrijk dat jij (en de TS) snappen waar de 'heftige' reacties vandaan komen.

[Voor 5% gewijzigd door Hydra op 02-02-2021 19:25]

[danslo]

Kijk eens naar Transcrypt. Is een zogeheten transpiler, waarmee je je python validatie logica kan hergebruiken in de browser.

En mocht je het WebAssembly pad willen bewandelen, dan heb je Pyodide.

[MartenBE]

Bart2005 schreef op dinsdag 2 februari 2021 @ 18:39:
[...]

Het gaat misschien wat off-topic van de "DevSchuur" maar is het een spel waar je spreekt van "perfecte informatie" zoals hier bedoeld:

Wikipedia: Perfect information

Of is er sprake van verborgen informatie? Want dan wordt een legale zettengenerator wat lastiger..

Er is geen verborgen informatie: iedereen ziet steeds alles op of naast het bord. De spelregels staan niet online, maar er staat volgens de beheerder een filmpje online op https://www.malkithegame.com/malki-its-you/malki-rules#/ .

Hoe ik het voorlopig doe: ik implementeer de logica in de backend in Python en hou de latency in de gaten. Als ik dit forum goed interpreteer, zit er niets anders op om de logica deels te herimplementeren in JS als ik speciale zaken in de frontend wil (maar dat is geen noodzakelijkheid op dit moment). Er zijn zaken zoals brython, transcrypt, ... maar niemand heeft daar echt ervaring mee.

[Voor 7% gewijzigd door MartenBE op 03-02-2021 12:47]

[com2,1ghz]

Ik denk echt dat die latency geen reet voorstelt. De state van je spel zit in het geheugen van de server toch?
Schaken is ook om de beurt dus je hebt ook niet te maken met asynchrone requests.

Je kan in vorm van error codes communiceren naar je frontend. Dan is dat lijstje met codes het enige waar je een mapping voor moet schrijven.
Dus:
POST - /move/
Response status 400
{
"error": {
"code": 1234,
"message": "Move not allowed"
}
}

In je GUI check je op code 1234 en toon je eventueel het bericht.

[Merethil]

com2,1ghz schreef op woensdag 3 februari 2021 @ 10:37:
Ik denk echt dat die latency geen reet voorstelt. De state van je spel zit in het geheugen van de server toch?
Schaken is ook om de beurt dus je hebt ook niet te maken met asynchrone requests.

En om hier op voort te borduren; je kan dus aan de hand van de state al op voorhand uitrekenen wat iemand mag doen met zijn stukken. Je kan dus continu up-to-date houden wat voor elke speler de valide locaties zijn waar zij hun stuk kunnen zetten.
Door bij elke wijziging dit te herberekenen houd je de server misschien wel druk, maar als de speler dan klaar is voor zijn beurt heeft 'ie direct (per stuk, of hoe het ook werkt in je spel) elke valide locatie en kan je die lijst in de frontend opvragen om al je frontendmeldingen te tonen (b.v. "Je wil naar A12, maar dat mag niet want reden X")

Ik denk dat je op deze manier de latency die je speler "merkt" heel laag kan houden, en toch goede meldingen op je frontend relatief simpel kan inbouwen, zonder dat je alle "beweeg"-logica nogmaals moet inbouwen in je frontend.

[JeroenTheStig]

MartenBE schreef op woensdag 3 februari 2021 @ 10:25:
[...]


Er is geen verborgen informatie: iedereen ziet steeds alles op of naast het bord. De spelregels staan niet online, maar er staat volgens de beheerder een filmpje online die de regels uitlegt op de instagram.

Hoe ik het voorlopig doe: ik implementeer de logica in de backend in Python en hou de latency in de gaten. Als ik dit forum goed interpreteer, zit er niets anders op om de logica deels te herimplementeren in JS als ik speciale zaken in de frontend wil (maar dat is geen noodzakelijkheid op dit moment). Er zijn zaken zoals brython, transcrypt, ... maar niemand heeft daar echt ervaring mee.

Ik denk echt dat je veel te zwaar tilt aan de latency, zeker voor een spel als schaken. We hebben het hier niet over een first person shooter of zo iets.

Wat je imo moet doen is in de backend je logica bouwen om te bepalen wat geldige zetten zijn voor een specifieke stuk. Je zult backend sowieso state moeten bijhouden over de huidige opstelling van je spel, inclusief details die nodig zijn om te bepalen of je bijv. een rokade of en passant mag uitvoeren (is de koning al verplaatst, is de pion de laatste zet verplaatst, etc.). Uit deze state kun je backend prima berekenen wat geldige acties zijn voor een specifieke stuk. Aan de backend valideer je dus ook of een volgende zet ( bijv. Ra1-a4) van een speler geldig is. Als response kun je dan idd zoals @com2,1ghz al aangeeft een HTTP 400 terugsturen met melding zoals 'invalid move'.

Frontend is een heel ander verhaal. Hier speelt gebruiksvriendelijk een rol, en daarbij wil je dan zaken implementeren zoals welke velden kan ik een stuk naartoe plaatsen als ik hem vastpak. Op Chess.com zie je dan inderdaad de velden van kleur veranderen waar je een stuk naartoe mag plaatsen. Deze informatie (welke velden zijn geldig voor de huidige stuk) haal je op dat moment op van de backend. Als je latency dan echt een zorg voor je is, dan kun je op het moment dat het jouw beurt weer is deze informatie ophalen voor al jouw stukken. Dan hoef je alleen maar dit datamodelletje wat je clientside hebt te raadplegen op het moment dat je een stuk wilt verplaatsen. Hier zul je dan ook op een gebruiksvriendelijke manier aan moeten geven als de gebruiker iets doet wat niet geldig is. Normaal gesproken zal je daarom dus ook geen HTTP 400 terugkrijgen van de backend, omdat je in je user interface al voorkomt dat de gebruiker een ongeldige zet doet. De backend validation is dus puur bedoeld om de zaak niet te manipuleren en de state valide te houden.

Kortom: het is absoluut niet nodig om logica twee keer te implementeren. Je moet alleen goed nadenken hoe je slim de informatie van de backend kunt gebruiken in je frontend om de zaak vlotjes te laten verlopen en tegelijkertijd de gebruiker te attenderen welke velden je een stuk naartoe kunt schuiven.

[Voor 9% gewijzigd door JeroenTheStig op 03-02-2021 11:42]

[Hydra]

Merethil schreef op woensdag 3 februari 2021 @ 10:57:
En om hier op voort te borduren; je kan dus aan de hand van de state al op voorhand uitrekenen wat iemand mag doen met zijn stukken. Je kan dus continu up-to-date houden wat voor elke speler de valide locaties zijn waar zij hun stuk kunnen zetten.
Door bij elke wijziging dit te herberekenen houd je de server misschien wel druk, maar als de speler dan klaar is voor zijn beurt heeft 'ie direct (per stuk, of hoe het ook werkt in je spel) elke valide locatie en kan je die lijst in de frontend opvragen om al je frontendmeldingen te tonen (b.v. "Je wil naar A12, maar dat mag niet want reden X")

Precies. De uitdaging bij de implementatie van een schaak 'engine' is vooral alle optimalisaties die je nodig hebt om meer dan 2 plies diep te gaan rekenen. Nu weet ik niet hoe 'anders' het spel van @MartenBE precies is, maar wat jij hier beschrijft is gewoon 1 plie diep rekenen, en dat kan prima 'brute force', computers zijn snel.

Dus als na een zet de client gewoon voor de huidige staat alle mogelijke moves ophaalt in de achtergrond, dan is er van merkbare latency gewoon helemaal geen sprake.

[PainkillA]

chielsen schreef op maandag 1 februari 2021 @ 23:42:
Alternatief: gebruik node als backend zodat je de regels makkelijk kan hergebruiken?

consessies doen op je backend taal/architectuur enkel en alleen om regels te hrgebruiken lijkt mij niet echt handig. Node is weakly typed, npm is een draak van een ecosysteem wat chaotisch en onveilig is, matige performance

Ik zou eerder de backend maken in een taal die fatsoenlijke OO ondersteund zoals php (mogelijk python) of een taal als golang vanwege de robuustheid,performance, makkelijke deployment.

[chielsen]

PainkillA schreef op woensdag 3 februari 2021 @ 13:48:
[...]

consessies doen op je backend taal/architectuur enkel en alleen om regels te hrgebruiken lijkt mij niet echt handig. Node is weakly typed, npm is een draak van een ecosysteem wat chaotisch en onveilig is, matige performance

Tja dat is vooral een mening en daarover verschilt de interpretatie nogal. Wat echter wel zo is is dat NodeJS backend + xxxJS frontend erg populair aan het worden is, vooral omdat je als developer zowel makkelijk op de front als backend kan werken. Als je dan ook nog makkelijk libraries / regels, kan hergebruiken is dat echt interessant.

[Hydra]

chielsen schreef op woensdag 3 februari 2021 @ 14:16:
Tja dat is vooral een mening en daarover verschilt de interpretatie nogal. Wat echter wel zo is is dat NodeJS backend + xxxJS frontend erg populair aan het worden is, vooral omdat je als developer zowel makkelijk op de front als backend kan werken. Als je dan ook nog makkelijk libraries / regels, kan hergebruiken is dat echt interessant.

Dit wordt een beetje een 'welles nietus' discussie maar dit is gewoon dus echt niet waar. Ik ben echt al bijna 20 jaar 'enterprise' developer and je ziet helemaal niet dat het populair begint te worden dat mensen ook back-ends in JavaScript gaan doen. Wat ik daarentegen wel gezien heb de laatste jaren, is dat we NodeJS JavaScript meuk hebben mogen herbouwen naar (in mijn geval) Java of Kotlin.

Waarom? Heel simpel. Je kunt je bedrijf niet baseren op front-enders die front-end code naar de back-end gaan copy-pasten. Want dat is waar het eigenlijk wel op neer komt.

Daarnaast is NodeJS al lang weer over die hump van z'n Hype Cycle heen. Net zoals Go overigens. Alle mensen die het 'nieuwste' najagen zij nu al lang aan het verkondigen dat Rust de toekomst is.

Zoals ik al eerder zei, validatie in de code heeft gewoon een ander doel dan validatie in de back-end. Het doel is in detail anders, dus de code is in detail anders, dus er is niet zo veel aan te hergebruiken. Dat hele kleine beetje herbruik doet er niet toe in een wereld waar je complexe back-end zooi aan het bouwen bent. Het opschrijven van de code is over 't algemeen de bottleneck niet.

NodeJS is in trek bij front-enders. En die hebben over het algemeen bij grote bedrijven niks te vertellen over de back-end architectuur.

[Voor 3% gewijzigd door Hydra op 03-02-2021 14:29]

[chielsen]

Tja, mijn ervaring is anders en als je dit ziet:
https://insights.stackove...works-libraries-and-tools

Staat NodeJS zwaar aan kop en ook JS is mega populair.
NodeJS icm met microservices zie ik echt steeds vaker.

[Hydra]

chielsen schreef op woensdag 3 februari 2021 @ 14:37:
Tja, mijn ervaring is anders en als je dit ziet:
https://insights.stackove...works-libraries-and-tools

Je weet dat NodeJS door elke front-end developer gebruikt wordt he? Het is een generieke runtime die ook weer door NPM bijvoorbeeld gebruikt wordt. Als je een dev-server opspint als je Angular of React gebruikt, gebruik je NodeJS.

Heck; ik ben Java developer en ik gebruik NodeJS ook om bepaalde tooling te gebruiken. Maar dat betekent niet dat ik daar productie code in bouw.

Linksom of rechtsom, of NodeJS nu populair is of niet (want laten we het niet over de Stackoverflow Bias hebben), niks doet af aan het simpele feit dat code herbruiken tussen FE en BE helemaal niet zo vaak voorkomt als NodeJS fans willen voorstellen.

[Voor 3% gewijzigd door Hydra op 03-02-2021 14:47]

[chielsen]

Beetje rare conclusie. Dus als ik Windows gebruik ben ik enthousiast over C++ omdat het daarin gebouwd is?

[JeroenTheStig]

chielsen schreef op woensdag 3 februari 2021 @ 14:56:
Beetje rare conclusie. Dus als ik Windows gebruik ben ik enthousiast over C++ omdat het daarin gebouwd is?

De link en de grafiek waar je naar refereert wordt letterlijk de volgende vraag gesteld:

Similar to last year, we asked about many of the other miscellaneous technologies that developers are using.

Kortom, het gaat om de meest gebruikte frameworks, niet om frameworks waar mensen het meest enthousiast worden.
Zoals Hydra al aangaf kom je al gauw met NodeJS in aanraking als je full-stack development doet, omdat de populaire front end frameworks daar op gebaseerd zijn. Het bedrijf waar ik werk wordt bijv. front-end in Angular gebouwd, dus dan komt daar ook NodeJS en nvm bij kijken. Onze backend en rest endpoints worden daarentegen in puur java gebouwd.

Kortom, de grafiek waar je naar refereert, laat m.i. niet zien dat NodeJS meer terrein wint als het gaat om backend development.

[Hydra]

@JeroenTheStig precies dat. En je kunt altijd wel statistieken cherry-picken om je punt te maken. Ik denk hoe dan ook niet dat de OP erg veel opschiet met deze discussie

[JeroenTheStig]

@Hydra Dat de OP niet veel opschiet met deze discussie ben ik het niet helemaal mee eens. Ik lees hier namelijk van verschillende mensen dat je validation rules uit de backend en de logica die daarachter steekt idealiter zou willen hergebruiken in de frontend. En daaruit voortvloeiend dat het daarom handig kan zijn om frontend en backend in hetzelfde platform te bouwen. Ik denk dat dit een verkeerde insteek is, omdat (zeker in het geval van OP) validation aan de backend gericht is op het voorkomen van datacorruptie, invoer van invalide data, of misbruik van je api, terwijl frontend validation vooral bijdraagt aan user experience. In het geval van OP bijv, zoals ik al eerder aangaf, het visueel weergeven naar welke velden een stuk verplaatst mag worden. En de informatie die daarbij nodig is, laat je door de backend uitrekenen.

Kortom, er is m.i. geen sprake van een dubbele implementatie van validation rules + achterliggende logica in zowel front-end en backend en daarom is het kiezen van eenzelfde platform in zowel front- als backend om validation rules te hergebruiken geen argument.

[Hydra]

@JeroenTheStig ik doelde op het of NodeJS al dat niet populairder wordt stukje

[chielsen]

JeroenTheStig schreef op woensdag 3 februari 2021 @ 15:09:
[...]

De link en de grafiek waar je naar refereert wordt letterlijk de volgende vraag gesteld:

[...]

Fair point, maar is het niet aannemelijker als je developers vraagt naar welke frameworks / technologieën ze gebruiken, en daar staat "Node.js" tussen, dat je dan niet meteen denkt aan npm waarmee je wat libraries binnenhaalt?
Zo gebruik ik Paint.NET, maar ik zou echt niet .NET aanvinken als ik als frontender alleen wat plaatjes daarmee edit.

Of de TS er wat aan heeft.. Nou ja het gebruik van NodeJS werd ontraden omdat niemand dat zou gebruiken. Puur op de ervaring van 1 poster, en die suggereert dat dat OpenStack een bias heeft..
Ik zou toch zeggen: er zijn voldoende mensen die er wel gebruik van (willen) maken.

[Hydra]

chielsen schreef op woensdag 3 februari 2021 @ 15:56:
Of de TS er wat aan heeft.. Nou ja het gebruik van NodeJS werd ontraden omdat niemand dat zou gebruiken. Puur op de ervaring van 1 poster, en die suggereert dat dat OpenStack een bias heeft..

Ik heb notabene in m'n eerste post aangegeven dat ik wat de TS maakt zelf een keer gemaakt heb in NodeJS + AngularJS, met websockets ipv. REST calls.

Het hele punt is dat je claimt dat NodeJS 'aan populairiteit wint' (neuh) en dat het een voordeel is dat je code kan hergebruiken (neuh). Daarin heb ik argumenten gegeven waarom ik denk dat je daar naast zit.

Nergens zeg ik dat de TS geen NodeJS kan gebruiken. Dat is echt larie. Het is alleen volkomen onnodig te gaan suggereren dat de TS overstapt naar NodeJS terwijl hij al spul in Python heeft want dat is heel veel extra werkt terwijl hij er niks mee opschiet.

Vooral bij beginners is "Analysis paralysis" best wel een groot issue. Dan is suggerenden dat hij stappen neemt die 'em weken kunnen kosten waar hij echt niks mee opschiet, nogal 'onhandig'.

Ik ben primair Java dev en ga hier ook niet op de TS inpraten dat 'ie toch echt alles in Kotlin moet gaan doen, omdat ik daar nu enmaal fan van ben. Want dat zou nogal egoistisch zijn, aangezien hij daar niks mee opschiet.