These are features of my game.
For something like League of Legends movement, my assumption would be that TCP would be sufficient since it's not like a first person shooter where exact placement with small fractions of a second timing is important.
I agree with the comment by @Engineer that your packet frequency depends on the game. You have to think a few things over: what important information do players get out of an update? What drawbacks do they have by not getting that in time? For example, for movement they might click on an enemy while the enemy is in a stale location state because they don't see yet that the enemy changed direction, but does that really matter? I don't think so. But what about skill use? If you have it programmed in a way that a server handles skills as they come in, then the clients need to send that packet immediately when the player uses the action, and also players might get angry when they think they should have won a fight but they didn't get the enemy skill use data in time to see it before they pressed their key.
So it would make sense to me that movement and skill use data get sent in different packets at different rates: move data periodically and skill use always immediately.
I disagree in the general case with the other part of the comment by @Engineer about not mixing udp and tcp. That depends mostly on your skill with using them, though the fact you asked this question would cause me to caution you and agree with @Engineer in your specific case. If you're not
