Sunday, October 24, 2010

Too Busy

I've been too busy with my full time job (lecturing at St.Martin's Institute of I.T.) that I didn't progress anywhere with the balancing of the weapons.

I will probably rescale down the project into just a shooter without any storyline for the time being. Then we see how it will be received by the public and guide the project accordingly.

The major problem I'm seeing is that I had envisioned the big screen of the ipad to be a big plus when navigating and directing the shit with the accelerometer, however people get their forearms tired quite quickly. I had introduced the touch-joystick as well, but it's not the same feeling.

Monday, September 27, 2010

New weapons done but not balanced yet

So this week I have added the ray-gun (previously I was referring to it as the BFG, but decided that the ray-gun has more potential) and also the missiles.

The ray-gun fires for a couple of seconds and you just point it to your enemies and damage would be given to the enemies. I have to tweak the recharge time and how much it stays on.

The missile will follow an enemy if you lock on to him. Right now it will lock immediately. Maybe I will add a couple of seconds before it locks. I will also need to make it more obvious that it locked on the enemy. Again I need to tweak the recharge time and also have a limit of missiles and add pickups for missiles.

I have added something which wasn't in the sprint... Actually three things. A crazy boss level where you have to chase an enemy and an alien structure made of smaller pieces that follows you. Still need to balance everything but it's looking good. The other thing is customizing the controls and placing the buttons wherever the user wants, although on a grid. And the last thing is to optionally seeing your vehicle, ala AfterBurner, but I need to add collision with it now.

I have noticed a slow down since I added more HUD stuff. I'm already using SpriteManager, but something is slowing down the framerate and narrowed it down to the HUD. It's not number of draw calls though. I will need to investigate more. If the worse comes to the worse, I will add an option for less details. It didn't effect the framerate on the iPad though.

I wanted to push out this sprint's prototype to the user but it doesn't feel right yet. So I will push it later during the week when I have sometime in the evenings.

What's next?
Collider for your visible ship with checks for camera not penetrating objects
performance tweak
minor bugs with ray and missiles

Sunday, September 19, 2010

Next sprint

I have redone the tutorial level. We'll see how it goes from the feedback this week.

The Touch (Joystick) control system is in place. I don't like it much, even because the game is now easier IMO. I prefer the Tilt control mechanism.

I have also done a survival mode level. I noticed that people just wanted to shoot down stuff. So I added that even if it wasn't planned.

I also met with an old friend of mine, who is going to have a go creating some 3d models. Cool.

So my next chunk of energies will be dedicated to
- adding pickups
- BFG which will give a short burst of energy after it charges
- Missiles where you have to lock on to an enemy and then fire away
- Adding the above to survival mode

Monday, September 13, 2010

Using SpriteManager for Unity iPhone HUD/UI

The problem is the usual... having a draw call for each GUITexture that you put on screen. Of course there is SpriteManager to put all sprites into one mesh, and thus one draw call. Here is how I used it.
Create a an empty GameObject and drag the SpriteManager script to it. Call the GameObject SpriteManager as well. Set the texture to point to your sprite sheet material and set the alloc block size to say 100. Also change it to CW from CCW.

Create a layer for the UI and make put the SpriteManager object in the UI layer.

Creating a Sprite Sheet
To create the sprite sheet I used Sprite Sheet Packer (only for Windows though), which given a set of images will generate for you the sprite sheet and also a text file containing the sprite sheet map which can be easily parsed. Each line of this text file will have imagename = x y width height.

I created the following sprite sheet map parser which returns a hashtable of the sprite's uv coordinates and dimensions indexed by the original image name

using UnityEngine;
using System.Collections;
using System;
using System.IO;

public class SpriteSheetMapParser : MonoBehaviour
public static Hashtable parse(string filename)
Hashtable h = new Hashtable();

