The tool Khatharr points too provides better leak diagnosis than the built-in solution. So definitely also worth checking out.
Honestly, if you just learn to use RAII then you don't have to mess with it much anymore.
Good advice, but I've certainly managed to leak memory even when using RAII (incorrectly, obviously). Sad to say, you should learn how to track down memory leaks if you want to be a well-versed C++ developer.
Plenty of good advice in this thread about how to get started on game programming.
However, I didn't see mentioned. If you are serious about being a game programmer as anything more than a hobbyist, you should strongly consider a Computer Science degree from the best 4 year college you can get into.
1) You'll learn a lot of stuff about how computers work, theoretical and practical, that you probably don't even realize you don't know. You can learn this stuff elsewhere, of course, but...
2) Most game programming jobs list a BS in Computer Science as a requirement, or at least a strong recommendation. Years of experience or good contacts can get you around this requirement, but do you want to count on that?
3) Game programming has a lot more in common with programming (any kind), than with playing games. So, you should be training yourself to be a programmer, more than a games expert.
4) That Computer Science degree will also come in handy if, at some point in the far future, the negatives of game programming outweigh the positives for you. Stability, higher pay, and shorter hours probably don't seem that important to you right now, but someday they might.
So, in 10th grade, you should be devoting your school time energy to math, science (especially Physics), and computer programming as much as you can. As a bonus, that stuff will be directly applicable to your game programming right now.
Are you familiar with using a debugger? If you set a breakpoint in eneMove_Tick and step through (looking at variable values as you go), it should rapidly become clear what is going wrong. If you are good with a debugger, this should be a lot easier than trying to figure out what is going wrong by inspection. If you are not familiar with a debugger, this is a perfect time to start! This is a skill that you will need and use often.
I'm not great at understanding code through inspection. If I was to try to understand your code better, I would probably walk through it in a debugger myself.
I'm the author of a real-time pausable RPG. To answer your basic question, "Do I have to do all that stuff?" Yes, you do. In fact, I think you simplified; for an attack, my code runs three timers. One for a character preparing to attack, but not yet attacking, who should display a fighting animation. Second, when the character actually is attacking, to display the attacking animation. And third, when the character is recovering from his attack, displaying a recover animation (i.e. moving his sword back from the extended position to the ready position). Real-time is complicated!
Now, how to handle it in code? For your action class, I have a similar set of classes. However, I subclass depending on the particular action. So "attack with a weapon" in one subclass, "cast a spell" is another, etc. Is something like that possible in your architecture? If so, you should be able to avoid having one mega-action class. I actually have one giant class that handles running all the actions through a switch statement. I'm not proud of this architecture, but there are not that many types of actions, so I live with it, and it works fine. You can probably do better than that, though, if you are writing code from scratch, by moving some or all of the action-running code into the sub-classes.