Log In  

Cart #33833 | 2016-12-21 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
1

P#33834 2016-12-21 05:38 ( Edited 2016-12-31 18:59)

:: tlm

I'm sorry, but the collision detection in this is too much of a mess for it to be playable. I figured out the actual puzzle easily enough, but if you leave yourself with too small of a gap (that you intend to go through later), there's no way around it, you can't walk in even when, visually, it looks like you should be able to.

P#33836 2016-12-21 06:35 ( Edited 2016-12-21 11:35)
:: enargy
1

Cool game, Shadow!

Like tlm mentioned, for this kind of game, predictable movement/collision is really important.

Here's a quick update that implements a cell-based type of movement instead of the free movement in the original:

P#33860 2016-12-21 12:52 ( Edited 2016-12-21 17:53)

Thanks for the feedback. The problem I had was that the characters are 7 pixels wide instead of 8 so that's why you can't fit.

Furthermore its easy to overshoot your intended destination due to not using the cell based movement.

The update by @enargy is a lot nicer to play :) I've just had a look at the code and I understand your changes: "a curator in motion stays in motion until it is %8 == 0". Newton/Winston would be proud.

P#34358 2016-12-28 08:57 ( Edited 2016-12-28 14:10)
:: enargy

@TheShadowHost : Yeah, having off-sized sprites can make collision more involved if you let them move freely.

The other way to solve this is to associate a rectangle 'hit box'. Then you update that as you update the sprite (using an offset) and use it for collisions.

Can't wait to see what you make next.

P#34532 2016-12-30 14:06 ( Edited 2016-12-30 19:06)

cute :)

I love the theme
and the sprites
:)

P#34614 2016-12-31 13:59 ( Edited 2016-12-31 18:59)

[Please log in to post a comment]

Follow Lexaloffle:        
Generated 2020-02-25 15:35 | 0.033s | 2097k | Q:42