Game computing: inginerie

Interacțiune om‐calculator

Dr. Sabin‐Corneliu Buraga – www.purl.org/net/busaco

2.0

Dr. Sabin‐Corneliu Buraga

Facultatea de InformaticăUniversitatea “A.I.Cuza” Iaşi, România



2.0

ingineria dezvoltării jocurilor



2.0

Never show fools unfinished work.

Michael Schrage



2.0



2.0



2.0

Productivity Software Goals Game Goals

Task completion Entertainment

Eliminate errors Fun to beat obstacles

External reward Intrinsic reward

Outcome‐based rewards Process is its own reward

Intuitive New things to learn

Reduce workload Increase workload

Assumes technology needsto be humanized

Assumes humans needto be challenged

Lazzaro & Keeker, 2004



2.0

Game creative design vs. game software design

cerințe, procese, așteptări diferite



2.0

Game creative design Game software design

Livrabile: documente privind proiectarea (producerea) artefactelor creative ale jocului ce va fi dezvoltat

Livrabile: descrieri ale etapelor/proceselor de proiectare a software‐ului de tip joc

Analog planului de producție a unui film

Specific dezvoltării de software tradițional

Oferă viziunea artistică a jocului

Reduce caracteristicile jocului la un set de cerințe specifice

Implică dezvoltarea software‐ului aferent

Specifică maniera de implementare a cerințelor

adaptare după (John P. Flynt & Omar Salem, 2005)



2.0

Caracter interdisciplinar al colectivelor de dezvoltatori



2.0



2.0

Abordări (Michael Mateas & Jim Whitehead, 2007):

focalizate pe aspecte tehnologice (computer science,maths)

interdisciplinare

focalizate pe factori artistici (artistic design, visual arts)



2.0

Necesitatea folosirii diverselor studiilor de caz(use cases)



2.0



2.0

Recurgerea la aplicații, API‐uri, biblioteci, instrumente, componente etc. specializate

implică variate cunoștințeale diverselor arii din computer science



2.0

conform John P. Flynt, Omar Salem, Software Engineering for Game Developers, Thomson, 2005



2.0



2.0

Livrabile: software requirements specification (SRS)

+use cases

traceability matrixtest plan



2.0

Informații ce pot fi folosite în stabilirea cerințelor:utilizatorii‐țintă ai jocului

experiențele anterioare în dezvoltarea de jocuriaspectele privind designul grafic & marketingul

jocurile ce pot fi modificate (mods) pentru a crea noul jocexistența proiectanților și nivelul lor de cunoștințe

structura echipei de programatori



2.0



2.0

Un aspect important este stilul/genul jocului ce va fi dezvoltat(Rollings & Morris, 2004):

Action—lots of frantic button pushingAdventure—the story mattersStrategy—nontrivial choices

Simulation—optimization exercisesPuzzle—hard analytic thinking

Toys—software you just have fun withEducational—learning by doing



2.0

Cele mai bune practici în specificarea cerințelor:completitudineacorectitudinea

considerarea doar a cerințelor necesarefezabilitatea

stabilirea prioritățiloreliminarea ambiguitățilorverificarea & validarea

managementul



2.0



2.0

Dezvoltarea jocului recurge la o documentație de proiectare game design document

sumarul jocului:game summary

narațiunea jocului (sixty‐seconds‐of‐play sequence):play narrative



2.0

Exemplu de sumar al unui joc (John Rose):“Ankh follows the quest for vengeance undertaken by Sekhem,

an Egyptian warrior determined to destroy those who defeated and killed his father. The game focuses on the battles fought by Sekhem

and his party of rebel warriors on their journey to the Egyptian capital of Thebes. These conflicts escalate from skirmishes to bloody clashes as the band of adventurers cross the desert sands of ancient Egypt.

Along the way, additional characters join the band and new enemies attempt to stop Sekhem’s advance. Interaction involves tactical control

of the small army during Ankh’s many mêlées, including strategic maneuvers, hand‐to‐hand combat, and spell casting.”



2.0

Exemplu de sumar al unui joc (John Rose):“The player is faced with winning battle after glorious battle, driving Sekhem toward his final confrontation with Uheset, the bloodthirsty Queen of Egypt. Conflicts take place in real time, stressing the tactical and chaotic aspect of warfare. Each level possesses its own ambiance and strategy, from the barren plains of Thebes to the lush splendor of the Dashur gardens. The graphics of Ankh illustrate the varied and

stylish architecture and landscapes of ancient Egypt. The game’s music varies from haunting chants to blood‐quickening battle drums. All aspects of the game’s art and sound immerse the player

in the primal rage of ancient warfare.”



2.0

Deducții pornind de la sumarul jocului:un unic personaj – Sekhem – corespunzând utilizatorului

