On a brighter note, Nigoro surprised everyone and released La-Mulana II today. So... Imma go play that!

@mayorofgaming, why not submit a demo version? You have still worked hard the jam, just because it isn't finished doesn't mean you can't submit. You could get some really important feedback if your planning on continuing the game. A lot of participants will not have finished their project either. The decision is of coarse yours to make, keep us posted on your progress.:)

^it's true. Last year I didn't finish my entry, but I submitted a short feature-incomplete demo anyway and ended up getting some good feedback and great ideas for continuing the project. 

@saliv, when you play the games on the jam page it will now let you rate the categories.:)

@spring:  Well, it's all custom home grown code for me, so I don't know how applicable this would be to anyone else, but bits of advice I was going to impart were:

1) it helps to structure your code as test and then move.   Perhaps that's obvious, but I used to do it the other way around, move an object and then see if it hit anything and that's definitely a recipe for trouble!  The particular form I use for this is a method that takes a desired movement as input and returns what the resultant movement would be.   If the path is clear, you get back what you put in.  If not, you get back the portion of the distance you could move before a collision would occur.

2) Test the whole object for collisions, not just the center.  Again, maybe that's obvious, but it wasn't always so obvious to me!  Also, depending on your collision system, it may already handle this for you.   You can start just testing all four corners of a box around the object and get more granular from there.  I have had good luck testing the four corners plus four midpoints of a box around objects.   For larger objects you may need to subdivide more.

3) I've found it simplifies things substantially to divide your movements into separate horizontal and vertical components and test them separately.  So first test/do your horizontal movement and then test/do your vertical movement.   By only testing along the cardinal axis, it makes testing for collisions pretty trivial, you just pop your starting point into tile map coordinates and step left,right, up or down to the end point checking if you hit an impassable tile along the way.   Technically this means you are moving in a stair step or zig zag pattern but unless your character is moving more than a tile at a time it's a very useful approximation.  

4) Divide your movements and test incrementally.  Instead of trying to test a move all at once pick some maximum delta size and test that much movement at a time.  For example, instead of doing one test of 100 pixels at once, do 100 tests of 1 pixel each, or 10 tests of 10 pixels each.  (hint: half your tile size is a good starting poing for a max delta size).   I know this should be completely redundant for any proper collision system (a good collision system would do this for you), but if you're having trouble it can help by minimizing the size of error that can occur (your maximimum delta).  And trust me, unless your testing thousands of objects, a modern CPU can handle the extra work load of subdividing your movements a little.

5) Finally, don't test the starting point of your movements.   This might seem odd, but it helps by allowing the player to move if they do get stuck in a wall, giving them some hope of escape.    

@Saliv:  Thanks!   It was definitely close but I had about 3 hours to spare which IIRC is better than I did last year.  Of course, working right up to the end is probably just my natures.  Resisting the temptation to go back and make more changes in those last 3 hours was probably the hardest part of the whole thing! ;)

@all:  I posted this in the main OGA Jam #2 thread but I figure it bears repeating here as well...

do consider commenting on the submission page for each asset you used in your game.  Not required but it's always nice to let people know how you used there stuff, and it doubles as a nice way to promote the Jam.  :)

@withthelove these are some useful suggestions, and yeah 1 is a deathtrap, I don't do that either in Kymiball, It seems like my collision system isn't too different from what you're suggesting with the exception of point #3, maybe implementing that idea could help improve the collision system in the game or something.

Also, my tiles don't have any hitboxes by themselves, meaning that a tile collision in this game simply works by checking whether a tile is walkable at one point, which just defaults to the floored multiple of 32 of whaterver point you want to move to in the room (sorry that was very badly explained) . Basically,  the whole object which wants to make the collision is checked, but only the top left corner of each tile is checked. I guess that must be an unreliable system even though I hoped it wouldn't be.

@Spring:  I think I got what you are saying.  Basically the tiles are treated as solid blocks.   That's the same way I do it for Yulpers and most of my other projects.  That should work just fine.   The only reason you'd need to do anything more would be if you had sloped tiles or tiles with holes in them or something like that. 

I'll say implementing #2 and #3 was the thing that flipped my own tile based collision tester from 'sometimes it breaks' to 'rock solid'.   Can't say which was more important.   If I had to guess I'd say it was #2 that really mattered.  I think maybe #3 just made the code simplier to write and understand and so cleared out whatever bugs I had with my previous approach.   BTW my earlier approach was basically a ray cast between the start and end points.  

Yulpers does have a very solid collision system, I never encountered a getting stuck in walls bug in it.

I remember yearly tutorials for game maker almost 10 years ago using a collision system which relied on moving first and then pushing the objects out of the collision blocks if they made contact.

@Spring:  If you watch closely, you can catch Yulper's segments getting pulled through the ground occasionally, but this is intentional.   They have a maximum distance from each other that is enforced without regard to collisions.

@withthelone I see, gotta play the game again to notice that ^^