Shikaku Madness on Google Play · July 27, 2012

Another day, another app store. Here’s Shikaku Madness on Google Play. I was able to use my brand new Nexus 7 to test/publish an Android Cordova build of the game.

Unfortunately, the Javascript performance of the Android WebView isn’t quite as good as the iOS UIWebView; the main user interaction (tap + drag to create rectangles) is faster on my two year-old iPhone 4 than on the Nexus 7. However, CSS transitions perform great on both devices.

I was hoping to integrate a Google Play in-app billing Cordova plugin, so as to make the game available for free (and sell additional puzzles), but the only plugin I could find didn’t seem to be very robust, and didn’t work for me “out of the box.” I considered writing my own plugin, but that in itself is kind of a daunting task, due to the fact that I have no Android/Java experience. Who knows, maybe if I get real bored (or if the Android version doesn’t sell any copies) I might try to make a free version.

In any case, if you have an Android device, check it out!

Add a comment · Posted by in Bizness, Games · , ,

Shikaku Madness on the Mac App Store · July 23, 2012

Just a quick note to say that I ponied up the $100 to publish apps on the Mac App Store, and dropped a copy of Shikaku Madness in there. It’s part of my experiment to port “HTML5″ games to as many platforms as I possibly can. I was inspired by Lost Decade Games, who wrote up a basic tutorial about embedding a Javascript app into a Cocoa WebView. Unfortunately, their tutorial is slightly out of date, so I spent a bit of time struggling to find a way around some annoying issues. One of the weird quirks of the WebView is that it doesn’t persist localStorage by default, and there is apparently no way to enable it without resorting to a private API call (which we all know, are the devil). The app was approved, though, which I guess means that particular call can slide under the radar. When I have more time, I’d like to learn more about writing an Objective-C/Javascript bridge (this is something that’s officially supported; it’s how Cordova/PhoneGap plugins are able to work) to implement in-app purchase.

I probably wasted a bit of time fussing around with creating my own custom project. However, the OS X Cordova port is pretty bare bones at this point, which is why I didn’t use it. Maybe a better choice would have been to try MacGap?

In any case, if you haven’t yet, you can check out Shikaku Madness in the Mac App Store.

Add a comment · Posted by in Games · , , ,

Experimenting with Javascript · June 26, 2012

In my last post I complained about dealing with all the static images that one has to create in order to support multiple iOS device resolutions. I was just getting so frustrated dealing with layouts that required 3 different static images, and having to jump through hoops whenever I wanted to display some sort of variable length text. About that time, I was tasked with creating a Javascript-based game at work (the very first of my life, which was kind of a milestone), with the requirements that it be DOM-based (not sure why that requirement existed, since the graphics were all bitmap, but I digress). Anyway, my thoughts turned to using HTML and CSS for the interface of Shikaku Madness, the game I was working on. It was a perfect fit, actually, since the UI could be easily recreated with HTML elements. While I promised myself that I would finish the Objective-C version of the game first, before experimenting with unproven technology, the lure of doing something new proved to be too much. Within a week I had ported most of my main game logic over to Javascript (CoffeeScript, actually).

Another plus for creating a game with Javascript is its’ portability and multiple deployment targets. I could put a version on the web for prospective players to try for free, and also port it to a variety of different platforms using a tool like Apache Cordova. And there could be additional porting opportunities in the future: Microsoft is getting on the Javascript bandwagon these days, making Javascript a first-class citizen for both Windows 8 and Windows Phone 8, and Mozilla is working on the B2G (Boot-to-Gecko) project which will allow web apps native access to a mobile device. While it’s not a “write once, run anywhere” situation, Javascript has the potential to run on many more platforms than Objective-C does.

In the process of porting my game, I learned quite a few interesting things about developing “HTML5″ games (kind of a misnomer), which I thought I would share here. First off, Javascript performance in Mobile Safari is quite crap. Even running with the “Nitro” Javascript engine, it’s considerably slower than your desktop. Shikaku Madness is about as simple as you can get for user interaction — only one touch is being tracked at a time, and a single HTML element’s size/position is being updated based on that input. Even still, the UI lags behind user input… it’s not unplayable, but it’s noticeably slower than native code.

There are a few tricks you can do to make some interactions feel more responsive. Using the CSS3 transform property, you can animate HTML elements with hardware acceleration, which makes movement much smoother. Instead of relying on a “click” event to trigger button actions, you can listen for a “touchstart” event, which fires instantly when the user taps an element. Even with these improvements, though, the app isn’t quite as responsive as you would expect. I feel like the performance is almost there, though.

