Archive for the 'The Snap' Category
The Snap, development log: Day 19
Monday, February 7th, 2011Mac 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
Sunday, February 6th, 2011Mac 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
Saturday, February 5th, 2011Mac 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
Friday, February 4th, 2011Mac 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
Wednesday, February 2nd, 2011Mac 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.
The Snap, development log: Day 14
Wednesday, February 2nd, 2011Mac build (r81)
Windows build (r81)
Status: Simple animations are now associated with both bullet collisions and snaps (unless you’re the one snapping). Like the “underwater snap” sound effects (which I like better now that they’re synchronized with the little animations) I think the exact animations here are placeholders, the important thing right now is that I can trigger animations at all. Also fixed a bunch of stuff under the hood.
The Snap, development log: Day 13
Sunday, January 30th, 2011Mac build (r70)
Windows build (r70)
Status: The “event tree” is in place; this is the mechanism I’m going to use to make events “depend on” other events, and allow future events to be taken out of continuity if you change things in the “past”. You can see this in action now by:
- Fire a bullet;
- Snap back 5 seconds in time;
- Throw yourself in the path of the bullet.
The bullet will hit you instead of the place it was going to hit, and the original bullet collision event and all its side effects (at the moment that would be only a sound effect, since players don’t have “health” yet) will be undone.
The sound effects for the snap are all new, and there are sound effects now when another player (or one of your “past selves”) performs a snap.
Some thoughts about how things are going:
- I really like how the “snap” sound effect sounds, especially contrasted with the bullet fire/land noises. The alternate sound effects you hear when “other people” snap, on the other hand, I don’t think I like at all and I’m thinking of those noises as placeholders. I was thinking, when someone else snaps, I want it be the snap sound effect but I want it to sound kind of far away, muffled, underwater. The way I know how to do that is low-pass eq and echo. But I think I overdid it. There’s a kind of WOOP WOOP quality to the noise that doesn’t sound good at all, and the sound just goes on too long, which exacerbates the problem that the “going out” snap is not at all well synchronized with the visible disappearance of the snapping square. Probably I will look into fixing this when I add some kind of visual effect accompanying the snap.
- I’m thinking about this “event tree” system I’ve set up. The thing I really like about it is that it makes really complicated side effects of simple actions possible: You perform event X which prevents event Y from happening two seconds in the future, then the other player jumps back in time and performs event Z which prevents event X which “reinstates” event Y into continuity, and you see all these side effects instantly. This sounds all neat in theory, but when I try to think of good examples of how this could happen in practice, most of the good examples I can think of involve killing other players and therefore invalidating all their actions in the timeline after that. Of course that will not be an element of this prototype I’m working on here, since I’m planning to only have two players and therefore if one player dies the game just ends. I’m wondering if I really need to push for 4p play somehow.
The Snap, development log: Day 12
Sunday, January 30th, 2011Mac build (r64)
Windows build (r64)
Status: Fixed a really nasty collision detection bug that would under certain circumstances cause a bullet to trigger a false “collision” on its first frame. Finding this bug took so long I didn’t have time to do much else.
I started on what I’m thinking of as the “event tree” but it isn’t there yet. Bullets do make a sound now when they collide with something, but because there’s no event tree, if you fire a bullet, go back in time, and then throw yourself in the path of the bullet, you’ll hear a phantom sound effect at the moment of the bullet’s original collision.
The screenshot above demonstrates the bug I fixed, in a way that probably isn’t worth explaining.
The Snap, development log: Day 11
Saturday, January 29th, 2011Mac build (r61)
Windows build (r61)
Status: Shader-based motion blur works! However, I don’t like it and will be taking it out immediately. It runs dog slow whenever it’s got enough sample points to look like anything at all, and it doesn’t even look right after that. Meanwhile, although the method I’m using could maybe make a little bit of sense if this were some super complicated 3D game, given again that this whole game is green squares, I can get this same effect cheaper through more conventional methods. Even if I’m not keeping the shader though I think it was still a worthwhile experiment for a couple reasons, one of them being that I can adapt this code into a graphical effect I will use.
A couple little things. If I turn the “power” on the effect way down, it actually both runs very quickly and also looks pretty attractive:
…but this looks really subtle and I can still get the same effect easier through other means. Meanwhile if I turn the effect way up it just looks sort of fun:
These last two images have nothing to do with anything and are included only for the sake of the person in the tigsource thread yesterday who said (s)he likes glitch art: