Designul Jocurilor Video pe Mai Multe Platforme

Abstract

Această lucrare de licență abordează proiectarea și problemele asociate de dezvoltare identificate în cadrul genului platforma de joc. În scopul de a crea o înțelegere a complexității fiecărei categorii – precum și de posibilitățile de utilizare a categoriilor ca orientări atunci când se dezvoltă o platformă de joc – un joc prototip a fost dezvoltat. Categoriile de punere în aplicare incluse în prototip a fost apoi măsurat cu un set de valori de complexitate software-ului. Această lucrare de licență va motiva și va explica selectarea categoriilor de implementare, pentru utilizarea valorilor de complexitate software, precum și să prezinte o documentație detaliată a dezvoltării prototipului. Rezultatul acestei lucrari de licență este o prezentare detaliată a categoriilor de implementare atașate cu exemple de complexitate pentru fiecare categorie, precum și un prototip al unui joc complet. Rezultatele complete ale acestei teze sperăm că va fi de ajutor în proiecte de joc la scară mică, independente sau academice în ceea ce privește proiectarea , procesul de luare a deciziilor, prioritizarea și planificarea timpului.

Cuvinte cheie: dezvoltare joc , design de joc , platforma de jocuri , complexitatea software-ului , cadru , analiza , prototip

Cuprins

Introducere

Fundal

Formularea problemei

Ipoteza

Grupul tinta

Limitarile

Cercetarile precedente

Dispozitia

Cap. 1. Fundalul

Complexitatea software

Mediul de dezvoltare

1.2.1 Modelul design-ului

1.2.2 Software extern

Cap. 2. Metode

Categoriile implementarii

2.1.1 Componentele nivelului

2.1.2 Mecanica Avatarului

2.1.3 Nivelul Vizual

2.2 Prototipul si complexitatea masurata

2.2.1 Prototipul

2.2.2 Masurarea complexitatii

Cap. 3 Rezultate

3.1 Implementarea #1

3.1.1 Productia

3.2 Implementarea #2

3.1.1 Productia

3.3 Implementarea #3

4.1.1 Productia

3.4 Implementarea #4

4.1.1 Productia

Cap.4 Rezultatele analizei

4.1 Observatii

4.2 Reflectarea asupra problemei

Cap. 5 Discutia asupra proiectului

5.1 Utilizabilitatea

5.2 Aspecte sociale

Concluzia

Dezvoltare viitoare

Referinta

Introducere

Acest capitol va face referire la fundal , formularea problemei induse de designul grafic al unui joc , ipoteza , grupul tinta , limitarile , cercetarile precedente si dispozitia.

Fundalul

Designul de jocuri este una din etapele esențiale în dezvoltarea jocurilor în special celor video. Fiind un porcedeu complex, acesta este împărțit în mai multe etape. Printre aceste etape se numară: modul de joc, povestea, mecanica jocurilor,designul de nivel și multe altele.

Un joc video sau platformer este un joc în care gameplay-ul se învârte în jurul ideii de mișcare și sărituri între obstacole și obiecte asociate ca platforme. Genul în sine nu poate fi pe deplin considerat un gen de sine stătător, deoarece este adesea combinat cu alte genuri de jocuri, cum ar fi jocuri cu împușcături și jocuri cu roluri. Platforma de joc gen provenit de pe scena arcade în jocuri de introducere la începutul anilor 1980, cum ar fi Space Panic (Universal, 1980) și Donkey Kong (Nintendo, 1981).

Pe parcursul următorului deceniu al genului platforma produce unele dintre cele mai populare jocuri influente pana in prezent, cu titluri precum Super Mario Brothers (Nintendo, 1985) – care au deținut titlul de a fi tot timpul de joc cel mai bine vandut timp de trei decenii – Sonic Hedgehog (Sega , 1991) și Super Mario Brothers 3 (Nintendo, 1993) . Cu toate că acest gen a urmat dezvoltarea 3D în secolul 21, cu jocuri, cum ar fi Super Mario Sunshine (Nintendo, 2002) și Rayman 3: Hoodlum Havoc (Ubisoft, 2003) genul platformă a început să arate în scădere de popularitate în piață. D. Boutros prevede că genul platforma sa bucurat de 15% din piața de jocuri video în 1998, în comparație cu 2% în 2002. Cu toate acestea, Boutros nu dadea vina pe genul în sine:

"Noi credem că nu este o chestiune de gen, ci o chestiune de principii de proiectare eficiente din trecut să fie uitat"

Afirmația făcută anul 2006, s-ar putea să fi fost exacte pe moment , deoarece astăzi asistăm la un interes reînnoit în genul de platformă cu jocuri de succes, cum ar fi New New Super Mario Bros 1 și 2 (Nintendo 2006, 2012), Braid (Jonathan Blow 2008 ), Donkey Kong Country Returns (Nintendo 2010) și Rayman Origins (Ubisoft, 2011) [27]. Este interesant de observat că recenta reapariție a interesului pentru genul platforma , , ,care se pare să fie paralelă cu versiunile ale acestor jocuri, deoarece cele mai multe dintre ele, în esență, sunt remake-uri ale unora dintre cele mai bine vandute jocuri platforma 2D din anii 1980 și 1990. Acest lucru întărește afirmația D. Boutros , indicând faptul că aceste componentele de design importante, de fapt, sunt uitate.

Formularea problemei

Formularea problemei acestei lucrari de licență poate fi pentru toate problemele considerate ca fiind echivalente cu concluziile trase de Boutros. În consecință, formularea problemei acestei lucrari de licență se bazează pe ipoteza că elementele importante legate de design – care ar putea contribui la rata de succes a unui platforme – poate fi adesea trecute cu vederea sau depriorizată în procesul de dezvoltare.

D. Boutros prezintă următoarea concluzie, care va servi drept principala problemă în această lucrari de licență :

“În dezvoltarea modernă a platformelor de joc, principiile de proiectare eficiente din trecut este adesea trecute cu vederea sau uitate”.

D. Boutros , atunci sugerează că această problemă provine în principal, de la dezvoltatorii platformelor moderne pentru "lărgirea pieței" , prin jocul lor mult mai ușor și, prin urmare, mai accesibile unui public mai larg. Apoi, el proclamă că acest lucru poate avea ca rezultat un efect gresit , producând jocuri mai puțin de succes, care tind să demonstreze lipsa unor similitudini cu cel mai bine vandut anterior si populara platforma de jocuri. Este important de subliniat că această teză nu va încerca să rezolve această problemă destul de mare și general, pe cont propriu. În schimb, această lucrare de licență va viza în primul rând dezvoltatorilor din domeniul academic cât și pentru dezvoltatori la scară independente și mici, în general. Din cauza acestui grup țintă specific a fost luată decizia de a include două posibile motive care stau la baza suplimentare pentru aceeași problemă:

Lipsa de cunoștințe în ceea ce privește componentele recurente legate de proiectare și caracteristici de la platforma de jocuri de succes anterioare.

Lipsa de cunoștințe în ceea ce privește consumul de timp, complexitatea și prioritizarea acestor componente în timpul procesului de dezvoltare.

Ipoteza

Strategia este să facem diferenta intre jocurile de platforma din anii ’80 si cele din prezent. In anii ’80 , exista ipoteza că jocurile arcade vor prospera si toate aceste “invatături” vor fi uitate.

Grupul tinta

Acest studiu trebuie considerat ca fiind pentru o scara mica de oameni , facand referire la devoltatorii din domeniul academic , cat si la dezvoltatorii independenti. Cu toate acestea, teza poate fi, de asemenea, de interes în ceea ce privește alte domenii. De exemplu, teza speculează și elaborează pe teme legate de general, design-ul jocului și la nivel de proiectare, care pot fi de interes pentru orice individ ce doreste studierea zonei de joc-design.

Limitarile

Datorită limitării timpului acestei teze, trebuie subliniat faptul că prototipul final utilizat pentru măsurarea complexității poate fi considerat ca fiind destul de mici dimensiuni. Acest lucru nu înseamnă neapărat că datele obținute din măsurătorile nu vor fi corecte în ceea ce privește mai complexe projects.-proiectare.

