Archive for the ‘SYK15’ Category

Mike and Middleware

Monday, April 4th, 2011

I’ve been making games for a really long time now, but one thing I’ve found myself rather resilient to was letting myself use Middleware. By Middleware, I mean 3rd party libraries. It’s funny since I always highly recommend that people use it (to save RIDICULOUS amounts of time), but I myself am just a really slow adopter of it.

SDL is one of few long-time 3rd party libraries I use. It lets me write my game code against the PC, Mac, Linux, and a few mobiles including Palm/HP’s webOS and Nokia’s Maemo. It’s a bit of a black box to me though. I know it initializes OpenGL for me, does some crazy stuff to let me access keyboard and mouse events, but if it broke I wouldn’t know where to start. Stable SDL has unfortunately been stuck at version 1.2.14 for a very long time, and 1.3 has been unfinished and “coming soon” for just as long.

Fortunately this has finally changed, as Sam the lead developer of SDL left his cozy job at Blizzard and has been pushing the project forward like a maniac. I started to familiarize myself with some of SDL’s internals due to this renewed focus, but it’s still mostly a mystery box to me. I have my codebase working against both SDL 1.2 and 1.3 branches, and last I checked (late February) 1.3 nearly did everything it was supposed to. SDL’s former glory is nearly ready to be restored, so I’m certainly feeling better about using it. If I keep using it and reporting bugs, it’ll fix itself.

* * *

SDL_Mixer is an addon for SDL that l’ve always felt a little funny using, but it works (mostly). It provides a simple audio mixer (load an mix multiple sound effects) combined with a single track of music playback. In practice though, I ran in to multiple issues with the library. Music playback has various looping issues on numerous platforms. My Smiles for Windows builds would accumulate noise whenever a music track looped, and on webOS they would make a distinct glitch noise at the loop point. The latest Hg (Mercurial) versions seem better, but I think I demand more from my audio library nowadays than what SDL_Mixer offers. Plenty fine for Smiles, but not moving forward.

* * *

For my submission to Intel’s first contest (where I won the car), I licensed a piece of Middleware called IrrKlang. Irrklang is much better than SDL_Mixer when it comes to features (sounds can actually be pitched, and you can play multiple music streams). It’s actually a really good library, but unlike the SDL family it’s even more of a black box – an Indie license does-not get you source, just some .lib, .dll, .a, and .so files. I’m sure that works fine for many people (FMod candidates for example). It works flawlessly for me on Windows, but I personally found the Linux and Mac support to be less than ideal (leading me back to SDL_Mixer for both), but Phil swears by it. I recommend checking it out and trying for yourself – you wont find a better deal on capable sound Middleware (*sigh* FMod).

* * *

Today though I have my own sound mixing code. It developed out of necessity on platforms such as Windows Mobile 6.5 and Samsung’s Bada (both completely lacking in any useful audio playback). It supports pitched music and sound playback, some rough ADPCM compressed sound plackback support, and in my latest now adds a single track OGG decoder. I’m not silly enough to think what I have is actually flexible and user friendly (it’s not like I need to support it), but I can make it work on any device or platform that can make noise. In a way I do wish I could rely on a 3rd party audio library, but it seems my own needs grow more and more diverse every day.

I should probably mention, all my audio code is wrapped behind a simple API of mine. Loading a sound, playing a sound, playing a song, crossfading to a different song, etc. So adding/trying a new API (or even using my own) is a matter of writing a new implementation of the same interface.

* * *

On my watch-list is OpenAL. Earlier this year I was asked by fellow Cannucks Hemisphere Games to help port their hit game Osmos to Intel’s AppUp platform (well, asked late last year but did it this year). “Port” might be pushing it, as it was more “help us test and meet these weird packaging requirements that aren’t NSIS”. A couple days later we were in business. One of the particular concerns of theirs was making the default OpenAL driver install correctly through an .MSI installer. It’s been a couple months since I did this, so while I can’t actually recall what I actually did, I was able to make it work exactly as expected and remember it not being particularly too difficult (tricky, but not stupid).

