YYZ

The game has been going on pretty nicely even though I spent almost a whole day solving bugs and had no ‘actual’ game progress. In preparation for a main menu revamp (my main menu currently looks like this:

The main menu uses the default built-in GUI from Unity, but that’ll change. I have drawn at least 4 backgrounds for the main menu, including a really awesome looking game logo.

Here is one of the backgrounds I made. It’s based on existing graphics, so not much work has to be done. Each time you load the main menu, a different background is displayed. I made the background displayed random at first, but afterwards, changed it so that it chooses the background based on a fixed and regular cycle. You won’t see the same background two times in a row, which is cool if you ask me. Much better than randomization.

The main menu revamp will also include an auto-save feature which backs up player’s save file automatically in case they lose their original save. It doesn’t work if the player still chooses to wipe his cookies or clears his cache etc, but it should be able to prevent saves lost through power outages or browser crashes.

Going HD

I have recently made the decision to go mobile with this game. Going mobile actually gives me nightmares because of a past experience. All the jargon about SDKs and shit drive me nuts. It’s really complex and not just a simple snap of the fingers to port it to mobile. I used Eclipse to develop a very simple mobile game in 8 weeks. It was for an assignment which I got distinction for, but it was really crazy for me, but it was also very memorable because it was my very first playable game. I think I vowed never to use Eclipse again. My friend insists it’s easy though, but he’s a programmer and I can’t even handle coding on PC!

Porting to mobile required some restructuring of code, but upon porting to mobile, I noticed that certain graphics were blurry. Some of them could be resolved via changing settings, while others required me to redraw higher res graphics.

I got a bit paranoid and drew some of my UI icons at absurdly huge sizes. A gear icon to toggle settings in the game is around 40 x 40 pixels in size but was drawn at a 400 x 400 size. I believe the downside is this increases game size though.

If this is the size of a button, I can’t imagine the size of the background…

Upgrades

One thing I have seen from players’ comments on games is that they want their character’s graphics to improve when they upgrade them. Apart from increasing their character’s stats, their appearance should change accordingly and look more powerful as well.

In this game, I planned to draw 3 unique graphics per character to show significant advancements in the character progression. However, when I played around with colours, I learned that I can do even more!

I had a new idea of class specialization – For example, you can upgrade your Priest to be a “Battle Priest” for more damage, a “Support Priest” to heal greater amounts of HP, or a “Holy Priest” who has higher survivability. This can be played around according to each individual player’s preference. Early on in my game, heal power is very important, so perhaps the player would upgrade his priest to be a support, but later on, damage becomes more important so he can change his speciality to damage.

Alternatively, because this is not part of the original game design, it might cause balancing issues. If I do not wish to add specialization, I will still add the new graphic variations via another way: Every 100 levels of upgrades, I plan to change the character’s sprite to have him appear more powerful.

Colour changes may look easy and effortless, but it still requires some work to really pick out the best colour palette and to also experiment with toggling each colour separately – topwear, bottomwear, etc. This is where I turn to my friends / family to ask for feedback on which colours look the best.

I marked in blue the generally favorable ones in terms of graphics, and marked in red which ones appeared the most powerful, so I can set them according to the respective character upgrade tier.

Together with a “job advancement” feature, this will mean each character will have 3 x 3 graphic variations = 9 different sprites for each character. 3 of the graphics are unique, requiring new drawings, which means I need to reanimate each character’s attack, idle and death animations at least two more times. Speaking of which…

Animations

I have had great progress with creating animations. I am now able to semi-automate generation of a skill spritesheet, which is a great convenience because I can now focus more on drawing the actual animation.

Previously, if I drew 20 frames of an animation, I would have to manually move each “picture” or frame to a very specific coordinate in Photoshop. For example, the first frame is at (0,0), then the next at (500, 0), then at (1000, 0).A one pixel difference could be very obvious and create jerky and badly vibrating animations. Because my frames are so far apart from each other, it  meant that making changes to one frame of the animation made it hard for me to compare to the previous and next frame because they don’t overlap (which makes it hard for me to apply onion skinning, an animation technique my friend taught me).

Onion skinning on a character

But now, I don’t do the movement. Instead, I export each individual frame to a PNG via a built-in script in Photoshop! Watching the script work was really damn cool as it automatically generated the sprites I needed. But this means photoshop gives me 20 separate pictures in my folder that I need to merge into a single spritesheet.

That’s where my old friend, TexturePacker, came in handy. I drag in the 20 pictures, input some settings, and it creates one, nice clean spritesheet into Unity. Technically, I could opt out this step because Unity accepts 20 pictures to make one animation, haha, so even more steps saved!

The animation above is a rough completion. It still requires final touch ups as well as improvements to its colour.

Here is another one of my more completed animation. The last few frames are a bit jerky and the movement isn’t very smooth so it still requires some touch ups as well. This skill animation is for ‘Dragon Skin’, a party buff that decreases damage you take from enemies.

Skill Types

I classified the types of skills I intend to have in this game to 4 main types. I have managed to code 4 skill types so far:

• Passive (provides a permanent stat boost to character, easiest to code and no animations required)
• Buff (when activated, gives a temporary boost to yourself OR party members for a few seconds. I coded this before in OldStory but is challenging to do in this game because I have to make a character’s buff work across multiple characters and single characters depending on the nature of the buff)
• Support (similar to a buff, but gives an instant boost, such as healing a party member’s health)
• Active  (an attack skill that deals damage to the enemy. The hardest to code.)

For active skills, I coded them in such a way that each character has a skill queue. Instead of immediately casting an attack skill, say “Triple Stab”, it adds this skill into a queue. When the player is in the ‘ready’ state, he then activates the first skill in the queue until the queue is empty. I made it this way because sometimes, the player can use a skill when the enemy just died, so your skill literally hits air before the next enemy respawns. This way, the player can spam all his attacks and not worry about overkilling or hitting nothing as leftover attacks will be stored and used on the next enemy.

Also, unlike OldStory, you can use multiple skills at once and they will be casted the moment they are ready, which is pretty cool because you can combo and stack several attacks together.

When I was done coding that, I would soon realise that the real challenge was in coding the buff system, which took me more than a couple of days to tweak and refine. It’s the party buff mechanic that makes life difficult where I have buffs that don’t seem to count down on the deselected character, or a same buff lasting two different durations on separate characters etc.