Wednesday, June 29, 2011

(Subline: Preferrably on a budget.)

As I wrote earlier, I must apparently make an iPhone game. In this post, I am going to relay to you my week-long ruminations on what development environment/game engine to use. I’m running crappy old Vista, so I’d prefer to get it done on that platform.

There are numerous possibilities available today and I don’t claim that this list is exhaustive. It is just meant to give a general overview. I have concentrated on the options that would serve my purpose (2D game) best. Thus, I have excluded things like Unity3D or the Torque 3D. ManiacDev has a list of more possibilites.

Development on PC

Since late 2010, Apple are more lenient about where and how you can produce your apps. They can now be created entirely on PC. (However, as far as I know, uploading them to the App Store still has to be done on a Mac, but you can probably borrow one from a friend for a minute hour day.)

In no particular order:

Marmalade (formerly Airplay SDK)

http://www.madewithmarmalade.com/

• Free for indie devs, proprietary codebase, runs on Windows, MacOS
• Deploys to: iOS, Android, Windows Mobile, Symbian and others
• Scripting: C++ in Visual Studio (Express)
• Requires Mac? Yes, for uploading to the AppStore.
• Comments: There are a boatload of tutorials, but I found them sloppily written. I have severe problems with C++’s loosely structured nature, so that might be the reason. Features are okay, lots of 3D games are developed wit this. No editor exists for 2D animations/levels, but a UI editor is apparently present.

OpenPlug

http://www.openplug.com/

• Free, proprietary codebase, runs on Windows, MacOS
• Deploys to: iOS, Android, Windows Mobile, Symbian and others
• Scripting-language: A light-version of Actionscript 3 in Flash Builder or FlashDevelop
• Requires Mac? Yes, and XCode for signing and uploading to the AppStore.
• Comments: Says it uses Actionscript 3, but fails to support basics like Movieclips or SWF-loading. Can’t even rotate objects! Hardly useful for games more complex than Space Invaders.

Adobe Flash/Air

http://www.adobe.com/products/air/

• SDK is free, proprietary codebase, runs on Windows, MacOS
• Deploys to: iOS, Android, Blackberry
• Scripting: Actionscript 3 in Flash Builder 4 ($200), Eclipse, FlashDevelop (free), Flash CS5.5 ($600)
• Requires Mac? Yes, for uploading to the AppStore.
• Comments: Adobe is extending their AIR platform with Android and iOS support. Basically, you develop a normal Flash application and wrap it in an AIR player that is optimized for mobile phones. It seems to have some problems with performance. Requires some newer version of Flash or SwishMax to make SWF assets. Does not work on iPhone 3G and below or on iPod generation 1 and 2.

Development on Mac

If you have a Mac that runs a reasonably new version of MacOS X, you get to use Apple’s official IDE as well as third-party tools (that all more or less feed into XCode). I couldn’t test any of these programs myself.

Apple XCode

http://developer.apple.com/technologies/tools/whats-new.html

• $100/year for members, proprietary codebase, runs on MacOS
• Deploys to: iOS
• Scripting: Object-C in XCode Editor
• Comments: This is the mothership. You don’t actually pay a yearly fee for XCode, but for the Apple Dev Program that lets you publish and sell games on the App Store.

Cocos 2D

http://www.cocos2d-iphone.org/

• Free, open-source codebase, runs on MacOS
• Deploys to: iOS
• Scripting: Object-C in XCode Editor
• Comments: As you can see, this is just a framework that makes game creation in XCode easier. You still have to install XCode. That said, it seems to provide many useful features.

Sparrow

http://www.sparrow-framework.org/

• Free, open-source codebase, runs on MacOS
• Deploys to: iOS
• Scripting: Actionscript-like language in XCode Editor
• Comments: Another framework for XCode, this one hides Object-C behind a clean and easy layer of… something that apparently resembles Java and Actionscript. Sounds interesting to me.

iTorque 2D

http://www.garagegames.com/

