Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(+1)

Hey Heckert!

Seems like a good start of a project. Too bad there's no actual work after the training day! :D

I bumped into one bug on the training day as well. If you line up the stones on the crossing so that there's no space between, but push the bottom one to the right and to the goal, the one above it gets stuck and you can't progress from 2/3 at all. Only restart works.

I would be interested to see where this game develops in the future!

Cheers!

(+1)

Did you manage to push the bottom one off the pathway?

Perhaps if you can reproduce it, provide a screenshot on where everything is located before you do that fatal push?

(+1)

No, it was not off the pathway. Here's the setup, so step 1:


And this is step 2:


So, I pushed the bottom rock to the right so it goes toward the second free slot, it gets pushed back on the track, but the 1st stone is ever stuck in the middle of the pathway, but I suppose in wrong position.

Hope this helps!

(2 edits) (+1)


Yeah, indeed. I didn't get into the exact same position but still got stuck... the detection if a target position in the grid is valid to be pushed on is incorrectly concluding that the target position is either blocked or not a valid position at all, so the check returns "I can't be pushed in that direction"...

Sometimes you can't approach one of the stones when you come directly on the pathway and have to go sideways, too.

This whole thing is due for a re-write and my approach on doing it fails far too easily...

In my latest test (see screenshot) I got them both stuck and couldn't push them anymore at all, although the flag for being pushable was still enabled (it gets disabled when one of the target positions is reached so once one of them has arrived youn can't push them out of it anymore, which is what I had suspected was happening even though the other one in your case was still too far away to detect the target position and also it should pull itself to the target when it does...)

Good that you got a repro now at least! You do have a grid as a model where you either set the grid occupied or not and then moving the visual is built on top of the grid? I think that way it should be solvable quite easily. But then of course it means that you need to adjust the player movement against the grid if player can move freely. And still, in the grid solution if two neighboring cells are occupied the player can't get between and game is stuck. :)

(+1)

The player should (at least in theory) also just move in grid cells. When using a gamepad's analogue stick, when movement is registered it's normalized for a grid cell's length.

But the way I implemented it, I rely too much on mapping towards the tilesheet grid, so I may get some inaccuracies with detecting neighbouring cells and what state they're in. I should completely rewrite all that stuff to work in a proper grid array...