Mobile Safari’s audio support is also quite crap. Even if a sound is preloaded, there’s a noticeable delay when the sound is first played. Another annoying problem is that sound effects played through Mobile Safari ignore the hardware mute button, and the volume can’t easily be changed by using the hardware buttons (you have to hit the +/- buttons at the exact same time the sound is being played, otherwise iOS thinks you’re trying to adjust the ringer volume).

Although I chose a DOM-based UI instead of using the canvas element (so that I could use CSS to style my interface), I learned that it’s not quite as easy as I thought to have a totally dynamic application size. In fact, the version of Shikaku Madness that I submitted to the App Store uses fixed element width/height and font sizes. I’m still working on making my CSS dynamic enough to handle arbitrary viewport sizes, which will be a necessity if I try to publish an Android version. The key problem is that it’s not possible to dynamically scale font size using CSS alone. The other problem is that I need to maintain a 2:3 aspect ratio in order to keep the layout consistent. I think I’m going to solve this by querying the viewport size, then modifying the app’s container element and font sizes at runtime.

I’ve just scratched the surface in regards to getting Shikaku Madness on multiple platforms. My next step is going to be publishing on the Mac App Store, then trying for a Google Play release. After that I might try submitting to the Mozilla Marketplace and whatever the Windows app store is called… as long as I can get enough motivation to keep working.

Regardless, you should definitely check out the Shikaku Madness demo page I set up. The app should run with recent versions of Firefox, Safari, and Chrome. It might or might not work with IE9/10. Sadly, I don’t have a recent enough copy of Windows to try out the modern versions of IE. Let me know in the comments if it borks on IE. Other comments and suggestions are welcome too!

Add a comment · Posted by in Programming · , ,

Resolution Woes · May 9, 2012

Oh, my unbridled naivety! My last post discussed a new game, and how quickly it was coming together. Of course, any project is easy to start, and the real difficulty is dealing with the soul-crushing minor issues that rear their heads when you’re almost done. In my case, dealing with image assets for 3 different screen resolutions (I use iPhone @2x assets for iPad) has sucked up a lot of time, and caused me to write my own custom class to superimpose TTF labels on top of image-based buttons, instead of creating hundreds of static button images. My game isn’t even very complex, so I can’t imagine the pain that an extra @4x resolution would cause for other developers.

All this annoyance from creating UI using static images has made me wish for the flexibility of CSS when programming interfaces. So much so, in fact, that the next project I start is going to use a combination of HTML, CSS3, Backbone.js and CoffeeScript, all wrapped together with Apache Cordova. It’s not the Canvas- or WebGL-based future that many envision, but manipulating the DOM will allow me to use CSS3 for graphics. It’s not like the puzzle games I’ve been making are very demanding in terms or performance, either. The lure of this new tech combination is so tempting that I have to actively resist the urge to re-write Shikaku Madness, but I’m holding strong and will finish up the Objective-C version before starting anything else.

Anyway, for you fine folks who are getting annoyed with creating UI assets in multiple resolutions, here’s a simple class I wrote to hopefully streamline the process: CCMenuItemImageWithLabel.

//  CCMenuItemImageWithLabel.h
//
//  Created by Nathan Demick on 4/17/12.
//  Copyright 2012 Ganbaru Games. All rights reserved.
//

#import "cocos2d.h"

@interface CCMenuItemImageWithLabel : CCMenuItemImage
{
    // Label w/ text on the button
    CCLabelTTF *label;
}

@property (nonatomic, retain) CCLabelTTF *label;

+ (id)itemWithText:(NSString *)text block:(void(^)(id sender))block;
+ (id)itemWithText:(NSString *)text size:(NSString *)size block:(void(^)(id sender))block;

@end

Basically all this class does is help you add a TTF label onto a blank button background. There’s a method for creating a default sized button, and another that you can customize to handle multiple button sizes (I have small, normal, and large in my app). Check the implementation:

//  CCMenuItemImageWithLabel.m
//
//  Created by Nathan Demick on 4/17/12.
//  Copyright 2012 Ganbaru Games. All rights reserved.
//

#import "CCMenuItemImageWithLabel.h"

#define kFontName @"insolent.otf"

#define kDefaultFontSize 24
#define kLargeFontSize 26
#define kSmallFontSize 14

