## Off to a good start

Posted by (twitter: @Eliot_L)
April 21st, 2012 1:49 am

My first Ludum Dare Compo was the previous one, LD #22. I had a good time and I learned a ton, and have used what I learned to make several physics-based games in Processing for various jams afterwards. However, I felt that my LD22 game suffered due to my poor art skills, so I decided I wanted to team up for the jam this time with a talented artist, for maximum awesome.

I’m working on a jam entry for LD #23 with my friend Daniel. He had an idea for a metroidvania where you traverse a rather small planetoid, where the curvature is actually visible.

We’re cutting the metroidvania part and trying to make a 2d action platformer set on a very small planet. The idea is that everything conforms to the planet’s curves, even your shots.

Here are some concept sketches of the planet and possible level designs that Daniel drew, along with some of my own drawings explaining how I will set up the collision volumes (using 2D arcs) and orient sprites.

I was pleased with how much progress I made on coding tonight, especially since I have never written anything like this before. I am using a generic template I made for writing games in Processing that I am calling QEngine. I will be publishing this game on the TinyWorld branch of the QEngine git repo.

As you can see from this screenshot, I have set up a class to define an arc section in code, and draw it for debugging purposes. These will be used as collision volumes, and I will draw a sprite in the same location. I couldn’t find what the real name of this sort of shape is, it’s a sort of wide arc, or arc with a circle segment removed from it. Microsoft calls them “block arcs” in their software but I couldn’t find any references to that being a widely used term.

I vaguely remembered reading about polar coordinates, and after looking them up again concluded that they would be a perfect way to store the position of objects in this game. It should be simple to move the player around and test for collision with arc segments if everything is stored in polar coordinates. And I even found some easy trig to convert to cartesian coordinates when needed (i.e. for drawing.) Here’s a screenshot of collision in action – the player (the white dot) is inside the upper left arc segment, which is why it’s red:

To move the player, I just add or subtract from his radial coordinate (vertical position) or angular coordinate (horizontal position). I love that math is providing such an elegant solution to what I thought might be  a pretty hairy problem! It’s times like this I’m glad I’m writing the game mostly from scratch in Processing since I have the flexibility to do stuff like this with ease.

There is one bug that I know of currently, I’m not accounting for the fact that there are multiple representations of a single angle in radians, so if you rotate the player past 360 degrees, the collision basically stops working. But I think this should be fixable if I can find a function to normalize the angle or whatever, if not I can always force it to wrap around with some custom logic.

Yay math! Yay game jams!

Here’s a hopeful sign-off for a productive day tomorrow. Good luck everyone!

[cache: storing page]