PDA

View Full Version : Cursor*10, single-player co-op



dislekcia
07-01-2008, 03:12 PM
Yeah. Single-player co-op.

http://www.nekogames.jp/mt/2008/01/cursor10.html

Play it and be amazed. Then let the ideas flow ;)

-D

Chippit
07-01-2008, 03:28 PM
I actually played this game yesterday. It has a really neat idea.

edg3
07-01-2008, 03:30 PM
That is interesting! :) It brings a few ideas to mind that could be quite interesting.

Gazza_N
07-01-2008, 03:32 PM
That. Is. Awesome.

Somebody hand the creator some Internets, please?

Nandrew
07-01-2008, 03:36 PM
My word.

The innovations that people have never fails to amaze me. And it was actually loads of fun.

Ruandre
08-01-2008, 10:00 AM
/über cool

BlackHawk
08-01-2008, 01:19 PM
Wow, that's pretty cool. Usually user-created "ghost" objects are only found in racing games, but this utilizes that idea to very good effect. The stand-out feature for me is how all your previous cursors also affect the current play-through. Five cursors clicking away on that locked box is very cool.

Here's an quick adaptation:

A simple pac-man game where your "ghost"/dead pac-man replay their path. However, the actual ghosts interact with the "ghost" pac-men. The ghost pac-men "intercept" the evil ghosts, as it were, by crossing paths on their replay, thus helping your current play-through. To further convolute the maze/mess, have the evil ghosts' "ghosts" also on the board.

Gazza_N
08-01-2008, 01:24 PM
This mechanic would be great for a time travel game. Rather than starting from scratch as per this game, the player is free to rewind and fast forward the timeline, then interact where and when they deem it necessary to solve puzzles or defeat enemies (imagine beating up a boss with ten temporal doppelganger versions of yourself!). That could be awesome.

Nandrew
08-01-2008, 02:05 PM
My word, you guys really are onto something here :O

dislekcia
08-01-2008, 02:24 PM
Ok, so how would you do it? Systems people, systems :)

-D

Gazza_N
08-01-2008, 02:40 PM
Killjoy :P

Probably the same way this guy seems to do it. Keep a global time counter for the level, and spawn a new player-controlled instance of the character/control object every time you "reenter the continuum". Record player actions on a per-object timeline (a list or dynamic array of some sort), then use these to control object activity on a predictive basis once the player time-jumps again (therefore losing direct control).

Easier said than done, but that seems solid to me. You would probably have to limit the number of time jumps the player could make for speed and memory purposes, but that can easily be turned into a gameplay rule.

Nandrew
08-01-2008, 04:06 PM
It's also likely that you'll need to have timed levels in a similar way to what was done in Cursor*10, since the memory toll could become enormous if any given incarnation had an obscene amount of time to perform anything.

It's a limitation, but it could be a good one if you twist it correctly.

Gazza_N
08-01-2008, 05:14 PM
Agreed. Either you would have to impose a global time limit, or else enforce a maximum rewind time like the PoP games do, after which any recorded info is dumped.

One of the major things, though, is what exactly you record. I imagine that by recording keystrokes alone you can put together a rather compact system. Key goes down, it gets logged. Key goes up, it gets logged. Recording data for every game cycle is suicide (and I strongly suspect from the exactness of the motion that Cursor*10 had a hellishly high sample rate).

This is sounding more and more like a multiplayer system, actually. Like a match replay in, say, C&C or Monochrome, but still remaining fully interactive.

BlackHawk
08-01-2008, 10:38 PM
It's also likely that you'll need to have timed levels in a similar way to what was done in Cursor*10, since the memory toll could become enormous if any given incarnation had an obscene amount of time to perform anything.

It's a limitation, but it could be a good one if you twist it correctly.

If you went with the system Gazza_N proposed, I think time is not a factor. Saving time as a 2-byte value (to get micro-second granularity), then the time between actions is just that, 2 bytes memory. You are correct about the memory per object, but with PCs coming out with 2 GB RAM and more that's maybe a non-issue for a small game.

A limit on the number of running objects is a bigger concern (switching between threads can be expensive and/or keeping the timing in sync). Hence only a limited amount of cursors (even though it makes sense gameplay-wise too).

Thaumaturge
09-01-2008, 03:36 AM
That is a very cool game, and a very interesting one indeed - thank you very much for the link, dislekcia. ^_^

I will admit that the multiple cursors wandering about the screen can get a little disorienting at times. o_o;


Probably the same way this guy seems to do it. Keep a global time counter for the level, and spawn a new player-controlled instance of the character/control object every time you "reenter the continuum". Record player actions on a per-object timeline (a list or dynamic array of some sort), then use these to control object activity on a predictive basis once the player time-jumps again (therefore losing direct control).

