Main menu

Monthly Archives: October 2005

Post navigation

More updates on the game development front. The game is turning out to be pretty fun and challenging. With the new bug types, it makes it very challenging to predict the bugs movement. I have a few more bug type ideas that I’ll be experimenting with that could prove to be quite challenging and interesting.

List of New Features:

The game is now fully playable (rounds, score, etc)

The frog is now drawn with a bitmap image instead of circles and lines

I’ve been developing this game on a PowerMac Dual 2GHz G5 with 1 GB RAM. The game was designed to run at approximately 60 frames per second. The animation was smooth and all the game objects moved at their correct speeds.

Last night, I decided to move my development over to my aging PowerBook 800 MHz G4 with 1 GB RAM so I could work on my code while watching the World Series on my couch.

Boy, what a wake up call!

Everything crawled on the screen. My frame rate dropped to about 30 frames per second and the whole thing became unplayable.

So, in comes the major refactoring task in order to support time-based animation and movement. After a long night, it all seems to be working now.

I keep track of time elapsed between frames and then calculate the percentage difference from the 60 frames per second. Then take that percentage and multiply it against the movement constants for each game object. This seems to take care of all the problems — though I probably need to test it out on some different processors when I get the chance.

Just about every game will need collision detection of some form. If you are using Cocoa and Objective-C for your game programming, then you’re in luck. There are a bunch of easy to use methods that can save you some serious time.

For Bullfrog, I’ve started with an all developer graphics based approach. All game objects are created procedurally. For the time being, I’m using no sprites and very little animation. Later, I’ll add these things, but for now, I’m concentrating on the game play.

The biggest challenge I’ve faced to this point was how to handle collision detection. The bullfrog attacks by flicking out its frog tongue to catch the bugs buzzing around his frog pond. The tongue is drawn using the Cocoa class NSBezierPath and its instance methods: moveToPoint:(NSPoint) and lineToPoint:(NSPoint).

This code is called when the game loop requests the frog class to draw itself. If the player is currently attacking, the frog tongue gets drawn.

One of the nice things about the NSBezierPath class is that it provides the extremely convenient method bounds. This gives you a bounding rectangle for the graphic we drew above.

Armed with bounds, we can use the fantastically useful Core Foundation function NSIsEmptyRect() combined with NSIntersectionRect to determine if two objects intersect or collide.

Since I’m using NSBezierPath to draw all my bugs, I can get all their bounding rectangles too. If I call NSIntersetionRect with the bounding rectangle for the frog’s tongue and each bug’s bounding rectangle, I can tell if there is a collision by checking the resulting NSRectangle with NSIsEmptyRect. This is illustrated in the following code.

There is one big catch to all this however. This may be because of the way I have implemented my frog’s tongue, but it seems that the NSBezierPath object returns a NIL instead of the correct NSRectangle when the frog is facing in one of the cardinal compass directions: 0, 90, 180, 270, or 360 degrees.

To get around this issue I needed to construct my own NSRectangle whenever my frog was facing one of these directions.

Ah, the joys of trigonometry. It’s been a long long time since I needed to know how to find points on a circle and how to determine the length of the the adjacent side of a triangle or remembering what a hypotenuse is.

One of the initial steps of getting my new game, Bullfrog, developed is movement. The player is a bullfrog, if you hadn’t guessed. The frog can rotate 360 degrees and can jump forward. So to move to a given point on the screen, the player would rotate the frog to the desired direction and then jump forward until reaching his destination. Simple enough, right?

Not if you haven’t looked at geometry or trigonometry functions for 15 years. How do you move a frog in a compass direction across the screen? Well, off to Google to search and search and search. One problem with searching on the internet, is you need to know what you are searching for.

Eventually, I figured it all out and found the right formulas. So to save myself time in the future and help my ailing memory, here is the code I wrote to handle these calculations. Maybe, it’ll benefit a reader as well.

Code fragments are in Cocoa / Objective-C:

#define PI 3.14

double DegreeToRadian(double degree)
{
return (degree * PI / 180);
}

double RadianToDegree(double radian)
{
return (radian * 180 / PI);
}

All this trigonometry stuff needs to be done in radians. So these functions convert angles back and forth from radians and degrees.

This code gives us the destination point. We send in the center of our circle or frog, the direction or 360 degree angle we want to move in, and finally the radius or distance we want to travel. We get back an NSPoint or (x,y) coordinates of or landing point.

While dreaming up an idea, I decided that I would start from the prototype I already have. It wasn’t far enough along to really be specific to any one particular game idea, so was easy enough to change.

So with a small stepping stone already written, I just needed a game idea to fit my requirements in order to get started.

The green circle looks like a big frog to me. It was originally intended to be just a temporary marker for testing movement inside my game view; but no matter, it’s now a bullfrog.

So… the idea.

You are a bullfrog. You live in a small pond. You have 60 seconds to catch and eat all the bugs flying over your pond using only your frog tongue. You must jump from lily pad to lily pad as they float around and eat yourself silly. If you miss a lily pad when jumping, game over. The goal is to clear as many levels as you can without running out of time. Each level gets harder by adding more bugs. Different kinds of bugs move at different speeds. Some bugs give you bonus time.

I’ve been thinking all day about ideas for the OMG Contest. It seems with the very short time requirements for the contest, I’m pretty limited in what I can do. Maybe, this is a good thing.

I started out with a blank piece of notebook paper and simply jotted down requirement ideas that might help limit the scope of a game that could be completed within the time frame on a very small to zero budget.

This is the list I came up with:

Game must occur in one location, room, or level

The content requirements need to be absolutely minimal: procedural graphics

No time for complex A.I.

Simple game controls (no joysticks, game pads, etc)

No OpenGL

Simple game play

Fast Paced

Randomly generated levels and enemies

If I keep to this list of requirements, it may just be possible to do this. Of course, now I need an idea that fits this list.

Contest Overview
The OMG (Original Mac Games) Cup is a new game programming contest established by iDevGames, in connection with Freeverse Software, to encourage unique Mac game development. iDevGames is proud to partner with the Mac platform’s leading game developer of original Mac games, Freeverse Software. The challenge of the contest is to create innovative Mac OS X games that emphasize engaging gameplay—in only six weeks! The OMG Cup builds on the success of our smaller contest, “21 Days Later,” and the industry leading annual contest, “uDevGames.” With numerous success stories of past entrants of our uDevGames contest releasing commercial games, we look forward to fostering the development of a new generation of Mac game programmers. – Carlos Camacho (Editor-in-Chief, iDevGames)
Official Start
October 18, 2005 12:01am GMT
The Three Fs of Winning
Fame, Free games, and Freeverse cash (Please see complete list below)

I haven’t decided yet if I’m going make a go of this or not. But it looks very interesting and fun. I’m sure they will get a bunch of top notch entries. It’s great that Carlos was able to sign up Freeverse as a sponsor, that gives the contest an air of professionalism and adds some great incentives.