Evaluating Processing as a Platform for Game Prototyping

1. Evaluating Processing as a Platform for Game Prototyping Daniel Volk 28.03.2011

2. Agenda •  Part I – Game Prototyping •  What is a Game? •  Why Game Prototyping? •  Part II – Processing •  What is Processing? •  How to use Processing? •  Part III – Game Prototype •  An Example

3. Part I – Game Prototyping •  What is Play? •  [Play is] ... „a free ac8vity standing quite consciously outside „ordinary“ life as being „not serious“, but at the same Lme absorbing the player intensely and uMerly. •  It is an acLvity connected with no material interest, and no profit can be gained by it. It proceeds within its own proper boundaries of 8me and space according to fixed rules and in an orderly manner.“ [Johan Huizinga] •  The Magic Circle •  Game Space •  Game Time ( ) ... primarily true for games ... the real world the ficLonal game world

4. Part I – Game Prototyping •  What is Play? •  Play is free – would otherwise loose quality as diversion •  Play is separate – described by limits of space and Lme •  Play is uncertain – course and results are not known beforehand •  Play is unproduc8ve – creates no wealth or goods •  Play is governed by rules – a new legislaLon is established •  Play is make-‐believe – it creates a reality, diﬀerent of real life •  Components of play •  Agon (≈ compe88on) •  Alea (≈ chance) •  Illinx (≈ frenzy) •  Mimikry (≈ masquerade) [Roger Caillois]

5. Part I – Game Prototyping •  What is a Game? •  Games can be the origin of play. •  „Reduced to its formal essence, a game is an ac8vity among two or more independent decision-‐makers seeking to achieve their objec8ves in some limi8ng context. A more convenLonal deﬁniLon would say that a game is a context with rules among adversaries trying to win objecLves.“ [Clark C. Abt] •  „A game is a form of art in which parLcipants, termed players, make decisions in order to manage resources through game tokens in pursuit of a goal.“ [Greg CosLkyan]

6. Part I – Game Prototyping •  What is a Game? •  „Games are rule-‐based“ •  „Games have variying endings, with different numbers assignable to a specific outcome“ •  „The different potenLal outcomes of the games are assigned different values, some posiLve and some negaLv“ •  „The player exerts effort in order to influence the outcome“ •  „The player is emo8onally aLached to the outcome of the game“ •  „The same game (≈ rules) can be played with or without real-‐ world consequences“ [Jesper Juul]

7. Part I – Game Prototyping player(s) game token(s) game space game 8me game rules ac8vity game goals compe88on decisions 1:0 outcome challenge aLachment consequences

8. Part I – Game Prototyping •  Game Rules •  DifferenLaLon •  (Game)world rules •  Rules define the boundaries and behaviour of the world containing the player (or his avatar) – the infrastructure upon which the game exists •  Non-‐digital gameworld rules are typically defined by the specs of the real world, digital games need to be defined at first •  Example (non-‐digital): the level of gravity in a soccer game (g = 9.81 m/s2) •  Example (digital): the types of interacLons possible within the gameworld •  Gameplay rules •  Rules define the possibility space seman8cally relevant for the game •  Example (non-‐digital): a ball that crosses the goal line increases the score •  Example (digital): the number of lives a jump‘n‘run character has ... also generic mulLverses like SecondLife implement this category of „game“ rules

9. Part I – Game Prototyping •  Game Rules •  Basics •  Game rules give games structure •  Game rules need to be unambiguous and repeatable •  Game rules need to be fixed and binding •  Game rules need to be balanced •  Understandings •  Game rules are limita8ons •  Rules define obstacles that impose challenges to the player •  Example: a field player in soccer is not allowed to use his hands •  Game rules are opportuni8es •  Rules define possible ac8ons that offer choices to the player •  Example: you can try to provoke the opposing player using his hands ... e.g. sensorimotor challenges in soccer (which are especially interesLng, since conflict is involved)

