But things just went down hill from there. On Sunday your main competitor, Mystery Bunny Games, publicly criticized you on their blog! They pointed out that all that Telnet business you were babbling about made your applications waste memory, increased the size of your binary, and misspent time initializing frameworks that were never used in the final release of your app. They called it a disservice to the users, that have to suffer slow, bloated apps cause some lazy developer decided to add thousands of lines of code just for his own convenience. Ouch.

If that was not enough, this morning you got rejected again… by Apple! They discovered they could use your binary to upload Lua scripts and run all kinds of hacks on the device. Somehow they didn’t thought that was cool.

But you have learned the lesson: never follow any advice you get on the intertubes. Now, let me explain you how you can fix two of those three problems.

Debug/Release

Whenever you build your applications you always start with an Xcode project template that has the basis all setup for you. Between other things it comes with one Target representing the product you are building, and two Configurations with the settings appropriate for both a Debug build, and a Release one.

The Target contains between other things what files, libraries, and frameworks are linked and compiled. And that is your problem. Your Telnet debug server class, AsyncSocket and the CFNetwork framework it requires, plus all those files of the Lua runtime, should really not be in your Release build; they are Debug tools. How can you have the two different builds include different files? You only see two ways of doing this, and you don’t like either.

1. To create different Targets for Debug and Build, and forget about the Configurations all together. But then for files that should be shared you will have to keep the targets in sync yourself, adding files to one then to the other.
2. The old #ifdef/#endif trick: edit all those files so they end up empty if you are building a Release. But modifying 3rd party code? You will need to do it every time they update it! And what about that framework you are linking to? Even linking empty files takes time, especially since your development powerhouse is the cheapest Mac Mini you could find on eBay.

Chunking with static libs

The first thing you really need to do is separate all this code into chunks. On one side all the code that is required for both Debug and Release. On the other, all the code for your debug server. So you start by putting it all into its own project, and building one of those static libraries you have heard about. It is so easy these days… Apple even provides you with a project template out of the box to do this.

What? Don’t want to do it yourself? Gosh, you are so damn lazy. OK, I will give you the code! Just grab it, build it and you will end up with a libLuaDebugServer.a that contains all the stuff from the last time. Well… almost all.

Remember that CFNetwork framework we needed? Static libraries don’t… well, they don’t include frameworks so… I guess we still need to link to that in the main proj… Why are you looking at me like that? Man, I am getting there! Don’t worry! When have I failed you? Yeah, don’t answer that.

Otherworldly flags

So now that you have that library, you can delete all that code from the main project and add the library instead. If you want to get serious you could even do some of that cross-project referencing and target dependencies crap. But you know what? You will still have the same problem! Adding your static lib to the project will add it to the Target, and that will link and compile it in both Configurations!

So is time to rethink this. Linking is the problem, and you need to do it differently depending on your Configuration. Hey, what’s this?

Other Linker Flags? I know you never look at any of these arcane build settings unless it is to check the -O Turbo button. But you can pass to this one here parameters for things you want linked only in the configuration selected! How? Easy.

-framework NameOfFramework
-l NameOfLibrary

So in our case, this should be…

-framework CFNetwork
-l LuaDebugServer

By the way, notice is not CFNetwork.framework or libLuaDebugServer.a; it figures out the filenames on its own. Now that you have that you don’t need to add the files to the Target, so they will not be linked and compiled with the Release build. Except that if you try to build the project right now, you are just going to receive a bunch of gibberish errors.

Paths

Although Xcode has no problem finding that CFNetwork framework, it has no clue where the hell your static library is. Not only that, but it doesn’t know where the headers of your static library are either, so when you call any of the methods of your LuaServer class, is more bitter than your quadruple shot of the mornings.

I am sure that you saw this coming, but you will have to mess with build setting again. The two we need are Header Search Paths and Library Search Paths. Let’s imagine that you have your static library project in the same folder than your main project. Then the paths should be like this:

Header Search Path:

"$(SRCROOT)/../LuaDebugServer/"

Library Search Path:

"$(SRCROOT)/../LuaDebugServer/build/
$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)/"

The important parts of those paths are the quotes (useful in case you have your projects in folders with names containing spaces), the $(SRCROOT) (that points to the folder containing the main project), and the $(EFFECTIVE_PLATFORM_NAME) (that makes sure to grab the correct version of your library whether you are building for the simulator or for the device).

Check?

There you have it. The same project than before, featuring Pancho the Begging Cat, built so it only uses the Telnet Debug Server and all the Lua code in Debug configuration, but not in Release. You don’t believe me? Is easy to check!

Debug

Et Release

