Hey all, this is my first time doing Ludum Dare. I’m still not sure yet if I want to enter the jam or the competition.

I’m thinking I am going to make a 2D side-scroller set on an abandoned space station in zero gravity. I will probably be writing the game in Processing.

I tried making a game like this once before, and did a movement prototype in 3D using UDK. The 3D math was very tricky, I’m hoping that a 2D version will be more manageable on such a short dev cycle!

I probably won’t be blogging much since I want to focus on finishing the game! Especially since I have a family function tomorrow so I won’t have the full amount of time.

I got a zero-gravity rigid body simulation working in processing! Thanks to the Fisica library (a wrapper for JBox2D.)

I’ve been thinking about art styles as well. I tried making an astronaut protagonist in the style of Cactus but it doesn’t feel quite right.

Here’s a screenshot from the current build which is just a physics sandbox:

I figured out how to switch my player between being controlled by the physics engine and manual control. When in free-fall you can make him rotate a bit. I also want him to cling to surfaces and the movement would be more like a game like Strider or Gunpoint where you can climb on walls. Once on the wall, you should be able to aim yourself using the mouse and then kick off the wall in the direction you’re facing.

This seemed like a good idea to go for manual control since I read a post about somebody who was frustrated with implementing player control through the physics engine.

No screenshot as it looks the same currently.

I figured out how to put the physics objects into groups and how to define a handler for collision events. I am now detecting when the player object collides with an object in the “wall” group, and telling the player object to switch to manual control then.

I’m getting tired, I think I will call it quits for tonight. I’m in good spirits as I feel like I made decent progress tonight. See you all tomorrow morning!

I was hoping I’d get some good ideas for this game in a dream last night. No such luck. But I’m well rested and ready to get back to work!

I finally got the player to “grab” onto a wall. The routine isn’t quite finished yet, but I managed to calculate the new angle of rotation based off of the normal of the surface the astronaut collides with.

Now I just need to implement logic to constrain his movement while attached to a wall, and allow him to climb and mantle around surfaces.

This page was helpful for explaining the math needed:
http://www.euclideanspace.com/maths/algebra/vectors/angleBetween/index.htm

I’m a little concerned that it’s taking too long to implement the movement and it won’t leave enough time for level design, etc. But the whole point of this game is the unconventional movement so it’s important to take the time to get the feel right. This may wind up just being a movement prototype and I will finish the actual game later. Hey, if Terry Cavanagh can do it, so can I!

I haven’t made as much progress as I had hoped for by dinner time, but I still am making decent progress. I wasted some time wrangling with some nasty undocumented features of Fisica (ray casting stuff) before I decided to just roll my own ghetto implementation. But the good news is that player movement is working now, pretty closely to how I had envisioned! I am able to specify walls as being grabbable or not. Just from messing around, it seems like some interesting gameplay might be to have a level with a combination of grabbable and non-grabbable surfaces so you have to ricochet around.

I’ve decided to release my first playable prototype. Download the game here. Brief instructions are below.

Instructions:

You can climb on light blue surfaces. You will bounce off of gray surfaces and debris.

When climbing:

Movement: WASD

Use mouse to aim where you want to go and click to kick off in that direction.

When in free-fall:

Rotate: A and S

Sorry, there’s not much else you can do to influence your direction of travel in zero g! 😉

The final game might have ballast you can throw out in order to get moving in a particular direction.

Had a family dinner tonight so I lost about two hours. I decided it might make more sense of the protagonist was a robot since he’s flipping around the level and not moving too much, sometimes quite brutally. It looks a little more natural to have a robot flipping around the level. Here’s my crappy robot art:

I played around with the prototype a bit to get a feel for the game. I also tried messing with gravity and found that it was interesting to have a bit of gravity in the level too. I think I’ll make a few levels without gravity and try a few with gravity as well.

Here are a few sketches of some level ideas I had. The straight lines are climbable walls, the squiggly lines are non-climbable walls. The triangle is the player and the X is the exit. The gravity of the level is listed at the bottom.

