Archive for the 'Video Games' Category

My Own Footsteps

Sunday, December 18th, 2011

Ludum Dare is a periodically held competition to make a game in 48 hours. For this weekend’s Ludum Dare (theme: “Alone”), I waited until the last minute, started a game Sunday morning, and over about seven hours banged out the first and only 3D game I have ever made. It’s called My Own Footsteps and sound is recommended.

Thanks to amon26, Mark and Stephen for playtesting.

You can find the Ludum Dare competition entry page for the game here.


Saturday, October 15th, 2011

Found out yesterday that (1) a group of indie games folk are crashing the IGF with a “pirate cart” of over a hundred indie games, and (2) Klik of the Month Club is doing a competition today with the theme “violate Atari’s intellectual property”. Of course I had to do something, so I made this little 2-player game. I started it last night at about 10:30, and finished it this afternoon at about 2:30. So that would be about 16 hours, some of it spent sleeping.

It’s like pong, but with more pong.


Playing with sound is recommended.

You Don’t Fit

Sunday, August 21st, 2011

Here is a video game I made in 48 hours for the Ludum Dare competition. It is called You Don’t Fit.


You can find the Ludum Dare competition entry page for the game here.

Thanks to everyone who playtested, especially Kevin, Alice, and Yakul.

By the way: This game supports user-created levels using Inkscape. Check the comments below for instructions on how to do this.

Polycode (and some things I did with it)

Monday, July 18th, 2011

So a month or two ago, indie developer Ivan Safrin released a game engine called Polycode. Ivan has been working on Polycode for several years and has been using it as the secret ingredient in some of his game releases, like TigSource Assemblee winner BitWorld. I took a look at the released version and was very impressed with it; it actually elegantly solves several problems I’ve been facing. I’m now developing a project against Polycode and also working on adding a few small features to it.


  • Some thoughts on Polycode
  • My efforts to port Polycode to MinGW (with code)
  • A tiny “getting started with Polycode”
  • What I’d like to do with Polycode next

Some thoughts on Polycode

Polycode is a top-to-bottom game library/engine/platform using C++ and LUA, like pixeltoaster. You can quickly develop a game just by writing game logic, and you can compile what you’ve got for Mac, Windows and Linux (and iPhone may work soon). Polycode differs from something like SDL or SFML in that it is a much more complete solution: instead of just sort of setting up a drawing surface and saying “have fun!”, Polycode can handle everything from asset loading to physics– you don’t need to know anything about making a game going in. At the other end, Polycode differs from Unity or GameMaker by being a little less complete– there is nothing like a level editor or integrated IDE yet, for example. (However, Polycode benefits in my view from having a good balanced view of “what you really need”– unlike Unity, Ogre or Panda, Polycode doesn’t either force you to learn some huge framework, or produce bloated executables full of functionality you’re not using.) Polycode also offers a step up from some of its more exact equivalencies, like Cocos or Löve, by supporting both 2D and 3D.

If you’ve been reading this blog, you may know I myself made a game engine called Jumpcore. Polycode does some things similarly; aside from some major features Polycode has and Jumpcore doesn’t even attempt (archive management, 3D physics), the main difference is that Jumpcore is much more minimal in its style. For example while Polycode and Jumpcore each bundle, say, TinyXML and a physics engine, Jumpcore just sort of leaves those libraries as exposed metal and expects you to use TinyXML directly. Polycode offers wrappers for things like physics, xml loading and graphics, and expects you to use these. This may be an advantage from Jumpcore’s perspective because it makes Jumpcore very easy to port, and because it means someone who wants to write “their own engine” can use Jumpcore just as a handy porting library while having complete freedom to design their own structures. However, I do not think this is much of an advantage because Polycode is already catching up with Jumpcore in terms of supported architectures (and doing so without using SDL as a crutch everywhere, as Jumpcore does) and meanwhile, although Polycode does make you do things “Polycode’s way”, it seems from my initial use of it to be extensible enough that you can take the wheel away from Polycode when appropriate. It probably makes more sense to, for example, use something like Polycode’s default display objects and make customized objects when you really need to, than to have to write your own OpenGL for everything from HUD display on up from the start (as Jumpcore makes you do).

The one big unique thing about Polycode is its ground-up LUA integration. When you use Polycode, you have a choice out of the box of which of two languages to use: C++ or LUA. LUA is a “scripting” language, like Python or Flash ActionScript. Polycode lets you write a whole game in LUA, and you get the exact same API C++ users do. (The one thing that interests me most about Polycode, and I’ll have more to say about this later, is the possibility of writing a game partially in LUA and partially in C++, something I think Polycode may make unusually easy).

My efforts to port Polycode to MinGW

So, how do you use Polycode? This bit is a bit trickier; Polycode is very new, and getting it working may be a bit fiddly.

When I made Jumpcore, I had a daydream: I should be able to write exactly one piece of software code, compile it three times from my same computer, and have Mac, Windows and Linux versions ready to upload– maybe mobile versions also. Polycode, in the form currently distributed, isn’t quite there yet: There are Windows, Mac, and Linux versions of the SDK, and each comes with a sample project, but there’s not a package on the Polycode site that combines all the platforms into one thing. Meanwhile, since each SDK uses native build systems (XCode on Mac, MSVC on Windows, make on Linux) you need to have a version of each operating system in order to build for all platforms. Ivan says he does his builds with Parallels, which probably does make things easy. I however don’t have a copy of Windows, so I decided to do things the difficult way. (This is the C++ version I’m talking about, of course; the LUA version as I understand requires no compiling at all to make an executable.)

The first problem– no combined sample project– is easy enough to fix. The second problem I had to do some work to get around. My solution was to just build the Linux version for Windows using MinGW. (MinGW is a GCC compiler that emits Windows .exe’s– and MinGW, conveniently, can be run on a Macintosh.) Since the Linux version is based on SDL, this approach works fine. However, it meant some setup in terms of rebuilding the Polycode libraries to work with MinGW. The MinGW-compatible version of Polycode I wound up with can be found at my fork on Github (Update 9-21-11: This URL moved, so I updated the URL.)– but that’s the source, which you probably don’t want, you want the libraries you can actually compile against. So if you want to use Polycode for MinGW, what you want to download is:

  1. This archive I made containing MinGW versions of everything you need to build a Polycode game
  2. This sample project (I’ll zlib license this at some point)

The #1 “archive” I mention above is a Linux-style directory hierarchy containing an include/, lib/ etc. In order to use it, you’ll have to set some environment variables.

A tiny “getting started with Polycode” (my way)

Here is what I do to compile my template project– on Mac, remember, although the MinGW process I describe below will actually work on Windows also if you’ve installed MinGW and MSYS.

Before doing anything, enter “Template/Xcode Template” in the example project and run Then:

To compile a Mac version: Look under “Template/Xcode Template”, open PolycodeTemplate.xcodeproj. You should be able to just build from there.

To compile a Windows version:

  1. Download and install MinGW 4.3.0 from here.
  2. Download and unpack the “everything you need” archive above; take note of the path it unpacks to, it will be something like “/Users/mcc/Downloads/Winroot”.
  3. In the sample project, go into “Template/winbuild”. You’ll need to set the location of the Winroot directory into the $POLYROOT variable by saying something like:
    export POLYROOT=/Users/mcc/Downloads/Winroot
  4. make

That’s it (and if anyone tries this and has problems, let me know). You should be able to make a linux makefile pretty easily from modifying the Makefile in the winbuild directory, but I have not done this yet.

What I’d like to do with Polycode next