Also, did you noticed how after building for the simulator, the firewall in your Mac didn’t bug you about accepting connections when running the Release build? I say you are ready for a nasty response to the Mystery Bunny Games people. If you only knew who they are…

NO!
I am in love with #nameOfCancelledProjectHere#!
Can you send me a .app or .ipa so I can play it?
I am seriously so mad right now!!!!

There you have it. A true fan of your work. Somebody that got really excited about a 1–day prototype by just reading about it somewhere online and looking at some awful screenshots of programmer art. If you compare it with the crap your friends are giving you lately about your projects this person is the best thing that ever happened to you! And he is seriously so mad right now. Not with one, or two, but with four, four exclamation marks! He was your best fan, but now he is so pissed he will forever be your worse detractor.

You can see it now. Anytime you post in a forum, join a new social network to avoid the friends that followed you to the last one, or do your taxes online, there he will be right behind you, yelling what an untrustworthy dirty rat you are. And you know what you did wrong, you knew it was wrong even before sending him that fateful email. You told him you have cancelled the project.

Why did you shelved this one? Why did you cancelled his favorite thing ever? To tell the truth you have quite a few rules you follow in the hopes of actually finishing something. Let’s just look at three. Your projects need to be…

Small

You are just one guy. You do it all: programming, art, sound, QA, customer support, testing, accounting, marketing, or any other ungrateful job required to make your game happen. Would it be easier if you worked with other people, contract some of these things out, have a team? Yes, but the crude reality is you don’t have money. You know how difficult all these jobs are, and jeez, what kind of person would ask anybody, even friends, to do all that work for free? No, you are on your own for now, and that means you have to be careful about the scope of your projects, cause you cannot spend years working without income… even ramen costs money these days!

But you know what? Keeping projects small is difficult. It always starts with a simple idea like, I don’t know, a hamster running around the screen. But soon you need to add some variation and interest, so you build levels, and different enemies, and weapon upgrades, and to make it more appealing you write a story line and start planning animated cutscenes, then figure out you may as well add vehicles, and… at the end it seems like your Hamster on a Hover Board idea has grown out of control. It was probably ahead of its time anyway.

You need to shelve anything that even smells like scope creep… were you having dreams of building a new MMORPGs? Forget it! Not on this shop!

Fun

You are making games, and the elusive fun factor is always your main goal. But you have noticed how “fun” means different things to different people; the barista of the day can be hours arranging formations of flying quesadillas into bunny heads; but your best friend laughs every time a quesadilla he shot down spits out cheese all over the screen. Now I could tell you about target markets and what not, but I think there is a more fundamental thing you need to do to make a fun game, and that is having fun making it.

When you are having a blast, when you are so delighted by your creation that it keeps making you smile, when you are loving to tweak it, and even the boring tasks are made bearable by just thinking how damn cool your game is, then you are on the right track. Your users will enjoy it cause its sheer awesomeness will exude all the enthusiasm you put into it into their little fingers. It’s so difficult to stay motivated and pull a project through to the end… if you are not having fun, is not going to work. So the moment it becomes too tedious, it gets shelved!

Seamless

You are creating games for iPhone. Not for Windows, not for the XBox, not for the Nintendo DS, and obviously not for free for a website. Each platform has it pros and its cons, and the quickest way to fail is not embracing what the platform offers, or not accepting what the platform is. Who uses it? How? When? What can it do, and what it is not designed to do? For you working on the iPhone this means your game needs to be:

• Playable in short bursts: pick up and play for five minutes while waiting in line to buy your lotto tickets.
• Made for a small screen: a reduced version of the experience in your computer screen doesn’t work.
• Controlled appropriately: trying to simulate buttons and d-pads? Better if you touch the objects on the screen directly, move the thing around, shoot photos, connect to the internet… in summary, do the things iPhone handles best.

Seamless is the best word you can think of. You know some of your game ideas are too rooted in your previous experiences in other platforms. They just don’t work that well on the iPhone. Does it feel forced? Are you going in circles trying to find an interface that fits your idea? It just may not be the right idea to begin with. So shelve it.

Is difficult, but is all for the better

At the end putting a project to sleep is a difficult decision. You have the best intentions for all your projects at the beginning. And after you have spent months working on something it is even harder! All that time weights like an iron ball attached to your foot. You think, “is not working that well, but… I cannot just trash all this work and start over!”. Don’t get married to your projects that fast. Keep re-evaluating them. If you have to cancel them, at least you have learnt what didn’t work! So if it’s growing out of control, if it doesn’t feel right, if is not fun to work on it anymore, make yourself a favor. Brighter ideas, exciting things that you can actually finish, are right around the corner, waiting for you to pay them some attention. So shelve that puppy and get cracking with the next one!