Actually, if I understand you correctly (and am not destined to "use meteor on self" ;P), I think that I would handle it the other way around - record a trailing string of actions (keystrokes, as you suggest, or perhaps "logical actions") on the part of the player, deleting old events once they pass out of the player's "time window". Then, when jumping back, all actions by all entities after that point are undone, a ghost is spawned (as opposed to the active avatar that you suggest), and the commands are assigned to it, from the entry point onwards. Note that the player-controlled avatar is neither spawned nor destroyed (death aside, of course), while ghosts are destroyed at the point at which the player jumped back to create the ghost.

Jumping fowards might be possible, within reason - it calls for non-player creatures to be simulated with the player avatar absent in a fairly short space of time, I would imagine. It is, however, largely outside of the scope of the concept, I feel, aside from my wondering whether there mightn't be some utility in jumping forwards and then back again - as a form of teleportation, perhaps?

I really like the image of multiple player avatars all beating some unfortunate boss creature. ;)


This is sounding more and more like a multiplayer system, actually. Like a match replay in, say, C&C or Monochrome, but still remaining fully interactive.

Now there's an interesting idea... a multiplayer game incorporating this mechanic. I'm not sure how a "jumping" mechanism might be made enjoyable (I imagine that being forcibly rewound would annoy the other players), but a mechanism similar to that of Cursor*10 might be interesting - play a round, and then play again, but with your earlier selves to interact with. One might throw one round in order to position future ghosts for advantage in later rounds, perhaps, such as putting all resources into reaching a particular, hard-to-reach or well-defended button that activates something of great use to oneself.


Usually user-created "ghost" objects are only found in racing games

Really? What are they used for there? Replays, perhaps?

Gazza_N
09-01-2008, 08:33 AM
I will admit that the multiple cursors wandering about the screen can get a little disorienting at times. o_o;
Agreed. I would've made the ghost cursors transparent myself.



Actually, if I understand you correctly (and am not destined to "use meteor on self" ;P)...
*Use Meteor on Thaumaturge*
In the immortal words of Max: "Oooh, fun!".

To me it seems simpler to create multiple instances of the avatar object, break direct user control when time jumping, then simulate player inputs via the object's action log once control is broken. This is especially useful if you plan on having the player jump back and forward multiple times. But hey, (cat-skinning idiom goes here). ;)



Really? What are they used for there? Replays, perhaps?
They're there for you to "race yourself", although the ghost isn't itself an active participant in the race (ie, you and your opponents can't collide with it, it doesn't appear on the leaderboard, etc.).

Thaumaturge
10-01-2008, 12:06 AM
*Use Meteor on Thaumaturge*
XD;

I suppose that I asked for that. ^^;


In the immortal words of Max: "Oooh, fun!".
"You crack me up, little buddy." :P


To me it seems simpler to create multiple instances of the avatar object, break direct user control when time jumping, then simulate player inputs via the object's action log once control is broken. This is especially useful if you plan on having the player jump back and forward multiple times. But hey, (cat-skinning idiom goes here).

Fair enough - it just seems simpler to me to keep one player-controlled avatar, which is never destroyed (again, barring such things as avatar death), and then create ghosts as required. I'm pretty sure that it would support multiple jumps as well.

*narrator voice* No cats were skinned in the making of this argument. :P


They're there for you to "race yourself", although the ghost isn't itself an active participant in the race (ie, you and your opponents can't collide with it, it doesn't appear on the leaderboard, etc.).

Aah, fair enough, and thanks. ^_^

As you may guess, I don't play racing games overmuch. ^^;

Gazza_N
10-01-2008, 09:47 AM
XD;
"You crack me up, little buddy." :P

Indeed. With meteors. :D

Let's go into specifics, if only to satiate my own curiosity (and probably highlight my abysmal lack of knowledge :P). How would you implement your timeline? Would it be global, or on a per-object basis like mine? And most importantly, how would you structure it, hypothetically?

I actually have very little experience with memory tricks and data structures, so now is a good time to potentially pick up some tips. ;)

Thaumaturge
11-01-2008, 04:57 AM
(Sorry for the delay - I started in on this, found things that seemed to call for more thought, gave them more thought, became distracted, did other things, etc... ^^; )

*rewinds the timeline and counters Gazza's meteor spell* Aha! Semi-on-topic and effective! :P

Warning: long post follows. You did ask for specifics, after all, Gazza. ;P

As to specifics:

I imagine that I might store a simple list of actions (as I said earlier, these could be either inputs or logical actions), with each action having an associated timestamp, using the world's time index (as opposed to the player avatar's, which should continue to increase at the standard pace, regardless of time jumps - for the player avatar it is always one moment later, even if jumping back or forwards).

