Milestone reached

There I sat today, in one of my favorite cafes in Chiang Mai called Ombra. It is decorated with American and European antiques. Organized, to avoid seeming gaudy or noisy. It feels like visiting someone's home. Alternative rock plays in the background, from a hidden speaker near the unplugged record player. A typewriter sits on a display desk, near books and records of classic rock bands. The hot cafe lattes contrast with the cold air-conditioning. I realize hours have passed, when my laptop alerts me that its battery is running low.

Other days I may visit the London Tea Room, which is like sitting in the lobby of Fawlty Towers.

The spacious cafe called CAMP is open 24/7 on the top floor of the nearby mall. The usual selection of Thai food vendors are just one convenient escalator ride down.

But back on track, I deployed a build of my game to my Android phone and then left Ombra. It looks and sounds great, thanks to my shopping sprees in the Unity asset store and sonniss.com. This game has a lot of potential if I keep at it. Here I am holding it up in my apartment, before going out for dinner around the corner:

Unlike my previous titles, I plan to go for an early release, but continue to nurture it full-time. It will get the attention it deserves through additional characters, items, features, and things requested by the community. The first version probably will only contain 50% of the anticipated total content to allow for flexibility.

A mini debug tool in Unity

There are many ways of creating a tool to debug a game. Console commands on run-time is a common one. In-game rendered menus is another. In Unity I have been using a simple game object that has a script that exposes check-boxes which act as either toggles or buttons (they automatically get unchecked). It's sufficient for my needs. It's like having a handy dandy remote control with a bunch of options to speed up testing.

The inspector of the single debug game object in the Unity scene will look something like this:

And the script is as simple as this:

 using System.Collections;  
 using System.Collections.Generic;  
 using UnityEngine;  
 public class EPDebug : MonoBehaviour {  
      public bool toggle1;  
      public bool toggle2;  
      public bool option1;  
      public bool option2;  
      public bool option3;  
      [HideInInspector] public static EPDebug instance;  
      public void Awake() {  
           instance = this;  
      }  
      public void Start () {  
      }  
      public void Update () {  
           base.Update();  
           if (toggle1) {  
                // do stuff each frame  
                // other game objects can check this variable too  
           }  
           if (toggle2) {  
                // do stuff each frame  
                // other game objects can check this variable too  
           }  
           if (option1) {  
                // do something once  
                option1 = false;  
           }  
           if (option2) {  
                // do something once  
                option2 = false;  
           }  
           if (option3) {  
                // do something once  
                option3 = false;  
           }  
      }  
 }  

I have a toggle that has the game print out verbose information regarding game states and whatever information suits me. I use the button options for creating spontaneous game objects and invoking commands like giving some in-game currency. This debug menu can be extended with number fields to change global variables too.

Big upcoming milestone

I am working towards an important milestone of this project - a fully playable demo. It will showcase an entire prearranged battle to demonstrate the general gameplay. It will be fairly polished, with special effects and audio that I plan to purchase in large commercial packs. From there, it will just be a matter of going into full production on the rest of the content and features, like the hero classes, enemies, and areas.

I have been contemplating some of the design features...

Damage Types and Defense Stats

The damage types are: physical, fire, cold, poison, and arcane. All creatures tend to focus on one or more. I considered defense stats for all these, but as a player, it gets unnecessarily complicated quickly: "This creature has half the cold defense as fire, but my fire spell does x more damage, should I use that or poison at wait.. what was the poison defense again? It is a goblin, which is green, so is that more or less resistant to poison? Screw it, I'll just attack with fire and pretend it was the ideal strategy."

...So, instead, defense stats only will be physical and magical that groups all the elements into one. In order to create distinctions between the elements, some creatures in particular areas can be completely immune or resistant to one, such as fire. It ought to force the player to utilize different heroes at different areas, rather than just blindly grinding away on a select few.

Weapons

Each of the player's heroes can wield an interchangeable weapon for basic attacks and passive bonuses. I considered having an inventory system with procedurally generated weapons and a crafting system. Instead I am just going to individually draw and author five named weapons for each class type, depending on the desired play style. The specific names will be easier to translate, rather than procedurally generated ones with names like: "Cruel Swift Dagger of Burning Flames". The grammar would not hold.

Upgrades for Skills and Equipment

I almost always use a five-rank upgrade system in my games. Instead I may extend to ten, requiring rare and limited reagents past rank five. Otherwise there is too much incentive to just dump everything into one specific upgrade that ends up skewing the difficulty curve too much.

