Chris Deering introed the conference (albeit with it’s old monicker, Edinburgh Interactive Entertainment Festival, but we can forgive him that. Prior to introing the keynote speaker, there was a bit of quiz-the-audience with the fancy voting devices they’d issued us. The gist of the results:

• Sector likely to experience most growth in the next year: spread results, favouring casual, handheld, mobile and MMO. Few people liked packaged console or PC titles to grow.
• Genre likely to experience most growth: Virtual life (a la Second Life or Home) topped the poll, with music titles a strong second. Not sure if I agree with that assessment, but that’s probably reflective of the general sentiment that virtual online communities are going to grow in popularity generally.
• Percentage of overall revenue to come from online (downloadables, subscription, ad-revenue, etc.): 20-40%. Fair enough – it’s definitely growing and becoming far more relevant, not just in our industry.

On a whim I checked my phone for available Bluetooth devices in the break-out area – an impressive 18 phones and PDAs which is I think the most I’ve ever seen. We do like our fancy toys. The Nokia N70 and N80 seemed popular, but the prize goes to the device cunningly labelled “Matt’s got AIDS”!

Aha! It seems that the Royal College of Physicians has joined the 21st century, and installed wi-fi in its lecture theatres. Of course, I’m at EIF, fueling up on coffee to fight off the hangover-induced grumpiness. More posts/updates as I go through the day of lectures, probably based on how compelling each lecture actually is! If I’d thought in advance, I would have brought my phone/USB cable, snapped a few pictures and added them to the posts, however that will have to wait until after the fact.

So I had a brief moment trying to be telegenic yesterday, being in front of the camera to do a bit for a promotional video being done for the EIF next week. I’m sure I will be edited to some extra small section as we don’t have much interesting stuff to say, but we shall have to see. Anyway, amongst the topics covered was “Why do you think VIS Entertainment went under” – which is sort of a tricky question to answer.

Sure, in the many times in Milnes after work at VIS we laboured long and loud over what we (the grunts) thought the problems were, and anyone for several tables around would be able to repeat them, but I think in the end it wasn’t as bad as it seemed then. Of course, we don’t have any insight into the real goings on, either financial or managerial, so it’s all supposition. However, from where we were sitting it seemed to boil down to one thing: cashflow.

VIS was pretty big at the end – probably still over 100 employees. That makes for a lot of salary going out the door each month. We had two big and one small project on the go (State of Emergency 2, Brave, and NTRA: Breeders Cup), and those had been going for a while, so there was probably little sales revenue from previous titles, only publisher milestone payments. Then of course Brave completed, with nothing to take its place – suddenly more than a third of those payments are gone, with potential sales revenue from it not likely to appear for many months. That’s going to hurt any company’s books, and if the balance is already tight…

That’s not really a ‘why’ so much as a ‘how’ though. The ‘why’ is even more supposition, but I think is reflected in much of what I’ve said here before. Publishers were being hit by tighter margins due to increasing costs, and were responding by tightening down on the developers. Slice the margins thinner and thinner, and the developer becomes so fragile that they cannot long survive if a project finishes with no follow-on, or worse, is cancelled early. In that sense, VIS were just another amongst many studios which died – Visual Science, DC Studios, and so many more across the UK and beyond.

Arguably had projects been cancelled or different decisions been taken things would have played out differently, maybe better, maybe worse. But it seems to me that even if a studio played a perfect game and made no wrong moves, they would still be only a small amount of bad luck away from failure. That for me is a symptom of a troubled industry, and is something I hope will improve. Certainly we all need to work smarter, not harder, to keep costs low enough that making games is profitable.

Interesting post here from Hypnos at Puzzle Pirates about the increasing dependency we have on our internet connections. I certainly know this one – every time I have to uproot and wait for a new DSL line to be installed I go a little bit stir crazy from the fact that I can’t check my email or do all of the things that normally make up my day to day work and life. Luckily this time round (less than a month away now), I have a laptop with wi-fi, and will most likely be haunting one of the free wi-fi coffee shops around Edinburgh to get my daily fix of Internet goodness.

So I must admit to being a bit of a luddite when it comes to embracing the new languages and technologies available for developers now. Partly this is because I’ve read (and heartily agreed with) No Silver Bullet by Fred Brooks, and partly it is because I’m much more comfortable knowing exactly what is going on ‘under the hood’ when I write software.

That being said, having good tools is a vital part of games development, and to write good tools you have to build good user interfaces on top of functional software. No amount of clean, efficient and well structured code is going to get you past that final hurdle, which is to interact with the user. I have spent too much time on too many different projects faffing around with inadequate UI libraries to want to spend any more on it now. I would say I am comfortable with MFC based development, but I would never claim that it was easy or pleasant.

So when I keep hearing other developers evangelising the merits of tools based on managed code (C#, etc.) and the .NET platform. Apparently it should take the pain out of making tools, and user interfaces, and should let me concentrate on the important things instead. Well, that was enough to tempt me in, and to give it a try.

The thing is though, our engine and game code is all based on C++, simple and clean, and we’re not going to change that (no matter how much XNA and Microsoft try to tempt us otherwise). So any tools we build have to be able to leverage all that pre-written code, and play nice with the other parts of our engine. So we needed a way to make the managed tools work with the un-managed engine, and that was where my headaches began.

Straight out of the gate, building a tool application with Visual Studio 2005 was simple and easy, and it took less than 5 minutes to have a skeleton UI that had all the right hooks for exercising some of the engine functionality needed to pre-process our assets. But then I had to figure out how to link those hooks to our pre-existing code, and that wasn’t nearly so simple. The problem was this – a C++/CLI based application (i.e. our tool UI) needs to jump through a few hoops to talk to native (C++) code. The documentation rabbits on about mixed and pure assemblies, DLL building, COM linking and a whole ream of pages about how to build a managed application. All of which is total overkill for what we needed – a simple wrapper layer between the managed UI application, and the native core code.

Now that I’ve found out how, it’s not as hard as I thought; as I work through the details, I’m going to note them down and post them here, because it was immensely frustrating to continually search for tutorials and references (I gave up on the MSDN documentation), only to find lots of people talking about how simple it was, but no-one bothering to let on how it was done.

Anyway, in lieu of a later, better post, here is what I have so far:

• Make a library DLL, making sure that it has managed (/clr) support enabled. This will form the wrapper layer
• The library DLL can statically link to the native libraries you have.
• Build a wrapper class which uses pointers to your native classes to route commands/requests to the native code. Make sure this is a managed class (it should take the form “public ref class WrapperClass” if you’re using C++/CLI)
• NB: You will have to follow the managed rules about not having native value types in your wrapper classes, but you are allowed to have pointers to native types and use new/delete as normal
• In your fully managed UI application, use the Reference system in the Common Properties for the project to add a reference to the wrapper library. This will automagically allow use of your wrapper layer classes, no need for headers or static linkage. [this is the one annoying step that really wasn’t clear from the documentation]

Anyway, a better picture should emerge from this experimentation, and I’m hopeful that once the basic pattern for managed/unmanaged tools emerges, that we’ll be massively more productive and be able to build up a nice tool-set using this new technology.

Interesting post here from Richard Bartle on problems in games industry education and the new games academy that TIGA has been pushing. I agree with most of it, especially the focus on the need for an education, not training. I don’t need people who have worked through a ‘my first game’ tutorial, and it seems like that’s what the computer games courses in the UK provide. The quality of graduate from these courses are rarely better than the wider pool of people who either studied a more traditional course, or who have come from elsewhere in the software industry. I don’t think that’s because the courses are bad at teaching, I just think they are focusing on the wrong things.

What we need are people who has learned the importance of structured programming, or the fundamentals of databases, or any one of a hundred other things that are vital to understanding exactly how to develop software for games. Basically what I need are people who have been educated to the level of a Computer Science degree, but with all of the extraneous parts taken out. Games developers rarely need to know formal proof notation for languages, or details of the electronics behind the hardware on which their software runs. They also need to be aware of the constraints under which they must develop – fixed memory environments, designing algorithms that never take longer than a fraction of a frame to execute, etc. Possibly the hardest thing to learn about games programming is how to make things happen with all of those shiny tools and bloated constructs unavailable.

Of course, my idea of an ideal course for a games developer is probably a bit of a hard sell for universities. After all, if you signed up for a games course, you’d expect to be making games for at least some of it. But the fundamentals of making games are the same fundamentals for all software – it is only when you reach the high-level concepts do ‘games programming’ and ‘regular programming’ diverge.

Nowhere is this more obvious than the field of Artificial Intelligence. I gave up the Artificial Intelligence part of my degree after second year, when it became clear to me that the fields on which it concentrated were not going to help me make games. Neural networks, machine vision, genetic algorithms, knowledge based systems – are all good for cutting edge research programmes, but utterly out of place on even the highest-end hardware for playing games. As such, the AI that you find in games bears little relation to the AI that you would research in a university. Sure, maybe you can build an all-singing all-dancing AI that can respond to your questions and think and act like a real person; but if you can’t make it run in less than 3ms and occupy less than a few hundred kilobytes of memory, then you might as well forget it.

Regardless, it seems that the good people, the ones who shine in their job, are the ones who would do well in games regardless of the course they studied at university. They are the people who make games on their own, who code them in their spare time and learn by doing, not just by being taught. I think there is very much a place for games courses, but they should be far more like Computer Science degrees than vocational courses.

So, I decided to add a bit of PHP to the bottom of the web site pages that displays when the particular page was last updated, and the About page hadn’t been updated since August 2006! That’s pretty bad on my part, so I must apologise. It annoys me when other people let their website go stale, but it’s a bit hypocritical to expect it of others when we don’t do it ourselves. So henceforth I pledge to keep the site more up to date and freshen things more regularly. That goes on the pledge list, probably somewhere around 600th or something. But I’ll try. In addition, I’ve added a Jobs page for the future, although it is empty at the moment, I thought I should have one. We certainly get enough CVs and people fishing for jobs, at least now I can filter out the ones who don’t read past the front page and just spam email everyone.

A little hint for anyone thinking of contacting us about a job: those who show that they’ve actually read the site and done at least some research into the Company are immediately rated above those who just have a list of emails and send off a form mail to all of them

We’re transitioning between projects this week, so Pete and I have been going over what we’ve done for the last few months, how things have gone, what we’ve got and where we’re going. And things are looking pretty good – we’re quite proud of the work we did with Add Knowledge; while there was the usual mad rush to wedge things in, looking back on it we can do some quick re-factoring to turn it into something maintainable and re-usable. Our internal code-base is looking reasonably plump with functionality for making games with, and we’re happy with the style and content. Unit-testing could be more wide-spread and thorough, but that will have to be a long term goal. All in all, I’d rate our performance probably a B for the last project – good, but room for improvement.

Coming up in the near future – well, starting our next project hopefully. Also I’ll probably be looking around for some small cheap office space for us to set up in – a more permanent base from which to grow. And grow we shall – there’s lots for us to do, and only so much time in the day.

A while ago, while doing ‘research’ for one of our contract jobs, I was scoping out pirate games on the Internet. Puzzle Pirates had come up in various places as an example of a massively multi-player game that wasn’t targeted at the usual World of Warcraft playing gamer. So I fired it up and gave it a shot; since it is free to begin with it was a bit of a no-brainer.

The game itself is really a massively multi-player world, but the actions you take in that world almost all revolve around puzzle games. Your character is simply a 2D sprite moving around an isometric world. The puzzle games themselves are nothing particularly new or innovative, but they play well, are polished and fit nicely with the world’s style. Your character earns money by working on a ship (either an NPC ship, or a real ship crewed by other players), pillaging other ships for booty, or by working in shops on the various islands which make up the game world. The workings of the ships are tied to your puzzle playing performance; if you play well, the ship goes faster, and in the case of ship to ship battles, can fire more cannons.

A simple idea, but one that works amazingly well; by no means is it an immersive pirate simulator, but the simplicity of the basic puzzles allows new players to contribute, and the complexity of how the different actions interact with the game world leads the player along a long learning curve with much scope for fun along the way. On a hunch, I introduced my girlfriend to the game, and while she doesn’t do any of the more complicated things available in the game, she is perfectly happy to haunt the game’s taverns and inns, challenging people to sword-fighting (a frenetic block building game) for money. I on the other hand have worked hard (in between regaining the losses made when my other half logs on to my character and gambles away all of my money) to build up enough to buy a little ship, and work on trading between islands. In fact, the in-game economy is complex and rich, and the interface is much like EVE‘s in that it involves bids, sales and supply (fake producers) and demand (player-run shops). Everything the player needs, from weapons to clothes, is produced by shops run by other players – the game masters do little to affect the economy at all.

Those who choose to subscribe can access the full range of the gameplay all the time; non-paying players can join in and enjoy the world, but are limited to basic equipment, restricted from owning shops, and may only play tavern (player vs. player) games on certain days. Those restrictions serve to nicely encourage people to subscribe, without placing a big hard wall between them and the paying players.

All in all, Puzzle Pirates is a great game to play. It’s light and easy to play that you can sneak in a quick 10 minutes of fun between other things, and complex and engaging enough that you may find that 10 minutes turning into several hours because of that one-more-go factor. Plus, Three Rings (the makers), have one of the coolest offices around, and you can’t fault that for keeping their staff happy!

Well, looks like we’ve been outed by the folks over at scottishgames.biz. I think most of the people who find their way to us either knew us in our past lives at VIS, or have been referred to us by word of mouth. There are a few brave and hardy souls who stumble on us via search engines, but they are quickly dispatched and their bodies pillaged for games consoles and cash.

Anyway, I’ve been keeping a relatively low profile until we were more firmly established, but I think there is probably no good time to make a big entrance into the industry, so we might as well stick our heads above the parapet a little. There will be pictures of Pete and I forth-coming, and I will finally get around to updating our About page! The Scottish games industry has seen some high profile losses over recent years, but the blood letting appears to have subsided, and I’m confident we’re on the way back up. Now if we could just persuade the journalists who write for the Scotsman not to keep telling the public how it’s all gone to pot, we might get somewhere.

Aside from that, I’ll be taking advantage of the discount available to Scottish-based developers for the EIF this year (thankfully it’s lost the cumbersome title, although I still preferred just ‘Edinburgh Games Festival’); but we’re a little busy so I’ve decided to miss out on Develop in Brighton this year.