runhello.com

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.

Mac build (r137)
Windows build (r137)

Status: Implemented a level select screen. Fixed the sound, which was actually completely broken in yesterday’s build (well, the snap sounds were). I then took a break to contract moderate hypothermia.

Note: There are some camera and other problems with the new levels.

Mac build (r135)
Windows build (r135)

Status: Implemented Ogg Vorbis for storing sound effects and such. Fixed a problem where there was something like a couple-second delay at startup. Added a logo screen (same one from iJumpman). Fixed some stupid bugs in yesterday’s build (like apparently I’d accidentally checked in a change where I was constructing the level map out of the image that describes the font… um). Made a bunch of under-the-hood changes in anticipation of level select, the only externally visible effect of which is that the starting positions of the players within the level is now partially randomized. Added a simple option to play again once the game is over.

A random thing: Increpare made a comment a couple days ago about what tournament-style play would look like with the time travel mechanic. I took the comment at the time as joking. Once though I got to the point of adding the Replay? Y/N box, and therefore making it possible to play the game more than once without restarting the whole application, I realized I was having to do extra work to make sure that objects and events didn’t leak through from the previous game. I’m not, at the moment, freeing any of the memory I allocate from game to game, so all the objects from previous games are just sort of hanging out in memory. So it occurs to me that if you had a game based on this engine with time travel controls more complex than just “press button to jump back 5 seconds”, you actually could just jump “back in time” all the way back into the last game you played, interact with the players there, make the current game’s event tree mutually intertwined with the last one, maybe change the outcome of previous games and watch the “overall games won” counter at the top of the screen fluctuate up and down…

Mac build (r122)
Windows build (r122)

Status: Added attract mode!

I spent way too long thinking about these names. I sort of want to rename the first two to “HANK” and “TARA” but then that looks/sounds too similar to “JAVA”. The rule for the names is they have to sound like they were ripped out of a 90s comic book.

Also fixed the aliasing/seam problems with text mode that I was talking about yesterday. Though it’s hard to tell the difference because all these images I’m posting are resized to 700×438.

Mac build (r118)
Windows build (r118)

Status: Abandoned project; will be spending the remaining time in the compo implementing a multiplayer version of VisiCalc.

Wait, that’s not it. What I meant to say is that I have implemented a replica of the Apple // text display system which will allow me to do Apple // style menus. In addition to being STYLIZED, these will hopefully be more functional than the old menus once they are done. Huge thanks here to Gerard Putter who allowed me to use his extraction of the Apple //c character set.

If you want to play with the Apple // mode, enter F6 at the menu screen (you can also enter F6 after the game has started for bizarre results). Once in this mode: use arrow keys to move around, type to enter letters, hold down control and type a decimal number to enter a special character, use F1 to save the screen to disk, press F2 to load it again, F3 to enter/leave invert mode and F4 to show/hide the cursor.

This still needs some work, in particular I have made no effort yet to make Apple // pixels map cleanly to screen pixels so there are problems with aliasing and funny-looking seams between characters (click to see PROBLEMS):

Mac build (r113)
Windows build (r113)

Status: Working physics! Chipmunk is now completely handling not just collision detection but all movement. This means not only that you can move up and against walls correctly (and there’s a fun little bounce when you hit a wall that I think I’m going to try to keep in) but that players can push and shove each other around. (At one point I even had a little kickback when you got hit by a bullet, but I took it out for now because it wouldn’t be able to work when you shot a “past self” player).

Downsides: There’s now a little bit inertia of when you start or stop moving; the characters move like they have heft, sort of. I tried to minimize this but there’s still a little bit. I’m not sure if this is actually something to fix or not. Also, if you just sit perfectly still for 10 seconds until your copy spawns on top of you, your copy actually spawns literally on top of you and it’s just sort of weird.

Anyway the physics is a big deal because what I now have is basically a system where “new” objects (i.e. objects being controlled by a player) are totally driven by the physics engine, “old”/”past self” objects are driven by the recorded movements and velocities from when they were “new”, and interactions between the two are natural and physics-y (“old” objects can’t deviate from their paths, but they can knock “new” objects out of the way). You could at this point fit in any kind of physics Chipmunk supports (like I at this point technically could, and as an experiment at some point might, turn on gravity), or I think without much difficulty drop in a 3D physics library like Bullet, and the time engine would just handle it.

I think I’m considering this the first “playable” demo; there’s nothing left at this point to “apologize” for, so to speak. You should be able to play a multiplayer game at this point and it should be fun (assuming the game is fun at all). Everything from here on out is polish, adding maps, and “additional features” like health/ammo canisters. If anyone’s able to give this version a play, I’d be really curious how it works out for you (and I need to find someone to play against…). I’d be especially curious, if you tried any of the previous builds, what you think about the new “hefty” movement.

Mac build (r110)
Windows build (r110)

Status: Added level maps and free-moving cameras.