Het spel zelf is het probleem niet. Dat doet het al maanden. Maar die database die eromheen gebouwd moet worden. Da's nogal een klusje. Ik begrijp nu waarom Frisbee destijds opperde om er een stand-alone van te maken.
Maar ik heb nu eenmaal de overtuiging dat het spel alleen een succes kan worden als je het tegen elkaar speelt. Dat is uitdagender. Spannender. Socialer. En het balletje gaat sneller rollen. Mensen nodigen elkaar uit. Als het goed is.......
 |
| Om het spel tegen elkaar te kunnen spelen zijn er contactmomentjes (requests/api's) nodig met de server |
Gisteren ben ik eens in die database, de backend, gedoken. Het gedeelte waar ik helemaal niets van weet (ik bedenk alleen de dingen aan de gebruikerszijde). Ik schrok van het aantal requests -> alleen ik en de developer kunnen nog maar inloggen...........
Ik zal het proberen in kaart te brengen. Vooral voor mezelf. Zodat ik mijn geduld in toom kan houden.
Gebruikers
Account aanmaken met naam, emailadres en wachtwoord.
Account verifiëren voordat ze kunnen spelen.
Inloggen.
Wachtwoord vergeten optie.
Hoogste score bijhouden.
Aantal tegenspelers bijhouden. Omdat de eerste 5 tegenspelers gratis zijn. Daarna moet je ze per 3 bijkopen.
Contact
Tegenspeler uitnodigen
Uitnodiging accepteren
Spelers koppelen
Bijhouden wie aan de beurt is
Bijhouden wanneer de laatste activiteit is geweest
Bijhouden wie de ronde wint
Rondes
Nieuwe ronde opstarten, beide spelers moeten dat accorderen
Speelveld aanmaken en naar beide spelers sturen
Bijhouden wie de ronde gespeeld heeft
Score wegschrijven
Volgende ronde opstarten
En dan staat de chatfunctie er nog niet eens in............
Toch nog maar eens uitvogelen of er ergens contactmomentjes weggehaald kunnen worden.
Cachen, cachen en nog eens cachen. Een dergelijke DB bouw je ook niet op een default MySQL engine (veel te zwaar) Zorg dat er contact "synchroniseer" momenten komen maar dat er ook het nodige local bij de klant blijft. Bij een push and pull houd je dan de data zelf onder controle. PS zorg ervoor dat de database een goede beveiligde API er tussen heeft. Desnoods met een 2way authenticatie zodat als botjes je api server vinden geen talloze requists sturen. Om je een idee te geven, sinds 15-1 heeft de sumoguard bigdata doos ruim 12000 invalid requists gehad met een vorm van bruteforcing om binnen te komen. Gr Maurice - SumoStore
ReplyDeleteDank Maurice, voor je reactie.
ReplyDeleteZoveel mogelijk wordt inderdaad lokaal gedaan. Ik vermoed dat er nog 1 synchroniseer momentje uit kan. Maar dat moet ik nog overleggen. Ik had vorige week zelfs nog een synchroniseer momentje toegevoegd -> het moment dat je de app (her)opent.
De developer heeft een hele leuke en betaalbare "engine" gevonden.
We zijn er bijna. Wat nu nog niet goed gaat is dat je via een bepaalde route kunt inloggen zonder dat je je account hebt geverifieerd. En de ronde gaat nog 1 stap te snel. De volgende ronde wordt al opgestart voordat de ander geaccordeerd heeft en de behaalde score gezien heeft. En hij telt verwijderde tegenspelers bij het totaal aantal tegenspelers op, waardoor te snel gevraagd wordt of je spelers wilt bijkopen. En op dat schermpje blijft hij hangen.
Kortom, er moet nog wat gebeuren.......