Aug 27

So I’m currently playing around with some multiplayer prototypes on the iphone, and when it came down to testing stuff I ran into a problem: You can’t deploy to multiple devices at the same time. Yea it’s not exactly a ‘problem’ per say, but it’s certainly tedious doing a ‘build and run’ on the devices you want to test. So much so that I dropped 3 player support in a prototype just to save time.

I did run across this blog post by Jonathon George on the topic. You can plug in all your devices at once and just switch the ‘active executable’ in the drop down to deploy to each device. Not ideal, but works for the time being. I figured there may be a way to run multiple instances of XCode projects but I expect that gets into all sorts of messy configuration issues so I haven’t spent the time trying to do it. Wonder if anyone out there developing multiplayer games has gotten a elegant solution to this?

Aug 17

After responding to Noel’s post on the size of games I soon learned it was a wide effort by developers to post their thoughts on this topic so I figured I’d throw my hat into the ring. I’ve had this topic in my head for a very long time and it’s been frustrating hearing friends’ and reviewers’ opinions on games. Other developers have covered this pretty well already so not sure what else I can contribute beyond just a rant :P .

I’m curious where this metric came from in the first place. I would imagine it had good intentions when it was first uttered, but somehow got mutilated, deformed, and abused as it seeped into the vernacular of reviewers and gamers spreading through genres where this metric becomes utterly useless. A common argument I hear is “$X dollars is a lot to spend on a short game”. I tried applying this metric to my own gaming experiences to see if I could glean any sense of rationality from it.

  • Tribes, Tribes 2, Tribes: Vengeance – All combined I spent about 80-100 dollars total for all 3 games. How long did I play those games? Years. Something on the course of 5-6 years. In an economical sense, these games were practically free based on the “Length of time” I spent with them. Those were my younger days when I probably should have been spending more time outside, but hey, I wouldn’t trade those memories for anything now.
  • Starcraft/Starcraft 2 – Another one I spent years playing. When SC2 was announced along with the collectors edition I didn’t have to think twice about paying $100 dollars. The game hasn’t even been out for very long and in terms of time spent, I’ve probably reduced the hourly “rate” to pennies on SC2 alone.
  • Battlefield 2, Battlefield 2142 – Played these religiously over the course of a year combined.
  • Call of Duty 1,2, 4, MW2 – 4 $60 dollar games. Again, played them enough to where it was practically “free”.

If you haven’t noticed, all the games that I spent extraordinary amounts of time playing are almost exclusively multiplayer. I’m a sucker for multiplayer games. When it comes to getting these games, price isn’t a factor in deciding whether I’ll play them or not. The fact that they are social/multiplayer games the biggest influence is: who out of my friends and online buddies are going to be playing it? Length never even came into the conversation. The quality of the shared experiences was what kept me playing long past the “expiration date”.

Ok, ok, so ‘length’ in a multiplayer game is almost a moot point. But it’s also a crutch many games hang themselves on. In order to pad out the “length” of a game, many games add a multiplayer aspect. Some are very welcomed and exhibit great design, while others seem like an after-thought for a back-of-the-box bullet point. So you could possibly make the argument that not only is length some sort of metric used by the audience, but some studios/developers are feeling the pressure as well.

How about single player games? Let us look at the evidence:

Call of Duty 4: Modern Warfare Campaign

I played through this in one sitting. I remember my first playthrough my jaw was on the floor during some of the set pieces. They set out to create a balls-to-the-walls action game and they did it. Reviewers played it and what did they say? They couldn’t shut up about the “length”. And despite there being no “standard” for length they kept saying an ‘average’ shooter’s single player tends to be longer. Time and time again the ‘negative’ on CoD4 was that the campaign was short. The news of a ‘short’ campaign for such a large title made headlines on many big sites.

At the end of the campaign I did have a thought about length: I was sad this awesome experience was coming to an end. But the compactness of it I think was its biggest strength! CoD4′s design philoposhy was to create a ‘hyper-realistic’ experience that gets you as close (if not closer) to  a big budget action movie as it could. If it was longer, the player becomes fatigued from the relentless action. A longer campaign would make them walk away not remembering the “whole” experience, just bits and pieces of it out of context. The game’s length was also another plus regarding the target audience. This was a mature game, namely for an adult age group. Most adults don’t have 40+ hours to dive into a solo game. So I applaud them for that. Why make something that the vast majority of your demographic won’t even see? The single player as an ‘experience’ was worth the price of admission alone. Not on length, but quality. But it seems some use those two words interchangeably.

Limbo

This little gem of a game from an awesome indie studio was amazing from start to finish. I’m not going to go on about it again as 2D Boy and others covered it pretty thoroughly. It took me 4-5 hours to beat. For those still trying to “rationalize” length, stop it. This game is an experience, not a damn feature film (which by the way, no one criticizes unless the film is too long it seems).

Mirror’s Edge

This game is where my frustration hit a boiling point. What’s amusing is the media didn’t really know how to approach a game that was genuinely pushing boundaries in game mechanics and at times it seemed they just defaulted to “it’s short”. Same goes for Portal. What does it say about the medium if people’s only complaint is “it’s too short”? I actually had a bit of an argument with a colleague who was stoked to buy the game, but once he read the positive reviews he decided against it because they said the campaign was short. OMGKDJFLA:JDWIO:JI#@R)@RJFDSFDL. Sorry. Got all angry again.

This time it seemed more perpetuated by the audience than the media. To the media’s credit, they focused on the game’s novelty and fresh gameplay mechanics, but still in passing mentioned how short it was. Just looking at this comment thread of all the ones who gave up the chance to try a truly unique game because it was “short” was quite saddening. I spent at least 20 hours playing that game. Not 3-4 as the single player was measured as. Why? Because it wasn’t even ABOUT the single player. This game was raw mechanics, freedom of movement, and anyone that took the time to dabble in the Time trials and the DLC knew it. They made the awesome concept of Quake Trick jumping accessible to a wider audience. Sadly due to the conventions of modern video games, anything not labeled ‘story’, ‘campaign’, or ‘single player’ is considered a side-offering and should not be put up for consideration in the ‘total length’ metric. It’s as if these same people didn’t play Geometry Wars. That game is a single damn screen, and it barely had any complaints about “length”.

At the End of the Day…

I sometimes feel games that get judged on length are treated by a different standard. Take a game that involves a system or a pure mechanic, like The Sims. No story. No levels. Just pure play. Something you enter and leave as you please. Another example: Geometry Wars. The whole experience is contained within a few short minutes. It makes no big claims of story or progression. Did length ever come up in the conversation? No, because length is ‘seemingly infinite’ and as a result not part of the discussion. Give a game a finite story, or a finite set of levels and regardless of the mechanics and the depth of the gameplay it seems “length” is suddenly a talking point again. Weird huh? If length is the only thing one can discuss about the merits of a game, then is the game not deep enough or are we not engaging it enough?

If you got this far into my rant then length is apparently not an issue for you, so go on ahead and read other developers’ take on it:

Jul 27

Markus Nigrin wrote a great follow-up to my previous post on managing one’s burn rate when going independent. His post touches on some really important information that I completely left out of mine, namely, being educated about investing and not ignoring it. I’m guilty of this as well, but only since “cutting the chord” have I become much more concerned about my lack of education about investing, and it’s something I’m currently working to improve.

It’s a great read, and some good book recommendations from him in that post. I would add to that “The Black Swan: The Impact of the Highly Improbable” as another book to read for those that are in a very “unpredictable” and hit-driven industry such as games, books, etc. It echoed a lot of sentiments I had felt at the time, but didn’t know how to articulate it and the book does a good job of explaining that.

Jul 19

When your profession empowers you to design literally just about anything, it’s easy to rationalize just about any game design decision. Hell, I somehow managed to rationalize that our new power up for Tilt to Live have a screeching hawk sound effect. Bad idea? You’ll have to wait and see.

When Adam and I are working on design details for how a particular system or game mechanic will work, we bring a lot of assumptions to the table of how we think people think. And those assumptions are sometimes rooted pretty deeply so it’s hard to get on the same page. What do we do then? We get into an all out brawl. Ok, not really. We usually turn to our ‘beta testing’ group to do some observation of how they play and react to our design decisions. Our group isn’t very expansive at the moment as most of them are local friends so we can bring them in and have them play our latest builds. Keep in mind I use the term ‘tester’ for anyone that seriously runs the game through it’s paces and those that play it really quickly to see how the game works. Now all this is the easy part. You have a conflict or issue figuring out some detail of a design you go to play testing to try to gather some data. Simply enough. If you aren’t doing at least this, then you’re crazy awesome at game design and you should stop reading. Now. Really.

Doing it honestly.

Like I said before, it’s easy to rationalize any creative decision. It sometimes becomes even easier to rationalize a creative decision in the light of data.  ”See? He did notice that you can only have pick up at a time active!” or “See? He didn’t even notice the limitations of the pick ups because he just runs through them blindly!” You have to try to stay objective as possible. You have to try to get in the shoes of the player and see what they see. Ideally, they are talking to you the entire time as they play giving you verification that your hypothesis is either incorrect or correct. Having worked on a single project a long time, the decisions you make on it almost take on a personal weight. When you find that your idea doesn’t work, you can take it personally if you’re not careful. This can become dangerous not just for your own mental well being, but testers/friends can pick up on it and not tell you what you need to hear.