Cercetarile precedente

Este important să se sublinieze faptul că această teză este în primul rând un studiu de sortare practică. Cea mai mare parte a timpului și a efortului a fost pus în dezvoltarea prototipului jocului și măsurarea complexității din diferitele categorii de implementare. Cu toate acestea, pentru a se asigura că nici o astfel de cercetare ar fi făcut deja – și mai presus de toate, pentru a fi în măsură să identifice și să analizeze componentele importante la platforma de joc – a fost extrem de necesar să se uite mai adânc în domeniul pentru a vedea ceea ce a fost deja făcut.

Dispoziția

Restul lucrarii de licentă va continua in capitolele următoare.

În Capitolul 1 voi vorbii despre fundalul jocului , complexitatea software-ului , arta de a crea jocuri , de mediul de dezvoltare , motoarele de creare și ȋnființarea unui joc pe calculator , când ai nevoie de un desing și un software extern.

În Capitolul 2 voi vorbii despre metodele implementării , macanicile avatarului , construcția acestuia si nivelul vizual al acestuia. Fiecare din metode și mecanici au o complexitate ce trebuie masurată și desemnarea prototipului asupra avatarului.

În Capitolul 3 voi vorbii despre rezultatele obținute , fiecare implementare având propriile metode.

În Capitolul 4 voi vorbii despre rezultatele analizei, observațiile și reflectarea asupra problemei descrise in aceasta licentă.

În Capitolul 5 voi vorbii despre acest proiect , utilizabilitatea si aspectele sociale ce le poate cuprinde această licentă.

Cap. 1. Fundalul

În scopul de a crea o mai bună înțelegere a rezultatelor licenței și modul în care acestea au fost generata, acest capitol va oferi o analiză de bază de complexitate a software-ului și a modului în care acesta poate fi măsurat. În plus, acest capitol va include o declarație a mediului de dezvoltare și software-ul utilizat la programarea jocului prototip destinat acestei teze.

1.1 Complexitatea software

Înainte de a prezenta datele colectate de complexitatea implementării prototipului , justificat să se clarifice sensul complexității conceptului prin care descrie procedura de măsurare asociate complexității ȋn diferite părți ale unui program software. În dezvoltarea de software, măsurarea unei caracteristici specifice a performanței unui program, eficiența sau calitatea este adesea menționată ca o valoare .

L.h Rosenberg și colab. rezuma unele dintre cele mai comune atribute software specifice pentru măsurarea metrică ca : eficiență, complexitate, inteligibilitatea, reutilizabilitatea , mentenabilitate și testabilitatea. Având în vedere că obiectivul principal al acestui studiu este acela de a crea o înțelegere a consumului de timp și complexitatea software-ului general legate de categoriile de implementare , evaluarea noastră se va concentra în primul rând asupra complexității și inteligibilitatea atributelor.

Pentru acest studiu, valorile dovedit a fi cele mai relevante în ceea ce privește formularea problemei au fost selectate.

Valorile selectate, inclusiv motivația, sunt:

Linii de cod: Poate cel mai de bază de valori în ceea ce privește măsurarea dimensională a unei metode sau clasă . Liniile de cod metrice pot fi măsurate într-o varietate de moduri . Pentru această licență , cu toate acestea, liniile de cod vor fi reprezentate de un cod non generat automat. Prin urmare, cantitatea de linii de cod nu va reprezenta numărul exact de linii din codul sursă. Prin excluderea tuturor liniilor de cod irelevante ,eu sper să cresc generalizarea rezultatului, făcându-l cât mai general posibil, indiferent de cadru și limbaj de programare, precum și a crea o înțelegere mai exactă a dimensiunii reale a fiecărei punere în aplicare. Motivația pentru inclusiv liniile de cod se datorează faptului că am găsit-o a fi cea mai concretă și drept înainte metrice în ceea ce privește măsurarea dimensiunii.

