EDIT: Changing the name to Rover Wars.

{"name":"roverwars.gif","src":"http:\/\/static.allegro.cc\/image\/cache\/3\/6\/3689497099ba45c4f3b0c9427bd1d160.gif","w":300,"h":225,"tn":"http:\/\/static.allegro.cc\/image\/cache\/3\/6\/3689497099ba45c4f3b0c9427bd1d160"}
I made my first allegro game. Turned out good if I do say so myself. I called it absorber Rover Wars. It's kind of a multi-player competitive Osmos.

I'm gonna feature this game on my site, Cymon's Games, in February, but it turned out so well I've just got to show it off. I could expand it, add a score table to declare a winner after a number of rounds, add sound, but I'm gonna keep this one simple. It proves the concept. If it turns out that folks like this I may make those additions.

Download it compiled for windows and it's source here.

Note to self, allegro.cc forums uses html tags, not BBCode.

Fun game. A little confusing as to which ball is whose (whom? Err, Matt!) when you start however.

Pretty neat game dynamics, but its not that hard. I was able to win 3 times in a row. I think its a great base for something more interesting. Maybe make the screen larger (like a large virtual area that you can move through) and have things like negative balls that always take away some of your life?

Naturally the game is better against a human. The AI is pretty dumb. It just find the closest bubble and if it's smaller moves towards it and if it's bigger moves away from it.

Oh, and in the case of a jerk hiding in the corner, your bad for getting so big. You can take care of it by pressing F1 and starting over.

Great game! I haven't tried playing against a human, but I'm sure it's really fun. But what framerate is it supposed to run at? It runs really jerky for me, but I see little CPU usage. And I don't think it needs more than 2.7 GHZ

Thanks for that. Duh. If you have any hints for the frame rate people are complaining about. Maybe that's just the frame rate the game's moving at.

let's see... 10 frames per second. Yeah that is a bit slow. But if I drop that it'll speed up the game, and I don't know that I want that. I'll play with it.

This won't speed things up considerably, but you have several places where you do this kind of construct:

if (blobs[c].x - blobs[c].radius < 0)
  ...
if (blobs[c].y - blobs[c].radius < 0)
  ...
if (blobs[c].x + blobs[c].radius) > SCREENW)
  ...
if (blobs[c].y + blobs[c].radius) > SCREENH)
  ...

I would think that if blob[c].x is close to the left edge of the screen, it can automatically exclude the need for the check that it's against the right edge of the screen as well. You could rewrite this to:

if (blobs[c].x - blobs[c].radius < 0)
  ...
else if (blobs[c].x + blobs[c].radius) > SCREENW)
  ...

if (blobs[c].y - blobs[c].radius < 0)
  ...
else if (blobs[c].y + blobs[c].radius) > SCREENH)
  ...

Then, if you're by the left edge of the screen, you're not going to check that you're exceeding the right bounds of the screen also.

You may consider sorting all of your blobs. Since your screen is wider than it is tall, it's better to sort them along the x-axis. Then, when you are testing for collisions, you can eliminate all blobs that are too far away. This will at help with the framerate, since you're currently testing ALL blobs, even those on the opposite end of the screen.

And why do you (re)initialize the player_colors every time your gameloop() is called? Since the color values are fixed (not dependent on their sizes, or anything), call them within your init() loop a single time, and pass them into your other functions (if you don't want to just make them globals).

EDIT
<nitpick>

You can initialize everything using the single-colon, which even gives you the ability to set const-defined variables (or, well, consts ):

</nitpick>

No.

I'm using the allegro timer routines to control my framerate. It was my understanding this would fix my timing at a constant rate. Is that not the case? At the moment my framerate is a 66ms pause, which should translate into about 15FPS.

@OnlineCop - Investigating further turns out that early return statement caused false positives on the collision at diagonals which was giving me negative overlap which was causing me trouble until I figured it was negative overlaps and corrected the code for that in the collides_with function, essentially fixing the symptom while not getting at the root cause. Now that I've fixed that I'm guessing my check for negative distances is mostly redundant, but good to have.

Also, concerning your else statements when you hit the side wall. Yeah, that might be a minor, very minor, optimization. But concerning sorting the list I do not see an effective way to make that save any time due to the 2D nature of the board. Unless I do some sort of perpixel check on the edges of the bubble. That's why "check_collide()" (IIRC that's what I called it) does a quick AABB check before pulling out the more mathematically intensive Pythagorean's.

And double oops to initializing player_colors every time. Fixed now.

re: nitpick - Wow! I didn't know it worked like that. Obviously I'm still learning.

Setting the FPS limit below 30 for a game that isn't Tic-Tac-Toe is absurd.