Acest lucru este mai mult o chestiune de proiectare sistem / provocare, decât o chestiune de codificare.
Practic, mă gândesc de a arunca împreună un Bejeweled joc -esque pe Facebook folosind doar HTML, CSS și JavaScript. Aceasta este cea mai mare parte din dorința de a învăța toate micile limitări ale FBJS printr - un proiect non-triviale.
Deci, aici e afacere. La dezvoltarea Facebook, apelurile reale API sunt foarte scumpe; nu numai că există un post suplimentar la serverele Facebook, există, de asemenea, limita de apel api și strangularea să vă faceți griji. Pe scurt, mai puține apeluri la Facebook cu atât mai bine. Combina acest lucru cu calendarul de preocupările chiar și acest joc de puzzle simplu, și există un motiv bun pentru a minimiza agresiv numărul de callback, în general.
Nefiind un expert de securitate, aici e design-am venit cu:
- Încorporați o sămânță aleatoriu în pagina de joc.
- Utilizați acea sămânță pentru a crea tabla de joc (precum și piese suplimentare, după cum este necesar).
- Tweak sămânța (XOR, concatena și hash, ceva de genul asta), după fiecare jucător mutare, în funcție de timp de la ultima mutare. Editare: Probabil că ar trebui să includă, de asemenea mișcare reală luată în mutant sămânța.
- La finalizarea joc a posta înapoi următoarele: joc începe de timp, fiecare mutare luate și când, iar rezultatele de partea clientului.
- Pe server, re-rula jocul cu datele date, sanatatea mintala a verifica ora de începere și de a muta ori, și apoi confirmați că rezultatele se suprapun.
- Pentru a reduce negarea serviciului, jocul în sine va fi optimizat pentru a avea un câștig de stare X rândul său.
- Pentru a descuraja serverul să fie folosit ca un „oracol“ de soiuri, un utilizator a posta înapoi un invalid de joc va fi interzis pentru o constantă de timp X (X fiind de ordinul minutelor).
Acest design necesită trei Facebook apel pe joc jucat: unul pentru a stoca semințele aleatoare înainte de joc este jucat, o să-l aducă după jocul este terminat, și unul pentru a actualiza scorul jucătorului în cazul în care jocul este valabil.
Ceea ce am încercat să o dovadă a sistemului împotriva este drept în sus scor spoofing ( http: // ... myscore = 999999999 , sau similar). Aș dori , de asemenea , pentru a atenua „anticipare“ atacuri, în care utilizatorul poate spune ce piese vin la placa următoare. Denial of Service pe serverul de hosting (intenționat sau altfel) ar trebui , de asemenea , prevenite.
Problema reală, poate cineva vedea un defect în acest design? Echivalent, există un design mai simplu, care îndeplinește criteriile mele?
Notă: Sunt conștient cât de inutilă, probabil, acest lucru este, dar ei o întrebare interesantă totuși.
Voi încerca să arunce unele numere aici pentru a ilustra raționamentul meu ane, acestea sunt destul de dur, dar sper util.
Presupunând că un consiliu de joc 10x10, există ~ 200 mișcări potențiale (pompare două bucăți adiacente) dintre care cele mai multe sunt invalide. Să presupunem că există în medie 5 mișcări valide pe „turn“. Dacă vom constrânge acțiunile jucător la cadrul de la 50 la 30.000 de milisecunde, există 149,750 potențiale noi hash-uri au furnizat „optimizări“ algoritmul nu se debaraseze de biți; Mă simt încrezător în spune că există cel puțin 10.000 de potențiali noi, care hashes trebuie să fie calculată de către un atacator presupunând un hash criptografic securizat este utilizat. Dacă arunci un algoritm-min max la acest lucru, decizia ta de copac explodeaza foarte repede. Arunca o sesiune de expirare joc de la acest lucru, spun 30 de minute, și cred că atacul, deoarece echivalentul în complexitate pentru a scrie un program de bot mic pentru a juca pentru tine, care nu poate fi în mod rezonabil apărat împotriva.
