jump to navigation

Game 1 for 1GAM: Hello Hanoi! February 27, 2013

Posted by Andor Saga in 1GAM, Game Development, Objective-C.
add a comment


My first iPhone game is available for download on the App Store. I call it Hello Hanoi!. It’s my “Hello World” for iPhone game development via Towers of Hanoi. My motivation to code and released the game came from the 1GAM challenge. A year-long event that dares developers to release 1 game every month.

When planning the game, I wanted to keep the scope very tight. At the end of it, I wanted a polished, tightly scoped game over a feature-rich, unpolished game. I think I managed to achieve that, but for my next game, I’d like to try the opposite.

The Pixels

I had a difficult time getting a hold of artists, so I decided to just learn pixel art and make all the assets myself. To begin making the art, I tried a few applications: Gimp, Aseprite, and Pixen. Gimp had issues with leaving artifacts on the canvas. Aseprite had problems with cursor position and I felt the UI was awkward. Pixen kept crashing. It was a bit frustrating so I restarted and re-installed them all. I launched Pixen first, and it seemed to work, so I stuck with it.

The result of making all the art myself shifted the release date dramatically. I should have released at the end of January and it’s almost March. At the same time, I had a lot of fun learning pixel art and learning about art in general, such as attention to color, lighting, shadows, and mood.

One particular level was very tedious to create and I soon realized I could generate the art instead! So, I launched Processing and wrote a small sketch to create a series of city buildings. It doesn’t look as good compared to what I could have done by hand, but it was a lot faster to create with this method.

The Code

The code was straightforward, but I did have to learn a few iOS specifics. How do I write a plist to storage? How do I use the new storyboards? Like the art, it was at times frustrating, but in the end it was worth it.

One mistake I did make was over-generalizing. I had the idea that it would be neat to support n number of discs. I wrote all the code to handle the rendering and positioning of the discs, but then realized it didn’t fit into the game. Players would get bored before they reached that many discs, and the necessary horizontal scaling of the disc assets would break the art style. So, I ended up taking the code out. Next time, I’ll try to catch myself over-generalizing.

I had a fun time making my first 1GAM game and I look forward to trying something new for the next one!

Objective-C Strings October 9, 2011

Posted by Andor Saga in Objective-C, Open Source.
add a comment

This is my second blog related to learning Objective-C! I’m going to briefly look into creating and using simple strings.

Since Objective-C is C with object extensions, you can still make use of C-style strings.

// This is still valid Objective-C string.
const char* cStr = "Hello!";

The language also introduces two classes which make using strings easier: NSString and NSMutableString. NSMutableString inherits from NSString which means we can use the mutable version anywhere where we can use an NSString.

As their names suggest NSString’s individual characters cannot change once they have been set, but we can easily mutate an NSMutableString. The primary reason for this split is efficiency v.s. flexibility. The compiler can efficiently store a string if it knows it will never change. Let’s take a look at declaring an NSString:

// Create a reference and point it to a statically allocated string.
NSString* nsStr1 = @"This is an Objective-C string";

When declaring string literals like this, the compiler will create a static const NSString. The string will be stored within the binary file itself. If you open up the object file you can even find it there.

Just like in C, strings are interned. If you create two static const strings, the compiler will be smart enough to make them point to the same address.

NSString* constStr1 = @"testing...";
NSString* constStr2 = @"testing...";

// compare pointers, not contents.
if(constStr1 == constStr2){
  NSLog(@"They are the same!");

If we wanted to compare their actual contents we can do:

if([constStr1 isEqualToString: constStr2]){
  NSLog(@"They are the same");


An NSMutableString can be less efficient than an NSString, especially if we’re copying them a lot. But they do give us flexibility. A common way to instantiate an NSMutableString is:

NSMutableString* nsmString = 
  [NSMutableString stringWithFormat:@"This is a mutable string"];
NSLog(@"%@", nsmString);

We can later change the contents of the instance by sending messages to the receiver:

// Change the string entirely.
[nsmString setString: @"Changed mutable string"];
NSLog(@"%@", nsmString);

// Or append some more text.
[nsmString appendString: @"!!\n"];
NSLog(@"%@", nsmString);

That’s it for now! In my next blog I’ll start looking into classes and objects.

Introduction to Objective-C October 1, 2011

Posted by Andor Saga in Objective-C, Open Source.
add a comment

I began a course for Apple application development which requires me to learn Objective-C. I decided a good way to learn the language would be to write short blogs on the subject. So to begin, some notes about Objective-C…


Objective-C allows use of C as well as C++ comments // and /**/

Based on C

The language is based on C, so we have access to types such as int, float, char, etc.

New Keywords

Many new keywords have been added. Some of which are used to directly support object oriented programming. These new keywords are prefixed with ‘@’ to avoid naming conflicts: @class, @interface, @end, @implementation, @protocol are some examples.

Header Based

The language is header based. We have a (.h) header file and (.m) implementation file.
The .h file contains our ‘C++ class declaration’ which we call the interface. It is in this file which we have the interface, properties and methods.
The .m (which stands for module) contains the implementation for the interface. We write the definitions for the methods and synthesize our properties.


We can use C-style ASCII “strings” as well as Objective-C @”strings” which can support ASCII and Unicode.


Objective-C has a preprocessor. Instead of using #include we use #import. The import directive does not need to be used in conjunction with include guards.


In Java every object inherits from the Object class which has a toString method. In Objective-C, objects which inherit from NSObject can be sent a description message for equivalent behaviour.

Declarad Properties

Like C#, Objective-C has direct support for properties. Unlike
C#, we can make Objective-C generate accessor functions.

Memory Management

In C++ we use new to dynamically allocate memory for an object. We can then create many pointers to the same object. When the object is no longer needed, we use delete to free the memory. At that point, no pointer which pointed to that object should be dereferenced.

Objective-C uses a reference counting system. We use keywords retain and release to increase and decrease references to an object once it has been initialized. When an object’s reference counter reaches 0, it is freed by the runtime and a reference pointing to that part of memory should not be sent a message.


Like Java, Objective-C only supports single inheritance. And like Java, it supports interfaces, which we call protocols. Furthermore, unlike C++, we can only publicly inherit from another class.