What Annon meant was that a "player" is not a "frame". Usually you make a new class for in game objects that hold data like velocity. What you've done here is bundle two things into one class. This isnt a big deal if you are just hacking around.

Also you need to add the listener to the Game Frame. In your Game Frame you have some instaces of your game objects (like Human Player), so when the event is received, you update your Human Player accordingly.

AAAAAAARrrrrrggghhhhhhhh!!!!! This has to be one of the most simple things, but i can't get it right!! I feel that i've tried everything!!

I think the problem is in the KeyListener or in the addKeyListener, but i'm not sure what!!

I've included all my source code in this post, just in one txt file, so u'll have to break it up (Sorry i wasn't sure whatthe convention was). But if you have a spare 5 mins or so, could you have a peek.

You've got a lot of issues. Mostly caused by bad style I suppose. E.g. requestFocus() and setVisible() are things that you generally don't call in a constructor. You should probably stick to the Java coding convention of starting identifier names with a lowercase letter and class names with an uppercase letter.

You've construction code scattered all over your source files, much of it outside of constructors.

You have physics/player state updates inside paintComponent, instead of in your main game loop.

You have methods named "pressedKey" and "releasedKey" in your player class, which is really a UI thing. You really want methods to set the player's direction of acceleration - call those methods from your KeyListener if you like.

The solution to your main problem though is that an empty panel is by default not focusable.

I was just reading through and was amazed nobody had said that yet. Yes, you can either setFocusable to true in the constructor, or

1 2 3 4

publicbooleanisFocusable() {returntrue; }

You can override the isFocusable method like the above. Generally, you should go with simply calling setFocusable, but sometimes when making games you don't want the main window to ever lose focus, or you want two panels to have focus. Say, for example, you have the game window on the left and scoreboard/interface on the right. Rather than have the game panel pass its key commands to the scoreboard (or a master model) or vise versa, you can trick Java into giving them both focus all the time. Or if you have Swing elements like buttons which will steal focus upon pressing this can be useful as well.

I usually use setFocusable(true) and then every time step say requestFocus() (this gives the focus to the component requesting it) so that I am not potentially messing anything up, but I have found myself twice doing the above method for whatever advantage.

Thankyou, thankyou!! I was seriously going mental over that!!! <-- i thought it would be simple

Quote

requestFocus() and setVisible() are things that you generally don't call in a constructor

Would you believe that DrawingFrame actually came from my computer science lecturer, and has been in the course notes for prob 5 years!! So if i've learnt bad programming blame those guys!

Quote

You should probably stick to the Java coding convention of starting identifier names with a lowercase letter and class names with an uppercase letter.

I thought i was pretty good with this, the only time i didn't do it was with the instance of HumanPlayer (i named it Player).

Quote

You've construction code scattered all over your source files, much of it outside of constructors.

I'm not sure what you mean by this? I can't see what i'm doing wrong, but then i was taught to do it like this, so please tell me.

Quote

You have physics/player state updates inside paintComponent, instead of in your main game loop.

I know this is wrong, but i was just doing sort of a hack-and-slash to try and get the thing to actually move. Won't happen again

Quote

You have methods named "pressedKey" and "releasedKey" in your player class, which is really a UI thing. You really want methods to set the player's direction of acceleration - call those methods from your KeyListener if you like.

Makes sense, I'll try to call it something different next time. The only thing was i wanted to process the KeyEvents inside the HumanPlayer class, but probably is better to do it in the game class.

@demonpants: Thanks for the info, but i'm not totally up with the focus yet, so i think i'll have to keep reading you're post to make sense of it!

Thanks every1 you've been tons of help, i'm sure i'll more problems in a day or two! Should i make a new thread if i do or not?

In GameFrame you have initialization of x & y, then a constructor, then initialization of the key listener. The member variables are usually kept together, but I sometimes also make a distiction with inner classes done this way.

Put any new issues, unrelated to KeyListener, in a new thread with an appropriate subject.

requestFocus() and setVisible() are things that you generally don't call in a constructor

Would you believe that DrawingFrame actually came from my computer science lecturer, and has been in the course notes for prob 5 years!! So if i've learnt bad programming blame those guys!

@demonpants: Thanks for the info, but i'm not totally up with the focus yet, so i think i'll have to keep reading you're post to make sense of it!

Thanks every1 you've been tons of help, i'm sure i'll more problems in a day or two! Should i make a new thread if i do or not?

I actually called setVisible(true) in most contructors for JFrames, personally. Basically I initialize everything, set the size of the window, and then make it visible. It's always worked fine for me. I don't see why you wouldn't call getFocus() in the constructor also, as long as it is after the setVisible() call. So your teacher is not necessarily teaching you bad practices, it's just another way of doing things. swpalmer probably keeps variable initialization in the constructor and window intialization elsewhere because it reduces coupling in your code. Sure, good practice, but not necessary.

Also, if you need help understanding anything I said I'll certainly explain it. And don't bother making a new post - I always check my "show new replies to your posts" link when I log in, so I'll see it.

I actually called setVisible(true) in most contructors for JFrames, personally. Basically I initialize everything, set the size of the window, and then make it visible. It's always worked fine for me. I don't see why you wouldn't call getFocus() in the constructor also, as long as it is after the setVisible() call. So your teacher is not necessarily teaching you bad practices, it's just another way of doing things. swpalmer probably keeps variable initialization in the constructor and window intialization elsewhere because it reduces coupling in your code. Sure, good practice, but not necessary.

Also, if you need help understanding anything I said I'll certainly explain it. And don't bother making a new post - I always check my "show new replies to your posts" link when I log in, so I'll see it.

I know that calling those methods in a constructor can work. But things like requestFocus() in particular are rather indirect for a constructor. As you said, I like to construct the objects in the constructor - but not the entire UI.. i.e. make the object, but don't make it visible. That way I can construct objects and save them to be made visible later, the code is more generic/reusable. I would definately say that the profs code was using poor style.

The new posts would be for the benfit of keeping the boards organised. Sure threads drift off-topic all the time, but there is no sense forcing threads off topic on-purpose. Many people skip posts based on the subject.

Hmm, that's a good point. Kepping things robust is very important. I think the only times I ever really use setVisible are in the actual main class, so it's not like it can contain a bunch of itself. But if you were dealing with multiple windows or eveer wanted more robust visibility, that's a very good point.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org