Archives for posts with tag: Programming

Good morning all, welcome to another edition of the Kana Quest devblog. Now last time I said we would have a blog written by the composers to talk about their process. As they are still working hard on making all the music right now we are going to postpone that one for an upcoming month. But is still happening.

And one more bit of news… Kana Quest will be coming to PAX Aus this year!!! So if you’ve been wanting to give the game a go, come on down, say hi, play the game, and find a handful of bugs as I freak out that there are still bugs in this thing. It shall be a swell time.

Now, onto this month’s topic…

Top 5 Dumbest Things That Theo Coded/Implemented Into Kana Quest.

So I was talking to my programmer Reuben this week and we got chatting about some of the frankly stupid things I’ve programmed since I started Kana Quest. And to be honest, most of these things are funny. So for the sake of entertainment, I am going to curate the finest pieces of coding idiocy my brain has produced. And hopefully this will explain to my relatives what I mean when I say that Game Designer is not a Programmer.

5. Stupid As Hell Names

So this one is relatively harmless on the “Theo, oh god what were you thinking” scale. It just meant that every now and again I would get a bewildered Reuben going “Theooooo, what does _______ do”. So lets look at some of the stupidest names for variables or function names that exist in Kana Quest shall we?

DumbCodingPart1

Because nothing says “Always give your variables descriptive names” like asdf.

I mean who hasn’t had been in a situation where they are too lazy to come up with a proper name for something. And this function is a pretty minor one so who cares riiight?

DumbCodingPart2

I mean at least this time the silly name explains what the script does… it moves shit… and it checks if shit has been moved. Simple. I can’t see any problems with the documentation here what so ever. Except for… you know… what is the actual shit is this script is moving.

DumbCodingPart3

This script is a completely different script from the last one

In a similar vein… “heyLookAtThisShitImHolding4U” is just flawlessly named. It perfectly sums up what the script does. It sits there holding level button data and doesn’t do anything else whatsoever. 10/10 flawless coding.

DumbCodingPart4

Unlike the previous scripts, if you got rid of this one you would get horrible visual glitches. Lot of pressure to place on monkeys, but they do the job.

Fun fact, if you have infinite monkeys sitting at infinite computers running Unity, they will eventually end up with an exact copy of Kana Quest. Really puts my coding ability into perspective.

DumbCodingPart5

And now we reach the pinnacle of both comedy and stupid names… Star Wars puns. 

The name here isn’t the funniest thing. Its the conversation with myself that happened afterwards in the comments. I forgot multiple times that I had written this stuff and each time I’d add another comment. I can’t really add any more on because I remember that I wrote all of this now, but its a fun little bit of stupidity. And it makes a good closing point on the category of dumb names.

4. The Hierarchy of the Parallax Objects.

So for those of you who have never used Unity or Unreal Engine. Every level (the technical name is a scene in Unity) has a hierarchy of all the objects within it. A normal person’s hierarchy might look something like this.DumbCodingPart6

See that window to the left? That’s this level’s hierarchy. Each object on that list is an object in the level. And if there is an arrow next to the object it means there are objects attached to it (the technical term is the object has children). This is what you are supposed to do. This way you don’t have to scroll down a massive list every time you want to change something. So you would think, that because I did it correctly here, in one of the levels, I would have done it consistently correctly across the whole game…

Ha no.

See in the level select screen, the background parallaxes. What that means is that the 2D images in the foreground move faster than the background images. This creates the illusion of depth. And it allows me to make pretty gifs like this.

World8-9Transition

So what does this have to do with the hierarchy? Well because of the silly way that I coded the parallax system. It can’t handle having objects having children like shown above. So now the level select scene’s hierarchy looks like this.DumbCodingPart7.gif

The eagle eyed amongst you can notice that there are some objects that do have children in this hierarchy. That’s because some objects are ok for me to give children, while there are others that is isn’t ok. The line is if I don’t want to be able to move the child objects with the parallaxer. Doesn’t excuse the stupidity of doing it this way but at least I get to turn it into that sweet #content.

