2012 - The launch of GameMaker: Studio

At the end of 2011, we set to work making a new product, GameMaker: Studio, with the intent that we could show it off at GDC in San Francisco in March. This gave us only a few short months to pull everything together, although this time, most of the hard graft fell to Russell. He had to convert all the nasty automated build scripts we had, into something that could work in a product, which wasn't an easy task.

We recoloured the IDE again so that it once more looked like a newer product and set about making the necessary IDE changes. Also part of this major release was bringing our Mac exporter up to date, and making it complete. Up until now, it worked just enough for the games we released, which were fairly simple so far. On top of this we also decided to add Box2D physics into the product to help mark it as a major update from the original.

To help squash bugs, we also released it as an open Beta, allowing all developers to play with it and help us track down bugs. This did result in several large "bug only" releases, but helped the stability a lot.

During this time, I was asked to speak at GDC on an HTML5 track by Darius Kazemi, something I was please to do. I love to do public speaking, particually when it's something I can actually speak with authority on! So while all this was going on, I was also preparing my slides for my first GDC talk, and the games guys were putting together a couple of demos for us to show off.

So in March, we were ready to head off. Geoff designed some large banners for the stand - a significant step up over our first stand at GDC Europe the year before, and Russell and I took them on as oversized luggage. That was a challenge! I searched for a week or so to find bags they would fit in, and ended up with 2 very large Ski bags, each of which could fit half the stand. Still once it was on the plane, it wasn't too much effort, but getting a Taxi big enough to take us to the hotel was fun.

Having not been to San Francisco before, I had expected to get Sunday free, but we hadn't finished splitting the demos, or written our scripts for our talks Sandy had decided we would do, so we actually spend the whole of Sunday in Sandy's hotel room finishing it all off, ready for the show. Sandy, his better half Caitlin, and Michel Cassius however, went out for a day of shopping, leaving us to plod on. We finished in time for us all to have a nice meal together at night, and we were finally ready for the show.

GDC 2012, San Francisco

It turned out to be an extremely busy show at that, and even though we booked late, we had lucked out on the location of the stand, and were directly across from Google, so there was lots of foot traffic. We got lots of interest, and loads of folk downloaded the beta to give it a whirl so we came back feeling good about the future.

But now the hard work of wrapping it all up into a fully viable product began, and there were quite a few late nights to make it happen. One thing we've tried hard to do, is avoid lots of crunch. Sure, it comes with the territory, but there is no excuse for excessive crunch, and while we work hard to achieve the deadlines we set, Sandy has always been flexible when it comes to them, making sure the product comes first, but without killing the staff - something we're all immensely grateful for.

Studio marked a major milestone for YoYo Games, with this product we were firmly looking to the professional developer; that is, a developer that wants to make money from his games not just for fun. Because of the effort involved, and the new target audience, the price was a lot more than the current community thought it would be, and they weren't happy. This was to be expected though, these guys were basically folk who bought Game Maker for $15 and many had been getting free updates for years. To suddenly have to pay hundreds of dollars seemed like a rip off to them, yet to a professional developer, a couple of hundred dollars with no royalties seemed like a deal that was too good to be true. But if YoYo was to grow, we needed these professionals to take us seriously, and shows like GDC were all about raising awareness of who we are and what we are doing.  Of course,we'd seen this already with GameMaker: HTML5, but it came back with a vengeance for Studio.

This isn't to say everyone felt like this, no, it was mostly the very old core GM devs who simply felt that YoYo should more or less be giving everything away for free - or close to it. But Game Maker was no longer a hobby project by a one man band, YoYo now had staff, offices and bills to pay, and this meant it had to be realistic on pricing, but that didn't matter, and suddenly everyone was a marketing expert.

While all this was going on, I'd decided to create a Deluxe version of Simply Solitaire at home, to see if it would help kick it back up the charts a bit. I had also merged the products into one, as previously we had 2 code bases, one for phone, and one for tablet. This was a nightmare, so I merged them into one, and created a new Pro and Free version. This went on sale at the start of April, but aside from now simplifying our code (and finally giving both Landscape and Portrait versions in one app), it failed to boost the app up the charts, which was a shame. One thing it did do though, was get a complaint from someone who owned the trademark of Simple Solitaire Deluxe, something we obviously knew nothing about. So we quickly rebranded as Simple Solitaire Pro and pushed out an update. The owners of the Deluxe trademark were friendly enough and this satisfied them and Apple.

We plodded with the work, and on and Studio was finally released on 22nd of May and we were finally able to draw a breath. Sales went well, when out of the blue YoYo got an invite to display at Google I/O, so Russell, Malcolm and Sandy all headed off while the rest of us carried on. We finally got another payment system in place, and hoped that this would solve all our problems - it helped a lot, but didn't quite.

Around July we had a very interesting call with Steam, and as they were about to open up a new software store, they were interested in getting GameMaker on there. Now, Sandy had been very rude to them the last time we spoke - things just weren't right for us to do anything, so it was a little embarrassing, but Valve are a great company, and everything was laughed off and smoothed over, and it was decided we would be one of the very few launch products for their new store. We asked when it was launching, and they just laughed again. Valve time is well known for being whenever they are ready, so we never felt much of a rush. We said we would look to add Steam Workshop support - something they were utterly thrilled at, but we had to make certain restrictions in the runner, and so the infamous Sandbox mode appeared. This was to protect users from rogue code, and to make sure everything was secure.