There are a few things I’d like to see happen with Polycode, and may take a crack at myself if no one else gets to them first.

  • I think the Mac version should be packaged as a framework. This would simplify project setup considerably.
  • My MinGW version has some issues with file size. It requires way more DLLs than it seems like it should– ideally everything would be static, really.
  • Similarly, my MinGW version shouldn’t depend on SDL, it should be possible to build the full-native Windows version using MinGW.
  • With both the Polycode core libraries themselves and projects based on Polycode, it would be nice if the per-platform build systems were better integrated with one another. Bitshifter is working on a cmake based build system that may help with this.
  • With Polycode in general, there seem (?) to be some issues on machines that don’t support shaders.
  • At the moment, there’s no way in Polycode to use the current screen resolution when making a full screen window; cross-platform methods for getting screen height, screen width, and screen refresh rate are needed (Ivan says he’s planning to handle this himself)
  • Vsync needed badly
  • Lots more documentation is needed– there’s lots of features in Polycode I’ve yet to determine if they’re adequate for my needs because I haven’t yet worked out how they’re used. In particular, we need some docs on how to extend Polycode. (On that note, if I wrote a “how to build Polycore” document would anyone read it?)
  • And here’s my big one:

As I mentioned, I want to be able to mix LUA and C++ in a single program. Some of this may be my personal preferences, but I’m increasingly frustrated by the fact that different stages of the game development process seem more suited for different languages, and so regardless of which language I pick I wind up frustrated at some point. If I’m implementing a complex graphical effect, or some sort of complex technical feature, then I really want to be writing C++; C++ is what I’m comfortable with, it lets me optimize and do low-level stuff easily. Parsing a PNG in LUA, say, sounds dreadfully unpleasant. On the other hand if I’m trying to lay out elements in an HUD, or design the AI behavior of some small enemy or object, C++ becomes an incredible burden; these kinds of things involve a lot of test, tweak, test, tweak, and with C++ this means an iteration cycle of maybe a minute because I have to restart the whole program and recompile just to change one thing. Meanwhile I’ve been experimenting with ActionScript lately, and with that I’ve had the opposite problem; rapidly prototyping “game logic” is an easy, lovely experience, but doing something like optimizing a display routine is a nightmare.

There are maybe ways around this problem, I could figure out this stupid “Fix and Continue” feature in XCode or shove lots more stuff into XML than I’m currently shoving but… to me, the simple solution would be to write basic engine stuff in C++, “game logic” in LUA (or some other LUA/Javascript/Python like language), and then on top of that maybe even have a LUA console while the program is running so I can mess with stuff and try out different things without having to restart the program at all. This is of course the sort of thing LUA is built for– it’s meant to be embedded– but there’s a good bit of work in getting it into your project, you have to set up bindings and all this stuff.

Polycode looks to me like a great shortcut on this– bindings for all the “API” stuff have already been created, so LUA code can act as a first-class citizen and not have to go through the C++ code to do everything– and it comes with a C++ auto-binding script (one of several that exist for LUA). The only problem is that although it’s doable in theory, Polycode is not set up to do this sort of thing yet. What’s currently being distributed is a “core” library that C++ stuff hooks into, and a separate project called “PolycodePlayer” which is used to run LUA-based Polycode games (the idea is that the player app loads in a Polycode “file” containing LUA scripts and resources); all the LUA integration lives in PolycodePlayer. Probably my biggest personal goal with Polycode is to try to see PolycodePlayer functionality migrated into a game project.


Monday, May 16th, 2011

This is a little music toy I made for PCs and mobile phones.

Download (version 1.0.1)

What is it?

    Drumcircle is a radial drum machine: you place tiles corresponding to notes or drum samples, and they play as the clock hand sweeps past them. An internet-play mode lets you collaborate on drum patterns online with other users of the program. I’m really happy with how this turned out– making drum patterns with the tiles just feels really natural and intuitive, especially on the tablet versions.

    Drumcircle includes icon art by Mike LeMieux and 27 different sample voices out of the box.

Sample packs

    The PC version of Drumcircle lets you add your own samples. Download this thing for more information.

Update 6/28

Someone made this youtube video of themselves using Drumcircle and it is awesome.

