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

Update....

So, it's been sometime since I've posted anything and a lot has changed - well, for me at least. I've left Realtime Worlds after some long term disagreements with how the project I was on was being handled, but I wish them all the best and hope they make a go of it. All I can say about the project is that IF they manage to pull it off, then it's gonna be huge! Good luck to all involved, I spent 5 years of my life on it, so I'm still very keen to see it work.

Still onwards and upwards I guess. I'm currently on gardening leave from RTW and have just over a week left before my official end date. It's nice to be able to kick back and relax a bit, although I have been finishing off some freelance stuff I've been doing on the side. I hope this will be announced soon so I can start blogging a little more about it, because it's really interesting in its own right. With luck, I'll have things sorted out in a couple of weeks and everything will become clear.

Because of all this, my retro projects have obviously taken a back seat, and will remain so for some time to come; and the same goes for my electronics. I'd love to get back into them but I have bills to pay like everyone else so I have to concentrate on other things. I'd love to dabble back with my electronics in particular, but it's going to be a while before I can afford to do that again.

Anyways... I hope to announce some stuff in a couple of weeks, and with any luck, you'll all be interested in that as well!


Oh! And you can follow me on Twitter if you REALLY have no life and nothing else to do... I'm on there as MDF200 (which was my old Visual Sciences login ID!

The cool wall

Computers and Consoles
Seriously Uncool	Uncool	Cool	Sub-Zero
IBM PC Tatung Einstine Amiga CDTV New Brain Commodore16 Spectrum+ Vic 20 Oric / Atmos Philips CDi Konix 3DO TI99/4A IBM 360 C64gs TRS80 BBC Micro Amstrad GX4000 Amstrad PCW Sinclair Zx80 Altair 8800 Nintendo Virtual Boy Dragon 32/64 Philips Videopac Elan Enterprise PC 200 Sun Ultra Sun Sparc Mattell Aquarius Cambridge Z88	FM Towns Plus/4 Commodore 116 Atari 400/800/1200xl/130XE/65XE Amiga CD32 Amiga 2000 Amiga 4000 Atari 2800 Atari ST Spectrum 16k/+2/128 Commodore 128 / 128D SAM Coupé Commodore Pet Atari Jaguar Sega Saturn Nintendo Game Cube Atari Lynx Sinclair ZX81 Nuon Acorn Electron Acorn Atom Amstrad CPC MSX Archimedes XBox Sinclair QL Playstation 3 Gameboy Advance PDP 8 Dec Vax PSP NeoGeo Pocket Commodore 64sx Vectrex Nintendo Nes Sega Master System	Atari 2600 Amiga 1000 Amiga 3000 Amstrad 6128 Plus Cray PC Engine Megadrive NeXT NeoGeo Mac Thinking Machine Nintendo DS Playstation XBox360 Dreamcast SGI Workstations N64	Magnavox Odyssey Pong Sinclair Spectrum 48k/+3 Commodore 64 Apple II+ Colecovision SNES Playstation2 Amiga 500 Amiga 1200 Gameboy Wii

A little while back the members of our team during a week of coffee breaks came up with the following cool wall. It was a hard fought list with many arguments about the virtue of each machine, but in the end we had our definitive list of old machines. Fans of TopGear will know all about the cool wall, and know it's nothing to do with how good anything is - just that it's cool or not. So heres our list... let battle commence!

Now remember... it's how COOL they were, not how useful, or powerful. The Plus/4 is a great little machine, but I'm not gonna pretend its cool. Also machines like the Amiga 4000 were awesome! But too expensive to be cool. So there you go - thats the rules.