Java Applet - Counter Strike game

[Myopical]

Well I've been working on my new project for my class, an applet of a counter strike game !
It could be just a mini shooting game using the MouseListener and MouseMotionListener.
I actually did not really start on the actual game yet.
What I'm doing is the opening small animations and the front page right now
My question is, I've imported 4 pictures for the animation, I added them with the MediaTracker one by one, set with a delay,
but when I drag or move the output window of the applet, the animation rewinds again.

Also are there any more new knowledges that I should be looking for when doing this type of shooting game?
This applet will be graphical intensive be as our teacher expects us to put a lot of graphics into it. (Such as gifs for the guns firing, enemies dying, imported pictures)
I've only touched onto the basics of applet, any suggestion and replies will be awesome.
Thank you all~~~

[Ultrahex]

I would recommend not building an applet and instead building a full fledge window managed using open source 3D rendering library so a lot of the grunt work is not there (unless I have mistaken your intentions on what you plan to build).

If anyone knows openGL I wouIld probably suggest JOGL however it may overcomplicate things depending on your time and commitment to the project.

An 3D shooter is a lot of work (i mean about 6 months to get a prototype normally), so you may also want to try an existing 3D engine to get you started if that is allowed.

[Myopical]

The project itself must be done in Java applet, and it doesn't have to be a 3D movable game.
The teacher only requires a small game that is 2D, including some monsters/enemies popping up in the background and shoot them.
I've been searching around for graphics in applet, and i came up with the contents of the double buffer.
Can anyone explain to me how double buffer works in order to provide a more smooth graphics?

[DemonWasp]

The problem with the default, unbuffered graphics is the following: updates from (memory representation of screen) to (image displayed on your monitor) happen whenever they want to, generally a solid 60 times a second (60Hz). Because of that, a system that draws directly to the (memory representation of screen), or "screen buffer", is going to end up having the middle of its drawing process exposed to the end user every so often. Sometimes the drawing will be done, other times the drawing will have just started (black screen?), other times it'll be partway through (showing you, but not your enemies...).

Double buffering eliminates the problem because the buffer that the screen reads from (screen buffer) and the one that you write to (draw buffer) are never the same. You draw to A, screen reads from B. Then, when you're done drawing, you explicitly "flip" the buffers, telling the screen to read from A, while you draw to B. This happens more or less instantaneously and can't really be interrupted by the "draw screen buffer to actual screen" operation. This means that the user sees a series of finished frames, rather than unfinished half-drawings.

[Myopical]

Also one more question, a very simple one to answer really.... (Accidentally turned this thread into answered, but I'll still post my future questions/concerns here).

For example, If I want to make a box to move from the applet window from left to right, I would need a loop and draw the box from left to right and repaint()
In order to cover up the image as it goes.
I'm also using the mousePressed method from the MouseListener to hit the box.
My question is, for such simple shooting game really, just shooting a box, how am I going to create the delay for the box to go from left to right,
because using Thread.sleep() will stop all actions in applet and I can't shoot or anything.

[copthesaint]

nanoTime() *Returns long*
Returns the current value of the most precise available system timer, in nanoseconds.
? I dont know how well this works... but for what you are doing a timer should work fine.

[2goto1]

Myopical @ Sat Dec 25, 2010 11:08 pm wrote:

Also one more question, a very simple one to answer really.... (Accidentally turned this thread into answered, but I'll still post my future questions/concerns here).

For example, If I want to make a box to move from the applet window from left to right, I would need a loop and draw the box from left to right and repaint()
In order to cover up the image as it goes.
I'm also using the mousePressed method from the MouseListener to hit the box.
My question is, for such simple shooting game really, just shooting a box, how am I going to create the delay for the box to go from left to right,
because using Thread.sleep() will stop all actions in applet and I can't shoot or anything.

I wonder if putting your box into its own thread will do the trick. I'm thinking that your main applet thread won't have to sleep if you do that, only your box thread will have to sleep / delay as long as you need it to. Java applets support multiple threads I think, http://www.webpelican.com/internet-programming-1/java-applets-threads/.

[DemonWasp]

Multithreaded rendering is a difficult problem that requires a careful, methodical approach, else it will end in disaster. If you're having a hard time moving single objects, you are not ready to handle a multithreaded execution environment.

[2goto1]

DemonWasp @ Thu Jan 06, 2011 9:59 am wrote:

Multithreaded rendering is a difficult problem that requires a careful, methodical approach, else it will end in disaster. If you're having a hard time moving single objects, you are not ready to handle a multithreaded execution environment.

Good point, the development difficulty will increase a lot if using a multi-threaded approach. It's easy to understand multi-threading but challenging to implement it well. I wouldn't recommend it for newbies