3. The Way Movement of Kana Coded.

Hey Kids! Do you like repeating the same bit of very long complex code 4 times with with very small and minor variations that are very easy to miss? Then you would have LOVED the way I had originally coded Kana Movement. Unfortunately (fortunately) I can’t show you what this one looks like as Reuben mercifully has fixed it to function in a much better way.

See the problem was when I first coded the movement I didn’t know about all your highfalutin coding terms like *structs* and *enums*. So the way I tracked the direction the player was moving was with an integer value. And it would run four different versions of *THE SAME CODE* four different times just gated off with if statements to get the effect that I wanted. It worked, and according to Reuben my logic within that chunk of code wasn’t even that bad. But it did mean that it would take me 4 times as long to add in a new mechanic or edit the movement code as I had to repeat all the changes I made to one part of it an additional three times. One of the first things Reuben did when he got the job of programming was changing this.

DumbCodingPart8

What I should have done in the beginning

When Reuben finished cleaning this up, he was able to delete a whole 2000 lines of code. And adding in new mechanics became infinitely easier as a result. Good times.

*somewhere Reuben’s eye starts twitching*

2. All The undo Function Information.

On a running theme of not knowing how structs work when I made it the undo function. See there is only one thing more complicated that moving Kana in this game: Undoing Kana. See the problem is that when I first made the undo function I decided that rather than swapping the game objects back to their original positions I decided that I would just swap all the data held on the objects that got moved.

This was fine when there were no strange and unusual mechanics. But the moment I started adding new mechanics I had to start adding new variables to track if one of the objects was one of these new mechanics. This would have been ok… if I tied all those variables together under one struct, it would have been fine. Also for those who don’t know what a struct is. Basically you get to determine the boundaries of a new variable type. And because of this you can make an array or list of that new variable type. This is important is it would allow me when making the undo function to ensure that the many different undo variables don’t get out of position. But that’s not what I did. So instead we have a tangled mess of a metric fucktonne of different list variables that we just have to hope and prey don’t get out of position and work as they are supposed to. Reuben took one look at this script and just said “nope” and decided he wouldn’t refactor the system.

DumbCodingPart10

You can see Reuben’s opinion of this system in the comments up the top

DumbCodingPart9

And these are all the other variables being used to manage the undo function. 

And you might have noticed if you were paying attention, that there is a variable in there called “movementType”, with the comment “//0 is up, 1 is down, 2 is left, 3 is right”. That does mean exactly what you think it means. The issue that I told you about as the number 3 dumbest thing that I coded into Kana Quest… it is present in the undo function. And because the undo function is such a mess, it never got cleaned up.

DumbCodingPart11.gif

Everything is fine. Say it with me now, EVERYTHING IS FINE

 

1. The Animation System

And here we have, the biggest, baddest most horrible monstrosity my sick, twisted mind thought was a good idea at one point. The animation system. “Why is the animation system such a problem? Surely your game doesn’t use that many animations” I hear you ask. Well think again because if I have an opportunity to make something bloody hard for myself I am going to take that opportunity.

And it alllll comes back to the fact that I decided I wanted the Kana in Kana Quest to look like this.

 

See how cute the Kana are? What could possibly go wrong? Well it all comes down to the numbers of it all. See this game teaches you how to read Hiragana and Katakana right? Well there are 45 base Hiragana, and 45 base Katakana. So that means that I will need 90 animations to cover each Kana. And as long as I just load up the correct animator object that has the correct animation attached this will be fine. Riiiight?

Wrong, because I decided in all my infinite wisdom to attach EVERY SINGLE ANIMATION to the one animator object. But then I hear you ask, but it’s only 90 animations, surely that’s not too bad right?

WRONG

Before I said there are 45 base Hiragana and 45 base Katakana. There are ways to alter the sounds of Kana. For example き(ki)+や(ya)=きゃ(kya). There are an additional 21 animations for both Hiragana and Katakana for all the ways you can modify a Kana’s sound. So there are 132 animations.