Not that bad! You cover your eyes. “Not that bad” is the kiss of death in the freaking App Store! You can already see your game  disappearing into the tide of forgotten apps, maybe get a few downloads when you finally make it free and it gets featured on Krapps.com. And the thing is… you don’t know why! Why is it so bad when it has all this cool stuff in it?

You remember when you started it. You were dating that daycare teacher, and inspired with how her sweet voice was always punctuated by the sudden screech when catching her rugrats doing something behind her back, you added to your game dinosaurs farting rainbows while juggling baby’s heads. That didn’t work out; actually, she got a restraining order. But the next date was such a great cook… you added the fire meatball shooter. Then it was the gothic girl (you added the fatty lipid-vampire), then the one in the military (the terrorist-skewer flag poles), then the veterinary (bi-headed chickens), then the farm girl (beheaded chickens)… Is all there on the screen in all its full-color animated glory.

You turn the iPhone off (for some reason is always running out of battery lately), and go after your friend see what’s up with all the laughing. What the…! Is that a gal wearing a mask that says “Evil”? Oh gosh, they are playing a board game in your bar! Disgusting! You knee your friend and point to the door, but is already too late; he is in perpetual snorting/chuckle mode now. You hurry out before it gets to you.

Wait a moment there buddy! Are you saying you don’t like board games? Aren’t you creating a video game? Not the same, eh? You sir are missing out! There are so many games out there with many interesting mechanics: board games, card games, dice games, role-playing games… They have been around for a while too, so I think they can probably teach you a thing or two about how to make your iPhone video game better, you know. Ah, now you are listening! OK, let me just explain you a few things about board games that can be applied to your designs.

The components tell a story

On a good board game you can look at the board, the individual pieces, the cards, the dice, and the box it all comes in, and before reading a word of the rules you should know what the game is about. You have pieces of an island, people screaming and boats, marine monsters, and a big whirlpool in the middle of the board! You must be playing Escape from Atlantis! Or you have a long icy track with a start and a finish line, wooden pieces of trees, cards with illustrations of dogs… this must be a sledge race! Snow Tails! Even if some pieces are abstract cubes, everything works together to support the theme and create a powerful image, and a promise for a experience that will be remembered.

The players know what their options are

At any moment, a player can look at the board and see the whole state of the game. He can see what tunnel his Space Marines are in, the blip in the next hallway that may reveal some violent Genestealers or be fake, just a trap to misdirect his resources. He knows he will have to open the door to find out, advance, and fire, with his limited action point supply; with all that info, he can more or less calculate the odds of the flamethrower guy frying whatever is there before one to six 4-arm aliens with razor claws get to him.

Players learn as they go

Some players like to get into the game and learn the rules as they progress. Even simple rules can combine in unexpected ways, and even experience players learn a lesson at every game. After all, nothing teaches you faster to close all those portals to another world than to have your city overrun by tentacled monsters.

There is a clear goal

Maybe the players are not on top of all the rules, but there is at least one thing all of them will want to know from the very beginning: how can I win? Does the player that kills the dragon win? Or is it the one that stole the most gold and got out while the rest were fighting the dragon? Different goals make for totally different strategies, and making clear what those goals are is of the utmost importance. Making it easy to guess who is getting ahead at any moment also enhances the game with ever-changing conflicts.

Quality components make a big difference…

Games with good components, even if they have terrible rules, are a pleasure to play. The click of the stones in a wooden Go set, the thick lavishly illustrated cards of Magic the Gathering in your hand, or a battlefield full of painted metal miniatures and props in a Warhammer 40K battle. Yes, you could play Go with bottle caps on a note pad, or Warhammer with some cheap plastic cowboys and indians and a few cardboard boxes. The rules, the gameplay, would be the same. But would the experience be the same?

…cause physical items are cool

Players like to roll the dice even when is not their turn, listen to them bouncing playfully on the table. They like to play with the pile of plastic coins by their character sheet. They like to organize the little wooden fences around their farms and set the animals in random patterns inside. They like to move their figurine with rhythmic little thumps over the board, one square at a time. The tangible nature of the pieces, being able to move them around, listen to the many different sounds they make, adds to the enjoyment.

Nobody wants it to take forever

Let’s be realistic, the number of players that enjoy going through the ASL binders is really small compared to the ones that like to pull Ticket to Ride out the shelf and start playing. This is clear too when you invite non-gamers to play. First question usually is, how long does this one take? As more and more euro-style games get published the trend is clear: simple rules and short play-time sells more, because people enjoy a 30 minute one-shot every now and then, but they think twice before getting into a 3 hour deal.

