If we knew you were comin', we'd've baked a cake

Tag: iOS

Image naming conventions for iOS and Android apps

Having a basic naming convention for the images in your mobile app can make your asset library a lot easier to manage. After working on some iOS and Android apps, I’ve come up with a method I think works pretty well. The basic rules are pretty simple:

  1. All image names should use only lowercase letters, numbers and underscores, like this:
    some_image_name.png
    another_one.png

    Do not use uppercase letters or special characters (Android doesn’t allow them anyway). The obvious exception here is that iOS retina display images will be have “@2x” appended to the name:

    basic_icon.png
    basic_icon@2x.png
  2. Do not put images in subfolders. If you use iOS xcasset libraries, use only ONE xcasset library for images. There are several reasons for this:
    • In Android, subfolders aren’t allowed for images
    • All of your images can be found in a single location, so nothing is hiding
    • It prevents accidentally giving the same name to 2 different images, which can cause all sorts of problems.
  3. Name all images by category like this:
    category_subcategory_imagename.png

    or you might think of it like this:

    folder_subfolder_imagename.png

    You still get the organization of folders without needing to use folders (which isn’t allowed in Android anyway). The other benefit is that images are grouped together alphabetically:

    home_header.png
    home_next_arrow.png
    home_prev_arrow.png
    login_label_user.png

    which is especially handy when using XCode’s Interface Builder for your layouts in iOS. The dropdown menu for images can get pretty long, so having them organized alphabetically by section makes it a lot easier to deal with.
    I tend to make the first word in the image name match the name of the app section (home, login). In cases where I need an image in multiple places, I create general category names like this:

    button_back.png
    button_next.png
    icon_check.png
    icon_trash.png

    Note that this also prevents creating multiple versions of the same basic icons. When I need an icon, it’s easy for me to see whether or not it already exists in the assets.

  4. Create a category for images that you want to delete later. I often use screenshots of design layouts to help me layout my views in Android Studio or XCode’s Interface Builder. I name them:
    comp_home.png
    comp_login.png
    comp_registration_1.png
    comp_registration_2.png

    Later, when I’m packaging my app for release, I know that I can trash anything in the “comp” category and it won’t break the app (well, it SHOULDN’T break the app).

  5. Give placeholder assets their proper, final names and correct dimensions (when possible), but make the image obviously wrong. Some people like to add red “FPO” lettering to these images. I personally like to add magenta backgrounds to image assets that I need to replace. Either way, it’s a glaring visual reminder that says “FIX ME PLEASE!!!” Giving a placeholder image the correct name and dimensions makes it easy to drop in a new file to replace the placeholder without combing through the files to rename or resize anything.

Of course, the key to this system is making sure that all of the other developers on the project are also using these rules. If everyone does it, managing your assets can be a lot less painful.

iOS Game Development – Prototyping Part 1

Another post in my iOS game development series

I strained my back last weekend (I’m getting old), so I’m spending a lot of time sitting down these days, recuperating. On the bright side, I’ve had time to start prototyping the Bouncing Babies clone I’m building for iOS. You can see my progress below:

If you want to check out my code, you can clone the GIT repo. Here are a few notes about the prototype:

I don't have any "levels" in the game yet. So far, it just feeds you one "baby" (yellow ball) after another until you get bored. I was just trying to test out the bouncing and the controls. I will add escalating difficulty in the next week or two.

Since this is a prototype, the code has almost no comments and the structure is a bit of a mess. Prototyping is meant to be quick and dirty. The idea is to get a working demo as fast as possible and not worry about the architecture. This helps define what's involved in building the real game. Ideally, you should throw out the prototype when you're done with it.

You'll need a copy of the Flash CS5 IDE to compile the demo. I'm comfortable coding in Actionscript, so I can build faster in Flash than any other method. I decided to sacrifice open-sourciness for speed in this case. I put all of the code in Actionscript class files, so you can dig through the code without Flash CS5 if you wish.

Realism and simulation are often unnecessary. In this game, I want the bounces to be equal distances apart. If the bounces were realistic, they wouldn't be equally spaced. But, I can make it feel right just by carefully adjusting the height and speed of each bounce. The game won't actually model reality, but a user won't notice because it feels right.

Along those lines, I wanted the bouncing on screen to look good. I know that the path of a ball flying through the air is given by a second-order (parabolic) equation:

y = Ax2 + Bx + C
So, I used this basic equation to specify each bounce. From linear algebra, I knew that I needed 3 equations to solve for my 3 unknowns (A, B, and C), which meant that I needed 3 points on each bounce. These were easily measured directly from the original game, but it takes about 5 minutes to do the algebra for each curve. There are 4 curves. What if I decided later that I wanted to tweak the height or width of the curves? So, I spent a little longer solving the equations with a set of hypothetical points: (a,b), (c,d), (e,f) and used them to create a helper file in Flash. It's in the GIT repo as arcmaker.fla. I can input any 3 points and it will calculate A, B, and C for me. It also draws the graph on top of a screenshot of the original game so I can see it. Last, it spits out some text that I can copy-paste into my game actionscript files. I probably spent a little over an hour on this. I used to resist coding helper scripts and level editors, thinking that it would be a waste of time, but it almost always pays off. If you think a helper script might be useful, go ahead and make it.

