Hi!
I only have a Sempron 2600+, it is a very little bit slow but quite playable. Is there any sound? I don’t hear anything. The aiming with the mouse is not accurate enough, I have to beside the ships to shot them successfully. Good work, keep it up.
Runs a bit too slowly to be playable (Ubuntu Linux, Java 1.6.0_10, old Athlon XP 2600+). I’m not a big fan of the controls, they feel awkward somehow, but perhaps it just needs some time to sink in… 
As for the graphics, nothing wrong with using vector/line graphics, but I think you should pay some attention to the choice of colors. A more consistent color scheme would make the game look nicer. Currently some of the color choices contradict each other and it looks more amateurish than it actually is… But if the graphics are just place holders – ignore everything I just said. 
I like the gameplay for such game (but I dont like such game : shoot them up), anyway it look good except that it run a little to slowly here (also I would have prefer an Applet one):
Whaaaa?
This should not require 3 Ghz, there is something wrong.
yeah, that is one reason why he wanted to switch to opengl.
I finnaly decided to play your game.
WOW, taht was fun! I didnt run slow at all!
I like the bad physics. it makes it more fun. more controlable.
… You need to fix the mouse aiming. Should be your priority.
Otherwise the game idea is good, but still need some tweaking on the gameplay. While the blur might be a cool visual effect it doesn’t help the gameplay, much rather the opposite.
So overall I would say this has a good potential. Good luck.
Hm, it actually seems worse than the last time I played it. Now I couldn’t tell what was going on because there was too much on the screen plus the game was lagging.
Nice start! I died fairly quickly, but it ran okay on my computer, at least until things got crowded. The blur is probably causing some of the slowdown, but I suspect some other graphics slowdowns lurking somewhere. In any case, I think it’s worth seeing how it runs/plays without the blur, I agree it gets a bit distracting, and not in a more typical Robotron-clone manner.
One suggestion: try playing with the color scheme a bit. Yellow/red is a tricky combo to make work, I don’t think it’s probably the best choice for a retro shooter, especially when you’ve got blues as well. You might also want to rethink the stroked polygons - single pixel non-AA strokes tend to look pretty bad, see if you can figure out how to get them anti-aliased (depends how you’re drawing), and it will be an improvement. If that’s not feasible, you might consider leaving them out or doing something else to add graphical interest to the ships
…then again, I’m saying this after spending too many hours fighting with my iPhone to hack anti-aliased fat lines by texture mapping (no AA line support on the chip, alas), so maybe I’m a bit too focused on smooth lines at the moment to be taken seriously…
Your source code is there:
http://prime.turquoisegrotto.com/java/bluefiend.java
Isn’t it?
I’m watching it now. I would like to discover why it requires 3 Ghz. Please split your source code into several classes/files, 1719 lines in a single file are a bit too much. Put the classes bullet, ship, enemy, boss… into separate files. It would be better if you added more comments too. Thank you very much for open sourcing it.
The bottleneck seems to be there:
buff = new BufferedImage(size.width,size.height, BufferedImage.TYPE_INT_ARGB);
g2i = buff.createGraphics();
g2i.setComposite(ac);
You create a new BufferedImage in the paint method that is called often of course. The use of alpha composite is costly too. I’m trying to understand how to work around this. Avoid recreating fonts and colors in the paint method too even though the impact on the frame rate is tiny.
Are you sure you need the line below in the main loop?
Thread.sleep(10);
It would be required in C++ but not in Java as the JVM is able to do what is necessary to drive this useless.
In the class bullet, lots of “new” calls could be avoided as the array called “bounds” contains 4 points. You should rather call “new” once for the array, once for each point inside the array and after that, modify the coordinates of the points in your methods update and update2. I do the same remark for the classes called “enemy”, “boss” and “ship”.
public class bluefiend extends JFrame implements KeyListener, MouseListener, MouseMotionListener
Maybe separate the JFrame, the KeyListener, the MouseListener and the MouseMotionListener (principle of “separation of concerns”).
Hi,
I concur with gouessej, a lot of things that are static and wont be needed to created dynamically while drawing shouldn’t be called in the draw method. It would also be nice to structure the code somewhat.
// Json
ok good, so I am not the only one who looked at the source and went “waa”
like goussej said, seperate all of the classes, it also makes developing easier, casue you can have more than one class open at a time
[quote]Recommended: 3ghz processor.
[/quote]
Get outta here. =D
I dont have access to such a machine. And I couldn’t convince my Xbox360 to run a 2d Java game. =P
ever tried putting a XBOX 360 game in a ps3?
“hey if you wanna play XBOX GET ONE!” lol
Watching the sourcecode is indeed a bit ‘worrying’ - which is not meant as an insult BTW.
There is no structure. This is very much like procedural programming. In Object Oriented Programming (OOP) one of the goals is to spl;it your code into parts that make out the ‘things’ in your game. If you have an enemy, you need an Enemy class, same for Bullet, Laser, Wall, Player, etc etc. Suddenly your code becomes much more structured, and coding becomes easier. All functionality of a ‘thing’ much be coded in the class of that thing. For example: your particle engine should have a lot of private methods to handle all the dirty stuff, and public methods called tick() and render(g).
Now your Game class only has to call particleEngine.tick() at a fixed interval, and particleEngine.render(g) whenever you’re drawing stuff to the screen.
Same goes for Bullet and Enemy. All code that is responsible for them, should be in those classes. Only very abstract (highlevel) functionality should be available to other classes through public methods.
You might want to read some tutorials (like those of Keven Glass) that clearly guide you through the process of building a nice asteroids game.
Overall I can recommend “Programming Methodology” which is a course at stanford “CS106A”
was posted on youtube by stanford
Okay I find this has become really stupid. Saying I don’t know proper programming methodology just because I prefer my classes be in the same .java file is insane. It would take less than 5 minuets to add public before each of those classes, and put them in a java file with their class name. I prefer it how it is. Not only that, but there is actually structure if you look. It’s something like ship -> player
ship -> enemy
Both the play and enemy are ships, so it makes since that they should extend ship. bullets aren’t so they don’t. Don’t say I have no structure just because I use a different structure than you.
Hi!
It isn’t the only thing that we criticized. I’m a bit disappointed by your behavior. I thought you would be happy to see that some people have watched your source code carefully. Some of us quoted some good practices and principles (“separation of concerns”) that are known to improve the quality of the code, we don’t criticize your source code only because you program differently, you’re wrong.
[quote]The term separation of concerns was probably coined by Edsger W. Dijkstra in his 1974 paper “On the role of scientific thought”
[/quote]
[quote]In computer science, separation of concerns (SoC) is the process of breaking a computer program into distinct features that overlap in functionality as little as possible.
[/quote]
What about my suggestion that could improve the performances, especially the frame rate and the memory use? Do you find them useless too?
I only wanted to give you some help. Is it stupid? ???
No, I liked that. I wasn’t talking about your post at all actually. your post was very helpful, thank you.
Edit: Okay, so it was you that talked about spiting up my code, but that wasn’t what bugged me. I thought I remembered someone saying something like “You’re code isn’t even split up, and there’s no structure!” I was wrong.