Even for gamers setup time is also an issue. I look at my collection, and even for games I love I have to stop and think… do I want to spend the next half hour setting all the little pieces? Setup time and complicated rules are both barriers to entry.

The experience is bigger than the game

Look at those people in the bar. They really seem to be having fun. But wait, the people watching them play, your friend included, seem to be having fun too. The question is then, is the game itself fun? Or is all the goofiness going on around the table? You know what, is both. After all, a boring game would not propitiate that kind of behavior! At the end of the day everything those people will remember is having a great time with their friends. And next time they see that board game sitting on a shelf somewhere the memory of this evening will bring a smile to their face. Just remember you want to be associated to those happy moments and not to the frustrating ones!

And that’s all for today buddy! Not get out of your video game shell and go play something else!

Most images were taken from the excellent BoardGameGeek.com. Go visit the the site to learn about board games you are planning to buy, or find excellent gaming aids for the ones you already have.

It all started with the interface. You were there positioning buttons, entering coordinates by hand: the score label, the Menu-pause™ widget, the alertness/drunkenness meter… it really started bugging you after having to re-compile for the tenth time just to find your designer (that is, you on Fridays) had decided to change the size of all the graphics. Then there was the turtle. I mean, how difficult do you think it is to calculate the mass of a freaking turtle? But somehow anytime you tried to change it the physics engine either made it go through the floor or bounce like crazy. Gosh man, didn’t we go through this already? Except your fancy level editor was of no help with any of this. You see, I may run the risk of repeating myself, but maybe is time to revisit the advice I gave you. First you need better tools.

Implementing a Socket Server for your iPhone Game

If there is anything to learn from all this frustration is that waiting to recompile sucks. Seeing changes live, that’s what you need. Being able to move your interface around until you get it perfectly lick-able, or change the hit points of your Pretzel Dragon till you find the perfect balance between Masochist level and N00b. At runtime. That’s what we are talking about! Sure you can already do all that with the debugger, but really… do you enjoy pausing and restarting, fishing for the right breakpoint and variable? That’s like having a swimming pool when what you need is an umbrella. Not fun.

So you come up with a plan: you are going to run a server on your game, connect to it from your computers command line, and send commands for the things you want to modify. You look on the interwebs for information on how to do this and then start wondering if maybe Networking 101 in school had nothing to do with hanging in the bar with the girl of the anchor tattoo. I could explain you how Berkeley sockets work, and the difference between transfer protocols, and we could talk about streams and datagrams, and the beautiful C API… or we could just use AsyncSocket. You will like AsyncSocket cause:

• you only need to add one class to your project! There are two available, one for TCP connections and another one for UDP. We will stay with TCP cause we are going to use Telnet to connect to your server.
• you don’t need to worry about low level details. Whenever the server accepts connections, clients disconnect or timeout, or a number of other things happen, AsyncSocket will just call your delegate methods. And for starters, you only need to really worry about implementing 4 methods.
• it plays nice with the current application NSRunLoop by default, and is non-blocking.

So you open Xcode, and decide to create a new barebones Window-based Application to test all this. Let’s just call it the Mystery Coconut HQ Simulator. You include AsyncSocket, then the CFNetwork.framework, then finally create a normal NSObject descendant for the Debug Server itself.

DebugServer.h ends up just with a few instance variables: the AsyncSocket object that works as server, an array of connected clients, and a flag to tell if is already running or not. One method for starting the server on a specific port, another for stopping, and we are done.

Then you implement a few delegate methods. I see your server can send messages to connected clients with writeData:withTimeout:tag:, and that it requires NSData versions of your strings. And since you want to listen to connected clients until they disconnect, you call readDataWithTimeout:tag: when they first connect, and then every time you get some input, cause if you didn’t the server would only ever receive the first message!

Nice! That was fast. You have a socket server.

Fast app switching in iOS 4

What? You don’t think is going to work? You think the whole AsyncSocket thing is a prank, like that time the girl of the anchor tattoo convinced you the NSCoders meeting was at the Blue Oyster? Well, let’s see; just add a DebugServer to the AppDelegate and… Holy crap! Who the hell put all this garbage in your AppDelegate?! Oh, wait… does this have anything to do with you using iOS 4? You skim through the docs as your eyes glaze over. OK, don’t get stressed. The important part is: where do you put the code to start and stop the server?

You could put the startOnPort: call on applicationWillEnterForeground:, but then iOS 3 devices will never run that code… no thanks. You end up putting it in applicationDidBecomeActive:.

