Mechanically Separated Meat

CLICK HERE TO JUMP TO THE PRETTY COLOR-CODED FULL RESULTS

This explanation will look a lot like that of previous years, but:

Every year since 2004 I’ve been hosting this Game of the Year poll for the users of some forums I read. There are a lot of GOTY polls out there, but this one I think is kind of special. Most polls, you’re given a list of four or five options and you’re asked to pick the one you liked best. This poll, people are given a list of a couple of hundred options, consisting of every new game released in the previous year– and asked to rate their top ten or twenty.

This does a few interesting things. First off, we get to see all the information about what people’s second, third etc choices are. Second off, because the second, third etc choices count, people are more likely to vote for the game they want to win, rather than the game they think is likely to win– they’re less likely to engage in “strategic voting”. Finally, because we have all this information, we’re actually able to provide somewhat reasonable rankings for something like the top hundred or so games of last year.

The full results– showing the exact number of voters who ranked each game first, second, third place etc– can be found here. In the meantime, the final results were:

1. Portal 2 (6571) *** GAME OF THE YEAR ***
2. The Elder Scrolls V: Skyrim (6253)
3. Deus Ex: Human Revolution (4234)
4. Batman: Arkham City (4134)
5. Bastion (4094)
6. Saints Row: The Third (2547)
7. The Legend of Zelda: Skyward Sword (2126)
8. Battlefield 3 (2071)
9. Dark Souls (2034)
10. Dead Space 2 (1681)
11. L.A. Noire (1639)
12. The Witcher 2: Assassins of Kings (1515)
13. Star Wars: The Old Republic (1505)
14. Gears of War 3 (1447)
15. Terraria (1421)
16. Dragon Age II (1411)
17. Super Mario 3D Land (1261)
18. Pokemon Black & White (1255)
19. Ghost Trick: Phantom Detective (1170)
20. The Binding of Isaac (1164)

The numbers in parentheses are the final scores each game got under the poll’s ranking system. Thanks if you voted, and some more elaborate analysis of the results (plus an explanation of the scores) can be found below.

NOTEWORTHY WINNERS

• GOTY 2011:
  

  #1, Portal 2

• Top-ranked Wii Exclusive:
  

  #7, The Legend of Zelda: Skyward Sword

• Top-ranked PC Exclusive:
  

  #12, The Witcher 2: Assassins of Kings

• Top-ranked 360 Exclusive:
  

  #14, Gears of War 3

• Top-ranked 3DS Exclusive:
  

  #17, Super Mario 3D Land

• Top-ranked DS Exclusive:
  

  #18, Pokemon Black & White

• Top-ranked PS3 Exclusive:
  

  #21, Uncharted 3: Drake’s Deception

• Top-ranked smartphone game:
  

  #24, SpaceChem

• Top-ranked smartphone exclusive:
  

  #48, Jetpack Joyride

• Top-ranked PSP Exclusive:
  

  #45, Tactics Ogre: Let Us Cling Together

• Best FPS:
  

  #1, Portal 2

• Best RPG:
  

  #2, The Elder Scrolls V: Skyrim

• Best “Indie” Game:
  

  #5, Bastion

• Best Game Available Through A Console Download Service:
  

  #5, Bastion

• “Cult” Award (see below):
  

  #42, Dungeon Siege 3

• Best Browser Game:
  

  #103, Escape from Puppy Death Factory

NOTEWORTHY LOSERS

• Best game of 2011 which somehow nobody considered to be their #1 pick: #23, Magicka
• Worst game of 2011 that at least one person considered their #1 pick: #215, Stronghold 3
• Worst game of 2011: An incredible three-way tie between #251, Rugby Challenge; #252, “Leedmees” (??) and #253, Fishing Resort for Wii. (Each of these games scored only one vote each, each from someone who considered it their 19th best game of the year.)

There were 22 games on the nominations list no one voted for at all.

ALTERNATE SCORING METHODS

The rankings listed above are based on a version of the Borda count voting method. Each vote cast for a game gives that game a certain number of points. If someone ranks a game #1, that game gets 20 points. If they rank it #2, the game gets 19 points. If they rank it #3 the game gets 18 points… and so on. I have a script that checks a couple of alternate ways of ranking the same data, though.

For example, if we rank games only by the number of first place votes they got, we get a wildly different list, with a different first place winner and lots of games listing that weren’t anywhere near the top 20:

First Past the Post

1. The Elder Scrolls V: Skyrim (141)
2. Portal 2 (92)
3. Batman: Arkham City (50)
4. Dark Souls (41)
5. The Legend of Zelda: Skyward Sword (31)
6. Deus Ex: Human Revolution (29)
7. Saints Row: The Third (25)
8. Bastion (24)
9. Battlefield 3 (17)
10. The Witcher 2: Assassins of Kings (16)
11. Star Wars: The Old Republic (16)
12. Ghost Trick: Phantom Detective (11)
13. Gears of War 3 (10)
14. Uncharted 3: Drake’s Deception (10)
15. Terraria (9)
16. Dead Space 2 (8)
17. Dungeon Siege 3 (6)
18. The Binding of Isaac (6)
19. Bulletstorm (5)
20. Pokemon Black & White (5)

