Here is a video game I made in 48 hours for the Ludum Dare competition. It is called You Don’t Fit.
Download
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
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:
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:
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.
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)
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
__________________________
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:
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!
A first person shooter
Download (1.0, r219)
How to Play
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?
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.
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.
Mac build (r188)
Windows build (r188)
Status: Objectively not a very big change but probably important, a complaint I’ve been getting from playtesters for a long time is that there’s all these copies of yourself on screen and you can’t keep track of which one you’re actually controlling (or, as, one report the other day pointed out, which half of the screen to even look at). So I gave the square you are actually controlling at any one moment a kind of pulsing glow now. (At one point messing around with the blend functions I got this to have a pretty light-bloom effect to it, but this broke other stuff…) If anyone plays this I’d be curious what they think of the player pulsing, did it help, etc.
Oh also the game shows score “totals” on the game over screen now.
Running kind of low on time now so I’m starting to think now about feature triage. The two things I think I’m going to really try to get in before doing final cleanup are music and the health drops. If ammo drops don’t make it in I’ll deal. I made some little sprite things for health, ammo and snap refill canisters. They looked terrible. Then I talked to Kyou, who did the sprite work for Jumpman, and he made these and they look awesome.
Current plan is to try to use one of these for the health refills.
Mac build (r181)
Windows build (r181)
Status: One more day on that increasingly-terrifyingly time-consuming controls configure screen, and I do believe I’ve fixed all the problems with it now. The controls file should save in the right place, not become garbled, your choice of auto-aim vs free-aim should be honored. As one more wrinkle I made the way you exit the screen now be that both players are supposed to snap. This decreases the risk you will blow past this screen without absorbing any of the information.
Also made some GRAPHICS today but did not put them in the program yet.