10. Part I – Game Prototyping •  Game Rules •  Levels •  Opera8onal rules •  Are visible on the surface (e.g. in form of a rule-‐set) •  Are procedurally formalized by instruc8ons/constraints •  Are more precise (specific for one game) •  Cons8tua8ve rules •  Lie hidden underneath the surface •  Are descrip8vely formalized by a finite state machine •  Are more abstract (specific for a class of games) •  Implicit rules •  Are surrounding rules that are defined by the player community •  Are typically unwriLen and ojen conveyed outside the game

11. Part I – Game Prototyping •  Game Rules •  General approaches •  Games of Emergence •  The gameplay challenges emerge in parallel from a set of simple (ﬁrst-‐ order), interacLng rules (which generates a wide decision tree) •  Is typically build around a strong simulaLve core •  Games of Progression •  Gameplay challenges are constructed serially, by way of special case (second-‐order) rules (which generates a narrow decision tree) •  Is typically build upon a strong narraLve backbone •  Gameplay •  The player is challenged by obstacles while working towards the goals (and their rewards); to overcome the obstacles he makes choices about the right acLons, interacts with the game accordingly and in doing so he unfolds the gameplay ...follows the principle of „easy to learn, diﬃcult to master“

12. Part I – Game Prototyping •  What is a Videogame? •  „A videogame is a game which we play thanks to an audiovisual apparatus and which can be based on a story“ [Nicolas Esposito] ( ) ... although true for classic games ... a ﬁcLonal virtual world the ﬁcLonal game world the Magic Circle Remember the (Game)world rules? Remember the Gameplay rules? the real world can be an abstracLon of

13. Part I – Game Prototyping •  Interac8vity •  „Just as the schwerpunkt of computers is processing, so too the schwerpunkt of all sojware is interac8vity – and this goes double for games.“ •  InteracLvity is „a cyclic process in which two ac8ve agents alternaLvely (and metaphorically) listen, think, and speak.“ [Chris Crawford] Think Think Speak Speak Listen Listen Human-‐Computer-‐ Interac8on barrier ...is a higher-‐level concept compared to interac8on!

14. Part I – Game Prototyping •  High interac8vity •  High-‐quality listening •  How wide is the range of (inter)ac8on op8ons offered to the player? •  High-‐quality thinking •  How complex is the set of algorithms (process intensity) executed by the game in response to the players input? •  High-‐quality speaking •  How strong is the expressiveness (the more sophisLcated the answer, the beMer – representaLon is secondary) of the game‘s reacLon? •  Core Game Mechanic •  Every game is designed around a main ac8vity (cf. „Jump‘n‘Run“) •  This acLvity is very sensi8ve to interac8on deficiencies •  It primarily defines the level of interac8vity ...in a way similar to the concept of entropy (cf. informaLon theory)

15. Part I – Game Prototyping •  Reasons for prototyping •  Game rules are best defined using boLom-‐up strategies (quite ojen interesLng features are discovered just on the fly) •  The same holds true for game interac8vity (direct result of rules) •  This is especially true for games of emergence (restricLng to first-‐ order rules means provoking second-‐order design challenges) •  Game balance is best achieved by playing and refining the game •  The same holds true for game interac8on (fine-‐tuning using a running prototype is especially important for core mechanics) •  This all assumes creaLng a playable prototype fastest possible

16. Part I – Game Prototyping •  A model for itera8ve game development •  Phases •  Concept •  Goal: generate ideas •  Tool: gameplay sketching •  Pre-‐Produc8on •  Goal: concreLze ideas •  Tool: gameplay prototyping •  Produc8on •  Goal: implement/reﬁne ideas •  Tool: evoluLonary development •  QA •  Goal: evaluate/ reﬁne ideas •  Tool: evoluLonary development •  Origin •  USC InteracLve Media Division (2003) [Tracy Fullerton]

17. Part I – Game Prototyping •  The spiral model of soXware development [Barry Boehm] Exchange width by depth •  Reduce design opLons •  Increase prototype scope