celelalte personaje sunt inamici simulați de software (NPCs)

există un voiaj ce implică crearea unor scene în care vor avea loc conflicte armate (bătălii)

stilul artistic al jocului este unul antic



2.0

Tipul jocului este un RPG de strategie



2.0

Descriere (Flynt & Salem, 2005):

“Ankh is a single‐player turn‐based strategy game. The game incorporates features that are common to

PC games, but it also introduces a variety of innovations: advanced resource management, the use of map and character editors, saving/loading of game states.”



2.0

Fiecare componentă este referită prin termenul stripespecificând atât structura/tipul componentei din punct de

vedere software – e.g., clase, obiecte COM, servicii Web,… –, cât și locul în care dezvoltarea componentei îl ocupă

în ciclul de dezvoltare a jocului



2.0

Componente funcționale preliminarii, detaliate în secțiunea Functional Requirements Component View:

Stripe 1: Game Opening2a: Tile Map, 2b: GUI Elements, 2c: Map Editor, 2d: Save Level, 3: Level Template (modeled on 1st level), 4: Character Editor,

5: Game Physics, 6: Inventory, 7: Combat, 8: Skills, 9: Outside World Management, 10: Skills Interface, 11: AI,

12: Remaining Levels, 13: Saving & Loading, 14: Options, 15: Revisions



2.0

User Characteristics:jocul este destinat utilizatorilor de orice vârstă



2.0

Assumptions & Dependencies:jocul poate fi rulat după instalare via programul livrat pe CD

necesită DirectX 9.c pe un sistem Pentium IV sau echivalent, placă grafică având suport pentru Direct3D,

rezoluție: 1024x768, TrueColor, interacțiune via mouse & tastatură

la cererea utilizatorului, pot fi efectuate actualizări online



2.0

Primary List of Functional Requirements (fragment):<R1> Software shall have the capability to save the game state

<R2> Software shall have the capability to return to a saved state by loading a file

<R5> Software shall have an auto‐save feature that automatically saves the game constantly

<R6> Software shall have a timer mechanism that will flush memory to disk periodically (every S seconds)

<R7> Software shall provide the option to save a Replay after a battle<R11> Software shall allow the player to play back at variable speeds

…



2.0

Functional Requirements Component View (fragment):

Stripe 1: Opening – requirements 8, 14‐18, 38, 57Stripe 2b: GUI Objects – requirements 18, 52

…Stripe 2d: Save Level – requirement 4

…Stripe 10: Skills – requirements 14‐21Stripe 11: AI – requirements 24‐26, 37

…



2.0

Design Constraints:

constrângerile de proiectare iau în calcul disponibilitatea, securitatea, mentenabilitatea jocului



2.0

exemplu de use case



2.0

Use case‐urile pot fi folosite pentru a facilitadescrierea scopului jocului, conform descrierii narative



2.0



2.0

Software Design Specification:ipostazele jocului (sistemului) sunt prezentate via view‐uri

desemnate de diagrame UML ori de liste

requirementsconceptualbehaviorallogical

component



2.0



2.0

De la un scenariu descris de un use case la interacțiuni inter‐obiecte



2.0

Documentația de specificare a designului jocului are structuraunui document de tip SDD (Software Design Document):

1. Introduction: purpose, scope, definitions & acronyms2. References

3. Conceptual view: use case, diagram,…4. Behavioral view: object diagrams

5. Logical view: class diagrams6. Component view: diagrams

7. Deployment view



2.0

conceptual view – exemplificare



2.0

component view – componentele implicateîn acțiunea de deplasare a unui personaj de joc



2.0

component view – exemplificare la nivel de stripe



2.0

Aspecte de considerat la redactarea documentului de design:



2.0

Structura generală a unui game design document (Rouse, ‘05)Table of Contents

Introduction/Overview Game Mechanics

Artificial Intelligence Game Elements Story Overview

Game Progression System Menus



2.0



2.0

Șabloane comune ce pot fi aplicate la dezvoltarea de jocuri:SingletonComposite

Chain of ResponsibilityState

StrategyObserverFaçade

MementoCommand



2.0

Recurgerea la Strategy pattern pentru a simplifica schimbările de atitudine la personajele de tip NPC:



2.0

Command pattern pentru implementarea comenzilor:



2.0

Proiectarea iterativă (iterative design)

uzual, are loc la nivel de fiecare stripe

de la stabilirea cerințelor la componente



2.0



2.0

activitățile realizate la o iterație la nivel de stripe



2.0

Exemplu de proiectare vizuală a stripe‐ului Level Template



2.0

Exemplu de proiectare a personajelor



2.0

Reguli de proiectare a jocurilor puzzle (Rollings & Morris, ‘04)