Russell was busy with other things, so I set to work making a new Steam version, when all of a sudden we got another slightly panicked call saying it had all been pushed up, and we had just a month to launch. We debated how much time we had, and how much I had to do, but we decided to just go for it, and put everything we'd planned into it. This included Steam workshop support and the the new Player app. I took the sample app they provided as it had both Mac and Windows support, and stripped it back, then added the player support, including downloading of subscription games, and playing them. This turned out to be a mistake, the sample app must have been written by an intern, as it was pretty nasty, and the Mac code was done totally wrongly. Russell took over the port of the Mac version and fudged it enough that it worked - if only just.  It was extremely hard work, and the whole month was basically crunch - something none of us wanted, but we had to be ready when Steam was.

I finished up all the new licensing system, plugged in the DLC engine they used and managed to get the whole of GameMaker and the exports onto Steam, Sandy was ecstatic, and Steam...well, it got delayed by about a month. Typical. Still, our work was done, and while I was off on holiday, Steam launched their Software store. We got some great press from it, and the new Free version we created for it's launch went down well. On top of that, we appeared to be the only bit of software that had implemented the Steam Workshop, so steam were extremely pleased with us as well. It might have almost killed me, but it was certainly worth it.

While all this was going on, Stuart and Sandy had been working hard with Microsoft, and we had added window 8 Javascript support, and we had started work on windows RT support - for native support on desktop, and phones/surfaces. Unity had announced this as well, but in typical Unity fashion, they announced a lot, and delivered very little. We on the other had managed to deliver what we promised, and Microsoft were also extremely pleased with what we delivered.

Enter November, and possibly the darkest hour - as it were, of my time here. The DRM bug. The "skull and crossbones" had been added to keep hackers at bay, and it had done just that since it's launch (and it wasn't for their lack of trying either) - which was quite an impressive feat, but additional checks were added by the team and in certain cases these simply failed, and resulted in false positives springing up. The additional code simply wasn't tested properly and a few users - only around only 0.02%  if memory serves were hit bit this. Most were able to restore from backups, but a couple weren't. We got a fix out within 2 days, but the damage was done. It was blown up out of all proportion, and folk were shouting how stupid it was and that they would never use GameMaker again, even when most of the folk complaining it turned out, never used it anyway. While the original code was mine, the bug that cause it wasn't, but the outside world needed someone to blame and it fell on me, which was fine. One thing about being outspoken in other cases, when things go wrong, you have to take it on the chin no matter who is to blame.

However they were right about one thing... my personal fight with the pirates had blinded me to our paying customers, and no matter what protection you put in to a product, it should never, EVER hurt a legit user, no matter how small the number. It was a painful lesson for me, not least because I'd seriously upset Sandy, and he's put a lot on the line for YoYo over the years, so his disappointment in the resulting news scandal was something I was quite upset over. We removed the offending checks, and then removed all other checks that could hurt an end user. In fact, the protection went totally passive. It still checks itself, and the various licenses, but it now only records and stores the issue for later analysis, and while we do now know who has a cracked copy, we haven't decided what to do about it yet.

So while 2012 was mostly a positive year with some astounding releases and work, it ended on a low, partly because I knew how out of proportion the whole DRM thing was, but mostly because I'd disappointed Sandy, and he has enough on his plate than to deal with stuff like this. So lesson learnt, I was looking forward to 2013 and getting back to the great foundation we'd built with Studio.

2011 - When it all starts to change.

Early in the new year we also released Mr Karoshi, which went on to win Android game of the year at a Pocket Gamer event, and as Russell finished off the Android runner, Stuart and the team started to work to get all our games released on the Google store as well.

So, up until now, the real focus was the runner, and getting it onto consoles and other platforms, but now the decision was made to update Game Maker 8, and see what we could do with that. We hadn't really touched the IDE at all, but I'd used Pascal years ago and quite liked it, so thought this should be relatively simple - how wrong I was.

Delphi is a totally different beast, and one that has numerous quirks waiting to bite you when you least expect it. Still, I was excited to take on Game Maker, and see what I could do with it. When I first started looking at it, it quickly became apparent that the room editor needed work, it's lack of zoom made doing lowres games a nightmare as small tiles were incredibly tricky to place. I've since discovered the reason for this is that Mark never uses the room editor, but a defines everything in text, and loads it in. This explains alot. He also said he didn't think it was possible to get enough speed from the rendering of the room to allow it to zoom, but that was never a concern for me. Pascal as one thing going for it, that being when you need to, you can drop assembly code right into the middle of pascal, and it all just works. Also, being an old sod I've written enough scaling sprite routines that I didn't view any of this a major challenge, so I basically rewrote Marks room drawing Delphi code, in pure assembler which then gave me the speed required to add zooming - probably the most requested feature at the time.

PokerSquares HTML5

While working on 8.1 Sandy also decided to take the plunge and try and get something running on HTML5. We had always had the browser plugin for GameMaker, but the bounce rate on it was horrendous, and it hardly ever worked thanks to all the browsers changing every couple of months. So, Sandy got Russell and I to see if we could deliver a prototype - a proof of concept that would prove it could be done. This was mainly so he could show it to some interested parties who had started sniffing around looking for web engines.