#define kDefaultNormalImage @"button-background.png"
#define kDefaultSelectedImage @"button-background-selected.png"
#define kLargeNormalImage @"large-button-background.png"
#define kLargeSelectedImage @"large-button-background-selected.png"
#define kSmallNormalImage @"small-button-background.png"
#define kSmallSelectedImage @"small-button-background-selected.png"


@implementation CCMenuItemImageWithLabel

@synthesize label;

- (id)init
{
    if ((self = [super init]))
    {
    }
    return self;
}


+ (id)itemWithText:(NSString *)text block:(void(^)(id sender))block
{
    int fontMultiplier = 1;
    
    if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad)
    {
        fontMultiplier = 2;
    }
    
    // Create button
    CCMenuItemImageWithLabel *item = [self itemFromNormalImage:kDefaultNormalImage selectedImage:kDefaultSelectedImage disabledImage:nil block:block];
    
    // Create label + append to button
    item.label = [CCLabelTTF labelWithString:text dimensions:CGSizeMake(item.contentSize.width, item.contentSize.height) alignment:CCTextAlignmentCenter fontName:kFontName fontSize:kDefaultFontSize * fontMultiplier];
    item.label.color = ccc3(0, 0, 0);    // Tweak this based on your button background image
    item.label.position = ccp(item.contentSize.width / 2.1, item.contentSize.height / 8);    // Tweak this based on your button background image
    [item addChild:item.label];
    
    // Return button
	return item;
}

+ (id)itemWithText:(NSString *)text size:(NSString *)size block:(void(^)(id sender))block
{
    int fontMultiplier = 1;
    
    if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad)
    {
        fontMultiplier = 2;
    }
    
    // Create button
    CCMenuItemImageWithLabel *item;
    
    if ([size isEqualToString:@"small"])
    {
        item = [self itemFromNormalImage:kSmallNormalImage selectedImage:kSmallSelectedImage disabledImage:nil block:block];
        item.label = [CCLabelTTF labelWithString:text dimensions:CGSizeMake(item.contentSize.width, item.contentSize.height) alignment:CCTextAlignmentCenter fontName:kFontName fontSize:kSmallFontSize * fontMultiplier];
        item.label.position = ccp(item.contentSize.width / 2.1, item.contentSize.height / 10.5);    // Tweak this based on your button background image
    }
    else if ([size isEqualToString:@"large"])
    {
        item = [self itemFromNormalImage:kLargeNormalImage selectedImage:kLargeSelectedImage disabledImage:nil block:block];
        item.label = [CCLabelTTF labelWithString:text dimensions:CGSizeMake(item.contentSize.width, item.contentSize.height) alignment:CCTextAlignmentLeft fontName:kFontName fontSize:kLargeFontSize * fontMultiplier];
        item.label.position = ccp(item.contentSize.width / 1.8, item.contentSize.height / 8);    // Tweak this based on your button background image
    }
    // Default
    else
    {
        item = [self itemFromNormalImage:kDefaultNormalImage selectedImage:kDefaultSelectedImage disabledImage:nil block:block];
        item.label = [CCLabelTTF labelWithString:text dimensions:CGSizeMake(item.contentSize.width, item.contentSize.height) alignment:CCTextAlignmentCenter fontName:kFontName fontSize:kDefaultFontSize * fontMultiplier];
        item.label.position = ccp(item.contentSize.width / 2.1, item.contentSize.height / 8);    // Tweak this based on your button background image
    }
    
    // Create label + append to button
    item.label.color = ccc3(0, 0, 0);    // Tweak this based on your button background image
    [item addChild:item.label];
    
    // Return button
	return item; 
}

@end

Not very elegant, but you get the idea. Hopefully you can use this as a starting point to help shorten the time you spend doing grunt production work on UI resources. Any other tips or suggestions for dealing with multiple devices and screen resolutions? Hit me up in the comments.

1 comment · Posted by in Meta, Programming · , ,

Preview: Shikaku Madness · April 6, 2012

It’s been a day of breaking blog silence! Part two of the Unity tutorial probably isn’t coming any time soon, in part due to the fact that I’ve been pluggin’ and chuggin’ on a new game. Yes, you can kick me now: it’s called Shikaku Madness, and yes, it’s a game based on an obscure Japanese puzzle. I’m trying out a few new ideas based on what I’ve learned from developing iOS apps for the past two years.

