typedef struct {
  CGPoint position;
  float direction;
  float speed;
} BallInfo;

- (void)receiveData:(NSData *)data fromPeer:(NSString *)peer
    inSession:(GKSession *)session context:(void *)context
{
  BallInfo b = *(BallInfo*)[data bytes]; // <<< exception here
  // do something with 'b'
  ...
}

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: EXC_ARM_DA_ALIGN at 0x0011db75

I agree that that piece of code won't win any awards for elegance, but it's plenty fast, which is what I was going for, given that this was a real-time multiplayer game example. I tested it extensively before putting it on paper in the book, and it worked well. But it will not work in the future without some changes.

Eventually I figured out what the problem was, after Matt Galloway (@mattjgalloway) pointed me in the right direction. In a nutshell, if you are compiling code for 3.2 and later, you need to worry about "memory alignment", particularly when dealing with data buffers and casting of something like a void* into int*, for example. For more information read this: Memory Alignment Issues on ARM Processors. Matt also explored this issue in depth on the Apple Developer Forums: Thread: EXC_ARM_DA_ALIGN.

So, how would you fix the code above to work correctly under such circumstances? Here is one possible solution:

typedef struct {
  CGPoint position;
  float direction;
  float speed;
} BallInfo;

- (void)receiveData:(NSData *)data fromPeer:(NSString *)peer
    inSession:(GKSession *)session context:(void *)context
{
  BallInfo b;
  memcpy(&b, [data bytes], sizeof(b));
  // do something with 'b'
  ...
}

Once again, thanks to Matt Galloway (@mattjgalloway) for his insight.

-- Peter Bakhirev

It was fun while it lasted. Mike and I have learned a ton. Now it's time to move on to bigger and better projects :-)

- Peter

Owen Goss from Streaming Colour Studios recently released a new iPhone game called "Monkeys in Space". I helped Owen test early versions of it, and enjoyed the game play even when it was rough around the edges. He finally got it released and it's a treat! It's a great addition to both the "pick up and play for a few minutes" and "sit there and try beating your own records" categories of iPhone games. I highly recommend it - and while you are at it, try chaining as many monkeys together as you can. Personally, I find that to be at least half the fun of the game.

Another game worth checking out is called "Payload", by Rod Strougo (who is part of a company called Prop Group). It literally came out a couple of days ago - and it's a perfect filler for anything from a short coffee break to a prolonged procrastination period (trust me on this one). I personally like the physics and responsiveness of the truck and that elusive simple-but-addictive feel of the game play. Try it for yourself.

-- Peter Bakhirev

-- Peter Bakhirev

Just to be clear, I'm not picking on TechCrunch: they suggested that users should pay extra $2.99 to upgrade to Tweetie 2, and I wholeheartedly agree. It's just that a lot of people don't seem to get that there is a lot more to price than just "most people won't buy anything above $X", and TechCrunch fell into that particular trap this time.

Here is where I'm coming from: I've been interested in the marketing/financial side of the software development industry ever since starting Byteclub.com and realizing that I have no idea how to sell stuff. In the course of researching the topic, I started coming across books that talked about a relationship between psychology and economics. There is definitely a connection there, and if you are interested in learning more about what happens behind the scenes when we are participating in financial transactions, I would recommend reading "Predictably Irrational" by Dan Ariely and "Influence: The Psychology of Persuasion" by Robert B. Cialdini. Another great book on a related topic is "Information Rules: A Strategic Guide to the Network Economy" by Carl Shapiro and Hal R. Varian. It talks about how economic principles apply to the world where information is cheap to reproduce and distribute. The most remarkable aspect of that book is that even though it cites examples from a decade or more ago, same exact rules apply today, even in something as "super-modern" as Apple's App Store.

So, what lies below the surface?

Irrational is king

Research shows that human beings are not rational - far from it. Our behavior when it comes to making financial and economic decisions is and always has been affected by emotions and cognitive biases. That's one of the reasons why they invented something called "marketing": in a perfectly rational environment, your purchasing decisions would be based strictly on value proposition and you wouldn't need a sleazy salesman to tell you why this car is better for your family than that one. (The other reason for having marketing is that we can only process limited amount of information - and brands need to find ways to squeeze their message into our mental pipe somehow). Real world studies show again and again that consumers are influenced by factors other than the true value of the product. The dreaded "race to the bottom" in App Store prices is a good example: a never-ending stream of cheap ($0.99) disposable apps creates an "anchoring effect" in consumers' minds, predisposing them to treat higher priced offerings as something out of the norm, to some degree. (That's what TechCrunch called "realities of the App Store"). But there is no rational reason why some of those apps should be priced so low. And that's exactly what makes picking the right price such a difficult task. Dan Grigsby over at MobileOrchard wrote a great article on the topic, titled "App Store Heresies: Higher Price, Better Ratings. Don’t Discount Your App At Launch".