And if you’re interested, here is my to-do list:

 * Implement level exit with next level int - & special int for game over
 * Restrict jump aim to 90 degrees from contact normal in either direction
 * Replace jump line with line & cool looking cursor
 * Restrict cursor to set distance from player
 * Implement jump charge by holding mouse
 * Implement some of the levels I designed on paper
 * Story? Should probably tell the player when gravity changes - falling free bodies also helps here
 * Make a little more effort on the level art... static BG image might work
 * See if there's some way to keep the player from phasing through walls (the jump restriction will probably help with this)

Well, I’m getting tired, going to call it a night. I implemented exits that take you from one level to another. I don’t know how difficult it would be to try to implement a smooth scrolling level in Fisica so I’m just going to keep it simple and use single screen levels.

I have to admit I’m kind of bummed. I had hoped to make more progress today.

The good news is that I think I have a direction. I certainly have my work cut out for me tomorrow. Unfortunately there isn’t much time for playtesting and iteration. I do want to improve the art a bit… but more time spent there means less time I can spend on the gameplay. (And it takes a lot of effort for me to even make mediocre art, I’m not an artist…)

In any case, I’m already pleased with this as a movement prototype. I think there’s interesting gameplay to be had with this design, given enough digging and iteration.

It’s becoming pretty apparent that I’m not going to make the game I was imagining two evenings ago. However, I think it’s okay. I certainly learned a lot as this was the first game I’ve ever made where I integrated a physics engine on my own. I’m hoping I’ll be able to polish what I have and add some levels. I think it will be better at this point to make a reasonably interesting game with crappy art than a crappy game with mediocre art which seem, unfortunately, to be my options. Maybe I can add enough to the background or some brief intro to at least express that this is occurring on an abandoned space station. Which was the reason I decided to do this game as I think that expresses the theme of being utterly alone in the black of space. My original plan was to have the player investigate why the space station was abandoned in the first place, and eventually find out that a portal had been found to some sort of alien world, tying into the larger theme of “are we alone?” in the universe.

But it looks like I’ll wind up with more of an abstract platformer, or a prototype of the other game.

I’m thinking for the next LD I’ll try to get a team together and do the jam. I asked an artist friend of mine if he wanted to work together on a game for this jam but he was too busy this weekend. Like I said I am not an artist and making art is a real chore for me, but I think the game would be improved by it.

My remaining to-do list:

High priority:
 * Implement some of the levels I designed on paper
 * Add in-game play instructions on level 1 - maybe an image
 * Title game, don't forget to change program title also
 
 Medium priority:
 * Allow player to mantle around corners in climb mode
 * Make a little more effort on the level art... static BG image might work
 
 Low priority:
 * Restrict jump aim to 90 degrees from contact normal in either direction
 * Replace jump line with line & cool looking cursor
 * Restrict cursor to set distance from player
 * Implement jump charge by holding mouse
 * Story? Maybe not at this point...
 * See if there's some way to keep the player from phasing through walls (the jump restriction will probably help with this)
 * For final distribution, package each OS version seperately

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!

Tags: polar coordinates, processing

I’d appreciate some advice on whether my collison system can be salvaged or if I need to rewrite it.
My game is using polar coordinates and I am defining sections of arcs like so for the level geometry:

Right now I wrote checks to see if a point at polar coordinate (r, theta) is inside the region between the greater and lesser arc that makes up a solid object, like so:

 class Arc {
 //Not a true arc, more of a segment of one or a "Block Arc", but it's much easier to type.
 float startAngle;
 float stopAngle;
 float maxRadius;
 float minRadius;
 //...
 boolean collidesWith(PolarCoord point) {
 return !( startAngle > point.t ||
 stopAngle < point.t ||
 minRadius > point.r ||
 maxRadius < point.r );
 }
 //...
 }
 

(Full class is here.)

It appears my math doesn’t work out for arcs on certain intervals. Previously I had encountered issues with this code not working when a radian was less than 0 or greater than 2*pi, so I wrapped my radians between 0 and 2*pi which fixed it. But I need to define some arcs that start around, say, the radian equivalent of ~270 degrees and end at ~45 degrees, making the shape of the letter C and crossing the 0 degrees mark. This kind of arc breaks my collision check above.