I don’t run a consumer sound card anymore (at least not in my workstation), but the theory is that if you had one of the latest-and-greatest Creative cards, you’d have a 5.1 surround sound gaming thing going on. As a bit of a home theater buff, I am fascinated by surround sound. Up until I started using pro-audio gear on my workstation PC, I was using a surround capable Creative card with a 4.1 speaker setup. But as it turns out, surround sound setups aren’t all that common. Take in to consideration that the potential total games market includes all cellphones, all tablets, all portable gaming systems, all PC’s and all consoles, and only a fraction of the high end actually use it. So as much as I want to love and embrace the wonderful world of 5.1, what matters most is what I do in classic 2.0 Stereo. Still, lack of market-share isn’t going to stop me. I love crazy tech gizmos and gimmicks – after all, I’m a programmer, and that means I get to play with new toys. OpenAL is just a mixing API though. It provides a high level interface to place sound sources in a game world, and something to listen to them. It’s practically the standard (more like, only one left) on PC, but I don’t think that’s the case on Sony, and certainly not Microsoft (whom is allergic to anything with the word “Open” in it being the de-facto standard on its platforms). Still OpenAL seems a good reference point. I don’t have access to PlayStation 3 or Xbox 360 documentation, so I’m just going to have to assume Sony and Microsoft would do something similar (sources and listeners), and structure my new player frontend around that.

Anyways, enough on Audio.

* * *

Airplay SDK is a new one for me, but one I learned to appreciate more and more every time I use it. A bit over a week ago, I was working on the Nokia Symbian^3 port of Smiles for a contest, and honestly, I had enough. The toolchain is based on Eclipse, which I have to say, is one of the worst IDE’s for project management. I’m sure it works fine for a single project targeting a single platform, but it DOES NOT play nice in a situation where we need to target multiple different platforms using different API’s and schemes.

It was Wednesday evening, and I had decided that I was out. The whole process of getting a binary on to the phones was immensely clumsy, assuming you could make one that actually worked in the first place, and there was too much to learn about a platform that literally had an expiration date (April 1st). So I let out my expletives, poured myself some wine (I normally only drink to celebrate), and proceeded to wind down the port.

My post-project-frustration tweet was responded to by Dave, one of my favorite Ludum Dare long-time regulars (check out some of his cool prior games here). He said something that made me feel stupid.

No no, I couldn’t possibly do that! Middleware! Eww! What about my pride? I’m Mr crazy dude that ports to every platform himself! What would my mom say?

I began my response tweet as any pig-headed fool would, but paused as I tried to come up with the reason not to. I couldn’t think of one. I rushed to their website and combed the sales pitch and documentation for that one thing I could use to kill the idea. I couldn’t find it. In fact, all I could find were more and more reasons to actually switch. Damn it! *breathe*

Dave, Airplay, you win.

The one thing that I could not refute was Android support. My existing Android port has been sitting in a half state of completion for months, maybe years. I was finally making some notable progress early this year, but put it off for some other more important deadlines (things worth money and prizes). I still have code to write to properly support the awkward system of indexing a Jar file to get my assets.

My Android port, circa new-years day. All my ports look like this when they start (no texture title screen)

So okay. If I could get an Android port of Smiles running in just a few days on Airplay, I’d seriously consider using it for both the Android and the Symbian^3 port. 30 day trial go!

This glitchy reinterpretation was new. Cut-off S looks like a macaroni noodle.

Huh. Okay. So you’re working, and stuff. Then… uh… How about the full game, and make it work on Symbian^3 as well?

Select Android and Symbian^3 phones... and what I mean by select are just the phones I have

Airplay, you win.

Within 4 days I had my code running cleanly inside Airplay, with even my sound mixer hooked up to the audio interface. Music wasn’t working properly on Symbian^3, but I had a whole 3 days to spare now. Huh. So rather than having to explicitly remove the music mute & skip-track buttons, I crunched a day to get an OGG decoder working in my sound engine (STB Vorbis). And boy am I glad I did. I often forget how much the music really ads to the game. Wow I say.

So within a week, I have a fully working version of Smiles for both Symbian^3 and Android, the first already submitted to a very important Nokia contest, and the later nearly ready to be sent off to all the noteworthy Android App Stores. I did stumble across a bug in Airplay for Android, but after a short bug report, it’s now on schedule to be fixed in the update coming any day now. It feels kinda nice to have deferred a bug to someone else. I was able to take my weekend and do something for me (work on my new game), instead of painfully trying to fix bizarre compatibility problems. Ahh!