But like a bad infomercial…

BUT

WAIT

THERE’S

MORE!!!

Because this is just for the normal Kana. There are Stone Kana, Ice Kana, and Ghost Kana that all have their own unique animations. There are an additional 132 animations for both Stone and Ice Kana. Which brings us up to 396 animations. There are 20 animations for all the Ghost Kana, so that brings us up to 416 animations, all attached to the one animator. There are a couple of other unique one off animations that I am excluding here for the sake of brevity, but suffice to say there are a lot of the fucking things. The end result is an animator window that looks like this.

DumbCodingPart12.gif

But, the best thing about all of this is that the version of Unity I am using is 3.1.6f. Which is long before they added a zoom function to the animator window. Which means I’m stuck panning manually like this if I need to edit, ANYTHING. And of course it also means that I can’t mass edit the transition logic. So Reuben and I have had to edit, EACH, AND, EVERY, ONE, by hand. Which leaves a lot of room for human error. Together we have probably spend a full working week of time, just editing and navigating around this thing.

Ah, fun times.

Wrapping Up

I hope this has been a fun look at my own stupidity and inexperience. We will be back next month for another Kana Quest devblog. Hopefully it will be with our composers but I’m sure I will be able to find something to talk about if they can’t do it next month either. Here are the relevant social medias for Kana Quest

And until next time, have a great month!

Hey all, This week we are going to do a review of the Ice Kana mechanic. We’ve done one of these reviews before for the One Direction Kana. Basically what we are going to do is discuss how the mechanic works, how difficult it was to implement, how it plays, and how much design space it has.

So how do Ice Kana work? Ice Kana can be moved in any direction freely but will keep moving the direction they were moved until they hit a non-moving Kana, a blank space, or the end of the level.IceTileDemo2.gif

Ice Kana cannot be moved with each other as if they could there would be situations where tiles would move forever. Also whenever an Ice Kana is moved, regardless of how far they move it is counted as only one move.

 

So how hard was it to implement Ice Kana into the game? The initial implementing wasn’t too bad. The debugging was the killer for this one. They way the game handles Ice Kana is by checking if either of the two moved Kana are Ice Kana, then if there is an Ice Kana it iterates the “move Kana” script until the Ice Kana makes an invalid move. This was pretty easy to do as it relied on preexisting logic that was solid. The hard part was managing the undo function.  The undo button will log each step of an Ice Kana’s movement as individual moves so I have to tell script at what points an Ice Kana is moved so It can group each of those moves together and undo them all at once. This part of implementation was a nightmare. The last point that was a hassle was the animations. See because I have the Kana faces animated, whenever I want a different set of images for a different mechanic I am forced to make new animations for them. But I hear you saying “Isn’t that a LOT of individual animations?”. Why yes it is. There are 46 base Hiragana, but I have to double that number for each Katakana. Okay so there are 92 animations? Nope, because I have that many animations for EACH mechanic that uses the animation system. So far that is normal kana, stone kana, ice kana, paralysis kana and slime kana. Now slime kana only actually has 16 animations because it is only applies to あ、い、う、え、お、や、ゆ、and よ (I’ll go into why when we review slime kana). But even if we take that into account we still have 384 individual animations. And let me tell you Unity is NOT DESIGNED to have that many animations going on at once. TryingToAddNewAnimations

See this clip is how you add a new animation into Unity. You have to scroll down the list of existing animations until you get to the bottom where you can select the “Create New Animation” button. It is one of the most infuriating experiences I have as a game developer.

 

Anyway, but I don’t have to worry about implementing it anymore! How does it play? Actually pretty good, it can make some really interesting levels. However Ice Kana are certainly the hardest mechanic in the game for the player. Which I’m fine with. The first three worlds are pretty easy and its good to have a mechanic that can really challenge the player. Personally I enjoy solving these puzzles but what I enjoy and players enjoy are often two different things. So I will still have to do a bunch of testing to make sure the world 4 levels aren’t too difficult. I know for sure that the last two levels of world 4 are by far the hardest in the game.

