I made a cheesy pong game with images that pop up and other distractions. I accessed my images as so:
zappa = new ImageIcon("/images/zappa2.jpg");
(yes, a pony-tailed pic of frank zappa pops up to block part of the screen and then starts moving around as further distraction)
I tried to export as a jar and a runnable jar, but either way, the program worked fine but no pictures showed up in my game.
I read a bunch of stackoverflow forums and found something that semi-worked. I changed the path to:
zappa = new ImageIcon(getClass().getResource("/images/zappa2.jpg"));
When I exported to a jar, the pictures showed in the game! However, whenever I comment out my old path and use the new getResource path, the game becomes very unstable. It only loads a rare number of times out of a set of attempts. In both eclipse and the exported jar, most of the times I try to load the program, I just get an empty frame, and on some occasions, I get game play, but my paddle is unresponsive to the mouse.
I want the stability of my first path, but the pictures exporting correctly of my second path.
Also, what do I want: jar or runnable jar? This is my first GUI program. Previously, I've made text programs, exported to jar, and ran them thru terminal.
Sure Stephan. Thank you for the welcoming as well!
Here is my Draw class which is the main content of the frame. This is probably an excessive amount of code especially since I have a lot of sections commented as I'm using this program as a teaching tool for my AP Computer Science A high school students. I can cut it down or provide any other of my classes if you want. Thank you again for your reply and help!
Afraid I can find a lot to say about code style. Sorry if this sounds like a litany of complaints. I hope you'll make it into a list of improvements to teach your students.
Stick to single type imports throughout, and avoid import on demand. You can then use the simple name Timer.
Consider a different name for this class from Draw. Call classes singular noun phrases. Maybe GamePanel would be a better name.
Consider making the game panel class final, and also not public. You may only need to use it in one situation, in which case you can confuse your students by making it a private nested class.
Declare each variable in its own line.
Use one empty line whennecessary, rather than two.
I am glad you abandoned the idea of having x and y as fields. It is far better to have a Ball and Paddle class, and let those classes remember their locations. That sounds a more object-oriented approach. Maybe you already have those classes but have called them Circle and Rectangle.
Use JOptionPane.YES_OPTION directly throughout. If you take a copy of it, there is a risk of that field being reassigned and the program won't work.
Carefully monitor the number of fields. Once you get beyond five fields, your class will become unwieldy. Consider whether any of those fields can be made into local variables.
Surround binary operators with spaces, one each side.
For reasons explained here, ignore the Java™ Tutorials and use Random#nextInt instead of trying arithmetic with Math#random. I
Methods called from the constructor should always be marked final or private. It is usually not necessary to use both. I think setStartValues() should be private.
Consider changing the name of that method; it doesn't only set the starting values, but seems to be called to reset the program to an initial state. Or have a private reset() method which simply calls setStartValues().
You are overriding paintComponent() and have correctly called super.paintComponent(). Add the @Override annotation to that method. Give it protected access, like its superclass' counterpart, not public. You should never have to call it directly.
Make code explain why the icons change with the score. That is where comments would be really useful.
Consider whether the Zappa and Bacon icons could be implemented by a different object, so as to keep this class from getting too large.
Use separate code for playing the game and for displaying it. Let the display classes display the bat'n'ball (and pigs) full stop. I think you should have a Game class which takes turns, calculates scores, etc.
I am pleased to see action listeners as private inner classes. Do you know about λs yet?
See how much code from the actionPerformed method can be transferred to the Ball object in its move() method. If you pass the width and height of the panel to that method, the move() method can deal with bouncing etc. Otherwise you will have an inordinately long method.
Wow! Thank you for taking so much time picking apart my code. This is my first year teaching and understanding this, so it makes sense that most of my approaches have perverted. I'll be researching most of your list today when I can and I might need clarification on any that I can't understand from web research.
Avoid public fields. You have got score marked public. I hope you meant to have it private, otherwise any other code can alter the score.
Beware of magic numbers. Those are numbers which appear out of thin air without explanation; according to the old Sun Style Guide (§10.3) the only number literals you should use are 0 and ±1, but I think that is a bit extreme.
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop