Matts Ramblings

Here’s an old blog post from an old blog site, with some musings on XCode. A few people I know are starting to play with some iPhone dev, so hopefully they’ll find it useful!

After using visual studio for over a decade, moving to XCode has been somewhat, interesting. At first, I found XCode incredibly frustrating, but after reading the docs, and spending some more time with the editor, I’ve come to a point where I feel comfortable using it.

so, to aid other VIsual Studio converts, Im going to list some of the things functionality that I found useful, and that have helped me become a bit more comfortable with the editor.

Condensed View and Editor Grouping

Personally, I find the default XCode layout only adds to the lack of familiarity for VS users. So the first change Id recommend is switching the XCode layout to Condensed. This “un-docks”  the project window from the editor window, and also splits the tree view into three tabs, which makes things feel a little more like the solution tree view in VS.

The trick to using condensed view, is to tick the “Open counterparts in the same editor” in the General page of the XCode preferences. And to enable “Grouping” in the editor window. Enabling Grouping in the editor window, stops XCode spawning a new window for each file you open, something that is often a source of initial confusion.

Vertical editor splits

One of the most useful features of the editor is the ability to split the editor window along the vertical axis.  To create a vertical split alt/option click the “split editor” button.  Unlike VS, the drop down list of open files is global to the editor, as opposed to being local to the split in VS.

Opening the associated header/cpp file

In VS, a common trick is to use alt-h to flick between the header and the cpp. Its possible to bind a similar hot key. it can be found at. Menu Key Bindings -> View -> Switch to Header/Source File.

Open Quickly

One of the features I love the most about Visual Assist, is the file open dialog which searches through your files as you type. XCode has this functionallity hidden under the rather innocuously named “Open Quickly”.  Bind it to a hot key, use it, love it. I wish this feature had a more prominent name instead of being hidden in the docs.

Where do my build rules come from?

This is one that I scratched my head over until it was cleared up by Mike Cohen (cheers!). Its possible to define build rules at multiple points within the project.

The basic rule of thumb is that target rules override project rules. And overridden entries in the target rules will be highlighted in bold.

Don’t use the Project menu to change the project options.

its just confusing, I dont really understand why these appear to override the options for the selected target. One day i shall find out!

Well, thats my list of things, not a lot of changes to make me much happier with the editor!. The only thing that still bugs me on a regular basis is that the expression window doesnt open with (or is part of) the debugger. Hmm..

A person far wiser than I suggested that It’s worthwhile updating one’s resume every six months, or at the end of every project. Yet for some unexplained reason It’s something that I rarely do unless I absolutely have to, mostly because I hate doing it.

Im not even sure why I hate doing it? Why do I detest merely documenting my achievements?

Since I don’t have a suitable reason for my abject hatred of 4 page documents containing a plethora of adjectives and bullet points, I’ve decided to update my CV, and my linked in profile to contain what I’ve been up to at Krome (and not posting here) for the last 8 months.

So, drum roll please!
I have been working on a Microsoft XBLA title called “Game Room” which will let you play a whole stack of retro arcade, and console titles. At launch we’ll have 30 games, but we’ll be releasing more and more over time!.

You also get your own “Arcade” in which to place the cabinets you’ve bought. Our art team has put a lot of time and effort into replicating the cabinets as they were when the games were originally released!

Come the 24th of March, you will hopefully be able to find “Game Room” on an Xbox360 or PC with Games For Windows Live near you!

You can find my linked in profile here and a PDF version of my resume is now available upon request!

So, I’ve been meaning to RTFM on agile for a while, and today I ordered a few books from amazon:

• “Agile and Iterative Development: A Manager’s Guide” and
• “Succeeding with Agile: Software Development Using Scrum”

Hopefully they will arrive soon. If Anyone has any other book suggestions, please let me know!

In the meantime, I’m making notes of the things that I’m not expecting Agile as a process to solve. Some of these things are quite important, if not critical. To start with, theres still two obvious questions which so far I’ve not worked out how to answer:

• When will you be finished, and
• How much will it cost

Im not really expecting a process methodology to answer those questions, at this point I’m leaning towards a probabilistic method of answering both questions. Which could be useful down the track for showing how changes impact both the overall cost of the project and the overall end date.

Actually, let me extrapolate on my thoughts on that. Lets, at the start of any project, assume that any long term estimates are completely incorrect, and that over the duration of the project estimates become more accurate the more well defined the project, and the tasks that have been estimated, become. They will however, never  be completely accurate.

Adding new functionality in the middle of a project, whilst completely allowable in an agile process methodology, is likely to introduce error back into our estimates as downstream dependent tasks are now less well defined.

Perhaps there is a way to track the probabilistic error increase?  Perhaps we can graph the uncertainty, and track it against overall progress, bugs, errors, and most importantly cost. The answer to the question of “when will you be done” becomes another question “when will you stop changing things?”. Only this time, we might have a graph to back ourselves up.

Ive got no maths, stats or otherwise to back this up, its just a hunch for now, but its an interesting thought nonetheless

A simple tome, but one who’s importance should not be overlooked. The most important phrase in software development is, simply:

what problem are you trying to solve?

At the start of any project, it quite often feels like anything is possible, the sky’s the limit. The deadline is so far away that its often difficult to gauge just what is both necessary, and needed. This point in the project is dangerous, very dangerous. The temptation is there to go and build the most amazing TTF renderer known to man, or the most amazing wood grain texture generator ever seen, or the most efficient open world streaming engine, or whatever takes your particular technical fancy.

It gets scarier when the designers join in on this, and begin to extrapolate upon pieces of technology which not only dont exist yet, but wont for a very long period of time. “we can have like, a gigantic planet that turns into a forest of trees and waits for you to get close before turning into a giant crab with a weak point that you can hit for massive damage!, we can stream that right?”

At some point, someone needs to sit down and actually decide what the heck it is that we’re going to make, and most importantly why.

Ive been playing a lot of borderlands lately, its a rather fantastic open world RPG game. Except that, its not really open world. Im sure somewhere, on a design document at the start of the project were the words “Open World”. Im sure a lot of debate was had about whether they should go and build a fallout3-a-like open world engine. Except they didn’t they’ve gone with the Unreal engine, and provided a set of levels which whilst being self contained, still provide the illusion to the player that it is a consistent, open world.

The end result is something which is greater than the sum of its parts, it feels like an open world, it plays like an open world, but it blatantly isn’t. As a player, I really don’t care that i cant see one side the entire world map from the other, there is always something to do, I’m of never far from something interesting, and the experience is far more tightly controlled and managed than some other, proper, open world games.

Im certainly not advocating one approach over another (fallout3 was equally brilliant, if completely different in feel), but rather that when given a clean slate to do whatever you so desire, sometimes its best to ask yourself why you want feature X before you start. Can you provide the same experience to the user without the overall cost to the development team. Especially when that cost can be used to add other features, and/or further polish the end result. Gearbox have shown this beautfiully with their open-world-kinda in borderlands.

A rather fantastic game it is too!

Its been a while since ive played  a game which has been put together with so much love that it totally steals my heart. Machinarium (http://machinarium.net/) is that game.

Its devilishly hard, and downright frustrating at times, but it just oozes something special. The world needs more games like this. please!

oh, and welcome to my blog.