From Gates to Staircases in Cocoa Quest

[Kingbry]

So this is a problem that has a lot to do with my understanding of how to work with the code taught to me in the Cocoa Game Workshop program Cocoa Quest.

so while going through the book I've been playing with things along the way so that I understand how things tick, but I've hit a fairly significant roadblock.

What I am trying to do is turn the Gate class that they've shown us into more of a "staircase" becauase the way the code works as is, you can only have one gate in the entire map, which greatly the level of complexity I can have in maps.

So say I have a staircase that goes from a map called "Second Floor" to a map called "Third Floor". I will have a corresponding staircase that goes from the "Third Floor" back to the "Second Floor". So what I want is for the capturing staircase to allow a player to preserve their position, when we change maps on them. That way, each map legend in the map.plist only needs two staircases - one for all the "up" stairs, and one for all the "down" stairs.

Now, I haven't even gotten to this point, but I do see a potential problem once all that gets solved... because the player's position will be standing on a staircase when the map changes, it might throw us into an endless loop of warping back and forth... but that's a fairly easy problem to solve... the easiest way would be to have the staircases locations slightly offset in the plist, or repurposing the code used to make sure that a spawned object goes in an open space to drop the player near the staircase, but not really on it.

Any help you can give me is GREATLY appreciated... I'm completely at a loss here.

[StealthyCoin]

What prevents you from having more than one gate/staircase?

[FreakSoftware]

Keep track of a variable which says that you just switched levels and should ignore 'collision' with the staircase until the player stops colliding with the staircase. In other words, when you switch levels, this flag is set to true, the player will be colliding with the staircase (because he's position right on top of it), but since the flag is true, it doesn't zoom you off to the previous location. Once the player moves off the tile, the flag is set to false so that if he moves back onto the tile he's zoomed off.

Or don't use tile-specific collision and use edge-of-the-tile collision and just always position the player so they are away from the edge of the tile when they move from place to place. Think Zelda on NES.

Just some quick thoughts.

[Kingbry]

Thanks for the replies guys!

- the reason you can't have more than one gate on a map is because the map-switching code does not preserve the player's position when it switches maps... instead it scrolls through the map array for the player's starting position on that map, just like it does for every other object including floor, wall, various monsters, etc...

So the way I think that I need to solve the problem is to change the map-switching code to preserve the player's position along with the other stuff (namely the keys it is holding, it's health and it's score). I believe that the position of all objects is in an NSPoint. There is one function that writes the essential stuff into a dictionary, and then another function that sets the players attributes to match the contents of that dictionary.


- I did think of having the HasMovedOnMap flag to handle the potentially endless loop. But I can't get to that point yet. :D

[Kingbry]

So I am still stuck. Here is what I have now:

These functions are in the player class.

- (NSDictionary) capture
{
[super capture]; <-- only sets the captured_ flag to YES.
return [NSDictionary dictionaryWithObjectsAndKeys: [NSNumber numberWithInt: score_], kCapturedScoreKey,
[NSNumber numberWithInt: health_], kCapturedHealthKey, keys_, kCapturedKeysKey,
[NSNumber numberWithInt: playerIndex_], kPlayerIndexKey, nil]];
}

and then

- (void) restoreFromCaptureDictionary (NSDictionary) captureDictionary
{
[super restoreFromCaptureDictionary: captureDictionary]; <-- which resets the flag.
[self setScore:[[captureDictionary objectForKey: kCapturedScoreKey] intValue]];

with similar statements for the health and keys.



Then the Gate class calls both of these if a player moves onto a Gate... as well as the map class function that switches the player(s) to a named map... but I don't think that code has to change if I add the NSPoint info for the player's position to the capture / restore functions, right?