It enables the coder to engage in some late binding without engaging in a lot of casts or more elaborate metaprogramming: the enum index used for assignment is itself an assignable value and therefore can be passed around and manipulated if the algorithm needs it. It's a very intentional tradeoff of structure and long-term clarity for a faster turnaround to make design changes.
I haven't even checked to see if the final program uses it. It's the kind of thing, though, that you might go in thinking, "maybe I will need that", and it doesn't add too much overhead to your prototype.
You can have functions iterate through the array. You may want have special functions for each indexed item, but if there is something you want to do for all of them -- say save or load, you can iterate through the list.
It gives a consistent layout in memory, meaning you can save/load very simply. Using a struct puts you at the mercy of the compiler's struct packing and alignment settings.
The other stuff is more stylistic but I'd guess he writes a lot of assembly code, and the enum style translates easily to asm.
I would agree with you. Stuff like `changeMotive` could just take a pointer rather then an index and then you wouldn't need it to be an array. More-over, if you still want to be able to do that loop to check for underflow/overflow at the end, you could just `union` it with an array - use the regular member variables throughout the code, and then use array at the end.
But it was written in 97 so personally I'd give him a break. It might be a style he picked-up from coding on some earlier projects where it made sense (Say, for speed, or because the compiler was garbage).
I can't think of a reason. Having to index by enum seems like it could be error prone.
Also, in the init(), instead of looping over all indexes of the array and setting 0, couldn't a memset be used?