Hi all, another month and another Devblog is here.

Sorry it is a day late, but I was volunteering during the Australian Federal Election yesterday and did not have time to write a post. And on that topic, all I will say is I am deeply disappointed with the results for a myriad of reasons. You might be happy with the results and that’s fine, but know and respect that this was a big loss for the Australian game development scene. If the election had have swung the other way, Labor would have reintroduced the Interactive Games Fund. This would have provided the industry with an additional 25 million per year. Now, of course, we will survive. But I really hoped this could have been an opportunity to do more than just survive.

Now onto the main thrust of this month’s devblog. This has been a bit of a weird month for the development of Kana Quest because all the major things have more or less been done. So we are in the fix up phase of things. Lots of small little boring things. For example…

W6L15.png

Before

newLevel2

After

This was a pretty small change, and I don’t blame you if you missed it. In the darker worlds the text displaying the number of medals becomes unreadable. So I added a backing to the medal counter to stop this.

I also finally got round to making some sprites for the final mechanic in Kana Quest. KanaveyorBelts.gif

These are Kana-veyor belts, they move all Kana in a row or column along one spot. Up till now we have just been using place holder assets. Still haven’t fully implemented them yet. That’s Monday’s job.

Also found a whole bunch of very strange and niche bugs.SlimeAnimationBug

For example here if you go to slime a Kana, then pull back to the first frame of the animation, and then let go of the mouse. It will cause the slime Kana to break and be unusable.

IceNNandBinDontRegisterMove.gif

Or how about, if you have an Ice “n” Kana and you move it into a removal tile from an adjacent position you don’t use a move.

Ice+YaYuYoBug.gif

Reuben (Kana Quest’s lead programmer) has had fun the last few weeks squashing this bug. So the problem was that when you used a ya, yu, yo Slime Kana on an Ice Kana and then undid any subsequent moves, the Ice Kana would become whatever was the last Kana it moved with. The cause of this problem was being caused by the fact that we had not set up the Ice + Ya/Yu/Yo animations yet. See, all the Kana faces are handled by Unity’s animator system. And the animator will change the animation according to each tile object’s hiraganaNumber variable. This a variable that is stored on the back end so the player never sees it, but it is vital to the function of the game. But when you add the Slime Kana to an Ice Kana, this changes the hiraganaNumber . However because there was no animation that corresponding to the new hiraganaNumber the animator just says “I’ll just keep playing whatever animation I was playing last”. However because of another weird quirk of how Kana Quest has been built, when you undo a move, you aren’t actually moving the Kana to their original positions. You are swapping all the data being stored between the two Kana involved in the move. So for a brief moment, the Ice Kana would have the hiraganaNumber of whatever you moved it with. This is normally impossible to see, but because of this bug this causes the Kana to display the wrong image.

But I hear you ask, why did it take Reuben a few weeks to fix this up? Well the first thing is that Reuben only works on Kana Quest two days a week, and secondly is that whole animator system I glossed over earlier. See, because all the Kana are just different instances of the same object, each of them have over 300 different animations that could be playing at any given time. And each of those animations need to have the logic behind them properly added. This results in a job that is both time consuming and impossibly dull. Oh and because we are using an old version of Unity for this, we can’t zoom out of the animation tree. So poor Reuben was stuck looking at this monstrosity for hours.

fuckedAnimationTree.png

Also note that this image is from about a year ago. There are now more animation states. So lets all tip our cap to the incredible job Reuben did with enduring this system this month. Also I feel its important to clarify that the janky-ness of these systems are my fault not Reuben’s. As I made them well before he was involved in the project.

Ok, one last weird bug before I sign off for the week.TileSlideMidMoveBug.gif

So if you moved a Kana on or off of a Kana-veyor belt while it is moving itself, it caused the whole system to have a bit of a melt down. This gif here its pretty tame as it just causes the わ to appear where the blank Kana was at the start of the level when the undo button is pressed. But in other times when I was trying to replicate this bug I had multiple Kana going “nope” and just translating off the screen and then glitching in and out of view if you tried to move anything around them.

There have been a bunch of other small little changes that have been going, but most of them aren’t easy to show visually or are just exceedingly boring to write about. So I’m sorry if this month was a bit light on the ground. Next month however I will be in Japan for Bitsummit. Unfortunately I wont be exhibiting there, but I will be around. But the long and short of it, is that next month I think we will do a tour of the places that inspired a lot of the art in Kana Quest.

Until then, take care.

Advertisements