As per the stop call… applicationWillTerminate: for sure, but also in applicationWillResignActive:, so that when the app goes to sleep you don’t keep the server running and draining battery and stuff. You know the system will kill it if you did that!

You wonder, how would you do all this if it was a game that needs to save state, and handle a run loop? If it was me, I think I would do something like this:

So let’s see what you got. You added a DebugServer instance variable to your AppDelegate. Then started it in say port 9990 in the applicationDidBecomeActive: method. Stopping happens in applicationWillTerminate: and applicationWillResignActive:. With a self-congratulatory smile you check the IP of your iPhone in the LAN before compiling and running.

There it is. A boring gray background. But unaffected by the laughs of imaginary peers looking over your shoulder, you fire up the Terminal and type telnet 0.0.0.0 9990 (or whatever your device’s IP was, I cannot remember now). And… you see nothing. Gosh! Open the port in your Firewall man! Do I have to explain you everything?

Finally. There it is. Those two days you spent messing with color settings in the Terminal were so worthy of this screenshot…

Now… what happens if you run this in the simulator? It works too?! Good job!

Commands?!

There you are, glancing at the screen full of pride. You can hear the Force Theme finally coming up on iTunes. Sun shines outside. Is that the calendar you were looking for under that pile of printed PDFs?

But wait… what can you do now with this? Are you telling me that you can type “exit”??? Really?! How the heck are you going to use this to modify your game at runtime?! Come on, look at those clouds outside!

Well, you obviously have to put more work on this! You grab a notebook and start scribbling a list of commands you need to have, like “get” and “set” and “list” and “make coffee with sock and fish tank”, and… I think you are going to need a parser for all that. But after that what? Well you will need to hook your variables to this system, so when you write “set turtle-mass 1.1″ it converts “turtle-mass” into a reference to a specific instance of your StupidTurtle.mass… You start thinking about registers, and command patterns, and lexers… and start crying while the Imperial March booms in the stereo.

OK, OK. Look, I will help you again. Let me present you my friend…

Lua

Would not it be nice if you could just type code in that Terminal? That it magically knew how to do operations, and loops, and assignments… that it knew about your variables… that it was as easy as writing in Xcode? Well, you cannot do that. At least not in Objective-C cause, you know, your friend the compiler waits at the end of that track. So what you need is a scripting language. You have read before about games using Python and similar languages to help with their fancy data-orientation. So you look around and find Lua’s ugly website. A scripting language that was made especially to be integrated with C? And with other languages too?? Wait, is that Objective-C in that list?

You check around diverse Objective-C/Lua projects and end up grabbing the Lua Objective-C Bridge. Seems kind of old and unmaintained, but you think is worth a try. You download the latest Lua 5.1.4 too, and add all the files to your project except for the lua.c, luac.c, and print.c, that you read somewhere are not needed. You go back to your DebugServer header and add a lua_State instance variable, then you change your init method implementation…

Then you add this to your onSocket:didReadData:, right after checking the client didn’t type “exit”.

Then you run the app again, connect through the Terminal, and start typing.

But you get nothing. Then you remember you have not fed the client the results… but what is that in Xcode’s console?

Yes! You start coding like crazy. In a few minutes you have a game loop, some sprites, and a GameState object with some properties and methods. You add the following to your Lua setup:

Just grabbing the GameState object and adding it as a Lua variable “game”? How do you call the methods of this object then? Seems “game:test()” calls [gameState test], and “game:setX_Y_(0, 2)” calls GameState’s setX:Y: selector! And since properties create accessors, you can also call those??? Can it really be that easy?!

The sun is bright, birds sing… as the Rebel Fanfare quicks in, you look at your phone and see somebody is calling… from your favorite coffee place.

@mouseStuckOnACoffeeShopDoor

Eeeeeeeeeeeekkkkk! Oh, God, I thought you were going to step on mee! Well, don’t look at mee like that! You have never seen a mouse, or what? I am just… resting here, OK? I will bee on my waee when my back legs climb this damn bump. Who had the ideea of putting this stupid plastic trim in the middle of the entrywaee anywaee?

Ah yes, you want to know about the #iDevBlogADay thingy. Oh, I can tell you! I saw it all from the very beginning. I was sitting on the blueberry muffins… have you tried them? Oh, yes, they are good. Just don’t… don’t eat the ones with… eh… chocolate chips, OK? Just saying. Anyway, this guy was hanging around with one of those new iPhones in hand. Tweeting like crazy, not paying any attention to his wife that had just order a blueberry muffin with chocolate chips for him. He he. He he he hehee. He he was talking with somebody about how great his new blog post was. Full of himself if you ask mee. The other guy is like…