Complexitatea : O valoare destul de complicată proiectat de Thomas J. McCabe, cu scopul de a măsura puterea logică a unui program.

Metrica este definită ca "măsurarea cantității de logica a deciziei într-o funcție de cod sursă . În cazul acestui studiu, această valoare va fi utilizată pentru a măsura cantitatea de decizii luate într-o anumită metodă. Motivația pentru includerea acestei valori se datorează faptului că valoarea deciziilor într-o metodă , în mod evident consumul de timp, în ceea ce privește programarea.

Adâncimea : Această valoare este definită ca "indică numărul de definiții de clasă care se extind la rădăcina ierarhiei de clasă. L.h Rosenberg subliniază faptul că o adâncime mare de moștenire în cadrul unei clase creează o complexitate de design mai mare, dar crește potențialul de reutilizare.

Mediul de dezvoltare

Scopul acestei lucrari de licență este de a prezenta un rezultat generalizat, utilizabil indiferent de limbaj de programare ales si/sau un mediu. Mediul înconjurător programing utilizat în acest studiu cu toate acestea, este Unity 5.2 , împreună cu limbajul de programare C #.

Unity este un motor de joc multiplatform dezvoltat de Unity Technologies și folosite pentru a dezvolta jocuri video pentru PC, console, dispozitive mobile și site-uri web.

Cinci versiuni majore ale Unity au fost eliberați. La WWDC show-2006, Apple a numit Unity ca runner-up pentru cea mai bună utilizare sa din categoria Mac OS X Graphics.

Proiectarea modelului

Înainte de a prezenta datele de complexitate, este, de asemenea, important de remarcat faptul că complexitatea software-ului și valoarea sa de cod poate diferii în funcție de alegerea modelului de proiectare. În acest studiu vom practica modelul de proiectare MVC (Model-View-Controller), care este un model de design bine utilizat și destul de populară în cadrul de dezvoltare de software, în general, [24]. Logica de bază a MVC este de a diviza software-ul în trei componente: Model, View și Controller. Poate că cea mai importantă componentă centrală este modelul care conține reguli și logica ale software-ului. În acest studiu , clasele din cadrul modelului va conține regulile și comportamentul. Componenta de View se ocupă de generarea ieșirii programelor, precum și informarea Controlorul cu privire la orice utilizator.

În acest studiu, cursurile din cadrul View se vor ocupa de randarea grafică și de sunet, de manipularea aparatului de fotografiat, precum și a detecta intrările utilizatorului.

Controler-ul este ca o legătură între componentele modelului și View prin care indica actualizarea modelelor .

Exemple ale background-ului:

Dupa cum observați , am expus background-ul din diferite unghiuri.

Software extern

Ca software extern am folosit assert-uri si script-uri din magazinul Unity.

Cap. 2. Metode

Acest capitol va oferi o acoperire detaliată a metodelor utilizate în cadrul acestei lucrari de licență. Realizarea acestei lucrari de licență poate fi împărțită în două proceduri principale: o analiză teoretică și una practică.

Categoriile implementarii

În scopul de a crea un cadru de lumină pentru a dezvolta o platformă de joc cu obiectivul extins de măsurare a complexității diferitelor categorii de proiectare și dezvoltare asociată, trebuie mai întâi să identificăm care aceste categorii sunt. Lucrarea de licență subliniază faptul că toate componentele importante, de multe ori se deprioritized sau uitate – decizia a fost făcută pentru a include, de asemenea, mai multe componente evidente, cum ar fi eliberarea jucătorului.. Această decizie a fost motivată de dorința de a crește generalizarea cadrului nostru, astfel incluzând un design mai evident și precum și componente.

2.1.1 Componentele nivelului

Subcategoriile din componentele unui nivel sunt :

Platforma – Orice obiect pe care jucătorul poate să treacă peste, sari sau să navigheze pe poate fi definită ca o platformă. Motivația pentru includerea acestui componentă este un motiv evident, deoarece acesta este elementul de bază al unui joc de platformă. Chiar dacă platformele sunt obligatorii pentru o platformă de joc, am găsit-o a fi de interes pentru a investiga complexitatea reală a acestei funcționalități, deoarece este împreună cu mecanica player-ului , funcționalitatea cea mai mare este prioritatea la începutul oricărei dezvoltari a unui joc de platformă.

