Download as PDF, PPTX
![Mocking
2013-05-19 19:36:29,980 -[INFO] -from applicationMOCK MAILER: send email
2013-05-19 19:36:29,982 -[INFO] -from applicationFROM:"yourfone.deCampus Buddies" <keineantwort@campus-buddies.de>
2013-05-19 19:36:29,983 -[INFO] -from applicationTO:"Nick" <mail@npruehs.de>
2013-05-19 19:36:29,985 -[INFO] -from applicationTEXT:
<html> <head> <title> ...
65 / 113](https://image.slidesharecdn.com/gamedevelopmentchallenges-141125041310-conversion-gate01/75/Game-Development-Challenges-65-2048.jpg)
Uploaded byNick Pruehs
Game Development Challenges
This document discusses challenges in game development based on Nick Prühs' experience. It covers the diversity of game types and roles involved in development. It also discusses art pipelines, game engines, physics examples, and lessons learned from developing the "Campus Buddies" social game. Key lessons include expecting API changes, using existing solutions, making testing and deployment easy, mocking network interactions, standardizing code style, using a feature-based project structure, prioritizing collaboration, listening to players, implementing tutorials, considering 2D animation, and addressing challenges with localization.
More Related Content
Similar to Game Development Challenges
![Vibe Coding vs. Spec-Driven Development [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/vibecodingvsspecdrivendevelopment-251209105622-43f455e7-thumbnail.jpg?width=640&height=640&fit=bounds)
Game Development Challenges
- 1. Game Development Challenges Nick Prühs
- 2. About Me “BestBachelor“ComputerScience KielUniversity,2009 MasterGames HamburgUniversityofAppliedSciences,2011 LeadProgrammer DaedalicEntertainment,2011-2012 Co-Founder slashgames,2013 2 / 113
- 3. Diversity of Games 3 / 113
- 4. Diversity of Games 4 / 113
- 5. Diversity of Games 5 / 113
- 6. Diversity of Games 6 / 113
- 7. Diversity of Games 7 / 113
- 8. Diversity of Games 8 / 113
- 9. Diversity of Games 9 / 113
- 10. Game Development Roles Programming 10 / 113
- 11. Game Development Roles 2D Art 11 / 113
- 12. Game Development Roles 3D Art 12 / 113
- 13. Game Development Roles Game Design 13 / 113
- 14. Game Development Roles Sound Design 14 / 113
- 15. Game Development Roles Cinematic Art 15 / 113
- 16. Game Development Roles Game Author 16 / 113
- 17. Game Development Roles Level Designer 17 / 113
- 18. Game Development Roles Technical Artist 18 / 113
- 19. Game Development Roles Localization 19 / 113
- 20. Game Development Roles Producer 20 / 113
- 21. Game Development Roles QA & Support 21 / 113
- 22. Game Development Roles Marketing 22 / 113
- 23. Game Development Roles PR 23 / 113
- 24. Game Development Roles Community Management 24 / 113
- 25. Game Development Roles Analytics 25 / 113
- 26. Art Pipelines 26/ 113
- 27. Art Pipelines 27/ 113
- 28. Art Pipelines 28/ 113
- 29. Art Pipelines 29/ 113
- 30. Game Engines 30/ 113
- 31. Game Engines 31/ 113
- 32. Game Engines 32/ 113
- 33. Game Engines 33/ 113
- 34. Game Engines 34/ 113
- 35. Example: Physics 35/ 113
- 36. Example: Physics 36/ 113
- 37. Example: Physics 37/ 113 −휖푣퐴퐵푛 = 푣퐴퐵 ′푛 definition coefficient of restitution = (푣퐴′ −푣퐵′ )푛 definition relativevelocity = (푣퐴+ 푗 푀퐴 푛−푣퐵+ 푗 푀퐵 푛)푛 definition collision impulse = 푣퐴푛+ 푗 푀퐴 푛푛−푣퐵푛+ 푗 푀퐵 푛푛 distribution = 푣퐴푛−푣퐵푛+ 푗 푀퐴 푛푛+ 푗 푀퐵 푛푛 commutativeproperty = 푣퐴퐵푛+ 푗 푀퐴 푛푛+ 푗 푀퐵 푛푛 definition relativevelocity
- 38. Lessons Learned 38/ 113
- 39. Campus Buddies 39/ 113
- 40. Campus Buddies 40/ 113
- 41. Campus Buddies 41/ 113
- 42. Campus Buddies 42/ 113
- 43. Campus BuddiesFeatures •Sharingads using multiple channels (Email, Facebook, Twitter, Google+) •Lead verification as specified by Yourfone •Authentication by different providers (username/password, Facebook) •Classical gamification mechanics (achievements, level ups, …) •Periodic competitions resolved by the server •Dynamic news stream •Full moderation backend •Responsive mobile version •Facebook OpenGraph integration •Friend referral program •Customized reportings •Secure reward shop •Stateless Scalable Web Application •SSL-Encryption 43 / 113
- 44. Campus BuddiesFeatures 44/ 113 Development Scope 10 Weeks
- 45. Lessons Learned 45/ 113
- 46. Gotcha! LESSON 1: ExpectchangesofexternalAPIs! 46 / 113
- 47. External APIs 47/ 113 •Integrated three of the major social platforms: Facebook, Twitter and Google+ •During the development process, both Facebook and Google+ changed their APIs… •… effectively turning some of our code into useless rubbish •Took about a day or two to get everything up and running again
- 48. External APIs 48/ 113
- 49. External APIs 49/ 113 •Talking to other web developers, we learned that social platform providers tend to change their APIs regularly •They won’t notify you about that. •Neither before, nor after. •Never.
- 50. Hint LESSON 2: Avoiddoingeverythingyourself! 50 / 113
- 51. Don’t Reinvent TheWheel 51 / 113 •Got a problem that is not exactly related to just your application? •Maybe someone else has already solved it. •There’s lots of smart people having spent tens of hundreds of hours on your problem. •Use that knowledge!
- 52. Don’t Reinvent TheWheel 52 / 113
- 53. Hint LESSON 3: Maketestingaseasy aspossible! 53 / 113
- 54. Make testing easy! 54 / 113 Atthebeginningoftheproject,Christianhadtheideaofcreatingadebugwebpagecontaininglinksforseveraldebugfunctions •creating and logging in a test user •adding points for the current user •unlocking achievements •and many, many more
- 55. Make testing easy! 55 / 113
- 56. Make testing easy! 56 / 113 This was arguably the best idea we had throughout the project.
- 57. Make testing easy! 57 / 113 •Debugging can be a pain in the ass •especially when network communication is involved •Our debug page saved us lots of blood, sweat and tears •The earlier you set up your debugging tools, the more you’ll benefit from them
- 58. Hint LESSON 4: Makedeploymentaseasy aspossible! 58 / 113
- 59. Deploy often! 59/ 113 Creating a new version can involve a step or two: •Accessing source control •Syncing working copy •Creating tags •Writing version numbers •Performing the actual build •Packaging the build result •Publishing the game on a build page •Running unit tests •Sending email notifications
- 60. Deploy often! 60/ 113
- 61. Deploy often! Youwouldn’t wanna do all that by hand. Every time. Do you? 61 / 113
- 62. Campus BuddiesLessons Learned 62 / 113
- 63. Hint LESSON 5: Mock networkinteractionfortesting! 63 / 113
- 64. Mocking •Everything thatinvolves network communication is annoying to test. •Wemockedparts of the remote interaction of our application •sending e-mails •verifying leads •Whenever a mail was sent, it was written to the console instead, for instance. 64 / 113
- 65. Mocking 2013-05-19 19:36:29,980-[INFO] -from applicationMOCK MAILER: send email 2013-05-19 19:36:29,982 -[INFO] -from applicationFROM:"yourfone.deCampus Buddies" <keineantwort@campus-buddies.de> 2013-05-19 19:36:29,983 -[INFO] -from applicationTO:"Nick" <mail@npruehs.de> 2013-05-19 19:36:29,985 -[INFO] -from applicationTEXT: <html> <head> <title> ... 65 / 113
- 66.
- 67. Campus BuddiesLessons Learned 67 / 113
- 68. Gotcha! LESSON 6: Standardizeyourcodestyle! 68 / 113
- 69. Consistent Code Style •If you aren’t alone (and I sincerely hope you’re not), you’ll want to standardize your code styles. •Be clear about tiny details such as tabs vs. spaces •greatly increases maintainability •reduces the number of merge conflicts 69 / 113
- 70. Merge Conflict 70/ 113
- 71.
- 72.
- 73. Eclipse 73 /113
- 74. Eclipse 74 /113
- 75. Lessons Learned 75/ 113
- 76.
- 77.
- 78.
- 79.
- 80. FreudBot Features •46levels, 17 animated characters, 10 screens, 137 cards, 4 comics, 10 000 words, 45 sounds •Dedicated website and social media channels •Multiple ad providers and in-app purchases •Fully localized to five different languages •Full analytics integration •Cloud savegames •Native mobile features (loading screen, snap mode, suspend, charms, toasts) •Marketing (fan art, card contest, trailer, contests) •Multi-platform release on iOS, Android, Windows Store, Windows Phone (Windows and Mac to come) 80 / 113
- 81. Lessons Learned 81/ 113
- 82. Hint LESSON 1: Usea feature-basedprojectstructure! 82 / 113
- 83. Feature Folders •ProjectRoot •FingerGestures •FreudBot •HOTween •NGUI •NData •Unity Test Tools 83 / 113
- 84. Feature Folders •ProjectRoot •FingerGestures •FreudBot •Animations •Atlases •Fonts •Localization •Prefabs •Scenes •Sounds •Sprites •Scripts •HOTween •NGUI •NData •Unity Test Tools 84 / 113
- 85. Feature Folders •ProjectRoot •FreudBot •Scripts •Ads •Analytics •Comics •Core •Debug •Dialogue •IAP •Mobile •Progression •Sound •UI 85 / 113
- 86. Feature Folders •ProjectRoot •FreudBot •Scripts •Ads •Components •Events •Systems 86 / 113
- 87. Feature Folders Thisway, features and plugins can easily be updated or removed without having to scan the full project tree. 87 / 113
- 88. Hint LESSON 2: Collaborationfirst! 88 / 113
- 89.
- 90. Collaborationfirst! Excel CSV XML Game 90 / 113
- 91. Collaborationfirst! Excel CSV XML Game 91 / 113
- 92. FreudBotLessons Learned Leteveryone work with the tools they’re most experienced with, and provide a tool chain for data conversion as soon as possible. 92 / 113
- 93. Hint LESSON 3: Listen toyourplayers! 93 / 113
- 94.
- 95.
- 96. Analytics 96 /113 This is okay. (Endboss)
- 97. Analytics 97 /113 This is not. (Intermediate level)
- 98. Gotcha! LESSON 4: Don‘tforgetthetutorial! 98 / 113
- 99.
- 100. Tutorials •Have playerstest your game early on •Don’t talk, just watch and listen. •Don’t underestimate the time required for implementing your tutorial. It introduces many special cases, such as •Prohibiting player actions (e.g. use ability, end turn) •Triggering unusual events (e.g. let turn timers expire) •TweeningUI in step by step •Providing fixed outcomes (e.g. always same card hand) 100 / 113
- 101. Hint LESSON 5: There‘s2D skeletalanimation! 101 / 113
- 102. Spine 102 /113
- 103. Spine Atlas Image 103 / 113
- 104. Spine Atlas File 104 / 113
- 105. Spine Animation File 105 / 113
- 106.
- 107. Gotcha! LESSON 6: Localizationisa bitch! 107 / 113
- 108.
- 109. Localization Pipeline 109/ 113 Game XML CSV Excel CSV XML
- 110. Localization Best Practice •Use unique, immutable localization keys •Changing any localization keys will invalidate any sheets handed out to your localization team •Highlight new texts, changed texts •These additional texts will have to be localized later •Provide a playable version of your game, as well as rich background information (e.g. characters, places) •People need to know the game before they can localize it. •Allow instant integration of the localized texts, if possible •Localization team can check for encoding issues, overlapping labels, missing texts immediately 110 / 113
- 111. And there ismore… •Learn from others! •Stick to your plan! •Build prototypes! •Use automatic testing! •Setup proper version control workflows! 111 / 113
- 112. And there ismore… •Learn from others! •Stick to your plan! •Build prototypes! •Use automatic testing! •Setup proper version control workflows! See Game Programminghttp://www.npruehs.de/teaching/game-programming/ Monday, 8.30 am, E 45 112 / 113
- 113. Thankyouforyourattention! Contact Mail dev@npruehs.de Blog http://www.npruehs.de Twitter @npruehs Github https://github.com/npruehs 113 / 113