next »

[increpare]

heheh

[tzachs]

Status: Broke everything.

You might say that you've experienced "The Snap"... 

[Will Vale]

You could presumably go back in time to before you broke it, and repair in the then-now the now-future time stream? Try not to step on any butterflies though...

I think this is probably the most interesting idea in the compo, it makes my head hurt to think about it. Is the event tree fully "analogue" so you can snap at any time? Does it blow up if players do lots of snaps, or does the 60 seconds put a practical limit on that?

Will

[mcc]

You could presumably go back in time to before you broke it, and repair in the then-now the now-future time stream? Try not to step on any butterflies though...

Such are the wages of svn

I think this is probably the most interesting idea in the compo, it makes my head hurt to think about it. Is the event tree fully "analogue" so you can snap at any time? Does it blow up if players do lots of snaps, or does the 60 seconds put a practical limit on that?

Will

The event tree is basically "analog" (not sure what you mean by that) in that changes propagate to the whole timeline instantly, the snaps are non-analog in that you can perform one literally anytime but the snap increment is fixed. So you can't just jump anywhere on the timeline at any moment.

Doing lots of snaps is actually very conputationally cheap. You're basically just populating the screen with more players to draw and it costs no more to draw a player than a bullet. There are some other things I'm a little worried about the cost of tho.

[rszrama]

Just stopping in to say the conceptual prototype works great on my Mac and really shows the potential of the game. I reeeeally look forward to playing this with other humans. 

[mcc]

Woo

Thanks for the report

[mcc]

Day 21

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

[mcc]

Day 22

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.

[increpare]

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.

What would tournament structure+time-travel look like?

[yokomeshi]

Everyone keeps warping back and forth trying to keep themselves from being eliminated, or to stop everyone else's meddling.  However, following a series of wacky temporal mix-ups, the first prize is awarded to Meryl Streep, six contestants prove to have been their own ancestors, and dinosaurs ruled WWII Germany.

[mcc]

Day 23

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

[increpare]

You know what might be interesting addition in this game?  Finite light speed w/ player light-cones.

[mcc]

Day 24

Mac build (r105)
Windows build (r105)



Status: Fixed some bugs. Explosions no longer sometimes draw "behind" other objects for example.

[mcc]

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.

What would tournament structure+time-travel look like?

So

A big problem with this whole concept, the "past as replay" idea, is that it forces player copies in "the past" to behave basically unrealistically because they cannot react to new information. Snap partially avoids this problem by having very simple mechanics but really even still there seems to be a suspension of disbelief problem, you jump five seconds back right in front of another player and they just move past you instead of shooting back or whatever. I've thought about getting around this by giving the "past selves" some very simple self-defense AI, but then the past selves are depleting your present self's ammo. There's not really a way to set up the AI the to make the same decisions the player would make.

I was thinking that you could do this time-travel-game thing "correctly" so long as you had technology capable of digitizing human consciousness, like say the tech from Richard K. Morgan's "Altered Carbon" novels. What you could do is upload representations of your players' minds to the server, simulate the players playing the game, and if at some point there's a "branch", like player 2 moves back in time and confronts player 1 and you need to know how player 1 would react, you could take your simulation of player 1's brain, erase their memories back to the branch point, and re-simulate those steps to see how they would have behaved differently. You'd also have a lot of interesting options for handling paradoxes if you did this, like say if player 2 appearing in the middle of the map causes the past player 2 to behave differently such that they don't later make their hop back in time. Like you could possibly rerun the simulation hundreds or thousands of times until the players converge on a stable set of actions. Or if the "re-simulate" timeline diverges too much for player 2 to have made their original jump, you could just declare the second player 2 "from a parallel future" and simulate two copies of player 2 in parallel.

… but I don't think I'm going to have this implemented by the end of the compo

You know what might be interesting addition in this game?  Finite light speed w/ player light-cones.

Hm, so this is interesting. One thing is that the game depends very heavily on the concept of an objective global clock, so you couldn't do real relativistic physics of any sort.

