Tuesday, January 26, 2016

Art Dump 2

So far so good. The design continues to change as I create assets - arranging them on the screen, mixing and matching to come up with new possibilities. Each day I sit back and discard the art that did not come to fruition. There is a lot not shown in this screenshot:


The other approach would have been for me to write 95% of the code with placeholder art, which would have been replaced near the end. That approach... previously has not worked out well for me. I've come to prefer this approach instead. So much of the original design has improved during the past couple weeks.

Tuesday, January 19, 2016

Art Dump

Moving right along. 

I forced myself to try new approaches for creating the art, particularly taking advantage of the Pencil Tool in Flash for outlines on props and characters. I break the lines down into "shapes" to prevent them from glitching when I splotch shadows and highlights. Consequently, the outlines on objects are a lot smoother, compared to using the brush tool which gives inconsistent thickness.


This section down here at the bottom, is what you will see most of the time. The extent of the monkey's vine will be off screen.

Saturday, January 16, 2016

Onward to 2016!

Onward to 2016! While I find a potential publisher for Zombie Guard and issue patches about once a week, I look forward to this year. This blog post will serve as my resolutions for this year. Here are a few:
  • Fully develop six marketable games for any platform...! Excludes game jam entries.
  • Blog more frequently.
  • Become proficient in HTML5.
As I reflect on my previous experience as a developer, I have come to the conclusion that I greatly prefer smaller projects that involve less time from start to finish. Smaller than Zombie Guard (one year) and Last Town (four months)

Realistically to achieve six this year, I will have to average two months for each, taking into consideration the down-time between projects. This is actually a realistic goal. Defend Your Nuts, for example, was six weeks of development time and I have a lot more experience now.

Lately I got to evaluate all kinds of tech. I settled on Phaser for HTML5 browser games written in LiveScript - a language with particular syntax and features I have come to love love love! LiveScript is incredibly powerful and compiles instantly to JavaScript so it saves me a lot of time. Here is a screenshot of some preliminary code I wrote:


I find the LiveScript syntax to be very effective. Loops, array operations, and boiler plate JavaScript for classes is much easier to achieve.

Here is some example code from the LiveScript website:


Not only is it less effort to write, but is less overall code to digest at a glance. I actually do find operations like this:

[1 2 3] |> map (* 2) |> filter (> 3) |> fold1 (+)
To be intuitive. It takes an array of values (1,2,3), multiplies each by 2 into a new array (2,4,6), filters only values greater than 3 (4 and 6) into a new array, and then calculates the sum starting from the left to be 10 (4 + 6). Of course this is a very generic example. Frankly, I find it easier to understand at a glance, compared to dozens of lines of loops and ugly braces defining scope everywhere. It is a Currying functional style that I have always wanted to embrace, starting with my days, years back, exploring the purely functional language Haskell.

As for art, Adobe Flash will continue to be my preference, for animation and asset creation. I find it so efficient to scale and transform basic shapes, and add splotches of shadows and highlights. I started using the Pencil Tool for cleaner lines. Lately I have been fairly inspired by the minimal art style in Scribblenauts so I would like to mimic it for minor props and backgrounds.

Here is a preview of some of the assets for my next project:


I already wrote a Phaser template for this tool called Animo, which composites Flash movie clips into sprite atlases, better than other tools I evaluated. Animo is no longer found on the Web because seemingly the company went under, so I keep my full version copy safely.

Tuesday, December 22, 2015

Trailer for Zombie Guard!

I would like to present my trailer video for Zombie Guard! Turn the volume up and max out the quality to 720p.


It helped tremendously to have an amazing soundtrack, licensed royalty-free, to apply the video clips in unison. Creating this trailer was a major milestone, as I was forced to fix bugs and finalize features for the recordings. There are still some balance issues and bugs here and there, but nothing major as far as I know. I will be submitting it to FGL.com for testing on iOS and Android.

Friday, November 20, 2015

Data Driven

I must say that data driven programming can be very effective in games. What does data driven programming mean to me? Writing a generic system that takes in variables to be used during processing.

For example, a generic system for game projectiles where variables include: speed, image file, sound effect, shoot delay, etc.

Another system for particle effects.

Another system for zombies.

Another system for weapons.

Etc.

Exposure

My first exposure to this approach was way back in 1999, when I explored the Kingpin: Life of Crime game source out of curiosity. I considered sprinkled code like this to be relatively welcoming:

G_Items.c from Kingpin: Life of Crime
At the time I found most of the other code to be rather esoteric. Even without programming expertise, one can safely assume the code above represents data for a fuse key. It is noticed while playing that  "world/pickups/coil.wav" is the sound effect that plays when picked up, and uses "models/pu_icon/coil/tris.md2" as an inanimate 3D model file. At the time, I modified some of these values and ran the game to my amusement, eager to learn more.

