[TEMA]X si 0 cu mai multe "table de joc"

Buna seara! Vreau sa fac o pauza de la invatat si sa ma relaxez, simt ca nu am randamentul maxim in perioada asta, asa ca m-am gandit sa incep un proiect pe care sa il termin pana se termina scoala (atunci pot reveni la invatat in mod normal, acum mai e faza cu ascultatul in ultimele ore, etc). Tinand cont ca anul trecut facusem un joc X si 0 player vs player, m-am gandit sa fac ceva asemanator, doar ca... Avand mai multe table de joc (mai exact 6), astfel incat:
Fiecare tabla are "casutele" numerotate de la 1 la 9. Lucrul interesant e ca in fiecare tabla de joc, ordinea difera. Astfel, daca un jucator alege cifra "3", in toate casutele, casutele de pe pozitia cu numarul 3 vor fi inlocuite de "piesa" jucatorului (X si 0).

Exemplu table de joc:
Inainte de alegerea unei cifre.

123	 147	 159	 456	 716
456	 258	 327	 123	 482
789	 369	 468	 789	 359

Dupa alegerea unei cifre (3):

12X	 147	 159	 456	 716
456	 258	 X27	 12X	 482
789	 X69	 468	 789	 X59

Tabla vreau sa fie facuta folosind +, | si -.
Acum, scopul pentru care am venit aici... Nu vreau sa il implementez folosind 6 matrici de 3x3, la fiecare pas sa fie modificata fiecare... Nu prea le am cu POO. Mai bine spus, ma descurc sa fac o clasa, sa creez metode si sa le folosesc in alte fisiere, dar nu am incercat niciodata ceva mai complicat. Am zis sa postez aici in speranta ca voi primi indrumari in cadrul dezvoltarii "joculetului".

Pana acum, m-am gandit sa il structurez asa:

-o clasa cu tablele de joc
-o clasa in care sa am urmatoarele metode:
     *alegerea jucatorului
     *verificarea validitatii mutarii
     *efectuarea mutarii
     *verificarea victoriei
     *incheiarea meciului
     *pastrarea scorului

Acum intrebarile de inceput...
-Sa lucrez totul in main.cpp, sau sa folosesc clase, asa cum m-am gandit?
-E ok cum am structurat clasele? (Ma refer aici la usurinta pe care o voi avea in implementare)
-Pentru tablele de joc sa le fac pe fiecare separat, mai exact sa fac 6 matrici de 3x3? Daca nu, cum le-as putea implementa?

Cam asta ar fi pentru inceput, ma apuc si eu acum de implementare.

Cu timpul, cand voi invata sa implementez grafica, "joculetul" va suferi un update substantial, adaugand si o versiune de player vs computer, dar pana atunci, vreau sa ma axez mai mult pe dezvoltarea gandirii si folosirea claselor.

Salut. Structura pe care ti-ai propus-o lezeaza un principiu, acela de separare a logisticii aplicatiei (aici: regulile jocului) de interactiunea cu utilizatorul. In primul rand, da-le claselor un nume, e foarte important, ca de acolo pornesc multe.

Pai, numele claselor... Sa fie cat mai sugestiv, ma gandesc la:
- Boards, tinand cont ca aceasta clasa va dispune de tablele de joc (initializare, afisare)
- Logics, in aceasta clasa urmand sa pastrez metodele de verificare joc, alegere jucator, verificare validitate.
Ar fi ok asa? Sau, gameLogics, gameBoards? Ma gandesc ca nu voi folosi variabile cu numele Logics, Boards, sau ceva asemanator, astfel incat sa creeze o confuzie intre ele.

E un singur board, deci class Board, si un singur joc, deci class GameLogic.

Iar Board asta ce face? Initializarea tine de logistica jocului, afisarea tine de afisare, n-ai voie sa le amesteci.

In Board ma gandeam sa retin tablele de joc, acele matrici, 6 la numar, si pozitionarea cifrelor pe "tile-uri" - daca le putem numi tile-uri, ca sa nu repet cuvantul casuta.

Bun, bun, e bine pana aici.