chrismwaite

(Christopher Waite)

@mysterycoconut Great post... highly entertaining. You should do them more often.

On 23-6-2010 18:43:19 from Echofon in reply to Miguel Á. Friginal

Just imagine his gloat! The jerk…

@deerTryingToSleepInTheRoadShoulder

Zipping along, zipping along! I am trying to sleep here for God’s sake! All day long zipping along! And they had a red car too! Do you know people think red cars run faster? Well, is not true. But the drivers sure think they can! Agghh! Saw that one?! That guy didn’t even saw me!

But yes, of course I saw when it happened. Not like I could sleep, could I??? I knew there was going to be trouble the moment the other guy showed up. He is always trouble if you ask me. He is all soft worded and sneaky and then… Badaboom!

SnappyTouch

(Noel Llopis)

@mysterycoconut @chrismwaite You know, that's not a bad idea. If we get @georgesealy and a couple more, we can have one post every day! :-)

On 23-6-2010 22:29:11 from Seesmic Web in reply to Miguel Á. Friginal

Saw that? See how fast he invites himself and the Kiwi to the party? I bet he drives a red car.

@sealShapedPawnWithSadFace

Is the White Queen looking in this direction? Oomph, have you seen that knife she has? I bet she is thinking of skinning me on the next game. Oomph! :(

That guy looked crazy, OK? Almost as crazy as the White Queen. But at least he didn’t had a knife. Not one that I saw at least. What he had was one of those annoying iPhone cameras. Snap, snap all over the vitrine, with flash and everything. Do they make iPhones with flash now? I though that guy Seal Jobs was against flash, no? Oh well, the world is crazy, I tell you.

So yes, it was getting big by the minute. Lots of people were joining, don’t ask me why. Is crazy.

OwenGoss

(Owen Goss)

@mysterycoconut @SnappyTouch Have I been signed up to do blog posts while I was scraping paint off my storm windows? I can sure try! :)

On 24-6-2010 00:18:27 from Echofon in reply to Miguel Á. Friginal

GavinBowman

(Gavin Bowman)

@mysterycoconut @snappytouch What happened? I step away for a minute and now I have to write a blog post every week?

On 24-6-2010 00:22:47 from Twitter for iPhone in reply to Miguel Á. Friginal

They didn’t even have a name or a hash tag! Look!

GeorgeSealy

(George Sealy)

@OwenGoss @mysterycoconut @frederictessier @GavinBowman @Bob_at_BH @SnappyTouch Should we have a name for our blogging support group?

On 24-6-2010 01:46:06 from web in reply to Owen Goss

I mean, how can you be tweeting all day about something and not even have a hash tag? Crazy I tell you. They didn’t have a clue:

SnappyTouch

(Noel Llopis)

@mysterycoconut DailyDevBlog? Incredible iPhone Indies? Week Of Awesomness? iDevBlogs?

On 24-6-2010 15:34:56 from Seesmic Web in reply to Miguel Á. Friginal

It was my idea. I… oomph, I know about Tweeter. I have been doing it for years and years now. I have the perfect covert too. I can tweet crap about the White Queen all day long, and she will never figure out if it was me or one of the other seven. Not that I have ever done that :( But in this case, it was totally me. I invented #iDevBlogADay.

And he didn’t even thank me :( Oomph!

@babyReachingForACigar

Chacho! Can you tell him to stop doing that? Crap! Have been here trying to get to it for an hour and the damn gorrino just keeps moving it away! Stop it! You are not going to help, are you? Fuck it. That other guy didn’t help me either.

He was freaking out. Everybody wanted a piece of the cake by then. It was like a daycare. “My ideeea”, “I was here fiiirst”. The cunts. Look how they fight!

Bob_at_BH

(Bob Koon)

@SnappyTouch @mysterycoconut If you want to get technical, I started it yesterday. :)

On 24-6-2010 02:44:24 from TweetDeck in reply to Noel Llopis

mysterycoconut

(Miguel Á. Friginal)

@SnappyTouch That's a great idea! Wait, let me look on Address Book for someone that doesn't have to go to work tomorrow… ABCD… N! Noel! :)

On 29-6-2010 02:51:00 from Tweetie for Mac in reply to Noel Llopis

HeadcaseGames

(Headcase Games)

@mysterycoconut I just want some exposure :)

On 27-6-2010 00:01:21 from web in reply to Miguel Á. Friginal

He was losing it. Then he decided enough was enough, and things got nasty.

mysterycoconut

(Miguel Á. Friginal)

@GavinBowman look, is going to get nasty if you guys do that. Wednesdays are the only days people can skip.It was in the rules #idevblogaday

