Finally gotten around to putting VS2010 on this machine, and this time around I’m breaking with tradition and simply not putting MSDN on there, at all. It used to be a no-brainer, put the reference libraries on as you’re going to be looking stuff up all the time. But these days it was always more an exercise in frustration than a useful tool.

Many topics are just “not there”. Huge swathes of really basic stuff are just missing (basic date formatting string specifiers – that’s pretty low level!), so that when you navigate to them it tells you the page is missing. Go online to the MSDN reference there, and you’ll find the page, just not in the locally installed copy. I thought to begin with it was just because I’d installed it badly, but even from a clean install it was still just not there. I’ve since concluded that it must be the Express versions are just subsets of the full documentation, to keep the downloads small. It’s certainly not a functionality split – like they’re only putting in help topics for things in the Express editions – because the Express editions are really quite close to fully functional. No, this is stuff that’s core to .NET and the language.

So, since I’m having to fall back on searching the internet anyway, I figure I might as well have my hard disk space back. The online resources available now are fantastic anyway, and it’s rare that I’m not connected when developing. Most often it’s the online MSDN references that show up first in the search, so in the end it’s much of a muchness – except I don’t have to use the horrible HTML help interface which has been getting steadily worse with every revision of Visual Studio.

I guess this is just another nail in the coffin of the disconnected computer: so many things now expect/assume/require you to be connected to the Internet. Which wouldn’t be so bad, but even with 3G connectivity, a network connection while on the move still isn’t something that can be taken for granted. But I’ll stop grouching about it like an old man, and go with the flow…

New link over in the right hand panel: GameDevBlogs.net Not to be confused with Jamie Fristom/Torpex’s GameDevBlog.com, to which we also link!

Basically it’s a new site to bring together many of the interesting game development blogs that are out there. Good to see a common location where you can go to read and discuss the game-dev news of the day, dip into the day-to-day life of various small developers like us, and generally learn something new. Go, read, enjoy!

It’s very strange, after having had so much to do solidly for so long a time, to be able to pick and choose what to work on again. There was a big stack of paperwork, of course, including our end-of-year accounts for 2009/10. And my desks had degenerated into a big pile of letters, both spam and ham. So clearing that was a requirement, not just a nicety. But aside from clearing those backlogs, the decision as to what to work on next has been quite tricky. In the end I opted to try and catch up on Tim in terms of iPhone knowledge. Tim has done the vast majority of the work on our iPhone apps so far, and despite working on the UI design with him, I’ve not had any time to get my hands dirty with implementation. So with some free time to play with, it was time to get some serious crash-course learning done.

Cue some virtual attendance of CS193P, the iPhone Application developer course from Stanford University. Taught by developers from Apple, and with all of their lectures videoed and put online, it has been a great way to get quickly up to speed with Objective-C and Cocoa Touch development. Of course that’s not the only way to develop for iPhone, you can (and in my opinion, should) implement the large part of any game or simulation app in standard C/C++. But for working with the iPhone operating system, and implementing interfaces (arguably where the real challenge and value in an iPhone app lies), it has to be done in Objective-C.

Stanford U

So while Tim was busy with some other work-for-hire, I took the opportunity to bash through the majority of the CS193P course, and start to tackle an app idea we’ve been talking about for a while: the Drunk Compass. More on that in later blog posts. Actually watching the lectures brought back a load of memories of university: it was nice to remember a time when all I had to do was take in as much knowledge as possible and try to retain it long enough to pass exams with.

Thankfully, as this was just one course, condensed, it didn’t last long enough to evoke the things that annoyed me about university: the feeling that I was always doing throw-away coursework. I’ve always preferred the hands-on approach, and by the time my university career ended, I was already itching to make something real, and loose it on the world. A shame then that my first shipped title with VIS didn’t see the light of day until 5 years later (although technically i-Race shipped much earlier than that).

