Being game designer

Admit it, the thought of being game designer has crossed your mind while playing a game many times. I'm sure you were playing a game, you liked or disliked, and thought to yourself: "I could do this better." "I want to be part of this"

But how many of you actually know what being a game designer means? Some of us might imagine that all it takes is vision or having great ideas. But it's much more than that.

How did I became game designer?

I had always been a gamer. I loved to play games but I never thought I could actually end up doing games.

I became a game designer pretty much by accident, I was a programmer developing medical applications focused mostly on inclusive design (usability and interfaces design) and I started to match what was a hobby with my work. At that point I realize that I liked to guess what makes games fun, how the player interacts with it and how to provide a great experience.

Then I meet some guys that were founding ACUV, I helped them define it and I started making my own games, programming them, doodling some graphics (I really suck at drawing, but I'm good doing sketches)… That background helped give me the perspective it takes to pull a product together and have a creative vision for it.

"A lot of people tell me: "I've got a great idea for a game." Frankly, who gives a crap? A great idea is meaningless. A great idea that leverages your existing technology, gets the team excited, is feasible to do on time and budget, is commercially competitive, and, last but not least, floats the boat of a major publisher... Now you have something." -- Ken Levine

What means to me being a game designer?

I love the fact it's not static, I like the creativity. The best part is seeing something that started as a random idea in the back of your head come to life. Seeing players pick it up and appreciate it, enjoy it, having people interested in the what you've created. Being able to meet people all around the world. Sharing experiences with other developers. There are tons of impressive things I love about being game designer.

Although there are some, few, bad things, like the lag in having an idea and finally seeing it realized. Maintaining that faith and team morale high while you're waiting for ideas to be implemented is difficult. It requires a good amount of patience.

Just to finish, let me tell an story: I was at a trade show with some work mates. We were having a conversation with some members of the spanish videogame industry press and some other spanish developers. We didn't know each other so we start talking about something as random as "what games are you playing he most?" and then one guy said, "I become really addicted to an iPhone game called Battle of Puppets". Guess how big our surprise was!?

That is what ultimately drives me into making games. Knowing that someone enjoys our games.

Postmortem: Battle of Puppets

About Small Wonders and Battle of puppets

The creation of the game meant the creation and establishment of a new studio, and learning everything from the ground up. None of the members had previous experience working in the industry and only a few of us had done a couple amateur games so, it was a huge feat to assemble a new inexperienced team and start working.

The core team was formed by 5 people, producer, designer, two programmers and two graphic artists, but as the project went on it was necessary to add more people to the team, so we contracted an external graphic artist and a music composer. At the end of the project about 9 people had intervened actively in the project.

Battle of puppets is a 2D strategy game for iphone/ipod Touch that takes away most of the complexity of the genre by not allowing the player to control its troops. the battle is mostly influenced by actions called professions that enable to control the flow of the battlefield by healing your troops, give them a power boost, possess other troops so they fight for you, stop enemy troops,... all of that while you create increase your defenses in order to project your base. The game is settle in 22 EEUU cities with changing backdrops, 5 armies, 6 professions, intuitive control, ...

What went right

1. Vision

The idea for our first game was to create something that at first look you'll fell intrigued with, something that you could show and say "hey, this is what we've done!", and I sincerely think we've achieved that and the key to this point was to bring together a very passionate team.

As I've said before none of then had previous experience, so at the beginning it was kind of hard to explain how they should work and how different this is for any other regular job, but it ended up being very rewarding as I let them work freely and this freedom made them want to give their bests.

But, this vision brought us a very ambitious project, that at the end was to big to us, and some important changes had to be made in order to meet deadlines.

Battle of Puppets is an iphone/ipod touch game and we choose that because we felt it was the right platform to achieve our initial vision. The iphone is a pretty mature platform, despite only being three years old, both in software support and in features support. Software-wise we felt that the cocos2d middleware was a very stable-well developed piece of software that provided us with the features that we wanted to add to the game. Platform-wise apple provides the appStore which is an impressive worldwide store and right out of the box that added to the impressive hardware that the iphone is. One very important feature for us was the low requirements to enroll in the development program.

2. New IP

The creation of a new IP and working on a new genre brings to the development a lot of uncertainty, because of the risks you are taking. Questions like, will the people like it? will they understand the game? is the gameplay balanced? is it intuitive? were all the way spinning in my head. No having many references to turn to in case something went wrong and the fact that all the similar games I tried were, in my opinion..., very bad, was a heavy burden, but at the end the results are pretty amazing.

Getting the correct art direction was key to achieve the results and so was having some control innovations that seted us aside from the competition. Most of the features in the game came along once the main control was done.

The idea of the puppets were mostly there from the beginning, but at that point there were not going to be animated, they were going to be more like a funfair attraction, but this feature was changed very early, before the first prototype, as it felt that the game was missing some "life". Another idea that changed early in the development was that the puppets were supposedly be inspired by the different puppet styles around the world, like chinese shadow puppets, mexican puppets,... but then in a crazy brainstorming session the idea of fitting the puppets around Opera came out and so we begin with the game.

Another key point was the usability, the drawing recognition system (professions), was something I didn't really see in a game since the time of Molyneux's Black & White, and I wanted in the game. In the first design BOP had a lot of buttons on screen and we didn't want the game to look like a current application, so the drawing system was a good solution to it, the result is a only 1 button interface (pause), the other actions are contextual to what you are doing, leaving the screen clean so the user can enjoy the game.

3. Good reviews

The reviews we've been having so far are very good. There is no metacritic for iphone games, but I would say is around 8 out of 10, most of the reviews ranging from 4 to 5 starts out of 5. The game was also runner up of Game of the Month (January) with Assassins Creed 2 and GTA: China Town wars.

Between the things the reviewers mostly emphasize are the Art direction, the graphic quality achieved by our programmers with the changing backdrops and all the effects, the music composed by Arturo Baquero, the depth of the gameplay despite its simplicity an the professions system.

What went bad

1. Ambition

The ambition for this project was pretty high and it was good at some level because it helped us reach a quality level that we couldn't have achieved either way, but it was also too high for an inexperienced team. So many big features felt out of the development due to that, some of then necessaries, some of them not.

The big issue was to focus on some not very important things and forget about some really important and necessary features. That made the game full of little details and empty of important details like variety on the gameplay and issues with the tutorial that we hopefully solve with patch 1.1.

Those facts bring up the problem of diversity, due to the focus on some low level details, that hurt the diversity of the game from the original design, also cause the game's length to felt little short. And I might say that the overall work-profit balance wasn't very good due mostly to outside entities.

2. Inexperience

None of the team had previous experience, none of us had worked before doing games, not even close, so we had to learn everything from scratch. We had to learn how to work together, set up the tools, choose a proper working methodology, work together us a team for the first time, know which one is best in what, learn objective-c,... soooo many different things. and I think we've suceded in this point, but that were task that required a lot of time, time really needed to spent on the game.

Although I encouraged the personal take on each one of the team we had a "many hats" problems leading us to do more than we could manage, like the producer supervising art, me programming instead of designing, which lead to a little oversight in our tasks.

A major problem we had was the insecurity to intermediate versions cause to this inexperience. The "abstraction" level needed to evaluate a work-in-progress was completely absent and that led us to some development irregularities, like add content once in alpha, major changes in beta,... thus causing delays.

3. Market presence

It's not the game did not sell, indeed it sell very good, specially compared with similar games on the market, it's just it did not come as popular as we've hoped to or how we've hyped ourselves after reading the reviews.

The problem I see here is that the game was target to a very broad audience, simplifying the game mechanics to its minimum and trying to appeal to as many people as possible, but the marketing focus was to try to reach to as many hardcore players as possible and those cause the gamers complaining about the game being to easy.

Conclusion

We are very happy with Battle of Puppets, despite all the problems we faced, we were also able to manage them and create a great game for iphone/ipod touch. We expanded our knowledge in gamedev and we hope that will reflect our next projects.

As conclusion I'll add a never seen before concept art pictures (were created within the first week) post how the game has changed.

Game Data

Publisher/Developer: Small Wonders

Platform: iphone/ipod touch

Release Date: January 27th (AppStore)

Development time: 5 months (+ 1 with patches)

Development team: 2 programers, 2 artits (+1 outsorced), 1 designer, 1 producer, the music and sfx were outsourced and the marketing team.

Cocos2d messaging/event system.

__________

It's been a while since I wanted to add a event system to cocos2d, and these days I've been working with Unity3D, which mostly relays on the event system to send information across all classes so I started working on it for cocos2d.

For those who don't know how a messaging system works, just imaging that you are creating a IA that for your FPS, and you want to notify all surrounding IA troops that the enemy base camp is under attack, then you'll have to perform this tasks:

1. Create the "UnderAttack" event.
2. Then you'll subscribe, in your IA enemies, to the message/event "UnderAttack" you want to listen.
3. create the listener for these event in which you'll have the code to react under this event.
   
4. then you'll send the "UnderAttack" event from your IA enemy that has discovered you.
   

And that is all.

Cocoa has it's on system, which is called Notification System, that works very well, but you have to write quite a lot of code to get it working so I've written a wrapper to simplify everything.

Messaging system

There are bassically three actions you can do on a messaging system as described before, subscribe to the event, unsubscribe of that event, and send messages.

Subscribe

The wrapper for that action is:

//Subscribes to aMessage event.
#define AMSubscribe(aSelector, aMessage, aObject) \
[[NSNotificationCenter defaultCenter] addObserver:(self) selector:(aSelector) name:(aMessage) object:(aObject)]

And what you'll have to write in your code to subscribe the events:

Create the event, (writting the event listener):

-(void)eventHandler: (NSNotification *) notification
{
     // senderObject contains the pointer to the sendMessage passed object. can be nil.
     id senderObject = [notification object];

     NSLog(@"%@ event triggered", self);
}

And then subscribe to the event with:

// custom onEnter
-(void) onEnter
{
     [super onEnter];

     //Here we should register the event listener
     AMSubscribe(@selector(eventHandler:), @"theTestEvent", nil);
}

I've added the AMSubscribe inside the cocos2d onEnter call, just to make sure it is called before any possible message is sent and thus lost, but you can add it everywhere you actually need it.

Things you should remember:

• the selector name is the listener function
• @"theTestEvent" is the name of the event and how you'll call it.
• you don't actually need the third parameter, so left it as nil. It's used if you only want to listen to this object messages.
• the listener function has to be in the same class subscribing to the event.
  

Unsubscribe

The function you should call is defined as:

//Unsubscribe aMessage event for caller object.
#define AMUnsubscribeMessage (aMessage) \
[[NSNotificationCenter defaultCenter] removeObserver:(self) forKeyPath:(aMessage)]

//Unsubscribes all events for caller object.
#define AMUnsubscribe \
[[NSNotificationCenter defaultCenter] removeObserver:(self)]

And this is how you should use it:

// custom onExit
-(void) onExit
{
     [super onExit];

     //Here we should unregister the event listener
     AMUnsubscribe;
}

As before, I've implemented it on the onExit function to make sure it is removed when the scene is moved, but you'll be able to add it wherever you want.

NOTE: Just remember to Unsubscribe to all the events before releasing the object or it will leak.

Send Messages

You'll send the messages with:

// send the message aMessage with aObject data
#define AMSendMessage(aMessage, aObject) \
[[NSNotificationCenter defaultCenter] postNotificationName:(aMessage) object:(aObject)]

And you it as:

-(void) menuCallbackSEND: (id) sender
{
     AMSendMessage(@"theTestEvent", [NSNumber numberWithInt:10]);
}

This code is extracted from the sample code below. Which sends a theTestEvent message with the NSNumber 10 as data.

Implementation

The implementation of the system is as easy as adding the "MessagingSystem.h" class to your project and calling the functions as described before.

Download

You can download a sample project with everything on it.
It consist of a clean project, just to be as familiar as possible, with the library added.

It consist on the HelloWorld scene subscribed to the event and another CCNode class with a label also registered to the event.

that will run as:

And after pressing the SEND button:

The file | MessagingSystem.h

The sample project | Test project

If anyone has any suggestion or question leave it in the comments. I'll be glad to answer.
Thank you for reading.

Custom localization system for your iphone games

__________

Localizating your application is crucial if you want to reach a broader audience, imaging how a Spanish or German kid will react if the game they try to play is in english or french, they just won't buy your game.

The iphone SDK has it's own localization system, which works very well, but as you may know the default localization system does not allow you to change the language in run-time, just use the OS default system, and it also does not allow other languages beyond what's defined on the iphone OS. So, if you want to change the language from a menu in your game there are many things you can do:

• write your own system, which is utterly boring and implies parsing your language files, or...
  
• overload and use what the framework has to offer.

This post tries to explain, first, how to the new localization system works, and second how to add localization to your system and how to use it to change the language in run-time.

Note: Although it is used for games it might be used for your own applications as well.

How the new system works

a. The iphone SDK way

The iphone SDK provides the NSLocalizableString("tag", "alternative") macro to obtain the localized string, from the Localizable.strings, for the given "tag" string or in case it didn't find a proper match it returns the "alternative" string.

I'll explain in the Implementation section how to build the Localizable.strings, just know that it has a strings in the format:

"tag" = "Localized text for the tag";

E.g.

NSString *localizedStr = NSLocalizableString(@"hello", @"Hello World");
//IF it finds the "hello" tag on the localizable.strings for the current OS language it will return the localized string.
//ELSE will return "Hello World"

b. The new way

With adding the LocalizationSystem.h and LcalizationSystem.m you add the following functionality to the default system.

• you'll be fully compatible with what was already done.
• you'll be able to change the language in run-time
• you'll be able to support languages not added in the iphone OS implementation, like Esperanto, Catalá, Elfic,...

Using it:

It's usage is fairly simple, there has been defined 4 macros that extends the default functionality. These macros are:

1. LocalizationSetLanguage("language")
Using the following macro you'll be able to change the localization default language into the language you want.

// Sets the desired language of the ones you have.
// example calls:
// LocalizationSetLanguage(@"Italian");
// LocalizationSetLanguage(@"German");
// LocalizationSetLanguage(@"Spanish");
//
// If this function is not called it will use the default OS language.
// If the language does not exists y returns the default OS language.
- (void) setLanguage:(NSString*) l{
 NSLog(@"preferredLang: %@", l);

 NSString *path = [[ NSBundle mainBundle ] pathForResource:l ofType:@"lproj" ];

 if (path == nil)
       //in case the language does not exists
       [self resetLocalization];
 else
       bundle = [[NSBundle bundleWithPath:path] retain];
}

The "language" string should match what you have on you Localizable.strings file

2. AMLocalizedString("tag", "alternative")
Gets the Localized string:

// Gets the current localized string as in NSLocalizedString.
//
// example calls:
// AMLocalizedString(@"Text to localize",@"Alternative text, in case hte other is not find");
- (NSString *)localizedStringForKey:(NSString *)key value:(NSString *)comment
{
 return [bundle localizedStringForKey:key value:comment table:nil];
}

The AMLocalizedString works just the same way as the NSLocalizedString.

3. LocalizationReset;
Resets all settings, in case you'll allow your user to leave the language settings as default.

// Resets the localization system, so it uses the OS default language.
//
// example call:
// LocalizationReset;
- (void) resetLocalization
{
 bundle = [NSBundle mainBundle];
}

4. LocalizationGetLanguage;
Gets the current set language.

// Just gets the current setted up language.
// returns "es","fr",...
//
// example call:
// NSString * currentL = LocalizationGetLanguage;
- (NSString*) getLanguage{

 NSArray* languages = [[NSUserDefaults standardUserDefaults] objectForKey:@"AppleLanguages"];

 NSString *preferredLang = [languages objectAtIndex:0];

 return preferredLang;
}

Implementation

Step 1. Creating the project

I'll use a Cocos2d 0.99.0 project as I wanted to demonstrate the system on games, but you'll be able to create the project better suits your application.

Step 2. Add localization to your project

To do so, you'll need to:

1. in resources group within your project, right click add... -> New File
2. I'll appear a window like the following. Go to Mac OS X -> Resources and select Strings File. Name your file "Localizable.string".
   

At this point you have added the localization file to you project, now open the information of the file (right click -> Get Info / cmd + i), and on the General tab press the Make File Localizable. You will get this as a result.

Now its time to add the localization you want.
tip: Name it as the language name in english. e.g "spanish", "french", "german",...

Step 3. Add the text.

Now open each of the files to add the text you want to localize, remember the format. Do it in the desired language file.

"tag" = "localized text";

"hello" = "HOLA MUNDO";

Add this point is exactly as if you were adding normal localization.

Step 4. Add the new localizatio file to your project.

You have to add the LocalizationSystem.h and LocalizationSystem.m to your project.

This can be done in two ways.

1. Right click -> Add existing files... wherever you want to add the files, select them and click ok.
2. You can darg from the sample project the group containing both files to your project.
   

Step 5. Just use the library.

1. Add

#import "LocalizationSystem.h"

In the classes that need localization,

2. Use AMLocalizableString instead of NSLocalizableString.

3. Use LocalizationSetLanguage to change the language.

LocalizationSetLanguage(@"Spanish");
CCLabel* label = [CCLabel labelWithString:AMLocalizedString(@"hello",@"Hello World") fontName:@"Marker Felt" fontSize:32];

The label will contain "Hola mundo".

Download

You can download a sample project with everything on it.
It consist of a clean project, just to be as familiar as possible, with the library added.

that will run as:

Each button represents a language added and OS, returns to the OS default language.

The files:
LocalizationSystem.h
LocalizationSystem.m

The sample project
Test project

If anyone has any suggestion or question leave it in the comments. I'll be glad to answer.
Thank you for reading.