The Snap, development log: Day 24

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

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

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

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%.

The Snap, development log: Day 20

February 9th, 2011

Mac build (r90M)
Windows build (r90M)

Status: Broke everything.

The Snap, development log: Day 19

February 7th, 2011

Mac build (r90)
Windows build (r90)

Status: Implemented a pretty neat motion-blur-y effect that fires when you snap. I have a couple ideas for making it look “cooler” later.

By the way, if it’s not obvious, the changes I’ve done this weekend have all been tiny fiddly things, because the next thing I really need to implement is health, and that is going to be incredibly obnoxious to implement… 😐

Postscript: WTF, since when does WordPress do graphical smileys in blog posts?

The Snap, development log: Day 18

February 6th, 2011

Mac build (r89)
Windows build (r89)

Status: A small update, when you perform a snap the appropriate visuals and sounds now occur in the other player’s half of the screen immediately.

The Snap, development log: Day 17

February 5th, 2011

Mac build (r87)
Windows build (r87)

Status: Added a little “time map” at the top of the screen showing where the players are in relation to each other in time. Fixed the aspect ratio in splitscreen mode.

Unfortunately “fixing the aspect ratio”, since I don’t have camera pan and scan yet, entailed making the map really thin. I need to make actual maps for this thing at some point. I am realizing I’m not especially looking forward to this.

By the way, if you try out these builds: The red areas are supposed to be walls! Pretend you cannot walk through them.

The Snap, development log: Day 16

February 4th, 2011

Mac build (r86)
Windows build (r86)

Status: Added splitscreen. Player one and their position in time appears on the left screen, player two and their position in time appears on the right screen. I also set it up where noises occurring on the left screen play to the left speaker, and noises occurring on the right screen play to the right speaker… I think I was imagining people might plug in earbuds and then give each player one earbud to wear. I have no idea what I do with the sound feature if I try to go beyond 2 players.

It’s kind of fun to snap a bunch and then watch players pingponging between the two screens.

This is sort of a first pass, so (1) both screens are drawn scrunched and (2) this probably doesn’t work yet on machines that don’t support OpenGL 2.

The following image is presented without comment.

The Snap, development log: Day 15

February 2nd, 2011

Mac build (r84)
Windows build (r84)

Status: Controls updates. Your control settings are now saved to disk when you set them and picked up again on load. If the game doesn’t find a gamepad it’s expecting at startup it temporarily shunts the appropriate player[s] back to default keyboard controls while the gamepad’s disconnected.

I also added… it’s a little hard to describe but sort of an “auto-aim” mode. In this mode instead of having separate move and aim controls, you just have your move controls and then a “fire” button. Hold down “fire” and the game fires in the last direction you were “facing”. Dual analog control sure is fun, but this more limited mode helps a lot if you want to fit a lot of players into one game with limited control options– it makes four people on one keyboard seem within the realm of possibility for example. Most importantly for my purposes it means I can now control two players simultaneously despite only having two hands (I map left analog to P1 move, right analog to P2 move, L1/R1 to fire and L2/R2 to snap) which makes testing way easier.

If you want to try auto aim mode wait until it prompts you for “fire up” and then press the backtick/tilde button on the keyboard. “Fire left” will become your “fire” button.