Archive for the 'Video Games' Category

The Snap, development log: Day 36

Friday, February 25th, 2011

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.

The Snap, development log: Day 35

Thursday, February 24th, 2011

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.

The Snap, development log: Day 34

Wednesday, February 23rd, 2011

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.

The Snap, development log: Day 33

Tuesday, February 22nd, 2011

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.

The Snap, development log: Day 32

Monday, February 21st, 2011

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.

The Snap, development log: Day 31

Saturday, February 19th, 2011

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.

The Snap, development log: Day 30

Saturday, February 19th, 2011

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.

The Snap, development log: Day 29

Friday, February 18th, 2011

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…

The Snap, development log: Day 28

Thursday, February 17th, 2011

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.

The Snap, development log: Day 27

Wednesday, February 16th, 2011

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):