Don’t be too cuteAvoid “serious” violence

Keep it abstract, but not too abstractGive rewards for progress

exemplu de succes: Lemmings



2.0

Componente (subsisteme) primare (Rollings & Morris, ‘04):User interface

Bidirectional event handlerData engine (graphics, level, miscellaneous data)Dynamics system (collisions and general physics)

Logic engine (the heart of the game)Graphics engineSound engine

Hardware abstraction layers(interfaces with graphics, sound, and controller hardware)



2.0

Subsisteme secundare:Game configuration system

Menuing systemOnline instructions and help system

Music system



2.0

Criterii de reutilizare a componentelor/bibliotecilor existente:disponibilitatecorectitudineactualitate

utilizare imediată

mentenabilitatelicențiere

compatibilitate



2.0

Software engineering risk assessment

prevenirea, reducerea, managementul (controlul) problemelor critice



2.0

Risc extern Risc intern

Probleme legale (copyright, licentiere,…)

Timpul alocat dezvoltării jocului

Prețul jocului Structura colectivelorimplicate în dezvoltare

Drepturi (royalties) acordatedezvoltatorilor & altora

Gradul de inovare tehnică

Costul punerii la dispoziția consumatorului

Gradul de creativitate artistică

Timp alocat marketing‐ului Tipul tehnologiilor implicate

Suportul organizațional Maniera de înțelegere a cerințelor

Atingerea stadiului de maturitate dorit

Metodologia de dezvoltare adoptata

Susținătorii proiectului Alte tipuri de risc



2.0

Aspecte de interes privind riscurile externe:finanțarea

suportul la nivel de organizațieresursele disponibile – e.g., transport

suportul acordat clienților (customer support)creativitatea – e.g., artiști grafici, suport muzical & vocal,…



2.0

Aspecte de interes privind riscurile interne:echipamentele (logistica)

membrii echipelor de dezvoltatoritehnologia – e.g., cea de ultimă oră

inspirația (creative input)durata de dezvoltare a produsului



2.0

Depinde de scopuri

exemple tipice:reduce lost productivityincrease productivity

increase opportunities for aesthetic expressionincrease opportunities for technical innovationcreate a safer environment for experimentation

reduce the number of errors the game has when it shipsadd to the quality of the development experience



2.0

Paradigma clasică (Robert N. Charette, 1989)



2.0

conform Andrew Rollings & Dave Morris, Game Architecture and Design: A New Edition, New Riders, 2004



2.0

Poate fi divizată în activități de verificare, validare & explorare



2.0

Planificarea fazelor testării jocului (Flynt & Salem, 2005)



2.0



2.0

Planificarea dezvoltării unui joc



2.0



2.0

Jucătorul poate avea la dispoziție un ghid de utilizare

strategy guideoferă descrierea interacțiunii cu jocul, inclusiv regulile & maniera de jucat

aspecte ce trebuie menționate: skills, key combinations, options, characters, character powers, effects, spells, healing, maps of levels, help etc.



2.0

modelarea la nivel înalt a unor jocuricrearea unui joc simplu de tip MMORPG

dezvoltarea unui joc sportiv de simulare pentru vârstnici



2.0

Modelarea jocurilor Pong & Pac‐Man

problemă: cum pot fi modelate entitățile unui joc?

A. Rollings & D. Morris, Game Architecture and Design: A New Edition, New Riders, 2004



2.0

Orice joc interacționează cu măcar 1 jucător uman

Toate jocurile prezintă elemente discrete – numite tokens –manipulate (in)direct de jucător

Token‐urile sunt gestionate intern de software

Conceptual, un joc poate fi descrisîn termeni de jucători + token‐uri



2.0



2.0

Token‐urile pot fi clasificate specificarea unei ierarhii

cazul Pong



2.0

Pot exista diverse interacțiuni între token‐uri – e.g., coliziuni –ce sunt specificate uzual via token interaction matrix

interacțiuni simetrice versus interacțiuni asimetrice



2.0

Anumite interacțiuni pot conduce la producerea unor evenimente ce vor fi tratate la nivel de cod

Interacțiunile dintre diverse token‐uri pot fi simplificate dacă se recurge la token‐uri intermediare

(e.g., însăși lumea jocului, agenți cu rol de broker‐i etc.)

Comportamentul token‐urilor poate fi descris via automate



2.0

modelarea comportamentului NPC‐urilor de tip ghostla Pac‐Man



2.0

automatul specific token‐uluireprezentând lumea jocului (world game)



2.0

Crearea unui joc simplu de tip MMORPG

ilustrează învățarea conceptelor de baze de date via game development

după o prezentare de Greg Wadley & Jason Sobell,The University of Melbourne, Australia

