Software Design Document

Mortar Mayhem
MPS Joi 8-10 (Team Name Pending)
Cuprins
1. Scopul documentului
2. Conţinutul documentului
3. Modelul datelor
3.1. Structuri de date globale
3.2. Structuri de date de legătură
3.3. Structuri de date temporare
3.4. Formatul fişierelor utilizate
4. Modelul arhitectural şi modelul componentelor
4.1.1. Arhitectura
4.1.2. Şabloane arhitecturale folosite
4.1.3. Diagrama de arhitectură
4.2. Descrierea componentelor
4.3. Restricţiile de implementare
4.4. Interacţiunea dintre componente
5. Modelul interfeţei cu utilizatorul
5.1. Succesiunea interfeţelor
5.2. Ferestrele aplicaţiei
6. Elemente de testare
6.1. Componente critice
6.2. Alternative
1. Scopul documentului

Documentul de fata realizeaza o descriere specializata pe componente a construirii jocului

Mortar Mayhem. Plecand de la datele Documentului de Specificatii a Cerintelor (SRS), se vor
prezinta in continuare modelele de implementare propriu-zise ale acestor cerinte, cu accent pe
interactiunea dintre acestea.

2. Continutul documentului
Documentul este format din patru sectiuni esentiale :

1. Modelul datelor prezinta structura aplicatiei din punct de vedere al modulelor

2. Modelul arhitectural si modelul componentelor prezinta sabloanele si compenentele
arhitecturale folosite si modul de implementare a interactiunii dintre ele.
3. Modelul interfetei cu utilizatorul prezinta succesiunea interfetelor si design-ul
fiecareia
4. Elementele de testare prezinta componentele critice si alternative de proiectare a
acestora
3. Modelul datelor

3.1. Structuri de date globale

Structura de date globala folosita de client este o instanta a clasei ClientMain. Aceasta are
rolul de a instantia toate celelalte obiecte folosite de aplicatie si de a face legaturile intre ele.

Aplicatia server foloseste ca date globale o instanta a clasei ServerMain. La randul ei, aceasta
asigura interactiunea dintre celelalte module.

3.2. Structuri de date de legatura

Obiectele instantiate de clasa ClientMain sunt de tipurile:

 GameScene - clasa care se va ocupa de randarea scenei. Aceasta va comunica in special

cu modulul de fizica, pentru obtinerea traiectoriei proiectilelor.
 Physics – reprezinta modulul de fizica, ce ofera functii care calculeaza pozitia unui
proiectil la un anumit moment. Acesta primeste date precum: pozitia si viteza initiala a
proiectilului, unghiul sub care a fost lansat, valori ale fortelor de frecare etc. Astfel, ofera
la iesire pozitia proiectilului la orice moment de timp.
 GUI - paginile de meniu si interfata cu utilizatorul. Acest modul contine implementari
pentru diverse elemente de meniu: Button, EditBox, ComboBox etc. Tot acest modul se
ocupa de input - clasa KeyboardMouseInput (ofera atat metode de stabilire de callback-
uri, cat si de polling pentru aflarea starii tastelor/butoanelor de mouse).
 Network - realizeaza conectarea la server si comunicatia cu acesta pe parcursul jocului.
Principalul tip de structura de date este clasa Message, care poate fi privita ca o interfata.
Orice clasa care o implementeaza trebuie sa defineasca metoda Serialize, care va fi
folosita la serializarea/deserializarea datelor ce trebuie sincronizate pe celelate masini
intr-un/dintr-un flux de date (se da si sensul transmisiei datelor). Cu obiecte de acest tip
opereaza clasa Messenger, care reprezinta trecerea de la layer-ul high-level Message la
layer-ul de baza oferit de Network.
 GameLogic - reprezinta logica jocului – lucreaza in stransa legatura cu componenta
GameLogic de pe server. Ca structuri de date, acest modul foloseste urmatoarele clase:
Player (modeleaza fiecare jucator), Weapon (arma disponibila/upgrade), Projectile
(proiectilul lansat de un jucator), precum si majoritatea claselor din celelalte module.
 Obiectele instantiate de clasa ServerMain sunt urmatoarele:

 Network - modulul care se ocupa cu organizarea sesiunilor de joc, cu comunicatia intre

clienti pe tot parcursul jocului, precum si de primirea si inregistrarea rezultatelor fiecarui
joc. Acesta foloseste structuri de date precum: GameSession (o sesiune de joc),
GameClient (replica pe server a unui obiect de tip Player de pe o masina client), o
instanta a clasei Messenger (care fie transmite anumite mesaje catre componenta de
logica a serverului, fie catre alti clienti), precum si clasa PlayerStatistics (modeleaza
entitatea Player spre a fi marcata in baza de date cu rezultatele jocurilor).
 StatisticsDB – primeste de la componenta de logica a serverului obiecte de tip
