Game computing: inginerie

Interacțiune om‐calculator 2.0

Dr. Sabin‐Corneliu Buraga

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

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


ingineria dezvoltării jocurilor



Never show fools unfinished work.

Michael Schrage



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 needs Assumes humans need
to be humanized to be challenged

Lazzaro & Keeker, 2004


Game creative design vs. game software design

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



Game creative design Game software design
Livrabile: documente privind Livrabile: descrieri ale
proiectarea (producerea) etapelor/proceselor de
artefactelor creative proiectare a software‐ului
ale jocului ce va fi dezvoltat de tip joc
Analog planului de producție Specific dezvoltării de
a unui film software tradițional
Oferă viziunea artistică Reduce caracteristicile jocului
a jocului la un set de cerințe specifice
Implică dezvoltarea Specifică maniera de
software‐ului aferent implementare a cerințelor
adaptare după (John P. Flynt & Omar Salem, 2005)


Caracter interdisciplinar al colectivelor de dezvoltatori



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

focalizate pe aspecte tehnologice (computer science, maths)

interdisciplinare

focalizate pe factori artistici (artistic design, visual arts)



Necesitatea folosirii diverselor studiilor de caz
(use cases)



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

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



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


Livrabile:
software requirements specification (SRS)
+
use cases

traceability matrix
test plan



Informații ce pot fi folosite în stabilirea cerințelor:
utilizatorii‐țintă ai jocului
experiențele anterioare în dezvoltarea de jocuri
aspectele privind designul grafic & marketingul
jocurile ce pot fi modificate (mods) pentru a crea noul joc
existența proiectanților și nivelul lor de cunoștințe
structura echipei de programatori



Un aspect important este stilul/genul jocului ce va fi dezvoltat
(Rollings & Morris, 2004):
Action—lots of frantic button pushing
Adventure—the story matters
Strategy—nontrivial choices
Simulation—optimization exercises
Puzzle—hard analytic thinking
Toys—software you just have fun with
Educational—learning by doing



Cele mai bune practici în specificarea cerințelor:
completitudinea
corectitudinea
considerarea doar a cerințelor necesare
fezabilitatea
stabilirea priorităților
eliminarea ambiguităților
verificarea & validarea
managementul



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



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.”


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.”


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



Tipul jocului este un RPG de strategie



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.”



Fiecare componentă este referită prin termenul stripe
specificâ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



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

Stripe 1: Game Opening
2a: 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



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



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



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
…


Functional Requirements Component View (fragment):

Stripe 1: Opening – requirements 8, 14‐18, 38, 57
Stripe 2b: GUI Objects – requirements 18, 52
…
Stripe 2d: Save Level – requirement 4
…
Stripe 10: Skills – requirements 14‐21
Stripe 11: AI – requirements 24‐26, 37
…


Design Constraints:

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



exemplu de use case


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



Software Design Specification:
ipostazele jocului (sistemului) sunt prezentate via view‐uri
desemnate de diagrame UML ori de liste

requirements
conceptual
behavioral
logical
component



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



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

1. Introduction: purpose, scope, definitions & acronyms
2. References
3. Conceptual view: use case, diagram,…
4. Behavioral view: object diagrams
5. Logical view: class diagrams
6. Component view: diagrams
7. Deployment view


conceptual view – exemplificare


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


component view – exemplificare la nivel de stripe


Aspecte de considerat la redactarea documentului de design:



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



Șabloane comune ce pot fi aplicate la dezvoltarea de jocuri:
Singleton
Composite
Chain of Responsibility
State
Strategy
Observer
Façade
Memento
Command


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



Command pattern pentru implementarea comenzilor:



Proiectarea iterativă (iterative design)

uzual, are loc la nivel de fiecare stripe

de la stabilirea cerințelor la componente



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


Exemplu de proiectare vizuală a stripe‐ului Level Template



Exemplu de proiectare a personajelor



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

Don’t be too cute
Avoid “serious” violence
Keep it abstract, but not too abstract
Give rewards for progress

exemplu de succes: Lemmings