în cadrul Academic Days 2007



2.0

Un MMORPG este un sistem software informațional

starea jocului se stochează central (pe un server)datele sunt persistente

accesul la date este concurentutilizatorii posedă identități, trebuind să fie autentificați

interacțiunea se realizează la client via o interfață‐utilizator



2.0

Mediul (lumea) jocului poate fi modelat(ă)printr‐o matrice de locații, fiecare având diverse caracteristici

jucătorii – umani sau generați de calculator – se pot deplasa în cadrul caroiajului, putând concura unul cu celălalt



2.0

1 2 3 4 5 6 7 8 9 1011 12 13 14 15 16 17 18 19 20

10099

X, 1 to 10

Y, 1 to 10



2.0

Folosind o imagine de fundal, poate fi realizat designul vizual



2.0

Locația curentă a jucătorului va trebui redată diferit

Etichetele specifică sănătatea & punctajul curent

Via diverse mijloace de interacțiune, vor fi afișate obiectele aflate în posesia fiecărui jucător + mesajele jocului

Se oferă și posibilitatea de a observa/interacționacu alți jucători



2.0

proiectare & implementare minimală a interfeței jocului(aplicația‐client la nivel de desktop)



2.0

modelarea datelor via tabele



2.0

Partea de procesare e implementată de proceduri stocate

facilitează accesul la date(concurența este rezolvată pe baza tranzacțiilor)

descriu comportamentul fiecărui control de interfață

pot fi apelate periodic via un timer existent la client



2.0

Procedure Inputs Outputs

spLogin PlayerName, Password 1 row from Player table

spMovePlayerTo PlayerId, X, Y ‘Success’ = 1 or 0

spGetPlayer PlayerId Player and room details

spGetItems RoomId list from Item table

spGetPlayers PlayerId, RoomId list from Player table

spGetInventory PlayerId list from Item table

spPickUpItem PlayerId, ItemId (none)

spDropItem PlayerId, ItemId (none)

spAttack PlayerId, VictimId, ItemId Message about damage

spGetAllPlayers (none) list of PlayerId, PlayerName

spAddChat Text, PlayerId1, PlayerId2 (none)

spGetChat PlayerId list of PlayerName, ChatText

spAddEvent PlayerId, EventDetail (none)

spLogout PlayerId (none)



2.0

spMovePlayerTo (@PlayerID integer, @NewX integer, @NewY integer)

IF EXISTS (SELECT * FROM Room WHERE X=@NewX AND Y=@NewY)BEGIN UPDATE Player SET RoomID =(SELECT RoomID FROM Room WHERE X=@NewX AND Y=@NewY)WHERE PlayerID = @PlayerID

SELECT 1 As 'Success'ENDELSE

SELECT 0 As 'Success'



2.0

Fiecare acțiune a unui jucător afectează vizualizarea datelorde către ceilalți utilizatori

Starea jocului poate fi specificată via modele simple de date:jucători, obiecte, evenimente,…

Recurgând la un sistem de baze de date, se poate simplifica problema accesului concurent

Separarea clară a prezentării de procesare & stocare a datelor



2.0

Această abordare este folosită și de jocurile comerciale

“Almost nothing about any object in Age of Empires is hard coded into the program. Huge tables of information describe

every characteristic of every object that appears in the game. The game designers used a system of over 40 Paradox database tablesto control and shape the game. As a result, they were able to constantly

update and tweak the game, and then test their changes without having to involve a programmer.”

Game Developer Magazine, martie 1998



2.0

Dezvoltarea unui joc de simulare dedicat persoanelor vârstnice – Pentanque

procesul de proiectare este controlat de utilizatorii finali:human‐driven design process

Vero Vanden Abeele et al., A Soft Approach to Computer Science: Designing & Developing

Computer Games for and with Senior Citizens, 2006



2.0

1. EthnographicObservations

2. ParticipatoryDesign

3. Presentation of Concepts

4. Development

5. Evaluation



2.0

Specificarea caracteristicilor jocului:sports‐simulation

2 playersintuitive, consistent controls

not competitive, but “feel good”practice and play modes

visual and auditory explanationscompose a team of unique characters with individual skills

consistent 2D and 3D, with matching sound



2.0

Instrument de dezvoltare: Virtools (Dassault Systems)



2.0

Prototipizare timpurieîn vederea testării de către utilizatorii finali



2.0

Stadiul actual al industriei jocurilor (Rollings & Morris)



2.0

Posibil model viitor (Rollings & Morris)



2.0

Un tot mai mare accent pus pe jocuri socialedisponibile la nivel de Web & de dispozitive mobile

social game computing



2.0



2.0

game computingaspecte privind ingineria dezvoltării de jocuri



2.0

Technology

Game computing: inginerie