next »

[godatplay]

I love glitch art, and I love this.   

[mcc]

Day 11

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:

[mcc]

Day 12

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.

[mcc]

Day 13

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.

[mcc]

Day 14

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.

[jeffrobot]

Bah, it's only just now occurring to me that single-screen multiplayer is actually going to be impossible, because players can simultaneously be at different points on the timeline. Maybe I'm gonna have to do some kind of simple LAN networking after all.

Mcc,

I don't know if you've solved this problem, but if you wanted to do single screen and reflect different positions in time, maybe you could shade the player's a different color. Like, green is in the present, darker shades of red are further back in time. So people could see immediately who is on their timeline and who isn't.

[mcc]

Bah, it's only just now occurring to me that single-screen multiplayer is actually going to be impossible, because players can simultaneously be at different points on the timeline. Maybe I'm gonna have to do some kind of simple LAN networking after all.

Mcc,

I don't know if you've solved this problem, but if you wanted to do single screen and reflect different positions in time, maybe you could shade the player's a different color. Like, green is in the present, darker shades of red are further back in time. So people could see immediately who is on their timeline and who isn't.

This is definitely something to consider. However, I'm leery about "overlaying" areas at all because (1) this will likely be confusing enough already (2) color currently is the only way to distinguish players and (3) maybe not a showstopper, but it would be hard to make that idea colorblind-friendly (especially with four players). Also something to remember: Who is on "your timeline" or "not on your timeline" is subjective, and the two different players. The problem is not so much conveying what is happening in multiple timestreams but presenting the respective viewpoints of both characters as valid...

Anyway I probably will at least attempt a build where timelines are overlaid as you describe when I get to the point in the project I have time to experiment with such things.

[mcc]

Day 15

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.

[jeffrobot]

Hey mcc,

First, I'm new to this forum, so I don't know if it's cool or not to give people design suggestions. Second, I don't mean to tell you to take my suggestion, but I just want to clarify one thing. I mean that there would be a single, objective time stream, and your color reflects where you are on it. So you wouldn't need to worry about validating people's own timelines (maybe that's a problem) Everyone would be on the same timeline. A player could be dark red, far back in time if he had traveled there. Farther, even, than some of his copies. It still reflects where he is in time relative to other players. And he knows that anyone else who is his shade of red is in the same time and can interact with him.

I may not fully understand the complexity of the gameplay , so this may not work. Also, I don't mean to tell you how to make your game. I thought it would be neat to discuss gameplay.

[mcc]

Hi Jeff, I do appreciate the suggestions, I was just explaining my thought process (since I had spent some time thinking about something like your suggestions).

The idea of there being one "objective" camera at a specific point in the timestream and other things being displayed relative to that had not occurred to me, that's interesting. I'll think about that.

[mokesmoe]

Another problem is that it would look weird when you wrap around back to zero.

[mcc]

Another problem is that it would look weird when you wrap around back to zero.

Well, one way to do it would be to have the "objective" camera be moving in time, in this case the objective camera would just define a standard "offset" in time.

The way I am actually implementing all this at present is that if "all time" is 60 seconds, and the snap distance is 10 seconds, then I maintain 6 physics spaces and each global tick I step forward all 6 spaces in lockstep. I then just happen to only show one of the six spaces at a time, and when you snap what you do is jump between spaces. (I keep the extra spaces around so that if you suddenly jump to a particular time all the objects will already be where they need to be, I do not need to calculate any of that.) So one way to do jeff's suggestion would be to just say, instead of showing the 1 of 6 spaces that contains the "player", I will always just show space 0 and then show the other spaces behind it.

[moonmagic]

Your game makes my head hurt pleasantly, like Primer. I'm excited to see where this ends up!

[mcc]

Day 16

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 (except to note, if you haven't noticed this yet, that you can get full size versions of any of these images I've been posting by clicking).

[mcc]

Day 17

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.

[godatplay]

Thank you for continuing the discipline of daily updates, sir. Much appreciated 

[mcc]

Well, glad someone's reading them If you'll notice there was not one this monday. I actually only said that I'd update on days I actually worked on the game... but there's only been one day since the compo start that I didn't, so...

[mcc]

Day 18

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.

[mcc]

Day 19

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

[mcc]

Day 20

Mac build (r90M)
Windows build (r90M)







Status: Broke everything.