It's been a while since I last posted (I believe its been about 8 months), but I've been incredibly busy. I've been recently working on a game, due out on WiiWare and PC something in Q1 2010, called Super Meat Boy. For those interested, you can find a trailer here:

Super Meat Boy Trailer

I just recently got back from an event in London showcasing Super Meat Boy at a Nintendo WiiWare event. It was great fun, the game went over well and we are very excited. But blah blah blah lets talk some tech about this meaty game (get it?).

The engine for Super Meat Boy has very much been a labor of love. The game is being developed mainly on two machines, an Intel Core 2 Duo 2.16Ghz housed in my (seemingly soon to be dead) laptop and a Intel Core 2 Quad 2.4Ghz desktop. 100% of the development is being done on these two PCs with the engine constructed in such a way that I link in drivers for different renders, input, core, and audio functionality. So far this method of engine design has worked out perfectly. Each module is abstracted out away from engine and game code and is placed in a seperate library. When I need a Wii Build, I link in my Wii libraries and poof, I have a Wii Build. Same with Xbox, PC, etc, etc, etc. This isn't that special really, its actually pretty standard. The specialness of this is due to the threading library I originally wrote for Goo!. Super Meat Boy runs on the second generation Goo! engine that features a self detecting threaded renderer...which is just fancy talk for a threaded renderer that does a little bit of a system test on your machine to determine if A. If it can thread it (i.e. is the processor multicore) and B. If it should thread it (i.e. Is the processor fast enough, is the processing power required by the renderer worth threading the rendering). So far it works very well....it even runs well on my little Acer Aspire One with a little Intel GMA 950 and a 1.6Ghz Atom Processor. It threads the renderer on that little thing and it does surprisingly well...I was impressed. On a machine where it should run a threaded renderer (My Core 2 Quad or Duo or the Xbox 360) it sets up the render threads on its own and goes to town, where on lower end PCs and the Wii, it doesn't need to thread the renderer so it doesn't. It makes my life easier and it utilizes the processors in a users machine, be it console or PC, to provide a nice, smooth gaming experience. The game runs beautifully at 1920x1440...which again, isn't saying too much for a game like Super Meat Boy, as it is a 2D platformer with some pretty lights and replays...but its scalable and that's what makes it special.

Right now, on the Wii in particular, I'm working on doing some threaded level loading, because I'm not a fan of load times, and neither are gamers. With a game like Super Meat Boy, you die often and you beat levels often, so even the slightest amount of wait is just a pain for gamers. Right now, the load time between levels is I believe is less than half a second, but I don't like that it pauses. So, what I'm doing is loading level A and when level A is loaded, I'll fire up a thread that starts the loading of Level B in the background on a very very low priority thread. Since the average level for a pro (like myself) takes anywhere between 5 and 10 seconds (again, I'm very pro, most new players will spend between 10 to 20 seconds on easy levels, and probably about 10 minutes on harder levels...this is how it happened in London anyway:)) to play through, this huge amount of time in between levels will allow plenty of processor time for a low priority thread to load the level in and be able to instantly switch to the new level in between level transitions, while then firing up another thread to load the next level. The system will work just fine, and we'll be blessed with the gift of little to no load times...that's something that we haven't had since the days of cartridge based games:)

That's it for me now, I must sleep, then get back to work. If you're interested in more game engine threading and design, shoot me an email. If you want to keep up with Super Meat Boy, follow us on twitter: http://twitter.com/SuperMeatBoy.

Good Night!!!!

Tommy

I'm in Santa Cruz these days working in the Cryptic Sea offices (Gish, BlastMiner) on Super MeatBoy and another secret project that I hope to be able to announce soon. The cross platform crazy engine I'm doing for Meatboy is coming along well. After doing extensive reading on how the Wii GPU does texture tiling and how it accesses texture memory I now have a cool texture and material system that is totally cross platform. That might not sound like much, but going from a PC/DirectX powered game to a Wii/OpenGLesque game with a recompile isn't an easy task. Right now I'm in the process of converting the graphics pipeline from 100% shader driven (I'm all directX) to something that can transfer to either a fixed function pipeline, like Wii or iPhone, or shader driven, like PS3, Xbox, and PC. I feel this should be basically done by the end of the week, with further improvements to be built in as I need them. The goal is to have all of the flexibility to create a game like Goo! on PC and Xbox, but still be able to make a more simple game, like Meatboy, and port it to all platforms by replacing system files, input, sound, and graphics drivers. So far, I'm winning:)