18. Part I – Game Prototyping •  Prototype categories (contentual disLncLon) •  Game design focus •  The prototype is built around a game design issue •  Technology focus •  The prototype is build around a technical issue •  Prototype categories (goal disLncLon) •  Generate ideas (sketching) •  A sketch is used to explore the design space, rise ques8ons about various opLons and propose specific selecLons •  ConcreLze/ Refine ideas (prototyping) •  A prototype is used to refine a concrete design choice, answer quesLons that arose while trying out opLons and test selecLons that have been made

19. Part I – Game Prototyping •  Prototype categories (structural disLncLon) •  Horizontal prototype •  Realizes just specific levels of the system desired and concentrates on singular aspects that need evaluaLon (e.g. the GUI) •  VerLcal prototype •  Realizes a properly func8onal itera8on of the system desired that cuts through all levels of the system but limits funcLonality considerably (e.g. the first game level) •  Prototype categories (life cycle disLncLon) •  Throw-‐away prototype •  The prototype is just built to demonstrate a specific aspect or to answer a concrete ques8on that arose while development •  Pilot system •  The prototype represents a preliminary version of the aspired product and is base for further development iteraLons

20. Part I – Game Prototyping •  Technical Requirements •  A good prototyping environment •  facilitates a shallow learning curve •  allows for fast itera8ons •  provides verLcal scalability (at least to a certain degree) •  This is typically accomplished, if the environment •  sets the right focus (animaLon/ simulaLon/ media) •  contains examples and snippets •  provides reusable components •  oﬀers a supporLng framework •  Is sourrounded by helpful tools

22. Part II – Processing „Processing is an open source programming language and environment for people who want to create images, anima8ons, and interac8ons“ [www.processing.org]

23. Part II – Processing •  Some examples...

24. Part II – Processing •  The Programming Language •  Built on top of Java •  Is strictly typed •  Has classes and inheritance •  The mandatory Hello World example: •  println("Hello World!"); •  Supports three modes of programming •  Basic (just one method body) •  Con8nuous (setup() and looped draw() as core) •  Java (well, it‘s just naLve Java... J) •  Can be exported (compiled) to diﬀerent languages!

25. Part II – Processing •  The Programming Environment •  Processing Development Environment (PDE) is bundled (Pro-‐users can also replace it by Eclipse) •  Provides basic funcLonality and is easy to use •  Contains examples and snippets •  Exports Applets and applicaLons •  Contains a basic set of supporLng tools •  Can be extended by external tools (provides an extension mechanism)

26. Part II – Processing •  The Programming Interface •  Is focused on Data Visualiza8on •  Can do 2D and 3D (both can be done HW-‐accelerated!) •  Contains a bunch of globally-‐accessible funcLons for doing standard work (very ﬂat API) •  The real Hello World example: •  textFont(loadFont("Dialog-16.vlw"), 16); •  text("Hello World!", 10, 20); •  Some addiLonal libraries included (Audio, Video, Network, ...) •  Lots of external libraries available (Hardware, SimulaLon, ...) (provides an extension interface)

27. Part II – Processing •  Program and Control Structures •  The same as in Java •  Data Types •  Nearly the same as in Java (e.g., color, ...) •  AddiLonal helper methods for handling (e.g., Strings, Arrays, ...) •  Math •  Operators are the same as in Java •  Methods for CalculaLon (ceil(), dist(), constrain(), norm(), ...) •  Methods for Trigonometry (sin(), cos(), degrees(), radians(), ...) •  Methods for Random Sampling (random(), noise(), ...) •  PVector as datatype for two-‐ or three-‐dimensional vectors

28. Part II – Processing •  Input •  Mouse (e.g., mousePressed(), mouseReleased(), ...) •  Keyboard (e.g., keyPressed(), keyReleased(), ...) •  File (e.g., loadBytes(), loadString(), ...) •  Output •  Text/ Image (e.g., println(), saveFrame(), ...) •  File (e.g., saveStream(), saveBytes(), saveString(), ...) •  Environmental Control •  Controls for seqngs (e.g., size(), cursor(), pushStyle(), ...) •  Controls for main loop (e.g., frameRate(), noLoop(), redraw(), ...)

