About ippa

Entries

 
Ludum Dare 27
 
Ludum Dare 21
 
MiniLD 24
 
Ludum Dare 19
 
Ludum Dare 18
 
Ludum Dare 16
 
MiniLD 14
 
Ludum Dare 15

ippa's Trophies

ippa's Archive

Minimalistic pixely goodness…

Posted by
Sunday, December 13th, 2009 4:06 pm

… with a twist. Give it 4 minutes of your life and I’ll give you a smile.

http://www.ludumdare.com/compo/ludum-dare-16/?action=preview&uid=1087  <– Here it is.

Pixel Perfect Collisions

Posted by
Saturday, December 12th, 2009 11:16 pm

Every time I use pixel perfect collision in a game I try a slightly different approach, trying to perfect the algorithm.

First it seems very very simple. Let’s just check 1 pixel at the center bottom (at the players “feet”) for a non-transparent pixel. If there’s a collision, follow Y-axis upwards (say, max 5 pixels) until we hit a transparent pixel (non-terrain). Put player there. This will make him walk on the terrain.. and also climb 5 pixel high obstacles. Higher obstacles needs to be jumped.

Cool enough, just checking one pixel and we get all that.

But then you realise you can jump into the roof.. and player will only stop first when his feet head is way into it and his feet his touching the roof.

So you check another pixel for collision, one at the head of the player, now you can stop him when he jumps into the roof. It works well.

Then you start painting more levels, and soon enough you’ll make a pointy object. The player jumps into it, not hitting the head or feet, just the mid-section. Player falls down by gravity, head hits the floor of the pointy object, and the player gets stuck.

You could either not paint pointy objects.. or you could extend your collision detection algo. One of the reasons I went with pixel perfect collisions is that I wanted levelbuilding freedom, just being creative and painting whatever fun terrain in paintbrush or graphics gale. I WANT pointy objects. Makes for nice ladders the player could jump on :).

So, we add pixel checks on the left and the right side of the player so we don’t jump into pointy things. It works decent, but you realise just checking 1 pixel at each side doesn’t cut it in all situations, objects you jump into could be Very pointy. So you basically end up checking all pixels on all sides. A bounding box if you so will, and we check all the pixels along the borders of it.

This is totally ok if you got a fast get_pixel()-method for your disposal. Now, how I usually do small games is I have a “physics”-behavior which I plug in into my player-class. This adds some instance variables to the player-object, velocity_x, velocity_y, acceleration_y etc. Before each update() the plugin will read those and modify x and y accordingly. Then I land in the update() method of the player with my new x and y (the behavior even saves previous_x and previous_y for me if I need to revert to the most recent position).

So, I’m in player update() and I got a new set of x and y .. and I got my collision_left?, collision_right?, collision_bottom? and collision_top? methods (I do Ruby so “?” is totally OK in method-names).

Still sounds like this should be simple, but it turns out it’s not.

What side do I check collisions for first? Depending on what I start with I’ll get different player controls. If I start by checking collision_bottom? and reverting y to previous_y on collision, then checking left/right and reverting x to  previous_x on collision I will be able to stick the player to a vertical wall just be jumping (say to the right) into it and keep holding right arrow-button. And if I check right/left first there’s other effects.

Though this might an effect of first doing all the physics and then doing all the collision detection. Maybe it’s a must to them at the same time, and with that I mean, if a right arrow key is detected, you “fake move” your player 1 pixel to the right and if right_collision? is true, you revert instantly. And so on.

I want to end up with something simple and readable, and I feel it should be possible.

Here’s a screenshot of the game I’m fiddling with, to give you a sense of what kind of terrain we’re talking about:

ld_16_screen

Who’s got the perfect pixel collision algo with simple physics? (only acceleration_y / gravity is OK)

First Mini LD#14 c0dez

Posted by
Friday, November 13th, 2009 12:12 pm

So..

First screenshot:  http://ippa.se/ghost.PNG

Rubyc0de @ http://github.com/ippa/ghost

You just died, floating above your cross… such a tragedy..

The Eternally Grey! Released!

Posted by
Sunday, August 30th, 2009 7:29 pm

After tons of  last minute tweaks and fixes I’m done. As they say, the last 0.1% takes 99.9% of the time ;).

I’m happy how it turned out, and I got to put my new ruby/gosu framework Chingu ( http://github.com/ippa/chingu/tree/master ) to the test.

Oh.. and don’t awake him…

screenshot

My LD15 Setup

Posted by
Friday, August 28th, 2009 8:48 am

This is my first Ludum Dare, but I’ve competed in smaller ones before.

Main language will be Ruby, since it’s just so sweet. OpenGL  2D gfx with Gosu (http://libgosu.org).

Gosu is available for Ruby and C++. Good stuff.

On top of that I’ve worked on my own framework this summer called Chingu ( http://github.com/ippa/chingu/tree/master ) which builds on Gosu.

Chingu adds game states, easier input handling, animation, text and particle classes and a bunch of other useful stuff.

Graphics: Inkscape and probably TileStudio ( http://tilestudio.sourceforge.net ) for pixelart / animations.
Music: Reaper ( http://www.reaper.fm ) – amazing DAW. And a bunch of VSTs on top of that.
Soundeffects: most likely http://www.freesound.org/

 

I have no idea why I got doublespaces between some words. Tried editing with both latest firefox and latest IE and it behaved the same way :p.

[cache: storing page]