My intention was to move the fracture method out of the kxFractureCube class to make it non-member non-friend. But once I started reviewing the method I immediately saw inefficiencies and potential expansions. First I refactored it to compensate for kxBox independent dimensions. Before, if the box wasn't a cube, it would break. Fixed that. Then it was trivial to change the method's parameter from an integer to a vector3 so you can now fracture the box independently per axis. That is, you can have it fracture in half on the local X axis, into thirds on the Z, and not fracture in the Y, etc. Here, a picture will help:
 |
| before kxBox::Fracture( 2 ); |
 |
| after: kxBox::Fracture( vector3df( 4, 2, 1 )); |
Good game design involves both a strong grasp of abstract rule systems and a practical hands-on iterative approach: skills which are at opposite poles. If you’re good at the former but poor at the latter, get other people involved at the earliest possible time when feedback is useful. This is where the tried and tested “release early and often” concept comes in.
ReplyDeleteOne word of warning: most gamers find it almost impossible to evaluate gameplay without some decent art on top. Game Developer
Thanks for the comment, Mike!
ReplyDeleteYeah, I'm not much of an artist. I'm an engineer more interested in making it work with elegant functional code. Once my maxscripts for creating levels are up to at least a version 1, I want to find some designers to help me add that flair!