It's just a matter of understanding the game, and then using what the API exposes to accomplish what you want.
Generic routines are tricky because of how complex this game is.We're planning a new routine implementation for 3.3, so as we get closer to that, I'll post some more reference materials on routines as what the issues are with developing them.
You can use OldRoutine as an example, but the mistake people make is trying to copy OldRoutine's logic as-is rather than understanding what the logic it uses is attempting to do. If you start simple, and look at making a minimal routine that only cast one spell, then look at how your logic works for a different spell of a different cast type, you should start to see the design issues you have to take into consideration.
For example, if you're only using Firestorm, you can almost cast anywhere and you'll hit the target, as long as it's not through a wall. If you then were to use Fireball instead, you'll see how you have to care about the path of the projectile, as you can not hit your intended target if there's something blocking it in front. This seems like a minor thing but makes a huge difference in the logic you have to write to handle skills properly. Then consider a skill like Freeizing pulse, which has similar mechanics to Fireball, but it can pierce, but it also loses a lot of damage the further away it's used. Do you want to move closer to a mob to cast it and increase the danger you're in, or stay further away and cast another skill that might be able to hit the target? You can't do both at once though, hence the problems with the routines we provide and how they can't cater to all logic at once, because you need a design that can support doing mutually exclusive things.