IceTileDemo3.gif

But I think if I can get the difficulty correct I think players will really like Ice Kana. It will just take a bit of tweaking and balancing to get there.

Finally, how much design space does the mechanic have? Well, LOADS this was one of the first times I finished making a world’s levels and thought “I could probably make another ten interesting levels here”. They interact with One Direction Kana wonderfully, and I am certain they will work really well with future mechanics yet to come. So I am really happy with how they’ve turned out. My one biggest concern is just how difficult players find them.

Wrapping up. I think Ice Kana are a great mechanic that I will probably end up using liberally in future levels, but I do need to be careful of the difficulty. Having some levels be a challenge is fine, but not if players find their brains melting. And while debugging them was a royal pain, I am very happy with where they have ended up.

What do you think of the Ice Tiles? Let me know in the comments! But until next time, have a great week!

So, PAX is getting awfully close now isn’t it.

I’m kinda going batty just trying to get everything together for the game. But the most infuriating part is that everything I’m doing looks like I’m doing very little from the outside.

When all you are doing is fixing small little bugs you don’t have anything interesting to show. I wish I could show you a bunch of exciting new features but I can’t. The closest thing I have to anything new is a loading screen hint section. HintDemo

Anyway. Apart from this the main thing I’ve been working on is contacting press people who are coming to PAX who I think would be interested in Kana Quest. I’ve had a little bit of a response so far so that’s better than nothing. Found one person who was perfect for Kana Quest. They were interested in educational games and taught Japanese themselves. So was able to contact them and get a positive response there.

I also got to contact Meghan O’Neil at PCPowerPlay. That one is big for me as I used to read her opinion pieces in PCPP a lot back in the day. And was the first proper critical thought about games I was exposed to. So without her work I probably wouldn’t have wanted to make games. I don’t think Kana Quest will be her jam, but I do get to say thanks so that’s exciting.

In other news it looks like Kana Quest merch will be available at PAX so if you are interested in a Kana Quest T-shirt, Kana Soft Toy, or Socks, PAX Aus is your chance!

Anyway. Hope y’all have a good day and I’ll see you around. I won’t do a blog post next week, but you will get a MASSIVE one after PAX!

Till then.

Bai

Before we get into the meat of this week’s update I just have some big news about Kana Quest. Officially Kana Quest is going to be heading to PAX Aus this year! If you are planning on coming come say hi and give the game a go! I would love to hear your feedback! And if you have any friends going tell them to check Kana Quest out! Anyway with that done, onto the week’s work!

So this week I’ve been working on implementing the second world into Kana Quest. I’ve known for a while that I want to transition between worlds by clicking and dragging the screen. And for the background art to join up seamlessly. So what’s the process of doing this involved?

world2MoreCurrent Step one was making the background art for world two. This was the easy part. All I really needed to watch out for here was to make sure that all the layers are repeatable so I can make the world as long or short as needed.

 

The next step was ensuring that the two worlds can transition into each other. This step will be easier in the future thanks to more planning in the world two art but no such planning was done for the first world’s art. As such the seam is a little abrupt. But its not an immediate shift so its better than nothing.

World1to2

MovingToWorld2

Part three was bringing the assets into unity and getting the camera to move when the player clicked and dragged. One small bug occurred with this though. I made my camera a physics object. Turns out any child object of a physics object loses its ability to know if the player is clicking on it. This caused some of my menus to stop working.

 

World2WithParallax.gif

Once we had the camera moving we had to get the background parallaxing with the camera. This means that the foreground art will move more than the background art to create the illusion of depth. This turned out to be troublesome as I kept being able to make my world two art not line up with the first world art. Thus forcing me to find a way to ensure that the art would always come back to the right position. This took half a day. It was not fun.