• $100, open-source codebase, runs on MacOS
• Deploys to: iOS, additionally Windows and Mac for another $99
• Scripting: TorqueScript in Torque editor
• Comments: Recently revived Garage Games offer their engines for $100 each. Has editor for levels, game objects, sprites. You are required to put Torque’s logo in your stuff.

MoSync

http://www.mosync.com/

• Free, open-source codebase, runs on MacOS, Windows
• Deploys to: iOS, Android, Windows Mobile, Symbian and others
• Scripting: C++ in Eclipse
• Comments: I was not sure where to put this. It’s really not possible to deploy an app for iOS with MoSync. MoSync will export an XCode project for you. The actual building has to be done in XCode. MoSync 2.5 is now also free for closed-source projects, as far as I can tell.

Corona

http://www.anscamobile.com/corona/

• $200-$350/year, proprietary codebase, runs on MacOS, Windows
• Deploys to: iOS (on Mac), Android (on Windows)
• Scripting: Lua in Corona editor
• Comments: The way this works is that you develop on a Mac for iOS and on Windows for Android. Funny marketing blurb: “Develop your own Fruit Ninja with less than 400 lines of code!”

Sencha Touch / PhoneGap

http://www.sencha.com/products/touch/ | http://www.phonegap.com/

• Free, open-source codebase, runs on MacOS, Windows
• Deploys to: iOS, Android, Blackberry, Windows Mobile etc.
• Scripting: Javascript with HTML5 and CSS3 in any HTML editor
• Comments: At quick glance, the relationship between these two seems to be this: Sencha is a framework for building apps that can be run in a (mobile) browser. PhoneGap then packages these HTML projects into binary apps. While Sencha apps can be used in Safari, if you want to make a stand-alone app for iOS, you need PhoneGap for Mac which needs XCode. Games in Javascript can be done, but this route seems more suitable for utility or business apps.

GameSalad

http://gamesalad.com/

• Free to $500/year, proprietary codebase, runs on MacOS
• Deploys to: iOS, web(?), MacOS
• Comments: This is one of those drag-and-drop game generators. No scripting required. Seems powerful, but again, needs XCode: “In order to submit your GameSalad made game to the App Store, you must first convert it to an Xcode project which can then be used to build a .app file for distribution.” $500 a year get you priority technical support and get rid of the GameSalad-branded preloader.

Other programs have announced future support for iOS, like GameMaker.

My favorite

If you care, I will tell you that I’m going with the Adobe Air option. Why shouldn’t I use the skills I already have? I really don’t want to muddle through C++ if I don’t have to. I find Actionscript 3 clean, consistent, and elegant. I’m hoping my tiny little test game won’t be affected too much by the performance issues. The biggest drawback is the device restrictions: iPhone 3G is apparently too weak for the hungry, hungry Air projector. Oh. Well.

PS: If you feel like there are errors in this list, please contact me and I will look into it.

Tags: apple, game engines, ios

Thursday, June 16, 2011

Three weeks ago, my friend challenged me to make an iPhone game. After some pondering, I decided that Pressure Cooker can do that! I mean Pigeon almost looks like an iPhone game already, all bumbly and cheery and “casual”. Although I wanted to go more into story-driven games from here on, the idea of an app certainly grew on me – especially since I was in a rut with ‘Into the Core’.

Apple sucks

I have never given mobile games much thought as I consider it an oversaturated market and don’t like Apple’s restrictive policies. Who wants to pay $99 just to be allowed to release something? However, the fact that I own an (albeit old) iPhone should indicate that I don’t really think Apple sucks, I’m just naturally given to inflammatory remarks. So Apple doesn’t suck and their devices are precious little gold bars and everyone on the subway and in the streets loves using them all the time, but how am I going to stand out amidst half a million apps?

Why bother?

Everyone I tell that I plan to make an iOS game immediately asks me what I’ll do with all the millions. *ahem* Yes. So if about 2 people will buy my game, what are my realistic goals?