First, here’s the sad story: I was pretty lucky that the first app I developed was based on an established game. People know what “nonograms” are, and are actively searching the App Store for such games. I get more downloads of Nonogram Madness now than when I first released it, even. My second app, Revolve Ball, suffers from a “discoverability” problem. Even though most people who try it out think it’s pretty interesting, there’s no way that people can find it organically. They don’t know it exists, and therefore don’t know to search for it. If my first app (that I’d spent so much time on) had clunked the way that Revolve Ball has, I might have given up.

So, for my next game, I’m making an adaptation of an existing genre: something that appeals to logic puzzle fans, and can be discovered organically. I’m also going the “freemium” route of making the app free, while selling more puzzles via IAP. Theoretically this will lower the barrier for entry, and get more potential customers. And, in another attempt to get organic promotion, I’m including an in-game puzzle editor, and allowing players to upload/share levels via the app’s website. Who knows if all this nonsense will be successful at all? Not me, that’s for sure. But the positive thing is that I’ve been able to crank this game out pretty quickly in the past three weeks, due to actually having some experience w/ Cocoa and cocos2d now.

Anyway, enough about bizness philosophy. What is “shikaku?” It’s a type of logic puzzle, of course, where the objective is to cover a grid with squares. The grid has numeric clues scattered on top of it, which help you know where each square is supposed to go. Each square can only overlap one clue, and the number on the clue tells you how big the square is. That’s probably not a great description; I’m still working on the best way to explain the concept. However, once you try a puzzle, you figure it out pretty quickly.

I’m hoping to have development wrapped up in about another month or so, and I’ll be sure to post my continued progress and the results of my app experiment here. Hit me up if you’d like to get an ad-hoc copy of the game!

2 comments · Posted by in Previews · , , ,

Unity Tutorial – Alien Attack (Part One) · February 27, 2012

Finally, after a lot of procrastinating, here’s the first part of the introduction to Unity that I promised so long ago. Unity is both a game engine and level editor, and is primarily visual in nature. You’ll create entities (known as “GameObjects”) in your game, then tell them how to act by attaching “components” to them. For example, a “RigidBody” component makes a GameObject use Unity’s physics engine, and an “AudioSource” component allows a GameObject to emit sounds. While Unity’s built-in components are powerful, you’ll have to create your own components (via scripting) to truly make your own game. However, the total amount of actual programming needed to get objects to interact the way you want is minimal compared with creating a game exclusively with code.

In Unity, the terms “scene” and “level” can probably be used interchangeably. A Unity project can contain multiple scenes, and these scenes can be swapped in and out as your game progresses. For example, when a game is launched, the player might be presented with a title scene containing UI, allowing them to select a gameplay scene. When the player chooses, that scene is loaded up and then the player can start interacting with the game. The game that we’ll make for this tutorial will have two scenes, a title scene and a game scene. Pretty basic, but it’ll introduce the concept of switching between scenes.

First, we’ll create the title scene. Bust open Unity and create a new project. This project will be based off another game where aliens are trying to “invade” from “space.” Let’s call it “Alien Attack.” So, when you create a new project, there’ll be a default scene already there for you. Hit Control/Command + S to save it, and name it “Title.” All this scene will do is show a title graphic with a button to start playing. Fire up Photoshop (or Pixelmator or Acorn) and create a logo for the game. Now, since I’m using Photoshop, I’ll just save the image as a PSD right to my desktop, and name it “title-logo.psd”. Now, create a new folder in the “Project” widget in your Unity window and name it “Images.” Drag the PSD from the desktop to that folder, and BAM! You’ve successfully imported it into your game. If you navigate to the main project directory in your filesystem, you can browse through all the assets you’ve added to the project, and edit them directly there.

Now we can start adding stuff to the title scene. Click the GameObject menu at the top of the Unity window, and select Create Other > GUI Texture. This will create a default Unity watermark. Looks kinda cool, so let’s leave it in there to show that this game was made with Unity! Select the “UnityWatermark-small” object in the Hierarchy view and edit the Transform component using the Inspector until the logo is positioned appropriately in one of the corners of the screen. Now let’s add the game logo we just created. Click the GameObject menu again, and make another GUI Texture. Rename this texture “Logo”, and select it in the Hierarchy. You’ll see in the Inspector, below the Transform component, there’s a GUITexture component. Drag the logo PSD you created from the Project widget into the “Texture” property of the GUITexture. Presto, now your logo is displayed! Adjust the Transform component’s Position and Scale properties until the logo looks good. If you want to, you can also change the background color of the title scene by editing the Main Camera object in the Hierarchy. Select the camera, then click the color box in the Camera component in the Inspector. I changed my background to black, but you can use whatever color you want.

Now, in order to make a clickable button that will take us to the game scene, we’ll have to create our own “Script” component and attach it to an object in the title scene. The script will display a button and load the game scene when clicked. In the Project window, there’s a little “Create” button at the top. Click Create > Javascript to create a new Javascript script. Supposedly C# is the most powerful choice for scripting in Unity, but all the official Unity scripting documentation is in Javascript, so that’s what we’re going to go with in this tutorial. Name your new script “title” to show that it’s in charge of showing the user interface in the title scene. You should probably also create a new “Scripts” folder in the Project window, to help organize all the scripts that will eventually be created. Drag the “title” script into the new folder, then double click the script to open it up in MonoDevelop, the script editor that ships with Unity. You can use any editor you want, actually, but we’ll use MonoDevelop for now. You should see that the script comes pre-populated with some functions named Awake and Update; those will come into use later for other scripts we’ll create. For now, just add this code to the script:

function OnGUI() {
	var width = Screen.width;
	var height = Screen.height;

	if (GUI.Button(Rect(width / 2 - 50, height - height / 5, 100, 50), "Start!")) {
		Application.LoadLevel("Game");
	}
}

This will create a 100×50 button with the text “Start!” on the screen. However, if you try playing the game right now, the button doesn’t show up! That’s because a script has to be attached to a GameObject in the Hierarchy before it can run. It doesn’t matter what object this GUI code is attached to, so we’ll attach it to the main camera. Drag the script onto the Main Camera object in the Hierarchy, then try running the game again. Success! However, if you click the button, you’ll get an error, because we haven’t created the “Game” scene yet, which we’ll do next.

Under the File menu, select “New Scene” to create another scene. Save it and name this one “Game.” This’ll be the scene that we create our actual game in. One thing to remember is that for every scene you create that you want to be in the final game, you have to add it to the “Scenes in Build” property in the project’s “Build Settings.” Go to File > Build Settings and drag both the Game and Title scenes into the Scenes in Build window.

Next, let’s set up the camera in the newly-created Game scene. Although the game that we’ll create uses 3D objects, we’ll constrain movement to be along only two axes. This means that we can position the camera to create a cool effect where enemies at the top of the screen are able to be seen from a lower angle. Move the main camera to (0, 70, -6) and set the rotation to be (60, 0, 0). This will make the player (positioned at the origin) appear to be at the bottom center of the screen. Alternately you could make the camera point straight down and make the projection “orthographic” to remove all perspective from the game objects, which would better simulate a 2D game.

One thing we might want to change is the fact that there’s no light source in this new scene, so any objects we create will be pretty dark. In the Hierarchy, click Create > Directional Light. Select the new light, and set its’ position to be (0, 20, 0) and rotation to be (90, 0, 0). This will create a light pointing straight down that will illuminate the tops of all the game objects we create.

Next, let’s create the player and enemy game entities. I thought it would be cool to do 3D pixel art, in an attempt to go beyond the standard cubes and spheres most tutorials provide. Also, since the player and enemies will be made up of a bunch of GameObjects, I’m going to attempt to create a cool effect where the entity breaks apart when it dies, by assigning physics components to each “pixel.”

In the Scene view, click the y-axis in order to get a top-down view. We’ll follow Unity conventions where a “top view” means the x-axis is left/right and the z-axis is up/down. Or, alternately you can set up your camera to view the X/Y axes. It really doesn’t matter as far as I know.

First, create a cube in the Hierarchy window. We’ll use this cube as a “pixel” to create an enemy object. Set its’ position to (0, 0, 0) by using the Inspector. This cube will be the center of the object, so we’ll build around it. Next step is to give the cube a better color than the default grey. To do that, create a new material in the Project window, and name it “Alien.” Click the Main Color color box in the Inspector, and choose a bright color. Drag this material onto the Cube object you created in the Hierarchy, and BAM!, the cube turns green! The great thing about this is that you can make a change to the Alien material, and all the objects that use the material will be updated automatically.

Now select the cube in the Scene window using the Translation tool, and hit Command-D (or Control-D) on your keyboard. This will duplicate the object. However, it’s still occupying the same space as the original, so drag it to one side using the translation arrows. Hold down Command (or Control) as you drag so that the object snaps to the unit grid. This means that you can easily place the duplicate cube 1 “meter” away from the original, without having to manually change the coordinates. Continue to duplicate and move cubes away from the center cube until you’re happy with what the alien looks like.

