In Preparation for Proof of Concept

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:

  1. 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.
  2. 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.
  3. 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:

  1. Fix the weird corner issue on Kanji such as middle. QA testers consistently get confused by this.
  2. Allow players to start drawing Kanji without having to wait for the animation to end in Battle mode
  3. Allow players to undo one stroke
  4. Additional player feedback in various places
    1. 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!”
    2. 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
    3. 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
    4. 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.

Quality Assurance for Kanji Samurai

Quality assurance is important for any game, but perhaps most important for those with an educational component like Kanji Samurai. It is important that we get feedback as to our game’s difficulty progression. Since we are asking players to use Kanji Samurai as a tool to introduce them to the Japanese language, we need to insure we maintain a challenge experience that does not overwhelm the player. Early testing already showed that our game was too difficult, and players need to be introduced to new Kanji at a gradual rate. At this point, our quality assurance sessions are all for player usability; the goal of our test is not for design feedback or to catch bugs, but to see whether our game feels good to play and provides the casual educational experience we are aiming for.

Kanji Players Memorized:

Down shee-ta

Middle nah-ka

Up oo-ay

Day/Sun knee-chee

Stroke order for Day/Sun:


We’ve already started to implement changes based on QA feedback. Perhaps the most important is feedback we received is that players were confused as to which stroke order to draw the Kanji in. In the earliest build, during training mode when the player is familiarizing themselves with the Kanji, the stroke order is displayed to players as an animation. Stroke order is simply the order in which players draw the lines that make up the Kanji. After the animation plays, players are tasked with tracing over the Kanji on their screen in the correct stroke order the animation showed them. Players have the option to view the animation as many times as they want. Although we had stroke order indicated through a simple animation in this early build, it was still not clear enough to players when strokes changed. Players primarily had trouble determining if the corner strokes were one or two strokes, as is the case with middle (中) where the top line and the right downward line are combined as one stroke. In order to relieve player frustration, we have since implemented an alternating color to the stroke order so it is obvious which lines come first and where each stroke ends. This means that when the animation of the Kanji plays, the current stroke will be red and the old strokes will be black. This will give players a clear indication of the stroke order they must follow.

Example of color indicated stroke order:

Stroke 2: You can see how players were initially confused by this as the top line and the line on the right could easily be perceived as two seperate strokes. By highlighting it as a single stroke in red ink, players should have a clear idea of how to draw the Kanji in the proper stroke order. kanji1Stroke 3: kanji2

During quality assurance, many players felt that had written the Kanji correctly and that the game had marked them wrong incorrectly. This was not the case, as we tested it thoroughly for accuracy. More likely players were drawing the Kanji in the incorrect stroke order or not drawing a stroke line long enough. We hope that players will have an easier time with stroke order during tomorrow’s QA testing because we have since implemented the indication of stroke order through color changes. However, the issue of not drawing the stroke order long enough is an issue that still needs to be addressed. Eric is working on determining the best way to account for player error in stroke length, and how much leniency we should grant them. The problem stems from Kanji like middle where players will draw the centerline just a block too long and get the entire Kanji wrong as a result. This is far too punishing for the player and also doesn’t make sense logically. We have discussed implementing a partial credit system in which players both take damage and give damage if they got the Kanji correct but in the wrong stroke order or if the strokes aren’t long enough. Eric is still looking into how to best implement this partial credit system.

I think I can sum up our playtesters feelings by keeping these three rules in mind in future design:

  1. Keep the Kanji simple
  2. Make the stroke order clear
  3. Allow player error in stroke length

Reflection on Initial Concepts

In late September, my team (now known as the Radiant Ronin) challenged Initial Concepts. In order to pass through the stage, we had to meet a series of requirements in order to proceed with our chosen concept. The main goal was to prove the value of the three game concepts we’d come up with and prove their gameplay with a simple prototype for each of them. At the conclusion of our presentation, we were to tell the class and our professors which game concept we decided to move forward with and why.