Source code for Jumpman, iJumpman, and The Snap

Tuesday, May 10th, 2011

I have just released the source code to my games, because why not.

The source code for Jumpman and iJumpman can be found here.

The source code for The Snap can be found here.

The code, art and music is available under the Creative Commons “Attribution-NonCommercial 3.0 Unported” license, which means it is free to use for noncommercial use as long as you credit the original creators. You can find more information about this at the Bitbucket pages. (If you find this license too restrictive, I suggest checking out Jumpcore instead.) Both games were created in C++.

Thanks to everyone who played these games, and if anyone finds the source useful, I’d be curious to hear about it!

Jumpcore 2

Sunday, April 3rd, 2011

Short version: Here’s an MIT-licensed open source C++ game framework that lets you write your game once and immediately have it run on Mac, Windows, Linux, iPhone, WebOS and Android 2.3. It packages together all the basic libraries you need to get started with writing a game, and makes mobile porting easy by abstracting away the incompatibilities between OpenGL, OpenGL ES 1.0, and OpenGL ES 2.0.

The project is hosted on Bitbucket, so you can download the source yourself by doing one of the following:

  • hg clone
  • svn co
  • Visit the Bitbucket page and click “get source” in the upper right corner.

Here’s a little physics demo that comes with Jumpcore, shown running on PC, iPhone, and Android:

Long version: When I first started writing C++ games a few years ago, I quickly discovered that there was a lot of stuff that you really need in order to write a game but which SDL+OpenGL don’t provide out of the box– things like text display, or build scripts for a crossplatform binary. So once I’d actually finished my game, I decided to package up the basic skeleton of my game into the thing I wished had existed when I started coding games– a package to serve as a bridge between “there exist cross-platform game libraries in the world” and “I can actually sit down and create a game in C++”. Once I’d put this package together, I found it useful myself for rapidly prototyping new game ideas. I released this a year or so ago as “Jumpcore”, with support for Mac, Windows and Linux; what I can announce today is a new version that adds support for mobile platforms (iPhone and Android). I’ve also set up a project on BitBucket; what I would like is if this could grow into something like a free and open-source version of Airplay SDK, or a stripped-down Unity.

Jumpcore is minimal; it tries to set things up for you and then get out of the way, allowing you to develop your own “engine” as you see fit. Most of the functionality is provided by a selection of open source libraries I’ve bundled in. Jumpcore comes with:

– SDL and GLee for event and window handling (on desktop platforms)
Chipmunk version 5.3.4 (2D physics engine)
– A modified FTGL ES (freetype text display library) with OpenGL ES 2.0 support
– TinyXML
– LodePNG, and a simple texture loader based on LodePNG
– A generator and loader for texture atlases based on a script by Retro Affect
– Pthreads for win32

Included code unique to Jumpcore includes:

– A simple GUI interface library (based on Chipmunk spatial hashes)
– Event wrappers unifying SDL mouse events with iPhone and Android touch events
– Wrappers for getting the paths of “internal” files
– A set of OpenGL wrappers that abstract away the differences between OpenGL, OpenGL ES 1.0, and OpenGL ES 2.0, meaning you can write your OpenGL code on mobile platforms the same way you write it on desktop platforms.

Getting started

Developing with Jumpcore basically just means implementing a few simple callbacks. You can find quick instructions and links documenting all the functions in the included libraries at the Getting Started page on the BitBucket wiki.


Jumpcore uses GCC on all platforms, however you will need a different version of GCC (XCode, mingw, etc) to compile each of the different targets. You can compile all five targets on one machine as long as that one machine is a Macintosh (Linux and Windows users may need to find a mac before they can compile for Mac and iPhone). You can find detailed build instructions at the How to Build page on the BitBucket wiki.

Caveats and future development

Jumpcore is a work in progress; as I mentioned this is the base I use for starting new projects, so I should be improving it as my main projects continue. For a list of known gotchas and things yet to be done, please see the TODO page, again on the BitBucket wiki. Note: Some of the limitations in this initial release of Jumpcore 2 are quite serious, particularly on the Android version, so you should probably read this page.

