coalesce notes (some story)

Idea: (shot down) a domestic drama about the life of the captain of the ship’s wife while he’s at war. Guns rotate like in Slipheed? Move forward, they spread, move back, they contract. Hold down the fire button & they lock. Need to work on the rotation of ships being part of the Ship class –– have the side-guns locked on to the side of the ship, rather than just have the same movement vector. Because currently they’re bumped around by the powerups. Also, they need to be destroy-able. Sprites for the ships + rotation of sprites. Moving background? – that involves redrawing the whole scene. But… don’t I already do that? I should draw & erase the ships to a BMP that’s the size of the whole level, and then draw the current viewport to the screen. Yes?

My goal should be to make my code as clean & understandable as possible first, & then go back & optimize at the end. For the Gunners, do I have them loop through the objects to pick a target?? Because I don’t need to. Naww, I just did extra testing to be safe. Take a look @ my collision code: clean that up. First off, the collision fn. should return a boolean.

Fix the attachments so they don’t bounce around. “fix” the missles so they can miss fix the flockers so they’re not batshit insane (x,y) of the powerups occasionally gets set to NAN… ?! I’m sure it has to do w/the collision detection on them, which shouldn’t happen. Maybe I should check for division by 0 somewhere…

mooooar coalesce notes

Get all the code that ships share into the ship class. Every enemy class also needs to be able to take at least one attachable (not that they necessarily will) Enemies don’t take powerups, but some can combine w/each other How does the main weapon get powered up? Gunner: creates a gunner attachment -powerup: increases firing rate Flocker: ? -powerup: adds flocking (& increases cohesion) to bullets *need more enemy types

• wideshot
• multishot
• laser
• waveshot?
• bigger bullets?
• an enemy that uses missles
• enemies (like the flocker) that don't necessarily have a weapon, but behave differently. These should upgrade the player's weapon in a reasonable manner, but not change the weapon.

*under which circumstances is a weapon replaced, and which upgraded?

• only the behavior-type upgrade, otherwise they replace
• all upgrade
• compatible weapons upgrade, otherwise replace

-in #2, the player should have an option to jettison the attachable.

coalesce notes (xn)

Weapon slots. They need their own firing rate & set of enhancements. It might be easier to break them off into a separate class.

Some unanswered q's: they're attachable, but what about detachable? – what happens if you pick up another type of powerup while using one?

solved. Attachables are now separate objects. A little tweaking is in order.

Also, better subclassing. Too much repeated code.

(x,y) coords should reflect an object's center, NOT its corner.

Mess around w/x,y,sizex,sizey,drawn_? and whatever the last one was. Do I really need all those?

cleaner code. And more testing! There's potential for disaster just lurking around a corner, I know it.

and more

Ok, so I’ve modified the sandbox so it’s a regular memory bitmap & thus needs to be blitted to the screen. Not much of a performance hit (if at all) on my Mac. Now to see how it fares in Windows. Everything is still line drawing, so replacing it w/bitmaps should help a bit.

The tough part is going to be determining which quadrant each vector is in. & I really should run tests on this. But I need to know what the right answer is, 1st.

Before I even get to any of that, I need to figure out this performance problem. Look at some examples / tutorials… See if I can spot what I’m doing differently (wrong).

I wonder if there’s some sort of objects-on-screen stress-test example? A blitting example, or something.

[trig. diagrams] v_x1f = v_x1 - m₂₁ • d_vxz v_x1f = v_x1 - m₂ / m₁ • -2(v_x21 + a + v_y21) / ((1 + a²)(1 + m₂₁)) [I don’t really know what this’s about]

what?! d = √(dy² + dx²)

So yeah, my math for that was completely wrong.

The flocking needs work. The little bit I did before work today, to implement an FOV for the bots, doesn’t seem to work.

How wd I go about “overloading” the math operators for vectors in plain C?

Okay, the ships(!) flock now but it needs tweaking. They’re pretty psychotic. I need to put a cap on their velocity… or something. And a better rule for when there’s no other flockers in view. Then flocking for bullets.

Enemies need to have a rule for when & under what conditions to leave the screen. So do powerups.

Enemies that shoot at the player.

Handle player death / game over

Bullet paths. Enemies following paths, too. Probably clean up my code. Take more advantage of subclassing.

I know it’s premature, but I’m thinking a bit about optimization, too.

I know unrolling loops is supposed to help, but I don’t have any loops I can unroll.

Lasers. A secondary ship.

multiple kinds of powerups.

Ship animations?

accelleration / decelleration? (very slight)

Missles. That’s what bullets w/variable paths should be used for. They’ll need a timer. They seek until that timer runs out (“fuel”?) at which point they just continue offscreen.

Want to do something w/fluid dynamics. Not sure exactly… Probably some sort of background animation.

Not now, but I will want to niceify the OS X version (& probably the Windows, too) – make them behave more like native apps. Menus, being able to close the window from the title bar, etc.

Missles. Missles need trails. Now, I see 2 possibilities for this. Have each “segment” be a distinct element - say a square - that gets drawn w/o reference to the other elements. OR: draw the trail as polygons connecting 2 elements.

Treat missles as multiple seeking particles that all start moving in different directions, but converge on the same target.

Theme: steampunk. cyberspace. demonic?

Some forms of missles encircle the enemy & create a containing sigil… or something.

Story? I like the idea of a secondary story like in the 1st Katamari Damacy where it’s about characters who are affected indirectly by the events in the game.

MARVELS

Ok; but that’s not important now. Missles, there should be a cap (upgradeable) on how many are onscreen @ once. if (# < cap>) fire_missle();

while (ship) {
  if √(dx + dy) < d {
    target = ship
    d = √(dx + dy)
  }
  ship = [ship next]
}

ok, missles are go. And they’re quite powerful. Don’t really like how they behave, though.

What next? New kinds of enemies? Further enhancements to weapons? Tweaks/improvements?

• Need bitmaps / sound.
• scripting.

short coalesce notes

Any file that refers to ships needs to be compiled w/the Obj-C compiler (so .c → .m) Any way I can cut down on the # of includes is good, too — more modular.