Speaking of Winning, I made a really really stupid fun game. It's called Free Money* Scratch n' Win and its on the AppStore for $0.99. The purpose of this game is to make people laugh as its a totally stupid lottery scratch off simulator. I did all the voices and put the most appropriate music to it that I could find. Give it a go, you'll laugh..and that's really all I'm going for:)

Free Money*: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=305612915&mt=8

I'll post again in a few weeks with maybe some Meatboy videos...maybe not. We'll just see how it goes! In the coming months I will be creating Tools for the engine, Flash exporters, texture tools, etc and I plan to talk a lot about that. Hopefully I'll be able to talk about the other project which is a much more technical project that can give some insights into threading on some next gen consoles.

Tommy

I've recently been hard at work on a few projects. One being an iPhone game, and another being a Wii game. First I'll touch on the iPhone (pun totally intended).

The iPhone game I have been working on is called Beat!. Beat! is basically Simon mixed with a random beat generator with a custom dynamic sound track and some neat sorta retro looking visuals. As the player progresses in the game, the sound track gets more and more intense. All in all its a pretty simple game but at one point it had a pretty complicated back end to it. I ported most of my engine over to the iPhone to help with this game. My main concern were the memory limitations presented by the iPhone, and with the dynamic sound track the game I was afraid of having (and did initially run into) memory issues. The first iteration of this game had a threaded music loading system. Basically as the user played, the next level of intensity would load into memory on a separate thread and when it was time to play the next level of intensity the current level would unload while the new one played. This took up at most 3 to 5MB of memory and provided a seamless transition from level to level. When being done all on one thread, there would be a very brief pause as one sound unloaded and another one loaded and played. However, there were some problems with the sound engine properly unloading sounds and I eventually had the sounds converted down to 32Khz and shortened their duration and ended up loading them into memory. I wanted to have a cool threaded loading system I could gloat about, and for a time I did but it just wasn't meant to be. I plan on exploring more threading options on the iPhone in the future, but I was generally impressed with the amount of load it could take. If you want to check the game out its called "Beat!" and its available on the iTunes store here. 

The official site for Beat! is here http://beat.pillowfortgames.com 

In other news I'm working with Edmund McMillen on Super Meat Boy which is a game for the Wii (http://www.supermeatboy.com). Super Meat Boy is a platforming game where you control a little cube of meat trying to save his girlfriend. It sounds cute, but it is a very difficult and satisfying game to play. SMB won't be a difficult game to develop, there's no crazy threading that will go on, maybe a bit of resource management but nothing too spectacular. SMB is kind of a cleansing game for me to develop since Goo! is a difficult and (at this point) tiring game to work on. SMB on the Wii gives me the opportunity to not only port the engine that powers Goo! over to the Wii, but also it gives me a unique opportunity to determine if Goo! can possibly run on the hardware. My initial stance is, no, it won't, but as I delve further into development I'm going to keep exploring the capabilities of the Wii. So far I'm impressed with the processor, it's pretty powerful for not being a totally top of the line latest and greatest processor like in the 360 and in the PS3. The biggest challenge in porting my engine over to the Wii for Super Meat Boy is the graphics pipeline. I never thought I'd be developing anything for the Wii, so I went with a totally shader driven graphics pipeline. Wii is Fixed Function all the way, so there are going to be some challenges along the way, but this again will prove to be a huge disadvantage in getting Goo! up and running on a Wii since it's pretty heavily shader driven. We'll see though.

Speaking of Goo!, development is sort of on hold as I'm waiting to see what the future will be. Right now there are some promising leads and if something pans out I will post here. Hopefully I'll know something in the next few weeks.

That about does it, I'll post more when more stuff comes up!

Currently, and for the last couple of years on and off, I've been working on a game called Goo!. Goo! is a game where you control a big glob of goo and try to eat other goos while avoiding and fighting against an ever changing environment. Goo! is a highly technical game that earned a nomination in Technical Excellence at the 2008 IGF awards, took the grand prize in the 2008 Intel Game Demo contest for Best Threaded Game and placed 3rd for Best Game on Intel Graphics. I'm trying to get the game done and have it released sometime next year so we'll see. You can see some screenshots and videos here:

http://goo.pillowfortgames.com

Right now I have taken the demo down as I'm converting the game to my new and final engine, but it will be back up soon. I'm also working on a handful of other projects while doing this...so I'm a pretty busy guy.

That's basically it. Despite the extreme business, I'm usually good about responding to emails and comments...so anything you want to ask just throw it at me. If it isn't stupid, I'm sure you'll get an email back.

Something clever,

Tommy