Another way of making the game feel right is to speed up the ball a bit on each bounce. When the ball moves at a constant horizontal speed, it actually feels like it's slowing down (because my bounce paths are too wide). I use a multiplier to speed up the ball a bit on each bounce. I created another helper for fine-tuning this. If you right-click on the Flash demo above and choose "Show Testing Console", you can change this multiplier. I have it set at a value that feels okay to me. a value of 1 will not change the speed at all - try it and you'll observe the "slowing down" effect. a value of 2 will double the speed on each bounce, 3 will triple it, etc. After updating the multiplier, right-click on the screen again and choose "Hide Testing Console" to play the game with the new speed settings. Tweak the multiplier value until the game feels right. It's amazing how such a small thing can make a huge difference in how the game feels. Again, this is another one of those helpers that is worth the time to code because I can quickly try different values and see what feels right.

The prototype is coming along nicely. I just have to code in my levels to ramp up the difficulty. Then, I can start figuring out how to port the game to iOS.

In case you missed it, the GIT repo is here. Clone it and you can follow my progress as I continue working.

...And you thought you'd never use algebra in "real life":

game design - who says you'll never need algebra

Yes, smarty pants, I know I could have solved the equations more easily with matrices, but my matrix algebra is super rusty, so I did it old-school.

 

 

Creating Bouncing Babies for iOS – Game Design Analysis

Another post in my iOS game development series

Before I try to recreate Bouncing Babies for iOS, I thought I should take the time to do an analysis of the gameplay. This could prevent some wasted time during development.

First, I want to point out that the original game fits the definition of a Classic Arcade Game:

  • Single Screen Play
  • Infinite Play
  • Multiple Lives
  • Scoring and High scores
  • Easy-to-learn, simple gameplay
  • No story

The original game was shareware back in the DOS days (pre-Windows). I knew that the game didn’t use a physics engine (not even remotely possible with the computing power back then), but I wanted to get a good look at how it worked, so I pinched a gameplay video from YouTube and combined all of the possible frames into a single image:

bouncing babies game design analysis

The image shows all of the possible positions for the babies and the player firefighters. Note how the babies can actually occupy only a handful of positions. Even when you have multiple babies on screen at the same time, they can only be in these distinct positions. The speed of the babies can be slowed down by simply repeating frames.

The gameplay is simple. You control a pair of firefighters who must bounce the babies to safety. As you can see in the image above, the firefighters have only 3 distinct positions. There are 2 control schemes:

  • the left and right arrow keys.
  • the 1, 2, and 3 keys.

Either way, I thought it would be an ideal game for converting to touchscreen control. The firefighters respond to the controls with no latency – as soon as you hit the key control, your players jump to the corresponding position. This seems obvious, but note that it is unlike breakout or pong, where the player can place their paddle in almost any position and the challenge is getting to the correct spot in time. Bouncing Babies is much simpler. The challenge is simply to hit the correct key at the correct time.

Here is another image showing the positions of the babies when they hit the ground:

bouncing babies game design analysis 2

There is no collision detection system in the game. As you can see from the second image, when a baby reached the low point of it’s bounce, the player firefighters had to be in place to bounce it. If not, the baby went splat. Again, the game is all about timing. When the baby was just about to hit the ground, the game checked if the player was in place to bounce it. If yes, bounce the baby. If no, the baby hits the ground.

One interesting thing I noted when I created the images above – the third bounce arc is smaller than the second. It doesn’t just look smaller – there are fewer baby positions in the third arc than the second. This means that it takes less time for the baby to fly through the third arc. This makes the timing more complex than it would be if the second and third arc were identical.

I’ll be making some tweaks to the game design, but I don’t plan to make any changes to the actual gameplay – just the way that the code works. Stay tuned for more.

Don’t forget, you can follow my agonizingly slow progress on the github repo:
https://github.com/wastedpotential/bouncing-babies
I’ve added the images from this post to the SOURCE folder in the repository.

Creating a simple iOS game – Bouncing Babies

The first post in my iOS game development series

I like to create games that use interesting gameplay mechanics – things I’ve never seen before, or an interesting twist on a classic game. The problem is that new mechanics are difficult to code. If you want to make something standard, like a Super Mario clone, it’s easy to find a game engine that will do most of the work for you. But new mechanics often require modifying a game engine, or even creating one from scratch. This can be time consuming and frustrating.

I’ve been working on a conceptual game prototype for a while now and it has me pulling my hair out at the moment. To make matters worse, this is a “stripped down” version of a larger game that I want to create. I thought this light version of my concept would be easier to code, but it has turned out to be pretty complex too.

In the meantime, I’m interested in creating a game for iOS. So, I’ve decided to create a very simple game from scratch and blog about the entire process. I’ve never created anything for iOS, so I will have a lot to learn. I also plan to post all of my progress publicly on github, so anyone who wants to follow along can pull my code and see what I’m doing. Since this is a learning process, there will likely be a lot of bad code and blind alleys. And since I have a day job and a family, progress is likely to be slow.

With these constraints in mind, I’ve decided not to design my own game entirely from scratch because I will inevitably add some seemingly simple gameplay element that will derail the entire process. Instead, I’ve decided to remake a classic DOS game from back in the day…

Bouncing Babies was a deceptively simple arcade game that I used to play on my first PC – a Tandy 1000 (yes, I’m old). Here’s a video of the game:

Like all classic action arcade games, the gameplay is simple, but it’s surprisingly addictive. It was one of my favorite games when I was a kid and there are few good remakes of it. Considering my time constraints, this is a project that I might actually be able to finish in a reasonable time period. Additionally, the game code shouldn’t be too complex, so development shouldn’t require any weird hackery (famous last words). I can still do a full redesign of the graphics and animation, but the gameplay will be the same.

So, stay tuned for more updates as I dive into this. This whole project may go down in flames, but I promise it will be an interesting ride.

Here’s a link to the github repo I will be using:
https://github.com/wastedpotential/bouncing-babies

Page 2 of 2

Powered by WordPress & Theme by Anders Norén