runhello.com

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.

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.

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

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

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

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

Mac build (r59)
Windows build (r59)

Status: Only had a little bit of time to work on this today. Spent it on trying to implement motion blur. It isn’t going well.

Mac build (r56)
Windows build (r56)

Status: Trying something that may be a dead end.

I adapted some code from my other project and added a shader postprocessing step where I can apply an arbitrary amount of blur to the screen at every pixel. I’m eventually going to try to use this to add motion blur and some other effects. For now, to test it, I set it up where it’s applying waves of blurring that sort of march across the screen. To make the effect more obvious I turned the “blur” up to a cartoonish level, but you can adjust the blur factor by pressing F5 and mouse-wheeling over the little control that appears. When you turn it down to -32 or -40 you get an aesthetically pleasing wavy effect that actually looks like a proper blur.

I’m not even totally sure if I can get away with using this effect. It slows my mac to a crawl whenever the window/screen is bigger than 1024×768 (though, there’s a reason for this, and maybe I can work around it) and it seems like maybe overkill for a game where literally everything is a single-color rectangle. Hopefully I’ll be able to adapt it into something interesting though…

Mac build (r51)
Windows build (r51)

Status: Collision detection improved. You can shoot “past selves”, and they can shoot you. Being shot has no meaningful effect yet, but you can do it.

You still can’t collide with other players or copies of yourself, players just pass through each other. I’m really not sure what should happen when you do that. Clearly if you’re just sitting there and a “past self” player runs into you, you should be pushed out of the way. And something should happen if a snap causes another player to spawn on top of you. (Telefragging? Cuz telefragging sounds lame to me.) I’m not sure there’s a sensible way of dealing with this, other than either turning Chipmunk back on or reimplementing large chunks of Chipmunk in an ad hoc fashion.

Mac build (r50)
Windows build (r50)

Status: The snap works. Press space bar to jump 5 seconds back in time. (When I’m playing with the gamepad, I map this to right trigger.) Bullet physics also work now, or at least, bullets can collide with things.

Limitations: You can coexist with the past but you can’t change it. You can shoot “past selves”, but (1) they can’t shoot you, their bullets just pass through you right now and (2) shooting them really has no effect since bullets don’t do damage yet. There’s no kind of visual effect associated with the snap right now so squares just kind of appear and disappear jarringly and it looks “wrong”.

Is the sound effect on “shooting” too annoying?