Next, we’ll “parent” all those cubes into a generic GameObject. That means we can move the GameObject and all the “children” will move with it. Click the “GameObject” menu, then select “Create Empty.” This will put a new GameObject in the scene Hierarchy. Place the empty object at the origin (0, 0, 0) using the Inspector. Using the Hierarchy window, select all the cubes you created and drag them into the GameObject. You’ll see that a small arrow gets created to the left of the GameObject entity, and all the cubes are now indented, to show that they are “children” of the GameObject. You can show/hide them by clicking the arrow next to the parent. Now you can rename the GameObject to something more descriptive, like “Alien.”

To deal with collisions, we don’t want to have to check for a collision against every cube that makes up the alien. Instead, we’ll create a Box Collider component and attach it to the parent GameObject. That way collisions can be checked against one big collider, instead of lots of little ones. Select the Alien object in the Hierarchy pane and click the “Component” window menu. Select Physics > Box Collider to add a Box Collider component to the Alien. You’ll see that by default, the collider is a 1x1x1 cube. You can adjust the center and size of the collider until it fits around the whole object (I made mine 11x1x7). Also, make sure that the “Is Trigger” option is checked, which means the collider will only be used to detect collisions, not for physics.

We’ll add some basic sound effects to our Alien. Make sure the Alien object is selected in the Hierarchy, then click the “Component” window menu. Select Audio > Audio Source to add an audio player component. This gives a GameObject the ability to emit sound effects via a script. Now, the player won’t hear anything unless there’s an Audio Listener in the scene, but fortunately the main camera has an Audio Listener component by default, so you don’t need to worry about it. Bust open sfxr or cfxr and create an “explosion” sound effect that you like, save it to your desktop, then drag it into the Project window to add it to the project (you can create an “audio” folder for organizational purposes if you like). Now highlight the Alien object again, and drag the sound file into the “Audio Clip” area of the Audio Source component in the Inspector. We’ll play this sound effect via a script that will be attached to the Alien object later.

The last thing we’ll do is assign a tag to the Alien. This lets us easily determine the type of object it is when it interacts with other GameObjects. For example, if your player object hits another object, you can test and see whether or not that other object is tagged as an enemy. If so, then your script can take the appropriate action. Again, make sure the Alien is selected in the Hierarchy, then look at the very top of the Inspector. There you’ll see a “Tag” property, which you can select from a drop-down menu. Click the menu, then choose “Add Tag” to create your own custom tag. Modify the “Size” property of the list that shows up, and create a new “Enemy” tag. Now you can go back and assign that tag to the Alien object.

Finally, we’re ready to actually create a “prefab” based on the complex GameObject we just put together. Prefabs are saved GameObjects that you can easily add to your game, either dynamically while the game is running or just by dragging the prefab object into the Scene. The advantage of using prefabs is that you don’t have to manually set up each new enemy object, you can just create one archetype and duplicate it a bunch of times. In the Project window, click the “Create” button and create a new prefab and name it “Alien.” Drag the Alien object you created from the Hierarchy over on to that prefab icon, and you’ll see the object name in the Hierarchy turn blue. You can make sure everything worked correctly by now dragging the prefab back into the Scene view; you should see another copy of the alien appear.

Now, repeat the steps we used to make the alien, except this time create the player’s ship. Remember to parent all the cubes into a new GameObject, add a Box Collider, an Audio Source (with a “shooting” sound effect), and tag the ship as “Player” before making it into a prefab.

You now have the two objects that will be used in the game. How about getting them to do something? Here’s where we’ll create more Script components to use with our game objects. Create a new Javascript script component and name it “player.” Double-click it to open it using the default Unity code editor, MonoDevelop. Here’s the Javascript code that will go inside:

// player.js
// #pragma strict enforces static typing in Unity Javascript
#pragma strict

// This public variable can be easily changed later in the Inspector
var moveSpeed:float = 5.0;

function Update () {
	// Get input from WASD or arrow keys (values from 0.0 - 1.0) and modify it by the "moveSpeed" variable
	// Also make framerate independent by multiplying by Time.deltaTime
	var x = Input.GetAxis("Horizontal") * moveSpeed * Time.deltaTime;
	var z = Input.GetAxis("Vertical") * moveSpeed * Time.deltaTime;
	
	// Modify the "transform" component of the GameObject this script is attached to
	// Translate (move) it along the X and Z axes. 
	// Y will always be zero because we only want to move in two dimensions
	transform.Translate(x, 0, z);
}

