Animations

Animation considerations:

* Each drawable game object (component) has the potential to have animations. Some might not. Do we make a distinction? Do we need to?

- We don't *have* to. If we solve the generic case (all drawable game components have animations), then we can simply say the static content is an animation of frame size 1. While this does require extra math for non-animated components, it should be minimal (currentFrame = (currentFrame + 1) % maxFrames), so it should be fine. If this bites us later, we can break the abstraction. Easier to have it in the first place.

* Each object that does have animation can have multiple animations: idle, walking, attacking, etc. So, they need to know about the sprites for those animations and also know
  what animations they correspond to. What is the best way to generically store those sprites/sprite sheets such that they correspond to the correct animations? Do we just
  store them one by one on creation in the object's generator class? This means they would be hard coded for now, but maybe we could abstract that out later on where they're
  all just read in by a text file or something.
  
- The "cleaner" (in my opinion) way would be to have multiple sprite sheets, one for each animation. This way, we can load up some kind of "animated" component. The game object would have one animated component per animation (idle, walking, etc). Then, the code that knows about it's state (if no keys pressed then state = IDLE) could just hot-swap it's animation to that of the "correct" one. This also allows us to do some kind of in-between state, like WALKING -> IDLE animation, etc.

As for how to load them, it's probably ok at this point to just rely on folder structure / hard coded values. The "correct" way would be to define a JSON file for each sprite's animations which would contain the animation name -> animation.png file (+ possible some attributes, like num frames, x spaces, y spaces), then just have a generator load those, storing them in its own mapping. In my mind, this is one of the easiest clean ways of doing things. In the future, all of our hardcoded stuff should be grabbed out of JSON config files (and correct ones written out if none exist, like how NGTS writes out a default NGTSSettings.ini if it can't find a valid one)

* Those animations then need to be performed according to the state of the object. The state component then might need to be expanded and the "animation" component (or should
  this just be an extension of the SimpleSpriteComponent?) then must know about the state component. Making the state component generic is probably the next step, where the
  player states are set in the player generator and all other object states are set in the respective object generator. This way the object's states correctly correspond with
  their animations.
  
- You can go either way on this. The SimpleSpriteComponent was meant to be a placeholder, but it actually has some value as it stands. You can either subclass it (SimpleSpriteComponent -> AnimatedSpriteComponent) or superclass it (AnimatedSpriteComponent -> SimpleSpriteComponent) depending on what makes sense to you (the first makes more sense to me, but you could argue either way). However, as stated above, you can again go either way for "knowledge of state". If you have one AnimatedSpriteComponent per state, then it makes sense for the StateComponent to know about each one, then swap them out. If you have one AnimatedSpriteComponent with all possible states (again, the "lookup" idea), then it could be passed in a state from (somewhere), which it would then lookup and find the corresponding animation to play. I think the knowledge flow of state knows about animation but not the other way is "better", although, again, open to discussion.

I like the idea of a generic state component. You could do something like have a list/set of Strings representing each State. This would correspond nicely to the JSON initiative, where each JSON could define arbitrary states ("Puking") that don't have to be ENUM values hardcoded somewhere.