Russell took on the compiler side, and I set about learning Javascript and HTML5. This was the first time we had written a runner from scratch, and it was pretty frantic work, yet in onto 2 short weeks, we had a one of our latest games - Poker Squares, running in a browser. To put this into perspective, it took us 3 months(ish) to clean up the C++ runner when we first got it, yet in only 2 weeks, we were able to get the framework of a brand new runner - enough so that a game would actually run. Not to blow our own trumpet, but that was damned impressive, and very cool. Russell then took this demo and showed it around at GDC in San Francisco, and the response was pretty good, so much so, that after 8.1 was released, we decided to jump on the HTML5 bandwagon and see what we could do.

Still, we had to get 8,1 out of the way first, and it was about this time we started "leaking" images, and teasing the community with what was coming - something I LOVE to do. We got Andrew to leak this little image and everyone started to get excited, knowing an update was coming, and then over the next couple of months we leaked some more details, images and the like. Another big feature was the auto-updater, so we could release new versions more quickly, and make sure everyone gets them. Traditionally, this has never happened in Game Maker, and folk have been stuck with much older versions.

While I was looking at this, Russell finished off the Android runner, and Andrew, Geoff and the rest of the games guys started churning out games. Russell then joined me on the final push of GameMaker8.1 and we released it (I think) on the 15th April, 2011. This was a free update and moved everyone from Softwrap to our own DRM.

We added quite a lot to it in the end, and over the next year, added even more features and upgrades, from new Font rendering code, to much, MUCH faster 3D rendering. However... some of this came at a cost, and the addition of the "TV" logo was much debated. This was something we discussed with the community as the initial idea of the .EXE timing out didn't exactly go down well. So, we listened, and we discussed, and the TV logo is what came out of it - for the Free version, and only on final .EXEs; that and a nag screen. It still wasn't hugely popular, but then, those who complained, were usually those who had no intention of ever buying - so what do you expect. By way of compensation however, we DID add in some pro-only features like sprite rotation, and the zooming room editor and this did help quiet folk down.

Food first.... planning later

Once 8.1 was out the door, and we had a couple of stabilising updates out, we turned our focus to HTML5 again. With the proof of concept, we saw that not only was a HTML5 engine possible, but very practical, and so Sandy decided he wanted a full blown HTML5 version of GameMaker to sell. We set about planning it all, and Russell, Sandy and myself went over to meet with Mark in Utrecht and talk through what would be involved, and how much time it would take. Our goal was GDC Europe in August - or at least have something to show there.