Data driven in Zombie Guard

Fast forward to 2015. Such a seemingly minor experience had a drastic impact on me. Most of my game projects are data driven - partly out of habit and partly out of simplicity. For example, here is the data for the blunderbuss that can be upgraded five times in Zombie Guard:


Additionally, here is one of the five sets of data for the blunderbuss at rank 1, referenced in the wtypes table inside g.wg_blunderbuss:


Data like this is passed into the function for shooting the weapon, and the generic system for projectiles uses this data as well. It is easy to compare and contrast various weapons.

One of the greatest benefits of this approach is that it scales well as content is added to a game project. For example, I could easily create a new weapon by duplicating just the data for this blunderbuss and modifying some of the variables.

Any fancy special case behavior can be controlled through a new value.

Sometimes hard coding is better

Sometimes a data driven approach is not always better. I was fortunate to have forgone the approach in Defend Your Nuts for the weapons, instead, opting for a hard coded approach.

Defend Your Nuts features a bow with variable number of arrow projectiles, an instant single-target rifle, a bazooka with baby rockets, and a shotgun with variable instant damaging pellets. How could I generalize this? It would have been over engineering, since I knew firmly I was never going to append additional weapon content.


There are two examples of shootEquippedWeapon above. The first is the data driven approach, which for such few number of weapons, would have been more complicated than the second approach that ultimately I pursued.

In other words, data driven approaches can be suitable for large volumes of features that share similar functionality, specified through a set of data. It depends on the situation. Otherwise, other approaches can offer more flexibility.

Room for growth

I'll probably continue to make use of data driven programming. In the future I want to utilize Excel spreadsheets as a means of authoring my data. That way, data variable names are only written once for each column, useful graphs can be generated off to the side, computations can be utilized to help me balance the game.

In the first example above from Kingpin, written in C, you would have to consider the layout of the structure and maintain the correct order of value types. It was just the nature of the language. In my examples using Lua, equating the variable names gets rather tedious too.

I see spreadsheets as being very useful in my future projects...

Sunday, November 15, 2015

Battle Modifiers

Lots of things to blog about! For this post, I want to focus on a small feature that took a few iterations.

I like to sprinkle in a bit of randomization into my games. Little surprises here and there to keep things interesting. In my previous game Zombie Tactics, characters could go off and scavenge for supplies during a battle. It offered risk versus reward - scavenging with many characters would provide the best rewards, but the player would risk getting wiped out with the remaining characters during a battle. On the other hand, not scavenging would be safer in the short run, but would forgo improved equipment and bonuses in the long run.

The simplest approach I took for Zombie Guard was a spinner wheel, reminiscent of prize wheels at a carnival. It was designed to offer temporary benefits and disadvantages. It was decorated with placeholder art. First of all, I was discouraged to spend a great deal of time making it look presentable. It was confusing too. Even worse, tapping the wheel did not feel very interactive. I like to at least give the illusion of choice.



The second iteration was just naive grid of selections. At least here, it felt like there was a choice, even though the function was just simply returning a random battle modifier. Overall this approach felt very rushed. With this implementation of the feature, it worked, but the the game was better off without it.



The latest iteration uses props from the current mission as objects to "search". There is a chance of finding something advantageous like extra ammo and landmines, at the risk of uncovering temporary setbacks like weakened defenses and stronger zombies.



It took a bit of effort to squeeze everything onto the screen. I could not write the names of the battle modifiers and the descriptions because it was just too much text on the screen. Also to prevent the player from forgetting the modifiers, sequentially I present each one being applied to the battle area with the description.

I found some good sound effects and utilized an existing particle effect. This feature now is more intriguing and cohesive with the rest of the game. 

It does take a bit of time to add in all those little movement transitions of the interface, but is well worth it. Corona helps make this easy through transitions with curved interpolation options. For example, the movement of the perks is "outExpo", meaning an exponential curve that starts very quickly and ends gradually.

Image by CoronaLabs
easing.inExpo ; easing.outExpo ; easing.inOutExpo ; easing.outInExpo
My general approach to game design is to offer a steady amount of progression of unlocked features, that is all polished with cool art, animations, special effects, and audio. If the game difficulty is balanced correctly, it can offer steady "fun" and keep the player engaged over time.

Friday, August 28, 2015

Zombie Guard

My latest project tentatively titled "Zombie Guard" at last nearly is completely finished!


Yes, there were delays to reach this point. It happens. There are many reasons, but importantly I made it to the end, so I am relieved! I'll write more info in the next post.. in the meantime, here are some screenshots: