Archives for posts with tag: prototyping

Hi Welcome to the Dev Blog for Kana Quest. If you’re new here and have never seen or heard of Kana Quest, read this blog post for the Who, What, When, Where, and Why of Kana Quest. –> https://kipentheodor.wordpress.com/2017/09/09/kana-quest-primer/

Otherwise read on to hear about what’s been done over the last week!

So I have one and a half months till PAX Aus hits. And I am officially freaking out. There is so much to do and so little time for me to do it. I still have to get Kana Quest onto Steam so I can take preorders at PAX. I still have to implement some sound into the game. I still have to organize my booth’s set up. There are still some bugs that need to be ironed out. I need to make an awesome trailer to show off my game. And finally the one thing that has me worried most of all, my tutorial is still awful.

The tutorial has always Kana Quest’s biggest weakness. I tried to sit down this week and think about all the common misconceptions people have when they sit down and play.

  • They think they are writing words.
  • They think Hiragana is Kanji and start freaking out they don’t know the meaning of each letter.
  • They don’t understand they are trying to match sounds.
  • They don’t understand the win state.

So how am I going to prevent the player from thinking these things?

I

Don’t

Know

That’s it. The reality is I’m just not sure. But I cannot afford to give up. So here are some ideas I have that hopefully will help fix the problem.

Idea 1. Completion Gauge: So most people when playing are not sure what their goal is. If I give a visual representation of how close the level is to being completed it will better communicate the goal. I think it will help players know how close they are to completing a level, but not necessarily understand why they are completing the level.  CompletionGauge2.gif

As you can see I have already started work on this idea, mainly because I think this is my best one. To get this working though I have had to change how I handle checking whether or not the level is complete. Now the game will find the largest group of Kana in the level. Before the game would only actually check the group size starting from one location. I had to change this as if that starting location was the last to be connected it would be very easy to have a situation where the gauge goes from zero to full which would only confuse player further.

Idea 2. Show the Player the Hiragana Table: So the idea here is to show the player the whole Hiragana table after they learn their first three Kana. Hopefully this will demonstrate to the player that Kana are phonetic letters and not Kanji (which are pictorial). The other great advantage of doing this is I prepare the player for all the characters that they will learn. That way they don’t freak out that they are going to have HUNDREDS of Kana to memorize. HiraganaTableGif.gif

Idea 3. Show the English Sounds Matching in Tutorial Levels: The idea behind this one is that the player doesn’t get to see where things are matching. While this is a core part of the gameplay later on, for the tutorial the most important thing is that the player understands the core mechanic. If showing the English for a little bit will achieve this I’ll try it!

Idea 4. Change the Structure of Tutorial Levels: So the idea here is that I increase the size of the early levels but not increase the difficulty. What I’m thinking is a really long level with the same Kana repeating but with stone Kana to limit movement. Coupled with the completion gauge hopefully this will communicate the idea that creating matches is the goal.

So those are my ideas on how to improve the tutorial. They aren’t perfect so if you have any ideas, PLEASE TELL MEEEE! I’ll see you all in a week’s time where hopefully I haven’t turned into a stressed out wreck.

Advertisements

This week was a big week for Kana Quest because as of writing, all the levels in the second world are complete. So for this week’s devblog we are going to look at how I go about making levels.

Before getting into it I just want to include a quick intro to some of the terms that I will use in this devblog.

Kana: The individual game pieces in Kana Quest. They are also letters of the Japanese alphabets (Hiragana and Katakana).

Match: When two adjacent Kana share a matching sound. Eg. KA N–> Matching “A”. Matches are important as they are how you complete levels in Kana Quest. When every Kana is connected by one chain of matches the level is complete.

Mystery Kana: The main mechanic of the second world in Kana Quest. They are represented with question marks both in game and in hand drawn notes. The player must pay attention to what the Mystery Kana matches with to find out the sound of that Kana.

Ok that’s that. Onward!

 

So what is step one? The first thing I will do before I make a level is to make a mental note of a couple of things. For example: What kana has the player seen before? What kana have been introduced very recently? How many moves did the last level need to complete? How many different possible configurations did the last level have?

That last one is really important. As it is the biggest determining factor of a level’s difficulty. For example look at the following mock levels.20170902_161642.jpg

Both levels have the exact same Kana, and require the same amount of moves to complete but A is significantly easier to complete than B. And it comes down entirely to the amount of possible configurations of the Kana. One of the first levels I ever made for Kana Quest was a 3×3 level with a Kana in every spot. It only took 2 moves to complete but no one could ever complete it.
20170902_163949.jpg

So once I’ve made a note of how difficult I want the level to be, using a pen and paper I start drawing down the idea of what the level should be like.

You can see this happening here. I start out with an idea for a level where you get two normal Kana to try and figure out lots of different Mystery Kana in the level. (Top part)

Once I realize the limitations of the level concept I rearrange things to ensure the level plays well (Middle part).

Finally I write down the solution to the level and the number of moves needed to get there. (Bottom part).

Once I’m happy with my first draft of a level its time to get it into the game!

To do this I have to give unity (the game engine I’m using) the following things. 1. The dimensions of the level (In this case 3×6). 2. Make a numerical list representing each of the Kana starting from the bottom left of the level.  (In this case the list is 12,47,20,47,47,310,47,307,47,322,47,105,-1,106,-1,108,323). 3. Tell unity how many Kana there are in the level. This allows unity to know when the level is actually complete. Once you do all of this you get…LevelDemo

One level, ready for play-testing! I will usually play the level once or twice to make sure that it is possible and I know the minimum number of moves needed to complete. Then I will give it to play-testers who let me know if the level is too hard or too easy. Then I will adjust accordingly.

If you have any questions about the level making process feel free to ask any questions in the comment section.

That’s me for this week. Have a great weekend all.