I'm rewriting the game known as Chain Rxn flash game found on Facebook (http://apps.facebook.com/chainrxn/), or Boomshine on the "originator's" site (http://www.k2xl.com/games/boomshine/), and just have the early stages of the game up. Nothing fancy so far, and the code is more spaghetti than anything.
I have everything, for now, in a single file if anyone can give me feedback. What I am trying to do right now is make the ball grow from the size that it IS (roughly 16x16 or 32x32 pixels) to about 10 times its size, stay that big for a bit, then shrink to nothingness. Total time that it will be stretched and shrunk before being "dead" for the rest of the round: 3-4 seconds.
I could create another, larger, bitmap and reference that instead, using stretch_blit to either stretch up (from the smaller image) or stretch down (from the larger), though I don't know how that will affect the semi-transparent properties that each of these Ball objects will need. You can check out the flash counterparts to see what they need to try to look like when they "pop".
Suggestions and feedback? I'll be either updating my original post with changes, or adding new posts with code as I make modifications!
I'd say OpenGL would be easiest (allegrogl)
If you draw the balls as primitive circles (instead of a pre-created bitmap), you can easily change the size of them.
By using drawing_mode(DRAW_MODE_TRANS, NULL, 0, 0); in combination with set_trans_blender(255, 255, 255, my_alpha_value); you can preserve the transparency effect of the primitives.
Arthur: I've used OpenGL but not allegrogl, so I'll take a look at it; it seems like the most logical approach, since I'd really rather have an arbitrary shape (say, for example, changing the shape from a sphere to a rotating triangle or even a "chain link" so I can get away with making a knock-off without stepping on anyone's copyright) and OpenGL is the best way to handle that.
Schyfis: Would 'my_alpha_value' be black (you've no doubt seen the code, and may have seen that the surrounding color appears to be "black" around the outer edge of the balls) or a different value? Will I need it if I decide to try to use OpenGL as Arthur suggested?
I've used OpenGL but not allegrogl,
In that case, you can treat allegrogl as a convenience library for setting up an OpenGL window in a cross-platform way, and adding allegro's input, sound, file, and what have you routines to it. All regular OpenGL commands are available in allegrogl, plus it loads extensions for you automatically.
Would 'my_alpha_value' be black
I'm not sure what you mean. my_alpha_value is a value from 0 to 255, with 0 being fully transparent and 255 being fully opaque.
How's the best way to transition states over a period of time?
First, the balls need to be bouncing around and ignore all collisions with everything EXCEPT balls whose states are non-STATE_MOVING (or STATE_DEAD).
When a ball gets popped, it needs to grow for a short period of time, stay big, then shrink, and finally die.
I thought that keyframes would be the best way to go with this. Until they actual get popped, there will be no keyframe (or, there will be a single keyframe whose value returns the default value or size of the ball).
As soon as the ball collides with another popped ball, it adds four more keyframes:
(max_size, time_now + 2 seconds) (max_size, time_now + 4 seconds) (min_size, time_now + 6 seconds)
After 6 seconds, the ball dies.
Of course, there will need to be some sort of method of dealing with a dead ball so it is no longer updated.
Any ideas or thoughts on this?
Should I be using some sort of Event manager instead to be handing the Pop event instead, or each of the different life cycles, rather than keyframes? What's the best way to do this part in your opinion(s)?