mooooar coalesce notes October 25

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) October 25

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.

---

Particle →	Ship →	Player
		Enemy →	Gunner
			Flocker
	Bullet →	Missle
	Attachable

and more October 25

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.

coalesce notes (now with numbers) October 24

So the Mac version begins to experience slowdown at around 50 objects (on my computer, at least). The Windows version: 13. What the hell? It's got me stumped. What the hell? Spending most of its time in some directx_unlock fn. I don't know what that does. I should probably post a plea for help on allegro.cc.

---

m₁v₁ + m₂v₂ = m₁v_1f + m₂v_2f I know the momentum & stuff is conserved, but how do I figure it out? I'm looking for 2 variables! Say m₁ & m₂ are both 1. v₁ + v₂ = v_1f + v_2f 2 + -2 = 0 + 0

2 + -2

-2 + 2 seems this is "right" That's if it's head-on, however. I'm not sure about otherwise

I need to add the vectors somehow. But which vectors is key – it's not velocity. Momentum. But momentum needs to be conserved.

So if they have the same mass, the velocities just switch. Different masses, though?

m₁v₁ + m₂v₂ = m₁v_1f + m₂v_2f

m₁v₁²/2 + m₂v₂²/2 = m₁v_1f²/2 + m₂v_2f²/2

v₁ + v_1f = v₂ + v_2f or v₁ - v₂ = v_2f - v_1f v_1f = v₁(m₁ - m₂)/(m₁ + m₂) + v₂(2m₂)/m₁ + m₂)

v_2f = v₁(2m₁)/(m₁ + m₂) + v₂(m₂ - m₁)/(m₂ + m₁) sm = m₁ + m₂

But that's only good for head-on collisions. "scattering" is more complicated.

v₂ = v((2m₁) / (m₁ + m₂))cosθ v₁¹ = v …

more October 24

Ok gotta get to work. I need objects & I need them done. Then work on a couple different kinds of enemies, maybe, make it so enemies can't hurt one another...

---

I'm getting there... Lots to change. I'm not 100% sure even the code I've changed thus far is valid. We'll see.

---

Completed the switch to objective C. This'll be far better. Deleting objects is a little clunky right now... And I don't want to have to include the display.h in the object files. That's not such a big deal, though.

---

And... made the switch to Obj-C work in Windows. A couple minor changes.