How to allow user background music with OpenAL by Mr Jack
Version 1.0 of Alien Swing has no music included, but also won't let you listen to your own music while you play. Since the iPod Touch and iPhone developed out of Apple's successful MP3 playing empire this seems rather suboptimal, so one of the things I've added in the 1.1 update is the ability to listen to your own music. This is actually a very straight forward thing to do, but I spent quite some time time tracking down how to do it, so here, reproduced for anyone else who wants to do it is how it's done: During your setup process, and before you call the OpenAL initialisation code, you need to add the following lines of code:
// Allow their music to play in the background AudioSessionInitialize(NULL, NULL, NULL,NULL); UInt32 sessionCategory = kAudioSessionCategory_MediaPlayback; AudioSessionSetProperty( kAudioSessionProperty_AudioCategory, sizeof( sessionCategory ), &sessionCategory ); UInt32 allowMixing = true; AudioSessionSetProperty( kAudioSessionProperty_OverrideCategoryMixWithOthers, sizeof( allowMixing ), &allowMixing );
These functions are included in AudioToolbox/AudioToolbox.h so make sure you're using the AudioToolbox framework and including that header in the appropriate file. The update to version 1.1 of Alien Swing was submitted to Apple on Monday but it's still in the 'waiting for review' state - I'm guessing this is because they're concentrating on getting all the iPad apps reviewed ready for release so it may be a while longer.
To XML or not to XML? by Mr Jack
Data-driven development - it's not just a fancy looking buzzword.
I remember back in the 8-bit days lovingly hand crafting user defined graphics and entering them into the interpreter (hey, it was BASIC for me back then) as cryptic strings such as 24, 60, 90, 90, 126, 84, 84, 0, nowadays of course no-one would dream of doing graphics that way. Levels too are generally passed off to data files, and knocked up in tools for the job, and since I started my professional career more and more of the arbitrary data that runs a game has been moved from the code out into data files.
But in many, maybe even most, games you can still find the distant descendent of those user defined graphics, little tables describing the behaviour of objects or systems, or a series of functions calls building up a table. And it's easy to see why; it's quick, it's easy and you don't have to faff about reading data files. The downside is that it's cryptic and hard to tweak. Fortunately, there's now a quick easy way to roll your own data driven code - XML. While the full standard has plenty of complications, the basic principles of XML are easy to understand, and easy to use. What to describe a texture page? You can just write something like this:
<page>
<file>background.png</file>
<texture>
<name>background</name>
<left>0</left>
<top>0</top>
<width>480</width>
<height>320</height>
</texture>
</page>
Which is both easy to process in code, and understandable to a human reader. Nice. Even more helpfully there are several widely available, easy to use C++ XML parsing tools already out there. At Strawdog Studios we used TinyXML and it had proved well capable of meeting our xml parsing needs. However, we also ran into loading time problems which led to Simon developing a pre-compiled xml solution. My first thought, then, was to look to making my own pre-compiled xml, but googling around I came upon RapidXML. RapidXML is some 30x faster than TinyXML, a feat it achieves by working in-situ: rather than copying data from the memory the .xml file is loaded into, it works with pointers into that data (which it also mangles with null terminators and so forth). This could have problems under some approaches and in some applications but it's perfectly suited for my needs.
With RapidXML doing the XML parsing donkey work, knocking up code to take data from .xml files is barely any more complicated than working from data tables stuck in the code itself, and it leaves the possibility of producing tools to create and modify the .xml files open.
Source control by Mr Jack
Source control is one of those vital development tools that distinguish professional developers from enthusiastic hobbyists. No serious programming project should be without it. The big benefits may only apply with larger teams but even when there's only a few, or even only one of you, working on a project source control still provides an invaluable service in tracking changes and managing different versions of your project.
Among those in the know there are two big names in the world of source control provision: Perforce and Subversion; while the older but still potent CVS still holds a big mindshare. Any of these three are well capable of competently filling your source control needs. XCode - neatly - comes with out of the box integration with all three. Unfortunately that doesn't make choosing which to use any easier. Subversion and CVS have the advantage of being out and out free software, whilst Perforce is a commercial product, however for small scale development Perforce offer a free version for up to two users.
Since I've worked with Perforce in the past, and I know and like it, it's the choice I went for. The Mac version of the server isn't as neat and easy to set up as the windows version, unfortunately, and my lack of Mac experience slowed me down as I thrashed about for an hour before getting it all set up properly.
Onwards and backwards by Mr Jack
Well, after a couple of days work, I've got as far as successfully loading a PNG, and displaying it on screen wherever you touch it (well, click it, since I'm still using the simulator). This may not seem like much but when you're exploring a new development environment, learning a new SDK and getting your head around a new programming language it can take a while to get anywhere at all. What I've got is enough to start writing a game with instead of just a tech demo.
But there's a problem: it's a mess. It hasn't been designed, things have been put in the wrong files and wrongly scattered between the C++ I know well, and the Objective-C I don't. So I'm faced with a choice, do I press on with an already messy codebase - maybe refactoring it as I go - or take what I've learnt from my little test project and try and do it better? Joel Spolsky says rewriting from scratch is the single worst mistake a software company can make, and for a whole working product I'd tend to agree but this isn't a whole working product; it's a couple of days of exploratory work. I choose option b.
But writing games isn't a beauty contest for your C++; once it's out there no one cares whether you carefully crafted your objects or slopped it all into a single C file spattered with gotos and global variables. So why care? I care because working with bad code is unpleasant, and it makes everything else you do take longer. Spending some time now getting things organised correctly means less time later fighting with code I got wrong now; and less time working in new features or finding where I put some function or another.
I think that's worthwhile.




