• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Procedural Processes - Lessons Learnt from Automated Content Generation in "Easy Money?"
 

Procedural Processes - Lessons Learnt from Automated Content Generation in "Easy Money?"

on

  • 158 views

In this talk, given at the 2012 No Show Conference, and alongside long-term partner in crime Heather Decker-Davis, we talk about our game "Easy Money?" and our approach to content generation - along ...

In this talk, given at the 2012 No Show Conference, and alongside long-term partner in crime Heather Decker-Davis, we talk about our game "Easy Money?" and our approach to content generation - along with the challenges they provided and the way it affected our workflow.

Statistics

Views

Total Views
158
Views on SlideShare
158
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Procedural Processes - Lessons Learnt from Automated Content Generation in "Easy Money?" Procedural Processes - Lessons Learnt from Automated Content Generation in "Easy Money?" Presentation Transcript

    • Procedural Processes Lessons Learnt From Automated Content Generation in “Easy Money”? Luke Dicken and Heather Decker-Davis @LukeD @HeatherMDecker
    • About Robot Overlord Games
    • About "Easy Money?"
    • Easy Money? Demo
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Algorithmic Maze Creation
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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)
    • 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
    • Challenges • Balancing the power of your tools • Easy Money? started out with 100 levels • PCG is not ideal for all types of games
    • 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
    • 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!
    • Alpha - http://easymoney.robotoverlord.co.uk/ Robot Overlord Games ! Heather Decker-Davis heather@robotoverlord.co.uk @heathermdecker ! Luke Dicken luke@robotoverlord.co.uk @LukeD