PlayerStatistics, pe care le adauga in baza de date a jocului. Aceasta clasa ofera si functii
de interogare, prin care se pot obtine unul sau mai multe obiecte de tipul PlayerStatistics
pe baza unor criterii.
 GameLogic – primeste de la modului Network al serverului diverse mesaje (obiecte de tip
Message), care in general reprezinta cereri ale aplicatiei client. Aceasta fie trimite un
raspuns clientului care a facut cererea, fie face broadcast la mesajul primit catre toti
ceilalti clienti. Clasa GameLogic asigura caracteristica turn-based a jocului, stabileste
conditiile de victorie, valideaza upgrade-urile facute de fiecare jucator si se ocupa de
intocmirea si stocarea statisticilor jocului.

3.3. Structuri de date temporare

Pe langa principalele structuri de date, exista si alte obiecte a caror durata de viata fie se
limiteaza la corpul unei functii, fie sunt folosite pentru a se transmite anumite date auxiliare
dintr-un modul in altul, dar acestea sunt nesemnificative (ca marime sau importanta) fata de cele
deja enumerate.

3.4. Formatul fisierelor utilizate

Aplicatia foloseste fisiere XML ca mod de stocare a informatiilor despre fiecare joc
desfasurat cat si pentru clasamentul jucatorilor. Aceste fisiere respecta standardul XML
(http://www.w3.org/TR/2008/REC-xml-20081126/). Datele despre un anumit utilizator se pot
afla prin accesarea acestor documente.
4. Modelul arhitectural si modelul
componentelor
4.1. Arhitectura sistemului
4.1.1. Sabloane arhitecturale folosite

Solutia software imlementata pentru jocul Mortar Mayhem a fospt proiectata dupa
modelul de arhitectura client-server. In acelasi timp, interfata cu ultilizatorul se bazeaza pe
sablonul event-driven architecture.

Componenta server este pur si simplu un mod de conectare a clientilor (jucatorilor).

Serverul este deci o platforma de interconectare, precum si o platforma de stocare, acesta tinand
evidenta jucatorilor. Serverul comunica prin intermediul modulului Retea cu clientii. Clientul
trimite serverului o actiune; serverul verifica validitatea acesteia si ii acorda permisiune de
executie daca este cazul.

Componenta client reprezinta jucatorul in sine. Acesta se conecteaza la ceilalti jucatori

prin intermediul serverului. Jucatorul are optiunea de tragere/cumparare munitie/cumparare
armura.
 4.1.2. Diagrama de arhitectura

Diagrama de arhitectura de mai jos descrie componentele arhitecturii aplicatiei si relatiile

de interactiune intre acestea.
4.2. Descrierea componentelor
 Aplicatia consta din urmatoarele module interconectate:

Modulul GUI (Graphical User Interface)

Este responsabil cu desenarea si randarea optima a interfetelor grafice ale aplicatiei.

Modulul de Logica
Este responsabil de coordonarea celorlalte module si asigura buna functionare a
aplicatiei.

Modulul Retea
Asigura comunicarea intre client si server prin transmiterea de pachete.

Modulul de Fizica
Se ocupa de calculul traiectoriei, impactului si tot ce tine de partea de calcul.

Modulul de Render
Formeaza si afiseaza pe ecran diversele obiecte prezente in joc.

Modulul MiniDB
Este o mini baza de date stocata sub forma unui fisier xml ce contine diverse informatii
despre jucatori (nume, scoruri).

4.3. Restrictii de implementare

Modulele aplicatiei trebuie sa acopere urmatoarele restrictii de implementare:
  Modulul GUI va fi dezvoltat folosind Adobe Photoshop CS4.
 Modulul Render va fi dezvoltat cu ajutorul motorului grafic XNA/Direct X.
 Modulul Retea va fi dezvoltat utilizand platforma .NET 3.5.
 Toate modulele vor fi dezvoltate utilizand limbajul de programare C# si Visual Studio
2008.

4.4. Interactiunea dintre componente

Pentru componenta Client(jucatorul), atunci cand utilizatorul porneste aplicatia, se va lansa
in executie clasa Main din modului de Logica. Aceasta va lansa in aplicatie interfata grafica a
jocului cu care va putea interactiona utilizatorul.

In continuare pasii ce vor fi executati depind de optiunile alese de utilizator din meniul
disponibil in interfata grafica. Se poate ca utilizatorul sa aleaga sa inchida aplicatia, caz in care se
vor opri componentele pornite pana acum si se va inchide aplicatia.

Se pot schimba setari ale jocului precum numele jucatorului, situatie in care Modulul GUI va
prelua optiunile utilizatorului si le va transmite Modulului de Logica cu care va interactiona
permanent. Modulul de Logica va prelua datele de la Modulul GUI si le va stoca permanent in
cadrul unor structuri de date si variabile speciale.

In cazul in care utilizatorul solicita demararea jocului, Modulul de Logica va lansa in aplicatie
Modulul Retea care se va ocupa de conectarea la un server de joc si comunicatia cu acesta.

Modulul Retea si Modulul de Logica vor interactiona permanent.

Odata ce serverul va trimite toate informatiile demararii jocului, Modulul de Logica al

clientului va demara modulele de Render si de Fizica si pe baza informatiilor primite de la ele va
interactiona cu Modulul GUI pentru a afisa jocul. Toate aceste module vor fi coordonate de
Modulul de Logica si vor comunica cu acesta in permanenta pentru a asigura buna functionare a
jocului. Modulul Retea va asigura actualizarea informatiilor pentru toti jucatorii care se afla in
joc.

Modulul fizica va fi apelat in momentul tragerii pentru a calcula traiectoria proiectilului.

Modulul de Render va comunica cu Modulul GUI pentru a plasa obiectele la locul lor in
fereastra de joc.
 Pentru componenta Server, Modulul de Logica este responsabil cu initializarea tuturor
celorlalte module. Clasa Main din acest modul va fi apelata la initializarea serverului si aceasta
va porni si va gestiona celelalte module.

Modulul de retea este responsabil de receptionarea conexiunilor mai multor clienti si de

schimbul de informatii cu acestia. Modulul Retea va primi informatii de la fiecare client in parte,
va gestiona conexiunile lor si le va transmite acestora informatii legate de harta de joc, de scor
sau orice alta informatie necesara lor.

Modulul de Logica va interactiona in permanenta cu Modulul Retea si se va ocupa de buna

functionare a jocului prin trimiterea de informatii coerente fiecarui client. De asemenea serverul
va intermedia comunicatia dintre clienti, acestia comunicand indirect, prin el. Modulul de Logica
va gestiona toti clientii si Modulul Retea se va ocupa de schimbul de informatii cu ei. Astfel va
exista o comunicatie permanenta intre Modulul Retea si Modulul Logica.

Pentru obtinerea informatiilor legate de jucatori sau scoruri precum si alte informatii, Modulul
de Logica va comunica in permanenta cu Modulul MiniDB care va fi initializat de acesta si care
va furniza informatiile solicitate. De asemenea Modulul de Logica va si trimite informatii pentru
stocare catre Modulul MiniDB.

Modulul de Logica va gestiona toate celelalte module ale serverului si va fi responsabil de

buna functionare a acestuia precum si a jocului.
 5. Modelul interfetei cu utilizatorul

5.1 Succesiunea interfetelor

In cadrul modulului GUI, ferestrele aplicatiei sunt afisate in asa fel incat sa fie cat mai
intuitive si usor de explorat pentru utilizator. Acestea vor urma fluxul descris mai jos:

Astfel, utilizatorul va putea naviga din meniul principal pentru a vizualiza fereastra cu
clasamentul jucatorilor avand cele mai mari scoruri, apasand butonul Clasament. Tot din meniul
principal el poate vizualiza fereastra cu detalii despre joc si despre realizatorii acestuia prin
intermediul butonului Autori. Atat din fereastra cu clasamentul, cat si din cea cu autorii se poate
reveni la meniul principal apasand tasta Escape.

Din fereastra cu meniul principal se poate intra in modul de configurare al jocului, prin
apasarea butonului Start. Se va trece in fereastra “Setari optiuni joc”, de unde se va lansa jocul
efectiv prin intermediul butonului Enter. Din “Joc efectiv” avem optiunea de a parasi jocul
reintorcandu-ne la meniul principal, folosind tasta Escape. In caz contrar, la sfarsitul rundei se
va intra automat in fereastra de afisare a statisticilor si optiunilor de cumparare. Daca s-a atins
numarul de runde prestabilit se intra de asemenea automat in fereastra de premiere , de unde prin
Enter se revine la meniul principal.

Daca nu s-a ajuns la numarul de runde setat , apasand Enter, se va intra in fereastra de unde se
va alege urmatoarea harta de joc de catre castigatorul rundei. Revenirea in fereastra de joc
efectiv se realizeaza prin intermediul butonului Enter.

5.2 Ferestrele aplicatiei

5.2.1 Fereastra meniu principal

Meniul principal reprezinta parintele arborelui de ferestre, si arata in felul urmator:

Aceasta fereastra este prima care apare in momentul deschiderii aplicatiei, oferind
utilizatorului (jucatorului) optiuni de navigare in ferestrele jocului.

Butoanele vor fi pozitionate central sub forma unui tabel descris in imaginea de mai sus. Aceste
butoane vor fi Start, prin care jucatorul va inainta spre jocul efectiv, dar prin parcurgerea
ferestrei de Setari optiuni joc.
 La selectarea butonului de Clasament se va afisa clasamentul cu utilizatorii avand cele mai
mari scoruri.

La selectarea butonului de Autori se vor afisa informatii despre joc si despre creatorii
acestuia.

La selectare butonului de Iesire se va inchide aplicatia.

5.2.2 Fereastra Setari optiuni joc

Nota: Aceasta fereastra va aparea doar daca programul curent este serverul.

Reprezinta fereastra unde se vor face setarile fara de care jocul nu ar putea incepe si va avea
ca model urmatorul desen:

In aceasta fereastra se vor putea face setarile privind numarul de jucatori (2 pana la 8), numarul
de runde si strategia de joc (Supravietuire, Distrugere sau Exterminare).
5.2.3 Fereastra Clasament

Este fereastra unde se vor afisa numele celor mai buni 10 jucatori, si scorurile inregistrate de
acestia in ordine descrescatoare, precum in modelul de mai jos :

Acestea vor fi tinute minte printr-o mini baza de date, ce va fi de fapt un fisier XML.
5.2.4 Fereastra Autori

Va cuprinde detalii legate de realizarea si realizatorii jocului:

 5.2.5 Fereastra joc efectiv

Cea mai importanta si mai complexa fereastra, in care utilizatorul va participa activ la
derularea jocului:

In aceasta fereastra vor aparea un numar de tancuri egal cu numarul de jucatori participanti la
joc, o harta ce initial va fi aleasa random, iar mai apoi de castigatorii rundei.

In partea de jos a ferestrei vor aparea toti participantii la joc, in dreptul textului Jucator activ
va aparea numele jucatorului al carui rand este in acel moment, iar in dreptul textului Jucatori
pasivi vor aparea numele jucatorilor care isi asteapta randul.

In partea din stanga sus vor aparea optiunile jucatorului activ, care va putea sa stabileasca
puterea de tragere, si unghiul sub care va trage.

Sus, in partea centrala va aparea Armura, in dreptul careia se va afisa "Nu" daca jucatorul
activ nu si-a cumparat armura, si "Da" in caz contrar. De asemenea va aparea si Arma jucatorului
activ selectata in acel moment si numarul de lovituri ramase cu arma respectiva.

In coltul din dreapta sus se va afisa valoarea elementului Viata, care prin atingerea cifrei de 0
va duce la eliminarea jucatorului.
5.2.6 Fereastra Statistici si cumparare

In cadrul acestei ferestre jucatorul va vizualiza statistici despre evolutia, punctajul

celorlalti jucatori si va avea posibilitatea de a cumpara arme. Fereastra este descrisa in imaginea
de mai jos:

Aceasta fereastra va fi formata din trei component, in chenarul din stanga sus se vor afisa
informatii ale utllizatorului in cauza, in chenarul din stanga se va afisa clasamentul si punctajul
din acel moment, iar in partea de jos a ferestrei se regaseste meniul de cumparare arme/armuri.
 5.2.7 Fereastra Premiere

Aceasta fereastra va aparea automat doar in cazul in cazul in care s-a terminat numarul de
runde setat la inceput.

Aceasta are ca si continut desemnarea celor trei mari castigatori ai jocului: Distrugatorul,
Exterminatorul si Castigatorul la puncte.
 5.2.8 Fereastra Alegere harta

Aceasta fereastra va aparea dupa fiecare runda, mai putin dupa runda finala a jocului. Ea este
descrisa mai jos:

Castigatorul rundei precedente are posibilitatea de a alege harta pentru runda urmatoare, in
timp ce ceilalti jucatori vor putea doar sa apese Enter. Dupa ce toti jucatorii au dat Enter se va
reveni la fereastra de joc efectiv, in urmatoarea runda.
6. Elemente de testare

6.1. Componente critice:

In functie de masina pe care ruleaza, exista cateva module care pot influenta in mod
direct performantele jocului. Modulul de render, prin nivel de detalii, si cel de fizica, prin
realism, pot ridica probleme pentru placa video, respectiv procesor. De asemenea modulul
retea poate ingreuna rularea prin ramanerea intr-o stare de asteptare atunci cand nu se
primeste nimic de la server. De asemenea datele trimise pe retea vor trebui sa fie suficient de
mici pentru a asigura o rulare fluenta.

6.2. Alternative:

In vederea imbunatatirii performantelor video, vor trebui realizate numeroase teste pe

diverse sisteme, cu diverse nivele de complexitate si calitate pentru a gasi o configuratie optima
in raportul calitate/viteza.

In vederea scaderii timpilor de retea se vor folosi pe cat posibil algoritmi de

comprimare a datelor si apeluri asincrone. De asemenea vom avea o mica baza de date intr-un
fisier xml. In cazul in care un parser propriu nu va fi suficient de performant vom putea folosi un
parser specializat oferit de .NET3.5.