Componente (subsisteme) primare (Rollings & Morris, ‘04):
User interface
Bidirectional event handler
Data engine (graphics, level, miscellaneous data)
Dynamics system (collisions and general physics)
Logic engine (the heart of the game)
Graphics engine
Sound engine
Hardware abstraction layers
(interfaces with graphics, sound, and controller hardware)


Subsisteme secundare:
Game configuration system
Menuing system
Online instructions and help system
Music system



Criterii de reutilizare a componentelor/bibliotecilor existente:
disponibilitate
corectitudine
actualitate
utilizare imediată

mentenabilitate
licențiere
compatibilitate



Software engineering risk assessment

prevenirea, reducerea, managementul (controlul)
problemelor critice



Risc extern Risc intern
Probleme legale Timpul alocat dezvoltării jocului
(copyright, licentiere,…)
Prețul jocului Structura colectivelor
implicate în dezvoltare
Drepturi (royalties) acordate Gradul de inovare tehnică
dezvoltatorilor & altora
Costul punerii la dispoziția Gradul de creativitate artistică
consumatorului
Timp alocat marketing‐ului Tipul tehnologiilor implicate
Suportul organizațional Maniera de înțelegere a cerințelor
Atingerea stadiului de maturitate Metodologia de dezvoltare
dorit adoptata
Susținătorii proiectului Alte tipuri de risc


Aspecte de interes privind riscurile externe:
finanțarea
suportul la nivel de organizație
resursele disponibile – e.g., transport
suportul acordat clienților (customer support)
creativitatea – e.g., artiști grafici, suport muzical & vocal,…



Aspecte de interes privind riscurile interne:
echipamentele (logistica)
membrii echipelor de dezvoltatori
tehnologia – e.g., cea de ultimă oră
inspirația (creative input)
durata de dezvoltare a produsului



Depinde de scopuri
exemple tipice:
reduce lost productivity
increase productivity
increase opportunities for aesthetic expression
increase opportunities for technical innovation
create a safer environment for experimentation
reduce the number of errors the game has when it ships
add to the quality of the development experience


Paradigma clasică (Robert N. Charette, 1989)



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


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



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


Planificarea dezvoltării unui joc


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

strategy guide
oferă 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.



modelarea la nivel înalt a unor jocuri
crearea unui joc simplu de tip MMORPG
dezvoltarea unui joc sportiv de simulare pentru vârstnici


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



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



Token‐urile pot fi clasificate specificarea unei ierarhii

cazul Pong



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


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



modelarea comportamentului NPC‐urilor de tip ghost
la Pac‐Man


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


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



Un MMORPG este un sistem software informațional

starea jocului se stochează central (pe un server)
datele sunt persistente
accesul la date este concurent
utilizatorii posedă identități, trebuind să fie autentificați
interacțiunea se realizează la client via o interfață‐utilizator



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



99 100

Y, 1 to 10
11 12 13 14 15 16 17 18 19 20
1 2 3 4 5 6 7 8 9 10

X, 1 to 10


Folosind o imagine de fundal, poate fi realizat designul vizual



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ționa
cu alți jucători



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


modelarea datelor via tabele


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



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)


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'
END
ELSE
SELECT 0 As 'Success'



Fiecare acțiune a unui jucător afectează vizualizarea datelor
de 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


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 tables
to 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


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


1. Ethnographic
Observations 5. Evaluation

2. Participatory 4. Development
Design

3. Presentation of Concepts


Specificarea caracteristicilor jocului:
sports‐simulation
2 players
intuitive, consistent controls
not competitive, but “feel good”
practice and play modes
visual and auditory explanations
compose a team of unique characters with individual skills
consistent 2D and 3D, with matching sound



Instrument de dezvoltare: Virtools (Dassault Systems)



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


Stadiul actual al industriei jocurilor (Rollings & Morris)


Posibil model viitor (Rollings & Morris)


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

social game computing



game computing
aspecte privind ingineria dezvoltării de jocuri

Game computing: inginerie

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (8)

Similaire à Game computing: inginerie

Similaire à Game computing: inginerie (18)

Plus de Sabin Buraga

Plus de Sabin Buraga (20)

Game computing: inginerie