Obstacole – Smith și colaboratorii definesc această componentă ca fiind "orice obiect care este capabil de a provoca daune player". În această lucrare de licență, ȋn această subcategorie se vor include toți dușmanii, proiectilele și piesele de pe sol care provoacă daune sau deces jucătorului. Alegerea acestei subcategorii ar putea fi, de asemenea, considerate ca fiind mai degrabă auto-explicative, deoarece obstacolele reprezintă principala sursă de provocare pentru orice platforma de joc. Cu toate acestea, această subcategorie poate să nu fie întotdeauna la fel de prioritare, deoarece este folosită ca și consumatoare de timp, în funcție de cantitatea de inamici spawnati.

Ajutoare de circulație – Orice obiect care să sprijine capacitatea de circulație a jucătorilor, în plus față de mecanica jucătorului. Exemple de astfel de obiecte sunt case, mașinuțe, scaune,parti componente, scări și frânghii. Această subcategorie credem ca este un exemplu tipic de componente care tind să fie trecute cu vederea. Prin urmare, este de mare interes pentru a investiga complexitatea reală și consumul de timp, o funcționalitate ca aceasta s-ar putea genera in timp.

Declanșatori – O altă componentă identificată de Smith și definită ca "obiecte interactive pe care jucătorul poate utiliza pentru a modifica stadiul nivelului sau chiar regulile de joc, cum ar fi fizica".Eu cred ca aceasta subcategorie trebuie să fie un alt exemplu interesant de funcționalitate care ar putea să nu fie întotdeauna o prioritate.

Elemente Collectable – Ultima subcategorie este definită ca fiind orice element de joc, care oferă un fel de recompensă. Exemple de astfel de elemente sunt monede, puncte, vieți suplimentare și de power-up-uri. Complexitatea acestei subcategorii este de asemenea considerată a fi de mare interes, deoarece elementele colectabile pot mări gameplay-ul în atât de multe feluri și totuși poate că nu i se acordă o atenție la fel de multa pe cat ar trebui.

2.1.2 Mecanica Avatarului

La a doua categorie de implementare, am ales din titlu de Mecanica Avatarului. Prin "Avatar" pur și simplu ne referim la caracterul jucătorului în cadrul jocului. Motivul pentru această definiție se datorează faptului că cuvântul "jucător", în unele studii se referă la persoana care joacă jocul, mai degrabă decât caracterul în joc. În această lucrare de licență, jucătorul se va referi întotdeauna la caracterul real în joc și nu persoana care joacă jocul. De aceea , am ales să folosim definiția "avatar", pentru a se evita orice neînțelegere.

Subcategoriilor din această categorie este definită și motivată după cum urmează:

Coliziune – Această subcategorie include toate funcționalitate legate de coliziune între avatarul și mediu, inclusiv platforme și obstacole. Această subcategorie nu a fost găsită în nici o cercetare anterioare, probabil datorită faptului că acesta este în mod exclusiv din punctul de vedere al unui dezvoltator, mai degrabă decât din perspectiva unui designer. De la un punct de vedere dezvoltatorii cu toate acestea, această subcategorie este de mare importanță, deoarece această funcționalitate necesita o cantitate mare de timp și efort.

Mecanica de bază – Această subcategorie include funcționalitatea care reprezintă toate mecanismele de bază ale avatarului, cum ar fi sărituri și în mișcare.  mecanica suplimentare – Ultima subcategorie intenționează să acopere orice mecanică suplimentă legată de avatar. Motivația pentru crearea acestei subcategorii derivă din cantitatea mare de posibilități în ceea ce privește avatarul. După cum sa menționat în introducere, o platformă de joc poate sau nu poate include, de asemenea, aspecte legate de alte genuri de joc, cum ar fi împușcături. Cu aceasta în minte, putem trage concluzia că mecanica avatarului poate include o mare varietate de mecanici, cum ar fi lovirea, fotografiere și crawling-ul. În consecință, orice mecanica a unui avatar dincolo de mecanica mai tradițională – ar trebui să fie plasate aici – menționate în ultima subcategorie.

