26Nov/091

Another day, another OS by Mr Jack

Today, yet another piece of hardware turned up in the form of an Acer Revo, which we picked up for just £145. It's not a throbbing powerhouse by any means: running just a 1.6GHz Atom, with 1Gb of RAM and a 160Gb HDD; but that's plenty to do what we want - specifically run the perforce server. It's also utterly silent and draws less than 20W: perfect for an always-on machine. That price comes with a couple of catches though: no sensible installed OS, and no optical drive - which has meant spending the afternoon learning enough about Ubuntu to install it from a USB, get SSH running and transfer the Perforce database over from the MiniMac.

"Just a 1.6GHz Atom, with 1Gb of RAM and a 160Gb HDD" I say! When I first learnt to program it was on a ZX81, it had a 3.25Hz (not megahertz, not gigahertz, just plain ol' hertz) processor and 1K of RAM. We, though, had the upgrade allowing a huge 16K of RAM! You did have type gently though, or it'd come lose and crash the thing... The first HDD we had, when I was about 14 or 15, was a 20Mb beast - we couldn't see how we'd ever fill it. How fast things change!

Filed under: General 1 Comment
25Nov/090

Social gaming for the iPhone? by Mr Jack

Apple provide no system of friends, achievements, on-line leaderboards, etc. equivalent to those of XBLA, PSN, etc. Fortunately third party providers have picked up the ball on this one, unfortunately several different third party providers have picked up different balls and run in different directions. Of these the top three pretenders to the thrown seem to be Plus+, OpenFeint and ScoreLoop. Of the three, OpenFeint seems to have the biggest mindshare and offer the best package for developers.

Anyone had any experience of these? Either as a developer or a user? Thoughts?

23Nov/092

Games are for fun by Mr Jack

Well I've been working away for a couple of weeks now, and it occurs to me I've not actually explained anything about the game we're making yet. It's a simple 2D physics puzzler, in which you attempt to get across the screen by swinging off objects. There will be two game modes, one consisting of a series of independent puzzles of roughly increasing difficulty, and the other a ongoing challenge in which you attempt to travel as far as possible across linked screens containing a variety of objects and challenges. So far I've been working on the latter of those two modes, but 95% of the code is common to both anyway.

The game has very simple controls, you just touch the object you want to swing off, hold to keep swinging and release to let go. This was initially the only controls I added, and it was enough to make the game both fun and challenging. But on it's first public outing I showed it to a friend who made the obvious observation I'd completely missed: why couldn't you swing higher by tilting the iPod? Doh! Why didn't I think of that? A few minutes of coding later and "tilt swing" was born. Rocking the iPod back and forth makes your character swing higher in a way that feels instantly natural and opens up new areas of game play to be explored.

If you look at the videos we've posted so far, you'll doubtless notice the lack of polish and graphics in the game. This is a feature, not a bug. The more design goes into a game, and the more time spent on level designs and art, the more fixed it becomes because changes mean throwing more and more stuff away. At the moment, it's easy to put new game mechanics - like tilt swing - in, and easy to explore new game designs and modes (today I've been experimenting with levels in portrait rather than landscape orientation). This kind of tweaking and exploration is vital to producing games that are really good fun to play. Whilst the ability to envision how a game will play while its only a doodle on a bit of paper is one of the skills that distinguishes the best game designers; there's no substitute for actually trying stuff out.

Many years ago, when I was still at my first games programming job we were working on a racing game (no, I'm not saying which one it was) in which the tracks were all modelled in Maya (for those of you that don't know, Maya is a 3D art package popular in the games industry). Whole worlds were built around these tracks that had never been anything more than sketchs, polygons were placed, tweaked and textured; whilst over on the other side of the room one of my fellow programmers was busy putting together the car physics, complete with a modelled clutch and drive train. Then, many months later, the tracks were nearing ready and the cars could, for the first time, be dropped onto track.

They couldn't get up the hills with their 70 degree inclines.

