Isometric movement over impossible objects

I have an idea for a game that extends the kind of puzzles in the game Hocus, so I thought I'd try to recreate its movement system. This is proving tricky & I have a question for anyone with experience making an isometric game.

First of all here's what Hocus looks like:

& here's its level editor:

My first thought was to use graph movement, moving from node to node, having cases based on each node's connections to determine which move directions are possible, if there's an obstruction, where you stop etc.

The cases turned out to be simple for a closed impossible figure like a penrose triangle:

-If a node has link in the same direction as player's upvector then an obstacle is found. Player can move in direction of obstructing link or go back the way they came.

-Else player can move along any link within their current plane (eg. if player up is +Z they can move in any XY direction from that node).

Here's how it turned out: https://dl.dropboxusercontent.com/u/523 ... index.html

& here's the sprites I used (I'm not posting the capx because it's embarrassingly long-winded & messy):

The next step is to figure out how to handle various cases for crossover edges:

My current approach of handling each node case by case is getting hard to manage, especially for player z-ordering. So my question to anyone who's made a 2d isometric game: would iso movement make the movement & obstacle testing easier, & can you think of any tricks to simplify things?

I see you are changing the object's orientation based on it path.

That should give you some extra info for deciding how to handle a crossover.

One thing I see that would simplify the z-ordering is if you only did a hexagon at a time. Actually with that you could easily enough handle collisions and movement within a hexagon very simply. You could mask out everything outside the hexagon. This does introduce a different problem though, transitioning from one hexagon to another which is mainly a matter of changing the player's position. That the point I'm stuck currently, just need to come up with a clever way to do that.

R0J0hound so for movement/colls within the current hexagon the calcs would be done as with your isometric behavior, giving each block within the hexagon an xyz position etc (except using formulas that work for non- 2:1 isometric). Or did you have something simpler in mind?

mattb

My behavior wouldn't work here because the isometric view is for 2:1 instead of 60 degree isometric. It could be an idea to somehow work with it, but I haven't given that much thought.

My idea may not even be simpler. I've been working on a example off and on to get a working example of my idea. but I haven't put a lot of time into it yet.

The z-ordering is too hard if all the cubes are placed. So only sorting them per hexagon is much simpler. To actually sort them i'd use the filimation approach which compares all the blocks and builds a tree graph of what is in front of what. Which is what my behavior does and works great for sorting isometric in most cases.

The collision detection is simple enough. If the player and a cube are visually overlapping you can then compare their isometric positions to do a bounding box collision check in iso. You could populate a 3d array as a 3d grid of cubes as a lookup but it shouldn't be necessary.

Everything is per hexagon and is the player overlaps multiple hexagons, then each would need to be updated.

What i'm currently working on is a way to update the cube positions on a hexagon. For that I need to know which of the six sides the the blocks exit and the the order of each of the three axis (x,y,z). Like if only the y and z line were used like in your top right image: x in front of z, y and z the same, z in front of y. I can move any line forward by adding the same value to each isometric position, which won't change the visual location.

The player's position can be different per hexagon because of this order, so to remedy the transmission from one hexagon to another, it needs to keep track of what line the current block it's touching is on (x y or z).

It may end up not being easier than what you're doing but it works in my mind. Once I get it working I probably can identify some unneeded cruft and simplify it. It's just taking longer than expected because I haven't had much time to work on it.

If you were going to keep the number of hex cells relatively small I would just create a lookup comparison based on each hex tile in events.

Edit:

Was just thinking maybe the bitwise method might work here:

http://www.saltgames.com/article/awareTiles/

R0J0hound

I'm thinking now that the per hex thing isn't going to work with the latest idea I have:

Originally it was going to be just the player & a patrol enemy moving around the level & some gates/keys, but now I think there could be some interesting logic puzzles with toggle switches & moving platforms. So it'd be like a railway switching/shunting puzzle where you need to plan your route, how many times you pass over toggle switches...

Moving platforms that just turn on/off would be easier to do, but you could use that to drop enemies off the map. It'd be more interesting to move them or the player to a different place.

I might revisit this idea later & try it in 3d instead when I get the hang of a 3d engine (using teleports & split geometry to handle the impossible shapes like Monument Valley). I really appreciate you taking a look though. By the way you helped with my multiple-gravity box movement question a while back, here's how that idea turned out:

http://i.imgur.com/Wf74Wn1.gifv

http://i.imgur.com/n2GlT9j.gifv (using Chipmunk here for the lasers & collision filtering)

http://i.imgur.com/SFZWOHW.gifv

newt

good idea, that would be handy for doing tiles case by case since there aren't many combinations