We created a prototype for each of our three game concepts in order to investigate their feasibility: Be Witch!, Kanji Samurai, and Demonic Deception. Be Witch! was my personal favorite of the three. It was a simulation game where players take on the role of a young witch out to prove her worth to the nearby town by mixing potions and completing requests. Players explore the forest and unlock additional sections of it by drinking potions and utilizing their effects. For example, a player would have to create a walk on water potion in order to access an island that contains additional ingredients. The basic gameplay loop would be players mixing potions, discovering new ingredients, exploring the forest, and assisting the villagers in a series of quests. Eventually, players would discover the heart of the forest and the secrets that lay within. This was my favorite game because of the cute theme and my fondness for simulation and exploration games such as The Sims and Skyrim, respectively.


Maddie Bouchie’s Be Witch! Environment Concept Art

Our next concept was Demonic Deception, which was the game we had the most difficulty with. We liked the overall concept: the player is a con artist who must lure demons to a medieval village in order to be paid to dispose of them. It was supposed to have a quirky vibe and feature a dark sense of  humor. Our theme was clear, but we were having trouble determining our core mechanics. We played with a lot of ideas. The game evolved from a tower defense game to a strategy/puzzle game. The basic gameplay loop is as follows: Players see an overview map of the village they are to sabotage. Each house in the village has slots available for the player to place lures–different artifacts that would attract different demons. For example, the player should place the perfume at the house with two male roommates because it would attract a succubus who are most useful against male victims. Once the player places all their artifacts in the available houses, the player ends the phase and demons begin flooding the village. Depending on where the lures were placed during the planning phase, demons are  attracted to different houses. Each demon is most effective against a particular family structure/house and would be able to destroy it more quickly. If the demons fail to destroy the town within a specified time limit, the player loses and has to restart the stage.

Although we finished the prototype and had finally locked down our gameplay, none of us were excited about the idea anymore. Play testers told us the game didn’t offer much challenge and had stale gameplay. We couldn’t help but agree. We’d met many times to try and flesh out the mechanics of the game and come up with an interesting concept, but we knew Demonic Deception was our weakest game concept.

Kanji Samurai, the casual mobile game where you learn Kanji in order to fight, is the game concept we decided to go forward with. Kanji Samurai is a casual semi-educational mobile game appealing to anyone interested in learning the Japanese language and culture. Players take on the role of an uneducated wannabe samurai warrior and battle opponents by tracing Kanji on their mobile screen in order to perform attacks. Although it was not my favorite game concept, it was the rest of my team’s favorite and it was far more in scope than Be Witch!, which was quickly accumulating too many mechanics and art assets. Kanji Samurai is a unique concept–although there are games teaching the Japanese language on the app store, they are all mainly educational and not very fun. In our game, we want to help players learn but also have an enjoyable experience. My designer is very passionate about Japanese culture and actually knows how to write, read, and speak Japanese. Our artist is excited about experimenting with Japanese art styles, and she’s taking inspiration from the popular ps2 game, Okami, as well. Our programmer is also excited about this game, despite how technically challenging it will be. At first we weren’t even certain Kanji Samurai was technically feasible, but we reached out to a Champlain Alumni who we were told made a game with a similar drawing mechanic. We got in touch with him and he explained to our programmer Eric how to implement a grid that players would connect in order to draw out the Kanji. Recognizing what the player writes is still a little wonky right now but we’ll keep tweaking it until it feels intuitive and accurate.

The reception of the class and our professor to our choosing Kanji Samurai was positive. They too agreed that Be Witch! had a lot of mechanics and was very art heavy. Our professor said it was evident that we’d tried hard to make Demonic Deception work and it was fine that we’d hit a dead end with it. That was the point of prototyping, he said, to see if your core gameplay is feasible and will offer players a meaningful experience. Seeing the prototype in it’s current state with four Kanji already implemented and several meaningful quality assurance session I am confident we can make Kanji Samurai a success.


Maddie Bouchie’s Kanji Samurai UI Mockup