But by this point, the tracks had literally hundreds of man-hours invested in them and making changes would have meant weeks of artist time; time we didn't have. So, instead, the car physics got bent and botched until they could get up the hills and, eventually, after a fashion you could race round the tracks. But because they hadn't been - and couldn't be - tweaked and tuned to the way the AI and the physics worked the tracks were too wide, it was too easy to pass and the corners weren't much fun.

That's not a mistake we plan on making, so much of this week will be spent tweaking, trying and exploring designs while the game's still fresh and maleable and before the art has been locked down. By the end of the week we should have the game - sans graphics and polish - playing much how it will when it's finished.

19Nov/090

Using the real kit by Mr Jack

Yes, that's it running on a real iPod Touch. You can see a couple of other bits of progress too, although they won't look like much until I get some real art done. The background is using a test texture loaded from PNG using an .xml described texture page, and you can see the transition between two distinct screens going on - again these screens are described in .xml. That's the basic building blocks of a game, and now it's running on the real kit I can start tweaking it to feel right with the finger control and figure out some sensible level designs.

18Nov/092

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.

13Nov/090

Can you tell what it is yet? by Mr Jack

Okay, so it's not really a game yet, but no matter how many games you've written or worked on there's always a little touch of excitement when you first make something that actually behaves like it might someday be a game. The video you can see here is of it running in the simulator, and so it's mouse controlled but it should transfer straight over to touch control when we can start using the real hardware.

13Nov/095

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.

Tagged as: , 5 Comments
11Nov/090

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.

Tagged as: No Comments
9Nov/090

Setting up by Mr Jack

One of the reasons for choosing iPhone as the starting platform for Mr Jack Games is the ease, and low cost, of entry. Apple provides a full suite of iPhone development tools completely free of charge, signing up to the developer's programme (which allows you to run your work on a real iPhone/iPod Touch, and put content up on the App Store) costs just $99. That's real value for money. Even the hardware isn't expensive. I plumped for a MiniMac (£499) and a basic 8Gb iPod Touch (£149) as all I needed to start with, the friendly folks as KRCS in Coventry threw in a mini display port to VGA adapter - allowing me to run with glorious two monitor goodnesss - for free.

Everything unpacked

Because I'd already got a keyboard, mouse, and a couple of monitors for use with my PC, the MiniMac was the obvious choice for me and a USB hub and a cheap USB extension cable even allows me to swap back and forth between PC and mac just by swapping a single USB connection. Handy. Getting used to working on a Mac takes a little while and tiny interface differences can niggle (why can't I maximize a window in the same way?) but the fact is that both PC and Mac have pretty solid, well designed interfaces these days. The only really troublesome problem I had was that the MiniMac doesn't handle normal British PC keyboards correctly, swapping " and @ round (among other problems) - fortunately this is easily corrected.

My cats decided to help out

How did people manage before Google anyway? I'm sure I should remember. I started programming many years before the internet, yet alone Google, came along but now I find myself baffled as to how we ever got anything done. My whole journey into MiniMacs and iPhones has been informed and guided with the help of internet searching - I'd have been left with my " and @ keys reversed, swearing at Apple everytime I hit the wrong one but for 10 minutes on Google.

Once everything was plugged in and doing a good impression of working it was time to download and install the development kit, which weighs in at a hefty 2.5Gb but includes everything you need to get started. XCode is Apple's IDE, sitting over a GCC based compiler, and... it's pretty good actually. Easy to get into, powerful, comprehensive and configurable. There are a few oddities to get used to if you, like me, have spent most of your career working with Visual Studio but it certainly does the job. Running your app on the iPhone itself has to wait until you're a registered developer but the simulator provides a quick and easy way to get started.

Tagged as: , , No Comments
6Nov/092

Welcome by Mr Jack

Hello, and welcome, to the development blog of Mr Jack Games. I'm the eponymous Mr Jack - more formally known as Jack Aidley - and this is where you can read along with the trials, tribulations and idle amusements of a new games development venture. After many years of working in Games I've decided to chance my arm at developing my own ideas, and the iPhone provides the perfect platform for that. I believe there's a real place in the market for well made, simple, accessible games and with any luck Mr Jack Games will soon be producing just such games.

You can follow this blog using the RSS feed, or just pop back from time to time for updates.

Tagged as: 2 Comments