Anyway, learning is good, and I think it’s been a welcome change of pace after the hectic nature of Crackdown 2 or our other client work. Hopefully now that I’m comfortable with the Cocoa interface tools, I can prototype our most promising app idea, and get it one step closer to reality.

And so it has arrived. Finally, and after much Herculean effort from all involved, we have given life to a healthy baby game. Okay, so it’s more of a hulking 250 pound armoured law enforcer than a baby, but I’m still proud of it like a child. It’s occupied more than 14 months of my time so far, so it’s a great feeling to know that it’s soon to see the light of day.

Crackdown 2

It’s weird, I’ve spent the last month and a half working with the MGS and Ruffian teams to take the game they’d made and turn it into a demo form; I thought I wouldn’t want to play the demo again. I’d play the full game, sure, because I’ve never actually made it all the way through without cheating, and it’s a game where the pleasure is in the journey, not in the destination. But the demo is 30 minutes from the start of the game, and your progress isn’t saved, so I thought I’d just skip it and go to the main game. My wife and family finally got me an XBox 360 for my birthday on Friday, along with a stack of games (Halo 3, Halo: ODST, Forza 3, Bioshock 2, Assassin’s Creed 2), so I wasn’t short of things to play.

But like a digital drug, I found myself using my demo preview code, and playing the demo. I knew what to expect, and that didn’t make it any less fun. Shooting, punching, kicking, driving, exploding, all over the island. Not just once either. Four times through, to get 7 out of the 10 possible demo achievements. I even got my wife to play it through as well. That one I pretended was research for work: you don’t get much more inexperienced at 3rd person games than Vicki, and I wanted to see if we’d pitched the demo opening right. We had – she picked it up surprisingly quickly, didn’t die until much further into the demo than I’d expected. More pride – we’ve made something that can appeal to not only the hard-core, dedicated Crackdown fans, but also to newbies as well. Crackdown for everyone!

Ruffian Games

Not that I can take much credit for that really, it’s the stellar team at Ruffian who have done a fantastic job on the game. I’ve been privileged to work with them, and the wider team at Microsoft. This has been the biggest budget game I’ve worked on to date, with the highest aspirations, and the highest quality bar. It’s been a real eye-opener, and a great experience. Both teams are chock full of talented, enthusiastic folks, and my passion for the title they’ve matched and exceeded at every turn. I’ve got to give a special appreciation to our ex-colleague Peter Mackay as well – who went to Ruffian after leaving us last year. He’s done a great job on the audio for Crackdown 2, allowing the quality audio design to shine through. I was sorry to lose him as a team-mate, but I think he’s found a great new role at Ruffian.

The demo you can get your hands on tomorrow (June 21st), and the full game will hit the shelves from the July 6th. Get to work Agent!

Wow. Five whole years. In games industry terms, that’s practically ancient. And even more strangely for me, I’ve now been running my own business for longer than I spent working as an employee for anyone else. The work we’ve done over the past five years has been so varied that I struggle to remember all of it; there are some projects from when I first started out that I forgot all about it until I was digging through our backup archive recently. Of course, we’ve had our ups and downs – this past year has been especially hard on me in particular, what with all the travelling around, and working away from Edinburgh. But the very fact that we’re here and still beavering away I think says a lot. And I must extend my heartfelt thanks to my associate Tim for doing such a great job here in Edinburgh while I’ve been kept busy with Crackdown 2.

Year Six will, I think, be far more eventful for us than Year Five. It’s too early to say yet what it will consist of, but I think there will be less X360 development, and a load more iPhone work. Of course, my prediction skills are fairly awful, so I should probably not try to guess in advance. What we do know is that we want to get our own projects out there and selling, and the iPhone is a far better opportunity for us to do that than, for example, WiiWare. And there will undoubtedly be work-for-hire as well, which is almost always interesting in itself, getting a chance to help out on other fun projects, and do what we do best – give our clients the software development help they need to ship. And if nothing else, we shall see just how furry the beard can get…

The Crackdown 2 Crunch Beard

