Archive for the 'The Snap' Category

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

The Snap, development log: Day 26

Monday, February 14th, 2011

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.

The Snap, development log: Day 25

Sunday, February 13th, 2011

Mac build (r110)
Windows build (r110)

Status: Added level maps and free-moving cameras.

The Snap, development log: Day 24

Sunday, February 13th, 2011

Mac build (r105)
Windows build (r105)

Status: Fixed some bugs. Explosions no longer sometimes draw “behind” other objects for example.

The Snap, development log: Day 23

Saturday, February 12th, 2011

Mac build (r97)
Windows build (r97)

Status: Did a big under the hood overhaul of the way I lay out HUD elements on the screen. Before, the way I positioned interface elements during the game was done by a bunch of spaghetti code doing ugly math, which resulted in a bunch of little bugs of varying levels of obviousness. Now I have some nice clean code for describing rectangles in relation to one another which I can easily use to actually place elements where they are supposed to go. Although I haven’t bothered actually placing said elements where they are supposed to go yet…

The Snap, development log: Day 22

Friday, February 11th, 2011

Mac build (r92)
Windows build (r92)

Status: Things actually work!

  1. You can get shot and take damage.
  2. You can go into the past and block a shot destined to hit another player, and you take damage and they heal.
  3. You can run out of health and die.
  4. Walls are now impassable (though this doesn’t exactly work great yet).

Thing #3 means that this is now, technically, a “game”! It is possible to win and possible to lose. You may feel free to start holding 32-person double elimination tournaments now.

The Snap, development log: Day 21

Thursday, February 10th, 2011

Mac build (r91)
Windows build (r91)

Status: Rolled back yesterdays graphics experiments, implemented health bars. They don’t do anything interesting yet. P1’s health is fixed at 100% and P2’s health is fixed at 50%.