Dec 24

I’m currently messing around with bluetooth multiplayer and it’s been a blast so far. The only downside is the much longer turn-around cycles for developing the network code to test on two devices. On the PC it was a bit cumbersome as well, but I could always just run 2 instances side by side locally. I guess if I had spent a little extra time to allow for Wi-fi AND bluetooth I could test with one device and 1 simulator, but it’s still always going to be slower than single device testing.

I had made a post about this a little while ago with running from a single project in XCode. Brian Stormont mentioned I could have multiple copies of the project all referencing the same source files. I finally gave that a try and it does make things a bit easier and allows for simultaneous debugging, but speed of deployment only seems a tad faster, if at all. When compiling from both projects it appears the 2nd project to be compiled is significantly slower and/or waits until the first one is finished. I guess that’s the problem with running a single instance of XCode with multiple projects.

Also if you try to compile at the same time while targeting 2 different devices but with the same configuration you’ll run into a lot of build errors. Creating a new configuration (akin to Debug-2 or something similar) allows the copied project to output it’s files separately without having any contention of the original project for file handles and such.

Thanks to all for their support on this blog and support for Tilt to Live! It’s been an awesome year and lots of exciting stuff coming up as we roll into 2011. You probably won’t see another post here until early January, so have a happy holiday!

(image courtesy of rooter)
Dec 15

About to head out for a week into the rockies for some fun snowboarding :D . So I won’t be able to keep up with e-mail, twitter, or the blog for the next week and I’m currently in a rush to pack. I didn’t want to just leave for a week without explanation though.

In any case, I still use iSimulate for testing Tilt to Live on the simulator. Having already written about the great benefits of using something like iSimulate I won’t go into the details again. Recently, I was trying to create a trailer for our upcoming ‘Viva La Turret’ DLC for Tilt to Live. I was using ScreenFlow along with iSimulate to capture video and iSimulate was performing extremely poorly. Knowing iSimulate uses Wi-fi to transmite the tilt data I turned off all wi-fi devices in my apartment thinking there was some sort of interference. Then I looked at my phone and realized bluetooth was enabled. Turning it off solved the problem. Googling for bluetooth and wifi intereference turns up a lot of similar cases, I just haven’t experienced it in development yet. I figured I’d pass that along.

‘Til next week!

Dec 7

I’ve started holding a particular mindset in regards to game design a little while after I started working on iPhone games, but I could never really articulate what I was feeling without sounding like a lazy game developer or religious nut. Danc’s article over at lostgarden reflects a lot of what I think about games as a medium, and what they can do, and where they are heading (good or bad). I’ve had this strange aversion to creating a gameplay ‘space’ where the amount of time spent playing a game almost directly correlates to the exact number of levels the game has.

Of course, any outsider looking in would probably see the flawed logic in that when you have the poster children of mobile games being heavily content driven. Danc argues that content heavy games aren’t the way to go and are inefficient game design. But just looking at the iPhone market, what he’s saying seems at odds with what is garnering consumer attention.  But then again, games like Angry Birds and Cut the Rope may simply be outliers. A glance at the top of the charts reveals Fruit Ninja, Bejeweled 2 (most likely due to Bejeweled 3′s release), and the ever present Doodle Jump. All of these games very light on ‘content’ and steeped deep in core mechanics. So maybe hope isn’t lost :) .

The reason I was feeling a bit of concern is there seems to be an influx of games trying to replicate the Angry Birds formula. Tons of levels, quick to go through, and a simple mechanic to play with. This may be playing a dangerous game, especially if you’re an indie. An indie’s time is extremely limited, and getting on that ‘endless treadmill’ to churn out levels is definitely not something you want to find yourself in if you wish to move on from a game and pursue something new.

There is something to be said for content-driven games created by indies though. They can work, but the path is extremely long and grueling. And in the end, you’re creating an experience that borders more on a book, or movie, rather than a game. I loved Braid and Limbo to death as they were amazing experiences and I’m glad they exist. But in all honesty, it’ll be a very long time before I ever revisit either. Their memory is more like a movie in my mind, not a game. I recall scenes, imagery, atmosphere, and mood. Oddly, I barely recall the puzzles in either and the platforming mechanics are forgettable. The very things that differentiate them as games versus other mediums are the things I recall the least about them.

Despite thinking ‘static levels’ are bad, the market can and will reward a game that has a decently fun mechanic and just pumps out content for it, very much like a season on a TV show. So as an indie, the market won’t punish you for it. Although you may soon find you’re punishing yourself :) . Another way to look at it is a meter of progress. Some players prefers games with discrete levels because it gives them a sense of progress and direction. High score games have little direction in their minds because the ‘end goal’ is to get #1 on the leaderboards, which in most cases is impossible so the game loses value and becomes more of a toy. It’s purely a mindset and expectation those players enter the game with and something a less ‘content’ driven game has to deal with.

Disposable Games

One of the lines in the article that hit home the hardest for me was:

“As a designer, I feel like I’m wasting my life when I create a disposable game.”

What’s interesting is that above thought is far less pronounced in my mind when I think about developing for say…The DS, Xbox 360, PC, Mac, etc. In the App Store there are literally thousands of games that can probably qualify as ‘disposable games’. I’ve played plenty of them, my friends have played plenty. And it’s not that they are bad games by any means, as we tend to get enjoyment out of them. It’s just that the amount of time we enjoy them is for but a fleeting second and then we move on. Gone are the months of hard work that designer/developer has put into that experience. Is it worth it? Why does this feel more relevant in the App Store? Is it because it’s harder to swallow that a $60 dollar game is disposable? Do those other platforms promote ‘deeper’ gameplay in general vs the more diverse App Store?

It’s not lost on me the context in which these games are played. Most are played a couple of minutes at a time, often times while the player is outside their home. So any long term investment needs to come from several play sessions over a very long time period as opposed to a more traditional game where investment usually comes in blocks of hours. Just because you’ll only have a few spare moments to entertain the player when they open the game doesn’t mean they also have to be the last. Words with Friends is an amazing example of this very concept, but I don’t think asynchronous play is the only answer to this, and beyond turn-based games isn’t a very good one.

Games like Angry Birds and Cut the Rope thrive on that concept by creating “tons” of static content that is consumable in very small time periods. Guess what? Once the player is done with all the levels, there’s little incentive to come back beyond the pure ‘fun’ of the mechanics. The question is, would players play the same puzzle again knowing the solution just for the sake of playing it? They seem to be in the content business now, which I guess isn’t a bad thing when business is good.

Some of the warmest comments I’ve received about Tilt to Live have been from players that begin their e-mails saying they’ve been playing this game since release. That’s 10 months and counting. If people are still playing it today, maybe we’ve created a game that isn’t disposable? I think Danc said it best about creating a deep game versus a content heavy game:

At a certain level of depth, a game transcends being a disposable blip and turns into a life-long hobby

That’s definitely a goal to keep in mind when I’m trying to create a meaningful game.

Dec 1

Wow. I think I’m still digesting thanksgiving dinner. Anyway, we just recently announced our newest game mode for Tilt to Live and it’s a doozy. In the midst of getting it all tested and ready to submit to Apple I had a bug lurking about the loading screen code. At seemingly random times the game would crash with an EXEC_BAD_ACCESS error somewhere in my loading assets functions usually stopping at CGContextDrawImage. The fact that I couldn’t replicate it with any sort of consistency really concerned me.

So what did I do? I put it off. hah! Through some beta testing our users submitted a few crash reports and after the pain of getting them to symbolicate (I can never get it to work on the first try) I wasn’t left with much to go off of. Then I noticed a peculiar thing in each of the different crash reports:

  • Thread 7 crashed
  • Thread 8 crashed
  • Thread 9 crashed

Wait what? Why am I crashing in different threads each…oh my. Apparently I haven’t learned my lesson. I wrote that post over a year ago mind you. I eventually went from libpng back to using CGImage loading for performance reasons. Most of my graphics were in texture atlases, but the new ones in turret’s syndrome were not. As a result they were lazy loaded in a background thread when I was pooling objects. The result? 95% of the time it worked without a hitch. Every now and then I would crash while loading some random asset from that method. *Face palm*.

Since I wrote that post I never really looked into any more info as to whether CoreGraphics or the methods usually used in UIImage were thread safe. In any case, it appears it’s not. For anyone that does want some sort of flexibility in loading assets in the background I’ve uploaded the small PNG loader code I wrote and used for a while in Tilt to Live. It’s a bit slower than using CoreGraphics libraries, but is thread safe. The main function of interest is LoadImagePNG(const char *path). It returns a struct called PNGImage that has all the data you should need to use the image. The function loads the image data into OpenGL so the struct contains the textureID if you need it. Pretty basic, and in order to get the same behavior on the iPhone I wrote a small transform that the loader uses to pre-multiply the alpha of the png’s.

The zip contains all the files needed to compile the loader. Just drop the files in a project and you should be good to go. If you’re wanting a more ‘official’ version, just download the latest libpng library to get the latest png.h and pngconf.h files. Enjoy!

Download: opengl-pngloader.zip