Save the script, then drag it on to the “Ship” prefab that you created. You should see the script component added in the Inspector when you select the Ship. Create a new instance of the prefab by dragging it into the Hierarchy, then set the position of that instance to (0, 0, 0). Now if you click the Play button at the top of the Unity screen, you should be able to move the Ship object around by using the WASD or arrow keys. The default movement speed in the script is pretty slow, so feel free to change the moveSpeed value either in the script or by using the Inspector.

Aaaand, break! Right now we’ve got a solid base for our game, having created complete player and enemy objects. The next installment will cover scripting a bit more in depth, so that we can actually shoot enemies. Let me know if anything was unclear, and I’ll do my best to help out. Also, feel free to download the project file to get started.

2 comments · Posted by in Tutorial · , ,

Review: Triple Town · February 9, 2012

Since it’s been a few weeks since I last posted, I figure my loyal audience might need an update as to what’s happening in Ganbaru Games-land. Well, in December I took a break from development to play through The Legend of Zelda: Skyward Sword (which was awesome, by the way). January was regulated to dealing with various illnesses, one after the other. First my daughter got a cold, right after Christmas, and then it spread to my wife and me. No sooner did we start to get better, when the kid got sick again! And now I’m coming down with yet another cold. Bad news! So, as you can imagine, sleep has been taking precedence over programming.

However, every dark cloud has its’ silver lining. In this case, the silver lining is a new, addictive game I’ve been playing called Triple Town. Triple Town has been a Facebook game for a while, but I don’t really play Facebook games, so I never tried it. Fortunately, Spry Fox, the game’s developer, has released both iOS and Android versions, so I figured I’d give it a shot. Spry Fox is actually involved in some litigation right now, suing a former partner that has released a pretty blatant Triple Town clone, so weirdly that also made me more interested in the game. If it’s good enough to straight up copy, there must be something there, right?

The idea behind Triple Town is simple: build up a town on the game grid by placing three or more objects next to each other. For example, three “grass” tiles create a bush, three bushes join to form a tree, three trees make a hut, etc. I’m actually not sure how high you can go, since I’ve never gotten anything above a mansion (3 huts -> house; 3 houses -> mansion). Pretty standard idea, but the twist is that the new structure forms where you placed the last match. You therefore have to plan out your moves so as to eliminate gaps between buildings.

The other twist is wild animals. Bears, to be specific. Every turn, you get a random object to place, and sometimes that object is a bear. Bears move around the board, preventing you from placing regular tiles on the spots they’re occupying. Even worse are Ninja Bears, who jump erratically around the stage. You can get rid of regular Bears by pinning them in a narrow area so they can’t move, but Ninja Bears can only be disposed of by Robots, which clear an object on any tile. “Bear Control” is a key aspect of the game; you’ll find yourself building special holding areas for bears, so they can’t run amok throughout the whole stage.

The game mechanics are deceptively simple, but very addicting. There’s just enough of skill vs. randomness to keep things interesting. In fact, once you get the hang of the game, you’ll probably want to play for some marathon sessions. This is where yet another interesting design choice comes in. Triple Town is a F2P (free to play) game, and its monitization strategy is quite clever. As you play the game, you have a limited number of moves you can make. Your move meter recharges itself over time, and you can also buy more turns using the in-game currency, which is earned by building large towns. However, if you don’t perform well enough during the course of a few play sessions, you’ll eventually run out of turns. That’s when you can either buy more in-game currency (for real-life $$$) or purchase the “Unlimited Turns” DLC. Of course, if you’re patient and wait for your turns to recharge, or create large cities, you can always play for free.

In conclusion, since Triple Town is a free download, you basically have nothing to lose by checking it out. Who knows, you could get addicted just like I have. I think the only way that Triple Town could be improved is if Spry Fox had named it “Trippple Town.”

★★★★★ — Triple Town – Spry Fox

Add a comment · Posted by in Reviews · , ,

Review: Super Crate Box · January 13, 2012

Heyooo, time again for me to write another game review instead of actually making games! This installment will cover the “underground” PC hit with the most redundant/nonsensical name ever, Super Crate Box. Super Crate Box (hereafter, SCB) was released a year ago to critical acclaim by Dutch developers Vlambeer. Unfortunately, the first release was Windows-only, so I never actually tried it out (although there’s a Mac version now). Fortunately, Vlambeer decided to cash in a bit on the success of the freeware PC release by porting the game to iOS. So, how is it?