So I’m left feeling extremely positive about Airplay, too positive perhaps. With the Nokia stuff out of the way, I started thinking about relying on it more. I spent a good chunk of this past Friday getting my Airplay port working on iPhone, and as expected, it was very straightforward (given how tricky Apple-dev can be). I’ve had some wild ideas about doing some updates, adding retina/universal support and whatnot, but I just never had the time to do it. An afternoon with Airplay later, BLAM! There’s still a long list of subtle tweaks I need, but it’s there, working, and I don’t even need to turn on the Mac to test it. 😀

Long term, I’m strongly considering letting Airplay take care of my mobile platforms, with the one exception of webOS. They’re part of the SDL family, so I’d rather work with that directly, as I do now on the PC. But upcoming stuff like the Blackberry Playbook, yeah, go ahead and be my porting intermediary Airplay. Mmmm.

I see this as a pretty big step for me. My “thing” the past couple years has been me doing all the porting myself, and now I’m nearly ready to let someone else (indirectly) take over. The only version of Smiles (nearly) in a store that uses Airplay is the Symbian^3 version. That will be followed up with the Android version very soon, but everything else I did all myself. The iPhone, the iPad, the Netbooks, the webOS, the Windows Mobile 6.5, the Maemo, the few PC+Mac+Linux versions that are available, and the Windows Phone 7 version (which was a collaboration of sorts, but my code ported over to C#). And now I’m talking letting Middleware handle the platform specifics for me.

I think I’m okay with it.

If I need an instant port for some contest or “quick buck” opportunity, I’ll probably step in and do it myself as usual. But if time isn’t of concern, I can easy it.

I’m okay with it.

I’ve admittedly been in a bit of a rut with the Smiles porting. I *SO MUCH* want to be working on a new game now, as Smiles itself came out nearly two and a half years ago. Doing everything myself like I am, my time is precious. Given what I do and can do, I could easily stick a dollar amount on it that would make any employer cringe. But unless I’m enjoying myself, it can be hard to be motivated.

I’m okay with it, especially after this past weekend.

* * *

I’m evaluating 2 new pieces of Middleware now. Not so much evaluating though, as finally sitting down and testing if my “yes, I will use this” analysis was correct. Both are things I’m expecting will make development of my new game better and easier.

* * *

The first is a scripting language called Squirrel. Common wisdom in gamedev seems to be that one should use Lua for game scripting; It’s easier for “non coders” or something, I dunno. Well I’m a coder, and I am law. If I want my artists to learn to count from zero, so be it. Grah! Truth of the matter though, I’ll be doing most of the scripting on my upcoming game, and I only want to do things that will actually improve my workflow. The more C++ like my scripting dialect, the better. Making me count from 1 and switch back to Pascal’esc begin and ends sounds like I’m back in High School. My decade of game industry experience has earned me the right to be a cranky-old-man, so I’m going to force my will upon all those that work under me. Hurah!

That said, Squirrel is a lovely language. Contrary to some dated benchmarks, as of 3.0, Squirrel is now on par with Lua performance wise. Sure, all languages have their weaknesses (even Lua), but performance isn’t one of Squirrels anymore. Sure, Lua has some lightning fast JIT’s available to it, but not all architectures are JIT’able (ARM and PPC specifically… we might be able to forget about MIPS though). I want to throw a special thanks out to Pekka of Polygon Toys (and for the benchmarks. I was practically sold on Squirrel already, but his numbers have solidified my commitment to it.

My use of Squirrel, contrast to Pekka, is that I want to use it as a high level data modeling language (akin to XML, but with actual function). I plan to code my engine in C++ as I would normally, but assign all specialization and logic between game-things to the script. My initial test have been extremely encouraging, roughing out the hierarchies of an extremely flexible crafting and recipe system in a matter of hours (well, if you ignore all the pre-planning that went in to it). It makes me wish I was further along on other aspects of the game. 🙂

I should also mention, Pawn was on my short list as a “raw execution speed” scripting language. It’s terrible with strings, but appears a solid choice for something like particle effects. And it’s very tiny.

* * *

The final piece of Middleware on the table is Bullet, the physics+collision library. It’s still admittedly very early in my analysis of it, but I’ve been warming up to it.

Like Airplay, Bullet has been a difficult sell for me. As it turns out, I’m no slouch when it comes to physics programming. Me and 2D soft-body physics are like this [does some sort of finger cross gesture]. I didn’t code Box2d, but I’ve coded things like it… before it was cool. 😀 Heh okay, I’ll admit there’s certainly some bitterness left in me that I didn’t capitalize off my physics skillz back during the recent gimmick-game boom. I had my PuffBOMB HD getting good in 2007, but to me only Microsoft and Xbox 360 had the power back then. Whoda-thunk iPhone would have been a better home… [/bitter]

So what particularly attracts me to Bullet is that it’s more of a collection of components. The library is designed in such a way that you don’t even have to use physics, you could totally just use it for the extensive collection of collision tests. That’s right up my alley. I’ll probably end up using it like everyone else (for physics), but I do feel kinda good that I have options (get SOME use out of that latent game-physics knowledge). But anyways, it’s still early and I don’t know how intimately I can abuse it yet. Looks good though.

And that concludes my little Middleware rant, and what I’ve been thinking about these past couple weeks. On to my “April Fools” port, and a slew of submissions.

Time to crank it to… you get the idea

Tuesday, January 4th, 2011

2011 is here! The IGF finalists have been announced, CES is upon us, and GDC is less than 2 months away. I always have a hard time following up epic posts like the last one. So with this, my third attempt (ahem), I’m going to try to be more to the point: My plans for the year.

First, the Mac App Store launches on Thursday… I wonder if Mike did something for that? 😉

This month I’m aiming finish up the last of the “non console” ports. My long overdue Android port slipped well past December, but at least my PC versions are done (just waiting on distributors). Pending some spontaneous slacking, I should start rolling out Android ports in the coming weeks. Aside from that, there’s 1 more phone port I have left to do, and a not-phone port I’d really like to finish.

February, later in the month, I have a long overdue iOS update I’m planning. More than anything, I’m tired of attending conferences (GDC) where the device in my pocket (an iPod touch) lacks the latest and greatest version of the game (iPad has it, but doesn’t fit in my pocket). So yes, I have some sort of universal agenda on the cards, but we see which way I go.

Before that though, and assuming my January ports don’t cannibalize all of February, I’ll be spending some time on my new game. This past Ludum Dare, I took the weekend finally start a gameplay prototype of this game. I didn’t get too far, but my hope is to spend the month of February getting the basic game mechanics working, just so I have something with me at the Conference (I’ve been muttering far too long about this new game without anything to show).

Once I get back in March, and for the entirety of April… lets just call this period of time “console ports”. I’ve been putting these off far too long; It’s a shame submissions and approvals are so much more complicated (and costly) on consoles, but oh well.

And if all goes according to plan, starting in May, I’ll be focusing most of my time on the new game.

It’s a heavy amount of Smiles work for early in the year, but I am expecting the new game to take a while. I have some pretty crazy ambitions for this new game. My hope is to make IGF submission with a polished vertical slice and memorable teaser trailer. The new game wont be finished this year, and will be a major departure from Smiles and my prior games. I’m sure I’ll have more rants and raves about it in the coming months.

So Mike, what will you be doing?

I’ll be working to convince you that this is a game you must play:

I intentionally chose the ugliest recent screenshot, so when it finally starts looking good, we can A/B it showing how much better it looks. Mmmm... Yellow circle on green terrain.

For now, back to porting.

The Development of Smiles, Part 0

Friday, January 2nd, 2009

I know my track record for completing a blog series is pretty lousy, but this one should be easier. I kept a personal log with pictures during the development of Smiles, so most of the work is done for me. I just need need to go through it and regurgitate my notes.

To start, I’m going to give a bit of insight in to what happened when I stopped writing my Engines, Names and Evolution blog series last year.

I apologize, but I am going to skip a significant follow up to that series for now (the Hammer engine), but this series should bring us back up to date.

Here we go.

– – – – – – –

Late 2007 and early 2008 were spent working on libraries, and foundation for my new engine Playground.

Playground was the successor to Hammer (PuffBOMB HD… will talk about this another day), which in turn succeeded Freedom.

– – – – – – –

Before PuffBOMB HD was shelved in late 2007 (Hammer engine), I was working alone on the project. Amicably, but that’s a series for another day.

The core issue with Hammer is that it wasn’t very reusable. As a whole, you could certainly build a new project based on it, but it’s elements were poorly isolated. Triangulation and collision testing code was embedded right in to the physics engine, so I couldn’t use the same code elsewhere without a lot of waste.

I prototype games regularly, and the product of this year of development (2007) wasn’t as useful as it could be.

– – – – – – –

Late 2007, I was at a crossroads. I still had savings left, but only enough to support myself. I needed a break from PuffBOMB HD, so I coined a new project. A suite of libraries and tools I could personally use for prototyping and developing games faster and more efficiently. The end goal may have been to build a Metroidvania derivative, but the core of the project was to build me some tools. If the project was going to fail again, at least I’d have a foundation to try the next thing. This was the Playground project.

Here’s where I get technical.

As mentioned, Playground is a suite of libraries and tools. It started with me collecting what usable parts I could extract from Hammer, and my Ludum Dare games and framework.

I should also mention that by library I’m referring to an element. A directory of files. Either copy the directory in to a project, or set up an SVN External for it. Only a crazy person would compile their work in progress library to a .lib/.a file and install it. If that’s you, you’re crazy! 🙂

One of the first and most useful elements I built was the Data and Serialization library. I decided to finally stop using C++ streams for binary File I/O, but wanted my file reading syntax to be nicer than fopen. The syntax for loading an arbitrary binary file from disk is as follows.

DataBlock* MyData = new_DataBlock( “Data.bin” );

Nice and easy. A DataBlock is an incredibly useful and lightweight basic type. It represents an arbitrary block of memory with a size stored in the first 4 bytes. It’s defined as followed.

struct DataBlock {
    size_t Size;
    char Data[0];

Pretty simple. For completion, the Data and Serialization library includes similar calls for normal non DataBlock data, but they’re so lightweight and flexible I use them anyways.

The great part about writing your own I/O wrapper is you can seamlessly integrate things like compression, munging, CRC’s and checksums. For example, load and decompress a file in 3 lines (one cleanup).

DataBlock* Compressed = new_DataBlock( “CompressedFile.zlib” );
DataBlock* Uncompressed = unpack_ZLIB_DataBlock( Compressed );
delete_DataBlock( Compressed );

The library is also written in such a way that, while it supports many compressors/hash methods, they are not required to be built or linked against the project unless explicitly used. In other words, if I don’t use BZIP2, I don’t need the BZIP2 headers or C files. As lightweight as you can make a library.

The vector math library is borrowed right from Hammer, cleaned up and isolated to be vector, scalar, and matrix math only. Types for rectangles and simple primitives are a library. Coding niceties like template types containing a,b,c or r,g,b,a components are a library. Strings, parsing a whitespace delimited file, and debug console logging as well.

Collision tests, and everything you do between primitives is a library of functions. Extremely long names, but they’re now modular in such a way they can be used in a physics engine, in a primitives library or a GUI/Menu system.

if ( Test_Point_Vs_Polygon2D( ... ) ) ...

Where this one returns a boolean value. I wont bother listing the arguments, but it’s a global C-like function. It takes direct types and pointers where appropriate. The functions follow the form “Action_What_Relationship_Who( … );”. Action is the operation, What and Who are the terms being tested, and the Relationship is the rest of grammar required to describe the operation.

Nearest_Point_On_Chain2D( ... );
Nearest_CornerPoint_OnEdgeOf_Polygon3D( ... );

Where the Smiles story begins is the Grid library.

Grid was a library created for a Ludum Dare game Pillar Caterpillar.

Here’s some concept art.


Pillar Caterpillar wasn’t playable within the compo timeline. It however still featured some great pre-production work, and a useful chunk of code that became it’s own library in Playground. Further work was done on the project, but that mock-up is the coolest looking part.

For the time being, only minor changes were done to Grid.

– – – – – – –

Shortly after the iPhone SDK was official announced in March 2008, I started prototyping some game concepts. The first, Magtraction (since Magnetica was taken, by a game completely unrelated to magnets).


A prototyped game concept deemed “too boring“.

The second, Dungeon Legion.


A prototype game concept deemed “too awesome“. Too awesome to finish in a short period of time. 😀

Both of these prototypes were the projects used to get the geometry tests up and working again.

You might hear more about Pillar Caterpillar and/or Dungeon Legion in the coming months (both projects are on my list I’m considering).

For the 3rd prototype, I wanted to revisit Grid.