It took us around 3 months to do a full rewrite of the runner and most of GameMaker's functions - there's a hell of a lot of them, not to mention the work on the IDE to make it look different. Fortunately, we weren't alone in this, Chris Harrison joined us; this time, and eegeo rescue case - these were members of the original team who were rescued from Realtime Worlds by some of the original investors. Anyway, Chris joined us and help port the many thousands of functions over.
Paul Cosgrove also joined us to help with a new Website update (and yes...I missed when Lee Turner joined us, I'm not exactly sure of the date he joined).

GDC Europe August, 2011

While we were ploughing into the work, the games guys soldered on, and produced more and more games, something that would stand us in good stead later on. With the bulk of the work done, we were finally able to use the IDE to create GameMaker games, and with a simple click, export them to HTML5, so so GameMaker: HTML5 was born. YoYo booked it's first ever show stand, and with some bad posters and makeshift banners, we wend over to GDC Europe to flog our wares.
This was another milestone for YoYo Games, and things went down pretty well, although the main driving message was - "That's really cool, but can you export to iOS and Android as well?". Bugger... Yes we could, but it wasn't built in, there were a complex set of build scripts that the games guys used to create games, and that certainly wasn't what the public would want.

Still,the show wasn't over yet, and thanks to a deal Stuart had done with Sony and for the Experia Play, we were now supposed to go on stage during the public days of Gamecom - a scary prospect. We watched the doors open from inside, and the masses descended into the halls at a run - usually in full games attire; Mario, Zelda and the like, so we sat to one side trying to stay out the way until we were required to fight our way through them to get to the stage.

We were to demo They Need to be Fed and the new special update that had been released, or rather I was expected to play it on a big TV in front of a (now) rather large crowd while Russell commentated. While waiting, I decided some practise would be good, as I hadn't played any of these levels before. Sandy got up on stage and did an intro - which he loves to do, then stepped back and let Russell and I embarrass ourselves. Still, didn't go too badly I guess, and was pretty good fun in the end, it's just as well I don't get scared in front of crowds isn't it!

We came back to the office to regroup, and realised that yes.... once we finished GameMaker: HTML5, we needed to start on a new product, one that did everything.....GameMaker: Studio.

GameMaker: HTML5 went on sale in September, and was selling well when, without any warning, our Paypal account blew up. We'd suddenly hit an automated limit, that looks for "spikes" in sales and then limits the account automatically (or so we believe). Many others have had this, and getting your cash from them turns out to be an utter nightmare, it has in fact taken us 2 years to get back into a working relationship with them, and we've been very careful to try and keep them updated on everything they need so as to make sure the aren't surprised by anything.

This caused a week of utter panic, as we suddenly couldn't sell anything, and in just a week, Lee managed to implement a new payment system and get us going again. This isn't to say it was without problems though, the design was (obviously) rushed, and we did get issues with it, but we dealt with these as best we could and moved on.

So 2011 saw us move from a small team, into a larger stake, and release 2 new tools in the form of GameMaker: 8.1, and GameMaker: HTML5, as well as releasing our first batch of games on Android, and having a huge hit on iOS in the form of Simply Solitaire - it was a busy old year, not like any of the coming years would be any less mind.....

2010 - A fresh start....

So here we are, the start of a new job, a new office and everyone raring to go. With only 4 of us there initially, it felt like a large space to fill, but it was cheap, and we had room to expand.

When we started, GameMaker 8.0 had just been released, and we weren't really looking to touch the IDE or windows platform at all, our sights were firmly fixed on getting games onto consoles - something we still really want to push, but has never managed to happen fully for us.

Russell also suddenly got pulled onto GM4Mac, as the guy that was writing it, slowed down to a crawl, and Sandy had been desperate to get it out the door for years now. With Russell now pushing it full-time as well, this was now suddenly a distinct possibility.

We finally made good progress on the PSP with our first game Green Tech by David Galindo was heading into the dreaded Sony submission process. This wasn't something any of us were looking forward to. Then something else happened.... Sandy suddenly wondered if it would be possible to get games onto the iPhone/iPods. The Apple app store had started to take off, and he was wondering if the runner would work okay on these new touch devices. He brought up his iMac got us an iPad, and I set about doing the first port, and inside a month I had the initial version running pretty well.

Come September, and we showed off this new work in progress, and set the a benchmark for new ports - around a month for the core of the work, and then a few weeks for all the frills. While over the years as new features go in, this now takes a little longer, it's still a fairly quick process compared to many other platforms. Since it had been one of our test games for a long time, we felt it only fair to let Chad Chisholm's Sky Diver be our first iOS game, and so we got Geoff Gunning to spruce up the look and feel of it, and submitted it to Apple. 
This was definitely one that made us nervous, Apple had just announced new rules for apps, and that games had to be written in C++/Objective C. Now the runner obviously was, but the games were script, and so we weren't sure how they were going to view these games. We knew that this was mainly targeted at Adobe's Flash, but it could have an aftershock that hit lots of other games. The first time, the game failed submission - not a big surprise for our first game through, but the only mistake was an icon or something, nothing major. It passed on the second attempt, and GameMaker's first cross platform game went live.
During the port of Skydiver, Realtime worlds had gone pop. The excessive spending, bad planning, and the refusal to let anything else out the door before APB hit them where it hurt. The whole My World team was let go, and the APB guys were sorry to see it, but were living in a little dream world, sure it wasn't going to happen to them, when a month or so later - it did. The whole company folded, and suddenly there were around 300 coders, artists, designers and testers out looking for work. Stuart Poole a producer on My World came in to see if we could use his skills, and it didn't take long for him to make himself useful, he helped push Skydiver through production and submission and came in full time shortly there after.
We started looking for another game, and this time pick Andrews "Maddening" game. It was different, looked nice, was pretty good fun, and actually a pretty small game meaning we could port it quickly. We did have to help Andrew optimise it quite a bit, as the rendering  wasn't great, but after that was done, it ran no problem at all. This was also the first game we had featured, as it suddenly appeared in the New and Noteworthy on the iPad - another first.

We then started to think about a little Christmas present for the community, and so started work on Simply Solitaire. This was to be a basic card game, just as a promo to what GameMaker can do. Geoff did a set of "wobbly" cards, which set the games unique look and feel and Andrew did his best to break my brain, by adding bugs into the most complex way of writing a simple card game ever devised. I jumped in and tried to help sort it out, but as this was my first real use of GameMaker, it was a shock to the system, not least because the way Andrew coded was nuts. Growing up with GameMaker, he doesn't think the way a traditional games coder does, and that makes his game code a little strange - to say the least. Still, after much cursing and swearing, and calling him Susan, we got it working and submitted it to Apple and it made it in time for Christmas.
Then something unusual happened in France. We've never been able to figure out exactly what or why, but it took off. Certainly Christmas helped, lots of new iPad owners were looking for free games, and this helped push the downloads up. In one day a alone we got over 77,000 downloads. Over Christmas we got to not only the number one card game, but the number one FREE game in several countries. It was a staggering achievement for something that was supposed to be a test - a promo. The only reason for making it, was for the YoYo Games logo in the background.

Solitaire HD - Number one FREE app

On the 28th December, it hit the Number one free app in the US, and we had a massive number of users for the 1st time. We decided to try and push out a quick fix for a minor issue, and in pushing too hard, made a fatal mistake. We simply didn't test enough, only Stuart and I really tested it, and 2 people testing for a few days, compared to the now hundreds of thousands is no comparison. It blew up - badly.We lost our top spot as reviews reported it was broken, and users were warned not to update. Sandy wasn't happy, and decided it had done it's job anyway, so to just ignore it and let it die.
Russell and I however, had other ideas....  We really wanted to try out the new in app advertising, and figured with the number of users Solitaire had, it could be interesting - and we didn't really want to let our biggest hit so far die either. In very early 2011, we fixed the issues and added a small advert in the lower right hand corner and push out the update to see what would happen.

The result totally surprised us. Aside from fixing the issues and keeping our users happy, we suddenly started getting in good money from advertising. In fact, not just good - great money from advertising - at which point Sandy forgave us for ignoring him, and promptly told us to add it to the other games. It's always been a problem; how to monetise users on a free game, and in this case, ads work - but they don't always. We tired adding adds to Skydiver and Maddening, and then suddenly realised that, yeah.... ads don't always work, but Solitaire was still doing well, and we still had a great user base, and income from it. Even when talking to some ad companies, they've been surprised at the number of impressions we've gotten per day, and have wanted a bit of that action. 
In January, Sandy also decided he wanted to get onto Android, and so while Russell set about doing that port, the PSP version of Green Tech was finally ready to go. Malcolm Collins - another rescue case from Realtime Worlds pushed the game through submission (physically sometimes, or so it felt), and it was finally ready to be released. It didn't do amazingly, but it was our first game on console, so we were reasonably happy, but we still really didn't like the submission process.
We hoped this was just an issue with the first game only, but time would tell, and tell badly...

2009 - A long road ahead....

Coming to the end of another year at YoYo Games, and it's hard not to reflect on how we're doing, and how far we've come in the short time I've been there. As I feel the need to ramble... I'm going to go back to where I was before, how I got here, and just how much we've accomplished in this short time.

Demo shown to Ordnance Survey

So, back in 2009 I was working for Realtime worlds doing a project called My World, this was a large GIS (geographical information system) based engine. That is, a 3D world based on real world digital map data. Dave Jones had brought me into the company back in 2005 and I founded the project, and was the sole member of the team for about a year, before Russell Kay joined me. In that time, I got the basics working and we presented the concept to Ordnance Survey, the owners of the UK map data. They were incredibly interested, and gave us even more data to test with, basically we got the whole of Scotland for free from them, and the project moved on. Meanwhile Russell joined and things gathered pace as we scaled everything up. We put together a demo and showed it to investors and (eventually) Realtime Worlds got around $80 million in investment from various places. All was going well, and the team grew as the project grew in importance and everything was right with the world.

A few years in however, and it all started to go pear shaped. The folk they brought in to manage the team never really understood it, and little groups formed within the team. There was very much a "them" and "us" culture. The "them" were mainly a bunch of juniors, and the producers, they loved meetings, bureaucracy, and doing jack shit basically. They were forever refactoring things, trying to make everything perfect and basically making no headway at all. The "us" were some of the original team, and basically those who knew what they were doing; We wanted as few meetings as possible, and to just wanted to get things done and get something out the door, knowing nothing is ever perfect. However, as time went on, the producers and management put more juniors in controlling roles and basically took over, and the project was doing it's best impression of a swan dive. So... come mid-2009, and I was at the point where I didn't see any reason to do free work at home any more, and started looking for something else to do.

Enter Mark Ettle (CEO of Cobra Mobile), an old boss, and a good friend from the old DMA Design days. He told me about a guy that was after some basic porting work, and wondered if I was interested. Now, a lesson I learnt a while back is that while doing a fulltime job, it's virtually impossible to do anything major at home that isn't aligned with work. Your brain just doesn't like being pulled in two different directions, and so I figured that if I was going to stand a chance, I'd need someone else this time, to help when I slackened off. So, I persuaded Russell to help me, and I met with one Sandy Duncan in June of 2009, midway through a road-trip holiday I was having, touring England on my own (which was great fun BTW). In the initial meeting with Sandy, he told me about GameMaker, and that he had this C++ runner that he was looking to port to the PSP and his plans he had for it all, while I described the experience Russell and I had, and what we could do for him. All this went well (obviously) and Sandy sent us the source for us to look at.

It was horrible, utterly horrible.

The runner had been commissioned so that it could go cross platform easily as the original (written in Delphi), was totally unsuitable. However, it had been farmed out from the company hired to do it, to an intern, and was written in MFC (Microsoft Foundation Classes). This is as about un-portable as you can get. The code was also horrible, not only written by a junior with very little experience, but designed to be very closely based on the original Delphi version, with special classes/code to try and emulate what the Delphi did, instead of making it a proper C++ project. Russell and I spent months just removing the MFC and cleaning it up to the point where we could even begin to start porting it - there are still areas we've never touched, that are still just horrible.


However, port it we did.... and several months later, we had it running on the PSP and showed Sandy when he paid us a visit to Dundee. He was ecstatic to say the least. Part of his dream for YoYo was getting games to play on other platforms, and many, MANY folk said he'd never manage it, but we had. What's more, we were running on a very low powered system, meaning it was all upwards from here.

In early 2010, things at Realtime Worlds had progressed beyond the point of stupidity, the "juniors" were now running pretty much running the show, making sweeping choices that crippled everything without understanding anything. My only amusement in all this was that decisions they had overridden years ago, were now coming back to bite them in the arse. Things I had told them simply wouldn't work some 3 years back and had been told was was an idiot, were as expected, coming true, and they were having to rewrite loads of stuff to fix it. I said it then, and I'll say it again, if you hire experienced folk, you should really listen to them.

Anyway, enough was enough, I was looking for an out, so I approached Sandy and we started to look at setting up an office in Dundee to work on GameMaker and all it's ports, and in early March 2010, I started working at home, finishing off the PSP runner along with Russell. We worked like this for about 3 months or so before we found an office, and it was just in time too. We were getting to the point where we needed to be sitting next to one another, Skype just wasn't viable any more.

Russell and I on the first day at the new office

So we opened the first office and Russell, myself, Andrew McCluskey (Nal) and Kirsty Scott started full-time in a brand new office, inside Abertay University. Andrew was hired from our community, as a GML programmer, and initially was simply doing tests for us. As time progressed, he became the first member of the games team, porting community games to other platforms - along with his own. Kirsty came in as our Community Manager, and manned the help desk, while Russell and I plough on with the port.

So... here we are, the beginnings of YoYo Games in Dundee, and the start of a wonderful road to wander down. In the 3 and a half years I've been there, we've done an amazing amount of work, games and tools.

I'll carry on rambling tomorrow, where the fun really begins!

A game in 2 weeks.

So, while at Realtime Worlds, they decided to let everyone have a play and gave them 2 weeks to do a game. We were broken up into several teams, each was supposed to have about 5 folk on them, however some had 7 or so, and out team had 3. Still, our team was awesome, and I wouldn't have had it any other way!
Although we had 2 weeks, we were supposed to spend the 1st week coming up with a few ideas, then the second week actually coding the chosen one. We had to submit the ideas to Dave and a couple of others and they would pick which one we were actually allowed to do in the final. I more or less ignored this, and spent a few days doing some research into imposters (more on this later), which basically allowed me to stack the deck so they'd have to approve the game we wanted to do. With only 3 members of our team, we played the sob story about how little time we'd have compared to the others, and that having done so much work on these imposters we should really be allowed to just carry on. Unlike most of the teams, I wanted to use the time to prove some tech that I wanted to use in MyWorld, not just have fun for a week making a game.

So what are imposter? Imposters are sprites that gave "many" rotations that you can use to "pretend" they are 3D objects - or entire 3D scenes for that matter! You can use them as a single billboard sprite rather than draw a complex 3D model, or even an entire area of a 3D world. They can be very handy. I'd done some work in them before where I had dynamically generated them, along with an Imposter ZBuffer which allowed you to drive "through" a sprite scene. Yeah... it's as odd as it sounds! Each texel in the imposter has a depth value, and that means a 3D model could move between it's pixels, unlike a normal billboard, where you could only move in front of, or behind it. They were pretty neat. But for this test, I was ONLY interested in raw throughput. So I did a bunny test (all good tests use bunnies!), and I tried to draw as many as I could. The scene shown here has around 50,000 bunnies. I have another image (I might upload them all to Flickr) that has around 200,000 at 38fps. These weren't static bunnies either, they followed a 3D terrain, and if you looked around them, they would look like a 3D model - pretty nice.

So, Dave and his gang picked the game we wanted - basically a Zombie tower defence game, and we had one week to make it work. We were given the world model in which it would all take place, but had to write everything else.

The first thing we did was to come up with a funny hovering Zombie type critter. He wasn't very pretty looking, but having no feet to animate meant a lot less imposters! This game was ALL about the massive number of things attacking you - kind of like the original doom, but on a bigger scale.

As a team, we were able to split things really easily. I did all the graphics and effects, Bill Henderson (who did the physics in Wild Metal Country) did the physics and general gameplay, and Sam Phillips did any graphics we needed. That said the art department weren't specifically assigned to a team and just churned out art as needed, so Tahir Rashid did all our 3D models (tanks and the like). This worked really well. While other teams spent ages in discussions about roles, and even changing engines part way through, we had really clear jobs and we all just got on with it. It was the most fun I'd had there in years!

Because of the massive numbers of Zombies the engine could do, I didn't even need to kill of dead Zombies, so corpses littered the field - it was very cool. They would pour out of the burrows hundreds at a time, till there was tens of thousands attacking! I did a very simple route finding system - and the would get stuck, but for the massive numbers, we couldn't do proper route finding for them - it worked pretty well though.

We put in lots of weapons to buy, and added a day/night cycle. During the day you could rebuild, add new weapons, and basically recover from the carnage the night before. At night, all you could do was watch, and keep your fingers crossed. Well... almost. You controlled a tank which you could go out and help defend areas, and basically blow up zombies on mass. Your tank took damage and you could recharge by returning to base, but if you'd left a hole in your defences, the zombies would get in and attack and destroy your base.

Some of the effects turned out really well (especially considering how little time we had). I wrote a small particle engine (that I donated to the other teams if they wanted it), and that let us do some cool effects and weapons. The Flame thrower and lasers were neat, as they'd set zombies on fire, and they'd run around with their head burning! The nuke was awesome! The nuke would explode in a massive BOOM, and fling everything - living or dead into the air, flying all over the place! WHEN you failed, you got to drive around just letting off nukes all over the place, it was very cool.

So, there you go.... You would think, with a game everyone enjoyed, Realtime Worlds might do something with it; but no. They were dead set on doing an amazing 3D world, and using it to play "Farmville". Ah well... It was good while it lasted. Still, the MyWorld tech was bought before RTW sank beneath the waves, so there is a remote chance that at least can still be saved. Of course, they'll have to hurry, I've seen several demos that are very close to what MyWorld might have been. That said.... I doubt they would have had flaming Zombies in them.

Oh... and Merry Christmas!! :)

A new direction in gaming...

I've been clearing out some of my folders and I discovered this, it's an article I wrote, way back in mid-2004 for MCV and it talks about appealing to the mass market, not hard core gamers. Re-reading it, I feel that very little has changed really. Realtime Worlds and APB epitomised this problem - to their cost, and while individual developers have taken some of this to heart via the new mobile market, consoles and PC games are still very much stuck in the old way of thinking. Sure, EA and other companies have just started to do the same in the mobile space, but it wasn't through choice, it was forced on them. Anyway, here it is. Perhaps I should do another, and try to predict what will happen in another 5-10 years! :)


A New Direction In Gaming

In today’s mass market climate, the idea behind making games is simple, spend as little as possible to make as much as possible. To do this, you need to get the highest percentage of players to development pound as is possible. For example, if you can get 100 mass market players for 1% spent on a project compared to 5-10 hardcore gamers for the same 1%, then you do what you need to get as many mass market punters as you can.

This makes sense, a lot of sense; so you have to wonder why so very few developers/publishers do it. Sure more and more players are being welcomed into gaming culture, but where’s the development cost going?

First, you have to decided how long an average project is, and for this discussion we’ll say two years. For many Large AAA games, this is conservative, since they can span 3 or more years (Half life 2 and Doom3 being 4 to 5!).

If we also assume that the cost is spread evenly (which isn’t usually what happens – costs usually go up towards the end), what portion of your development do gamers play? Well the mass market gamer will buy a game, and play only a small section of it before either becoming bored with it, or simply not possessing the skills needed to reach higher levels. Problem is, with games being so expensive, they won’t then rush out and buy another one, they’ll simply play this on off and on, and not getting much further, and getting more and more frustrated.
The Hardcore gamer will play the game from start to finish, and take however long is required to do so. This means he won’t buy a new game until he’s finished the current one. The developer’s problem is that they make content for the hardcore gamer, making games bigger and bigger to satisfy these people (and I include magazine reviewers in this as well since they play games for a living).

This pushes up team sizes, costs and risk. The problem is, around ⅔ of this is wasted effort. The casual gamer just doesn’t get that far, so the return on your development pound drops after the first few levels. Ironically, the first few levels are easiest to make, the most polished and usually finished inside a year to 18 months, and would probably reduce the development cost by at least half. So, what if games were ⅓ the size? What if they were ⅓ the price? This would place games squarely in the impulse buy bracket (around the £15-£20 mark), and as a result, people would probably buy more games. And even if they did finish the game, a new one isn’t 4 years off. Updates could extend the game easily with more levels; in fact the exact same levels that were going to be in the game in the first place, only now, the casual gamer will now want to buy and play them, pushing up the return on the development pound.