So here we have the last part of getting this whole thing working. The transition. This gave me the most trouble out of everything and is what I spent most of this week working on. The reason is for the first world I had used a static overlay that would fade in OVER everything in the scene. This overlay would work fine as long as the overlay was the exact same as the background. But once you add a variable camera position you no longer can guarantee this. So things had to change. So now, what is happening is I have a script that finds all the visible parts of the background, and prevents them from being destroyed when a new scene is loaded, then it moves those objects into the same relative position as they were in the previous scene. This is important as the camera’s position changes scene to scene so if this didn’t happen the art would be misaligned, or not in shot at all. Then would take all other objects in the scene and fade them out. Once the new scene is loaded it would get all the new non-background objects in the scene set the transparency to full and fade the new objects in. The result is what you can see below.

FirstWolrd2Level

 

And that was the process involved in adding the second world to the game. All subsequent worlds will be easier as I won’t have to worry about making the last three steps all over again. It will be set up for me already! Anyway I hope you all enjoyed learning about my process.

Till next week.

So this week had one task. One job that had to be done. It was long, it was boring, it was tedious. It was implementing Katakana into Kana Quest.

Why is implementing Katakana such a chore I hear some of you wonder. Well simply because implementing each Katakana has a bunch of steps that are not at all interesting and when you times those steps by 46 (the number of kana) things get very boring very quickly.

So the pipeline is as follows.

  1. Create the sprites. (We talked about this last week as I was most of the way through making the Katakana Sprites at that point.)
  2. Set the image setting for each sprite.
    1. This isn’t too bad what I have to do is tell unity how it should process each sprite. How big the image is (pixels per unit), its filter type (point filter as bi-linear and tri-linear make pixel art look awful) and if its a single or multiple sprite image. Now all of the above I can do all in one go by selecting all the files at once, but below I have to do one by one, because Unity wont allow me to do this in batch. Finally I have to set the sprite size for multiple sprite Kana. So for each Katakana I had to go into the sprite editor and tell it to divide my sprite sheet how I wanted it divided.
  3. For each kana make an animation using the unity animation system.
    1. For the stone tiles this is easy. They are just one frame so its just a matter of dragging and dropping the image into a new animation. For the normal tiles this takes a while longer because I have to copy the animations seen on the Hiragana Tiles. But the big annoying part of this step is that I have a LOT of animations on the one object now. So much so that they don’t all fit on screen so adding a new animation took about three seconds of scrolling down the animation list before I could get to the “make new animation” button.
  4. Add those animations to the animator of the tile object, and then set up the logic of when to play those animations.
    1. So putting the animations into the animator is easy. Select all the files you want and drag them onto the animation screen. Setting up the logic has to be done one by one and is really tedious. Right click from where you want the tile to transition from and to (from all to each individual animation in this case). Then click the arrow that comes up and create the parameters controlling the animation. In this case, what is the tile’s hiragana number? Is Katakana enabled? And is this a stone tile or a normal tile. Rinse and repeat 92 times.
  5. The last step is to add a control for turning Katakana off and on. This was the last and easiest step. Now if the player presses ctrl+shift+k in game katakana will be toggled on and off.

And that’s the process. Since you got through all the technical stuff your reward is some gifs! Enjoy!KatakanaDemo

SoneKatakana

So this week has been a rough week for Kana Quest. This has mainly been because my grandfather’s health has deteriorated quite significantly so my mind has been elsewhere. But hey somethings did get done so without further ado here’s what I got done.

First thing I got done was I have fully implemented a medal system into Kana Quest. This allows the player to choose their own difficulty. A gold medal will be earned by completing a level in the minimum number of moves. A silver medal will be earned by completing the level within two or three moves beyond the minimum. And bronze medals are earned for completing the level in any amount of moves.

KanaQuestMedalMedu

Seen below is a demonstration of the player losing the medal they earn based on how many moves they use.

MedalDemo

finishedlevelThis is a wip of the gui that will appear once the level is complete. I like the cool rainbow next level button but I’ve gotten a bunch of feedback that it doesn’t fit with the art style. A variant of this gui will appear depending on the medal the player earns.

 

 

 