So, does it make sense for Wolfram to charge a seemingly outrageous price for what appears to be a portal to their free website?

Price and publicity

Regardless of what their true motives were, the very fact that the population of tech blogs and Twitter spent a non-trivial time discussing Wolfram's move and forwarding links around is a win in terms of marketing. Any publicity is good publicity. And all they used for this is price of their app. They didn't have to release an outrageous app that was later pulled by Apple; they didn't have to hide questionable adult content inside of their application - all they did is add an extra 0 to the price, and got an Internet minute of fame in return.

They didn't pioneer this technique, by any means. You must have heard about another recent example, developer of a game called "Alchemize" raising the price to $40 as a means of protest against "cheapskates". How did that move work out for Schiau Studios in terms of publicity? I bet there was a publicity-related bump.

I don't know how much money Wolfram spent on developing their iPhone app or how much they would have to generate in sales to cover the cost, but I bet that publicity that they received is absolutely worth it, at least in terms of brand recognition.

But that's not all. Price has a few more tricks up it's sleeve.

Price and perception-of-value

Studies show that higher priced painkillers work better than lower priced ones. Even if the pill itself is nothing more than a placebo. (See "Predictably Irrational" for details, or MSNBC's article). Does this apply to other things, like perceiving app's quality? I haven't heard of any studies that addressed this particular question, but there is an abundance of evidence that people commonly associate high price with higher quality. So much so, that in some industries it's a standard practice to set artificially high prices on certain products in order to attract a particular kind of consumers and create an aura of exclusivity and quality (Bentley? Tiffany & Co? Rolex?).

A whole plethora of psychological effects could potentially be in play here: from "choice-supportive bias" where you ascribe positive attributes to an option that you ended up selecting, to "social proof" that makes you buy more expensive things to confirm certain social status, to "endowment effect" where you place higher value on objects that you own over the ones that you don't. Regardless of the exact mechanism behind all this, marketers have been exploiting this bias for a long time now, and you yourself have surely been a "victim" of this technique.

Let's take a moment and talk about Tweetie 2. Here's why Loren Brichter's decision to charge users to upgrade to Tweetie 2, even if you already paid for Tweetie, was the only right one: value of the brand must be upheld at all costs. This means keeping up the quality of your products, but it also requires you to charge users premium for the privilege of using your products (if it's warranted, of course). You absolutely want some users to say "I really want X, but it's a bit pricey right now and I cannot afford it", especially after they have had a taste of the quality in the form of a Lite version or one of your other products. Want proof? Look in the mirror: Chances are that you have been upgrading your Apple laptop/iMac/iPhone at least once-per-two-years in the recent history, just because something new and awesome has come out and "that machine does seem to not be enough anymore". If not, then you must know somebody who does. Apple has been skillfully and profitably playing this game for a while now. And let's face it: their products are usually worth it (and so is Tweetie 2).

That's not to say that you can just slap an outrageous price on a turd and expect consumers to fall over themselves to get in on the action. If your product sucks, your scheme will come undone faster than you can say "information propagation".

Setting a high price and maintaining quality are necessary but not sufficient conditions to achieving financial success with your apps. Obviously, there is a whole lot more to it than meets the eye. Just remember: It should be a privilege to use a quality product - price and treat it as such.

I'd also like to mention TextMate, an excellent text editor for OS X. TextMate 2 is in development and Allan Odgaard, its author, promised free upgrades-for-life for those that paid for the original version. I personally think that was a big mistake: those that use the editor often will be more than happy to pay for a significant upgrade, and the developer would be a lot more financially incentivized to work on the upgrade. Plus, TextMate is a valuable brand, and its value should be upheld (and a lot of users seem to agree in the comments here) But Allan has been saying "free upgrade" for so long that it might be difficult to backtrack on it without generating an outcry. I wish him all the luck - hopefully he can find a way to make money on the new version, because he deserves it (we want him to stay in business and make more awesome products!), and keep users happy.