This list is owned by the player avatar.

I will use the following list for illustration:



action_1 action_2 action_3 action_4
0ms 5ms 8ms 20ms


I will also presume that the game has a method called "update" that takes as a parameter the time since the last update - whether it uses scaling by time or a fixed timestep internally is probably irrelevant.

When jumping backwards, one first identifies the interval between actions into which one is jumping.

If, in our example above, we decide to jump back to 7ms, we are jumping back into the interval between action_2 and action_3.

One can then derive the appropriate state of the then-created ghost by taking the state as of action_2, applying action_2, and calling update(jump_time - start_of_interval_time), or, in this case, update(7ms - 5ms).

The problem, of course, is in rewinding everything (including NPCs, monsters and environmental elements (such as physics-affected props)) back to its state at the desired point.

If the environment is entirely static, or has only a few non-static elements, then the state of each entity could be included in the input/action list, and interpolated as called for in a similar manner to the actions.

For a highly dynamic environment, the most simple solution might be a separate timeline for the state (position, orientation, velocity, health, animation, logic state, etc.) for each entity (player included, but of course excluding the elsewhere-stored input/action data). This, however, could incur high costs.

Perhaps better would be to record major state changes for "active" objects - NPCs, monsters and the like, that may have an effect on the world. Such changes would include logic changes ("monster 'm' decides to go over there") as well as "physical" state changes ("monster 'm' now has 10 health"). These would again be interpolated as called for.

On another note, one potential problem that I see is that of multiple backward jumps, given a trailing list of set maximum length. Say, for example, that the player is allowed to jump back x time units, and the recorded timeline goes back y = k*x time units, where k > 0. If the player were to jump backwards more than k times, they would run out of recorded actions.

This might call for either a limit on the number of jumps that the player may make in a given period of time, or an absolute limit on the distance back that one may jump - an attempt to jump back from one's initial jump-point more than k times would be unsuccessful.

If properly hidden (perhaps behind some form of resource requirement - charge in the jump pack, or crystals to be collected, perhaps), I think that a limit on the number of jumps within a given period may be the easier to implement and the less jarring to the player.

Finally, I think it probably worth noting that if any of the player's ghosts get killed, the player avatar should probably also die (along with any ghosts created between the two).

But what does one do about players attempting the Grandfather paradox by shooting themselves? ;P

Gazza_N
11-01-2008, 08:00 PM
*rewinds the timeline and counters Gazza's meteor spell* Aha! Semi-on-topic and effective! :P
Bravo! A masterful stroke, good sir! And now, I parry!
*falls apart*


<Long detailed description of system goes here>
Thanks for that - it gave me a lot more insight into what you're thinking in terms of this shooter. I see we agree on the basic idea of how the system would function on the whole, even if the fine details are at odds. I concede that your system is probably the most efficient in terms of memory and processing time, as mine would involve having a whole army of player objects instantiated at once, even when inactive.

As regards recording the state of all active objects - is seems to be essential, unfortunately, along with all the limits it creates.


But what does one do about players attempting the Grandfather paradox by shooting themselves? ;P
Honestly? Deduct the current player health. That way you uphold causality, and deter the player from committing temporal suicide. :P

Thaumaturge
12-01-2008, 06:52 AM
Thanks for that - it gave me a lot more insight into what you're thinking in terms of this shooter.

'Tis my pleasure - I enjoyed working on that. ^_^


As regards recording the state of all active objects - is seems to be essential, unfortunately, along with all the limits it creates.

True, but I don't think that it need be recorded at any point other than those at which the object's state changes - after all, presuming that you have a sufficiently deterministic system (and I imagine that such would be a very good idea in this case), the rest should be recoverable (to whatever extent it would be the same, given that the player is changing things) as the system simulates.


Honestly? Deduct the current player health. That way you uphold causality, and deter the player from committing temporal suicide. :P

Heheh, indeed - that probably is the appropriate response. ;)

dislekcia
12-01-2008, 03:02 PM
Keyframes people! Keyframes!

Make your world system, enemies and the like all deterministic. That means that provided they start in the same places and configs, given the same set of player actions they will always turn out the same way. This means that you only need to store player actions and a 'snapshot' of the world every once in a while to be able to rewind/fast forward to any point in the game's timeline.

All you'd do when changing the player's time point is find the snapshot of the world prior to that point and "replay" all the actions up to that point. *poof*, thanks to determinism, the world will now be exactly as it was... Essentially what you're doing is cutting down on object-relative decision storage with smart programming ;)

-D

ShadowMaster
12-01-2008, 11:07 PM
Keyframes people! Keyframes!