The last thing that I achieved was debugging the new movement script from last week. I’ve gotten rid of a lot of the main bugs that were plaguing that script but now things are much more stable. There is still some bugs in there but I have had a much harder time replicating those bugs so they remain in until I can consistently trigger those bugs to get rid of them.

Anyway hope you all have a good weekend. I’ll see you next week.

So this week Kana Quest has progressed slowly. Not gonna lie. But sometimes you need to take a step back from making a thing so you can continue pressing on in a healthy direction. But still I’ll show you all what I’ve made, why I’ve made it and all that.
HavaVer2So this is a character that I have made for the tutorial sections of the first world. I have a plan of how each world is going to look like and what theme each one will have. The first world is all about Sakura flowers. This is because spring signifies new beginnings in most cultures and the symbol for spring in Japan is Sakura. Another cute thing to note is the academic school year begins during Sakura season. So it makes sense to start a new journey about learning new things. Anyway this character is called Hanna because the word for flower in Japanese is Hana (I’m a sucker for multilingual puns).
So one major problem I’ve encountered this week was one coming from my own art.  So the plan for Hanna is that she will be speaking to the player via text box. And this will be overlay on-top of the background (See Below). The problem is the background commands a lot of attention and I can’t just put Hanna on-top of it. If I do it will look awful. And to be honest this has been just further frustrating me about the background art. I really want to re-do it to make it more usable but I’m afraid I will be falling into the trap of never finishing anything. So for now I am going to leave it. I will make note of future backgrounds to avoid the traps that I have put myself into from that first background.TutorialScriptSkipButton

The things I will do for future backgrounds are as follows.

  • Use less colors and stay strictly within color pallet
  • Don’t make the image a fixed size. It limits my ability to add new levels should I need to.
  • Make sure you set up the backgrounds to parallax this way worlds can be as large or small as I like.
  • Make the visual level counters an even distance apart.

 

SlimeTilesThe last thing I want to show this week is the Slime Tiles. This is the finished art of a mechanic that has been finished for a while. Basically all the Hiragana that don’t have a consonant (a,i,u,e,o) when used with another Hiragana will change the other Hiragana. For example using o (far right in above gif) with a Ka (far left in tutorial demo gif) will change the Ka to a Ko. Once used with another tile the changed tile will have that same transparent slimy color over it so the player can track the change. I really like this mechanic because it solves a couple of problems. First it makes a,i,u,e,o function differently from other kana that have both a vowel and a consonant. The reason this is important is that if they didn’t behave differently they would just restrict level design space for no real reason as they can only be matched with similar vowels as they have no consonant. Secondly they get the player to focus on the sounds of the tiles in interesting ways. This way the game isn’t just a puzzle of “how to I move the tiles around in the most efficient way”?

So that’s my progress for the week. If anyone has any questions about Kana Quest or design choices please feel free to ask!

Till next time.

 

So I have been in Japan for the last year teaching English to Japanese kids. Now that I am back in Australia I am going to be focusing on making a bunch of work for my portfolio that I can use to get a job.

So for the last two days I have been working on making a tutorial script that I can use for any of the games that I make in the future (as well as games that I’m currently making). What the script will do is the designer will tell it how many events there are to be in the tutorial. Then select what type of events they will be. And then use the controls on the script to adjust the events for final use. You can see the user interface for the script below.

TutorialScriptScreenShot

The reason I am working on this script is that I have been working on a game that teaches the player to read Hiragana (the first of the three lettering systems in Japanese). And the rules are a little confusing at first. This means I need a good tutorial. And the only way to get a good tutorial is to iterate on it a lot. But previously I have been making the tutorial with scripts that only fitted that tutorial. Thus I would have to re-code the tutorial every time I wanted to change something.

This script will allow me to change my old tutorials quickly as well as make new tutorials.

Also, a quick afterword. I will make regular updates to this blog to document my progress. As a result there will be more work in progress type posts rather than finished product type posts in the future.

Theo