Hook it up.

by midge 9. September 2014 02:13

From Urban Dictionary, the top definition of the phrase "hook it up" is "Make it happen".


Hook it up is exactly what I did tonight, in the more literal sense. I had the Prototype menu framework that I had set up and the actual gameplay in a separate Xcode project. Sadly, bringing these 2 projects together was a little daunting. Why? Well I've been obviously working on this project OFF and on for longer than I care to admit.

So all I really did was get so the menu will load the actual game. This may be exciting enough for me to start putting a little more time into this game again.

I had initially planned on making this for iPad and iPhone. I think I'm going to finish the phone version first, and then try to guess how much effort it would take to finish the iPad version. There is a very real possibility that I may just want the satisfaction of finishing this thing, and may not even care about the iPad part by then.

This whole thing feels like more of an exercise in time management and motivation than anything else.

Oh well. At least I did something tonight. Something is better than nothing.

Midge, out.


I did a tiny little bit today

by midge 1. September 2014 21:37

I hadn't worked on this thing in a while. I think I was either a little overwhelmed with the idea of merging or just not interested in the menus. Whatever the cause, I needed to get back to the idea of TINY little boring goals. The other day when I was thinking about how I hadn't worked on this in a while, I thought of another goal. Just open up my dev laptop. That's it. Turn the computer on and look at the stuff I hadn't been working on. Read some of the code.

I did that yesterday. It got it back on the mind, and here we are, I started working on it again a little bit.

All I did today was start merging the menu with the actual game play. I merged the menu code files into the original game project. Now the original game project loads the menu. Now I need to have the menu... use the actual playable game. I don't know if that made sense.

Hey, so at least I worked on it today. =]


[Game Goes Here]

by midge 27. April 2014 13:58

I worked on menu flow yesterday, pretty late at night. I did most of my work from midnight to about 3am.

I was over complicating things a bit, I think. I stripped it down to bare-bones, and mostly leveraged things I already know. I was thinking about writing a fancy level select screen with a UICollectionViewController, but I don't know how to use that yet. It's like a table view controller but much more powerful. Then I decided that was a stupid thing to waste my time on. I don't need to spend all this time for a fancy level selection screen if I'll have what, 3 levels tops at first? I just used buttons.

I basically wired the whole thing up. There's a main menu screen, a level select screen, a preferences screen, a placeholder for the actual game [Game Goes Here] and then a Game over Menu.

I broke these up into separate projects so I wouldn't accidentally break something on the game while making big changes on the menu.

The menus look awful, but I'm not focusing on that yet. I just want them to work, and that's what they seem to be doing for now.

It really is amazing how much time this whole thing takes.

My next steps are probably going to be going back to the game (not the menu project) and work on loading external resources (levels and scores) detecting when the game is over, and being able to restart the game level.

Then I'll probably merge the two projects, menu and game play.


Totes Ma Notes (Menu design planning)

by midge 22. April 2014 02:38

Above is my indecipherable chicken-scratch.

I was procrastinating today on working on game stuff. I think a big part of that was not knowing exactly what I was going to do for the overall menus and flow of the game. I feel like I got a lot done tonight and I didn't even touch a computer. Ummm, well besides this one for this blog post, but whatever - YOU touch computers.

Seriously though, putting this on paper helped. It was refreshing to work on a different part of the same problem. I want a simple, intuitive menu that is easy to use but easy enough to extend so that I can add new content/features later without too much trouble.

I like the idea of having a setting to skip the main menu and get right into your most recently played level.

I need to think about the level select screen which will also be the high score screen. I will probably only keep track of the best score per level. Although I could extend that to a list per level if I really want to.

You can see where I wrote "Show Add here" *ha, should be "Ad". I've been thinking a lot about where and when to put ads. I want them to not be intrusive enough to disrupt game play but I also would like to make a little tiny bit of money off the game if I can.

Also, where should the in-app purchasing go.

I think this at least got me on the right track for starting to figure out what I'm doing for the menus. I found this surprisingly enjoyable. I thought I would hate making menus. Maybe I still will, but until then I remain naively optimistic.


Quick update

by midge 21. April 2014 01:51


I didn't work on the game too much today, but I did get a (very) little bit done! I added the text for the current distance on the bottom left and the best score for the current level on the bottom right.

That's it! Not much, but it feels much better to do a little something than nothing.

I think I'm going to flowchart a very simple menu system that's extensible enough to add in the later stuff I want to add, then I'll make it in storyboard with low/no art to make sure it works.


Tilting animations, collision detection refinements

by midge 20. April 2014 01:37


I worked on the game twice today, once much earlier and once more just now. Earlier in the day I got the tilt animations working. I ended up just adding in some empty space around the resource images so that there would be plenty of space within the image to rotate without getting cut off on the edges. Because that rectangle used for the graphics is much larger, I no longer use that for collision detection.

I now use one box for the helicopter body, and one for the rotor/tail combo. I think this was a pretty nice compromise. Red one above is the body area, purple is the rotor. Yellow are the levelblocks that are being tested for collision. Above I just turned all of the level bricks on, but I'm only checking for collisions, not handling them.

Despite getting a decent amount done, I didn't feel super motivated today.

Here's some stuff that's left:

  • Crash animation
  • Detecting game over condition, starting crash animation/explosion. Basically the game over --> new game path
  • Menu screen
  • High score screen, storing high scores (probably no game center integration yet)
  • level data, possibly a level selection screen
  • Writing current score and best score on screen while playing
  • Improve level graphics with some textures.


That said, I think I'm going to work on the game over --> new game part and make some very very simple menus first.

I don't know if I'll be rolling my own menus or using some apple UI stuff, I might need to do some research.







Math is hard, let's go iOS programming!

