So last week I’ve finished the previous enemy and this week I got to work on the next one. I’m now the dedicated enemy programmer I guess and I like it!
This enemy is different in behaviour than the previous one, where in the last one I used code to move it around. For this one we’re using animations to do the whole movement cycle. This on one hand makes my life easier because I don’t have to bother creating natural looking movement. On the other hand it makes my life harder, if it needs to do a death animation during the regular animation, I need to copy that position and rotation of the root to the new animation.
In the end this was actually quite easy to work with and for this enemy definitely worth it since this type of character was really dependant on a smooth movement with wiggles and what not.
For future reference it got mentioned by one of the designer that I need to look at the specification of the enemy before saying the magic keyword (done), to check if I’m not wasting someone else’s time with my not-quite-done-yet feature.
Normally when I say something is done, the designers come take a look at it to see what maybe needs to change about the spec, not to check if I did everything according to the spec. I jotted down some bullet points for myself after this to improve my planning and workflow for the enemies:
Enemy functionality (what creates an enemy)
- Movement
- Attack
- Death
- Score
- Other collisions (if applicable)
- Animations + Tweaks on implementation
- Particles + tweaks on implementation
- Editor Items (lines,gizmo)
- Resettable (particles, position, rotation, animation)
planning & misc. (What do I need to review)
- Update technical document
- Animation check with animation artist
- Particle check with particle artist
- Check enemy if functions can be moved to EnemyBase class
- Check current implementation with Spec.
- Design review
- Code review on feature finish