On 24-6-2010 20:34:15 from Tweetie for Mac in reply to Gavin Bowman

He made a fucking waiting list and was ready to give the boot to a couple people.

weheartgames

(Mike Berg)

@mysterycoconut So if we miss a post, we get the boot?? No pressure!

On 29-6-2010 22:25:28 from Echofon in reply to Miguel Á. Friginal

Somehow he got some support too:

SnappyTouch

(Noel Llopis)

@mysterycoconut Sounds good. After all, the point is to motivate us to write. Getting kicked out isn't the end of the world #idevblogaday

On 27-6-2010 17:30:54 from Seesmic Web in reply to Miguel Á. Friginal

And when I saw that I told him, “Chacho, to do all those dirty jobs you need thugs. And a cigar”.

SnappyTouch

(Noel Llopis)

@frederictessier Yes, back to work. Otherwise @mysterycoconut's won't be the only wrath you'll have to face :-b

On 26-6-2010 00:30:58 from Seesmic Web in reply to Frederic Tessier

So yeah, bad business all together. I would not trust any of the crooks to help a poor bab… fuck! Almost got it! Stop moving the fucking cigar, you idiot!

@catWithWiseFaceSittingInJapaneseGarden

Meow! #iDevBlogADay is a group of indie developers that want to blog more regularly. Each day of the week is assigned to 2 people. Each person writes in his own blog about whatever he wants, including silly stories that have nothing to do with real game development. Then they tweet about it with the #iDevBlogADay hash tag. If a person doesn’t blog during his assigned day, his spot is given to a different developer. You can read all the participating blogs through the group’s RSS feed. If you are an indie developer and you want to participate, ask @mysterycoconut to be included in the waiting list.

Meow.

struct CannibalisticHerbivorousPlant
{
    CannibalisticHerbivorousPlant()
        : position(0,0)
        , velocity(0,0)
        , hunger(HungerType::Atrocious)
    {}
    Vector2D position;
    Vector2D velocity;
    HungerType::Enum hunger;
};

CannibalisticHerbivorousPlant cannHerbPlants[MAX_PLANTS];

cannHerbPlants[0].position = Vector2D(10, 13);
cannHerbPlants[1].position = Vector2D(-5, 0);
cannHerbPlants[2].position = Vector2D(13, 0);
...

I know, that doesn’t look like anything I would ever code myself, but we are talking about you after all, and you have to recognize that when you are in rapid prototyping mode, you are pretty sloppy.

Your development cycle at this point is something like this:

1. Code furiously, adding the functionality for the new items or monsters, then their position and other state in your test level.
2. Compile. Go get coffee, the sloppy code is getting kind of big.
3. Run the app. Find that you put a plant in mid-air. Although you archive the idea for a future feature, you decide right now it just looks ridiculous.
4. Modify the position in your code.
5. Recompile. Go get another coffee.

After a few dozen items, and some hundreds of modifications, your hands are shaking all over the keyboard, and you swear your IDE is spawning duplicate windows like Gauntlet ghosts. Time to take an extra shot, and think about your tools.

Unsolicited Advice #1: Spend Time on Tools

So the code is getting messy by the minute, and this is just the test level! In the long run you are going to need something that loads the different levels, and saves player progress. You have heard of this technique of just dumping your memory into a binary file for a quick load/save, so you do that. You ran your game once more, save the initial contents of memory into a file, then proceed to get rid of all the code that initialized your test level, and replace it with a nice simple call to your new load function. It works. Purrffect.

But wait, there is an upside down quesadilla just flying by! How did you managed to miss that? So you look at the hex dump of your level file and you wonder… is that 63A0 the orientation of the quesadilla? Or the grow rate of your zombie peppercorn?

Obviously, you need a better way to do this. You are sold on this prototype and want to go full steam ahead! What you need is a level editor to create and edit these files, one with a user-friendly interface. Even better if is one of those fancy GUI apps where you drag stuff around. That way there will be no more guessing, no more floating plants, no more quesadillas flying out of formation! It will increase the speed of your development cycle tenfold! Once it is done. And gosh, that sounds like a lot of extra work. Just thinking about it you don’t feel so agile anymore. So you prepare for the hardship hoping you can ship in a couple years if you don’t get fed up with the damn editor first. Well, I have something to tell you:

Unsolicited Advice #2: Don’t Get Stuck!

You are blocked. You have looked into doing an application with windows and stuff, and all that Model-View-Controller, event queue, menu managing crap weights like a tombstone on your game’s back. You need to look for alternatives. What do you need, really? An application with a GUI, and a file in your specific memory format at the end. Maybe you can use an open source editor and write an exporter for your format? Or write a command line tool that converts their format into yours?

