2. Parallel arrays vs. Objects. The OO way is obviously with a Particle object for each on screen particle, yet with high numbers allocated this may be GC and pool unfriendly.
Um, I don't think so... unless you intend to treat each particle as a uniquely identifiable object that you operate on as individuals? (which IIRC would be unusual for a particle system?). Otherwise, that is not the "OO way", but is symptomatic of a misunderstanding many people have about what OO is all about (IMHO because it's tricky to understand, got taught originally by bad teachers, and then large numbers of people who didn't understand but thought they did tried to explain it in simple terms, and now everyone's confused

. Took me - literally - years to meet a good teacher who also fully understood it and could explain it to me properly).
The OO way would be to identify the thing which has:
- data
- methods which only operate on that data.
(which would suggest to me you only want to work with groups of particles, rather than individuals)
To my mind, this is reinforced by the fact that you tend to emasculate OO if you ever knowingly attempt to assign objects in a way that will be hard to maintain (e.g. if it crosses boundaries that you just know you'll need to split apart, or does NOT cross boundaries that you know you'll NEVER need to split apart).
AFAICS this implies that each "set" of particles should be an object; if you intend all articles from an emitter to have one behaviour (which is sensible) then you would define your set as "everything from a particular emitter". However, it would make sense to slightly decouple this and add the rider "...created in a particular timeframe" so that you could do runtime alteration of the emitter, perhaps change it's sparks from blue to red - i.e. you would have all it's emitted particles in one set, and then call a method "nextSet()" or simliar on the emitter that would cause it to switch to using a fresh set (i.e. because you want to treat the new particles differently without affecting the old).
FYI this is related to mobs in survivor - we do everything at the mob level, and monsters are just raw basic data, to the extent that many things you might expect us to store on a monster (like the particular skin, or 3D model) we don't - you have to query their containing mob object instead. Although they do have full objects backing them this is mostly because Xith needs a 3D object for each to put in its scenegraph, and partly because java has no structs - so it's a PITA to store small numbers of monsters (only a hundred or so, max) in custom struct-like data structures, instead of just being lazy and using objects
