gggmork
If you can make any sense of this post, congratulations
Posts: 2415
Registered: 06-07 |
Ha ha. There should be 512 by the way, not that it matters (8x8x8).
The functions I had rotated about the x y or z axis exactly only which is kinda ridgid (the cube was rotating in each at a different speed). I made a new function that allows rotation around an arbitrary axis (I think, haven't fully tested it). So basically you can draw an imaginary line anywhere and it should rotate around that line. Which probably means it can tilt up/down/left/right/tilt side/side, regardless of where it is currently pointing/facing.
It should be easy to expand/contract the cube over time by simply multiplying each x/y/z coordinate by a multiplier (because each coordinate "pretends" the center is the origin 0,0,0), and the cube itself has its own center which then is added to each coordinate. Projectiles probably won't be hard to add.
For the "photomosaic caco" idea in the OP, I thought about making the whole thing a sphere instead of a cube (because a caco is a sphere). But then rotating a sphere isn't very interesting because as you know, a soulsphere for example doesn't even need rotation frames because a sphere looks the same no matter how its rotated, whereas a cube has more interesting corners that rotate.
Also I realized an 8x8x8 cube of cacos (could be hollow too to save having to compute all the mass of "innards") wouldn't make a very high resolution image (if each caco is colored to match the pixel of the larger overall caco, then that's only 8 pixels wide.. something like 16x16 hollow might look better, or maybe a sphere.
Or maybe that'd be too much of a pain, it'd just be one frame of animation anyway.. multiple frames, like another when it shoots etc, would take forever.
I could store each individual caco in an triple nested array:
cacoArray[8][8][8]
OR just make it a single array:
cacoArray[512]
where each "object" if you will, in the array, stores an x/y/z/tid/health/shooting behavior/whatever.
I think an advantage of the former is I could immediately access a particular 8x1 plane of the cube or something, whereas the latter would need to cycle through each caco and ask "if x= bla" for each or something, which might be slower.
But the latter might have more freedom because you're not limited to an array-restricted cube form. Like a big complex thing like a giant hand or something doesn't map to a cube very well. Or the caco's horns are "extra" things that don't map with the sphere, so maybe its best to just have a 1d array. Or use either, or both, depending on what happens to map best.
I'd probably noclip the cacos too so the cube can shrink really small sometimes without them failing to warp because they're on top of eachother (I can still give the player damage or something probably by collision checking the cube with the player's hitbox).
I was gonna make it have attack patterns, and you could kill each individual caco until the whole thing was dead. Like in one attack, all the constituent cacos could come "alive" and break out of the larger caco mold to attack you as a group before returning to their grid locations again.
In another attack it could bounce off walls like a 3d pong ball, each time it hits a wall, projectiles could come randomly out of each side and ceiling or something + a quake, etc. And just kind of a visual effect thing, sometimes every other plane would rotate clockwise while the rest rotate counter clockwise. Not sure how successful or motivated I'd be to do this stuff.
Last edited by gggmork on 01-23-13 at 00:44
|
01-20-13 18:13 