Well, SCB is a single-screen shooting game. The goal, as the name of the game might imply, is to collect “crates.” Nabbing a crate will increase your score by 1. Hey, it’s not quite that easy! To prevent you from becoming a crate-collecting master, baddies stream down from an opening in the ceiling (I don’t know how they got there). You can shoot or avoid the enemies, but if an enemy makes it to the bottom of the screen, it falls into a fire pit. Naturally, this enrages and teleports it back to the top of the screen, where it becomes even harder to deal with. Fortunately, every time you collect a crate, you get a different weapon to help eliminate the hordes of baddies.

Seems simple? Deceptively so. The fun of the game is the balance between killing enemies and collecting crates. While each crate gives a weapon that is better than the pistol you start with, some weapons are certified lemons. The disc gun, for example, will chop baddies in half, but it also ricochets and can slice you in half as well. Dual pistols just means that you can shoot underpowered bullets both left and right. Mines take a second to arm, which doesn’t help when there are enemies right on top of you. An average game means getting a good weapon (such as the grenade launcher) and clearing the screen, then picking up as many crates as you can until another good weapon appears.

SCB uses virtual “buttons” to control the action, and while physical buttons will always be better for playing games, Vlambeer has managed to make the controls not quite as painful as other iOS games. This is because the hit-detection area of each button is much larger than depicted on screen, so even if your fingers move around in the heat of battle, you’ll still usually be able to control the game. Every once in a while I’ll experience a “cheap” death, where my fingers migrated off the buttons, but most of the time my character bites it because I’m too greedy for crates.

The verdict is in, and that verdict is: get it. It isn’t too often that a “simple” game such as SCB provides such a level of addictiveness. And, as always, for $1, you can’t go wrong on price.

★★★★★ — Super Crate Box – Vlambeer

2 comments · Posted by in Games, Reviews · , , , ,

End of 2011: Giving Back · January 3, 2012

As you all may have noticed, it’s 2012 now. The end of every year has its’ share of annoyances, not least of which are people trying to get you to donate money before the end of the year. If you visited Wikipedia at all in the past month, you’ve no doubt completely tuned out the “Read a Personal Appeal!” banners that were strewn across each page. Normally I tune all that stuff out too, but this year I got to thinking a bit about how privileged my life is.

  • Grew up in a solidly middle class family
  • Graduated from both high school and college
  • Have a full-time job with health insurance
  • Disposable income to buy Apple kit
  • Disposable time to program said kit

It’s pretty remarkable, actually. I’m probably in the top 1% of the world in terms of having a comfortable life. So I decided to try to be a little bit less of a selfish prick and donate some of this past year’s gaming income to a worthy cause.

I decided to help the scholarship fund for Harambee Christian School. It’s a K-7 school in Columbus, Ohio, that provides private education to kids who would otherwise not have many opportunities. I figured that since Harambee is a program in my city that tries to give kids something that I take for granted, helping out financially would be the least I could do.

I realize that this post is about a month late to try to convince people to donate to charitable organizations before the end of the year, but you should think about regularly donating to a non-profit regardless. The audience of this blog is primarily people just like me: middle class, with enough income to buy crap we really don’t need. Take a step back and think about how you can really help people, and not just by providing bits of mindless entertainment to smartphone users.

Add a comment · Posted by in Meta · ,

Intermission: The Legend of Zelda: Skyward Sword · December 14, 2011

As you can see, since announcing that I was going to start dabbling in Unity, I actually haven’t done anything! The cause of this is the fact that I’m currently ~20 hours in to the new Zelda game, Skyward Sword. Basically I’m trying to recharge and remind myself why I like games in the first place by actually playing one.

Fortunately, Skyward Sword is pretty good. While it isn’t as purely groundbreaking as Ocarina of Time, it does add a number of new gameplay mechanics that make the game feel fresh. My only criticism so far is that parts of the game are a bit padded (i.e. to progress, you need to fetch an item located in an area you’ve previously completed), but that is almost inevitable with any large-scale adventure game.

I’ve been talking the game up to co-workers, and even though I haven’t completed it yet, I can wholeheartedly recommend that you dust off your Wii and start swinging the remote like a crazy person. It’s a true “Nintendo” game, which is about as high of praise as I can give anything these days. Once I finish, I’ve got a few ideas in mind for new projects to start, so we’ll see where those lead.

Add a comment · Posted by in Games, Productivity · , , ,