So I’m thinking, I can either fix my math for the check somehow, or abandon this method completely. Unfortunately I can’t find many resources on how to do this type of collision check properly. I couldn’t even find what these arc segment shapes are actually called.

In addition, I’m seeing occasional tunneling issues and would like to switch to doing an arc segment + line segment test for continuous collision instead of just an arc/point test.

The alternative I thought of was to define my arcs based on a vector at the center and an angle, and use the dot product to the player to do my collison checks, similar to the FOV check described here.

But it will take time to do that and I’d rather salvage this code if possible. If anyone has any advice, please let me know.

Tags: arc collision, polar coordinates, processing

We’re currently 35 hours in and have some decent progress to show. I got a full player movement and collision system working using arcs to define platforms and walls. You can now run and jump around the level, and the ‘camera’ follows you.

Here’s a screenshot of what the game looks like now, complete with debugging info on collision arcs and background tiles:

I figured out a workaround to the issue I posted about earlier thanks to the help of some twitter buddies. Thank you also to everyone in the LD community who chimed in. I am splitting arcs that cross the polar axis into two arcs, and everything works fine so far. You can see the seam of the axis, i.e. 0 degrees, and the arcs that cross it have been split in twain.

I thought you all might be interested to see how we made this level and translated it into code, so here is a screenshot of that process in action:

Daniel designed a level on paper using a compass, and scanned it in so he could paint it in Photoshop. He then sent me the image, which I measured using a handy screen protractor (which doesn’t have a setting to measure angles clockwise, WTF!) and entered into the giant blob of setup code that is our one and only level. I worked out a function that adds a ring segment based on its start and stop angles and ‘valence’, i.e. what level it’s on. It figures out the maximum and minimum radius of each arc segment based on the even spacing that Daniel set up in his design. So that has sped up the process quite a bit. You could say that without it, the process of making levels would be too protracted. Ba-dum psshhhh.

Now, for some technical rambling…

I’ve been having some pretty disheartening performance issues in Processing.  It’s a prototyping tool that excels at real-time procedural graphics – it doesn’t do so well when you expect it to be blitting bitmaps to the screen at 30 FPS. As soon as I threw in some background art, the framerate dropped significantly. I tried reducing the size of the art and scaling it up in-engine but the exact same issue persisted. In a hail-mary attempt, I rolled back from the Processing 2 beta to Processing 1.5.1 so I could try the now-deprecated P2D renderer. And what do you know, it performed way better than the Processing 2 2D renderer, Java2D!

Unfortunately, since the level is laid out in polar coordinates, it’s a pain in the ass to line up raster graphics since they are all rectangles. Also, my jam partner Daniel requested that we use raster graphics so he can paint them in Photoshop.

What this amounts to, for a 1024 x 768 game like ours, is a level that is 6144 x 6144. And we can’t build platforms out of standard square tiles since the entire level is curved. So we split the image up into 1024 x 1024 slices and tiled them in-engine in the hopes that we might save on performance somewhat, since I can cull tiles if they are out of the camera’s view. This doesn’t seem to be helping a ton.

Also, the image loading needs some tuning. I was loading everything at runtime but the load time for the game was awful that way. So I switched to asynchronous loading on an as-needed basis, but now I’ve created a thundering herd, each thread requesting a 1024×1024 image from disk at once! And there are 18 of these during launch to load the images at and around the player. I think I’ll need to throw these image load requests into some sort of prioritized queue so I can throttle them. I also need to make the game update steps independent of framerate.

So overall, perf is in pretty bad shape now, and I’m apprehensive about what things will be like once we start adding animated sprites for the player and enemies. Also, it appears as if the P2D renderer may have a really bad memory leak, my swap file grew to 8 GB when I was testing the game! Bleaahhh…

I’d like to learn openFrameworks for my next game, maybe I can optimize the rendering better. There remains the option of me trying to implement my own renderer on top of Processing’s P3D (OpenGL) renderer but god knows if that will help at all.

There’s a ton of stuff to do tomorrow. i.e. turn this movement/art prototype into a game!

Good luck, and rest well, fellow jammers!

Tags: performance, polar coordinates, processing