29. Part II – Processing •  Basic 2D Drawing •  2D PrimiLves (e.g., point(), line(), ellipse(), rect(), ...) •  Curves (e.g., arc(), curve(), bezier(), ...) •  AMributes (e.g., ﬁll(), stroke(), smooth(), color(), ...) •  PShape as datatype for handling SVG shapes •  Basic 3D Drawing •  3D PrimiLves (e.g., sphere(), box(), ...) •  Lights (e.g., ambientLight(), pointLight(), spotLight(), ...) •  Materials (e.g., ambient(), emissive(), shininess(), specular(), ...) •  Camera (e.g., camera(), frustum(), ortho(), ...)

30. Part II – Processing •  Advanced 2D/ 3D Drawing •  Vertex Handling (e.g., beginShape(), vertex(), texture(), ...) •  TransformaLons (e.g., pushMatrix(), translate(), rotate(), ...) •  Images •  Handling (e.g., image(), imageMode(), Lnt(), ...) •  Pixel Handling (e.g., loadPixels(), ﬁlter(), blend(), ...) •  PImage as datatype for handling GIF, JPG, TGA and PNG images •  PGraphics as datatype for the main rendering context •  Typography •  Handling (e.g., loadFont(), textFont(), text(), ...) •  AMributes (e.g., textMode(), textSize(), textAlign(), ...) •  PFont as datatype for pixel-‐based VLW fonts

32. Part III – Game Prototype •  Core Game Mechanics •  Avoid geqng hit by incoming objects •  TaMer objects by using effector •  Opera8onal Rules •  Avatar health is restricted (obstacle) •  Different objects with different behaviour (choice) •  Effectors are restricted in some way (obstacle/ choice) •  Different effectors are available (choice) •  Movement of avatar is restricted to screen (obstacle) •  Player tries to survive as long as possible (main goal) •  Player tries to survive certain amount of Lme (intermediate goal); is then offered new effector opLons (reward) •  Interac8on •  Player controls avatar by keyboard-‐mouse-‐combinaLon (→ game Lme) (→ game space) (→ game category)

33. Part III – Game Prototype •  Prototype I – „Birth of an avatar“ •  Type: •  Horizontal throw-‐away (technology) •  Focus: •  InteracLon with player avatar •  Goals: •  Show simple avatar representaLon •  Move avatar using keyboard (a,w,s,d)-‐keys •  Evalua8on •  OK: •  Indirect steering works beMer •  Playing with inerLa feels good -‐> use acceleraLon/ space theme? •  NOK: •  Movement needs to be restricted to screen •  Velocity needs to be restricted to reasonable limit •  MulLple-‐key movement doesn‘t work properly yet

34. Part III – Game Prototype •  Prototype II – „Aiming at bad objects“ •  Type: •  Horizontal throw-‐away (technology) •  Focus: •  InteracLon with player avatar •  Goals: •  Show simple avatar and eﬀector representaLon •  Aim eﬀector using mouse •  Evalua8on •  OK: •  Approach will do •  Using translaLons works well •  NOK: •  Loosing mouse focus interrupts experience •  Crosshairs mouse cursor would improve game feeling

35. Part III – Game Prototype •  Prototype III – „Ready for take oﬀ“ •  Type: •  Horizontal pilot (technology) •  Focus: •  InteracLon with player avatar •  Goals: •  Combine Prototype I and II •  Remedy current NOKs/ Do simple code refactorings •  Evalua8on •  OK: •  Approach will do •  Movement restricLon should be part of gameplay •  NOK: •  Loosing mouse focus interrupts experience