Teams should not only find that the dreaded overtime is now reduced giving them a social life, but that the next set of games are much easier to do. With a firm codebase to work from, extra features and content can be added along with new levels in around 6 to 8 months making new releases quicker to come out, again increasing the value of the development buck.

So what’s the downside? Reviewers will no doubt complain that games are smaller, and hardcore gamers moan that they finished it already and will then promptly rush out and buy more. However since the price is now at least half what it was, they can afford to.

They may have to wait 6 months for the next set of levels and added features and so on. But what percentage of your paying public is this? No clear study has been done, but several reports suggest that only around 10-15% of the market can be attributed to the hardcore.

Given a choice of paying ⅓ to a ½, most of your paying public would opt for the smaller game, given that they’ll never finish it anyway. Putting it another way, if GTA was ⅓ the price and ⅓ the size (say only 1-2 stages), would you care? Especially if you knew another was only 5-6 months away?

There’s also a sound psychological reason as well. When a player finishes a game, he gets a thrill from seeing it through to the end, and this encourages him to do it again. Being beaten over and over isn’t very satisfying, and will eventually drive them off. Valve’s “Blue Shift” was a case in point. Small, beautifully done, and possible to finish for the masses; not to mention only costing around £15. Reviewers weren’t happy at the size of it, because they were used to these games and finished them easily, but most people who played it, loved it.

Anyone who’s played Farcry will know that it just doesn’t stop! It goes on and on. By the end of it (and I cheated to see the end, only to discover around 15 huge levels!), you’ve had your fill. And if another one came out, I doubt I’d buy it, as nice as it was.

Certain games will always take time (Doom, Unreal and HalfLife etc.) since they also make engines to sell, and others will appeal to everyone no matter what the size (Sony’s Eyetoy being one). But for the most part, there is simply too much content in games. Anyone that’s played Halflife 2 will notice fantastic levels that you fly past and only see once; pointless.

The point is, that even though there is a small market for very large games, all gamers expect games to be large because the magazines, online reviewers and even publishers assume that every game has to be, when its simply not the case. Games are one of the cheapest forms of entertainment around; DVD’s and Cinema give you only a few hours fun at most for a lot more cost. However reviews and the hardcore seem to expect games to last for months, but without the price tag. This needs to change.

While games will always represent value for money, the size and scale of them needs reducing. Around the days of Shenmue on the Dreamcast, there was talk of episodic game creation. While not quite the same thing, the concept is sound. Smaller games, more often.

The Sims have proven the bolt on market very successfully, and while the game is larger than normal, it keeps extending itself with each “small” release. This in turn keeps the interest up, and sales going. The last problem here, is convincing publishers that they need to sell these games cheaper. After all, the public's used to paying £30-£40 for a game, so why stop? We can make even more money? Publishers must also be made to realise that its in their who best interests to reduce the price, and get into that critical impulse buy bracket. Once there, sales should go through the
roof.

Not only would this aid in getting a better return on development costs, but it helps the development team do less overtime per game, reduces the risk to the publisher, and thereby allowing more variety in gaming. It also helps the public by reducing gaming costs and by allowing them to complete games, which in turn encourages them to play more, and hence buy more.

Its time to stop coding for the hardcore gamer, and go where the money is.

DMA Design radio program

A while back the BBC did a little radio program on Dave and DMA Design, it's a pretty good program and well worth a listen. It's mainly four of us talking about how it all started, and you can hear Dave, Me, Russell and Steve talking about how it all got going. Anyway... it's pretty good, so have a listen.

