In order to pass through the Proof of Concept stage of Kanji Samurai’s development, we have to, well, prove our concept. To me, this means getting our core gameplay and mechanics established. Our game loop needs to be effectively showcased. The game loop for Kanji Samurai is as follows:
- Training: Players learn a set of 4 Kanji from their sensei. Players are given a traceable image and an animation of the order and direction of strokes. Once the player has written each Kanji correctly three times, these Kanji are considered mastered and players can use them in battle.
- Battle: Players test their new Kanji in battle mode against a rival samurai. Players deal damage by writing the Kanji correctly within 1 minute. Players are given an animation of the Kanji once before it disappears and they must replicate it. Players lose health by running out of time to write the correct Kanji. Once the enemy is defeated, players can move on to challenge their sensei in battle.
- Challenge: Players will battle their sensei in the same way they battled the rival samurai, except they will no longer see an animation of how to draw the Kanji at all, and their sensei’s health will be higher. Once the player has beaten their sensei, they will be prompted to travel to the next location to learn the next set of Kanji.
Players progress through this game loop by selecting different locations across Japan on a map interface. Each location will have 3 sub locations-one for training, one for battle, and one for challenge. Eventually, we will incorporate a narrative to accompany the gameplay at each location in order to enhance the user experience, but that is not necessary to prove our gameplay concept. To prove our concept, we must have this core gameplay adequately displayed within the prototype with some original art assets and mechanics essential to the game. I have also enlisted the help of my friend to say pronunciations of the Kanji to greater solidify the players’ learning of the Kanji.
The best way to ensure our game is conveying our game loop effectively is to run it through quality assurance testing. I really enjoy running quality assurance for Kanji Samurai because I truly value the feedback we receive from players. Often, testers provide great insight as to how to improve our player experience. After analyzing the results from QA, I came up with a list in order of importance as to what players’ need. It is as follows:
Ways to Improve Player Feedback:
- Fix the weird corner issue on Kanji such as middle. QA testers consistently get confused by this.
- Allow players to start drawing Kanji without having to wait for the animation to end in Battle mode
- Allow players to undo one stroke
- Additional player feedback in various places
- When the player first enters into the first training mode, have a pop up saying, “Replicate the Kanji on your screen. Be sure to follow the proper stroke order and direction!”
- Literally show them an example with middle because they still aren’t getting it. Have the game say, stroke 1, and show the first stroke. Then it says stroke 2, and shows that stroke, etc, etc until the Kanji character is complete. Then the player will draw over it
- When you click on the Boss Battle with Sensei, have a pop up appear saying, “Warning: When you challenge your sensei for Kanji mastery, you will no longer be presented with an image of the Kanji. You must replicate it from memory. Proceed?” answer with yes or no
- Put an arrow on the end of the line that draws each stroke indicating direction
I always prioritize the tasks I give my team by their importance as determined by what players’ need in order to prove our concept to them. My designer, Glynis, and I discuss the issues players have at quality assurance testing and write down some solutions, then when I write up the quality assurance analysis I create a list of priorities for improved gameplay based on those solutions. If our prototype is complete with our core game loop as described above with the changes implemented from QA, we should be all set from a technical standpoint. However, documents still need to be written, hours still need to be logged, and a presentation still has to be made.
Whenever it comes time to create a presentation to challenge a stage for capstone game development, I start with a basic outline of the slides. I look at what is required in our provided checklist and lay out the slides accordingly. I set it up to what I think is aesthetically pleasing, and then my artist, Maddie, goes in and provides the finishing touches. Preparing for the presentation isn’t all just in the powerpoint–it’s important to practice! We always make sure we know who is covering what slides and understand the general outline of the presentation. It’s important that our presentation showcases not only the strengths of our game, but also the strengths of our team and why we are excited to be working together on this concept. If we don’t showcase how excited we are about our concept, how can we expect to convince the audience our game is worthy? Glynis and I work well together when we give presentations. She is the expert in the Japanese language and loves Japan so her enthusiasm during presentations really shines through along with mine. I still get nervous during presentations, but presentations for game development classes are always the easiest for me because I am extremely invested in the work and my team.