Make your world system, enemies and the like all deterministic. That means that provided they start in the same places and configs, given the same set of player actions they will always turn out the same way. This means that you only need to store player actions and a 'snapshot' of the world every once in a while to be able to rewind/fast forward to any point in the game's timeline.

All you'd do when changing the player's time point is find the snapshot of the world prior to that point and "replay" all the actions up to that point. *poof*, thanks to determinism, the world will now be exactly as it was... Essentially what you're doing is cutting down on object-relative decision storage with smart programming ;)

-D

Yeah but that level of determinism is bad, makes the game too predictable. I think what you can do is have a deterministic random number generator and then just store the seed, that way you have the best of both worlds. Determinisms and randomness. What do you think?

Thaumaturge
13-01-2008, 01:35 AM
Hmm... Yes, I think that you're right, dislekcia - one needn't store keyframes for all logic state changes on the parts of non-player active objects, as I think that I had suggested, but can instead store the states for non-player objects in the player's action recordings.

In fact, it seems to me now that my suggestion was flawed with respect to storing the states of non-active objects...

ShadowMaster, I really like your idea, and it involves storing only a little more data - one can have "random" events that nevertheless recur predictably over multiple time jumps.

However, I would caution the use of this - a change in the timeline that introduces even one more call to the random number generator can knock off events that would probably not seem as though they should be affected in such a way. For example, one might travel back in time, spin a wheel (gaining a random number) that wasn't spun the first time, and wind up with a randomly-chosen three monsters bursting in moments later instead of a previous four.

One might want to keep multiple random number generators, one for each set of features that might reasonably affect each other.

dislekcia
13-01-2008, 03:31 AM
Yeah but that level of determinism is bad, makes the game too predictable. I think what you can do is have a deterministic random number generator and then just store the seed, that way you have the best of both worlds. Determinisms and randomness. What do you think?

That would be part of having a deterministic system, yes ;) All deterministic means is that it's repeatable, it doesn't have to be predictable by the player... Plus if you start out from a semi-random state each time the game starts, any possible predictability is going to diverge very quickly as the player makes more and more decisions that are different to the previous play session.

-D

ShadowMaster
13-01-2008, 09:33 AM
ShadowMaster, I really like your idea, and it involves storing only a little more data - one can have "random" events that nevertheless recur predictably over multiple time jumps.

However, I would caution the use of this - a change in the timeline that introduces even one more call to the random number generator can knock off events that would probably not seem as though they should be affected in such a way. For example, one might travel back in time, spin a wheel (gaining a random number) that wasn't spun the first time, and wind up with a randomly-chosen three monsters bursting in moments later instead of a previous four.

One might want to keep multiple random number generators, one for each set of features that might reasonably affect each other.

Adding new random events will change the timeline and thus not mess up the number generators as you can only go back in time. And the only way forward is playing the parts over, creating new logs, and thereby keeping random generators in sync.

Your idea of multiple generators will make things a whole lot easier ;) , since all the function calls don't have to be in the *EXACT* same order, only the functions relative to a specific generator has to.

SkinkLizzard
13-01-2008, 01:53 PM
@ thaumaturge why is that a bad thing
I think something like that could quite easily be incorporated into the game mechanic,
I mean really who knows how this thing we call time works. maybe the fourth monster had a very peculiar
hearing problem that makes the high pitched squeak of a wagon wheel on an axle deadly,
and as such it died when you spun the wheel leaving only 3 monsters to burst into the room.

Thaumaturge
15-01-2008, 07:59 AM
Well, such things can be good, but risk annoying players when the system seems to be inconsistent. Unless you provide information that indicates the fate of the fourth monster (such as its corpse lying in the next room, with a pool of blood seeping from its ears ;P).

Again, such things can work - I was reading just tonight about systems that hide a lot of their logic from the player. However, it is something that I suggest be used with caution, especially where the player is likely to expect some degree of determinism, as, I feel, in time-jumping.

However, it occurred to me recently that the system that we have been describing might not be entirely suited to a logical time-jumping scenario, in which one might expect changes to the timeline to:
A) Potentially cause temporal paradoxes (what happens if, in time-jumping, I destroy the monster that was the reason for my time-jump?), and
B) Potentially remove the reasons that ghost player avatar might have had for an action (what happens if, after time-jumping, I pick up an item that I had, prior to time-jumping but before this point, picked up? Should the ghost go through the motions? If not, surely the player should have control of the ghosts actions, since it is ostensibly the player avatar?)

(By the way, the article that I was reading, 'Game Design Essentials - 20 Mysterious Games' (http://www.gamasutra.com/php-bin/news_index.php?story=16939), I actually found to be very interesting indeed, and gave me a few thoughts for Planar. It covers games that are in some way mysterious in their workings.)