Wolfram is in an interesting position: they don't want their product to become a commodity, but in order to spur adoption, they have to give something away for free (access to the main website) to compete with the likes of Google. $50 price tag reinforces the message of "we are not just some cheap-o graphing calculator app for $0.99". Having started very high, they have a lot of room to play with the pricing if they choose to. In addition to that, they can always try to "pull a Goldilocks" by releasing a lower priced product that will be accepted a lot more favorably. More about that next.

Price as a tool of persuasion

There is another interestingly subtle marketing practice called "Goldilocks pricing" that I'd like to bring up. For some reason, I haven't seen it being widely applied in the App Store (but I haven't specifically looked for it, either). It involves offering consumers several versions of the product: cheap, medium priced, and very expensive one. Given such a spread, consumers usually go for the middle option. On psychological level, this technique might have something to do with an effect called "extremeness aversion", which is a tendency to stay away from fringes and stick to the middle. Regardless of what exactly makes this interesting mechanism tick, the idea here is that the highest priced item doesn't actually have to sell well, or at all, because you will make your money on customers inevitably gravitating towards the middle of the pricing spectrum. The decision-making doesn't seem to work that way if you only offer 2 options, because the higher priced item automatically becomes "the most expensive one" in customer's eyes.

To make things more complicated, some researchers are arguing that there exists an opposite effect, called "extremeness seeking". It comes into play if you, once again, have versions of a product varying from cheap to very expensive, but there are a whole bunch of similarly priced but difficult-to-compare-and-choose-from options that reside in the middle of the pricing spectrum. Example: for a reasonable price, I can either have that car with a DVD plus an awesome subwoofer, or a bigger engine and alloy wheels, or more room for kids in the back. The theory is that, when faced with these choices, consumers will gravitate towards some sort of a "premium package": a higher-priced option that doesn't involve nearly as much compromise and trade-offs. Think about it next time you order a slightly higher priced Surf-and-turf because you couldn't decide between lobster and steak.

Be smart about how you price it

The bottom line is: think carefully about how you price your apps. Don't let a vocal minority that isn't willing to spend money, fueled by mass media, drive your decisions. Understand what your target audience is (read "The two App Stores" by Marco Arment). Think about what message your price sends to potential buyers. Be careful about how you position your brand.

Once again: Ability to use a product is not a right - it's a privilege, regardless of what your users might think. Price it right.

-- Peter Bakhirev

Here is a link to the presentation on Prezi.com: "Networked Games on the iPhone". Or, to see the embedded version, click on "Read more" below.

It was great meeting all of you. Thanks to Barbara and Chuck for organizing a great event.

-- Peter Bakhirev

Scope creep for fun (and profit)

As it turns out, it's hard to come up with a "complete" game in 10-12 hours (surprise-surprise!), especially for those of us that haven't developed many games before (myself included) - mostly due to scope creep and a constant desire to add cool-looking things early on. If you have enough discipline to come up with a crude project plan and stick to it, you will have higher chances of finishing within the time constraints - but the chances of getting struck down by an unforeseen technical problem (that will easily set you back an hour or two) are still pretty high - especially if you use unfamiliar technologies in the process. A lot of developers at the event were inspired by earlier sessions that covered physics engines and especially Cocos2d framework, and decided to try using some of those APIs for the first time during the Jam. From the perspective of time, it's about the balance between how much coding a framework like Box2D saves you vs. how long it takes to learn it. Knowledgeable people, Google and code samples are your best friends. All in all, learning something new and cool was definitely a big part of the experience - but please don't ask me to show you the Frankencode that came out of it... I'm afraid to look at it myself. I am fully expecting some of those classes to haunt me in dreams for days to come.

Lessons learned

Below is my personal take on what it takes to successfully make a fun game in 10-12 hours of non-stop work with a semi-hard deadline. But don't take these guidelines too seriously - unless it's a competition for a million dollar prize, of course. Main point is to have fun and learn something new, but it doesn't hurt to be realistic about your goals at the same time.

Short summary: It comes down to very clearly understanding what is the CORE of the project that you will be working on and focusing on it. It starts with finding a suitable idea. Then, you move on to figuring out what constitutes the essence of the gameplay. What is the absolute minimum that's required to make it work?

- If you have an idea for a game that you will want to code, take your time to define the scope of the project beforehand. Carefully assess your skills, make sure you understand what is achievable and what is not. If you need to learn some new framework, make sure to account for it - it WILL take more time than you think, regardless of how much sample code you can dig up. Try to enlist help from somebody who really knows how to use particular technologies that are new to you. Make sure to be courteous - most of the time those people will have their own stuff to worry about and won't have too much extra time to babysit you.

- After you define the scope, cut it in half! In the cases like this, there is a big difference between FINISHING a limited game and STARTING an ambitious project, and most of it comes down to one simple thing: when morning comes, you will feel a lot better if there is something that you can hand to OTHER people to play with, something more than screenshots and explanations. Plus, if you do finish early, it'll be easy to think of some additional features to add.

- If you decide to try a few ideas before settling on the final project, try to stick to rapid prototyping and don't invest too much time into building code infrastructure that you might not even use because that particular game idea turns out to not be fun enough to go with.

- Remember: you are building a prototype! Dirty code is ok. Unless your idea is to build the next generation graphics engine in one night, don't spend too much time trying to make your class structure clean. On the other hand, source code that looks too much like a bowl of spaghetti might slow you down if you do need to spend significant time debugging it or you start forgetting what calls when and why after taking a break. Find your own balance here.

- "Layer" your work: Finish the basics first, and then start adding more advanced features on top. Don't get carried away with trying to perfect one particular area of the project. Each successive iteration should make the whole thing better incrementally - because if you have to bail out early, at least you will have SOMETHING working. Good example: if you have some characters in a game, don't implement graphics/animations for those characters right away - do it with primitives first. This might not fully apply to a game where some intricate graphical/physical model is the centerpiece (i.e., a sophisticated ragdoll game), but I bet you could defer graphics and sound until later stages in a lot of game projects.

- If you can find somebody to produce artwork and sounds for you, do it. Each minute that you spend in Photoshop is a minute that you are not coding. But then again, don't get carried away with the outsourcing process - it can be remarkably easy to get sucked into spending lots of time trying to "guide" your artist and formulating feedback - each minute that you spend writing those emails or IMs is a minute that you are not coding.

- If you are a perfectionist, this can be tough, because the balance is heavily tilted towards "how fast you can do it" and away from "how good it's going to come out". Some people aren't prepared to compromise like that. Try to make an exception (this one time) and focus on getting there as fast as possible. One other potential way out is to severely limit the scope and focus on quality. Instead of having a "game", make a cool "toy".

- What if you don't have any game ideas? There seem to always be a couple of people that are better at generating ideas than implementing them. This might be a good opportunity to team up.

- Keep track of time - it's important to be aware of how you are progressing and adjust scope if necessary.

- Debugging when tired can be a b*tch. But you already knew that...

Bottom line: it's all about having fun while trying to accomplish something under pressure. It's not as dreadful as it sounds, you just need a bit of determination and inspiration. Oh, and don't forget to stock up on chocolates, fruits and caffeinated beverages...

-- Peter Bakhirev

P.S. More info about the event

And here is the source code for the demo app: GKDots

The conference hadn't been "officially" kicked off yet, but you could already feel the awesomeness and the brain power. In one of the 4 early talks scheduled for Sunday, Jay Freeman (saurik), the creator of Cydia, talked at length about code injection in iPhone apps using a framework that he created called MobileSubstrate, available on jailbroken devices. As far as I understand, this framework allows you to intercept Objective-C method calls at runtime in any application and modify app's behavior. The pinnacle of Jay's presentation was him hacking the built-in Maps application to stop the map rotating using iPhone 3GS' compass, and rotate the graphic (a half-transparent white cone) that indicates user's heading instead. It took about 2 hours, which mostly consisted of reverse-engineering Maps.app and trying to figure what to intercept and how to get to the relevant graphics layers - all of this without any access to that app's source code. Jay's tools of choice: IBM laptop, 'vim' editor and an SSH session to a jailbroken iPhone - not for the faint of heart. Even though some of this stuff might not be too relevant to "official" iPhone app development, it's good to get "close to the metal" every once in a while and reinforce the notion that iPhone is nothing more than a computing device and not some mythical being that feeds on Objective-C code. After all, how much can you really learn about your car if you never open the hood?

Party time!

Quick, what's a synonym for 360iDev? "Party" is a good answer. More specifically: plenty of beer, food, great group of people and some Rock Band. What else could you wish for?

It was a great start to a great conference - and it should only get better as the week progresses.

-- Peter Bakhirev