Day 1.5 recap

Posted by (twitter: @Eliot_L)
April 22nd, 2012 5:04 am

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: , ,


Leave a Reply

You must be logged in to post a comment.

[cache: storing page]