One tip I found helpful in reading my data and separating myself from my idea is: Don’t think of why your idea will work. Think of why your idea won’t work. It can be seen as a negative way of going about things, but only listing the positive doesn’t help you analyze your decisions. You become blinded by the ‘happy path’ of when your idea is executed inside a narrow scenario, ignoring a sometimes large problem in the shadows. Uncovering the weaknesses in your design is far more telling than a huge list of positives. Save the positives for the “back of the box” :) .

Doing it early.

One of the things that still gets me today is trying to send out builds of our game as early as possible. I always keep saying “just one more day and I’ll have feature X completed or bug Y squashed”. I have to remind myself that our testers aren’t our ‘true’ audience. Yes we want to make them happy and have fun. But better to have your helping hands tell you your game idea is utter crap than to find out it is utter crap 3 weeks after release. This one can be rather painful because you’re fully aware of all the gaping flaws in the code, art, and mechanics and you don’t want to show your work in an incomplete state. Not to mention, it’s hard to explain to your testers why the player sprite is flickering about as if it’s having a seizure whenever they press ‘jump’. Well do it anyway. And get use to it.

We’ve been getting better at this through all the game mode additions we’ve been doing to TTL. With our latest mode, Frostbite, we’ve had play testers in very early in the iteration of the game mechanic phase. They’ve seen the game grow and each step of the way have provided extremely good feedback on helping us balance the game. The actual game mode wasn’t even fully functional when we started playtesting. So what did we get out of it? We focused on the feel of the movement, controls, enemy placement. All minor things that I would spend tedious time tweaking on my own. With each new iteration we tell themwhat was new in that build and have the testers focus on it instead of being overwhelmed by “play this whole game mode and tell me what you think.” One thing to keep in mind is beta testers are there for feedback. Try not to let it turn into a ‘designed-by-committee’ ordeal. Or maybe you want to…but I’m a control freak so that’ll never happen ;) .

Doing it often.

This can be a double edged sword. From my limited experience, testers can sometimes be seen as a limited, nonrenewable resource. You may have a completely different group of testers by the end of the project than when you started. I had this idea of being gung-ho about testing early so I would send out weekly builds to everyone very early in the development process. The problem? Tester fatigue. When the deltas between versions is very minimal, testers may not be interested in a weekly build. As a result, I spaced out the test builds in early development to be a little more rare so that testers had time to recover and were excited to give a new build a try. As release  day got closer, this feedback loop shortened as we approached daily, sometimes hourly test buids.

In the end, no matter how you approach getting feedback for your game, it is almost always is beneficial to your game.

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web siteRSS feed, or Twitter.

May 27