Picked up on when reading through some old posts on the sweng_gamedev list, and had to be shared.

So after a weekend up north in Glencoe, trying to get my head back in some kind of productive space, I hear from my sister that she’s given birth to not one, but two miniature people today. So I’ve raised a glass or two to my sister’s new family, which pretty much excludes the possibility that I’ll do anything useful tonight.

Suffice to say that while I’ve continued to work on CruiseControl.NET plugins, I’ve yet to write up anything useful that could be condensed into a blog post. My article on employee Terms and Conditions for IndieVision.net has been shunted to one side, again. I had a productive meeting on Friday with one of the developers of Visual Studio, making an effort to persuade them to include some games development friendly features with their next version (not 2010, the one after); hopefully one or two of them will make it in and I’ll have improved the development eco-system just a little bit.

But in general I’m still struggling with the long commutes to Dundee, and the limited amount of time in the evenings to be productive. So on that rather downbeat note, I shall finish up, and place a tick in the entry on my task list for “Development Blog”. Hopefully future entries will be more avuncular and jolly. Wow, how long have I been waiting to use that adjective to describe myself… 🙂

Aha! Just downloaded the WordPress app for iPhone, we shall see if writing blogs on the move lets me be more reliable with my posts. As I write this particular draft (lamenting the iPhone’s keypad) I’m on a bus on Princes St, moving between Microsoft at the East End and our own office at the West End. This afternoon I’ll be talking through our ideas for iPhone apps with Tim.

That’s right folks, we’re now all set up for iPhone development, MacBook, iPod Touch, iPhone, and a raft of ideas. As I’m swamped at the moment, Tim’s taking the lead on all this, and our first project will be a small productivity app that he came up with. More details and screenshots as we get closer to completion…

This started life as a response to a query about whether or not I knew of any books for learning games design for someone just starting out, but it is a common enough question I thought I’d promote it into a blog post (especially since I’ve been too busy to post recently).

There are certainly good books on games design, GameCareerGuide.com I think has a few articles listing good titles. I couldn’t judge their quality as I’m primarily a programmer rather than a designer. However I’ve always thought that trying to learn games design by reading books (or even going to lectures in a design course) is a flawed way of doing it. You wouldn’t try to learn to play chess by watching videos of someone else playing; maybe once you’ve already got a good grounding in the subject and you know enough to realise how much more there is to learn. But until you’ve got a good handle on the fundamentals, it would just be a deluge of information, with very little context.

My take on it is that, rather than spend a lot of money on books on the subject, that one of the best ways to learn about game design is by evaluating games. That is, playing a wide variety of games, and taking the effort to critically evaluate and compare titles. There are titles held up as great examples in their genres, like Zelda: Ocarina of Time, Halo, Command and Conquer, Call of Duty, Fallout 3, etc. There are also games which try hard but just aren’t as good. As a designer, you’re expected to know why some games are good, and why some are bad.

If you can take a pad and pencil and write down what are the good and bad points of these games, and compare them against other games, then you’re learning the fundamentals of game design. Does the user interface feel good, or is it confusing? Look at the challenges in the game and evaluate them – are they fun? Do they allow players to learn skills, and feel like they are progressing?  Is the difficulty curve sensible? Is there sufficient challenge and variety in that challenge?

You can play a game and look beyond the immediate experience, to see the mechanics behind the game, and judge whether they work or don’t. You can look at several different games in the same genre and pick out what they have in common, and where they are unique. You can spot bad design just by playing a game, and then think of ways that you might avoid those flaws. Anyone can do those things, but a good designer is great at doing them. A good designer does that without even thinking, they celebrate the good in games they’ve played, and vilify the bad. And no-one can be a good designer without experience of games, lots of games, all different sorts of games. If you want to be a games designer, you should be playing as many games as possible.

The only other thing I would say, and it may sound harsh to those who come here hoping for insight because they want to jump straight in as a designer, but it’s better to clear up any misconceptions now. Practically no-one becomes a games designer as their first job in the industry. Really. I don’t think I’ve ever met anyone who was a designer as their first job in the industry, and I know a fair few designers.

The competition to become a designer is fierce, and it is very hard to prove your worth in an interview. Most often, designers start in another facet of the industry – most commonly in the art or programming side, but also sometimes from QA / testing – and while they’re at a studio in that role they can demonstrate their ability as a designer and persuade the management that they would be useful in a design role. And even then there are dozens of people at a studio, all of whom have varying amounts of talent in design, and only room for a few people in actual design roles.

So if you really, really want to get into games, then don’t focus solely on design, you need another role. At most studios, in most roles you will have some design input into the game you’re making, especially if you are keen and get involved in design discussions, even more so if your ideas are good. But if you’re expecting that you’ll do a Computer Games Design course at University X and then swan straight into a straight design role (even a junior one), then you are going to be sorely disappointed.

I must admit, I’m a bit of a CruiseControl.NET fan. It drives most of our automation systems, and provides us a backbone from which we can hang many different systems. I use it both here at the Company, and when I’m doing tools consulting with other teams. That said, it’s not without it’s flaws and limitations; not least of which is the lack of documentation on custom plug-ins.

There are a wide variety of pre-built plug-ins already available, for source control systems like Perforce and Subversion, and build systems like Nant and MSBuild. These usually work pretty well straight out of the box, if you’re building a vanilla continuous integration server. That is, every change made to source control results in a build of some sort. I’m not going to dwell on why that’s a good idea (it is), I’m only going to say that there are times when you need something different. There are inelegant ways around this, but in truth CC.NET has all of the customisability to let you do this properly within the system – by defining your own plug-ins.

Reading the documentation on CC.NET, you get only a single page of documentation on custom plug-ins, and that page is pretty spotty at best. It shows you a “hello world” plug-in, with no clues as to what information you get into the plug-in, when your plug-in’s methods will be called, or how you’re supposed to pass either status information or logging back to CC.NET itself. In short, it’s pretty useless, other than to highlight that the facility is there, and give you enough of a pointer to get you into the code and poking around.

Sure enough, with Auto-complete on, you find that there are lots and lots of information passed to you, and by debugging and breakpointing inside your plug-in, you can get a feel for when your code is called. Making CC.NET load and unload your plug-in is refreshingly easy and fairly robust, and once you figure out how to pass parameters to your plug-in by specifying them in the config file, you can see the possibilities open up. More importantly than the sample building plug-in though is that, through a bit of digging, you find you can also define your own custom source control plug-ins, and with the combination of those two things, you can do pretty much anything you want.

In one particular situation, I’ve been working with a Perforce (p4) source control system, and a rather black-box build system for the game itself. Rather than wanting a build made of every single commit to the p4 repository, I needed it to make only particular builds – those marked as verified by the developer’s internal test team. This is a pretty common situation when you’ve got an automated build system – you have a raw source control system that lies underneath, which operates at the level of atomic commits. But above that is a logical structure, which only people understand – that operates at the level of ‘nightly builds’ and milestones. You have custom logic which you can apply to the system, using some basic rules. So in essence you have a virtual source control system, built on top of the raw version. By writing a custom source control plug-in for CC.NET, you can expose an interface to your automated build server, so that it recognises when something new is available from that virtual source control, and only builds exactly what you want.

CC.NET offers great flexibility, and those people who develop it, know all about that flexibility. But information on what you can do, and how, is rarer than hens teeth. So over the next few weeks, I’m going to write up and publish here some examples of real-world plug-ins that I’ve written. That should hopefully give readers enough context to go off and write their own plug-ins, to suit their own needs.

Disclaimer: all of the points made here refer to CruiseControl.NET 1.4.x, not the later versions of the system. There are some big and eagerly awaited advancements in the newly released 1.5 version, that many people like myself will have to avoid for now, until it’s bedded in.