somewhatspecial

Mirishita 2019 CEDEC conference slides

Oct 4th, 2019
556
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. This is a rough translation of Mirishita's CEDEC conference presentation slides. This should give you a good understanding of how Mirishita's design philosophy and software design/architecture works.
  2.  
  3. While I do have some background on software engineering, I admit that technical terms are not my strong suit, so I apologize in advance for any errors. Regardless, do enjoy!
  4.  
  5. Also, be sure to refer to the slides when reading this as well.
  6.  
  7.  
  8.  
  9. _______________________________________________________________________________________________________________________________________
  10. Mirishita Management Techniques!!!
  11.  
  12.  
  13. - About this Session
  14. - Contents:
  15. - Introducing the Mirishita Engineer Team's management guidelines and examples of practical application
  16. - Session Targets:
  17. - Engineers with experience developing, operating management titles (games which are constantly updated rather than a single release)
  18. - Engineers involved with management titles
  19. - People interested in Mirishita's Engineer team
  20.  
  21.  
  22. - Session Contents:
  23. - Engineers' initiatives
  24. - Server-side initiatives
  25. - Engineers' challenges
  26.  
  27.  
  28. _______________________________________________________________________________________________________________________________________
  29. Engineers' Initiatives
  30. For the sake of stable operations
  31.  
  32.  
  33. - Self-introduction:
  34. - Sasaki Katsushi (佐々木 克)
  35. - Bandai Namco Studio - Programmer
  36. - Mirishita Client-side Engineer
  37.  
  38.  
  39. - Management team structure:
  40. - Total team size: >100 people
  41. - Engineers: ~30 people
  42.  
  43.  
  44. - Our mission:
  45. - Implement the specifications of functions and ideas based on commercial strategies that are always aware of user needs via engineering, and release them with stable quality and in proper cycles.
  46.  
  47.  
  48. - Definition of Stability:
  49. - Don't stop service
  50. - No bugs in the updates
  51. - Progression according to schedule
  52.  
  53.  
  54. - How long does it take for a song to be released?
  55. - About 6 months for a new song!
  56.  
  57. - 6 months before:
  58. - Unit (and song) concept is decided.
  59. - 4 months before:
  60. - Production plan decided
  61. - Progamming begins
  62. - Performance data is prepared
  63. - 3 months before:
  64. - Motion capture
  65. - 2 months before:
  66. - Finish programming
  67. - Production work begins
  68. - 3 weeks before:
  69. - FIX
  70. - 2 weeks before:
  71. - Begin testing
  72. - Release
  73.  
  74.  
  75. - About 4-5 songs release every month
  76. - Platinum Star Theater
  77. - Main Scenario (Commu)
  78. - Platinum Star Tour
  79. - Main Scenario (Commu)
  80. - ?
  81.  
  82.  
  83. - The Premise
  84. - Client updates take time
  85. - Systematic progress is essential
  86.  
  87.  
  88. - Engineer Guidelines 1:
  89. - 80% Rule: If you have 7.5 hours, use 6 hours to program
  90.  
  91.  
  92. - Reasons for 80%
  93. - Emergency support
  94. - Investigation of errors
  95. - Responding to requests of users
  96. - Others
  97. - Refresh (they need to take breaks too lol)
  98. - Technical research
  99.  
  100.  
  101. - Engineer Guidelines 2:
  102. - The schedule is of the utmost priority
  103.  
  104.  
  105. - For the Schedule's sake
  106. - Grasp the mid-to-long term plans before determining the points that absolutely cannot be left out
  107. - Proposal of a test-driven schedule that is reliable and sustainable
  108. - Must have a thorough understanding of the test schedules' evaluation criteria
  109.  
  110.  
  111. - What if we can't ensure testing time?
  112. - Send it off unsullied
  113. - Don't include any riskier updates
  114. - Volume adjustments
  115. - Whole team will help to shrink features
  116.  
  117.  
  118. - What if, after all that, we can't do it and it's no good?
  119. - We do our best and implement it
  120. - Use a Boost (lol)
  121. - Cannot be conservative with updates
  122.  
  123. _______________________________________________________________________________________________________________________________________
  124. Server-side Initiatives
  125. For the sake of stable operations
  126.  
  127.  
  128. - Self-introduction
  129. - Hoshina Kazunari (保科 一成)
  130. - Bandai Namco Studio - Programmer
  131. - Mirishita Server-side Engineer
  132.  
  133. - Server-side Guideline
  134. - Ensure the maximum possible time for gameplay
  135.  
  136.  
  137. - For the sake of maximizing gameplay time
  138. - In order to never stop:
  139. - Ensure sufficient capacity
  140. - Scaling
  141. - Do not create even a single point for malfunctions
  142. - Never cause a problem that requires emergency maintenance
  143. - In order to reduce the amount of time needed to stop:
  144. - Shorten the regaular maintenance period
  145. - Resolve issues without stopping the game
  146. - Be able to switch back on the spot
  147.  
  148.  
  149. - Types of Maintenance
  150. - Regular maintenance
  151. - Backups
  152. - Changing of database schema
  153. - OS and middleware update
  154. - Waiting for client updates
  155. - Emergency maintenance
  156. - Infrastructure failures
  157. - Fatal bugs
  158.  
  159. - Mirishita and Maintenance
  160. - Ever since we opened on June 2017, the game has never stopped even once for maintenance
  161. - There have been some parts that have stopped due to failure
  162. - Can do maintenance on certain functions
  163.  
  164. - Mirishita's Server
  165. - Google Cloud Platform: We employ Google App Engine (GAE)
  166. - For more info, search "The GAE/Go that supports Mirishita"
  167. *(Is a seperate presentation, https://www.slideshare.net/GoogleCloudPlatformJP/gaego-80349110)
  168.  
  169.  
  170. - Characteristics of GAE
  171. - High availability
  172. - A standard decentralized configuration, so not likely for trouble to occur
  173. - Scaling efficiency
  174. - The servers can be started in seconds, so only need to do scaling at moments with heavy load
  175. - High capacity
  176. - Can bear around 10,000 requests per second (in Mirishita's case)
  177. - Fully managed
  178. - Can scale automatically according to the number of requests and amount of data
  179.  
  180.  
  181. - Back to Types of Maintenance...
  182. - Regular maintenance
  183. - Backups (Can run without stopping)
  184. - Changing of database schema (No need)
  185. - OS and middleware update (No need)
  186. - Waiting for client updates
  187. - Emergency maintenance
  188. - Infrastructure failures (Reduced)
  189. - Fatal bugs
  190.  
  191. - Maintenance for the sake of updating the Client
  192. - If the server and client versions don't match and it can't operate (Incompatible), must enter maintenance in order to wait for a new client update
  193. - Even if the store releases a new client, not all users can download it - restriction
  194. - How does Mirishita solve this?
  195.  
  196. - Do our best to preserve backwards compatibility (For the sake of Client updates)
  197. - The server supports both old and new clients
  198. - Before a new client is released, update the server first so that you can download it immediately upon entering the store
  199.  
  200.  
  201. - Handling bugs
  202. - When bugs occur in the production environment, in certain cases the whole game needs to be stopped to perform maintenance to prevent the damage from spreading
  203. - Very important to detect bugs before they occur
  204. - How does Mirishita solve this?
  205.  
  206. - Do our absolute best to test (Ensure no bugs come out)
  207. - Bring our test environment closer to the production environment
  208. - Move server configuration closer
  209. - GAE can make test configurations the same as the production one
  210. - Different security settings
  211. - Reduce the amount of data
  212. - Function to create dummy data
  213. - Move the settings closer
  214. - The settings differ based on environment, bring it closer step by step
  215.  
  216.  
  217. - Production Environment Update Flow (refer to the diagram here for illustration)
  218. - Update production environment from V1 to V2
  219. - Test with a combination of the V2 Client and V2 Server (Development)
  220. - Test with a combination of the V2 Client and V2 Server (Staging)
  221. - Test with a combination of V1 Client and V2 Server (Staging)
  222. - Test with a combination of the V2 Client and V2 Server (Production)
  223. - Since iOS requires a store review, submit V2
  224. - Now all Clients use the V2 Server
  225.  
  226.  
  227. - Test Environment
  228. - Step-by-step application
  229. - Test using different Client and Server versions
  230. - Fill in the gaps from Production-side
  231. - Test in Production environment
  232. - A debugging user exists, invisible to other users
  233. - Testing future features
  234.  
  235.  
  236. - Bug handling
  237. - January 2018: Players' scores were not recorded in the Ranking
  238. 1. Notify users after discovery
  239. 2. Confirm a fix in the Test environment
  240. 3. Apply the modifications to the Production environment while application is still running
  241. 4. While operating, restore the rankings from the Play Log
  242.  
  243.  
  244. - July 2017: Setting error that prevented users from returning to the Home screen
  245. 1. Perform an immediate version switch-back
  246. 2. Inform users
  247. 3. Confirm a fix in the Test environment
  248. 4. Apply fix to Production environment
  249.  
  250. - Detailed Action Log
  251. - If we have a detailed log of a user's selections, stats, used and earned items, etc., there is a very high chance that we can restore their state later.
  252. - Rollback function
  253. - Most dangerous after new deployment, so be prepared to roll-back to the immediate previous state
  254.  
  255. - January 2019: A bug where displayed items could only be purchased once in the Item Shop
  256. 1. Perform maintenance on the Shop function, inform users
  257. 2. Confirm a fix in the Test environment
  258. 3. Apply the modifications to the Production environment while application is still running
  259. 4. Re-open the Shop function
  260.  
  261.  
  262. - For the sake of maximizing possible play time
  263. - Server layout
  264. - High availability architecture
  265. - Test environment
  266. - To reduce the gap between Test and Production environment
  267. - Handling bugs
  268. - Prepare and exploring for ways to do it without stopping the game
  269.  
  270.  
  271. - This does not mean no maintenance
  272. - There is no value in no maintenance
  273. - If so, when maintenance is really required, our judgement would be less capable
  274. - Is a factor that can hinder challenge
  275. - Always aim for high user value
  276. - To continue playing with a peace of mind
  277. - To always deliver new content
  278.  
  279. _______________________________________________________________________________________________________________________________________
  280. Engineers' challenge
  281. To surprise the users
  282.  
  283.  
  284. - Self-introduction
  285. - Hayato Ikeda (池田 早人)
  286. - Bandai Namco Studio - Programmer
  287. - Mirishita Client Engineer
  288.  
  289.  
  290. - Recall Our mission:
  291. - Implement the specifications of functions and ideas based on commercial strategies that are always aware of user needs via engineering, and release them with stable quality and in proper cycles.
  292.  
  293. - Further mission:
  294. - Always with a spirit of challenge, implement and deliver surprises that will exceed a user's expectations
  295. - That is to say:
  296. - Because there is "stability", the challenges we take on will always be connected to the element of "surprise"
  297.  
  298.  
  299. - For the sake of surprising the users
  300. - Have an environment that can challenge us
  301. - Constantly pursue intellectual curiosity
  302. - Share ideas among one another
  303.  
  304. - What does it mean to surprise the users?
  305. - Do something you would never think about
  306. - Even if you did think about it, do what you still haven't done yet
  307.  
  308.  
  309. - Case studies:
  310. 1. 13-Man Lives
  311. 2. Mirishita Kanshasai (Thanksgiving Festival)
  312. 3. TEAM_UMIMI
  313.  
  314.  
  315. - What is 13-Man Live?
  316. - A new mode added in April 2018
  317. - Increasing the number of idols rendered on stage from 5 to 13
  318.  
  319.  
  320. - Technical background
  321. - Before release, the AKANE Great Strategy (refer to my previous translation of the Unite 2018 slides) was performed.
  322. - Implemented in the Test mode
  323. - Improved terminal performance
  324.  
  325.  
  326. - Surprise from the project members
  327. - The impact of the test display was very large
  328. - Increased the unity of all the project members
  329. - Able to add more function in a short time period
  330.  
  331. - Surprise from the users
  332. - The impact of 5 to 13 members on stage during the teaser trailer was very large
  333. - A short time period of 3 months to add the new mode
  334. - Added 13 costumes at the same time
  335. - Now, 13-Man Lives are regularly added
  336.  
  337.  
  338. - What is the Mirishita Kanshasai?
  339. - A special Live Event that took place in October 2018
  340. - Had a special in-game livestream that many users could enjoy at once
  341.  
  342. - Technical background
  343. - Studying of video playback methods and constructing a test environment
  344. - Cooperated with Bandai Namco Rights Marketing
  345. - Implementation of the chat, stamps and survey functions
  346. - Conducted thorough testing for this one-shot feature
  347.  
  348. - Surprise from the project members
  349. - Various ideas came out in the first attempt
  350. - Possible to play live video from within the app
  351. - Might as well do it in a vociferous manner
  352. - A positive spiral of ideas and implementation
  353.  
  354. - Surprise from the users
  355. - Surprising that real-time livestreaming could be done from within the app
  356. - Stable servers
  357. - Various real-time functions implemented:
  358. - Chat
  359. - Stamps
  360. - Surveys
  361. - The birthday button (remember the Chizuru skit?)
  362.  
  363. - Feelings of Thanksgiving toward the users
  364. - Present of the Official Pamphlet
  365. - Also implemented a stream archive
  366. - "We should be the ones. Thank you."
  367.  
  368.  
  369. - What is TEAM_UMIMI?
  370. - Technical research project
  371. - Using Mirishita to perform technical research!
  372. - Effective use of the 80% rule
  373. - UMIMI is an acronym
  374.  
  375. - What's UMIMI?
  376. - Ultimate MIllion Live wo MIseteyaru!
  377. - A team to show off the Ultimate Million Live
  378.  
  379. - Are you surprised?
  380. - We don't have anything we can show you today, but stay tuned... I think you'll be surprised
  381. - Look forward to any future updates!
  382. - Continues Challenging!
  383.  
  384.  
  385. - Engineers' challenge
  386. - Challenges are built on a foundation of stability
  387. - (Good techniques + Proper measures) = Surprise from the users
  388. - Aim for that positive spiral
  389. - Continue to take on challenges
  390.  
  391.  
  392. - So what are Mirishita's management techniques?
  393. - Stability & Surprise
  394.  
  395. - Thank you very much!
RAW Paste Data