36. Part III – Game Prototype •  Prototype IV – „Emissions all around“ •  Type: •  Horizontal throw-‐away (technology) •  Focus: •  InteracLon with player avatar •  Goals: •  Show representaLon of eﬀector emissions •  Provide basic emission behavior •  Launch emissions using mouse •  Evalua8on •  OK: •  Approach will do •  NOK: •  Emissions discharge it too staLc (add random factor) •  Emissions lifeLme is too staLc (add random factor)

37. Part III – Game Prototype •  Prototype V – „Avatar, trigger-‐happy“ •  Type: •  Horizontal pilot (technology) •  Focus: •  InteracLon with player avatar •  Goals: •  Combine Prototype III and IV •  Remedy current NOKs/ Do simple code refactorings •  Evalua8on •  OK: •  Approach will do •  Implemented emiMer might work best as short distance type •  NOK: •  Emission rate shouldn‘t depend on framerate •  Emission should be restricted to lej mouse buMon

38. Part III – Game Prototype •  Prototype VI – „Bad objects on the move“ •  Type: •  Horizontal throw-‐away (technology) •  Focus: •  InteracLon with game objects •  Goals: •  Show representaLon of bad objects •  Provide basic bad-‐object behavior (hunLng mouse) •  Evalua8on •  OK: •  Approach will do •  NOK: •  IniLal direcLon of bad objects has to be set •  Bad Objects need to be diﬀerent -‐> classes of objects?

39. Part III – Game Prototype •  Prototype VII – „The (make believe) witch hunt“ •  Type: •  VerLcal pilot (game design/ technology) •  Focus: •  InteracLon with player avatar/ InteracLon with game objects •  Goals: •  Combine Prototype V and VI •  Remedy current NOKs/ Do simple code refactorings •  Colorize game world •  Evalua8on •  OK: •  Approach will do •  NOK: •  Swarm-‐behavior is too predictable yet •  Annoying ﬂickering -‐> double buﬀering enabled? •  Input-‐handling should be centralized

40. Part III – Game Prototype •  Prototype VIII – „Hit ´em“ •  Type: •  Horizontal throw-‐away (technology) •  Focus: •  InteracLon with game objects •  Goals: •  Provide basic object-‐to-‐object collision-‐detecLon •  Provide simple collision-‐handling •  Evalua8on •  OK: •  Approach will do •  NOK: •  Number of collision checks probably need to be restricted •  Style of collision-‐handling needs to be improved

41. Part III – Game Prototype •  Prototype IX – „The (serious) witch hunt “ •  Type: •  VerLcal pilot (game design/ technology) •  Focus: •  InteracLon with player avatar/ InteracLon with game objects •  Goals: •  Combine Prototype VII and VIII •  Remedy current NOKs/ Do simple code refactorings •  Add simple gameplay behavior •  Evalua8on •  OK: •  Approach will do •  NOK: •  Add visual feedback when hiqng bad objects •  Add player health and points

42. Part III – Game Prototype •  Prototype X – „A delicate liMle gameplay plant“ •  Type: •  VerLcal pilot (game design) •  Focus: •  Gameplay Improvements •  Goals: •  Remedy current NOKs/ Do simple code refactorings •  Enrich gameplay behavior/ Add game states •  Evalua8on •  OK: •  Approach will do •  NOK: •  Add audio component to the game •  Add diﬀerent bad object types

43. Part I – Game Prototyping •  Technical Evalua8on •  A good prototyping environment •  facilitates a shallow learning curve •  allows for fast itera8ons •  provides verLcal scalability (at least to a certain degree) •  This is typically accomplished, if the environment •  sets the right focus (animaLon/ simulaLon/ media) •  contains examples and snippets •  provides reusable components •  oﬀers a supporLng framework •  Is sourrounded by helpful tools

Evaluating Processing as a Platform for Game Prototyping

Du liest eine Vorschau.

Hier ansehen

Evaluating Processing as a Platform for Game Prototyping

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie Evaluating Processing as a Platform for Game Prototyping (20)

Weitere von Daniel Volk (12)

Aktuellste (20)