Finding The Fun


Published on

Final Form Games talks about the importance of making good decisions early on in development, and how iteration, prototypes, and testing can provide you with the information you need to make the right choices.

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Finding The Fun

  1. 1. Finding the Fun Presented By Tim Ambrogi
  2. 2. Finding the Fun <ul><li>Games are expected to be fun
  3. 3. Fun is elusive, and nebulously defined
  4. 4. Result of a complex interaction </li><ul><li>Digital
  5. 5. Chemical
  6. 6. Psychological </li></ul></ul>
  7. 7. Games I've Worked On
  8. 8. The Problem At Hand <ul><li>Some terms: </li></ul>
  9. 9. The Problem At Hand <ul><li>Some terms:
  10. 10. optimization problem </li><ul><li>the problem of finding the best solution from all feasible solutions </li></ul></ul>
  11. 11. The Problem At Hand <ul><li>Some terms:
  12. 12. optimization problem </li><ul><li>the problem of finding the best solution from all feasible solutions </li></ul><li>solution space </li><ul><li>the set of all possible solutions to an optimization problem </li></ul></ul>
  13. 13. Where To Eat? map of philly restaurants
  14. 14. Where To Eat? map of philly restaurants colored by price
  15. 15. Constraints <ul><li>Some more terms: </li></ul>
  16. 16. Constraints <ul><li>Some more terms:
  17. 17. constraint </li><ul><li>a condition that must be satisfied for a solution to be valid </li></ul></ul>
  18. 18. Constraints <ul><li>Some more terms:
  19. 19. constraint </li><ul><li>a condition that must be satisfied for a solution to be valid </li></ul><li>constrained optimization problem </li><ul><li>an optimization problem whose solution space is limited by a set of constraints </li></ul></ul>
  20. 20. Where To Eat? map of philly restaurants colored by price with constraint lines
  21. 21. Bringing It Back Let's bring this back to games. NOTE: In reality, the space of possible games with regard to fun is an erratic, discontinuous, non-linear, high-order multidimensional space far too complex to clearly represent with a single Venn diagram. For now, though, let's suspend our disbelief...
  22. 22. Games vs. Not Games venn diagram of games and not games
  23. 23. What Genres We're Familiar With venn diagram of game genres
  24. 24. What Our Demographic Will Buy venn diagram of our demographic
  25. 25. What We Are Willing To Make venn diagram of games we're willing to make
  26. 26. What We Have Manpower For venn diagram of games we have the manpower to make
  27. 27. What Does That Leave Us? <ul><li>A small subset of constraints
  28. 28. All of those are clear-cut and straightforward
  29. 29. Far fewer games left after satisfying all of them </li></ul>And we haven't even talked about FUN yet!
  30. 30. Fun Height Map height map of fun for tim
  31. 31. Different Fun Height Map height map of fun for someone else
  32. 32. No Way Out <ul><li>One more term: </li></ul>
  33. 33. No Way Out <ul><li>One more term:
  34. 34. over-constrained problem </li><ul><li>a constrained problem whose solution set is the empty set </li></ul></ul>
  35. 35. No Way Out <ul><li>One more term:
  36. 36. over-constrained problem </li><ul><li>a constrained problem whose solution set is the empty set </li></ul></ul>Over-constrained problems are where bad games come from
  37. 37. No Way Out Over-constrained problems are where bad games come from
  38. 38. Decision-Making <ul><li>Those diagrams were contrived to make things clearer
  39. 39. In reality, it's just really confusing
  40. 40. Where are the peaks and valleys of fun?
  41. 41. How much manpower do you need?
  42. 42. These are hard questions that you will be forced to answer </li></ul>
  43. 43. Decision-Making <ul><li>Every decision you make imposes constraints
  44. 44. Those constraints can lead you to make worse decisions
  45. 45. Eventually, you may end up in an </li></ul>over-constrained situation <ul><li>If so, chances are that you will </li></ul>ship a bad game or slip your date
  46. 46. Your Best Guess <ul><li>Decision-making early on is critical
  47. 47. Some are common to most games: </li><ul><li>2D, 3D, or some hybrid?
  48. 48. Which programming language?
  49. 49. Should we use Flash for our UI? </li></ul><li>You might rely on experience with past titles to make acceptable decisions </li></ul>
  50. 50. Your Best Guess <ul><li>Some are trickier
  51. 51. Example: Platformer Jumping Mechanic </li><ul><li>How far should the player be able to jump?
  52. 52. Should he be able to control himself mid-air?
  53. 53. How much and in which ways should he be able to control himself mid-air?
  54. 54. Does holding down the jump button control the jump in any way?
  55. 55. Should he have a double-jump? </li></ul></ul>
  56. 56. Your Best Guess <ul><li>If you're smart, you'll: </li><ul><li>Crunch numbers
  57. 57. Crawl the internet
  58. 58. Play similar games
  59. 59. Talk to peers/colleagues
  60. 60. Weigh your options carefully
  61. 61. ... </li></ul></ul>
  62. 62. Your Best Guess <ul><li>If you're smart, you'll: </li><ul><li>Crunch numbers
  63. 63. Crawl the internet
  64. 64. Play similar games
  65. 65. Talk to peers/colleagues
  66. 66. Weigh your options carefully
  67. 67. … and take a guess. </li></ul></ul>
  68. 68. Your Best Guess <ul><li>It's all you can do, there's nothing wrong with it
  69. 69. Some call guessing 'intuition' or 'design sense'
  70. 70. In the case of true innovation, </li></ul>there isn't a lot to go by, since it's something truly new TRUE INNOVATION --------->
  71. 71. A Process Of Iteration <ul><li>You can't rely on your first
  72. 72. guess to be correct every time </li><ul><li>Example: this guy guessed
  73. 73. this outfit would make him
  74. 74. look totally awesome </li></ul><li>Solving these problems is
  75. 75. better approached using an
  76. 76. iterative process </li></ul>
  77. 77. A Process Of Iteration <ul><li>The iterative process: </li><ul><li>Start with your best guess
  78. 78. Repeat: </li><ul><li>Identify problem
  79. 79. Hypothesize solution
  80. 80. Implement solution
  81. 81. Test </li></ul></ul></ul>
  82. 82. A Process Of Iteration <ul><li>There are some questions this process raises: </li><ul><li>How do we identify the next problem to solve?
  83. 83. How do we come up with a possible solution to the problem?
  84. 84. How do we know if the solution worked?
  85. 85. When do we stop iterating? </li></ul><li>Testing is the way we gather information pertinent to making good decisions about making games fun </li></ul>
  86. 86. What Kind of Testing? <ul><li>Let's clarify our terms: </li></ul>
  87. 87. What Kind of Testing? <ul><li>Let's clarify our terms: </li><ul><li>Beta Test - Test a product to identify defects after the product has been realized, but before it goes to market </li></ul></ul>
  88. 88. What Kind of Testing? <ul><li>Let's clarify our terms: </li><ul><li>Beta Test - Test a product to identify defects after the product has been realized, but before it goes to market
  89. 89. Focus Test - Test a product to gain information about how it will be perceived by a group representative of your target demographic(s) </li></ul></ul>
  90. 90. What Kind of Testing? <ul><li>Let's clarify our terms: </li><ul><li>Beta Test - Test a product to identify defects after the product has been realized, but before it goes to market
  91. 91. Focus Test - Test a product to gain information about how it will be perceived by a group representative of your target demographic(s)
  92. 92. Play Test - Test a product to gain information about the gameplay experience </li></ul></ul>
  93. 93. Please Test Your Games <ul><li>This is a plea from me to you!
  94. 94. Please test your games as early and often as possible
  95. 95. Making games without play testing is like playing a game of Mastermind without ever being told how close you were
  96. 96. You just don't have enough information to predict fun innovations without testing </li></ul>
  97. 97. Please Test Your Games <ul><li>Case In Point: Jamestown </li><ul><li>Weapon-switching mechanic
  98. 98. Camera system
  99. 99. Zoomed-in perspective </li></ul><li>All of these looked great on paper
  100. 100. Your brain will fill in design holes with optimism and false confidence
  101. 101. We've learned that no idea is certain to be fun! </li></ul>
  102. 102. Please Test Your Games <ul><li>Never commit to an innovative game whose central innovation has not been tested
  103. 103. It may not seem like it, but it is reckless and risky
  104. 104. We have a term: playtest-positive </li><ul><li>When a feature is consistently enjoyed by playtesters during testing </li></ul><li>For core features, we don't commit until the feature is playtest-positive </li></ul>
  105. 105. Mid-Game Recap <ul><li>Hopefully, this make sense to you: </li><ul><li>“Finding the Fun” is an optimization problem
  106. 106. Our decisions create constraints that limit our solution space
  107. 107. Thus we must take care to make good decisions
  108. 108. Iteration lets us fix our best guesses until we are confident in them
  109. 109. Testing helps us gain the information we need to efficiently fix our best guesses </li></ul></ul>
  110. 110. Prototyping
  111. 111. What is Prototyping? <ul><li>“Prototype” is a word with many definitions
  112. 112. A gameplay prototype is not a “quick and dirty version of the game” </li><ul><li>The motivation for a prototype comes from our iteration process before
  113. 113. The more rapidly we iterate on a feature, the more iterations we will achieve per unit time
  114. 114. Each iteration improves the feature
  115. 115. Thus, we want to keep iteration time short </li></ul></ul>
  116. 116. What is Prototyping? <ul><li>My definition: A prototype is a version of the gameplay upon which you can iterate quickly </li><ul><li>The goal is not to have a game you can ship
  117. 117. The goal is to gather information and find the fun as quickly as possible
  118. 118. Once you have found it, you can port your findings back into your game with a high degree of confidence </li></ul></ul>
  119. 119. Prototypes Can Be Analog <ul><li>It doesn't need to be in-engine, in-game, or even a piece of software – choose the right tool! </li></ul><ul><li>Some mechanics (such as social gameplay) can be worked out with cardboard and scissors </li></ul>
  120. 120. Prototypes Can Take A While <ul><li>The initial prototype can even take a while to create, if it leads to sufficiently rapid iteration </li><ul><li>Example: Physics programming in Booty Blocks </li><ul><li>Worked out a Python version of the physics gameplay, and then iterated on it in Windows
  121. 121. Iterating on it via the iPhone SDK couldn't compete with the real-time feedback of Python on Windows
  122. 122. Overall it was a massive time savings
  123. 123. The Python version of the game had far fewer constraints on it, so it was easier to experiment with different approaches quickly </li></ul></ul></ul>
  124. 124. Prototypes Can Remove Constraints <ul><li>Temporarily removes constraints and overhead from your development process </li><ul><li>Modern game development involves editors, build pipelines, dev kits, million-line engines
  125. 125. Much of this is extraneous to gathering the information you want
  126. 126. A simple prototype can eliminate those details when you need to, and lets you focus on the specific problem at hand </li></ul></ul>
  127. 127. Prototypes Let You Test Early <ul><li>Gives you something testable early on
  128. 128. Even if you don't have a game ready, you have something you can test and gain valuable information from
  129. 129. Dodging bullets cheaply
  130. 130. early on can save an
  131. 131. entire project </li></ul>
  132. 132. Prototypes Can Be Blind (Like Justice) <ul><li>Blind Prototype </li><ul><li>We prototyped the core Jamestown gameplay while only implementing visuals critical for player feedback
  133. 133. The idea was that we could integrate art into the game once we had the fun
  134. 134. This removed artistic manpower and schedule as a constraint </li></ul></ul>
  135. 135. Prototypes Can Be Blind (Like Justice) Blind Prototype Visual Prototype Final Gameplay
  136. 136. Prototypes Can Be A Touchstone <ul><li>Touchstone </li><ul><li>Having a prototype of a feature in any form offers a touchstone for design discussions
  137. 137. Simple prototypes can help solve problems even if they don't implement the feature fully
  138. 138. Even partial information gives you a foundation on which to base discussion </li></ul></ul>
  139. 139. Prototypes Aren't The Game <ul><li>You'll hear this a lot, but it's nuanced
  140. 140. Prototype isn't a synonym for “incomplete version of the game”
  141. 141. You can play with an idea in an entirely different context, and gain a huge amount of insight into its challenges and complexity
  142. 142. As you learn more about it, you can start making prototypes that are more integrated into the complete experience </li></ul>
  143. 143. Recap On Prototyping <ul><li>Let's recap: </li><ul><li>The goal is to iterate quickly
  144. 144. Gives you something you can test, and thus get information from
  145. 145. Serves as a touchstone
  146. 146. Removes unnecessary constraints on the development process
  147. 147. Some good gameplay prototyping frameworks: </li><ul><li>Paper + pencil + scissors + foil
  148. 148. Flash
  149. 149. PyGame
  150. 150. SDL/OpenGL
  151. 151. XNA </li></ul></ul></ul>
  152. 152. But That's Not All! <ul><li>The last thing I want to cover is how different kinds of developers can apply the prototyping process to their work </li><ul><li>3D Visual Artists
  153. 153. Audio Artists
  154. 154. Graphic Designers
  155. 155. Programmers
  156. 156. Others! </li></ul></ul>
  157. 157. Prototyping For Visual Artists <ul><li>3D Visual Artists </li><ul><li>Often referred to as a “mockup”, but the idea is the same: </li><ul><li>Iterate quickly so you can get a better product </li></ul><li>Model and texture rough gameplay elements
  158. 158. Put them together into a scene
  159. 159. Try varying the size and number of the various elements to figure out the ideal composition
  160. 160. Explore possible cameras that may work </li></ul></ul>
  161. 161. Prototyping For Visual Artists <ul><li>Post-processing and Effects </li><ul><li>Render to an image and pull it up in Photoshop
  162. 162. Paint particle effects over the render
  163. 163. Apply filters to achieve effects such as bloom
  164. 164. Iterate on these with fellow artist's feedback as testing
  165. 165. Talk with programmers about how to get it in the game
  166. 166. Use the prototype (mockup) as a touchstone </li></ul></ul>
  167. 167. Prototyping For Audio Artists <ul><li>Audio Artists </li><ul><li>Play the game and improvise music on top of it as it plays
  168. 168. Create sound effects and queue them up in a test project to play intermittently while you play the game
  169. 169. The sound guy actually did this on Booty Blocks, and within hours of our initial audio integration we had polished audio that was very close to final </li></ul></ul>
  170. 170. Prototyping For Graphic Designers <ul><li>Graphic Designers </li><ul><li>Often done, also referred to as “mockups”
  171. 171. Motion graphics in Flash or After Effects
  172. 172. Interface and UI in Flash/Illustrator/Photoshop
  173. 173. Can test and iterate on usability in Flash without any of the game in place
  174. 174. On Booty Blocks and Jamestown, the animations for HUD feedback were prototyped in Flash, iterated on, and then rapidly ported into the UI engine (not Flash) </li></ul></ul>
  175. 175. Prototyping For Programmers <ul><li>Programmers </li><ul><li>If you are trying to integrate a black box library, do it first in a simple prototype app, and then use the experience to do it right in the real app
  176. 176. Don't be afraid to throw away code; you'll do it anyways
  177. 177. Having a killer mechanic you know is fun is worth nearly any amount of wasted code
  178. 178. When writing a complex core system, iterate on a simple version to figure out a good approach </li></ul></ul>
  179. 179. Don't Be Afraid! <ul><li>It's a big step for a developer to switch to a prototype-based iterative development process
  180. 180. It may seem risky to spend time on prototyping
  181. 181. The bigger risk is making an important but irrevocable decision without enough information </li></ul>Give it a try, you won't be sorry!
  182. 182. In Conclusion <ul><li>Game development is a series of optimization problems
  183. 183. Prototypes and playtests can be used to reduce risk and improve decision-making
  184. 184. In the end, what matters is a commitment to creating something testable and iterating on it
  185. 185. The rest is optimization! </li></ul>
  186. 186. Questions and Answers(?) <ul><li>Hopefully this presentation has generated a few questions!
  187. 187. Feel free to ask them now, or email them to me after the talk: </li><ul><li>[email_address] </li></ul><li>Follow us on Twitter: </li><ul><li>@finalformgames </li></ul><li>Slides are available upon request
  188. 188. Thank you! </li></ul>