Quiz...

Okay, so perhaps I should have been a little clearer, but the general rule of question one sticks through out. So here we got...

1) Memory Access. This is it pretty much it, especially on today's hardware but does have a similar effect (if not as profound) on older machines as well. If someone is reading/writing gigs of data every frame, it's gonna suck, not just because they have a huge loop in there, but because in modern computing (and we'll stick with this just now), memory is the number 1 enemy.

In the past, CPU access was around the same speed as memory, so it would be a little slower to read from memory - usually just a few cycles. These days, memory is incredibility slow compared to the CPU. Register operations will (in real terms) take less than a cycle, while un-cached memory access can take thousands of cycles (once you remember page faults and the rest).

This is crazy, so the less memory you can touch the better. Now... this may include reducing passes over data and doing it in one pass (while doing a little more register based work), or simply removing data access and tables if you can do it in a simple calculation. In the past, we used to have multiply and divide tables, but these days this table can be so expensive, you're far better just doing the ASM instruction which only takes a few cycles.

So, heres a real world example - particles. If your doing particles on the main CPU (we'll ignore the GPU for now), then the smaller you can make your particle structure the more you'll be able to render; not because you can draw more, but simply because the CPU only has a limited memory bandwidth and reducing that means you can do more, or better yet, do other things - like gameplay.

I've seen it over and over again. People continually looping over large amounts of data, wondering why things are slow when it's not that much data they're processing. Remember in this day of the multitasking OS, a 1Mb cache is not yours alone. You're data will be continually kicked out by other processes, so even if you only have 64K of data, you'll be surprised how little time it spends in the cache. The answer is to prefetch the next block, and do a little more processing on the current one, thereby reducing the number of iterations you have to do. After all, if your talking 400 cycles (say) to read a cacheline (around 64bytes last time I checked), then why not use the 400 cycles doing something instead of 400 cycles waiting on memory coming into the cache?

2) This actually has nothing to do with optimisation - by bad. Its a simple 2 part question...

2.a) Release it. No game, or application is any good if you never release it. No matter how shiny, awe inspiring, or ground breaking; who cares if it never sees the light of day? So rule 1 of any program development, make sure you get something out, or it's just wasted effort.

2.b) Make it fun. In games, it's easy to release something with lots of features and levels, but if it's not fun, no ones gonna play it. It's that simple. I can name several games that appear to have been developed by idiots. Games that were all gloss and no gameplay. Some teams fixate of making things as pretty as possibly, but thats really not the most important thing. You have to enjoy being IN the game, or like 2.a it's pointless and a waste of time and effort. You'd be amazed how often this rule is ignored, or something particularly frustrating removes all the fun that SHOULD be there.


So there you go... Yeah, not the best phrased questions, but I bet looking at these you're either nodding in agreement, or shouting at the monitor something like "Rubbish! Algorithms are FAR more important!!". Well, this is true... but given even a reasonable algorithm, you can then apply the memory rule and speed it up more. The less memory you touch, the quicker your code will be, it's that simple.

oh... and no smart answers about being in a calculation loop with no memory access for a second - we're assuming you're not a moron. :)

Performance...

Here's a little quiz for you. Both of these issues have come up in conversation over the past week or so, and I thought it would be interesting to pose them, and give you the chance to prove your smarter that most games developers...

Question 1
Whats the main thing to tackle inside a program, that's virtually guaranteed to speed it up?

Question 2
When writing a game, whats the 2 most important things to make sure you do? (In order please)


The answer to both these questions should be obvious, but lets see how you do. I'll answer them in a couple of days...

Now... if you cast your mind back a few years, you'll remember me doing a fancy little routine for XeO3's bullet allocation. This was a simple "stack allocator" that sped up my code by quite a bit. Well, you can now find this article in the new Games Programming Gems 8 book. Yes, about a year ago I got the article accepted, and it's now in print and out. This is the 1st time I've decided to try and get an article published, but I thought it was about time. It takes the general concept a little further and uses it in standard programming (rather than 6502), and comes with a few little examples.

The only reason I mention this (aside from being chuffed that I finally got something published), is that this is one of the main reasons I still code old machines. Without writing XeO3, this would never have occurred to me. Old machine place unique limits on what you can do, limits that simple don't appear to be around anymore, and as such require you to think outside the box. They are still a valuable learning tool, and can lead to better code on a day-to-day basis. I've now used the Stack Allocator in several applications I've since written, and found it much simpler/quicker to implement than linked lists, not to mention easier to follow. I love how retro coding really can teach an old dog new tricks....

DMA Design - Now part of history.... apparently.

So a couple of years back the old museum in Dundee closed to get a well needed refurbishment, and while shut it got in touch with Realtime Worlds and asked for everything DMA that would could get our hands on. Now the museum is open again and it has a section based on local history, and a selection of the DMA stuff has been put on display. It's very odd seeing something that I've been intimately involved with appear in a museum! Particularly as (last time I checked), I'm not dead yet! But it's very cool to see DMA Design given the same kind of importance as Timex (who made the ZX Spectrum, right here in Dundee) and D.C. Thomson who...well.. own half of Dundee. There's also lots of stuff dealing with life sciences and the like, and to think that we've managed to influence Dundee's past enough to warrent a little display is very satisfying, not to mention a little cool.
The newly opened museum is pretty good, so if your in the area, you should pop in and see it