Prototype makeover

I purchased some large art bundles from the Unity asset store. Backgrounds, icons, and special effects always have been my weaknesses, so just buying royalty free art is a sensible investment. Having the art early on can influence design in unexpected and beneficial ways too.

I will continue to paint and animate my own characters. I use a tool called Spine which allows me to programmatically interchange pieces like weapons and gear. I chose to use animals as the fantasy heroes because it fits better in the premise of the game. Plus, animals are gender-neutral, and it rids having to be politically correct in having a specific number of different races, especially for a game that will be localized worldwide.

Match 3 RPG

I am likely going to make a match-3 RPG. Character abilities can be triggered by placing a pattern on the grid, that must match the locations of previously destroyed cells (illustrated by orange cells in the screenshot below). It will be made in Unity using C# and the Spine animation tool. The same tech was used to make my latest finished and soon to be released game Pizza Bot.

Prototype

This next match-3 project likely will be fantasy themed because I already have a whole bunch of character art. Painting backgrounds and icons is my weakness, but I can buy some through the Unity asset store. I spotted some great special effect packages too.

Match 3 always will be popular, and is already "fun" from the beginning. The design challenge is going to be crafting all the interesting features that extend out the game, while offering sufficient strategic elements to prevent the experience from getting dull and monotonous.

I believe as long as there is gradual and continuous progression through occasional unlocking of interesting features, then the game will surely be a success. A game like Zombie Guard is not necessarily fun because of say, the weapons, but rather, the unlocking and upgrading of the weapons. This has been a general design focus in all my games. Typically I strive to create the core of the game, and then insert a lot of content with data driven systems for weapons, skills, items, and AI character types.

Since this will be a turn-based match-3 game, I can write some simple AI to play-test the game for me. I have a spare phone to have AI play stable builds 24/7.

From the very beginning I will be setting the game up for easy localization into other languages. If done correctly, all I would have to do is gather translations privately from various people who have already contacted me. Ideally, it will be easy to update and append translated text through external data files.

So, that is that.

Two Goats

Goat Mechanic has been updated and Gassy Goat has been released...

Goat Mechanic

I have updated my previous app Goat Mechanic on Google Play and redistributed it on the Apple App Store. It started as a game jam entry that got turned into a standalone app. I integrated Google Admob interstitial (video) ads. Players can wait for in-game currency, or watch a 30 second video ad, or purchase currency with real money. It is a bit shameless, but it works.

This is an older game, written in Lua with the Corona game engine. This project uses a tool called Spriteloq/Animo, used to consolidate the art; the tool no longer exists because it was sold to a company that is no longer in business. Thankfully, I had a backup within the project's depot.

Gassy Goat

At last, Gassy Goat has been released - a game that had been finished for a long time, now available for download on Google Play. I will submit it to the Apple App Store in a week if there are no major issues.

Gassy Goat is an HTML5 game written in Phaser with the language LiveScript that compiles to JavaScript. The code is obfuscated with Minifier.org, and packaged as an Android APK with Cocoon.io using the AdMob plugin for interstitial ads. Yes, there are definitely many layers of technology involved here.

...I'm glad to be near the end of list of tasks. Only Pizza Bot remains. There are some older apps that I considered revising, but I have determined it would not be worth the time.

Zombie Guard update and return to iOS

Zombie Guard has been given a much needed update! I went through and increased the game difficulty, added different controls for vertical movement, updated to the new ads plugin and Corona game engine for many benefits including improved performance.

Updating an app to a new version is a bit slippery. I had to carefully ensure that the game can handle the save files of the previous version. Plus, upgrading to the new AdMob plugin had issues. Is any of this difficult to program? No, but there is zero room for error because the update will gradually affect up to 50,000 current users.

The app recently was declared an Editor's Choice through Google in the category of zombie games. Recognition like this, and all the YouTube videos of players enjoying my work is what motivates me to continue.

Due to this article, I have improved the default controls for movement by allowing pinpointed touch location rather than buttons. Plus, all buttons can be enlarged which might feel more comfortable on smaller phones. Settings can be changed back through the options.

Zombie Guard sits at a million downloads on Google Play. It is making its way back onto the Apple iOS app store (and most of my other apps). Building the app even through the Corona engine requires a modern Mac, so I'll be renting and connecting remotely to one through MacInCloud.com. To my surprise, Corona already is installed.