But if the lightcones were just a visual effect, I think you could do this pretty easily as long as you used a software renderer and maybe were willing to put up with a lower resolution (not that that's a big difference with graphics like this, I was apparently doing RTT at 1/2 resolution for much of the last week and never noticed). I'm already storing for each "frame" in the time loop a bunch of information about object positions and velocities and such, I could easily also just store an actual bitmap of the way the board looks at that point in time and then skew across frames when drawing to screen.

One thing I like about that idea, it would be interesting to make it where when you snap, you don't immediately get to see what's happening far away from you. Like maybe when you snap the visuals from the "new time" only appear at your character and spread out from there over a few frames, like from your perspective the "old" photons are still coming at you from pre-snap and it takes a second for light to catch up to the fact you've time-teleported. (I don't know if I can think of a non-contrived way to explain to the player why that happens in non-game-mechanics terms though. Emission theory of vision?) This would institute some kind of minor penalty for snapping "too much" while still allowing you to snap a lot if you really need to, because once you snapped it would take you a second or so to even be able to see what's happening around you.

[Will Vale]

<snip interesting discussion of light cones/slow data acquisition>

It would make perfect sense in a space combat game as opposed to a deathmatch one. There's some great combat design in Elizabeth Moon's novels involving light lag, incomplete scan data, and short/long range FTL jumps.

I've often thought that would make an interesting game - I have pages of notes on how it might work and whether it would be fun. My gut feeling tells me it'd be obscure, but if you make the simulation rich enough fun might just emerge.

Sublight was supposed to be a step on the road to this, but I never found time to work on more pieces for it. Ah well.

Thanks for your earlier description of the event tree - I think what I wasn't getting was whether it was fully discrete, or whether events could come in at any point in time - so you jump -10s, but you can start from any time rather than at 10 second intervals.

The latter would make it possible for the tree to grow very large, but since you have a limiting factor in that players only make so many decisions per second, it's probably not a huge deal?

How do you store player movement in the event tree?

Cheers,

Will

[increpare]

A big problem with this whole concept, the "past as replay" idea, is that it forces player copies in "the past" to behave basically unrealistically because they cannot react to new information.

That doesn't trouble me too much.  I guess the main thing is that it encourages a certain style of play - with players hedging a lot.

One thing I like about that idea, it would be interesting to make it where when you snap, you don't immediately get to see what's happening far away from you. Like maybe when you snap the visuals from the "new time" only appear at your character and spread out from there over a few frames, like from your perspective the "old" photons are still coming at you from pre-snap and it takes a second for light to catch up to the fact you've time-teleported. (I don't know if I can think of a non-contrived way to explain to the player why that happens in non-game-mechanics terms though. Emission theory of vision?) This would institute some kind of minor penalty for snapping "too much" while still allowing you to snap a lot if you really need to, because once you snapped it would take you a second or so to even be able to see what's happening around you.

Sounds a bit boring to me, but I guess if it makes a better game, then....

[mcc]

A big problem with this whole concept, the "past as replay" idea, is that it forces player copies in "the past" to behave basically unrealistically because they cannot react to new information.

That doesn't trouble me too much.  I guess the main thing is that it encourages a certain style of play - with players hedging a lot.

It does, and I'm curious to see what that style of play is like once I get something outright "playable"...

Sounds a bit boring to me, but I guess if it makes a better game, then....

Well just as well because no way am I implementing it for the compo : P

[mcc]

Day 25

Mac build (r110)
Windows build (r110)



Status: Added level maps and free-moving cameras.

[rszrama]

Hey mcc, just tried the latest Mac build and noticed 1) that the free-moving camera wasn't working for me in single player mode and 2) the player doesn't "slide" against walls.  So, if I'm walking along a wall and start holding up before reaching the edge so I can hug it as soon as I'm around the corner, I stop moving entirely. I understand how this is likely working from a collision detection standpoint, but it's awkward / unexpected from the player's standpoint (and makes it tricky to navigate some of the close corners / single block width corridors).

Also, I really like the snap blur... good effect.  :D

[godatplay]

(I don't know if I can think of a non-contrived way to explain to the player why that happens in non-game-mechanics terms though. Emission theory of vision?)

Why don't you do a radial blur with some glow to give it a sort of "tunnel of light" effect? I think that'd be a simple and intuitive way to get the point across, at least as a first pass at the idea. An even cheaper solution would be "radial ghosting," as seen when you enter into the stock trading mode in American Dream.

I don't see a problem with the concept being confusing at all, but I guess I thought Inception was a perfectly straightforward movie. But this idea seems like one of those distracting things that will prevent the game from getting done, heh. Those kinds of things are so tempting...