…it’s so calming. I remember registering this domain in similar weather conditions, hence the name :) . I submitted an update to Tilt to Live earlier this week, after crunching for a few days to get it done. So much to say and so little time :[. Heading up to New York City this weekend with family, which’ll be enjoyable. Went there for the first time a couple weekends ago since middle school, and it was so captivating. I enjoyed just walking down the streets in southern Manhattan and taking in the sights. Small experiences like these seem to do wonders for me in terms of creative ideas. I really need to travel more…

In other news, I somehow got suckered into playing Starcraft 2 and now I’m completely owned by it. The strange thing is I can’t stop thinking about it, but yet I can’t bring myself to play it. I can only seem to play it with a buddy as 2v2. Guess I can’t handle the stress of 1v1 right now, as it’s not exactly the best way to unwind after a hard day. Blizzard has created a rather compelling strategy game that has so many nuances I always get excited thinking about them. Not to mention I’ve actually enjoyed watching pro Starcraft 2 match-ups on youtube. They are simply amazing to watch. Someone needs to go make a SC2-TV app for the iPad. Go. Now. DO IT.

Apr 14

Here I was thinking that once Tilt to Live was out the door, that it’d calm down a bit and I’d get a breather to rest for a few days. Wrong. Running off the early buzz of Tilt to Live we took it as an opportunity to generate some extra excitement for our upcoming updates. It was a very weird shift going from a mostly ‘quiet’ development cycle of just spending days coding away to suddenly spending the majority of the next few weeks doing PR, marketing, chatting with players, etc. It’s been one hell of a balancing act since release despite knowing that releasing a game is only half the battle.

With that being said, my workload has pretty much exploded. And as a result, my updates here have been lagging. Things worth noting as of late (for me at least):

  • Tilt to Live was selected as one of Touch Arcade’s Games of the Month. We were honored to receive the ever elusive 5-star rating from them as well. Thanks TA!
  • Tilt to Live popped up on Joystiq earlier this week as well as on their podcast a few weeks ago. Awesome!

I’m afraid to say posts on here are going to be rather infrequent for the next couple of months. I’m anticipating that around July I’ll have all my stuff sorted out and finally be able to get back on a more regular schedule. I’m hoping to do some more tips and tutorials in the future as well. But until that time, just hang tight. :D

Feb 15

So I’m using OpenAL to do the audio in Tilt to Live. Over the course of development audio became the bottleneck of my game, both in size and in performance. The following could help you if you’re experience audio performance issues and are somewhat new to OpenAL. Let me preface this with: Don’t blindly optimize. Measure, Measure, MEASURE! Know what your bottleneck is before trying to tune code!

  1. Don’t make more than 32 sources objects in OpenAL. Of course, this number may vary from device to device and what generation the device is. Making any more than the limit the device support makes openAL fail silently, and at this point you’re wasting cycles.
  2. Load your audio buffers and create your source objects ahead of time and re-use them. This is a big one. Don’t generate and delete source objects in the middle of your game update. Instead, it’s much faster to just grab a ‘free’ source that is not playing a sound any longer and attach it to another buffer. I was pre-loading my audio-buffers, but creating/deleting sources on the fly in Tilt to Live. Then I started ‘pooling” and I got a decent gain out of re-using source objects.
  3. Keep OpenAL calls to a minimum. Especially in tight update loops, don’t repeatedly call openAL functions that don’t change frame-to-frame. I found that a good portion of my time was spent doing something as simple as ‘alSourcei()’ on each source ID per frame was causing a significant slow down.
  4. Don’t query openAL state if you don’t have to. In my case, I wrapped openAL Sources in objects with properties to get volume,pitch, etc. Initially those properties simply called the openAL equivalent and returning it instantly. This was hurting my frames due to some some innocent looking “backgroundMusic.volume += someVal” happening each frame along with other audio sources doing the same thing. Save any state you can in instance variables, and as a last resort hit openAL when you need to.
  5. As for size, you should consider compressing your sound FX and music to a reasonable size. If you’re like me, you hate giving up quality; especially if you listen to the full quality one and then the compressed one. It can seem like night and day. But in reality, when your users won’t have a full quality audio file to compare it to, they will not notice the difference.

As a sidenote, you can look at my first dev tip for batch compressing audio files.

Feb 14

We're extremely close to submitting our first title "Tilt to Live". We plan on submitting it this upcoming Friday. After a long and grueling (but awesome fun!) development cycle we've learned a ton. I figured an interesting way to distill our new found knowledge it would be in very short "dev tips" for developing an iPhone game. Today I start out with audio:

Compressing Audio

By the end of development our game weighed in at 16 MB. We wanted to go below the 10MB limit so users could download our game over-the-air. Quickest solution? Compress the audio. Now, we were already using some compression but we have over 60 audio files! The main crux of the problem is we want to be able to quickly compress all our audio to a certain format, build it, look at final build size, and test for quality. For this I wrote a quick script:

#!/bin/bash
rm -rf caff
mkdir caff
for i in *.wav
do
afconvert -f caff -d ima4@22000 -c 1 $i caff/${i%%.*}.caf
done

Now for a little explanation on my setup:

  • I have a single folder (let's call it 'finalAudio') with all the original, uncompressed wave files used in our game.
  • The script sits inside this 'finalAudio' folder as well and I run 'chmod +x build_audio' where 'build_audio' is the name of my script so I can just click on it in Finder when I'm wanting to re-export my audio.

What the script does:

  1. It removes any folder/file named 'caff' in the current directory
  2. it makes a new directory inside 'finalAudio' called 'caff'. This is where the compressed audio will go
  3. It looks through all wav files inside 'finalAudio' and runs the 'afconvert' utility on each file and puts the resulting compressed file in 'caff'.

I'm not going to go into the details of all the options you have with afconvert and what audio formats the iPhone supports. There's plenty of documentation online covering that already.

Just an interesting sidenote: we took our 13-16MB game and shrunk it to 6.5 MB using ima4@22000 with 1 channel.

Jan 28

I've received a few e-mails now regarding this tutorial that was hosted on Ziggyware's site. So here's a quick post to help others save some time and give an update on it's status:

Ziggyware.com seems to be down indefinitely. As a temporary solution until I get back around to hosting this tutorial myself you can find the Google cached version of it here. If you wish to look at the sample code and illustrations in full you can download the XNA sample from my site here. Note, that the XNA sample was built on a very old version of XNA so my guess is it will not compile out of the box, but the general logic for the ribbon trails should be the same regardless of XNA version.

Ribbon Trails XNA

Enjoy!

Jan 16

I had seen a few things written about "Everyday the same dream", a game created by but never took the time to try it out myself until recently. It's a compelling art game where you try to subvert you're daily routine. It took me a few minutes to figure out what to do after a few days of the mundane routine, but  that added to the whole experience of the game itself. It's a very subtle, but clever design that speaks to a wider audience.

Be sure to give it a try. It only takes 5-10 minutes to play through.

« Previous Entries