Divine Beats – Night at the Monastery Alternative Beat Map Representation in Music Rhythm Games
by Ingrid Wu
Thesis Instructor: Marko Tandefelt Thesis Writing Instructor: Loretta J. Wolozin
A thesis document submitted in partial fulfillment of the requirements for the degree of Master of Fine Arts in Design and Technology Parsons The New School for Design May 2010
©2010 Ingrid Wu ALL RIGHTS RESERVED
2 Abstract
“Divine Beats – Night at the Monastery” is a music rhythm game about a drummer’s adventure as he works with a monk on an exorcism quest. The game aims to convey beat map data to the players without using the traditional heads‐up display.
3 Table of Content
ABSTRACT∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 3
TABLE OF CONTENT∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 4
LIST OF ILLUSTRATIONS ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 6
CHAPTER 1 ‐ INTRODUCTION∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 7
1.1. CONCEPT∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 7 1.2. IMPETUS AND MOTIVATION ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 7 1.3. SIGNIFICANCE∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 8 1.4. DESIGN QUESTIONS ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 8 1.5. AUDIENCE ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 9 1.6. FINAL PRODUCT ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 9
CHAPTER 2 ‐ DOMAIN AND PRECEDENT∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙10
2.1. DOMAINS∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙10 2.1.1. GAME DESIGN ‐ MUSIC RHYTHM GAMES ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙10 2.1.1.1. Beat Map Data and Representation∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙11 2.1.1.2. Beat Mark Graphics vs. Game Environment∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙12 2.1.2. GAME DESIGN – INTERFACE DESIGN ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙15 2.2. PRECEDENT: FURTHER ANALYSIS RELATED TO THESIS∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙17 2.2.1. RHYTHM HEAVEN∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙17 2.2.2. VIB RIBBON∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙18 2.2.3. PRINCESS∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙19
CHAPTER 3 ‐ METHODOLOGY ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙20
3.1. PROTOTYPE OVERVIEW ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙20 3.1.1. DIVINE BEATS‐ DRIVE AWAY THE BEAST ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙20 3.1.2. BASKETBALL DRILL∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙21 3.1.3. CHUCK AND CHERRI∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙22 3.1.4. DIVINE BEATS – NIGHT AT THE MONASTERY (DB‐NM)∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙23 3.2. DESIGN DECISIONS ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙24
4 3.2.1. PLATFORM CHOICE∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙24 3.2.2. GAMEPLAY MECHANIC∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙24 3.2.3. NARRATIVE CONTEXT ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙25 3.2.4. VISUAL AESTHETIC ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙26 3.2.5. MUSIC ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙28 3.2.6. SOUND EFFECTS∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙29 3.2.7. INPUT DEVICE∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙29 3.2.8. TUTORIALS ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙31 3.3. INTERVIEW AND SURVEYS ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙31 3.4. USER TESTS ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙32 3.5. TECHNICAL IMPLEMENTATION ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙33 3.5.1. BEAT MAP DATA ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙33 3.5.2. BEAT MATCHING ALGORITHM ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙33 3.5.2.1. Timing Zones ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙33 3.5.2.2. Beat Mark Status∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙35 3.5.2.3. Mark of Interest ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙36 3.5.2.4. Beat Matching Scenarios ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙37 3.5.2.5. Beat Marks with Different Values ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙42 3.5.3. PERFORMANCE ISSUES ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙42 3.5.3.1. Audio syncing∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙42 3.5.3.2. Input Lag ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙43 3.5.3.3. Configuration File∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙43 3.6. COLLABORATION ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙44
CHAPTER 4 ‐ EVALUATION ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙44
4.1. RESULTS∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙44 4.2. PROCESS ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙47 4.2.1. RESEARCH METHODOLOGY ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙47 4.2.2. IMPLEMENTATION∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙48 4.2.3. TESTING PROCEDURE ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙49 4.3. FUTURE PLANS AND ITERATIONS∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙50
REFERENCES∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙52
APPENDIX 1 ‐ USER TEST WORKSHEETS ‐ BASKETBALL DRILL ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙55
APPENDIX 2 ‐ USER TEST WORKSHEETS ‐ DIVINE BEATS – PLAYTECH∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙58
5
List of Illustrations
Figure 1‐1 ‐ "Divine Beats ‐ Night at the Monastery" gameplay screenshot∙∙∙∙∙∙∙10 Figure 2‐1 ‐ The beat marks and timelines of “Rockband”(upper‐left), “Taiko no Tatsujin”(upper‐right), and “Dance Dance Revolution”(left)∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙12 Figure 2‐2 ‐ Gameplay scene in Atlantica from "Kingdom Hearts II"∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙14 Figure 2‐3 ‐ "Rhythm Heaven" – The Glee Club stage ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙17 Figure 2‐4 ‐ "Vib Ribbon" gameplay screenshot∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙18 Figure 2‐5 ‐ "Princess" gameplay screenshot ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙19 Figure 3‐1 ‐ “Divine Beats – Drive Away the Beast” gameplay screenshot ∙∙∙∙∙∙∙∙∙21 Figure 3‐2 ‐ Drum Controller in action∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙21 Figure 3‐3 ‐ "Basketball Drill" gameplay screenshot∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙22 Figure 3‐4 ‐ "Basketball Drill" game flow concept ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙22 Figure 3‐5 ‐ "Chuck and Cherri" game flow concept ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙22 Figure 3‐6 ‐ "Chuck and Cherri" gameplay screenshot∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙23 Figure 3‐7 ‐ Early and Final versions of the Drummer and Enemy Sprites ∙∙∙∙∙∙∙∙∙∙28 Figure 3‐8 ‐ "Divine Beats ‐ Night at the Monastery" during the exhibition ∙∙∙∙∙∙∙30 Figure 3‐9 ‐ Tutorial Slide Show for instructions to play∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙31 Figure 3‐10 ‐ Time Zones for beat matching∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙34 Figure 3‐11 ‐ Time Zone placement in relation to playhead ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙35 Figure 3‐12 ‐ Beat Mark Status in relation to Time Zone ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙35 Figure 3‐13 ‐ Beat matching case 1: No beat marks ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙38 Figure 3‐14 ‐ Beat matching case 2: Hot beat mark nearby ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙39 Figure 3‐15 ‐ Beat matching case 3: Warm beat mark nearby ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙39 Figure 3‐16‐ Beat matching case 4: Warm beat mark nearby with Cold ‐ Hit beat mark ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙40 Figure 3‐17 ‐ Beat matching case 5: Warm beat mark nearby with Cold ‐ Miss ‐ Too Early beat mark ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙41 Figure 3‐18 ‐ Beat matching case 6: Warm beat mark nearby with Cold ‐ Miss ‐ Too Late beat mark∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙41
6
Chapter 1 ‐ Introduction
1.1. Concept
My thesis is a music rhythm game, centered on the adventure of a drummer in a
fictional Oriental world, and it deals with a common aspect of music games: how to
inform players the timing for when they have to perform a certain action. In this
game, I want to explore how beat map data can be implemented and incorporated
into the game environment, instead of presented on a separate graphic layer.
Currently, it is a Flash game that can be played with a gamepad, and it will be
distributed over the Internet as a downloadable executable.
1.2. Impetus and Motivation
I have been playing several music rhythm games for quite some time. Responding to
the music rhythm with different actions demands a lot of concentration, and the viral
experience when I do things right is gratifying, making me feel I have done something
to make the music performance work out. Starting from “Taiko no Tatsujin”(Namco,
2001~2009) and “Osu! Tatakae! Ouendan”(iNiS, 2005), I began to explore other
music games, including the mainstream “Guitar Hero”(Harmonix, 2005) franchise and
the more unorthodox “Rhythm Heaven”(Nintendo, 2009).
My motivation for this thesis stems from the different ways various music games
handle beat map data and the game environment within. More often than not, when
the beat map data is rendered visually, it stands separate from the game
environment and competes for attention. During the gameplay, it’s necessary for the
7 players to focus on the graphic components presenting the beat map data, and thus the game environment is ignored. These game environments can include a group of performing characters and avatars, virtual concert stages, or even narratives. To me, it seems like a waste to have these assets being nothing more than decorations during the gameplay. Thus, in this thesis project, I look for ways where the game environment can have a more significant role during gameplay.
1.3. Significance
The thesis deals with an aspect that all music games have to deal with, namely, how the players can be informed of when and what they have to do at a certain time in the song. Chapter 2 will go over how existing music rhythm games accomplish this. In my thesis, I adopted some of these methods for my own game, and encountered several challenges during the process. By the end, the development of this game shall provide a case study on alternative methods for representing beat map data without neglecting the game environment.
1.4. Design Questions
What are some of the conventional and unconventional ways beat map data
have been represented in music games?
How much beat map data can be represented yet still allow the users to pay
attention to the environment inside of the game?
If beat map data are to be merge within the environment of the game, how can
it still present information clearly to the user?
8
1.5. Audience
The intended audience for this game is mainly gamers with varying exposure to music games. The narrative context and music choice may also appeal to people interested in archetypal narratives and graphic styles inspired by Asian culture.
1.6. Final Product
The final prototype “Divine Beats – Night in the Monastery” is inspired by the NDS game “Rhythm Heaven”. It builds upon a call‐and‐response game mechanic, where the player has to repeat a previously performed rhythm. In this game, the drummer works with a Taoist Monk to evict malicious spirits from their possessed victims, whom are spawned based on the rhythm of the background music. Having the enemies representing the beat map data introduces challenges covered by the mentioned design questions.
Starting from the Main Menu, the game application consists of:
An introduction slide show, which explains the narrative behind the game.
Two tutorials, each consisting an instruction slide show and a practice stage.
One stage featuring an Asian pop song.
The game was later exhibited on a PC as a Flash application that can be played with an Xbox game controller. It uses MIDI files to define the level data. The implementation details will be covered further in Chapter 3.
9
Figure 1-1 - "Divine Beats - Night at the Monastery" gameplay screenshot
For the rest of this paper, Chapter 2 will go over issues in game design I want to address through my thesis project, as well as some prominent precedents that relate to those issues. Chapter 3 covers the methodology I employed while implementing the game, which includes prototypes I’ve done, design decisions I made, and technical details of the game. Finally, Chapter 4 covers user feedback on the final prototype, as well as evaluating the thesis process and how it has accomplished the goals of this thesis project.
Chapter 2 ‐ Domain and Precedent
2.1. Domains
2.1.1. Game Design ‐ Music Rhythm Games
The music rhythm game has became a genre of game where interacting with the game music is the core of the game. For this thesis, when I talk about music rhythm games, I am specifically focused on the subgroup that Collins defines as rhythm‐action games: ”[v]ideo games in which the player must respond in some way to the rhythm or melody being presented […]”(Collins, 2008). These games are also
10 more widely known as “rhythm games” (Wikipedia contributors, 2010). The players have to perform to a predefined sequence of timed beat marks, which should correspond to the music’s rhythm.
2.1.1.1. Beat Map Data and Representation
For games commonly known as rhythm games, each of them has to employ a method to convey to the players the actions they need to perform. This thesis adopts the terminology used in “osu!”(peppy, 2010) – a parody game to “Osu! Tatakae!
Ouendan”, “Elite Beat Agents”(iNiS, 2006), and “Taiko no Tatsujin” that enables user‐generated level contents online‐ and refers to these information as “beat map data”. Others may also refer to this information as “score” or “game score”(Lieberman, 2006). For my thesis design, I decided not to follow this convention, as the same vocabulary has dual meaning in game design ‐ in particular, the reward points gained by the player during the gameplay.
The representation of the beat map data varies amongst games. The most common representation involves a series of beat marks traveling down a timeline. The timeline will suggest the correct timings for the player’s response, while the appearance of the beat mark indicates the action to perform. During a chanced conversation at the Game Development Conference this year, Kevin McGinnis from
Harmonix also pointed out to me that players are not only shown what they have to do in the present, but also what they will have to do in the future as well. The vertical trail of arrows in “Dance Dance Revolution”(Konami, 1998), the horizontal trail of beat marks in “Taiko no Tatsujin”, and the 3D roadmap of “Rockband”(Harmonix,
2007~2009) and “Guitar Hero,” are all variations of beat map representation that
11 serve that same purpose. For these games, the graphic components showing the beat marks become the center of attention for players during gameplay.
Figure 2-1 - The beat marks and timelines of “Rockband”(upper-left), “Taiko no Tatsujin”(upper-right), and “Dance Dance Revolution”(left)
2.1.1.2. Beat Mark Graphics vs. Game Environment
Other visual performances may also take place during the gameplay, usually in the background. For “Dance Dance Revolution”, that will either be dancing characters or motion graphics. “Taiko no Tatsujin” has dancing characters, some of which will start to display different gestures and expressions based on the player’s performance. For
“Rockband” and “Guitar Hero”, the background shows the player’s avatar performing on a stage with an audience ‐ all in 3D with camera cuts ‐ and is almost like a music video. The avatar animations are predetermined, though the crowd will show different reactions based on the player’s overall performance to that point ‐ you will hear them booing on a poor performance, for example.
12 For the above examples, some of them use the background visual elements to establish a game world or environment; “Rockband” and “Guitar Hero”, in particular, use the setting and character animation to establish the mood of a concert performance. Nevertheless, during the gameplay, these background performances are neglected for the most part of the gameplay. Players of “Rockband” may pay attention to the beginning and ending sequence of their avatars’ performance, which are before and after the actual gameplay, but during the gameplay these are ignored as the beat map information starts to compete for attention (Fortugno, 2009).
To an extent, these games aren’t exactly about the virtual game environment. All these games have tangible peripherals that physically engage the players, and they are all party games or arcade games. Players are playing the game in the context that they are simulating the act of playing music in front of other onlookers in the real world. In that case, the game worlds created aren’t meant to be the main focus of the gameplay experience. As my thesis project, “Divine Beats – Night at the
Monastery”, is meant to do the exact opposite and put more emphasis on the game world, it will have to adapt a different approach in representing the beat map data.
For other music games that take a different approach to beat map representation, the gameplay experience becomes different as well. “Rhythm Heaven” is the polar opposite of those previous examples in that it has no graphic components dedicated solely to convey beat map information. Based on a Simon‐says game mechanic, the player has to repeat a series of rhythm patterns presented to them. These rhythm patterns are presented through audio and character animation, and there are no timelines or beat marks on the screen. Players hence have to rely on audio and their own sense of rhythm to play the game. A lot of prototypes in this thesis take after this game, which Chapter 2.2.1 will discuss in detail.
13 Then there are games that straddle in‐between. While they still employ graphic components to show beat map data, they also attempt to blend these into the game world.
For starters, in “Kingdom Hearts
II” (Square Enix, 2006), the
protagonists participate in
several musical performances in
the realm of Atlantica, which are
a series of mini‐game. Like
“Rockband”, the beat marks are
Figure 2-2 - Gameplay scene in Atlantica from "Kingdom layered over the background Hearts II" video. However, it becomes clear that the main focus is on the performance in the background. Each beat mark shows its own expiration timeline and the associated action, and it is placed near the object or character it will affect when the player hits or misses that mark. The timing gaps between the beat marks are also considerably widespread and sparse, so the players don’t have to spend 90% of the gameplay checking the status of beat marks.
Another example involves the game environment embodying the beat map data all together. “Vib Ribbon” demonstrates this concept by turning timelines and beat marks into a terrain of obstacles. The protagonist transverses this terrain in a speed based on the background music’s tempo, and he avoids different obstacles through different actions. The placements of the obstacles are based on the music’s rhythm.
The act of the protagonist traveling down the road thus becomes a performance in‐sync with the music itself. Chapter 2.2.2 will further discuss this game’s influence over my thesis project.
14
2.1.2. Game Design – Interface Design
For most music games, the beat marks and timeline are likely to be part of the game’s heads‐up display (HUD). Whether it is the 3D beat mark roadmap of
“Rockband” or the single‐lined beat mark queue of “Taiko no Tatsujin”, their purpose is the same: to inform the players of upcoming actions they have to perform. In my surveys from user test interviews, most respondents who played similar games also pointed out that during gameplay, attention is primarily given to the HUD that shows the beat map data. Other visual components, including performing characters and background video clips, are likely to be ignored.
On the other hand, more and more video games are gearing towards making the
HUD less intrusive. Amongst many reasons, taking out the HUD can help the game become more immersive. While HUD is effective for conveying information to the players, it can also make it harder for players to immerse themselves into the game’s virtual environment. “Just as a filmmaker doesn't want a viewer to stop and think,
‘This is only a movie,’ a game developer should strive to avoid moments that cause a gamer to think, ‘This is just a game’,” says Greg Wilson on Gamasutra. “More detailed graphics and more refined storytelling techniques can also draw a player into a rich and complex game world. However, nothing screams ‘this is just a game’ louder than an old‐fashioned HUD” (Wilson, 2010). Wilson suggests that there are several methods existing games employ to eliminate HUDs that stand as a component separate from the game environment. Among them, I have chosen the ones that seem most applicable for my thesis design. These include:
1. Using audio
15 While audio is often viewed as accompanying feedback that enforces other visual
cues, it can also convey information that will be more difficult if conveyed visually.
In fact, in survival horror games such as “Silence Hill”, the game environment can be
visually obscured, where either the environment is dark and/or the player has a limited field of view. In such cases, the player has to rely on audio cues to navigate
through the game environment (Whalen, 2007).
In the case of “Silence Hill”, the game takes place in settings that are either dark or
fogged, limiting the player’s ability to perceive visual information. Instead, the
protagonist carries a radio that emits static white noise whenever an enemy is nearby, and even the radio remains invisible for the majority of the time. Exploring the game
environment thus becomes more like a hearing activity.
The final prototype, in fact, will show a similar phenomenon, where the player makes
decisions based on audio as well as visuals.
2. Place the information into the game world, literally
Instead of making the HUD a separate layer of graphics, display the information with
objects that are part of the game world. For example, have a futurist weapon display
on its LCD screen the number of ammo, as “Doom 3” has done.
3. Render HUD elements with an aesthetic theme
Having the HUD elements tied to the game world by rendering it in a style that
resonates with it. For example, in a first‐person shooter game, instead of having a static reticle overlay that assist in aiming, allow this reticle to blend in with the game
16 environment more. Wilson listed “Kameo: Elements of Power” as an example with its reticle while shooting magic projectiles.
2.2. Precedent: Further Analysis Related to Thesis
2.2.1. Rhythm Heaven
“Rhythm Heaven” is a game on the Nintendo DS that utilizes the stylus input. It consists of a series of mini‐games that involve different actions of tapping and flicking to the music. Most of the stages in “Rhythm Heaven” adapt a call‐and‐response mechanic, where the player has to repeat a previously played rhythm sequence.
Figure 2-3 - "Rhythm Heaven" – The Glee Club stage
Unlike many music rhythm games, the stages in general contain no graphic layers that indicate the exact beat map sequence the player needs to play. As a result, the player has to take his cue from the audio and background animation. This is possible given that 1) the beat map sequences are kept relatively simple and succinct, and 2) each stage starts with a tutorial explaining to the player the tapping and flicking action that need to be performed.
17 The core mechanic and action required from the player is fairly simple, which is a good feature for my thesis to have as well, given the possible platforms. Also, because graphics follow a minimalist style, where few or no graphics are used to show the sequence to be played, players have to pay more attention to the audio, as well as environment elements often considered secondary in other music games (for example, the animation of the performing characters).
My game adopted the call‐and‐response mechanics and representation of beat map data through audio and elements from the game world. I will want to see how variations of that will affect the player’s experience with the song, visual performance, and narrative of the work.
2.2.2. Vib Ribbon
In this game, the player travels a landscape full of obstacles, and each of these obstacles can be avoided by different actions. Further yet, the obstacles are placed base on the song chosen by the player: a player can place his CD into the console machine and generate a level using the songs on it.
This game is similar to “Rockband” in that it represents beat map data as a progressing timeline. However, instead of having a HUD telling players what to do, it rendered the beat marks as part of the game world, which the protagonist interacts with and will Figure 2-4 - "Vib Ribbon" gameplay screenshot have an effect on the gameplay’s
18 outcome. Many of my prototypes follow this method to convey beat map data
without using another HUD ‐ by associating the beat marks with an object (in this
case, an enemy possessed by evil spirits) inside the game world.
2.2.3. Princess
Rektor, a Norwegian electric band, collaborated with Agens to create a game featuring Rektor’s single, “Princess” (Rektor and Agens, 2009). Throughout the game,
references to “Dance Dance Revolution”, “Pacman”, and street fighting games show
up from time to time. The player has to score enough points to see the good ending.
The player controls the main character through a terrain of mini‐games. Each of
these mini‐games places the action of inputting along the music’s rhythm in a
different context. One of the mini‐games is a direct parody to DDR, where the
protagonist dances according to the arrow key input. Another mini‐game spawns
enemies based on the music rhythm, and the player’s best bet to defeat them is by
reacting according to the music rhythm as well. These are examples I refer to for my
thesis when brainstorming for alternative methods to represent beat map data,
particularly the second example, where incoming enemies embodies the beat map
data.
Figure 2-5 - "Princess" gameplay screenshot
19 Another point of interest for this game is the way it teaches players how to play the game. The instructions for each mini‐game are displayed on the screen. Yet, as the player enters a mini‐game, they soon have to encounter upcoming enemies or obstacles, leaving them little time to digest the instructions. Perhaps giving instructions on the fly isn’t an effective way to get the players into the game. That is why for my game, the tutorials are separate modules from the actual stage. They are first step‐by‐step instructions, followed by practice stages with simpler beat mark sequences. This will give a good amount of time for the players to get comfortable with the core mechanic of the game.
Chapter 3 ‐ Methodology
The final product of my thesis is a music rhythm game implemented in Flash, playable with an Xbox controller for PC. The game should serve as a case study for game designers on music games and alternative ways to represent beat map data, aside from the common heads‐up display.
3.1. Prototype Overview
The following is a brief overview of the prototypes. Chapter 3.2 will further explain how each is relevant to the development of this thesis.
3.1.1. Divine Beats‐ Drive Away the Beast
In this prototype, the player plays a drummer who has to scare a beast away by drumming. The game has a tug‐o‐war structure, where the player has to hit the drum as fast and loud as possible to win the game.
20 The game can also be played with an external drum controller, which has a microphone embedded in it. Most users find the drum controller an intuitive interface.
There are other narrative episodes of the drummer’s adventure, each of them meant to introduce different sorts of gameplay involving the drum.
Figure 3-1 - “Divine Beats – Drive Away the Beast” Figure 3-2 - Drum Controller in action gameplay screenshot
3.1.2. Basketball Drill
This prototype is the first one in this thesis to emulate the call‐and‐response mechanism found in “Rhythm Heaven”.
The player plays a rookie of a basketball team, and his goal is to repeat a series of dribbling patterns done by the team captain. There are no head‐up displays showing the beat map data. Players take their cue through the actions of the call (the captain), which is accompanied by character animation and audio.
21 Figure 3-3 - "Basketball Drill" gameplay screenshot Figure 3-4 - "Basketball Drill" game flow concept
Most of the users who’ve played this game cannot figure out the game mechanic and its goal. The lack of a background music also means this prototype has yet to be called a music game.
3.1.3. Chuck and Cherri
Figure 3-5 - "Chuck and Cherri" game flow concept
The game features two ball‐like characters, Chuck and Cherri. The player plays as
22 Cherri, who has to chase down Chuck and retrieve the ribbon he has stolen from her.
During the gameplay, the two characters transverse a road of obstacles: Chuck plants landmines as he runs along, and Cherri has to jump over them. By having Chuck running in front and Cherri having to avoid the obstacles he placed, a call‐and‐response protocol is established in the gameplay. Chuck’s action, and hence the obstacles’ position, is the “call” and is set to correlate with the background music’s rhythm.
Based on user testing, once the
users figure out how to control
Cherri’s actions, they have no
problem understanding the act
of Cherri jumping over
obstacles. While most users
find the game mechanic fun,
some was expecting this to Figure 3-6 - "Chuck and Cherri" gameplay screenshot behave more like a platformer action game instead of a music rhythm game. For example, users questioned why
Cherri was not getting closer to Chuck after successfully dodging numerous obstacles.
3.1.4. Divine Beats – Night at the Monastery (DB‐NM)
Based on “Chuck and Cherri”, the story is changed to continue the concept of a drummer’s adventure in “Divine Beats”. In this stage, the drummer has to work together with a Taoist monk to save a group of people possessed by malicious spirits.
Instead of jumping over obstacles, the drummer has to beat the drum in accordance to approaching enemies. The monk, who is running in the front and placing talismans
23 on the incoming enemies, hints to the drummer the pattern he will soon have to
perform.
For this prototype, a lot of user feedback is about their difficulty in figuring out when
the drummer is supposed to hit the drum in relation to the enemies. Also, since most
users are not familiar with Chinese religious practices, they have a hard time
understanding the monk’s role and his interaction with the drummer and the
enemies.
3.2. Design Decisions
3.2.1. Platform Choice
The game is developed in Flash with Actionscript 3, and is distributed as a package of
swf files and level data.
While there are other software development kits that will yield applications with
higher CPU performances, I still decided to use Flash and AC3 to prototype this game for portability. Swf files have the advantage of being playable on both PC and Mac,
and can also be played over the web. Another reason is the creation of art assets; it’s
easier to modify game sprites in the fla files than having to import it in the code.
Finally, there are precedents of music games done in Flash (Newgrounds Inc., 2010),
proving it is possible for a Flash application to handle audio syncing by some means.
3.2.2. Gameplay mechanic
I wanted to make a music game that diverts from the experience of “Rockband”,
“Guitar Hero”, and “Dance Dance Revolution”, in which the player pays attention
exclusively to the roadmap of beat marks. For now, “Rhythm Heaven” is the best
24 example of music games that don’t feature a heads‐up display for beat map data.
Each stage presents a situation where the player has to repeat a previously played rhythm pattern. All stages also start with their own tutorials for the player to familiarize themselves with the type of actions they have to respond to and perform.
Starting from “Basketball Drill” (Chapter 3.1.2), the prototypes have kept the call‐and‐response mechanics as part of the gameplay, and all tests show that the players will refer to the call regarding when they are supposed to act.
3.2.3. Narrative Context
The narrative for the game has undergone the most change. In fact, when I first worked on “Divine Beats‐ Drive Away the Beast” (Chapter 3.1.1), my intention was to have the narrative determine the type of gameplay for each stage. Back then, I also drafted other episodes of the drummer’s adventure, where the drummer used the drum to relay messages to an army, participated in a boat race, and evicted evil spirits – the last idea is later revived in the final prototype. (Chapter 3.1.4)
However, given the number of possible stories to work from, I started to find it difficult to determine a core mechanic that makes a fun game. This also led me to take a detour and work with stories and character backgrounds that are more generic and simple. The good thing about that is I get to think more about the type of game I want. Eventually, I decided to tap into the music rhythm game genre, where the user had to act based on a pre‐defined beat map sequence.
Sometime after “Chuck and Cherri”, I decided to return to the concept of “Divine
Beats” and choose one episode where the call‐and‐response mechanic will be meaningful. At the end, I chose the one where the drummer teams up with a monk
25 in exorcist activity, given its theme on collaboration.
During this switch of narrative direction, I only intended the story to be skinned over
the existing game mechanic. As it turns out, the new narrative in fact introduces new
problems, particularly on how the beat map data should be rendered. (Chapter 3.2.4)
3.2.4. Visual Aesthetic
“Basketball Drill” takes after the minimalist art style of “Rhythm Heaven”: there are
no beat marks clustering the screen, and the artwork is crisp and simple.
However, I later decided that the game might still need some visual elements to
represent the beat map data. One of the reasons came from users’ reaction towards
the difficulty of the game. Most users didn’t understand that they were supposed to
dribble the same pattern as the captain, and a lot of them looked towards the
metronome meant for debugging purpose. Secondly, one other thing I want to
accomplish is to make the environment in the music game (background video and
animation) have more involvement with the gameplay. For example: What if the 3D
roadmap of beat marks in “Rockband” can be fused with the performing characters
in the background video? What if the characters can serve the same function as the
beat marks and inform users of upcoming actions?
Game reviews points out that not even players of “Rhythm Heaven” can avoid
narrowing down their senses during gameplay. In later levels with more complex beat
map sequences, playing with your eyes closed becomes the best winning strategy
(Shea, 2009).
With “Chuck and Cherri” and “Divine Beats – Night at the Monastery”, I
experimented with how beat map data can be rendered in such a way to merge with
26 stage elements ‐ such as backgrounds and performing characters. For “Chuck and
Cherri”, the obstacles placed by Chuck serve the same purpose as the beat marks in
“Rockband”: it gives a visual impression of rhythm.
In “DB‐NM”, the obstacles are replaced by enemies, Chuck placing landmines is replaced with a monk placing talismans, and the player now plays a drummer who defeats the incoming enemy with his drum beating.
This setup is less intuitive than “Chuck and Cherri”, both in concept and in aesthetics.
Few users have problems understanding the act of Cherri jumping over a road of obstacles, where the obstacles’ placement corresponds to the background music’s rhythm. Having a drummer hitting the drum when a possessed person comes near, on the other hand, needs a lot of explanation. An introduction slide show is included in the game and briefly explains the backstory and cultural context of the game.
Meanwhile, two tutorials explain the core mechanic and provide mini‐stages for players to practice. These two features in the game are meant to establish the interactive relationship between the drummer, the monk, and the enemies.
Another challenge is having the game sprite stand in as beat marks. At the early stage of “DB‐NM”, users cannot tell from the enemy sprites when they should hit the drum. After all, characters with posture don’t have clear‐cut edges as the beat marks in “Rockband” do. Other users also mentioned that the details of the sprites distract their attention. Thus, the sprites eventually became more blobby and constrained within a rectangular form. Since the narrative specifies that the sonic energy activates the talisman on the enemy’s forehead, I made sure that the enemy’s head defines the sprite’s leftmost edge, while his limps and body resides behind it. Also, a sonic field is rendered whenever the drummer hits the drum. It covers the “Safe
Zone” (Chapter 3.4.2.1) that’s ideal for the drum sound to affect the enemy.
27 After making these changes, users complain less about not knowing when to hit the drum. For most users, once they realize the enemies stands for rhythm patterns, they will eventually figure out the spot for when the enemies can be “hit”.
Figure 3-7 - Early and Final versions of the Drummer and Enemy Sprites
3.2.5. Music
Starting from “Chuck and Cherri”, I have been using Asian pop music as the background music for my game stages. A lot of my testing users don’t understand
Japanese or Mandarin, and there had been different responses to that: most thought it sets the pace and use it as a metronome, while one or two chose not to listen to it on the basis that they don’t know the song. The latter makes up a very small minority, though, so the language barrier is not a major issue for the song choice.
I have looked through songs under the Creative Commons (Creative Commons, 2009) as well as licensed ones. For “Chuck and Cherri”, the pitch‐altered version of Ai
28 Otsuka’s “Sakurabon” is used to give the game a cheerful mode. For “DB‐NM”, Hsiao
Hung Jen’s “What the Heck is Love” is used. It’s a fusion between rock and traditional
Chinese music, placing the game’s atmosphere within the cultural context, but at the same time playing with the upbeat‐ness of contemporary music.
The tutorials use a different song, namely Elsa Huang’s “Converse”. The song is completely instrumental with no lyrics, and its rhythm is slow yet distinct, making it ideal for the beginner tutorials.
3.2.6. Sound Effects
The sound effects became part of the cues players use to determine their timing and actions, as user tests on “Basketball Drill”, “Chuck and Cherri”, and “DB‐NM” all indicate. They also tend to be comical, in accordance to the visual art style.
For “DB‐NM”, I have two drum sounds associated with the drummer’s two input actions: beating the drum head, and beating the drum shell (i.e. the wooden body).
In a sense, I imitate how “Taiko no Tatsujin” maps the user input to the game’s audio reaction. As for the sounds from the monk (placing different talismans on different enemies), I choose to have sounds that imitate the monk’s yell when he places the two different talismans. There had been suggestions to use sound resembling paper rustles instead, but I felt that sort of sound will not stand out against the background music, plus it will not have the same comical effects as the monk’s yell.
3.2.7. Input Device
At the beginning, I debated whether I should use a Wiimote or drum trigger for the game. After determining my audience and means of distribution, I thought that doing
29 such will shut out certain gamers. It will be impractical for a random player over the
web to have a customized drum. Hence, I decided to use a USB gamepad instead,
reducing for myself the hassle of dealing with hardware and ensuring that the game
will be widely accessible to its potential user‐base, since there are applications that
enables USB gamepads to work with Flash games (Ohkubo, 1999~2002).
For the exhibition, I got an Xbox
controller for PC, which, with the help of a
game profiler, functions similarly as a
generic USB gamepad (PowerUp Software
LLC, 2010). I decided to have this controller in the exhibition after some Figure 3-8 - "Divine Beats - Night at the observation during Playtech (Appendix 2), Monastery" during the exhibition where users spend a lot of time locating
buttons. The Xbox controller has colored buttons, which can be associated with the
enemies of different colors. During the exhibition, the game can be played and
navigated by using the controller.
30 3.2.8. Tutorials
Starting from “Basketball Drill”, it became
clear that if the gameplay is unconventional
from commonly known music games, a
tutorial is necessary for the users to get into
the game (Appendix 1). I added this feature
in “DB‐NM”, where there are two tutorials.
One explains to the player when they Figure 3-9 - Tutorial Slide Show for instructions should have the drummer hit the drum (i.e. to play
the timing aspect of the beat matching scheme), while the other one introduces the
second drum input (i.e. the gameplay using two different types of beat marks). Each
of these tutorials includes a slide show of instructions and a practice stage.
3.3. Interview and Surveys
During user tests, I conduct pre‐play interviews with the testers, where I ask them
about their experience and opinions about existing music games. The results and
feedback are summarized below:
Except for a few users who aren’t familiar with games, most gamers know of at
least one music game. Amongst them, “Rockband”, “Guitar Hero”, and “Dance
Dance Revolution” are frequently mentioned.
The song choice within the music game can indeed attract players.
The music also sets the pace for the gameplay.
For most of the music games, players largely ignore the background video and
animations during gameplay. Nonetheless, in “Rockband” and “Guitar Hero”, the
31 video and animations help establish the atmosphere of the gameplay. These
games also have a separate graphic layer that shows the beat map data.
The interface and heads‐up display used to show beat map data varies
depending on the game mechanic, but are essential to inform players of what
lies ahead and what actions will need to be performed. It is also more helpful if
the beat marks are shown with bright, saturated colors.
For most users, narrative is rarely a prominent component for typical music
games.
The survey helps me identify some of the common currency used when talking about existing music games, and what expectations people might have from the music rhythm game genre.
3.4. User Tests
I joined the Game Workshop led by Eric Zimmerman and Josh DeBonis for the entire duration of this thesis project, for which we periodically have play tests at the lab of
Parsons. While most of the testing users there are students and faculties in the same department, useful feedback are gained nonetheless. Most of the prototypes are tested this way, and Appendix 1 is an example of how the test is conducted.
There are two opportunities where I get to test outside of school. One is at Playtech for the final prototype, which is described in detail in Appendix 2. The other one is during the Onezero DT Thesis Show (May 2010), where the game is exhibited in a gallery for 3 days.
32 3.5. Technical Implementation
3.5.1. Beat map data
The MIDI protocol is used to represent the individual beats of the beat map data,
which are essentially timing data. Commercial games such as “Rockband” have also
used MIDI for their level design (Nordhaus, 2010).
Each stage will have three MIDI files associated with it: the one for the timing of the
call’s action, the one for the timing of the player’s correct input, and the one for
showing in‐game cut scenes.
These MIDI files are created in Pro Tools (Avid Technology, 2010), where the
background music’s sound file can be placed in one track. This allows me to set the
MIDI notes in accordance to the background music.
Playing and parsing MIDI files in Flash has proven to be complicated. Some of the
existing Flash libraries for MIDI require additional plug‐ins. I also toyed around with
sample applications developed by these libraries, and the performance can be rather unstable (abudaan, 2010). For example, the MIDI won’t play, or the application
simply won’t start.
At the end, I found a tool that converts MIDI files into readable, csv‐formatted text
files, and have my game read in the text files instead (Walker, 2009).
3.5.2. Beat matching algorithm
3.5.2.1. Timing Zones
The first way I thought of handling the beat matching is to have each beat mark
object (e.g. approaching enemies) keep its own beat gauge, which keeps track of the
33 time in the song where this beat mark object is situated, the remaining time before it expires, and whether an interaction with it now will be too early or just right.
However, this type of data structure is expansive, requiring more memory space for the gauge display and more processing time to update the gauge’s state. In the end, I instead set three time zones around the drummer, while having beat marks traveling across them. If an input occurs, it will affect at most one beat mark object, and the result will depend on where that object lies in relation to these zones.
Figure 3-10 - Time Zones for beat matching
The time zones are as followed:
Late Zone If a beat mark enters here without interacting with user input, it will be
considered a miss.
Safe Zone If a beat mark interacts with user input while it’s in this zone, it will be
considered a hit.
Red Zone If a beat mark interacts with user input while it’s in this zone, it will be
considered a miss.
34
Figure 3-11 - Time Zone placement in relation to playhead
3.5.2.2. Beat Mark Status
Meanwhile, the beat marks can also have different statuses depending on the song progress and their interaction with the call and player.
Figure 3-12 - Beat Mark Status in relation to Time Zone
Presuming that only one type of beat mark is involved (e.g. the game only has one type of drumbeat), the beat mark statuses are as followed:
Inactive Beat mark has not yet interacted with call.
Activated Beat mark has interacted with the call. This also means the beat
mark should be visible on the screen now. An activated beat mark
35 will not be affected by user input until it becomes Warm or Hot.
Warm Beat mark has entered the Red Zone.
Hot Beat mark has entered the Safe Zone.
Cold Beat mark has either interacted with user input or expired, and any
future user input should not further affect it.
Cold beat marks are further defined by its history. While further user input will not affect a Cold beat mark, its history status might still be useful during beat match checking.
Cold – Miss – Beat mark interacted with a user input when it’s in the Red Zone.
Too Early
Cold – Miss – Beat mark entered Late Zone without any user input interacting
Too Late with it.
Cold – Hit Beat mark interacted with a user input when it’s in the Safe Zone.
Unlike the Warm and Hot beat marks, which can only exist within the Red and Safe
Zone, a Cold beat mark can be in the Red, Safe, or Late Zone as the song progresses.
3.5.2.3. Mark of Interest
Another thing I had to keep track of is which beat mark to check a received user input against, so that we won’t need to transverse the whole beat map sequence. I call it the Mark of Interest (MoI). During the game progression, the Mark of Interest is defined with the following rules:
36 There is only one MoI at any time.
The MoI is the first beat mark that isn’t Cold.
When a MoI becomes Cold, the beat mark after it becomes the new Mark of
Interest.
The MoI can either be Hot, Warm, Activated, or Inactive, and a user input may or may not affect a current MoI depending on its state.
3.5.2.4. Beat Matching Scenarios
Base on what’s covered before about the time zones and beat marks, as the game progresses, the beat marks changes as such if no user inputs are present:
At the beginning, all beat marks are Inactive.
A beat mark is Activated once the call interacts with it.
An Activated beat mark becomes Warm when it enters the Red Zone.
A Warm beat mark becomes Hot when it enters the Safe Zone.
A Hot beat mark becomes Cold – Miss – Too Late when it enters the Late Zone.
The MoI is updated to point to the first beat mark that isn’t Cold.
So, what will happen when a user enters an input? Listing out all possible scenarios on how the beat marks will be affected is daunting. Later, I find it easier to draw the time zones and place the beat marks on different places in order to come up with possible scenarios.
37 Case 1: If there are no Hot or Warm beat marks, the input is not associated with any beat marks, and therefore nothing happens (except for the character hitting the drum).
Figure 3-13 - Beat matching case 1: No beat marks
Here is an example of such a case. No beat marks are in either the Safe or Red Zone.
Note that beat marks that are Cold or outside the Safe/Red Zones are not effected by the input.
MoI: The Mark of Interest in this case should be C, which is the first beat mark that isn’t Cold.
Case 2: When there are one or more Hot beat marks in the Safe Zone, the user input interacts with the first Hot beat mark.
38
Figure 3-14 - Beat matching case 2: Hot beat mark nearby
For example, beat mark C and D are Hot, and F is Warm. The input interacts with the first Hot beat mark, which is C. This should result in beat mark C becoming Cold ‐ Hit.
MoI: Should be C, afterwards passed to D as C interacts with input and becomes Cold.
Case 3: When there are one or more Warm beat marks in the Red zone, with no other beat marks in the Safe and Late zones, the input interacts with the first Warm beat marks.
Figure 3-15 - Beat matching case 3: Warm beat mark nearby
As such, the input interacts with beat mark A, which results in A becoming Cold ‐
Miss – Too Early.
MoI: On A first, then passes to B as A turns Cold.
39 Case 4: When there are one or more Warm beat marks, one or more Cold beat marks in the
Late Zone or Safe Zone, and the latest Cold beat mark has a Cold ‐ Hit status, the input interacts with the first Warm beat marks.
Figure 3-16- Beat matching case 4: Warm beat mark nearby with Cold - Hit beat mark
In this example, beat marks A and B have been successfully hit and changed into Cold
‐ Hit status, and may be in either the Safe/Late zone. An input right now will thus be associated with beat mark C, and C changes its status to Cold ‐ Miss – Too Early.
MoI: On C, then passes to D as C becomes Cold.
This case is similar with Case 3 with the exception that Cold beat marks are present in the Safe/Late Zone.
Case 5: When there are one or more Warm beat marks, and the latest Cold beat mark has a
Miss – Too Early status and is in either the Red/Safe/Late Zone, the input interacts with the first Warm beat marks.
40
Figure 3-17 - Beat matching case 5: Warm beat mark nearby with Cold - Miss - Too Early beat mark
In this case, beat marks A is hit when it’s still in the Red Zone, and turns Cold with a
Miss – Too Early status, and may be in either the Red/Safe/Late zone. An input right now will thus be associated with beat mark B, resulting in B turning Cold ‐ Miss – Too
Early status as well.
MoI: On B, then passes to C as B becomes Cold.
Case 6: When there are one or more Warm beat marks, and the latest Cold beat mark has a
Miss – Too Late status and is in the Late Zone, the input is associated with either the first Warm beat mark or the latest Cold beat mark.
Figure 3-18 - Beat matching case 6: Warm beat mark nearby with Cold - Miss - Too Late beat mark
In the above example, B has just turned Cold – Miss – Too Late as it enters the Late
41 Zone without having any input interact with it. Should a user input occur soon after
that, we’d like that input to be associated with B instead of C, in which case will result
in nothing.
Otherwise, if C ends up being closer to the current time than B is, the input is associated with C instead, turning it Cold ‐ Miss – Too Early.
3.5.2.5. Beat Marks with Different Values
It is not until later when I decided to add another input/drumbeat into the gameplay.
That means the beat matching algorithm needs to be adjusted, as well as new
characters and sound effects associated with the new input.
The beat matching check in regards to time is unchanged. In fact, checking the time
of the beat marks comes before checking the value. Matching up the user input value
with that of the beat mark doesn’t occur unless that beat mark is Hot – or, in other
words, the conditions of Case 2 from Chapter 3.4.2.4 are fulfilled first. Another beat
mark state, Cold – Miss – Wrong Value, is also added.
Other than having new enemy sprites and sound effects for the newly added input, I
also need to think about how the sprite (the beat mark) should look when it turns
Cold – Miss – Wrong Value.
3.5.3. Performance Issues
3.5.3.1. Audio syncing
After I edit the MIDI files that determines when the monk acts and the drummer
should act, I render a mixed version of the background music and the MIDI tracks as
42 a draft to check if the MIDI notes matches the music.
However, even if the same MIDI files sound like they are in‐sync with the song, once they are read into the Flash application, there will be lags. If we use the timing data in the MIDI files to evoke the call’s actions, the call will act later than expected. After talking to others who also dealt with audio‐syncing in Flash, I am more convinced that this could be due to Flash’s capabilities in dealing with audio.
Fortunately, this lag is consistent throughout the beat map sequence, so a global adjustment value could get around that problem.
3.5.3.2. Input Lag
For awhile, there had been a lag between the moment the user press the button and the moment where the character and sound actually respond. It could be the audio having a delay, or it could be the code structure having a bottleneck.
Eventually, I had to strip down the game to do nothing but have a button input that makes the player character do animation and plays sound. I also used Mr. Doob’s performance monitor to check the frame rate and memory size of the application when it runs (Mr.doob, 2010). With this bare‐boned structure, I found out that the input lag problem could be mitigated by increasing the frame rate of the SWF file – and the main timer’s frequency along with that.
3.5.3.3. Configuration File
Even if the game runs perfectly on my own laptop, the beat map syncing is off again once it runs on another machine, which means I have to change the adjustment
43 value for the beat maps again. To avoid having to recompile the code for a value that will undergo constant changing and testing, I have an XML file that stores the adjustment value. Later, this file is also used to store the movie frame rate, timer frequency, scaling values for the timing zones, and beat mark traveling speed. The configuration file should make porting the game to other machines easier.
3.6. Collaboration
At the beginning, I was working with a character animator who will do the game sprites. When he decided that he could no longer devote time for the project, I had to settle with making the sprite animations myself, making them being as economical as possible.
Chapter 4 ‐ Evaluation
4.1. Results
As a result of my design process of converting the enemy sprites to serve the same purpose as beat marks, I feel that I have learned what aesthetic choices will make the sprite clearly convey the beat map data and what will make it more confusing for the players.
Before and during the exhibition, I made several tweaks on the color scheme of the enemy sprites and the controller buttons. It appears that employing such color schemes can helps the players distinguish which input to respond with. At the beginning, I paired up blue and red enemies with green and yellow talismans and sonic fields, while having the blue (X) and red (B) buttons on the Xbox game
44 controller control the drummer’s actions. When users start to play, a few users
thought they should use the green (A) and yellow (Y) buttons instead, since those are
the colors of the talismans and the sonic fields. To eliminate this problem, I changed
the talismans and sonic fields to fit that of the corresponding enemies as well.
In the final prototype, as the game runs longer, the audio lag will start to appear
(which, I note, is not noticeable when the game is launched). After playing 4 stages,
the audio will be out of sync with the visual elements. The audio lag has been a constant problem throughout the thesis process. Even with code snippets that help
indicate the application’s performance and memory usage, it becomes hard to
pinpoint what is causing this problem. This problem appeared after the game stages
become part of the module of the whole application, alongside the main menu,
tutorials, and introduction. That will be a good place to start debugging.
The game, otherwise, is generally better received than I thought it would be, and the
game is fun. A few people ended up comparing it with “Guitar Hero”. This game is an
attempt to be different from “Guitar Hero”, but the fact that they would make that
comparison means they can place the game in a genre and recognize this as a game
where they have to respond to the background music.
About one third of the people actually cares about the back story of the game and
went through the “Introduction” slide show. Some of them will do so before playing
the game, and there are a few who did so afterwards.
Tutorials are essential for this sort of hybrid rhythm game. For earlier prototypes,
when there is no tutorial slides or stages available, players might even have a difficult
time understanding what they are suppose to do. For the final prototype, players
respond to the tutorials differently. There are those who reflected that the tutorials
45 are helpful and explain the game mechanic fairly well. Then there are some players
who dived right into playing the game without going through the tutorials; hence
they didn’t understand that this is a music game, and simply proceeded as if the
game is a normal platformer game, only to get slaughtered during the gameplay.
A lot of players gave good comments on the music used, despite the fact that most of
them can’t understand Mandarin. Few of them pointed out that the beat map
sequence doesn’t always fit perfectly with the song. I’m aware of this issue for awhile,
and can only say that some of the songs, particularly “What the Hell is Love”, have
rhythm patterns that don’t always lend themselves well to the call‐and‐response
pattern. This is a design issue that can only be resolved with the help of a composer.
Most of the players use the enemy sprites to judge when they are suppose to hit the
drum, while a few said they will also take the audio from the Monk into
consideration. Nonetheless, most of the players responded that the Monk is helpful
in telling them what rhythm pattern they have to do next.
By the end, the call‐and‐response game mechanic, the Monk, and the game sprites
have been able to convey the beat map data to the players for the majority of the
time; how successful they do also depends on the player’s expectations for the game.
For players who went through the tutorials and understand the basic game mechanic,
they are able to get into the flow of the game, even though during gameplay they
may miss on the first few enemies before they get used to the timing.
On the other hand, those who don’t fully understand the game mechanic or even recognize the game as a music game will figure out what the input does, but won’t
be able to hit the beat marks or defeat the enemies during the gameplay. As
mentioned before, these players take this as another platformer action game and hit
46 the drum continuously, which results in many enemies entering the Miss – Too Early state. A few of these players didn’t even use the headphones when they play the game. An interesting case is when such players eventually went back and checked out the tutorials again. After which, they will attempt to play again, and do a lot better then. It shows that the tutorial is important for setting up the rules and expectations for the game and preventing the players from playing the game with their own assumptions of what it might be. Currently, the player can choose to go through the tutorials or just play the actual stage; perhaps it’s a better idea to encourage the player to go to the tutorials first by setting the tutorials up as early stages, which the player should play through before starting on the actual stage.
4.2. Process
4.2.1. Research Methodology
I am rather slow in looking for resources outside of school on game design issues. At the earlier phase, I conducted most of my research by talking to other gamers, reading game reviews on websites, and playing games when I can. The Game Design
Workshop in Parsons, led by Eric Zimmerman and Josh DeBonis is another great source of advice and support. Eric and Josh had given me a lot of advice that are crucial for game design, and they always encouraged me to explore and test ideas with iterative design and prototyping. Talking to other fellow students who are also interested in and developing games is also helpful; some of them introduced me to some useful precedents. The workshop also constantly held play tests in school, where I performed most of my user tests.
It is not until later when I start going to conferences such as GDC and found sites such as Gamasutra with prolific articles. I now know more places outside of school to look
47 into when I need answers and appreciate talking to other people in the game design field.
4.2.2. Implementation
I collaborated with someone on this project for a short time. At the beginning of the spring semester, when I decided on the story and characters of my final prototype, I worked very briefly with an illustrator on this project in the Game Design Workshop, who was supposed to handle most of the graphics and animation assets. It turned out that this person didn’t know a lot of things about Flash and character animation, and his aesthetic style diverged from what I have established. Eventually, when he decided that he can no longer stay on this project, I was secretly relieved, because managing the group had become tiresome.
Of course, that turn of events means I had to reassess what art assets I must cut down for this project, which explains why the game sprites are not fully animated in the final prototype. If I ever were to work with another animator for this project, I will have to make sure his or her skills and style are up to what I need.
When I ran into problems with technical issues, particularly those involving the audio syncing, I usually found it more helpful to ask a Flash/Actionscript guru in person instead of searching for help online. For one thing, it usually takes some time before someone responds with answers. Also, as the code got bigger, it becomes harder to post codes online and ask for help. So far, I have been able to get in contact with one person who had worked on a Flash music game before, and he gave me a few useful tips. One of the most prolific creators of Flash music games I know is CoolioNiato, whom doesn’t have his own website or other online identity other than those on
48 game portals, and even contacting him on Newgrounds didn’t go any further. If I can
get in contact with him somehow, I’m sure he will be a great source of technical
advice, too.
I will still need to fine tune this game further and get rid of the audio lag that appears
after the game runs for a longer time. I’m hoping I can get into contact with more
people who have created music games in Flash. Maybe the BBS threads I’ve posted
long ago will also have more replies now.
4.2.3. Testing Procedure
Most of my user tests have been done with peers at school during the Game Design
Workshop’s play testing event. The flow of those tests, for the majority of the time,
involves me interviewing the users on their perception on music games, letting them
play my game, and asking for feedback after they are finished with the game.
Appendix 1 is a good sample of how user testing goes in such events.
The only two opportunities I got to test my game with people outside of school is 1)
at Playtech (See Appendix 2), an event where kids comes to Parsons to play with
different game prototypes, and 2) the thesis symposium, where the game was
exhibited with other games at the Game Lounge.
It’s an encouragement to see people having fun with the game. On the other hand,
certain problems in the design surface more quickly. Keeping the color scheme
between the talismans and enemies in‐sync didn’t occur to me until someone used
the wrong button. Another problem involves the input device choices. During the
exhibition, a monitor, a game controller, a set of headphones, and a mouse are
presented on a pedestal. The mouse is there in case I need to restart the game, but
49 some users will attempt to click through the screen with the mouse instead of using
the controller.
4.3. Future Plans and Iterations
First, I would like to resolve the issue of the music. Both of the music pieces I used in
the game are licensed, and I will have to resolve this issue if I want to launch this
game online or submit it for game contests. For one solution, I’ve gotten some references to another composer who had heard of my project and seems willing to
collaborate with me on some original soundtracks. I also want to contact the artists
of the current tracks as well, to see how they will react.
Second, I want to eventually have this game enter a game contest. That means I’ll
have to fix the audio lag bug. Switching to another software development platform
that handles audio better (such as Unity) is tempting, but for time’s sake, digging into
the Flash game community and finding a way to get around the current bug seems
more practical right now.
There had been some other suggestions on the game mechanic, some of which I
think are worth considering. One suggestion is to have the drummer’s stamina
decrease not only when he misses, but also whenever he hits the drum. That will
mean the player needs to do some resource management and not just hit the drum
when he doesn’t need to; the downside is that it reduces the possibility of improv
performance play. Also, this game technically still uses HUD to display the player’s
score and the stamina bar. Given that now beat marks are no longer shown by a HUD
anymore, it might be even better if the score and player stamina also become
something that is shown through the game environment – for example, animate the
50 drummer in different states based on his stamina.
51 References
1. abudaan. "miditoflash ‐ Project Hosting on Google Code." Google Code.
http://code.google.com/p/miditoflash/ (accessed May 16, 2010).
2. Avid Technology, Inc.. "Avid | Pro Tools." Avid | Home.
http://www.avid.com/US/products/family/pro‐tools (accessed May 16, 2010).
3. Creative Commons. http://creativecommons.org/ (accessed December 17,
2009).
4. Collins, Karen. Game Sound ‐ an introduction to the history, theory, and practice
of video game music and sound design. Cambridge, MA: MIT Press, 2008.
5. Fortugno, Nick. "Simulation." Class lecture, Game Design I from Parsons the
New School of Design, New York, NY, October 29, 2009.
6. Harmonix Music System. Guitar Hero. PS2. 2005.
7. Harmonix Music System. Rockband. PS2. 2007~2009.
8. iNiS and Nintendo. Osu! Tatakae! Ouendan. NDS. 2005.
9. iNiS and Nintendo. Elite Beat Agents. NDS. 2006.
10. Konami. Dance Dance Revolution. Arcade. 1998.
11. Lieberman, David. “Game enhanced music manuscript.” Proceedings of the 4th
international Conference on Computer Graphics and interactive Techniques in
Australasia and Southeast Asia (Kuala Lumpur, Malaysia, November 29 ‐
December 02, 2006). GRAPHITE '06. ACM, New York, NY, 2006. 245‐498.
12. MIDI Manufacturers Association Incorporated. "MIDI Manufacturers
Association." MIDI Manufacturers Association. http://www.midi.org/ (accessed
52 December 17, 2009).
13. Mr.doob. "Mr.doob | Stats." Mr.doob | three.js. http://mrdoob.com/80/Stats
(accessed May 16, 2010).
14. Namco. Taiko no Tatsujin. PS2 & NDS. 2001~2009.
15. NanaOn‐Sha. PaRappa the Rapper. PlayStation Portable. 2007.
16. Newgrounds, Inc. Newgrounds.com — Everything, By Everyone.
http://www.newgrounds.com/ (accessed May 16, 2010).
17. Nintendo. Rhythm Heaven. NDS. 2009.
18. Nordhaus, Matt. "Rock Band Network Postmort." Keynote speech, Game
Developers Conference 2010 from Harmonix Music Systems, San Francisco, CA,
March 13, 2010.
19. Ohkubo, Ryo. JoyToKey. Version 3.7.4. 1999~2002.
http://www.electracode.com/4/joy2key/JoyToKey%20English%20Version.htm
(accessed December 17, 2009).
20. peppy. osu! ‐ rhythm is just a click away. http://osu.ppy.sh/ (accessed May 16,
2010).
21. PowerUp Software, LLC. "Pinnacle Game Profiler." Pinnacle Game Profiler.
http://pinnaclegameprofiler.com/ (accessed May 16, 2010).
22. Rektor and Agens. Princess. Flash. http://www.rektor.no/index.php?go=princess
(accessed October 7, 2009).
23. Shea, Tom Mc. "Rhythm Heaven Review for DS ‐ GameSpot." GameSpot.
http://www.gamespot.com/ds/puzzle/rhythmtengokugold/review.html
53 (accessed December 17, 2009).
24. Sony. Vib Ribbon. PS. 2000. http://www.vibribbon.com/ (accessed December
17, 2009).
25. Square Enix. Kingdom Hearts II. PS2. 2006.
26. Walker, John. MIDICSV. http://www.fourmilab.ch/webtools/midicsv/ (accessed
December 17, 2009).
27. Wikipedia contributors. "Music video game ‐ Wikipedia, the free encyclopedia."
Wikipedia, the free encyclopedia. http://en.wikipedia.org/wiki/Music_games
(accessed May 16, 2010).
28. Whalen, Zach. "Case Study: Film Music vs. Video Game Music: The Case of Silent
Hill." Music, Sound and Multimedia (Music and the Moving Image). Edinburgh:
Edinburgh University Press, 2007. 68‐81.
29. Wilson, Greg. " Off With Their HUDs!: Rethinking the Heads‐Up Display in
Console Game Design." Gamasutra ‐ The Art & Business of Making Games.
http://www.gamasutra.com/features/20060203/wilson_01.shtml (accessed May
16, 2010).
54 Appendix 1 ‐ User Test worksheets ‐ Basketball Drill
Concept (idea+form) What’s Being Tested A music rhythm game that merges with interactive music Three dirty prototype for one game stage concept video and becomes another form of expression and are tested, focusing on these areas: performative art. Game elements such as the game Whether the audio is in‐sync with the user input mechanic, the sound effects, graphic interfaces, and the and visuals. accompanying music video/animation will be How different input devices affects the gameplay. experimented upon to see their effects on how the users Whether the core mechanic is intuitive for the perceives the music and the game as a piece. users. The beginning prototypes will follow music games such as If user is a gamer, how does he/she perceives the Rhythm Heaven, Parappa the Rapper, and Vib Ribbon as visual/audio/narrative elements in existing music examples in how game presents a narrative with a given rhythm games. music. Who is your “ideal” respondent Target audience will be people who knows the artist of As the target audience can include users of varying the music or gamers who’d be interested in the music exposure to music games, there should ideally be a game genre. few testers who are familiar of music rhythm games, The game will be distributed over the internet, either as a while another few who probably don’t play music Flash game or a downloadable executable. rhythm games as much. The users are expected to be computer literate.
Menu Data Gathering Tools The concept of the prototyped stage is about a rookie basketball player receiving training from the team captain. For this training session, the rookie has to imitate the captain’s dribbling pattern. The game session is less than half a minute, and the gameplay resembles a typical call‐and‐response performance. By the end of the session, the rookie’s performance will be judged as a pass/fail stage, depending on how closely the rookie re‐enacted the captain’s performance. During the gameplay, a metronome will also be playing in the background.
For the first prototype, the game is played with the keyboard, where the user presses the space bar to dribble. A second prototype plays a slightly different dribbling pattern. The third prototype uses the mouse instead of the keyboard; the user dribbles by clicking.
Interviews are also performed for two purposes: Gather demography data on tester’s view on existing music games Gather feedback from the users on the game experience
The Protocol: The interview survey is attached at the end. Before a user plays the games, he is interviewed with the questions
55 on the first page, which covers the user’s experience in music rhythm games and what role different game elements take in the game experience.
The user then goes through and plays each of the game prototype. During this, the designer takes note of the user’s behavior during the game, including how many times he will attempt to clear the stage, how he figures out the input controls.
When the user is finished, he will be interviewed with the questions on the second page, which are mainly about the game experience.
Most of the testing took place on a desktop Mac with an external mouse, but a few tests have to be performed on a laptop PC due to locations. This is also noted in each of the user’s feedback.
Feedback: There are, in total, 6 users who tested the prototypes: 4 are Parsons students in the DT lab, and 2 are people in a hobby meetup.
Pre‐test survey Most of the users are gamers who have played or heard of at least one music game or another, Rockband and Dance Dance Revolution being the most referenced.
Music Most users agree that the music used in the game is very important for a music game. Some users said they would use it to determine rhythm for their gameplay as well. Some users also indicated that part of the joy of playing music rhythm game is re‐enacting musical performances. For games like Guitar Hero, the song is the main focus, while music without lyrics might recede into the background. The songs used also determine the lifespan of the game, as some users might get tired of it.
Graphic Interface Users expect the graphic interface to give them immediate feedback during their gameplay. Most games also seem to favor using bright & crisp colors for the graphic interface, which works as a indicator of success and failure.
Video & Animation The music video or animation running in the background usually has little to do with the gameplay. Nonetheless, they do create context for the game.
56 While the players might not pay much attention to the video and animation, the onlookers might still like it as an anecdote.
Gameplay Behavior On average, it takes around 4 tries for the user to clear the stage. Some users will use the mouse when they are supposed to use the keyboard, and vice versa,
User Feedback For most players, figuring out the game control seems difficult unless they are told about it. Once they know the controls can how it relates to the character, most of the users can figure out the gameplay and clear it. While the goal and the required input action are listed at the beginning, some users didn’t register them. Users agreed that a tutorial mode or clearer instruction interface would help them understand the mechanic quicker. While the metronome is helpful for some users, users also pointed out that the movements of the characters aren’t in‐sync with the metronome’s. Some users also felt the rookie and captain look too much alike. While the audio is in‐sync with the character movements, the input seems to be lagging. Most users prefer playing using the keyboard; for those who had to play on the laptop, the difference between an external mouse and a touchpad also made the experience different. Most users rely more on their hearing to play the game, though some rely on sight instead. A few mentioned that the scoring mechanic seems to be off sometimes; that is, the user got a “Miss” when he felt he actually got it correct. Analysis: The setup of having a call‐and‐response gameplay, with minimum gauge graphics usually found in other music rhythm games, doesn’t come off as intuitive for most users. A tutorial mode on the control inputs and the goal of the stage is one way to solve this, as well as clearer graphic interfaces during the gameplay. Keyboard as an input device seems to allow more flexibility for prototyping; mouse input will have to deal the mouse’s physical form, adding more variables on the gameplay. The audio/input syncing will be a constant technical challenge. The metronome is originally placed as a debug device and replaces the lacking music as a backdrop. If this stage is to be fleshed out more, more details on the character animations, as well as a longer stage with running music, are two aspects to be dealt with first.
57 Appendix 2 ‐ User Test worksheets ‐ Divine Beats – Playtech
I. Concept (idea+form) II. What’s Being Tested? Divine Beats – Night at the Monastery is a music rhythm The prototype tested is v. 25, with 2 tutorials, an game developed with the intent to explore alternative introduction, and the actual stage. Things I looked ways to represent beat map data (timing data indicating for include which option from the Main Menu will what action the player has to perform and when). the players go to, how they try to break the game, The beginning prototypes will follow music games such as and what is their cognitive process when playing the Rhythm Heaven, Parappa the Rapper, and Vib Ribbon as game. examples in how music games convey beat map data to III. Who is your respondent? the players. Instead of relying heavily on head‐up display The testers at Playtech are kids ages from 8 to 18, (HUD) to convey beat map data, these games also use with a few adults as well. other game assets to embody such data. Target audience will be gamers who have at least minimal exposure to the music game genre. The game will be distributed over the internet, either as a Flash game or a downloadable executable.
58 IV. The Protocol? The game is played on my laptop, which is connected to a TV screen. The audio outputs i used is my USB headphones. There is also a USB gamepad for playing the game. At the beginning, the game starts at the Main Menu with the following options: [0] Synopsis (Tells the backstory of the game and characters) [1] Tutorial 1 (Introduces the basic core mechanic of the game – Hit the drum to save a possessed victim) [2] Tutorial 2 (Introduces the gameplay using two buttons) [3] Play stage (The actual stage)
The Main Menu can currently only be selected through keyboard input, so I will have to ask the testers what they want to do and key in the option for them.
After playing the game, the testers are asked again about their play experience. This post‐play interview is quite informal and mainly verbal, but the questions may include: Is the tutorial helpful in helping you understand how the game works? How do you find the audio elements in the game? What about the visual elements? Describe how you play the game. How do you determine when and how you are supposed to respond to an upcoming enemy? Do you think the beat matching is fair/accurate? What’s your interpretation of the characters in the game? Does the context setup (for example, the monk’s and drummer’s roles in the exorcist ritual) make any sense?
The Game Divine Beats – Night at the Monastery adapted the pseudo‐side‐scrolling game mechanism with different character designs and narrative context.
The story surrounds a drummer and a Taoist monk who are traveling together with a caravan. During their stay at an abandoned monastery, they found themselves under the attack of their fellow travelers. The monk said the evil spirits dwelling nearby possessed the other travelers. In order to save them from possession, the monk has magical talismans that have the power to expel the spirits. The catch is that these talisman required external energy to activate, such as the sonic energy from the drummer’s drum.
Using the same call‐and‐response game mechanics in Cherri and Chuck, while the monk places talismans on incoming enemies, the player plays the drummer, who has to hit the drum and activate the talismans as the enemy is in the right position.
The enemy will switch to a ready‐to‐attack pose when it gets close enough. If the drummer hits the drum then, the talisman will successfully expel the evil spirit from the possessed enemy.
59
On the other hand, if the drummer hits the drum too late, he will be attacked. A similar situation will occur if the drummer hits the drum too early, causing the talisman to activate prematurely. A sonic field will appear everything the drummer hits the drum, and the area it covers provides a hint of the optimal position for hitting the drum and defeating the enemies.
The two tutorial modes will each start with a slideshow of instructions, followed by mini‐stages much like the stage mentioned, with different background music and beat map sequences.
V. Feedback Almost all players going through the tutorials. Only one of them dived into the last stage right away, and he performed poorly. About half of them start off with the Synopsis, while the other half wants to play immediately and start with the tutorials. The game is better received than I thought. While some kids leave immediately before I could ask any questions, those who do get to respond thought the game is fun A good handful of people will start off by continuously hitting the drum. After being rewarded with a series of Miss – Too Early beat marks, they eventually started timing their drum beats. There are no obvious out‐of‐sync lags between the beat marks and background music’s rhythms. Almost all of the players rely on visual cues to determine when they should hit the drum (looking at the sonic field’s range, checking the enemy sprite’s animation). Only one of them uses the audio as a hint of upcoming enemies. Most of the players find the tutorial slides and stages helpful. While few complained about the content, some of them pointed out that the writing can be more condensed. Those who didn’t go through the Synopsis don’t quite understand the narrative context or the cultural reference in the game. It doesn’t seem to affect how they feel about the gameplay, though. When asked what can be improved, most of them pointed out the more detailed stuff, such as coloring Synopsis illustrations, more sprite animations, etc. Some users suggested other gameplay elements to make the game more challenging. Such includes making the stage longer, have varying speed of the beat marks at different sections of the game, make use of the buttons on the gamepad that are not used yet. The button/key icons can be rather misleading. People will think a keyboard input is on the gamepad while a keyboard number input can be done on the gamepad. Many of the players also spend a lot of time locating buttons on the controller.
VI. Your Analysis The game is better received that I thought, but various little stuff made the experience less fluid and needed to be fixed.
60 Let the Main Menu options be selectable through the gamepad, in the same manner as any console game. Get an Xbox controller (or any controller that is color coded) Edit the tutorial slides; make it shorter and to the point.
61