daniel-santos/flare — pull request #1 by daniel-santos (2012-04-28 05:37:52+00:00)
Title: Mostly refactoring

OK, so this is for some review and you may want a few things changed, so let's start.

This only has two things that change the game play (well, three I guess)
* Give Knights a bonus when doing melee attacks and using a shield, they have a chance to not be interrupted when getting hit. In play testing, this does make a difference, although it doesn't seem to bring them quite up to the same power level as a ranger. Perhaps this will improve with fire & cold weapons and/or other bonuses.
* Made gems sell-back at half their price instead of 1/4th.
* Range calculations are now made using actual distance [i.e., sqrt((a - b) * (a - b))]. This means that when operating on a range of 3, going from 1,1 to 1,4 will still be in range, but from 1,1 to 4,4 will not be. If you would prefer the old functionality, it's not too hard to change it back. Alternately, I can add 0.5 to range calculations and have it behave more like it was before, while still doing a correct range calculation.

So now for the refactoring. Primarily, this involved replacing statically sized arrays with dynamic types, like list & vector. My brain is a little fried, so I forgot exactly what all arrays I changed, but I tried to get the big ones.

So now Items and Powers are passed around as references (and pointers when needed) to actual const Power or Item objects instead of an index, where you have to to a lookup from some external source to get the actual object. This makes quite a few things much simpler, less verbose and more readable, not to mention reducing the number of compiled instructions.

I did a lot of source-code cleanup (that doesn't make much difference in executable size or memory footprint), like replacing a lot of somearray[something.index] by just caching the value in a local variable and re-using that. I've eliminated close to 100kb of source code doing this! (and readability is improved as well).

I've cleaned up most constructors to eliminate double initialization, by using member initializers. Also, I changed the pointers being passed around to various core objects into references, since they are much less problematic (you can't change them by accident, get a null pointer without trying hard, etc.)

I've added a simple Uncopyable class that just prevents the C++ compiler from generating a default copy ctor & assignment operators. This prevents accidental copying of objects (like when you meant to initialize a reference, but you accidentally tried to call the copy ctor). This is basically a rip-off of boost::noncopyable (which I think is a stupid name anyway, because it's not English, where "uncopyable" is) (see http://www.boost.org/doc/libs/1_49_0/libs/utility/utility.htm#Class_noncopyable for info on that).

I added a distilled 2d vector class template and typedefed an int version of it to Point. This way, your basic calculations & operations are built-in to the type and aren't implemented externally in some function, or even worse, in code scattered throughout the galaxy. it supports your basic operations like distance, length, normalize, dot product, linear interpolation, etc. I added a few non-member operator overloads to allow for interaction with SDL_Rect and such as well.

I did a little revamp of the CombatText system as well, mostly to make it more extensible. I wanted to add some other features to that (such as having the combat text follow the source and not the camera, like when you kill a monster and move) but I got side-tracked on too many other things. Now it will only require a little more effort and we can have combat text that moves at different speeds and has a longer duration. I thought it would be cool to add text messages for leveling up (that stick around and move up slowly) and for experience gains. Again, that part isn't done yet.

Bugs: There may be a bug left with the shield power. In one test play session, my shield wouldn't die and I'm not sure why, nor could I find a cause. I exited and re-loaded and never had that problem again (after another two hours of play).

I got a lot of whitespace changes encapsulated in a commit that I managed to exclude this time, hurray! However, this may cause some patches to be "fuzzy", but it's only because of this whitespace stuff.

That's all I can think of right now. I'll try to annotate some stuff later