by midge 19. April 2014 02:59


Good progress today. I probably put in about 2.5 hours. I'd like to explain what I finished, what I learned and all that, but it is getting late and I'm pretty tired. (So I said, then I went and did it anyways)

First off, I did get the helicopter animation in place for the character. That was very cool, and very immediately satisfying. Not that I was that far off from getting there last time.

What I immediately realized though, was that the image was probably too big to use and still have interesting game play. So I got to work on scaling stuff. Today I mostly worked on image transforms. I did some very modest refactorizations as well.

I noticed that I had been storing primitives (floats or ints) for a lot of rectangle sizes, but then I realized there was a struct for that (CGsize), so I started using that all over the place. Pretty simple change.

For scaling, there are built in easy to use scaling stuff for UIImage, but they kind of suck (I read). They leave you with some very blurry or jagged lines, just not nice things when scaling down. I found a piece of code online that scaled down pretty cleanly, so I used that.

I'm not doing scaling on the fly, but once at startup and then holding onto those UIImages in memory. Same thing for rotations.

Rotations were harder. My math is rusty, and I wasn't super interested in learning how to do the math for rotations, I just wanted them to work. I was guilty of some googling and pasting code here. However, the big block of rotation code I tried just didn't work.

I realized though, I could modify the existing scaling code for rotations by changing the CGTransform. I wish I knew this math and graphics code better, but this was not the problem I wanted to focus on. Fortunately, modifying the scaling code worked great (except it was upside down, so I flipped it =P). The only problem with it now is that the helicopter rotates outside of its original box, so some parts get cut off. This should be pretty easy to fix but I just called it a night because it was getting late and I was tired.

All this rotation stuff is just for the tilt effect when the helicopter climbs or dives. A lot of work for a stupid little effect that I think will look cool. And yes, I know I could have done this by just modifying the resources and saving a bunch more image frames. I didn't want to do that because it's tedious work, and it's less flexible. With scaling and rotation on the fly (I pun so hard) this is a lot more flexible. And I can tweak for what looks good on a whim, instead of spending all this time making resources only to realize I want more angles, more frames or a different size or something. Minimizing resources should hopefully keep the download very small.

So I guess the first thing to fix next is make sure the rotations don't get cut off on the edges. Then I'll get back to making the collision detection work with the new art, and slightly harder part, getting the collision detection to work with rotations... although I just had an idea to simplify the rotation collisions. I can test a big outer box area first (the actual animation frame) and only if collisions are detected there continue with the more fine grained collision detection.

I'm realizing that a lot of this code will be reusable for other personal projects, and that its awesome.

That's all for tonight!






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.


I made a helicopter animation today

by midge 15. April 2014 22:02


I'm glad I got this out of the way, this part was extremely tedious. I think I made the art at waaay too high of a resolution, It's probably going to lose all of its detail being shrunk down on a phone. I'll keep higher res copies available in case I want to use them on an iPad version later.

I may plug this helicopter animation into the game tonight, or that might wait until later.

Good progress today.



by midge 15. April 2014 14:42

I set up this website a couple of years ago, and aside from ripping off "Is It Christmas yet?" and putting a santa hat on the front page, I haven't really done much with it. I was planning on putting side projects up here, but I haven't really made much.

I started writing a simple ios game last summer, then I didn't touch it for almost a year. I've very recently just started working on that game again. There's still plenty of work to be done, but I've resolved to finish it this time.

I feel like I've recently shifted my mindset, and part of that is what has helped me get going on this thing. I procrastinate. A lot. I think I always have. When I'm anxious about getting something done, I have little rituals that I go through. In college it used to be some bullshit like I had to have a redbull and some other things at hand. I couldn't start studying into everything was "right". Looking back now, I know that was just an excuse to delay or look for some sort of distraction. I've had a few ios projects that I started with great enthusiasm and told friends about, only to burn out and lose interest. Unfinished. I've got plenty of those.

I think part of it for me was fear that I wouldn't live up to my own standards. I consume a lot of the things I like. I read books I like, play games I like and watch shows I like. Consuming good things sets the bar pretty high for your own work. The feeling that what I do might not stack up, might make me feel or look stupid is sometimes paralyzing. It can feel overwhelming.

So about those shifts in mindset. I think I'm a pessimistic person by nature, and some of these thoughts may seem pessimistic, but I think they're weirdly freeing.

"Nobody cares". I think I got this attitude from the gym. People worry about everyone else watching them, thinking they are fat, thinking they are weak or whatever... but the majority of the time, the other at the gym are working on themselves and nobody cares what you're up to. Without feeling like other people are watching your missteps frees one up to experiment, fail, and learn - To get better.

I read a lot of programming forums and websites. Sometimes people post motivational things and whatnot. One thing that helped me get around the procrastination bit was "find one thing that you can do RIGHT NOW" and do it. Don't worry about the big picture. Don't worry if the task seems too trivial. Big tasks are made up of a lot of smaller ones. Usually when doing the small tasks I get better ideas, and I have the self-satisfaction of getting something done. Small successes snowball into larger ones.

I guess one final point. The first thing I make may not turn out awesome... There's a very good chance it will suck. It might not live up to my standards. So what? No big deal. It's easy to be a critic, but much harder to make things and put myself out there. I can improve on that project over time or move onto the next thing and make the next thing better. Don't worry about it. Focus on one thing at a time, because you can only do one thing at time. Divide and conquer.

So this is  little pep talk to myself and anyone else who finds themselves here.

I mean to update this regularly. Some of the posts may be more technical, some of them may be more high level like this.

The game itself I'm working on at the moment is a simple side-scrolling helicopter game.

Let's go make some stuff!




About the author

Hi, I'm Midge.

Month List

Page List