Si cum faci cu introducerea datelor si afisarea lor? Nu ai voie sa le inghesui in aceste doua clase.

Deci, sa fac inca o clasa pentru afisare + introducere date? Ceva pentru input si output sa inteleg... GameIO (input/output) ar fi ok? Sau mai generic? GameScreen (tinand cont ca toate acestea se desfasoara in consola, jucatorul reusind sa le vizualizeze)?

GlontzZz, on 03 iunie 2015 - 22:13, said:

Ambele idei sunt partial bune, dar se poate mai bine.

GameIO nu mi se pare destul de sugestiv, IO poate fi de multe feluri, poate fi prin retea, prin fisiere, etc.

GameScreen e prea generic, una e cand desenezi intr-un GUI, alta intr-un CLI, dar in ambele cazuri desenezi pe ecran, pe screen.

Daca ar fi sa gandesc ca tine, as numi-o GameConsoleLoop, pentru ca e vorba de o bucla (vei avea o bucla while(cliGameLoop->gameRunning())) intr-o consola (text).


Acum, legat de modul implementare, ai doua cai: test-driven, sau "non-test-driven". Daca vrei sa-l dezvolti la modul TDD (ceea ce-ti recomand), vei programa mai intai strict primele doua clase care n-au de-a face cu I/O.

Dupa poti sa treci la interfata. Te sfatuiesc sa faci asa pentru a vedea usurinta cu care poti apoi sa-i tragi o interfata ulterior dezvoltarii, daca faci TDD - pentru ca TDD te forteaza sa expui API-ul intr-un mod facilitant daca faci TDD corect.

Ti-ar prinde bine si deoarece intentionezi sa-i tragi apoi o interfata GUI, si vei vedea cu mai multa claritate cum poti refolosi clasele care implementeaza logica fara a le modifica.

Deci iti ramane sa-ti cauti o librarie de TDD pentru C++. Nu conteaza care, dar te-as sfatui sa iei una simpla, care nu stie multe.

Si cand zic care nu stie multe, ma refer la una de genul http://www.jera.com/...ns/jtn002.html. Te ajuta sa te confrunti cu problemele de baza, ca sa intelegi apoi pentru ce sunt alte utilitati ale altor frameworkuri pentru TDD mai bogate in facilitati.

Vezi de exemplu: https://code.google.com/p/tinytest/

Edited by OriginalCopy, 03 June 2015 - 23:29.

Okay, atunci TDD sa fie, iar ca librarie JTN002.
Deci, pana acum am asa:
- Clasa "Board", unde pastrez cele 6 matrici.
- Clasa "GameLogic"
- Clasa "GameConsoleLoop".

Cum ai zis, ar trebui sa incep de la clasele care nu au legatura cu input-ul, output-ul, deci de la primele 2. Cel mai convenabil mi se pare sa incep de la Board, ca sa pot avea un punct de plecare exact (tabla de joc). Acum am alta intrebare: pentru cele 6 table de joc, sa fac 6 matrici gen table1[3][3], table2[3][3], table3[3][3] etc... Sau exista o metoda si mai convenabila?

GlontzZz, on 04 iunie 2015 - 06:26, said:

Ăstea sunt detalii de implementare care nu ar trebui să conteze, pentru că le ascunzi în clasă (private) și expui doar metode (public) care fac lucruri relevante pentru joc.

Tocmai asta e chintesența OOP, encapsulation. Dacă ai modelat corect interfața publică, în interiorul clasei vei putea modifica detaliile de acest gen, fără a afecta codul client (restul codului care apelează interfața publică).

De fapt, eu chiar ți-aș recomanda să faci mai întâi varianta simplă de x și 0, și să te concentrezi la început pe modul iterativ de programare din TDD. Apoi poți adăuga o nouă clasă cu varianta avansată de Board, care respectă o interfață comună. Astfel vei face cunoștință și cu unele tehnici comune de refactoring precum extract method, pull up, etc.

Pare mai anevoios decât e necesar, dar privește asta ca pe o oportunitate: vei vedea destul de multe pe baza unui proiect simplist, cu riscuri minime de a eșua. Profită de această oportunitate.

