No Show 2012 - Heather Decker-Davis and Luke Dicken - Procedural Processes
•Als KEY, PDF herunterladen•
1 gefällt mir•482 views
Creating the number of levels that players are coming to expect from casual games can be a daunting task for small teams – especially when you factor in replayability and difficulty progression. In this session, Luke Dicken and Heather Decker-Davis detail the process of developing “Easy Money?”, a casual game that relies on procedural level generation. The goal of the session is to showcase some techniques that have been learnt across the whole development process. Not only will the mechanics of Artificial Intelligence system driving the generation of fun and engaging levels be explored, but also how using this approach impacted both the design decisions of the project, as well as the artistic direction. The experiences related in the session should enable teams to apply similar methodologies in their own projects and have greater success wrangling this increasingly necessary topic, which can otherwise be fraught with peril. In this session, attendees can expect to learn about the ways that implementing procedural content generation can affect your overall workflow, your approaches to early implementation and prototyping and importantly the manner in which you iterate your designs. Although all of this will be presented in the context of the development of “Easy Money?”, the lessons imparted are intended to be generally applicable.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (14)
Ähnlich wie No Show 2012 - Heather Decker-Davis and Luke Dicken - Procedural Processes
Ähnlich wie No Show 2012 - Heather Decker-Davis and Luke Dicken - Procedural Processes (20)
Mehr von No Show Conference
Mehr von No Show Conference (11)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
No Show 2012 - Heather Decker-Davis and Luke Dicken - Procedural Processes
- 1. Procedural Processes Lessons Learnt From Automated Content Generation in “Easy Money”? Luke Dicken and Heather Decker-Davis @LukeD @HeatherMDecker
- 10. Easy Money? Demo
- 11. Easy Money? Demo
- 13. Why Generate Procedurally? • Players expect lots of content in games
- 14. Why Generate Procedurally? • Players expect lots of content in games
- 15. Why Generate Procedurally? • Players expect lots of content in games • Players memorize static levels
- 16. Why Generate Procedurally? • Players expect lots of content in games • Players memorize static levels • Disinterested in replaying the same content
- 17. Why Generate Procedurally? • Players expect lots of content in games • Players memorize static levels • Disinterested in replaying the same content
- 18. Why Generate Procedurally? • Players expect lots of content in games • Players memorize static levels • Disinterested in replaying the same content • PCG can keep it fresh. Imagine Temple Run with a fixed level layout
- 19. Why Generate Procedurally? • Players expect lots of content in games • Players memorize static levels • Disinterested in replaying the same content • PCG can keep it fresh. Imagine Temple Run with a fixed level layout
- 20. Why Generate Procedurally? • Players expect lots of content in games • Players memorize static levels • Disinterested in replaying the same content • PCG can keep it fresh. Imagine Temple Run with a fixed level layout
- 21. Why Generate Procedurally? • Players expect lots of content in games • Players memorize static levels • Disinterested in replaying the same content • PCG can keep it fresh. Imagine Temple Run with a fixed level layout • Easier to store an algorithm than a set of assets
- 22. Procedural Generation in EM
- 23. Procedural Generation in EM • An ample set of levels was needed, and PCG could help us achieve this
- 24. Procedural Generation in EM • An ample set of levels was needed, and PCG could help us achieve this • Mazes are generated semi-randomly
- 25. Procedural Generation in EM • An ample set of levels was needed, and PCG could help us achieve this • Mazes are generated semi-randomly
- 26. Procedural Generation in EM • An ample set of levels was needed, and PCG could help us achieve this • Mazes are generated semi-randomly
- 27. Procedural Generation in EM • An ample set of levels was needed, and PCG could help us achieve this • Mazes are generated semi-randomly • Items are deployed semi-randomly
- 28. Procedural Generation in EM • An ample set of levels was needed, and PCG could help us achieve this • Mazes are generated semi-randomly • Items are deployed semi-randomly
- 29. Procedural Generation in EM • An ample set of levels was needed, and PCG could help us achieve this • Mazes are generated semi-randomly • Items are deployed semi-randomly
- 30. Procedural Generation in EM • An ample set of levels was needed, and PCG could help us achieve this • Mazes are generated semi-randomly • Items are deployed semi-randomly • Today, we want to talk about how everything comes together and how PCG impacted our workflow and results
- 32. Developing Procedurally • Setting up conditions for a potential range of envisioned player experiences, rather than crafting highly specific settings
- 33. Developing Procedurally • Setting up conditions for a potential range of envisioned player experiences, rather than crafting highly specific settings • Static vs. Procedural levels
- 34. Developing Procedurally • Setting up conditions for a potential range of envisioned player experiences, rather than crafting highly specific settings • Static vs. Procedural levels
- 35. Developing Procedurally • Setting up conditions for a potential range of envisioned player experiences, rather than crafting highly specific settings • Static vs. Procedural levels
- 36. Developing Procedurally • Setting up conditions for a potential range of envisioned player experiences, rather than crafting highly specific settings • Static vs. Procedural levels • Developers used to working strictly with static content models may need to shift their mindset
- 38. Designing Procedurally • Designing interactions for a space that does not yet exist
- 39. Designing Procedurally • Designing interactions for a space that does not yet exist • Spatial challenges and the realm of possible results
- 40. Designing Procedurally • Designing interactions for a space that does not yet exist • Spatial challenges and the realm of possible results • Be aware of potential unplayable situations
- 41. Designing Procedurally • Designing interactions for a space that does not yet exist • Spatial challenges and the realm of possible results • Be aware of potential unplayable situations
- 42. Designing Procedurally • Designing interactions for a space that does not yet exist • Spatial challenges and the realm of possible results • Be aware of potential unplayable situations
- 43. Designing Procedurally • Designing interactions for a space that does not yet exist • Spatial challenges and the realm of possible results • Be aware of potential unplayable situations • Prototype your mechanics first
- 44. Designing Procedurally • Designing interactions for a space that does not yet exist • Spatial challenges and the realm of possible results • Be aware of potential unplayable situations • Prototype your mechanics first
- 45. Designing Procedurally • Designing interactions for a space that does not yet exist • Spatial challenges and the realm of possible results • Be aware of potential unplayable situations • Prototype your mechanics first
- 46. Designing Procedurally • Designing interactions for a space that does not yet exist • Spatial challenges and the realm of possible results • Be aware of potential unplayable situations • Prototype your mechanics first • System-oriented or formulaic progression
- 47. Designing Procedurally • Designing interactions for a space that does not yet exist • Spatial challenges and the realm of possible results • Be aware of potential unplayable situations • Prototype your mechanics first • System-oriented or formulaic progression • as always, refine with testing
- 48. Designing Procedurally • Designing interactions for a space that does not yet exist • Spatial challenges and the realm of possible results • Be aware of potential unplayable situations • Prototype your mechanics first • System-oriented or formulaic progression • as always, refine with testing • Choose variables that follow your design goals and uphold a sense of fairness
- 50. Designing Procedurally • Test extremes of variables to find your target start and final level values
- 51. Designing Procedurally • Test extremes of variables to find your target start and final level values • Then build a formula to fill in between point A and point B
- 52. Designing Procedurally • Test extremes of variables to find your target start and final level values • Then build a formula to fill in between point A and point B • Linear equations are a good starting point
- 53. Designing Procedurally • Test extremes of variables to find your target start and final level values • Then build a formula to fill in between point A and point B • Linear equations are a good starting point
- 54. Designing Procedurally • Test extremes of variables to find your target start and final level values • Then build a formula to fill in between point A and point B • Linear equations are a good starting point
- 55. Designing Procedurally • Test extremes of variables to find your target start and final level values • Then build a formula to fill in between point A and point B • Linear equations are a good starting point • Simple linear progression can be tweaked
- 56. Designing Procedurally • Test extremes of variables to find your target start and final level values • Then build a formula to fill in between point A and point B • Linear equations are a good starting point • Simple linear progression can be tweaked • For a distinct endgame feel, for example
- 57. Designing Procedurally • Test extremes of variables to find your target start and final level values • Then build a formula to fill in between point A and point B • Linear equations are a good starting point • Simple linear progression can be tweaked • For a distinct endgame feel, for example
- 58. Designing Procedurally • Test extremes of variables to find your target start and final level values • Then build a formula to fill in between point A and point B • Linear equations are a good starting point • Simple linear progression can be tweaked • For a distinct endgame feel, for example
- 59. Asset Creation
- 60. Asset Creation • Involve artists early so they can experiment with the specific PCG system
- 61. Asset Creation • Involve artists early so they can experiment with the specific PCG system • Artists must think modularly and consider possible ways an asset may be positioned
- 62. Asset Creation • Involve artists early so they can experiment with the specific PCG system • Artists must think modularly and consider possible ways an asset may be positioned • Several possible approaches
- 63. Asset Creation • Involve artists early so they can experiment with the specific PCG system • Artists must think modularly and consider possible ways an asset may be positioned • Several possible approaches • theme packages
- 64. Asset Creation • Involve artists early so they can experiment with the specific PCG system • Artists must think modularly and consider possible ways an asset may be positioned • Several possible approaches • theme packages • color shifting
- 65. Asset Creation • Involve artists early so they can experiment with the specific PCG system • Artists must think modularly and consider possible ways an asset may be positioned • Several possible approaches • theme packages • color shifting • procedural texture
- 66. Asset Creation • Involve artists early so they can experiment with the specific PCG system • Artists must think modularly and consider possible ways an asset may be positioned • Several possible approaches • theme packages • color shifting • procedural texture
- 67. Asset Creation
- 68. Asset Creation • The art style in Easy Money? embraced the level structure while following the desired aesthetic
- 69. Asset Creation • The art style in Easy Money? embraced the level structure while following the desired aesthetic
- 70. Asset Creation • The art style in Easy Money? embraced the level structure while following the desired aesthetic
- 71. Asset Creation • The art style in Easy Money? embraced the level structure while following the desired aesthetic
- 72. Asset Creation • The art style in Easy Money? embraced the level structure while following the desired aesthetic • Testing and prototyping art was helped in nailing down specifics methodology for asset construction
- 73. Prototyping
- 74. Prototyping • Once general level characteristics were defined, 2D tiles were created
- 75. Prototyping • Once general level characteristics were defined, 2D tiles were created
- 76. Prototyping • Once general level characteristics were defined, 2D tiles were created • This allowed us to refine both the generation system and the piece set
- 77. Prototyping • Once general level characteristics were defined, 2D tiles were created • This allowed us to refine both the generation system and the piece set • Easily iterate with little asset commitment
- 78. Prototyping • Once general level characteristics were defined, 2D tiles were created • This allowed us to refine both the generation system and the piece set • Easily iterate with little asset commitment • Prototyping stages
- 79. Prototyping • Once general level characteristics were defined, 2D tiles were created • This allowed us to refine both the generation system and the piece set • Easily iterate with little asset commitment • Prototyping stages • 2D representation
- 80. Prototyping • Once general level characteristics were defined, 2D tiles were created • This allowed us to refine both the generation system and the piece set • Easily iterate with little asset commitment • Prototyping stages • 2D representation • 3D explorable levels
- 81. Prototyping • Once general level characteristics were defined, 2D tiles were created • This allowed us to refine both the generation system and the piece set • Easily iterate with little asset commitment • Prototyping stages • 2D representation • 3D explorable levels • Adding the funds
- 82. Prototyping • Once general level characteristics were defined, 2D tiles were created • This allowed us to refine both the generation system and the piece set • Easily iterate with little asset commitment • Prototyping stages • 2D representation • 3D explorable levels • Adding the funds • Incorporating hazards
- 83. The Art Pipeline
- 84. The Art Pipeline • 2D tiles formed the blueprint for 3D pieces
- 85. The Art Pipeline • 2D tiles formed the blueprint for 3D pieces
- 86. The Art Pipeline • 2D tiles formed the blueprint for 3D pieces • Precise construction ensured each piece would snap together properly on the grid
- 87. The Art Pipeline • 2D tiles formed the blueprint for 3D pieces • Precise construction ensured each piece would snap together properly on the grid • Pieces unwrapped, textured individually, then tested in-game
- 88. The Art Pipeline • 2D tiles formed the blueprint for 3D pieces • Precise construction ensured each piece would snap together properly on the grid • Pieces unwrapped, textured individually, then tested in-game • To minimize draw calls, pack as much into a single texture sheet as possible
- 89. The Art Pipeline • 2D tiles formed the blueprint for 3D pieces • Precise construction ensured each piece would snap together properly on the grid • Pieces unwrapped, textured individually, then tested in-game • To minimize draw calls, pack as much into a single texture sheet as possible
- 90. The Art Pipeline • 2D tiles formed the blueprint for 3D pieces • Precise construction ensured each piece would snap together properly on the grid • Pieces unwrapped, textured individually, then tested in-game • To minimize draw calls, pack as much into a single texture sheet as possible
- 91. The Art Pipeline • 2D tiles formed the blueprint for 3D pieces • Precise construction ensured each piece would snap together properly on the grid • Pieces unwrapped, textured individually, then tested in-game • To minimize draw calls, pack as much into a single texture sheet as possible • Maximized reusability of pixel space for shared components
- 93. Simple Maze Creation • Creating mazes isn't overly hard
- 94. Simple Maze Creation • Creating mazes isn't overly hard • Just placing appropriate pieces into the world where there is a “road to nowhere”
- 95. Simple Maze Creation • Creating mazes isn't overly hard • Just placing appropriate pieces into the world where there is a “road to nowhere” • Very efficient approach
- 96. Simple Maze Creation • Creating mazes isn't overly hard • Just placing appropriate pieces into the world where there is a “road to nowhere” • Very efficient approach
- 97. Simple Maze Creation • Creating mazes isn't overly hard • Just placing appropriate pieces into the world where there is a “road to nowhere” • Very efficient approach
- 98. Simple Maze Creation • Creating mazes isn't overly hard • Just placing appropriate pieces into the world where there is a “road to nowhere” • Very efficient approach
- 99. Simple Maze Creation • Creating mazes isn't overly hard • Just placing appropriate pieces into the world where there is a “road to nowhere” • Very efficient approach
- 137. Maze Verification
- 138. Maze Verification • We use some simple checks to validate the mazes produced are interesting
- 139. Maze Verification • We use some simple checks to validate the mazes produced are interesting • Number of dead-ends placed in the maze
- 140. Maze Verification • We use some simple checks to validate the mazes produced are interesting • Number of dead-ends placed in the maze • Straight-line Distance from start to end
- 141. Maze Verification • We use some simple checks to validate the mazes produced are interesting • Number of dead-ends placed in the maze • Straight-line Distance from start to end • Number of pieces that have been placed
- 142. Maze Verification • We use some simple checks to validate the mazes produced are interesting • Number of dead-ends placed in the maze • Straight-line Distance from start to end • Number of pieces that have been placed • If any of these checks fail, the maze is rejected and a new one generated
- 143. Post-hoc Verification vs Guided Generation
- 144. Post-hoc Verification vs Guided Generation • Verification is a very simple process
- 145. Post-hoc Verification vs Guided Generation • Verification is a very simple process • Guiding generation is way more complex
- 146. Post-hoc Verification vs Guided Generation • Verification is a very simple process • Guiding generation is way more complex • Do we solve the simple problem multiple times, or the complex problem once
- 147. Post-hoc Verification vs Guided Generation • Verification is a very simple process • Guiding generation is way more complex • Do we solve the simple problem multiple times, or the complex problem once • Your mileage may vary
- 148. Analytics
- 149. Analytics • Working out what the player is doing in your game is majorly important
- 150. Analytics • Working out what the player is doing in your game is majorly important
- 151. Analytics • Working out what the player is doing in your game is majorly important
- 152. Analytics • Working out what the player is doing in your game is majorly important • You need to pay attention and dig into the data to discover what’s actually going on
- 153. Analytics • Working out what the player is doing in your game is majorly important • You need to pay attention and dig into the data to discover what’s actually going on
- 154. Analytics • Working out what the player is doing in your game is majorly important • You need to pay attention and dig into the data to discover what’s actually going on
- 155. Analytics • Working out what the player is doing in your game is majorly important • You need to pay attention and dig into the data to discover what’s actually going on
- 156. Analytics • Working out what the player is doing in your game is majorly important • You need to pay attention and dig into the data to discover what’s actually going on
- 157. Analytics • Working out what the player is doing in your game is majorly important • You need to pay attention and dig into the data to discover what’s actually going on
- 158. Analytics • Working out what the player is doing in your game is majorly important • You need to pay attention and dig into the data to discover what’s actually going on
- 159. Export and Replay of Content
- 160. Export and Replay of Content • Analysis needs context
- 161. Export and Replay of Content • Analysis needs context • We need to have the ability to export configurations of levels
- 162. Export and Replay of Content • Analysis needs context • We need to have the ability to export configurations of levels • Also need to be able to bypass PCG system to load up a specific maze
- 164. Procedural Difficulty • We have parameters that we're using:
- 165. Procedural Difficulty • We have parameters that we're using: • for generation, for verification, for ingame properties
- 166. Procedural Difficulty • We have parameters that we're using: • for generation, for verification, for ingame properties • So it isn't hard to see that if we start manipulating these parameters we can start varying the difficulty
- 167. Procedural Difficulty • We have parameters that we're using: • for generation, for verification, for ingame properties • So it isn't hard to see that if we start manipulating these parameters we can start varying the difficulty • As the game progresses, we can control the tone of the spaces being created
- 168. Procedural Difficulty • We have parameters that we're using: • for generation, for verification, for ingame properties • So it isn't hard to see that if we start manipulating these parameters we can start varying the difficulty • As the game progresses, we can control the tone of the spaces being created
- 169. Procedural Difficulty • We have parameters that we're using: • for generation, for verification, for ingame properties • So it isn't hard to see that if we start manipulating these parameters we can start varying the difficulty • As the game progresses, we can control the tone of the spaces being created
- 170. Procedural Difficulty • We have parameters that we're using: • for generation, for verification, for ingame properties • So it isn't hard to see that if we start manipulating these parameters we can start varying the difficulty • As the game progresses, we can control the tone of the spaces being created
- 171. Procedural Difficulty • We have parameters that we're using: • for generation, for verification, for ingame properties • So it isn't hard to see that if we start manipulating these parameters we can start varying the difficulty • As the game progresses, we can control the tone of the spaces being created
- 172. Player Modelling
- 173. Player Modelling • We can look at how the player is playing the game and what they are choosing to spend time on
- 174. Player Modelling • We can look at how the player is playing the game and what they are choosing to spend time on • Then tailor the game to these tastes:
- 175. Player Modelling • We can look at how the player is playing the game and what they are choosing to spend time on • Then tailor the game to these tastes: • Players who prefer exploration can be given larger spaces
- 176. Player Modelling • We can look at how the player is playing the game and what they are choosing to spend time on • Then tailor the game to these tastes: • Players who prefer exploration can be given larger spaces • Players who dash to the goal can be given tight mazes with more hazards
- 178. Procedural Signposting • How can we guide the player?
- 179. Procedural Signposting • How can we guide the player? • Signposting is how designers subtly influence player perceptions
- 180. Procedural Signposting • How can we guide the player? • Signposting is how designers subtly influence player perceptions • Lights under "important" doors
- 181. Procedural Signposting • How can we guide the player? • Signposting is how designers subtly influence player perceptions • Lights under "important" doors • Cover position suggesting enemy locations
- 182. Procedural Signposting • How can we guide the player? • Signposting is how designers subtly influence player perceptions • Lights under "important" doors • Cover position suggesting enemy locations
- 183. Procedural Signposting • How can we guide the player? • Signposting is how designers subtly influence player perceptions • Lights under "important" doors • Cover position suggesting enemy locations
- 184. Procedural Signposting • How can we guide the player? • Signposting is how designers subtly influence player perceptions • Lights under "important" doors • Cover position suggesting enemy locations • Can we generate these signs on the fly?
- 185. Procedural Signposting • How can we guide the player? • Signposting is how designers subtly influence player perceptions • Lights under "important" doors • Cover position suggesting enemy locations • Can we generate these signs on the fly? • In EM, we're playing with how we can use our collectibles and hazards to help the player flow towards the goal (or misdirect)
- 186. Challenges
- 187. Challenges • Tools development may rack up a significant cost: both time and money
- 188. Challenges • Tools development may rack up a significant cost: both time and money
- 189. Challenges • Tools development may rack up a significant cost: both time and money
- 190. Challenges • Tools development may rack up a significant cost: both time and money • Strong programming knowledge required
- 191. Challenges • Tools development may rack up a significant cost: both time and money • Strong programming knowledge required • significant debugging and refining
- 192. Challenges • Tools development may rack up a significant cost: both time and money • Strong programming knowledge required • significant debugging and refining • responding to fringe cases
- 193. Challenges • Tools development may rack up a significant cost: both time and money • Strong programming knowledge required • significant debugging and refining • responding to fringe cases • Potential "sameness" generated spaces
- 194. Challenges • Tools development may rack up a significant cost: both time and money • Strong programming knowledge required • significant debugging and refining • responding to fringe cases • Potential "sameness" generated spaces • may be combated through:
- 195. Challenges • Tools development may rack up a significant cost: both time and money • Strong programming knowledge required • significant debugging and refining • responding to fringe cases • Potential "sameness" generated spaces • may be combated through: • peppering in unique content
- 196. Challenges • Tools development may rack up a significant cost: both time and money • Strong programming knowledge required • significant debugging and refining • responding to fringe cases • Potential "sameness" generated spaces • may be combated through: • peppering in unique content • combo approaches: both procedural and static
- 197. Challenges
- 198. Challenges • Balancing the power of your tools
- 199. Challenges • Balancing the power of your tools • Easy Money? started out with 100 levels
- 200. Challenges • Balancing the power of your tools • Easy Money? started out with 100 levels • PCG is not ideal for all types of games
- 201. Summary
- 202. Summary • Must evaluate the pros and cons of PCG on a project-specific basic
- 203. Summary • Must evaluate the pros and cons of PCG on a project-specific basic • The methods here can be leveraged for many different styles of games and tailored to many different level structures
- 204. Summary • Must evaluate the pros and cons of PCG on a project-specific basic • The methods here can be leveraged for many different styles of games and tailored to many different level structures
- 205. Summary • Must evaluate the pros and cons of PCG on a project-specific basic • The methods here can be leveraged for many different styles of games and tailored to many different level structures
- 206. Takeaways
- 207. Takeaways • Break levels down into modular pieces
- 208. Takeaways • Break levels down into modular pieces • Establish the PCG system early
- 209. Takeaways • Break levels down into modular pieces • Establish the PCG system early • Tight integration between artists, designers and developers
- 210. Takeaways • Break levels down into modular pieces • Establish the PCG system early • Tight integration between artists, designers and developers • PCG will affect decisions made by all groups
- 211. Takeaways • Break levels down into modular pieces • Establish the PCG system early • Tight integration between artists, designers and developers • PCG will affect decisions made by all groups • You can use PCG to turn your games to 11!
- 212. Alpha - http://easymoney.robotoverlord.co.uk/ Robot Overlord Games Heather Decker-Davis Luke Dicken heather@robotoverlord.co.uk luke@robotoverlord.co.uk @heathermdecker @LukeD
Hinweis der Redaktion
- \n
- Founded by Luke as an AI-centric "studio"\nFocused on AI prototypes, and later AI work-for-hire\nLong-time collaborator Heather joined in March as resident designer & artist\nGame development project spun out of Heather's MFA thesis\n
- Founded by Luke as an AI-centric "studio"\nFocused on AI prototypes, and later AI work-for-hire\nLong-time collaborator Heather joined in March as resident designer & artist\nGame development project spun out of Heather's MFA thesis\n
- Founded by Luke as an AI-centric "studio"\nFocused on AI prototypes, and later AI work-for-hire\nLong-time collaborator Heather joined in March as resident designer & artist\nGame development project spun out of Heather's MFA thesis\n
- Founded by Luke as an AI-centric "studio"\nFocused on AI prototypes, and later AI work-for-hire\nLong-time collaborator Heather joined in March as resident designer & artist\nGame development project spun out of Heather's MFA thesis\n
- Founded by Luke as an AI-centric "studio"\nFocused on AI prototypes, and later AI work-for-hire\nLong-time collaborator Heather joined in March as resident designer & artist\nGame development project spun out of Heather's MFA thesis\n
- Casual title based around risk/reward management\n"Millionaire" style lose-everything death penalty\nFacebook-based leaderboards\nIncreasing difficulty each level forces players to decide when to quit and log their score\nHand off to Heather after this one for a demo of the game\n
- Casual title based around risk/reward management\n"Millionaire" style lose-everything death penalty\nFacebook-based leaderboards\nIncreasing difficulty each level forces players to decide when to quit and log their score\nHand off to Heather after this one for a demo of the game\n
- Casual title based around risk/reward management\n"Millionaire" style lose-everything death penalty\nFacebook-based leaderboards\nIncreasing difficulty each level forces players to decide when to quit and log their score\nHand off to Heather after this one for a demo of the game\n
- Casual title based around risk/reward management\n"Millionaire" style lose-everything death penalty\nFacebook-based leaderboards\nIncreasing difficulty each level forces players to decide when to quit and log their score\nHand off to Heather after this one for a demo of the game\n
- Casual title based around risk/reward management\n"Millionaire" style lose-everything death penalty\nFacebook-based leaderboards\nIncreasing difficulty each level forces players to decide when to quit and log their score\nHand off to Heather after this one for a demo of the game\n
- Casual title based around risk/reward management\n"Millionaire" style lose-everything death penalty\nFacebook-based leaderboards\nIncreasing difficulty each level forces players to decide when to quit and log their score\nHand off to Heather after this one for a demo of the game\n
- \n
- Players expect lots of content in casual games\ntraditionally we were building this content purposefully, "by hand"\nInherent issues w/ static level content\nPlayers memorize levels and optimal paths - \nOften disinterested in replaying the same content\nPCG can keep it fresh. Imagine Temple Run with a fixed level layout\nEasier to store an algorithm than a set of assets\n
- Players expect lots of content in casual games\ntraditionally we were building this content purposefully, "by hand"\nInherent issues w/ static level content\nPlayers memorize levels and optimal paths - \nOften disinterested in replaying the same content\nPCG can keep it fresh. Imagine Temple Run with a fixed level layout\nEasier to store an algorithm than a set of assets\n
- Players expect lots of content in casual games\ntraditionally we were building this content purposefully, "by hand"\nInherent issues w/ static level content\nPlayers memorize levels and optimal paths - \nOften disinterested in replaying the same content\nPCG can keep it fresh. Imagine Temple Run with a fixed level layout\nEasier to store an algorithm than a set of assets\n
- Players expect lots of content in casual games\ntraditionally we were building this content purposefully, "by hand"\nInherent issues w/ static level content\nPlayers memorize levels and optimal paths - \nOften disinterested in replaying the same content\nPCG can keep it fresh. Imagine Temple Run with a fixed level layout\nEasier to store an algorithm than a set of assets\n
- Players expect lots of content in casual games\ntraditionally we were building this content purposefully, "by hand"\nInherent issues w/ static level content\nPlayers memorize levels and optimal paths - \nOften disinterested in replaying the same content\nPCG can keep it fresh. Imagine Temple Run with a fixed level layout\nEasier to store an algorithm than a set of assets\n
- Players expect lots of content in casual games\ntraditionally we were building this content purposefully, "by hand"\nInherent issues w/ static level content\nPlayers memorize levels and optimal paths - \nOften disinterested in replaying the same content\nPCG can keep it fresh. Imagine Temple Run with a fixed level layout\nEasier to store an algorithm than a set of assets\n
- Players expect lots of content in casual games\ntraditionally we were building this content purposefully, "by hand"\nInherent issues w/ static level content\nPlayers memorize levels and optimal paths - \nOften disinterested in replaying the same content\nPCG can keep it fresh. Imagine Temple Run with a fixed level layout\nEasier to store an algorithm than a set of assets\n
- Players expect lots of content in casual games\ntraditionally we were building this content purposefully, "by hand"\nInherent issues w/ static level content\nPlayers memorize levels and optimal paths - \nOften disinterested in replaying the same content\nPCG can keep it fresh. Imagine Temple Run with a fixed level layout\nEasier to store an algorithm than a set of assets\n
- Players expect lots of content in casual games\ntraditionally we were building this content purposefully, "by hand"\nInherent issues w/ static level content\nPlayers memorize levels and optimal paths - \nOften disinterested in replaying the same content\nPCG can keep it fresh. Imagine Temple Run with a fixed level layout\nEasier to store an algorithm than a set of assets\n
- Players expect lots of content in casual games\ntraditionally we were building this content purposefully, "by hand"\nInherent issues w/ static level content\nPlayers memorize levels and optimal paths - \nOften disinterested in replaying the same content\nPCG can keep it fresh. Imagine Temple Run with a fixed level layout\nEasier to store an algorithm than a set of assets\n
- Players expect lots of content in casual games\ntraditionally we were building this content purposefully, "by hand"\nInherent issues w/ static level content\nPlayers memorize levels and optimal paths - \nOften disinterested in replaying the same content\nPCG can keep it fresh. Imagine Temple Run with a fixed level layout\nEasier to store an algorithm than a set of assets\n
- One of my design goals was to facilitate a constant race to the top. Static content was at odds w/ this.\nAn ample set of levels was needed, and PCG could help us achieve this\nabout skill and reaction vs. muscle memory\nMazes are generated semi-randomly\nItems are deployed semi-randomly\nToday, we want to talk about how everything comes together and how PCG impacted our workflow and results\n
- One of my design goals was to facilitate a constant race to the top. Static content was at odds w/ this.\nAn ample set of levels was needed, and PCG could help us achieve this\nabout skill and reaction vs. muscle memory\nMazes are generated semi-randomly\nItems are deployed semi-randomly\nToday, we want to talk about how everything comes together and how PCG impacted our workflow and results\n
- One of my design goals was to facilitate a constant race to the top. Static content was at odds w/ this.\nAn ample set of levels was needed, and PCG could help us achieve this\nabout skill and reaction vs. muscle memory\nMazes are generated semi-randomly\nItems are deployed semi-randomly\nToday, we want to talk about how everything comes together and how PCG impacted our workflow and results\n
- One of my design goals was to facilitate a constant race to the top. Static content was at odds w/ this.\nAn ample set of levels was needed, and PCG could help us achieve this\nabout skill and reaction vs. muscle memory\nMazes are generated semi-randomly\nItems are deployed semi-randomly\nToday, we want to talk about how everything comes together and how PCG impacted our workflow and results\n
- One of my design goals was to facilitate a constant race to the top. Static content was at odds w/ this.\nAn ample set of levels was needed, and PCG could help us achieve this\nabout skill and reaction vs. muscle memory\nMazes are generated semi-randomly\nItems are deployed semi-randomly\nToday, we want to talk about how everything comes together and how PCG impacted our workflow and results\n
- One of my design goals was to facilitate a constant race to the top. Static content was at odds w/ this.\nAn ample set of levels was needed, and PCG could help us achieve this\nabout skill and reaction vs. muscle memory\nMazes are generated semi-randomly\nItems are deployed semi-randomly\nToday, we want to talk about how everything comes together and how PCG impacted our workflow and results\n
- One of my design goals was to facilitate a constant race to the top. Static content was at odds w/ this.\nAn ample set of levels was needed, and PCG could help us achieve this\nabout skill and reaction vs. muscle memory\nMazes are generated semi-randomly\nItems are deployed semi-randomly\nToday, we want to talk about how everything comes together and how PCG impacted our workflow and results\n
- One of my design goals was to facilitate a constant race to the top. Static content was at odds w/ this.\nAn ample set of levels was needed, and PCG could help us achieve this\nabout skill and reaction vs. muscle memory\nMazes are generated semi-randomly\nItems are deployed semi-randomly\nToday, we want to talk about how everything comes together and how PCG impacted our workflow and results\n
- More about setting up conditions for an envisioned range of possible player experiences than crafting a highly specific linear experience \nTerminology: static vs procedural.\nAnalogy: the difference between Peggle and Bejewelled - randomly placed and deliberately laid out\nSince many games follow the static content model and you may be used to developing this way, it might require conscious breaking of your previous development mindset\n
- More about setting up conditions for an envisioned range of possible player experiences than crafting a highly specific linear experience \nTerminology: static vs procedural.\nAnalogy: the difference between Peggle and Bejewelled - randomly placed and deliberately laid out\nSince many games follow the static content model and you may be used to developing this way, it might require conscious breaking of your previous development mindset\n
- More about setting up conditions for an envisioned range of possible player experiences than crafting a highly specific linear experience \nTerminology: static vs procedural.\nAnalogy: the difference between Peggle and Bejewelled - randomly placed and deliberately laid out\nSince many games follow the static content model and you may be used to developing this way, it might require conscious breaking of your previous development mindset\n
- More about setting up conditions for an envisioned range of possible player experiences than crafting a highly specific linear experience \nTerminology: static vs procedural.\nAnalogy: the difference between Peggle and Bejewelled - randomly placed and deliberately laid out\nSince many games follow the static content model and you may be used to developing this way, it might require conscious breaking of your previous development mindset\n
- More about setting up conditions for an envisioned range of possible player experiences than crafting a highly specific linear experience \nTerminology: static vs procedural.\nAnalogy: the difference between Peggle and Bejewelled - randomly placed and deliberately laid out\nSince many games follow the static content model and you may be used to developing this way, it might require conscious breaking of your previous development mindset\n
- Designing interactions for a space that does not yet exist - takes a different design mindset\nSpatial challenges - requires thought into the realm of possible results (are there potential impossible challenges?) and necessary constraints\nBreak it up. test core game mechanics - would this be fun? prior to developing a level gen system\n•Goodbye level design. System-oriented or formulaic progression is key - like all game design, requires testing to refine\n•Identify which variables impact your game in the desired manner - sense of fairness\n
- Designing interactions for a space that does not yet exist - takes a different design mindset\nSpatial challenges - requires thought into the realm of possible results (are there potential impossible challenges?) and necessary constraints\nBreak it up. test core game mechanics - would this be fun? prior to developing a level gen system\n•Goodbye level design. System-oriented or formulaic progression is key - like all game design, requires testing to refine\n•Identify which variables impact your game in the desired manner - sense of fairness\n
- Designing interactions for a space that does not yet exist - takes a different design mindset\nSpatial challenges - requires thought into the realm of possible results (are there potential impossible challenges?) and necessary constraints\nBreak it up. test core game mechanics - would this be fun? prior to developing a level gen system\n•Goodbye level design. System-oriented or formulaic progression is key - like all game design, requires testing to refine\n•Identify which variables impact your game in the desired manner - sense of fairness\n
- Designing interactions for a space that does not yet exist - takes a different design mindset\nSpatial challenges - requires thought into the realm of possible results (are there potential impossible challenges?) and necessary constraints\nBreak it up. test core game mechanics - would this be fun? prior to developing a level gen system\n•Goodbye level design. System-oriented or formulaic progression is key - like all game design, requires testing to refine\n•Identify which variables impact your game in the desired manner - sense of fairness\n
- Designing interactions for a space that does not yet exist - takes a different design mindset\nSpatial challenges - requires thought into the realm of possible results (are there potential impossible challenges?) and necessary constraints\nBreak it up. test core game mechanics - would this be fun? prior to developing a level gen system\n•Goodbye level design. System-oriented or formulaic progression is key - like all game design, requires testing to refine\n•Identify which variables impact your game in the desired manner - sense of fairness\n
- Designing interactions for a space that does not yet exist - takes a different design mindset\nSpatial challenges - requires thought into the realm of possible results (are there potential impossible challenges?) and necessary constraints\nBreak it up. test core game mechanics - would this be fun? prior to developing a level gen system\n•Goodbye level design. System-oriented or formulaic progression is key - like all game design, requires testing to refine\n•Identify which variables impact your game in the desired manner - sense of fairness\n
- Designing interactions for a space that does not yet exist - takes a different design mindset\nSpatial challenges - requires thought into the realm of possible results (are there potential impossible challenges?) and necessary constraints\nBreak it up. test core game mechanics - would this be fun? prior to developing a level gen system\n•Goodbye level design. System-oriented or formulaic progression is key - like all game design, requires testing to refine\n•Identify which variables impact your game in the desired manner - sense of fairness\n
- Designing interactions for a space that does not yet exist - takes a different design mindset\nSpatial challenges - requires thought into the realm of possible results (are there potential impossible challenges?) and necessary constraints\nBreak it up. test core game mechanics - would this be fun? prior to developing a level gen system\n•Goodbye level design. System-oriented or formulaic progression is key - like all game design, requires testing to refine\n•Identify which variables impact your game in the desired manner - sense of fairness\n
- Designing interactions for a space that does not yet exist - takes a different design mindset\nSpatial challenges - requires thought into the realm of possible results (are there potential impossible challenges?) and necessary constraints\nBreak it up. test core game mechanics - would this be fun? prior to developing a level gen system\n•Goodbye level design. System-oriented or formulaic progression is key - like all game design, requires testing to refine\n•Identify which variables impact your game in the desired manner - sense of fairness\n
- Designing interactions for a space that does not yet exist - takes a different design mindset\nSpatial challenges - requires thought into the realm of possible results (are there potential impossible challenges?) and necessary constraints\nBreak it up. test core game mechanics - would this be fun? prior to developing a level gen system\n•Goodbye level design. System-oriented or formulaic progression is key - like all game design, requires testing to refine\n•Identify which variables impact your game in the desired manner - sense of fairness\n
- Designing interactions for a space that does not yet exist - takes a different design mindset\nSpatial challenges - requires thought into the realm of possible results (are there potential impossible challenges?) and necessary constraints\nBreak it up. test core game mechanics - would this be fun? prior to developing a level gen system\n•Goodbye level design. System-oriented or formulaic progression is key - like all game design, requires testing to refine\n•Identify which variables impact your game in the desired manner - sense of fairness\n
- Test extremes of variables to find your target start and final level values, build a formula to fill in between point A and point B\nLinear equations - offer straightforward control, gradual progression... good starting pt. \nYou may choose to further shape the progression curve past the base linear format\n
- Test extremes of variables to find your target start and final level values, build a formula to fill in between point A and point B\nLinear equations - offer straightforward control, gradual progression... good starting pt. \nYou may choose to further shape the progression curve past the base linear format\n
- Test extremes of variables to find your target start and final level values, build a formula to fill in between point A and point B\nLinear equations - offer straightforward control, gradual progression... good starting pt. \nYou may choose to further shape the progression curve past the base linear format\n
- Test extremes of variables to find your target start and final level values, build a formula to fill in between point A and point B\nLinear equations - offer straightforward control, gradual progression... good starting pt. \nYou may choose to further shape the progression curve past the base linear format\n
- Test extremes of variables to find your target start and final level values, build a formula to fill in between point A and point B\nLinear equations - offer straightforward control, gradual progression... good starting pt. \nYou may choose to further shape the progression curve past the base linear format\n
- Test extremes of variables to find your target start and final level values, build a formula to fill in between point A and point B\nLinear equations - offer straightforward control, gradual progression... good starting pt. \nYou may choose to further shape the progression curve past the base linear format\n
- Test extremes of variables to find your target start and final level values, build a formula to fill in between point A and point B\nLinear equations - offer straightforward control, gradual progression... good starting pt. \nYou may choose to further shape the progression curve past the base linear format\n
- Test extremes of variables to find your target start and final level values, build a formula to fill in between point A and point B\nLinear equations - offer straightforward control, gradual progression... good starting pt. \nYou may choose to further shape the progression curve past the base linear format\n
- Test extremes of variables to find your target start and final level values, build a formula to fill in between point A and point B\nLinear equations - offer straightforward control, gradual progression... good starting pt. \nYou may choose to further shape the progression curve past the base linear format\n
- In general\nThe tech of how everything's put together will cause challenges for artists: involve them early\nArtists must think modularly and consider possible ways an asset may be positioned\nmodular assets in level editors - some parallels, but lack of direct control = new challenges\nMany possible approaches for art beyond this (theme packages, color shifting, procedural texture) Note pattern textures may prove difficult to predict/align\n
- In general\nThe tech of how everything's put together will cause challenges for artists: involve them early\nArtists must think modularly and consider possible ways an asset may be positioned\nmodular assets in level editors - some parallels, but lack of direct control = new challenges\nMany possible approaches for art beyond this (theme packages, color shifting, procedural texture) Note pattern textures may prove difficult to predict/align\n
- In general\nThe tech of how everything's put together will cause challenges for artists: involve them early\nArtists must think modularly and consider possible ways an asset may be positioned\nmodular assets in level editors - some parallels, but lack of direct control = new challenges\nMany possible approaches for art beyond this (theme packages, color shifting, procedural texture) Note pattern textures may prove difficult to predict/align\n
- In general\nThe tech of how everything's put together will cause challenges for artists: involve them early\nArtists must think modularly and consider possible ways an asset may be positioned\nmodular assets in level editors - some parallels, but lack of direct control = new challenges\nMany possible approaches for art beyond this (theme packages, color shifting, procedural texture) Note pattern textures may prove difficult to predict/align\n
- In general\nThe tech of how everything's put together will cause challenges for artists: involve them early\nArtists must think modularly and consider possible ways an asset may be positioned\nmodular assets in level editors - some parallels, but lack of direct control = new challenges\nMany possible approaches for art beyond this (theme packages, color shifting, procedural texture) Note pattern textures may prove difficult to predict/align\n
- In general\nThe tech of how everything's put together will cause challenges for artists: involve them early\nArtists must think modularly and consider possible ways an asset may be positioned\nmodular assets in level editors - some parallels, but lack of direct control = new challenges\nMany possible approaches for art beyond this (theme packages, color shifting, procedural texture) Note pattern textures may prove difficult to predict/align\n
- In general\nThe tech of how everything's put together will cause challenges for artists: involve them early\nArtists must think modularly and consider possible ways an asset may be positioned\nmodular assets in level editors - some parallels, but lack of direct control = new challenges\nMany possible approaches for art beyond this (theme packages, color shifting, procedural texture) Note pattern textures may prove difficult to predict/align\n
- EM Specific\n•Art style embraced the level structure: old timey steampunk carnival sideshow\n- rivet cuffs\n•I say bring artists in early because it may take trial and error to figure out the best approach.\nTesting and prototyping.\n
- EM Specific\n•Art style embraced the level structure: old timey steampunk carnival sideshow\n- rivet cuffs\n•I say bring artists in early because it may take trial and error to figure out the best approach.\nTesting and prototyping.\n
- EM Specific\n•Art style embraced the level structure: old timey steampunk carnival sideshow\n- rivet cuffs\n•I say bring artists in early because it may take trial and error to figure out the best approach.\nTesting and prototyping.\n
- EM Specific\n•Art style embraced the level structure: old timey steampunk carnival sideshow\n- rivet cuffs\n•I say bring artists in early because it may take trial and error to figure out the best approach.\nTesting and prototyping.\n
- EM Specific\n•Art style embraced the level structure: old timey steampunk carnival sideshow\n- rivet cuffs\n•I say bring artists in early because it may take trial and error to figure out the best approach.\nTesting and prototyping.\n
- EM Specific\n•Art style embraced the level structure: old timey steampunk carnival sideshow\n- rivet cuffs\n•I say bring artists in early because it may take trial and error to figure out the best approach.\nTesting and prototyping.\n
- •Once general level characteristics were defined, 2D tiles were created\n•This allowed us to refine both the generation system and the piece set, easily iterate\n•Level gen system built to support easy add/removal of pieces\nonce the system was refined & basic tile set consistently produced desired results, we moved forward with 3D asset production\nOverall prototyping occurred in stages: 2D, 3D, pickups/funds, then hazards, each building on the last\n
- •Once general level characteristics were defined, 2D tiles were created\n•This allowed us to refine both the generation system and the piece set, easily iterate\n•Level gen system built to support easy add/removal of pieces\nonce the system was refined & basic tile set consistently produced desired results, we moved forward with 3D asset production\nOverall prototyping occurred in stages: 2D, 3D, pickups/funds, then hazards, each building on the last\n
- •Once general level characteristics were defined, 2D tiles were created\n•This allowed us to refine both the generation system and the piece set, easily iterate\n•Level gen system built to support easy add/removal of pieces\nonce the system was refined & basic tile set consistently produced desired results, we moved forward with 3D asset production\nOverall prototyping occurred in stages: 2D, 3D, pickups/funds, then hazards, each building on the last\n
- •Once general level characteristics were defined, 2D tiles were created\n•This allowed us to refine both the generation system and the piece set, easily iterate\n•Level gen system built to support easy add/removal of pieces\nonce the system was refined & basic tile set consistently produced desired results, we moved forward with 3D asset production\nOverall prototyping occurred in stages: 2D, 3D, pickups/funds, then hazards, each building on the last\n
- •Once general level characteristics were defined, 2D tiles were created\n•This allowed us to refine both the generation system and the piece set, easily iterate\n•Level gen system built to support easy add/removal of pieces\nonce the system was refined & basic tile set consistently produced desired results, we moved forward with 3D asset production\nOverall prototyping occurred in stages: 2D, 3D, pickups/funds, then hazards, each building on the last\n
- •Once general level characteristics were defined, 2D tiles were created\n•This allowed us to refine both the generation system and the piece set, easily iterate\n•Level gen system built to support easy add/removal of pieces\nonce the system was refined & basic tile set consistently produced desired results, we moved forward with 3D asset production\nOverall prototyping occurred in stages: 2D, 3D, pickups/funds, then hazards, each building on the last\n
- •Once general level characteristics were defined, 2D tiles were created\n•This allowed us to refine both the generation system and the piece set, easily iterate\n•Level gen system built to support easy add/removal of pieces\nonce the system was refined & basic tile set consistently produced desired results, we moved forward with 3D asset production\nOverall prototyping occurred in stages: 2D, 3D, pickups/funds, then hazards, each building on the last\n
- •Once general level characteristics were defined, 2D tiles were created\n•This allowed us to refine both the generation system and the piece set, easily iterate\n•Level gen system built to support easy add/removal of pieces\nonce the system was refined & basic tile set consistently produced desired results, we moved forward with 3D asset production\nOverall prototyping occurred in stages: 2D, 3D, pickups/funds, then hazards, each building on the last\n
- •Once general level characteristics were defined, 2D tiles were created\n•This allowed us to refine both the generation system and the piece set, easily iterate\n•Level gen system built to support easy add/removal of pieces\nonce the system was refined & basic tile set consistently produced desired results, we moved forward with 3D asset production\nOverall prototyping occurred in stages: 2D, 3D, pickups/funds, then hazards, each building on the last\n
- •Once general level characteristics were defined, 2D tiles were created\n•This allowed us to refine both the generation system and the piece set, easily iterate\n•Level gen system built to support easy add/removal of pieces\nonce the system was refined & basic tile set consistently produced desired results, we moved forward with 3D asset production\nOverall prototyping occurred in stages: 2D, 3D, pickups/funds, then hazards, each building on the last\n
- 3D level assets modelled based on 2d tiles\ncareful attention to scale and consistent construction ensured each piece would snap together properly on the grid\nOnce all models passed testing in-game, onward to texture.\nWith this particular engine, to minimize draw calls, I crammed as much onto a single texture sheet as possible - pickups to level pieces\nThey have individual UVs but all refer to a single image for texture info\nPacking aside, maximized reusability of pixel space for shared components\n\n
- 3D level assets modelled based on 2d tiles\ncareful attention to scale and consistent construction ensured each piece would snap together properly on the grid\nOnce all models passed testing in-game, onward to texture.\nWith this particular engine, to minimize draw calls, I crammed as much onto a single texture sheet as possible - pickups to level pieces\nThey have individual UVs but all refer to a single image for texture info\nPacking aside, maximized reusability of pixel space for shared components\n\n
- 3D level assets modelled based on 2d tiles\ncareful attention to scale and consistent construction ensured each piece would snap together properly on the grid\nOnce all models passed testing in-game, onward to texture.\nWith this particular engine, to minimize draw calls, I crammed as much onto a single texture sheet as possible - pickups to level pieces\nThey have individual UVs but all refer to a single image for texture info\nPacking aside, maximized reusability of pixel space for shared components\n\n
- 3D level assets modelled based on 2d tiles\ncareful attention to scale and consistent construction ensured each piece would snap together properly on the grid\nOnce all models passed testing in-game, onward to texture.\nWith this particular engine, to minimize draw calls, I crammed as much onto a single texture sheet as possible - pickups to level pieces\nThey have individual UVs but all refer to a single image for texture info\nPacking aside, maximized reusability of pixel space for shared components\n\n
- 3D level assets modelled based on 2d tiles\ncareful attention to scale and consistent construction ensured each piece would snap together properly on the grid\nOnce all models passed testing in-game, onward to texture.\nWith this particular engine, to minimize draw calls, I crammed as much onto a single texture sheet as possible - pickups to level pieces\nThey have individual UVs but all refer to a single image for texture info\nPacking aside, maximized reusability of pixel space for shared components\n\n
- 3D level assets modelled based on 2d tiles\ncareful attention to scale and consistent construction ensured each piece would snap together properly on the grid\nOnce all models passed testing in-game, onward to texture.\nWith this particular engine, to minimize draw calls, I crammed as much onto a single texture sheet as possible - pickups to level pieces\nThey have individual UVs but all refer to a single image for texture info\nPacking aside, maximized reusability of pixel space for shared components\n\n
- 3D level assets modelled based on 2d tiles\ncareful attention to scale and consistent construction ensured each piece would snap together properly on the grid\nOnce all models passed testing in-game, onward to texture.\nWith this particular engine, to minimize draw calls, I crammed as much onto a single texture sheet as possible - pickups to level pieces\nThey have individual UVs but all refer to a single image for texture info\nPacking aside, maximized reusability of pixel space for shared components\n\n
- 3D level assets modelled based on 2d tiles\ncareful attention to scale and consistent construction ensured each piece would snap together properly on the grid\nOnce all models passed testing in-game, onward to texture.\nWith this particular engine, to minimize draw calls, I crammed as much onto a single texture sheet as possible - pickups to level pieces\nThey have individual UVs but all refer to a single image for texture info\nPacking aside, maximized reusability of pixel space for shared components\n\n
- 3D level assets modelled based on 2d tiles\ncareful attention to scale and consistent construction ensured each piece would snap together properly on the grid\nOnce all models passed testing in-game, onward to texture.\nWith this particular engine, to minimize draw calls, I crammed as much onto a single texture sheet as possible - pickups to level pieces\nThey have individual UVs but all refer to a single image for texture info\nPacking aside, maximized reusability of pixel space for shared components\n\n
- Creating mazes isn't overly hard\nBiggest challenge is tracking representation internally\nThis is not a code tutorial so skipping all of that!\nAll we really need to grow a maze is place appropriate pieces into the game world\nAnywhere that is a "road to nowhere" can have more maze tagged on.\nVery efficient approach\nGenerates some nice spaces, images are using 2D prototypes that Heather mentioned\n(1st image)\nIntended to create mazes of around 20 pieces, but scales well\nAround 30,000 it starts to chug and take a few seconds\n(2nd image)\n
- Creating mazes isn't overly hard\nBiggest challenge is tracking representation internally\nThis is not a code tutorial so skipping all of that!\nAll we really need to grow a maze is place appropriate pieces into the game world\nAnywhere that is a "road to nowhere" can have more maze tagged on.\nVery efficient approach\nGenerates some nice spaces, images are using 2D prototypes that Heather mentioned\n(1st image)\nIntended to create mazes of around 20 pieces, but scales well\nAround 30,000 it starts to chug and take a few seconds\n(2nd image)\n
- Creating mazes isn't overly hard\nBiggest challenge is tracking representation internally\nThis is not a code tutorial so skipping all of that!\nAll we really need to grow a maze is place appropriate pieces into the game world\nAnywhere that is a "road to nowhere" can have more maze tagged on.\nVery efficient approach\nGenerates some nice spaces, images are using 2D prototypes that Heather mentioned\n(1st image)\nIntended to create mazes of around 20 pieces, but scales well\nAround 30,000 it starts to chug and take a few seconds\n(2nd image)\n
- Creating mazes isn't overly hard\nBiggest challenge is tracking representation internally\nThis is not a code tutorial so skipping all of that!\nAll we really need to grow a maze is place appropriate pieces into the game world\nAnywhere that is a "road to nowhere" can have more maze tagged on.\nVery efficient approach\nGenerates some nice spaces, images are using 2D prototypes that Heather mentioned\n(1st image)\nIntended to create mazes of around 20 pieces, but scales well\nAround 30,000 it starts to chug and take a few seconds\n(2nd image)\n
- Creating mazes isn't overly hard\nBiggest challenge is tracking representation internally\nThis is not a code tutorial so skipping all of that!\nAll we really need to grow a maze is place appropriate pieces into the game world\nAnywhere that is a "road to nowhere" can have more maze tagged on.\nVery efficient approach\nGenerates some nice spaces, images are using 2D prototypes that Heather mentioned\n(1st image)\nIntended to create mazes of around 20 pieces, but scales well\nAround 30,000 it starts to chug and take a few seconds\n(2nd image)\n
- Creating mazes isn't overly hard\nBiggest challenge is tracking representation internally\nThis is not a code tutorial so skipping all of that!\nAll we really need to grow a maze is place appropriate pieces into the game world\nAnywhere that is a "road to nowhere" can have more maze tagged on.\nVery efficient approach\nGenerates some nice spaces, images are using 2D prototypes that Heather mentioned\n(1st image)\nIntended to create mazes of around 20 pieces, but scales well\nAround 30,000 it starts to chug and take a few seconds\n(2nd image)\n
- Creating mazes isn't overly hard\nBiggest challenge is tracking representation internally\nThis is not a code tutorial so skipping all of that!\nAll we really need to grow a maze is place appropriate pieces into the game world\nAnywhere that is a "road to nowhere" can have more maze tagged on.\nVery efficient approach\nGenerates some nice spaces, images are using 2D prototypes that Heather mentioned\n(1st image)\nIntended to create mazes of around 20 pieces, but scales well\nAround 30,000 it starts to chug and take a few seconds\n(2nd image)\n
- \n
- \n
- \n
- \n
- \n
- \n
- This is one shows that we are aware there is a piece to the North that doesn't have a corresponding Southerly connection, so the piece selected at random cannot have a North connection\n
- Likewise here, it cannot have a north pipe\n
- \n
- \n
- \n
- \n
- This one /must/ have a north connection to keep the maze complete\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- End Capping\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- One end-cap is replaced with the end room asset\n
- The algorithm implicitly produces "fully connected" mazes.\nWe use some simple checks to validate the mazes produced are interesting\nNumber of dead-ends placed in the maze\nDistance from start to end\nNumber of pieces that have been placed\nIf any of these checks fail, the maze is rejected and a new one generated\n
- The algorithm implicitly produces "fully connected" mazes.\nWe use some simple checks to validate the mazes produced are interesting\nNumber of dead-ends placed in the maze\nDistance from start to end\nNumber of pieces that have been placed\nIf any of these checks fail, the maze is rejected and a new one generated\n
- The algorithm implicitly produces "fully connected" mazes.\nWe use some simple checks to validate the mazes produced are interesting\nNumber of dead-ends placed in the maze\nDistance from start to end\nNumber of pieces that have been placed\nIf any of these checks fail, the maze is rejected and a new one generated\n
- The algorithm implicitly produces "fully connected" mazes.\nWe use some simple checks to validate the mazes produced are interesting\nNumber of dead-ends placed in the maze\nDistance from start to end\nNumber of pieces that have been placed\nIf any of these checks fail, the maze is rejected and a new one generated\n
- The algorithm implicitly produces "fully connected" mazes.\nWe use some simple checks to validate the mazes produced are interesting\nNumber of dead-ends placed in the maze\nDistance from start to end\nNumber of pieces that have been placed\nIf any of these checks fail, the maze is rejected and a new one generated\n
- Frequent question\nEssentially boils down to P vs NP\nVerification is a very simple process\nGuiding generation is way more complex\nDo we solve the simple problem multiple times, or the complex problem once\nYour mileage may vary\nDepends a lot on the frequency you will reject generated spaces with\nFor EM this is about 1 in 50, and we can generate a maze without guidance on the order of 2ms\nQuick maths and at 60fps - 2.56x10^-14 chance of slowing down even a frame\n
- Frequent question\nEssentially boils down to P vs NP\nVerification is a very simple process\nGuiding generation is way more complex\nDo we solve the simple problem multiple times, or the complex problem once\nYour mileage may vary\nDepends a lot on the frequency you will reject generated spaces with\nFor EM this is about 1 in 50, and we can generate a maze without guidance on the order of 2ms\nQuick maths and at 60fps - 2.56x10^-14 chance of slowing down even a frame\n
- Frequent question\nEssentially boils down to P vs NP\nVerification is a very simple process\nGuiding generation is way more complex\nDo we solve the simple problem multiple times, or the complex problem once\nYour mileage may vary\nDepends a lot on the frequency you will reject generated spaces with\nFor EM this is about 1 in 50, and we can generate a maze without guidance on the order of 2ms\nQuick maths and at 60fps - 2.56x10^-14 chance of slowing down even a frame\n
- Frequent question\nEssentially boils down to P vs NP\nVerification is a very simple process\nGuiding generation is way more complex\nDo we solve the simple problem multiple times, or the complex problem once\nYour mileage may vary\nDepends a lot on the frequency you will reject generated spaces with\nFor EM this is about 1 in 50, and we can generate a maze without guidance on the order of 2ms\nQuick maths and at 60fps - 2.56x10^-14 chance of slowing down even a frame\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- Analysis needs context\nIn particular for tracking Fringe Cases - Heather mentioned\nHow can we inspect events in a player's game when that content is being generated on the fly?\nNeed to have the ability to export configurations of levels along with analytics data\nSo also need to be able to bypass PCG system and load up a specific maze for replay\n
- Analysis needs context\nIn particular for tracking Fringe Cases - Heather mentioned\nHow can we inspect events in a player's game when that content is being generated on the fly?\nNeed to have the ability to export configurations of levels along with analytics data\nSo also need to be able to bypass PCG system and load up a specific maze for replay\n
- Analysis needs context\nIn particular for tracking Fringe Cases - Heather mentioned\nHow can we inspect events in a player's game when that content is being generated on the fly?\nNeed to have the ability to export configurations of levels along with analytics data\nSo also need to be able to bypass PCG system and load up a specific maze for replay\n
- We have parameters that we're using\nfor generation\nfor verification\nfor ingame properties\nSo it isn't hard to see that if we start manipulating these parameters we can start varying the difficulty\nLarger mazes, more mines, faster moving mines, increase the branching of the maze\nAs the game progresses, we can control the tone of the spaces being created\nSee Tiny Wings for a good example of this in action\n
- We have parameters that we're using\nfor generation\nfor verification\nfor ingame properties\nSo it isn't hard to see that if we start manipulating these parameters we can start varying the difficulty\nLarger mazes, more mines, faster moving mines, increase the branching of the maze\nAs the game progresses, we can control the tone of the spaces being created\nSee Tiny Wings for a good example of this in action\n
- We have parameters that we're using\nfor generation\nfor verification\nfor ingame properties\nSo it isn't hard to see that if we start manipulating these parameters we can start varying the difficulty\nLarger mazes, more mines, faster moving mines, increase the branching of the maze\nAs the game progresses, we can control the tone of the spaces being created\nSee Tiny Wings for a good example of this in action\n
- We have parameters that we're using\nfor generation\nfor verification\nfor ingame properties\nSo it isn't hard to see that if we start manipulating these parameters we can start varying the difficulty\nLarger mazes, more mines, faster moving mines, increase the branching of the maze\nAs the game progresses, we can control the tone of the spaces being created\nSee Tiny Wings for a good example of this in action\n
- We have parameters that we're using\nfor generation\nfor verification\nfor ingame properties\nSo it isn't hard to see that if we start manipulating these parameters we can start varying the difficulty\nLarger mazes, more mines, faster moving mines, increase the branching of the maze\nAs the game progresses, we can control the tone of the spaces being created\nSee Tiny Wings for a good example of this in action\n
- We have parameters that we're using\nfor generation\nfor verification\nfor ingame properties\nSo it isn't hard to see that if we start manipulating these parameters we can start varying the difficulty\nLarger mazes, more mines, faster moving mines, increase the branching of the maze\nAs the game progresses, we can control the tone of the spaces being created\nSee Tiny Wings for a good example of this in action\n
- We have parameters that we're using\nfor generation\nfor verification\nfor ingame properties\nSo it isn't hard to see that if we start manipulating these parameters we can start varying the difficulty\nLarger mazes, more mines, faster moving mines, increase the branching of the maze\nAs the game progresses, we can control the tone of the spaces being created\nSee Tiny Wings for a good example of this in action\n
- We have parameters that we're using\nfor generation\nfor verification\nfor ingame properties\nSo it isn't hard to see that if we start manipulating these parameters we can start varying the difficulty\nLarger mazes, more mines, faster moving mines, increase the branching of the maze\nAs the game progresses, we can control the tone of the spaces being created\nSee Tiny Wings for a good example of this in action\n
- We can go a step further tho\nRather than adapting the game to suit the degree of challenge we want a specific level to represent\nWe can look at how the player is playing the game and what they are choosing to spend time on\nThen tailor the game to these tastes\nPlayers who prefer exploration can be given larger spaces\nPlayers who dash to the goal can be given tight mazes with more hazards\n
- We can go a step further tho\nRather than adapting the game to suit the degree of challenge we want a specific level to represent\nWe can look at how the player is playing the game and what they are choosing to spend time on\nThen tailor the game to these tastes\nPlayers who prefer exploration can be given larger spaces\nPlayers who dash to the goal can be given tight mazes with more hazards\n
- We can go a step further tho\nRather than adapting the game to suit the degree of challenge we want a specific level to represent\nWe can look at how the player is playing the game and what they are choosing to spend time on\nThen tailor the game to these tastes\nPlayers who prefer exploration can be given larger spaces\nPlayers who dash to the goal can be given tight mazes with more hazards\n
- We can go a step further tho\nRather than adapting the game to suit the degree of challenge we want a specific level to represent\nWe can look at how the player is playing the game and what they are choosing to spend time on\nThen tailor the game to these tastes\nPlayers who prefer exploration can be given larger spaces\nPlayers who dash to the goal can be given tight mazes with more hazards\n
- We've talked about making the level\nWe've talked about catering the level to the player\nHow can we guide the player?\nSignposting is how designers subtly influence player perceptions\nLights under "important" doors\nCan we generate these signs on the fly?\nIn EM, we're playing with how we can use our collectibles and hazards to help the player flow towards the goal (or misdirect)\n
- We've talked about making the level\nWe've talked about catering the level to the player\nHow can we guide the player?\nSignposting is how designers subtly influence player perceptions\nLights under "important" doors\nCan we generate these signs on the fly?\nIn EM, we're playing with how we can use our collectibles and hazards to help the player flow towards the goal (or misdirect)\n
- We've talked about making the level\nWe've talked about catering the level to the player\nHow can we guide the player?\nSignposting is how designers subtly influence player perceptions\nLights under "important" doors\nCan we generate these signs on the fly?\nIn EM, we're playing with how we can use our collectibles and hazards to help the player flow towards the goal (or misdirect)\n
- We've talked about making the level\nWe've talked about catering the level to the player\nHow can we guide the player?\nSignposting is how designers subtly influence player perceptions\nLights under "important" doors\nCan we generate these signs on the fly?\nIn EM, we're playing with how we can use our collectibles and hazards to help the player flow towards the goal (or misdirect)\n
- We've talked about making the level\nWe've talked about catering the level to the player\nHow can we guide the player?\nSignposting is how designers subtly influence player perceptions\nLights under "important" doors\nCan we generate these signs on the fly?\nIn EM, we're playing with how we can use our collectibles and hazards to help the player flow towards the goal (or misdirect)\n
- We've talked about making the level\nWe've talked about catering the level to the player\nHow can we guide the player?\nSignposting is how designers subtly influence player perceptions\nLights under "important" doors\nCan we generate these signs on the fly?\nIn EM, we're playing with how we can use our collectibles and hazards to help the player flow towards the goal (or misdirect)\n
- We've talked about making the level\nWe've talked about catering the level to the player\nHow can we guide the player?\nSignposting is how designers subtly influence player perceptions\nLights under "important" doors\nCan we generate these signs on the fly?\nIn EM, we're playing with how we can use our collectibles and hazards to help the player flow towards the goal (or misdirect)\n
- We've talked about making the level\nWe've talked about catering the level to the player\nHow can we guide the player?\nSignposting is how designers subtly influence player perceptions\nLights under "important" doors\nCan we generate these signs on the fly?\nIn EM, we're playing with how we can use our collectibles and hazards to help the player flow towards the goal (or misdirect)\n
- First and foremost: not a silver bullet, but good to have in the tool set\nTools development, creating your content gen systems, can end up being a quagmire of cost and time\n(see Spore, ambitious but infamously over-budget and behind schedule)\nTeam MUST have strong programming\nample time WILL be spent debugging and refining procedural systems, responding to fringe cases\nPotential "sameness" of autonomously generated spaces\nmay be combated through:\nintroduction of unique content over time, but each new level gen feature must be tested and refined\ncombination approaches, as seen in Diablo games\n
- First and foremost: not a silver bullet, but good to have in the tool set\nTools development, creating your content gen systems, can end up being a quagmire of cost and time\n(see Spore, ambitious but infamously over-budget and behind schedule)\nTeam MUST have strong programming\nample time WILL be spent debugging and refining procedural systems, responding to fringe cases\nPotential "sameness" of autonomously generated spaces\nmay be combated through:\nintroduction of unique content over time, but each new level gen feature must be tested and refined\ncombination approaches, as seen in Diablo games\n
- First and foremost: not a silver bullet, but good to have in the tool set\nTools development, creating your content gen systems, can end up being a quagmire of cost and time\n(see Spore, ambitious but infamously over-budget and behind schedule)\nTeam MUST have strong programming\nample time WILL be spent debugging and refining procedural systems, responding to fringe cases\nPotential "sameness" of autonomously generated spaces\nmay be combated through:\nintroduction of unique content over time, but each new level gen feature must be tested and refined\ncombination approaches, as seen in Diablo games\n
- First and foremost: not a silver bullet, but good to have in the tool set\nTools development, creating your content gen systems, can end up being a quagmire of cost and time\n(see Spore, ambitious but infamously over-budget and behind schedule)\nTeam MUST have strong programming\nample time WILL be spent debugging and refining procedural systems, responding to fringe cases\nPotential "sameness" of autonomously generated spaces\nmay be combated through:\nintroduction of unique content over time, but each new level gen feature must be tested and refined\ncombination approaches, as seen in Diablo games\n
- First and foremost: not a silver bullet, but good to have in the tool set\nTools development, creating your content gen systems, can end up being a quagmire of cost and time\n(see Spore, ambitious but infamously over-budget and behind schedule)\nTeam MUST have strong programming\nample time WILL be spent debugging and refining procedural systems, responding to fringe cases\nPotential "sameness" of autonomously generated spaces\nmay be combated through:\nintroduction of unique content over time, but each new level gen feature must be tested and refined\ncombination approaches, as seen in Diablo games\n
- First and foremost: not a silver bullet, but good to have in the tool set\nTools development, creating your content gen systems, can end up being a quagmire of cost and time\n(see Spore, ambitious but infamously over-budget and behind schedule)\nTeam MUST have strong programming\nample time WILL be spent debugging and refining procedural systems, responding to fringe cases\nPotential "sameness" of autonomously generated spaces\nmay be combated through:\nintroduction of unique content over time, but each new level gen feature must be tested and refined\ncombination approaches, as seen in Diablo games\n
- First and foremost: not a silver bullet, but good to have in the tool set\nTools development, creating your content gen systems, can end up being a quagmire of cost and time\n(see Spore, ambitious but infamously over-budget and behind schedule)\nTeam MUST have strong programming\nample time WILL be spent debugging and refining procedural systems, responding to fringe cases\nPotential "sameness" of autonomously generated spaces\nmay be combated through:\nintroduction of unique content over time, but each new level gen feature must be tested and refined\ncombination approaches, as seen in Diablo games\n
- First and foremost: not a silver bullet, but good to have in the tool set\nTools development, creating your content gen systems, can end up being a quagmire of cost and time\n(see Spore, ambitious but infamously over-budget and behind schedule)\nTeam MUST have strong programming\nample time WILL be spent debugging and refining procedural systems, responding to fringe cases\nPotential "sameness" of autonomously generated spaces\nmay be combated through:\nintroduction of unique content over time, but each new level gen feature must be tested and refined\ncombination approaches, as seen in Diablo games\n
- First and foremost: not a silver bullet, but good to have in the tool set\nTools development, creating your content gen systems, can end up being a quagmire of cost and time\n(see Spore, ambitious but infamously over-budget and behind schedule)\nTeam MUST have strong programming\nample time WILL be spent debugging and refining procedural systems, responding to fringe cases\nPotential "sameness" of autonomously generated spaces\nmay be combated through:\nintroduction of unique content over time, but each new level gen feature must be tested and refined\ncombination approaches, as seen in Diablo games\n
- First and foremost: not a silver bullet, but good to have in the tool set\nTools development, creating your content gen systems, can end up being a quagmire of cost and time\n(see Spore, ambitious but infamously over-budget and behind schedule)\nTeam MUST have strong programming\nample time WILL be spent debugging and refining procedural systems, responding to fringe cases\nPotential "sameness" of autonomously generated spaces\nmay be combated through:\nintroduction of unique content over time, but each new level gen feature must be tested and refined\ncombination approaches, as seen in Diablo games\n
- balance - potential for nearly limitless content, but offering endless levels often conflicts w/ player expectations, finite goals\nUse your newfound PCG powers wisely\n(EM had 100 levels... dropped to 25)\nprocedural level generation is not ideal for all types of games\nFor example, environmental storytelling becomes a challenge\n
- balance - potential for nearly limitless content, but offering endless levels often conflicts w/ player expectations, finite goals\nUse your newfound PCG powers wisely\n(EM had 100 levels... dropped to 25)\nprocedural level generation is not ideal for all types of games\nFor example, environmental storytelling becomes a challenge\n
- balance - potential for nearly limitless content, but offering endless levels often conflicts w/ player expectations, finite goals\nUse your newfound PCG powers wisely\n(EM had 100 levels... dropped to 25)\nprocedural level generation is not ideal for all types of games\nFor example, environmental storytelling becomes a challenge\n
- developers should evaluate the pros and cons of procedural generation relative to their project before taking off w/ this path\nkey question: does the benefit brought by PCG warrant the tools dev, testing, etc?\nThe methods here can be leveraged for many different styles of games (RPGs, action, racing, etc.) and tailored to many different level structures\nA well-known example would be Diablo 3, which is structured essentially the same what we’ve been discussed here today.\n
- developers should evaluate the pros and cons of procedural generation relative to their project before taking off w/ this path\nkey question: does the benefit brought by PCG warrant the tools dev, testing, etc?\nThe methods here can be leveraged for many different styles of games (RPGs, action, racing, etc.) and tailored to many different level structures\nA well-known example would be Diablo 3, which is structured essentially the same what we’ve been discussed here today.\n
- developers should evaluate the pros and cons of procedural generation relative to their project before taking off w/ this path\nkey question: does the benefit brought by PCG warrant the tools dev, testing, etc?\nThe methods here can be leveraged for many different styles of games (RPGs, action, racing, etc.) and tailored to many different level structures\nA well-known example would be Diablo 3, which is structured essentially the same what we’ve been discussed here today.\n
- developers should evaluate the pros and cons of procedural generation relative to their project before taking off w/ this path\nkey question: does the benefit brought by PCG warrant the tools dev, testing, etc?\nThe methods here can be leveraged for many different styles of games (RPGs, action, racing, etc.) and tailored to many different level structures\nA well-known example would be Diablo 3, which is structured essentially the same what we’ve been discussed here today.\n
- Break levels down into modular pieces\nEstablish the PCG system early\nTight integration between artists, designers and developers\nPCG will affect decisions made by all groups\nYou can use PCG to turn your games to 11!\n
- Break levels down into modular pieces\nEstablish the PCG system early\nTight integration between artists, designers and developers\nPCG will affect decisions made by all groups\nYou can use PCG to turn your games to 11!\n
- Break levels down into modular pieces\nEstablish the PCG system early\nTight integration between artists, designers and developers\nPCG will affect decisions made by all groups\nYou can use PCG to turn your games to 11!\n
- Break levels down into modular pieces\nEstablish the PCG system early\nTight integration between artists, designers and developers\nPCG will affect decisions made by all groups\nYou can use PCG to turn your games to 11!\n
- Break levels down into modular pieces\nEstablish the PCG system early\nTight integration between artists, designers and developers\nPCG will affect decisions made by all groups\nYou can use PCG to turn your games to 11!\n
- \n