If you have problems compiling this or getting it to work, please do let me know. Thanks!

The Snap

Monday, February 28th, 2011

A first person shooter

Download (1.0, r219)

How to Play

    The Snap is a two-player deathmatch shooter with time travel. Time in the Snap arena takes place in a loop. 20 seconds or so after the start of each game, the events of the game will begin to repeat themselves. You can also jump back in time by about five seconds or so by performing a Snap.

    If you interact with the past, you will change the present. If you shoot someone in the past, you will damage them in the present. If you block a bullet in the past, thus preventing someone from getting hit by that bullet, damage in the present will be undone.

    For best results, I suggest using a gamepad with analog thumbsticks (you can fit both players on one gamepad if you try!); also, since the game uses stereo sound with the sounds “heard” by one player going to each ear, I suggest plugging in a pair of earbuds and giving each player one earbud.

    10 levels are included, and you can make your own; if anyone tries out the custom levels feature, please do post below and let me know.

Future development?

    This a prototype of sorts, created in 40 days for the Tigsource Versus competition. I’d be interested in making a more complex game with more complex environments and online play (maybe a “real” first person shooter or a 2D platformer with free-aiming guns) using the time engine someday. Is there interest in this?

The Snap, development log: Day 38

Sunday, February 27th, 2011

Mac build (r212)
Windows build (r212)

Status: Added select-screen “previews” to the levels that didn’t have them or where they had them but they looked wrong. Fixed a bunch of visual and controls glitching. Finally got to do some playtests and concluded that just literally no one notices the subtle glow that the “you are controlling this character” characters get, and the game is simply not playable if you can’t follow which square you’re controlling. Gave in, said SCREW AESTHETIC PURITY and put big ugly smiley faces on the character you’re controlling. If you can’t keep track of who you’re controlling now, there is nothing more I can do for you. Oh, and I gave the game an icon.

This will be the last update of this type, my post tomorrow will be my final submission to the compo. I don’t expect any further changes except a linux version and maybe a kill screen if OpenGL 2 is not present– I’m hoping to spend my time tomorrow doing as little coding as possible and ideally making, like. A HOW TO PLAY graphic or something.

I hope you have enjoyed this little 39-day tour of a creative process; maybe I will try this again sometime. Thanks for reading, and please remember to return your 3D glasses in the designated bins on the way out.

The Snap, development log: Day 37

Saturday, February 26th, 2011

Mac build (r199)
Windows build (r199)

Status: Rushed one last feature in: Health drops. At periodic intervals, if the level is set up for it, there will be a flash in the time bar up top indicating a health container has just appeared somewhere on the timeline. If you get the health container, you restore some health. The health container is subject to the ravages of time travel like anything else in this game, so if you get a health container, and then the other player goes back in time and gets it first, the extra health is deducted from your bar and transferred to the other player.

The original idea with the health/ammo drops was, since the incentive is to grab them as close as possible to the moment where they spawn (to prevent someone else from retroactively grabbing it “first”), as soon as one appears on the timeline it should create a race across time where all the players dash to jump back to the point where the spawn was marked to occur. The health/ammo drops were supposed to be an incentive to move around the timeline and the map, and create interesting “moments” in time, instead of just plodding forward in normal time or camping near time 0 around the other player’s spawn point. However as things have developed I don’t think the health drops are enough of an incentive for them to really change the game much– play just moves too quickly in this prototype, and picking up the health packs is mostly extraneous to winning (if I got ammo drops in, there were going to be levels where taking advantage of the ammo drops was required because you actually just weren’t given enough bullets to kill the other player without reloading at least once). So you probably are better off just ignoring the ammo drops. However maybe this will give some sort of sense of how things might work in a slightly more complex version of this game.

In the end I put health drops in exactly one level, and stuck it at the end of the list with the other “experimental” levels.