runhello.com

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!

A first person shooter

Download (1.0, r219)

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

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?

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.

Mac build (r179)
Windows build (r179)

Status: Fully featured controls config screen– you can choose gamepads in addition to the keyboard now, and you can choose whether to use auto aim mode or not. The defaults for both players have been changed to use auto aim mode (meaning, 2 players can actually play on 1 keyboard using the default controls now). The superfluous, vestigial mouse-driven “menus” from earlier in the project have been removed (which felt good) and, since it’s no longer used anywhere, the mouse cursor is now hidden during gameplay. Hitting “esc” now causes you to go “back a screen” until you quit instead of quitting immediately.

Nearly all of these features (all of them except the esc thing, basically) are totally broken, and using them will result in you running into a set of bizarre and inconsistent bugs which somehow exist when I build in release mode, do not exist when I build in debug mode, and may or may not exist on Windows. In release mode on mac it usually reads apparent garbage data instead of the defaults, usually does not create the controls save file (but often later successfully loads the correct data from the file it did not create), and asks for unused buttons (like “fire right”) in auto aim mode. It looks like either I have a subtle memory corruption bug or I’m doing something incredibly illegal with filehandles.

EDIT: Wait, like a minute after I made this post I figured out part of the problem. Somehow the controls prefs file on mac has been getting saved to / instead of to the expected directory. Which is pretty bad. But this does not explain the other problems.

Mac build (r171)
Windows build (r171)

Status: Fixed various camera problems, added levels which “loop” (it seemed weird to me that the time axis looped but the x and y axes never did), added levels with gravity, allowed levels to override several other physics defaults, added custom messages for levels, added a level setting called “immortal bullets”. The game is technically like 3x bigger now counting by number of maps.

There is a particular visual glitch associated with the loop levels still. The “Platforms” (gravity) and “RubberRoom” (immortal bullets) levels, which are kind of experiments/jokes, kind of highlight flaws in the engine and I’m not sure whether to keep them in or not.

Guess I might as well document how user-created levels work now. You can create your own levels by dumping .xml and .png files into the same directory as the Snap .exe (or .app). Snap will load all .xml files it finds when it starts up, and when it’s building level maps it will load .pngs in the directory “with the exe” before looking inside the application’s internal folder (in other words it’s possible to override default maps). If you want to see example .xmls and .pngs, look inside the “Internal” folder (or, on the mac, control-click the .app, choose “Show Package Contents”, look in Contents/Resources). You should be able to just copy the default level.xml and edit that; each “level” line is one of the default maps. The “level” attributes, if it’s not already obvious, are defined like:

• “name” – Name in level menu. Required.
• “file” – Png file name to load to construct map. Required unless “padded_room” is true. Notice, EVERYTHING else except these first two attributes is optional and will be replaced with sensible defaults if left out.
• “maxhealth” – Maximum/starting health. An integer greater than zero.
• “std_zoom” – The camera zoom amount. A float value greater than zero.
• “forever_length” – Number of seconds before the timeline “loops”. A float value greater than zero.
• “snap_factor” – Snap distance is calculated by dividing this number from forever_length. This should be an integer which evenly divides forever_length.
• “block_size” – Each pixel in the “file” png will equate to a square with this side length. For scale, a player character is always a square 0.2 units wide and 0.2 units tall. This should be a float value greater than zero.
• “have_camera_freedom” – Determines on which axes the camera may move freely. This is what I’m going to call an “xy mask”, which means it’s an integer equal to either 0 (for “neither axis”), 1 (for “x axis”), 2 (for “y axis”) or 3 (for “both axes”). The default is 3.
• “have_camera_limit” – Determines on which axes the camera halts at the edge of the map. An xy mask. Default is 3.
• “repeat” – Determines on which axes the map “loops”. An xy mask. Default is 3. By the way, I’ve discovered that my old game Jumpman (which also used PNGs for level maps) is an excellent editor for making levels using this feature. Note though unlike Jumpman you shouldn’t try to make levels in which the “repeating” area is so small you can see copies of yourself. This won’t work and trying it will lead to graphical glitching.
• “padded_room” – If set to “1”, the map is discarded and instead a special map is built which is exactly the size of the screen. block_size is honored but this attribute has not been tested to– and probably does not– work with many of the other attributes.
• “immortal_bullets” – If set to “1”, bullets bounce off walls instead of exploding against them. May cause odd things to happen.
• “gravity” – If greater than zero, vertical gravity is enabled. This should be a float equal to or less than zero. The default is of course zero. May cause odd things to happen.
• “w_e”, “p_e”, “b_e”, “w_u”, “p_u”, “b_u” – The elasticity and friction material values assigned to, respectively, the (W)alls, (P)layers, and (B)ullets. Do the documented things e and u do in the Chipmunk physics engine. Of very little use to you unless you are playing with gravity (I still haven’t found a good value to set friction to with gravity, so the “Platforms” level things move like on ice).
• “message” – If present, the contents will be shown on the level select screen in the blank space between SNAP and FOREVER. All the messages in the default levels are of the form “HAZARD: Something here”.

The custom levels feature probably shouldn’t be considered “supported”. Entering bad values for some of these attributes, particularly name or file, may cause the game to misbehave or crash. And I may change the schema later, though either way I’ll bundle an updated copy of this documentation along with the game or something.

Mac build (r151)
Windows build (r151)

Status: Still pretty sick and progress is very slow. A little alarmed because I’d been hoping I’d be able to use this 3 day weekend as crunch time– I’m certain I’m going to meet the deadline but I’m starting to get worried about which features will or won’t make it in. I got a good way along on the player config screen but it’s still got issues, in particular you can’t pick anything other than the keyboard so I can’t remove the “old” menus yet. I’m using inverse text to denote selection on the player config screen so I switched the level picker screen to use inverse text for selection also– that >SELECTION< thing was extremely aesthetically pleasing to me but oh well, it was also kind of hard to read. Now that I'm looking at the player config screen, I'm worried about whether it's readable or if there's just too much dense ASCII. I tried to space it out a bit.

Mac build (r142)
Windows build (r142)

Status: Was kind of sick today so didn’t get a lot done. Implemented a player config screen (unfinished, atm just press return to skip past it) and also set it up where user-created levels can be loaded. Will document how you do this later.