The Snap, development log: Day 29
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…