// Create an instance of StreamReader to read from a file.
// The using statement also closes the StreamReader.
using (StreamReader sr = new StreamReader(Application.dataPath + filename))
String line;
// Read and display lines from the file until the end of
// the file is reached.
while ((line = sr.ReadLine()) != null)
int equalsIndex = line.IndexOf ('=');
//get the image name
string name = line.Substring(0, equalsIndex).Trim();
//and the uv coordinates and width height
string[] dimensions = line.Substring(equalsIndex+1).Trim().Split(' ');
Rect r = new Rect(int.Parse(dimensions[0]),
h[name] = r;
catch (Exception e)
// Let the user know what went wrong.
print("The file could not be read:");
return h;

The next thing was creating a singleton base class to be used by any sprite sheets you are going to use, as you may be using multiple sprite sheets. So each sprite sheet you would want to access would be another class extending this base class.

using System.Collections;

public class SpriteSheetSingletonBase {

private Hashtable spriteSheetMap;

protected SpriteSheetSingletonBase (string spriteSheetMapPath)
spriteSheetMap = SpriteSheetMapParser.parse(spriteSheetMapPath);

public Hashtable SpriteSheetMap
return spriteSheetMap;


For the sprite sheet used by the HUD I simply created this singleton

using UnityEngine;
using System.Collections;

public class SpriteSheetHUD : SpriteSheetSingletonBase{

private static SpriteSheetSingletonBase instance;

private SpriteSheetHUD () : base("/Textures/spritesheet.txt")


public static SpriteSheetSingletonBase Instance
if (instance == null)
instance = new SpriteSheetHUD();

return instance;

I created the parser class with just one static method that extends MonoBehaviour due to print mainly. I didn't want he sprite sheet singletons to extend MonoBehaviour and have extra baggage. I wanted the singletons to be plain old objects.

SpriteBase class
Next was creating a sprite base class which would be linked with any transform (empty gameobject) that would require some sprite to be drawn at that position. You then just need to specify the name of the sprite in your sprite sheet map. You also need to link the sprite manager object in your editor with the script, as you may have multiple sprite managers as well. Of course you can create a script which extends the SpriteBase class to animate the object etc.

using UnityEngine;
using System.Collections;

public class SpriteBase : MonoBehaviour {

public SpriteManager spriteManager;
protected Sprite sprite;

public int width = 10;
public int height = 10;
public string spriteName;
public Color color = Color.white;
private Color oldColor = Color.white;

// Use this for initialization
void Start () {
Rect dimensions = (Rect)SpriteSheetHUD.Instance.SpriteSheetMap[spriteName];
sprite = spriteManager.AddSprite(gameObject, width, height,
(int)dimensions.x, (int)(dimensions.y+dimensions.height),
(int)dimensions.width, (int)dimensions.height,

// Update is called once per frame
void Update () {
if (color != oldColor)
oldColor = color;
// transform.position = transform.position + new Vector3(1,0,0);
// sm.Transform(s);

public void RemoveSprite() {
print("spritemanager should be removing sprite");
sprite = null;

public void HideSprite() {

public void ShowSprite() {
Setting up a UI Camera
Create a new camera, call it UI Camera. Set the culling to just the UI Layer, so first select nothing, and then select the UI.
From the main Camera you will have to remove the UI layer too, so go the main camera and from the culling just unselect the UI layer.
Set the depth the UI Camera to 1 so it is rendered after the main camera.
Also change it to orthographic. I also pushed it to some negative value, e.g. -7 in the z direction.
I changed the size to 160 on an iPhone display, so the size of sprites that I give when creating them, maps to the rendered size on the screen. That 160 is actually the screen height/2. If you are developing for iPad and Retina displays you would need to do something like this.

camera.orthographicSize = Screen.height/2;

I put that in the camera's script Update() although it should be in the Start() however in the editor the Screen.height wouldn't have been changed on starting up, if the window is set to iPad and Maximize on Play.

That should be it. Enjoy. Coming up next is how to do a radar.

Sunday, September 12, 2010

Last sprint was hijacked :)

The last sprint was completely changed. Some valuable feedback was coming in and I found it more important to address them rather than the features in the last sprint.

I implemented an auto locking system. It's now very easy to shoot down enemies IMO. I will probably put that on for Easy mode (whenever I implement difficulties that is)

I introduced a tutorial level instead. Still needs a lot of rework. In fact I got some more feedback on this too. The tutorial should be really small. The next iteration, the tutorial should be incorporated into a level and shooting should be very early in the tutorial. Navigation is not the fun part of the game but shooting is.

Also I should add a touch control system ASAP since I got some complaints, especially when playing on an iPad, that they get tired. Wimps! :)

So my next iteration will basically be
- get tutorial level right
- touch controls

Monday, September 06, 2010

Next HyperGlider sprint... BFG, Missiles, Overshield + gameplay tweaks

I'm releasing the first prototype to my close friends to play test it a bit.

I encountered a couple of problems, namely the framerate drop due to draw call for each sprite. So I started using SpriteManager for the HUD. I also implemented properly the radar. I will be posting a separate post on that. I also introduced an simple intro, where a draft comic strip is displayed and then a dialog is presented. All the graphics are drafts and will probably not make in the final version

While I will be waiting for some feedback I will be working on the next stuff:
- BFG... a huge blast that needs to recharge
- Missiles... lock on an enemy and shoot away
- Overshield... you can boost and blast into enemies
- tweak the gameplay to make it highly action packed

Sunday, August 29, 2010

Prototype available to friends soon

Ok so I bought Unity iPhone License, and added the enemies and made them shoot. However I didn't bother with optimizing the draw calls just yet.

Instead I concentrated on adding the fun elements in the game. I improved the sensation of speed by adding a stretched particle system just in front of the player's camera and I enable emitting only when the player is boosting. I also added the rotation of mothership to align firing the planet off the face of the universe. The player can now go inside the cannon and drop the nuke. He cannot enter the cannon until the mothership finishes aligning, after which the cannon's shaft opens. This may change later on when I tweak the gameplay.

I encountered some problems such as the turret's gun's rotation to shoot at you got screwed after the mothership changes orientation. I thought it was trivial to solve, but after wasting a couple of hours I pushed the task down in my priority list. I also wasted precious time trying to fix a bug with the radar. This is how the rad should work. According to the ship's forward direction and up direction, we project the enemies on a plane (up = normal), but after this projection I want to show the projected enemies on an XY plane and it's the latter part which I've got problems with. The bug that I see is that in some quadrants, the result of the positions on the XY plane are skewed somehow. Haven't figured out the problem yet, but someday I have to face this.

A friend of mine has also started sketching the comic strip for the intro, hopefully I will be seeing the sketches soon. I've also contacted a friend of mine who may give me a hand from the musical aspect of the game.

For next week:
  • Prepare build for prototype testers including intro page
  • Tweak the enemy to be a bit more realistic (current he can shoot even if its not looking at you
  • Make some game over triggers and restarting the game.
  • Tweak the manouvrability of the spaceship
  • Also the timing for mothership aligning and getting the end of the tunnel with some enemies such as turrets and ships coming at you.
  • Cutscene to see mothership shooting planet

Monday, August 23, 2010

Turrets & bullets

This week I managed to get the hang of using a unity particle system for all the bullets by using the Emit() method of the ParticleEmitter. That will ensure just one draw call for all the bullets in my scene.

I have also made a Turret to focus on a target and start shooting at it. I also tried doing a prediction method that takes into consideration the distance and speed of the vehicle. I will need to add also into consideration the bullet's speed.

For Next week:
- re-add the enemies and make them shoot at the player
- optimize the textured enemies to use an unparented bones system (read this somewhere to minimize draw calls in unity)
- buy unity license

Sunday, August 15, 2010

New iphone/ipad game in development

I have just finished doing the game bible for my next game. The work-in-progress name of the game is HyperGlider. The name will probably change later on.

In short it's going to be a 3d space shooter game with intense action. The way how to hold the ipad will immerse the player even more in the game.

I will be using Unity and I will try to push the limits of the ipad to make it as visually appealing as this game: Star Wolves

I will be posting any updates about this game on this blog.

Saturday, April 03, 2010

SoundToy iPad app approved for launch

This is great news. It has been approved by Apple and will be available on the iPad's launch on the AppStore! Keep you posted on how it goes.

Thursday, April 01, 2010

SoundToy - iPad app in 24hrs

The story started when a day before a public holiday here in Malta (31st March), I got a reminder from Apple Developer Center to submit any iPad app for review for the great launch of the iPad. And I thought why not create something simple in just a 24hr - code jam. My wife was going to be busy doing figolli (traditional Easter sweets), so I said let me a do a coding marathon where in less than 24 hours I have to submit an iPad app. This wouldn't have been possible if I didn't have experience building Buttonia for the iPhone.

Problem 1: I didn't have Snow Leopard, so I bought it after finishing a tutorial with my students on that day. And that evening I installed it together with XCode 3.2 / iPhone SDK for the iPad. Installation went smooth, although took a while to finish due to updates. I still made a TimeMachine backup before just in case :)

Problem 2: What can I do in less than 24 hours? I thought what would I want to do if I had a big multitouch screen? I would want to touch it with both hands and swipe and do some nice visual effects. That would be quite easy to do. Then I said what if I add some sound to it? That would make it more engaging and it would be ideal for kids to play around with it. I'm not really an audio programmer, but a sine wave generator wouldn't be difficult to code. Then if I get some sales, I might add some more sound effects to it and improve it later.

Problem 3: I didn't have an iPad, so I was bound to use the iPad simulator which although it works, its a bit slow on my machine. Plus I cannot tilt it or shake it, or actually multitouch it. So once I had a semi-decent touch trail effect, and a sine-wave generator, whose pitch changes according to where you touch the screen, I ported the code into another project to try it out on my iPod Touch. Now I know I could have done a universal build, i.e. an app that works both on the iPod Touch and iPad, but I didn't want that as it is not the same thing when you have a small screen. The main idea of porting it was to test the multitouch, but also to hope that the sound glitches I was experiencing in the simulator where a bug in the simulator and not in my code. Obviously I was wrong! The sound glitch still occurred and it only occurred when a sound starts, and when it ends. It also wasn't working nicely when blending multiple sine waves.

As I said I'm no audio programmer, so probably this would have been a no-brainer for some experienced audio programmers. The problem was in fact in the blending of the waves. I didn't want to use (A+B)/2, where A and B are two samples, because if one of them is silence, then outcome would be half the volume. I tried this as a test, even though it might half the volume and with this I didn't have any glitches. So I concluded my blending formula of (A+B) - A.B (not exactly this, but a variant of it), was not working right. My mind was already slowing, especially after coding an all-nighter with just 4 hours of sleep (5am - 9pm). I tried to find on the internet how to do correct blending. I discovered a lot of other unrelated algorithms, but not what I wanted. After telling the problem to my wife, I got to the solution :). Basically I used A*a/t+B*b/t where a is the current sine wave's volume, b is the previous waves' volume and t is the total volume (a+b). Now consider A as being the current wave we are mixing, and B as the previous wave (which is a mix of other waves). Then b is simply the maximum volume of all the waves mixed so far. This is probably not the correct way how to do, but I was pressed with time. It worked and no glitches :)

The polishing stage was the shortest cycle I have ever done on any project. There wasn't much to polish since it was a small project. I just added some concepts like double tap to hold a note, and shaking to clear the notes. Then made a quick logo and some simple text instructions while the app is loading.

All in all, it was a fun coding experience. I learned a lot, and definitely I need to get my hands deeper into audio programming/DSP. Waiting for Apple's review...

Wednesday, March 24, 2010

History of Buttonia - Maltese iPhone game

Buttonia was originally invented by Sven Neumann back in 1996. The first time I saw it was ten years later in 2006 when I was at Sven's place and he was showing me his prototype games.
When he showed me his version of Buttonia I was hooked. Its simplicity and addictiveness was its strength. The first couple of seconds you are really puzzled on what you need to do, but then you immediately realise that each button effects it's neighbours and that's it. You just need to turn on all the buttons.

It was still a prototype at the time and he never had the time to polish it. I told him "We got to polish this and push it out and see what happens". I had done some shiny buttons and Sven put up some javascript together and we rolled out an online version on We had a daily 3x3, 4x4, 5x5 and 6x6. The 6x6 were a bitch to solve and took around 5min to solve it. We had quite a hit when it got reviewed by blogs. At one point we were flooded from the Japanese. They seem to like these kind of puzzle games.

At the time we spewed out randomly generated puzzles without verifying if they were solvable or not. The users could flag if it wasn't solvable or not. We knew this was a problem and we had several chats on how to come up with an algorithm to know whether a generated puzzle was solvable or not. Sven is more into Math than me, and after a lot of research/trial and error he came up with a mathematical solution. He tried to explain it to me, but it was beyond me. Too many matrices and transformations for my liking. But it works! We give the algorithm a randomly generated puzzle and it tells us whether it is solvable or not.

Meanwhile I was interested in iPhone development, not because of the gold rush really (which is over by now), but I always wanted to know what it would be like to develop for such a device. I had already developed a couple of games for the n-gage (Symbian OS), and sincerely the SDK wasn't that well organized (but maybe they fixed this by now). So I bought a second-hand macbook and also a second-hand ipod touch (with a cracked screen), and started developing some prototypes, unrelated with Buttonia. I had started an engine for shoot'em ups but realised I needed a lot of art to make it really addictive and polished. Then I met Sven again and he tossed the idea of porting Buttonia for the iPhone. And that's were I started creating an even more polished version of Buttonia. We met every now and then to see what was working and what not. The prototype was done in a couple of weeks, but then remained the next 90%. Polishing takes ages. We wanted to get the tutorial as best as we good, and when we give the device to our friends to play it, they still people press Play and don't care about the How to Play section :). They still figured out what they need to do.

I carried out two beta phases with my friends who had an iPhone/iPod touch and they gave valuable feedback. I only had one crash from one of the testers, and sent me the crash log and solved it. Thanks Luke. We had valuable feedback and fixed some usability issues. The best feedback though was when I showed someone the game and I just see how he/she will react to the game. Awesome experience for a developer to see his product being used. It's an eye-opener, because everyone will act differently and they always do something with the game you wouldn't have ever imagined. My best beta test is actually my wife. She likes games and she finds bugs so easily. So she is the first one to play my games before showing it to anyone else :).

Last week we released the game to Apple and it was approved within a couple of days. We are currently waiting for some iPhone app reviewers. We are already hit #1 in Malta's AppStore, but we still need to make a hit internationally. Unfortunately when you release a game on the AppStore it immediately gets buried in the hundreds of apps released per day. So you really need to have a polished product to get noticed. We'll wait and see. We have to spread the word :)

For more information about the game and a video check out
Buttonia is now available on the AppStore.

Saturday, March 20, 2010

Buttonia for the iPhone/iPod touch released on the AppStore

Last Wed, 17th March, we have uploaded Buttonia to Apple for review, and after two days it got approved! It has been an enjoyable ride with the iPhone SDK and Apple's quick and efficient service. We have learned a lot and we will surely do other apps in the near future.

Something about the game:
The aim of this simple but addictive game is to turn on all the buttons, in the least time possible as quick as you can. Each button flips its neighbouring buttons according to the icon on the button.

Visit the Buttonia website for more info or find in the AppStore. Tell your friends and spread the word :)

Tuesday, February 09, 2010

OCMock for the iPhone

I was using OCMock for testing on the iPhone, but for some strange reason, a configuration I had once done disappeared. I tracked down the tutorial I had used to set up OCMock, and went through it again to get back my tests to working condition again.

I don't want forget this link anymore, so I'm blogging it :)