Get to da choppaaaaaaaaa!

by midge 17. April 2014 01:26

And by that, I mean work on work on my helicopter game side project.

Yesterday I was thinking about maybe I'll use the animation I had created during the day at night, that did not happen.

Tonight my list of things I might get to were:

  1. Animate the resources I had made in the game
  2. Add a tilt effect for when the helicopter is climbing/descending
  3. Update the collision detection, especially if the tilt changes the collision boxes.

I definitely did not get to #2 and #3 tonight, and if I'm honest with myself I only *kinda* finished #1.

I animated the helicopter in the game (Looks great, if I may say so myself), but I only animated it in a static location to the side, I did not move it into the actual player avatar yet.

If anything, the animation looks much better than the rest of the level, which is just green blocks at the moment. It actually kinda contrasts how bad the rest of the thing looks and makes me want to dress things up a bit. I am constrained by my choice of how I'm storing the level data, which is just 1 bit per block - On or off. I could change that so we could have some more textures, but I don't think it's worth it. I really like the idea of being able to save a whole level as a long list of integers.

I'm thinking the game may include 1 handcrafted but very long and challenging level (you're not supposed to "beat" this kind of game) and then maybe a random level that procedurally generates it as you go.

Another approach would be lots of short levels that are much easier and beatable. Actually, this might make people come back to the game a lot more than 1 long impossible level with a high score. I could color code the blocks of the level according to difficulty.

I've also decided I'm not touching iPad yet for the first release. I may initially release this as an iphone only game, then if possible change it to universal (iPad and iPhone). If that's not iPossible, I may just release a separate iPad version.

I may be tempted to change the game considerably for iPad though... with more screen real estate and a different aspect ratio, it could be a very different, and much better looking game.

When I was writing the collision detection code, I was very pleased to learn that ios had a method that tests if 2 CGRects intersect. Since I use CGRects all over the place, it meant I didn't have to write much collision code. One incorrect assumption I made was that CGRects could be rotated - They cannot be rotated, they must be parallel with the X and Y axis. This could complicate collision detection a little bit. I write some polygon collision detection, but that's not fun and I really don't want to do that. I think what I'm going to do is a bit of a hack. When the copter tilts during sharp climbs or descents, I'm probably just going to use several smaller rectangles to approximate the collision area. So I can still use the existing rectangle tests I've been using, I'll just do more of them. The collision rectangles will be different based on the orientation of the copter, and the collision detection rectangles will be independent of the rectangles used for drawing.

I like the idea of the collision rectangles being a little smaller than the graphics. That way a player thinks "Ooooh close call I barely made it" instead of "What the fuck, I did NOT hit that brick!".

Some stupid problems I ran into tonight:

   I was setting the background color black and I couldn't figure out where at first. This was a problem because the helicopter rotors are dark and they need a little more contrast to show up. One of the earliest methods I wrote did it, so I changed the background color to a light blue. Now you can see the rotors fine. It makes me want to change the blocks to more of an earthy green instead of the obscene bright green they are now.

The methods I was using to draw the images was drawing them upside down. Apparently it was a lower level method that didn't take device orientation into account or something. I think I was trying to use some CGImageRef method and I ended up using some UIImage method in the end.

Paths for reading in files in xcode. By default xcode puts everything in "groups" which are not really files in the filesystem, but fake groupings of files that are all in the top level folder. This means your path to any resource in the top level is just the resource name itself. I moved my images into an actual folder, but that meant I had to include the path folder in the path as well. Doh. Rookie mistake but it didn't hold me up too long.


Maybe it's a little premature to bust out a success kid. I don't care.

Doing it.


Add comment

  Country flag

  • Comment
  • Preview

About the author

Hi, I'm Midge.

Month List

Page List