Important în TDD e să scrii doar codul de care ai nevoie, și să testezi interfața publică. D-aia am zis că nu contează detaliile de implementare, în teste vei apela doar acele metode publice.

Dacă nu faci așa, te vei alege cu ceea ce se numește brittle tests, adică teste foarte sensibile la refactoring, care încep să fail-uiască la mici schimbări ale detaliilor se implementare.

Brittle tests are a no-go in TDD.

Alt lucru important e să scrii mai întâi un test care fail-uiește, apoi production code pentru a face testul să pass-uiască.

Bine ți-ar prinde și să folosești git sau similar. Zic git pentru că ar fi ușor să primești feedback de la noi și despre modul în care programezi iterativ, dacă faci câte un commit mic pentru fiecare schimbare logistică din joc. Publici codul pe github și îți revizuim fiecare pas pe care îl faci.

Eu așa îmi doresc să mă fi îndrumat cineva când am învățat programare.

Ok, deci sa incep cu un joc de X si 0 normal. Aveam deja unul facut fara prea multa munca, fara clase sau altceva.  
https://gist.github....2102eca6cf0f393
Sa il modific pe acesta, sau sa incep altul?
Cat despre Git... E ok daca folosesc gist-uri si nu repository? (Mereu ma-ncurc in repository, niciodata nu mi-a iesit pe W8)

Edited by GlontzZz, 04 June 2015 - 07:28.

Eu aș începe un proiect nou pentru a avea o istorie curată care documentează evoluția ta în TDD.

Cât despre git, probabil faci ceva greșit. Deschide un nou topic în care descrii pașii pe care îi urmezi, ce setări ai, etc.

E un proiect de învățare, deci ieși din zona ta de confort și ... învață lucruri, învață de ex să pushuiești cod pe github.

Am reusit cu git-ul. Voi face si un repository in momentul in care voi incepe lucrul .
Asadar, sa incep cu un joc simplu de X si 0, cu TDD. Asta inseamna programarea doar in main.cpp, sau folosind si clase? Sa stiu cum structurez programul si imi planific timpul.

P.S.: Continui in acest topic, sau fac unul nou?

Edited by GlontzZz, 05 June 2015 - 21:38.

Asta inseamna 3 proiecte:

• Jocul in sine ce cheama functionalitatea din biblioteca (executabil direct)
  
• Functionalitatea de baza (biblioteca)
  
• Testele ce testeaza functionalitatea (executabil direct)

Pentru teste, mie imi place boost. Dar, pentru inceput, te descurci si scriind tu codul ce cheama pe rand fiecare functie de test.

Edited by dani.user, 05 June 2015 - 21:50.

Stai... 2 executabile? De ce as avea nevoie de 2? La ce teste te referi pentru functionalitate?

Codul de test arata cam asa

#include <my_class.hpp>
#define BOOST_TEST_MODULE MyTest
#include <boost/test/unit_test.hpp>

BOOST_AUTO_TEST_CASE( my_test )
{
	my_class test_object( "qwerty" );

	BOOST_CHECK( test_object.is_valid() );
}

BOOST_AUTO_TEST_CASE( other_test )
{
	BOOST_CHECK( (1 + 1) == 3 );
}

Il rulezi si iti da un raport: my_test a trecut, other_test a picat, etc.

Okay... Pana acum am TDD si varianta cu Testele (codurile de test) in executabil... Mi se pare dificil sa le implementez pe amandoua simultan, necunoscand niciuna din cele 2 metode... Nu ar fi mai ok sa fac intai implementarea de care zicea OriginalCopy completa, apoi sa pun si cel de-al doilea executabil, pentru codurile de test?

Nu, mai întâi scrii un test, încerci să-l rulezi, și constați că nici măcar nu compilează.

Apoi scrii funcțiile / metodele / clasele necesare pentru a face codul să compileze fără erori sau avertizări de compilare.

Și constați că în urma rulării testelor, toate spun "fail".

Apoi te apuci să completezi părțile lipsă până când testul spune " pass"

Asta înseamnă test-DRIVEN development.

Te forțează să gândești când programezi, și face previzibilă evoluția proiectului, minimizând astfel și riscul de eșuare.