• Number A: I want to have fun. Bobby Kotick doesn’t like that but that’s why he is CEO of a multi-million dollar international corporation while I am an under-employed, starving designer.

• Number B: Closely related to A, I want to try to make a game I’d personally enjoy.

• Finally, number C: I’ll go for experience. Yeah, I can scribble nice graphics, but check it out: I made an i-app!

What to do, what to do?

At first, I unearthed an old idea for a story-heavy labyrinth/puzzle/adventure game. Then I realized it wouldn’t work on iPhone’s small screen and with its emphasis on simple navigation. I wanted something that would work with single finger taps. Right now, I have amassed about 5 ideas (that probably all have been done before, but I don’t care – see above) and I’m starting with the easiest scripting- and interaction-wise. ‘Into the Core’ will have to stand back for a while.

Engines

In my next post, I will write about something that I hope is actually useful for other people: A comparison of the available SDK’s, their pros and cons and how I made the choice to go with the one I’m going with.

Tags: apple, development, game design, ios, planning

Wednesday, April 27, 2011

Now that I have made a game, I get to write a hopelessly self-indulgent review entry about it, mainly because I realized a few important things. So here’s what I intend to do differently next time:

1) Thou shalt usability-test!

I have kept the development of Pigeon pretty private, so I didn’t do any usability tests. Finally letting friends play it in a nearly finished state was pretty eye-opening: The navigation scheme is crystal-clear to me, so why is it taking them five minutes to understand how to move the player around? Even the help-features could only provide a band-aid over deeper control issues. So if you’re using an unusual control scheme, test it with players first. This is easily the point that could have benefitted the game most.

2) Know your scripting language

When I planned the game, I knew next to nothing about AGS and its capabilities. The only thing that made me choose AGS over Wintermute and Flash was the large, active, and, welcoming community. People seemed to be making all kinds of neat games with the engine, so I happily drafted some timed puzzles thinking it wouldn’t be a problem. Then I got caught up in the details of the scripting language.

For a while, I was debating just scrapping the game, then other times, I thought about rebuilding it from scratch in Flash, but I had already invested so much time into the AGS version, I honestly just wanted to finish the game and move on.

3) Timed puzzles – use with caution

I found out that timed puzzles are really hard to get right, especially multiple ones in succession. In conjunction with the above point, this could create some moments for the player like: “Why is this not working now when it looks like it should? – Oh, because the designer didn’t intend for it to work until I have done something else first.” This is the most you can possibly frustrate a player.

4) Talking characters are nice

As opposed to mute pigeons, talking characters can give hints and explain challenges in words rather than having to use visual cues alone, which need more testing and have to be done really, really well to be understood. (While working on Pigeon, I played Ben304′s ‘Shoot, I Got Abducted’, and gee-whizz, even his aliens talk! So convenient…)

5) One-room games

One-room games, especially ones with many moving parts where lots of stuff is going on, are tiresome and frustrating to make. You seemingly never see progress because after weeks, you are still staring at the same screen.

6) Find an efficient art-style

Oh, vector graphics. I love you and I hate you! You are beautiful and crisp and cheerful when you’re done well, but constructing you and getting your every curve right is a tiring process that takes much longer than it should. Next game: Totally different style and hopefully quicker.

Tags: artwork, Dinner for Pigeons, game design, post-mortem, usability

Saturday, April 16, 2011

Oh yay! I wish to inform you that there is a game I’ve made that you can play now. It is called Dinner for Pigeons and that is a pretty descriptive title.

If you direct your mouse pointer to this here link and go click, it takes you to the download page. Simple, right? And free! Did I mention the game is free? It is really just a tiny cutesy game that you can devour in a couple of minutes.

I hope this is the first in a long row of games that I plan to make until I die or run out of internet. I mean, I put all this money and effort into this website, so I better use it, right?

You can comment on the game or rate it here.

Tags: Dinner for Pigeons, release