2.1.3 Nivelul Vizual

A treia și ultima categorie de punere în aplicare, cu titlul nivelul vizual , include toate graficele și sunetele existente in aceasta lucrare de licență. Din punctul meu de vedere, dezvoltatorii ar trebui sa nu abordeze jocurile numai dupa aspectele estetice. În această lucrare de licență ne aflăm în ipoteza că funcționalitatea ca efectele vizuale si spectaculoase nu concep intreg jocul de platforma , ci și modul de joc si povestea. Având în vedere că punerea în aplicare a graficii și a sunetului poate fi destul de consumatoare de timp, în funcție de dezvoltatorii artistici – este uneori dificil să punem in echilibru funcționarea logistică si elementele vizuale. Cu aceste motivații în minte, am împărțit această categorie în două subcategorii principale:

Grafica – care reprezintă codul legat de aspectul grafic.

Sunet – care reprezintă codul legat de aspectul sunetului.

Prototipul si complexitatea masurata

A doua procedură principală a acestei lucrari de licență este de tip pur practic. Această procedură include punerea în aplicare a unui prototip de joc. Acesta acoperă, de asemenea, toate măsurătorile efectuate pentru complexitatea acestui prototip. Pentru a măsura complexitatea software-ului, a categoriilor de implementare și subcategoriile acestora, decizia a fost făcută pentru a dezvolta un prototip platforma de joc care ar include cât mai multe dintre categoriile de punere în aplicare. Un alt scop a fost de a investiga posibilitățile de utilizare a categoriilor de punere în aplicare ca orientării atunci când se elaborează o platformă de joc de la zero. Procesul de implementare a fost executat iterativ rezultând în patru iterații. Aceste iterații vor fi denumite implementare 1-4 în Capitolul 3: Rezultate.

La sfârșitul fiecărei iterații, s-au efectuat măsurători de complexitate.

Prezentare generala – Un text introductiv va fi prezentat la începutul fiecărei documentații rezultate. În urma introducerii, va exista o imagine de ansamblu a claselor implementate împreună cu o diagramă de clasă. Scopul prezentării unei diagrame de clasă la fiecare iterație este de a crea o imagine mai clară a opțiunilor structurale realizate în punerea în aplicare.

Prezentarea de ieșire – Un depozit de ecran care arată rezultatul de ieșire de la punerea în aplicare.

Cap. 3 Rezultate

Acest capitol se va prezenta rezultatele derivate din prototipuri celor patru iterații. Cele patru iterații vor fi denumite în continuare Implementare #1-4.

3.1 Implementarea #1

Prima implementare prototip a condus la funcționalitate celor trei subcategorii găsite în categoriile de punere în aplicare. Aceste subcategorii au fost: platforme, coliziune și de bază mecanică. În plus, această punere în aplicare include, de asemenea, o proprietate din obstacole. Datorită limitării timpului a acestui studiu, această lucrare de licență va prezenta o implementare a platformei în mișcare, excluzând în același timp platforme diagonale.

3.1.1 Productia

Figura 3.1 Diagrama de clasa ce arata relatiile intre background si celelalte obiecte

Figura 3.2 Obstacolul dimbolizant un grup de bolte

Figura 3.3 Obstacol simbolizând o mașinuța de pompieri

Figura 3.4 Obstacol simbolizând o mașina

Figura 3.5 Obstacol simbolizând un dulap

Figura 3.6 Obstacol simbolizând un trenuleț

Figura 3.7 Obstacol simbolizând o bâtă de crichet

Figura 3.8 Obstacol simbolizând un ceas

Figura 3.9 Obstacol simbolizând un grup de case

Figura 3.10 Obstacol simbolizând un grup de bucăți lego

Figura 3.11 Obstacol simbolizând un braț de papușă

Figura 3.12 Background-ul impreuna cu toate obstacolele