Writing games with graphics

Sup /prog/
I've been working on and off on a simple RPG game in Java (as that was the language I was learning at school when I started). By simple, I mean that so far it lacks any sort of "cut scene" support. There are quests (but no pretty way of introducing them), map switches, levelling up, character classes, but no cut scenes (and of course no physics simulation since it's just a little RPG game). Anyway.

The non-graphical stuff was fun and easy, as was making the actual graphics, but integrating the images into the game has proved a pain in the ass. I pulled it off, but this required making the game an applet and redrawing that applet either at timed intervals or when an action was performed, depending on what was going on (intervals when walking on the overworld map, on action when in battle). Animations are also a major pain. ideally I would simply load the various frames of every animation into arrays and loop through them when I need to, but this would require timed refreshing which hasn't been working for me (honestly I don't even know why, it seems to be random, as if JRE just has bad days sometimes).
So basically, what do I do, /prog/, what do I do? How do I make the damn thing refresh every 10ms or so regardless of what's going on (the navigation and battling are done by different classes with very different thread managing, but I want them to have identical functions for that, or better yet, a timer that refreshes the applet independently of the current JFrame that is active)?

Heck, even better, I'd rather write this without the use of applets. I don't care if it means rewriting everything graphics-related. Making it without applets was my original intent, but I simply had no idea where to start. I still don't. Any tips? I tried googling for ways to deal with graphics without the use of applets, but failed. I'd prefer to do this in Java or C, though the former is more familiar to me (I do intend to learn C properly, just not this year, thanks to college).

Sorry for the length.

OP here. This game is a programming exercise for me rather than "trying to make my shitty design a reality." If I just wanted to get this thing done without caring how, I'd just make it in flash or some pre-made thing... or I'd leave it the way it is (except add cutscenes), since it looks cute and it actually fun to play. I would however, like to make it better, because I think it would help me in the future to know this stuff.

>>6
Thanks for the tip for not handling the actions in the listener. I'll try it this evening when I get home.

>>12
>>13
I realized that doing this was scratch (aside from standard Java libraries, of course) was a bad idea a few hours into starting the coding, and this was a year and a half ago (a very on-and-off project, it started as my final for 11th grade programming, a better version served as my final for 12th grade programming, and now I'm trying to get back to working on it for fun in my spare time). Since I'm not going for a commercial, polished game here, I don't mind spending the extra time doing it from scratch.



I'll probably keep it as an applet to keep it simple, at least until the game is finished (and then I can think about ports, even though it's more work in the end), and so far the actual input handling hasn't been a problem at all, and really all of my current problems stem from two things. The drawing of images (which I think I can fix, it was bad writing on my part), and a few minor errors in processing the user's in-game actions (like whether they are done targetting a monster or not, I need to go through the code, comment the hell out of it, and find where the little mistakes are, debugging this has been a pain since I have a very hard time replicating the errors).

Thanks for your help guys. Honestly, this was much more than I expected from /prog/ because it's been... shitty lately (I don't normally post, but I do lurk occasionally).  Actual good tips from /prog/? Whoa.