Most years when I look at the first-past-the-post list a “cult” game emerges that received very few overall votes, but where an overwhelming percentage of those votes were #1 votes (I think of this as the “Persona award”); this year actually didn’t have an incredible standout in this category, but I think the award fairly goes to Dungeon Siege 3, which scored a relatively poor #42 in the overall rankings but made it all the way to #17 counting first place votes only.

I also did two more ways of sorting the rankings: an “approval” vote, where nothing is counted except the number of votes a game received (i.e. a first-place and a twentieth-place ranking count the same– all the matters is if the game was on someone’s list); and an instant runoff vote. Your eyes are probably starting to glaze over at this point, so I bolded the places where these two votes differ from the official rank. A small observation: Although these counts usually don’t differ much from the “main” count, this year the IRV list actually looks pretty different to me, I think mostly due to the number of near ties in the official count. Witcher 2 and Star Wars TOR were only within a couple points of each other on the official list; as were Pokemon and Mario 3D Land; as were Ghost Trick, Binding of Isaac, and Uncharted 3 (barely off the list at #21). One more or fewer ballots for any of these games would have changed the rank order. Another small observation: 670 people voted this year. Not only did more than half place some sort of vote for Portal 2, independently counted more than half placed some sort of vote for Skyrim.

FINALLY: PER-FORUM BREAKDOWNS

As mentioned before, this poll mostly exists for a handful of video game forums where some people I know post. Since a few years ago when I started posting the results on this blog, I’ve tried to actually run some extra results, in each case counting only those voters who– as far as one could tell from looking at the logs– had come to the poll from one particular forum or other.

So, here you have it– these numbers aren’t totally accurate because my logging method is not entirely trustworthy, but here’s an approximate by-forum breakdown of these results. Links go to color-coded full listings.

Hello anyone out there: I’ve got this Game of the Year poll that I run on some web forums I frequent. The way it works is that you rank your favorite games of the year– up to 20, though vote for as many or as few as you want– and the script will sort out the top 200 or so out of everyone’s votes. Here’s last year’s results if you want to see what this looks like (or previous years here). I will run this poll script for one week and then post the results. If you’d like to give it a try:

Vote here

When one week is up I will delete this post and post the results here on this blog. Thanks!

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.

• Mac version
• Windows version
• Linux version (requires SDL and Freetype)
• Source code

Thanks to amon26, Mark and Stephen for playtesting.

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

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.

Download

• pongpongpongpongpongpongpongpong (Mac version)
• pongpongpongpongpongpongpongpong (Windows version)
• pongpongpongpongpongpongpongpong (Linux version, supplied by Ranjeet Jhutti)
• Source code

Playing with sound is recommended.

So this is SUPER arcane, but: I’ve been starting to use DVCS lately, and I sort of hate it, but I hate it less when I can use Mercurial to do it. Unfortunately most people doing DVCS are using Git, which means if you are using Mercurial you basically have to be using hg-git so that you can work with Git repositories while still using Mercurial. One thing I’ve found a little inconvenient about using hg-git though is that once you’ve imported the Git repository in using hg-git, all the revision numbers are suddenly different because they’re calculated in Mercurial format now, which makes it very hard to for example look at the github network graph or have a conversation with another developer about different revisions. So I made a patch that shows Git revision numbers alongside the Mercurial ones when you’re using hg-git and also lets you refer to revisions by Git revision when updating, diffing etc. You can find this on my hg-git fork on Github, and I’ve submitted it back to the main project. Oh, I also put in there a neat little script I made to test my changes, that uses virtualenv to automatically build little self-contained python worlds with specific versions of Mercurial and Dulwich. I’m desperately trying to think of some use for this outside the tiny confines of testing hg-git and so far failing.

…for anyone who couldn’t follow that: Mercurial is a program that lets you download source code, Git is a different program that lets you download source code, hg-git lets Mercurial users download source code from Git users, and I did a thing that makes hg-git easier to use.

I hopefully will get to make some more improvements to hg-git later if I have time, like I’d like to try to take a look at why hg outgoing support keeps breaking. I also really want to throw hg-git into the profiler and try to figure out why it’s so SLOW. If I do take a crack at this you’ll be able to find it at my Github fork linked above.

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

Download

• Mac version
• Windows version
• Linux version (requires SDL and Freetype)
• Source code

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.

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.

Following:

• 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 dopack.sh. 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.

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

Download (version 1.0.1)

• Mac version
• Windows version
• Linux version (requires SDL and Freetype)
• iPhone version (or search app store for “Drumcircle RH”)
• Android version (requires Android 2.3)
• Source code

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.

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!

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 https://bitbucket.org/runhello/jumpcore
• svn co https://bitbucket.org/runhello/jumpcore/trunk
• 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.

Compiling

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!