So you keep thinking about that while you go to your daytime job where you maybe create animated Flash intros with no mute buttons, another one of those stupid drag-n-drop JavaScript shopping carts, and a website or two with a backend database full of nicknacks that somebody expects to sell. You come back home still wondering how to make this GUI where you drag-n-drop your graphics, and somehow saves all that data without too much effort. You decide to go to the coffee shop, iPad under your arm, see if you get inspired by the barista of the day. Would not it be wonderful if you could run your editor right there in the coffee shop too? In your iPad?

If it was me, I sure would use all those nice tools available out there that I am used to work with. Since we are talking about you, maybe you use different tools. But, just for the sake of it, let’s imagine you are like me. You start thinking of creating a “proper” Mac or Windows application, then you change your mind and change it into an iPad one, then you realize you will spend more time messing with code that has nothing to do with your levels than anything else. You change it into a website, with a MySQL or PostgreSQL database, and PHP scripts. But finally you go for the fastest solution: 200 lines of JavaScript, the browser’s SQLite database, a single PHP web service to export the files. A few hours later you have a working editor.

And that’s kind of the point: use whatever you think you can pull off faster. Use the tools you know best, or the ones that others have created before you, and concentrate only on your custom parts. Don’t get stuck on doing things a certain way just because that’s how everybody else with a multimillion dollar budget is doing it. You are an indie! Being small and being able to adapt to changes is your strength! You can change your code really fast, change your tools, change your goals. And at this point, almost anything is valid as long as you can continue concentrating in making your game.

Unsolicited Advice #3:
Faster Development != Faster Coding

Is sunny again. You are sitting in the coffee shop showing the barista of the day your fancy editor running in Safari, having fun placing quesadillas in the sky. “Cool! Can I play it now?” she asks. Mmmm… let’s look at your development cycle again:

1. You let the barista of the day change the quesadilla’s formation in your editor. You export the level.
2. You pull out your MacBook from the bag, start XCode, replace the level file. The barista of the day goes attend another client.
3. You compile your app while you sip your coffee nervously. You hear giggling coming from the far side of the counter.
4. After what seems like ages the game finally loads. You jump off your chair, iPhone in hand, to show it to her. She gives you the “who are you?” look, then continues talking with the other guy.

Wait a moment! That doesn’t seem to be any faster than before! OK, but at least you don’t have any upside down quesadillas, that would have been embarrassing. But how do we make this faster? Maybe loading the level file on the fly? Haven’t you seen some video recently of a guy saying loading content from the web will make your designers wet themselves?

So you modify your load function so it loads from a URL instead of from a local file, adding #ifdefs all over the place to make sure that only runs on your Debug build. Let’s rewind:

1. You let the barista of the day change the quesadilla’s formation in your editor. Is that a… bunny head? Whatever. She clicks Save and the level is saved in the server.
2. You pull out your iPhone and start the game. She squeals with delight when the quesadillas fly by. Ooops. One of them hit a house.
3. She goes back to the editor giggling. Some guy leaves cause he was tired of waiting.

Now we are talking. That kind of development cycle will let you tweak your levels to your hearts content! You will be so productive this will be done in like no time at all! Now, if you could only stop getting distracted by the barista of the day… seems she wants more bunnies. Maybe killer bunnies. Back to coding!

First of all, let me get it out of the way: I am sorry. For three months now we have been selling one application for the iPhone/iPod Touch, the excellent Pip dice simulator. In those three months around 700 people bought it. Seven hundred may not seem a lot to you, specially if you have been reading any iPhone developer success stories recently, but it is way more than I expected for an app that, even through really polished, was competing against a plethora of similar offers.

The thing is, for the whole three months, the Mystery Coconut site has only been a splash screen; no support page, no additional information about us or about Pip, no sign we were alive or even care about the product except for our UserVoice pages. I got an email the other day that nicely sums up what probably has been the unfortunate reaction of most people looking into Pip.

No help page? No troubleshooting? No FAQ? Not even a list of those scrolling tips? Taking bug reports is great, but you need to give your customers a little more info.

So true. Did I say sorry already?

The good news is the site is up, you are reading the first entry of the blog, we have support pages for Pip and news about the upcoming 1.1 version. We are alive and well, and if you are a customer, we have you covered (if you are not, try us out!). Being a one person company is not easy. I put lots of effort into the site and I hope the wait was worth it. I am still working on implementing search, more screenshots and videos for Pip, and some other features. Your feedback is as welcomed as ever, and this time way easier to send my way. So now, let’s roll!