Final Build

Android
Windows

[DEV] Final Stretches + overview

For the final hours of the project, finetuning the multiplayer, and polishing it took most of my time. Adding more scripts to deal with animations, and a good attempt at syncing the visual appearances of the characters.

Rewriting a lot of code to get the single player up and running. For future development the kanji drawing and multiplayer components should be much farther apart.

Overview of my contributions

• Kanji VG pre-processor
  A system to convert kanji in svg format to directional components.
• Kanji Writer
  A system that easily writes kanji with mouse or finger.
• Kanji Database manager
  Easily manage all those kanji, from anywhere in the project.
• Kanji Writer Manager
  An event based system to easily compare user input with the Kanji Database.
• Multiplayer
  A gamemode for 2 players to face each other in battle.

[DEV] Multiplayer + player management

Working further on the multiplayer, also adding base support for playfab integration, to handle logins etc.

[Dev] Kanji Writer

Will this ever end!?

Working on the kanji recognizer to be a smooth experience was my main goal for this week, making it a intuitive. This system works really well, but it’s not super clean when taking a look on the code inside.
This system also has some detection on how accurate the kanji was.

[DEV] Introduction to Networking

This week I dove into the world of networking. Since I have quite some experience with Unity’s implementation of networking, I was able to get quite some results. Playfab makes it easy to login from any portal, and easy to track user statistics and store custom data to fit the needs. This can both be used for storing player customization, but also remembering how well the player preformed in certain difficulties of the game. Combining the cloud code of playfab with the matchmaking of photon a worthy opponent can be found.

Photon also handles most of the networking traffic. After some testing, I was able to interact with people from the other side of the planet, without much delay.

More on this next week, the school network is causing quite an issue though, since we can’t communicate to the servers that set up the matches.

[DEV] SVG parsing

The KanjiVG project offers us a large array of svg files with all the kanji stroke information we need. However the data is not quite in the format we need it to be. This week I’ve spend time on a script that converts the svg files to strokes. 
I also added a internet lookup for the meaning of the kanji using the wwwjdic api

I’ve also written more documentation about the system which can be read here

[DEV]SVG Parsing

To build the database for the kanji lookup, I am using the data provided by the KanjiVG project. This data is served in an svg format. However the svg format has a lot more data than we need, therefor I wrote an javascript application that converts the data in to a readable, understandable format. If needed I can easily load this into a database, for usage by the game.

[DEV]Interest Points for regonition

For the kanji to be easily processed by the system, we need only interesting data points.
Therefor I added an script to the current writing system that ‘guesses’ interesting points.
It has an accuracy value, that easily increases the level of detail when drawing. This does make shape recognition harder though. Since kanji are almost always a combination of ‘almost’ straight lines. We are only looking for corner situations. Underneath you can find a video of the script in action. The accuracy is the Distance in Directional change of the mouse, and is set at a value of 1.2 0.5f for this project.

Unlike my version from last week, this supports diagonal lines without much issue.

UPDATE 23/10
I have since refined this method even more, with more accurate results for complex shapes ( not demonstrated in the video )

[Dev]Writer + kanji recognition

Diving more into a working kanji, breaking kanji down to their core elements, that might help solving the recognition system.

I’ve chosen to go for a ‘directional’ approach, where input is sorting a tree based system of kanji’s based on their input order.

I’ve started to write some documentation about this here.
Simple lines are already recognized by the system, the ‘shape simplifier’ also reduces the lines to the minimum amount of data points which would make it easier for the program to get the correct shape.

[DEV]Ocr vs Tracing vs guessing

This week I’ve been experimenting with different approaches to the character recognition, where after the user input the system checks what the input was and the meaning of that input.
OCR -> Scan the image for data and attempt to compare the character visually for similarities.
Tracing-> Have hidden predefined lines that can be followed by the user input, the user can not actually draw non existent character parts.
Guessing -> Since almost all kanji are made up of almost straight lines, we can use a directional system to guess what the input was, unrelated to the position.

This will be continued towards the following week(s).