Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I've been testing with AndEngine for months, but still haven't produced any game prototypes. There are few reasons why I want to switch to libgdx:
- AndEngine is using libgdx's INI wrapper for Box2d, but updates reach Andengine slowly
- I'm primarily targeting Android, but having option for easy porting to other platforms could come handy
- Documentation! AndEngine has absolutely no documentation, except for examples.
- I would like to get as high performance as possible and that seems easier on libgdx.
Few things I am concerned about libgdx is that I will need to write lower level code and that development for full game will take longer? But then again, sometimes I lost few days to understand how some parts of AndEngine work, so is it possible that I'll even write code faster with libgdx since it's fully documented?
What should I be aware about libgdx before switching? What is main difference when coding game and designing code?
You should be aware of the following things:
It is more performant, thats a fact and widely known. Libgdx uses
native code for the more difficult tasks.
Development on it is very fast, I dont get why (some) people say it
takes a lot of lines to do simple tasks, thats simply not true. The
library is very high level with the possibility of programming as
low level as you would need. Especially the ability to test on
desktop immediately, instead of waiting for the app to deploy to an
android device or worse... the emulator. That makes the development
time way faster.
The library gives a lot of freedom, you can make the things as you
want it. For example I made a template that I use for every new
game, that makes things even faster for me.
You dont have to know opengl, androidsdk or lwjgl, actually you just
need to know the abstractions of the library. But you can make
platform specific code if needed. And thats well documented.
complementing P.T. point, libgdx has a wrapper for box2d physics and
bullet (3d) physics which are pretty easy to use (except bullet :S
nah kidding). And I would say, the new 3d api is almost complete,
not much will change for the next stable release, I even read on irc
that it is pretty much done. I use it and can tell you its very easy
to use.
In conclusion, Libgdx is a very fast library to develop on. Its very performant, and complete. Has a good and helping community, plus great documentation. I would recommend you to change :)
Both P.T. and Lestat make very good points in their answers. But for me, I think there is just one thing that you need to know about libgdx, which is simply that libgdx is a toolkit not an engine or framework. This one fact means that you are not locked in to a particular way of doing things. If you want a micro-framework, write one with libgdx. If you want to write "Unity 2D", write it with libgdx. If you want to put everything in one file, throwing object oriented principles to the wind, you can do that with libgdx.
It helps that it is well documented.
It helps that it is fast.
It helps that it has a strong, knowledgeable community.
It helps that the source code is available and is well-written.
It helps that it comes with examples.
It helps that it is a platform abstraction layer so the same code will run on multiple platforms.
It helps that it is actively developed.
But fundamentally it is a toolkit, albeit an excellent one. What you choose to do with that toolkit is up to you.
If you're having problems finishing prototypes, I would concentrate on the usability of your tools (over performance, for example) to produce prototypes. So, the speed of updates to Box2d shouldn't be important (its in a good enough state). The ability to do development on your desktop should be important (build/test time is much quicker) without an Android device in the loop. Documentation and examples should be very important. High performance does not matter on a prototype that is never completed. Worry about that later. (Goal #1 should be completing something.)
Libgdx has a broad set of libraries and wrappers, mostly around graphical APIs (e.g., Scene2d, or SpriteBatch or the TiledMap infrastructure). There is a 3d API, but it is still moving pretty quickly, and not yet a stable place to develop on. I want to say that it doesn't have a lot of "gamey" abstractions (though it does have some), but I really don't have enough experience with other higher-level libraries to compare.
Instead of trading your current tool's short comings and pitfalls for a new tool's shortcomings and pitfalls, you are probably better off sticking with the tool you know.
Related
I am just getting started with coding and app development using LibGDX and i´ve got some general and some more specific questions about it.
Before I start: I know that some of my questions might have already been asked somewhere on the internet but I found it really hard to get a straight answer to them.
So, the most basic question first:
Is it possible to create an average application (like angry birds or doodle jump) in LibGDX in a reasonable amount of time?
Browsing the internet I came across many people stating that engines like Unity are "just so much easier to use" and that you can create a game in a fraction of the time it would take you to code a game in LibGDX.
Is that really the case?
My second question connects to the first:
Is LibGDX really worth the time? Picking up any engine or Framework seems like a lot of work, so I wondered if LibGDX is a growing platform worth learning or just an irrelevant framework of many.
The third question is a bit more specific (and the most important one for me):
How can I make LibGDX game pretty?
I know, that sounds weird at first but looking at hundreds of apps in all kind of appstores I´ve noticed that most unity apps look really neat whereas most apps found in the Badlogic gallery look just awful to be honest.
So I wondered is there a simple way to add animations, particle effects, shadows, etc. to a LibGDX application. If I was coding a 2048 clone (just as an example) how can I make my tiles slide together and blend nicely?
Creating good looking animations is something I struggle with the most...
(If you want you can have a look at what I created)
I would really appreciate any answer to any of my questions!
Thank you for making it through this huge post.
MrMorph
Question 1:
If you're good at LibGDX and know quite a bit about the API, it would be easy to make a game like Angry Birds or Doodle Jump. Unity is easier to use, because GDX doesn't have a GUI editor - meaning you have to position things using coordinates.
Question 2:
I think LibGDX is worth doing. It's free and royalty-free, which is good unlike Unity, and it's on Java so it's relatively fast.
Question 3:
To make particles, there's a 2D and 3D particle editor which you can download of the LibGDX website or run from your IDE if you import the 'tools' module. For animations, you can make sprite-sheet animations easily with the Animation class and you can move things around smoothly (for your 2048 clone) using functions like MathUtils.lerp() to smoothly interpolate a value to another, over time, slowing down as it gets nearer.
A late answer, but hopefully someone will find this useful.
Checkout my answer to a similar question here: What I need to get android game with graphics like this?
I've used both libgdx and Unity and talk about my experience in the answer. At this point I'm in favor for Unity for most small/medium sized games. The editor really does make development much easier (especially for a one-man team). Libgdx + Overlap2D + Ashley (entity component system) is basically a very light-weight version of unity imo. Going the open-source route, you will definitely learn more since you'll be more involved in gluing these tools/concepts together. To answer your individual questions directly:
Question 1:
There are many good games made with libgdx. The reason you see a lot of crappy looking games in Gallery is because the submissions are sorted by time. The gallery does not prioritize good games to be shown first, this was a community decision a while back. Engines like Unity of course show off the best games first. To see some good looking libgdx games, checkout games by Robotality. Also, take a look at the "Showcase" section of libgdx forums; sorting by reply count will show some interesting games made in past few years.
As for the the claims that Unity is easier to use, I agree. I've made the switch myself just because how easy it is to come back to a project after months, and just starting playing around with it. Not as easy when your game is mostly code.
Question 2:
Libgdx is the better way to go if you want to learn. Because it's a framework, you'll be dealing more closely with the components that make up a game engine. You'll be putting your own game engine together with the APIs provided. Unlike Unity, you'll have to choose whether you want to use an Entity Component System like Ashly. You'll decide when physics engines get updated, when you render, how you load and manage assets, etc. Once again, unlike Unity, there is no enforced structure in place.
You'll be spending time reading libgdx's very well written source code as well as the excellent technical github documentation. I'd say the overall effort to make a game is greater when using libgdx, because of the learning. It's great if you have the time, but can be frustrating if you're developing only once in a while as a hobby.
Question 3:
The question is a little unclear. As I've stated above, there are plenty of crappy looking games made with unity, they just don't show them on their gallery/showcase game. Plenty of games with bad art are made with all popular game engines.
Libgdx has the things you want: checkout Interpolation functions for smoothly controlling object movements, particle editor to create & load particles, not sure about shadows (for 3D?).
Hope this will help someone decide what tool to use.
Yes it is very possible to create a simple game in libgdx. I used to use this framework all the time. If you are semi new to it YouTube has some awesome tutorials.
Now I use unity primarily, and here is why:
It is easier from a productivity standpoint yes.
Libgdx can be a lot of work when trying to work with graphics.
Plus it was an easy transition from Java to c#.
And yes in most cases unity can move a bit faster, again from a productivity standpoint, in libgdx there is more of a process to setting up graphics and viewports and etc.
libgdx is 100% worth it. A big part of what libgdx helped me with was grasping how the backed of these applications work. This has helped me a great deal in debugging problems in unity and just advancing my knowledge overall.
If you have good graphics and understanding of the framework then you can make a libgdx game that does look beautiful. The difference is that unity simplifies the process for you. And all the demos you see are from a huge pool of projects. With libgdx being such a good start to game development, there are going to be plenty of projects, with no proof of how much work and or time was put in.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I am a complete beginner in java. Although i have studied a lot of literature on the language (well sort of), this is my first real project.
I was basically planning to make a simple clock widget and later plan to build Gui s. Until now, i had learnt in swing. But then i found on this site that Swing is kinda outdated
( ref : Java GUI frameworks. What to choose? Swing, SWT, AWT, SwingX, JGoodies, JavaFX, Apache Pivot?).
What i needed was some good libraries in java to assist me in this process ( the clock widget and subsequently more complex gui). So i thought of getting libraries from jgoodies, the free ones.
And now i am utterly confused and messed up on what to do and dont understand anything. And of course i dont need books in design patterns etc etc. Just java references and some tutorials on gui using java and jgoodies to get me started. And i cant find them anywhere.
So please point me in right direction.
Reading background (Head First java, java the complete ref and data structures and algo)
(Suggest others if not sufficient)
AWT has effectively been replaced by Swing.
SWT is a different framework, which provides greater native interaction with the OS
JavaFX is the new player on the block, while some consider it a replacement for Swing, it's primary intention was to display Flash or act as an alternative to it.
SwingX and JGoodies are Swing based libraries.
Swing and SWT have begin around for quite some time, some might consider them to be "old", but what it does mean is there is a body of knowledge surrounding the frameworks, as well as a number libraries designed to support and extend them
JavaFX is new player on the market and has yet to build the same knowledge and support base.
If I was you. I would pay attention to Swing (personally) as it is going to provide you with the best ground base of experienced developers and support to help you on your way.
Once you become more comfortable, you could explore SWT, JavaFX and other toolkits and frameworks.
I would start with Creating a GUI with Swing, Performing Custom Painting and 2D Graphics.
My (personally) feeling is to build an understanding of the base library, try and learn it's strengths and weakness. This will help you understand when to use such libraries as SwingX and JGoodies - IMHO
What i needed was some good libraries in java to assist me in this process ( the clock widget and subsequently more complex gui). So i thought of getting libraries from jgoodies, the free ones.
Probably you don't need libraries as much as you think you do. Learn stuff from first principles and you will learn it better.
All the major Java GUI frameworks are quite high level and functional already. When you are first starting out, I think you should skip 3rd party libraries and see how far you get with what is provided in the base JRE and the framework of your choice. There is more than enough to learn with just the basic frameworks, the java language and the JRE. If you try to add in other frameworks too early, you will end up overloaded, confused and less productive. Plus the increased abstraction of the libraries may prevent you from learning some of the important underlying principles well enough.
Once you get a bit more experience in building things, then you will have a much better idea where the gaps in the frameworks are for your application and you can add in 3rd party libraries at that time.
planning to make a simple clock widget
If you get stuck, here is code for a JavaFX clock: How to draw a clock with JavaFX 2? or a similar implementation in Swing.
Note that creating a clock is quite a bit different than creating a traditional form based GUI that makes use of a library of predefined controls - but any of the major Java GUI frameworks can handle both tasks.
Don't make a clock your first GUI programming task, do something easier. Then try to create a clock later.
using swing for precise layout is really a difficult job
There are interactive graphical layout managers for Swing and other frameworks (e.g. the excellent SceneBuilder for JavaFX) which make this easier.
However, when first starting, it's probably worth hand coding stuff rather than letting a tool manage the layout for you (for example when learning JavaFX, stick with just the Java API and don't use FXML until you are completely comfortable with the Java API). You will learn the ins and outs of layout management and other things better that way. Sure you will make some mistakes and there will be a bit of frustration, but things will become clear in time with some persistence. And you may eventually end up deciding that you prefer hand-coding rather than using a graphical tool anyway.
The tricky part is usually creating quality, dynamically resizable GUIs that look good at different resolutions and window sizes - and that is generally tricky for beginners no matter what GUI toolkit is used.
The layout managers in JavaFX are very similar to the basic layout managers in Swing - so layout-wise there is little difference between the two frameworks.
The retained mode Scene Graph in JavaFX may be a bit easier to work with than the direct mode painting of Swing, but I guess that is not quite layout related.
Introspection tools, such as ScenicView for JavaFX, ease debugging layouts at runtime. Think of things like ScenicView as something similar to Firebug for HTML (e.g. your essential layout debugging companion).
And now i am utterly confused and messed up on what to do and dont understand anything.
You understand more than you think you do or you wouldn't have known enough to ask this question.
What you should do (IMO) is just pick a Java GUI framework (any framework - they are all passable), pick a decent starting task (something that seems mind-numbingly simple - even simpler than a clock) and start coding. Make everything task related; very small tasks with clear end-goals. Write a decent amount of code and always go back and revise your code and it's output to try to make it the very best it can be - don't settle for good enough.
Try painting rainbows and happy faces - when you code that up and see it on the screen, you will feel good about yourself :-)
If you need a refresher on the Java language, follow the Oracle Learning the Java Language trail. That trail is the way I learnt Java many years ago. It has been maintained over the years so that it is still a great resource and useful today.
If you choose Swing, follow the starting links from MadProgrammer.
If you choose JavaFX, follow the JavaFX tutorials and the Ensemble sample app but be aware that some of the JavaFX tutorials are targeted to more experienced programmers.
I plan to build a game for mobile. My target platforms are iOS and Android. I hope to be able to carry out testing on windows and/or linux. I'm a bit over my head in this as aside from general game development experience, all the technologies are fairly new to me. I've done a decent amount of research and have concluded that the game should be written in/ported to C++ to ensure that most of my engine can be easily ported to multiple devices.
Another thing I'd prefer is to write the game initially in java and port to C++ since that's where I'm most comfortable and will get it done the fastest.
Now I have the issue of choosing whether to use a game engine such as cocos2d-x, or to write the engine from scratch and use OpenGL ES 2.0 for rendering. Initially I thought it would be better to use cocos2d-x since I don't have a lot of experience with OpenGL. My problem with using cocos2d-x, however, is that since I want to write the game initially in java, that I'm going to have a hard time porting the engine to conform to cocos2d-x (or I'd have to learn all about the cocos2d-x engine to begin with and then write my engine to mimic the cocos2d-x engine.. seems redundant).
Upon further consideration, I thought that writing my own engine using OpenGL would actually be the better option. I'm able to use the PowerVR SDK along with JOGL to emulate a GLES environment. Also it seemed nice since I would be able to allow GL to do most of the work for me in terms of collision detection and transformations. My only issue with this is that since the game is going to have multiplayer support as well, the GL collision detection and such is basically moot since I'm going to have to do collision checking server side anyway to prevent the game from being easily hacked. Of course for the single player game play this method is viable.
Obviously this decision is subjective and depends on my personal preference, though I hope to have given enough background for some more experienced persons to lend their opinions.
That being said, my question is: given these parameters - would it be better for me to use cocos2d-x and suffer the head trauma of building the game from the ground up in C++, or would it be better to write my own engine initially in java and struggle through the OpenGL aspect of it?
Building your own engine from scratch would be too much of a work and would attract lot's of bugs to creep into. The tried and tested engines are better choice in my view. The porting would be far more easier to do, since you would be having a working game.
I am using Marmalade engine currently and I am quite happy with it's performance. It gives you direct access to the OpenGL libraries, although I've never tried it. You should give it a try too, although it's not free, but the 90 days evaluation license is free to check it out.
I've decided to write it from the ground up in c++ using cocos2d-x. It hasn't been as bad as I expected.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Since Java supports OpenGL, what is the best option for developing a game?
Java + OpenGL
C++ + SDL + OpenGL
I always avoided Java (in game development, of course) because of it's speed. But, I discovered that Java supports OpenGL. So, I think speed can't be the problem anymore. What should you choose? Are there remarks?
Java would be a lot easier for me, because of my experiences in Java and the garbage collector.
In my opinion, if you have an idea for a game in your head it doesn't matter what you write it with (at first), C/C++, Java, pen & paper... Pick the language you're more comfortable with, prototype and test your game idea, once you have a rough sketch and know what you need to do, throw the prototype out, design the gameplay & architecture and then start coding the actual thing. Don't optimize until after you've got most or all of the functionality working (in general, there's always minor bugs to hunt) and you actually see where the bottlenecks are.
I've seen it happen over and over again, game programmers are among the worst premature optimizers ever, trying to squeeze out a few cycles from something trivial, while missing the biggest bottlenecks and then optimize some more (in the wrong place). I've also found myself guilty of this many times. I'd say don't pick C++ (or Java for that matter) because of the speed, you can get very good performance out from both, if done "right". If need be, you can always switch to another language, if the language itself is really the bottleneck or really preventing you from doing something. Java isn't automatically slow and C++ isn't automatically fast, you can go (very) wrong with both. I used to root for C and C++ in everything, but after having worked with Java for quite a while, I really don't miss all the hassle that much.
There are lots of (already optimized and fairly easy to use) game engines available for both languages, so there's no need to roll your own... unless you really want to. In my experience, most hobbyist "game programmers" tend to be more interested in the technical side of things than in the actual game (myself included) ;) Once all the technical hurdles are done and you get that nice model/bunch of sprites/particle effects running with some shader-effects, the enthusiasm seems to fade away... But don't let me discourage you, game programming is very fun, even if you never actually finish anything (I wouldn't call any of my own projects finished).
I haven't coded any games for a while, but for C++ 2D SDL is a good candidate, other option could be SFML, or if you want a lower level touch with OpenGL, you could try going with GLFW + SOIL + some audio library. For full-blown 3D, I'd say try either OGRE or Irrlicht + Irrklang (there are probably loads of others too).
In Java, there's at least Slick2D, Golden T Game Engine and for lower level access, LWJGL (although I think you can access LWJGL via Slick2D also). For 3D, someone recommended jMonkeyEngine to me, but I've never tried it.
I would vote for C++ for the simple fact that you have a dependable destructor in your objects. This lets you wrap many of the OpenGL components (buffers, textures, etc.). You can know that when the object is created, the asset is allocated, and when the object is destroyed (or goes out of scope), the asset is cleaned up.
It certainly can be done in Java. Minecraft was made in Java, and it has pulled in over $25 million.
Java has been proven to be just as fast if not faster than C++, though granted, you don't achieve such results without a little parameter tweaking and careful monitoring of the garbage collector. If you want to pursue game design with Java, I'd say that's a good choice to make, provided you study up on how to approach it first.
I'd go with C++, SDL, and OpenGL.. SDL is getting revamped with 1.3 at the moment, and it will be really good. In my opinion you should do it in C++ as you have stated you would feel more comfortable with Java, being comfortable after making a game in C++ would be very beneficial. You would not only make a game, but learn more at the same time.
If you go down the Java route you may need to ship the JVM along with your game. That's not to say don't do it but many people may not have Java installed or not have a recent enough version for the features and performance that you want. I haven't looked into the licensing requirements for shipping the JVM but that's probably something you'll want to investigate before making the decision.
You should also be aware that when highly tuning an app that although the Java API is the same across platforms that there are differences because the implementations of those often use the underlying OS. So I doubt that using Java would reduce the test burden at all for a game.
It really depends on what language your most used to. There's a steeper learning curve with c++ than with java. If you not into none of the languages, and is eager to get some development done I would recommend java.
And a little side note. If you totally new I would also recommend looking at XNA, but it's based on DirectX. And you have to know some C#.
Well I've programmed all my games in SDL and I would definitely recommend using c++. Though you may want to look at SFML!
http://www.sfml-dev.org/
SFML is already integrated with OpenGL, and it's fairly easy to get up and running with game programming.
It really depends on what kind of games you want to build and which programming language your more comfortable with.
If your planning to make big games in the future , C++ is best for overall experience. Most commercial games are written in C/C++. Microsoft also has XNA framework which uses C#
Id still go with the programming language your more convenient with, they are both great
However, if you dont mind learning a bit more then go with C++
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I've been a web programmer for a while and I can also program in Java. I have an idea for a small, multiplayer RPG game that I want to work on. It will be played through a java applet in the user's web browser.
I have written the design document and specifications of the gameplay. What I'd like to know now is how I can develop the game? I've worked only with windows-like business apps in the past, with built-in widgets for textboxes, dropdowns, etc. With game programming it seems that I would have to build my own widget/controls for the UI of the game.
These are the specific questions I have in mind:
1) How to display a 'loading...' message with a progress bar while the game's images, sound, etc are being downloaded. (Using the java applet)
2) How to create the UI of the game with its own menu, controls, etc. Such as by clicking the map icon it would show up a map to them. Clicking the friends icon would let them chat to their friends, etc.
3) And other, general game development issues that i should know about, like whether I should use 2D or 3D graphics, physics in games, etc.
If there's a good recommendation for a book that will help me, do share.
If this is your first game, a multiplayer project might be too ambitious.
Loading screens are not terribly hard - I implement them by counting up how many files I have to 'load' and then advancing the progress bar (and doing a screen refresh) every time another file has been loaded successfully. You can do this with as much granularity as you please - it might complicate your loading code to add the UI component. I wouldn't worry about it for now; maybe just throw up a basic "Loading..." frame and then implement a full progress bar later when the game is more solid. I've also seen some good implementations with multithreading.
The other two will come with experience; I think what you need more of is a general tutorial for game development than the specific answers. You should definitely start smaller. Once you understand the structure and problems of a smaller game, it will be easier to apply those to larger games.
Most reasonable game programming books will go over basic game structure; I like Game Coding Complete but it's quite complicated for a beginner (it covers more complex ways to approach large projects). Game Architecture and Design is similar, but might be better suited to what you're looking for since it also covers some minor project management "best practices."
There's a lot of different ways to do UI, from using the Java primitive UI types (depending on what other libraries you're using) to self-writing your own "HUD" implementation with just what you need.
One thing that is probably worth being familiar with is multi-threading. For example, with the "load screen", you might have one thread displaying the progress bar, while other threads simultaneously load data.
Similarly, much of the interactivity will happen by dispatching multiple threads to do many things at the same time (move different characters on the screen) or to handle interrupts by user input.
I would look at O'Reilly Books
Killer Game Programming in Java
Coding For Fun
The easiest route is to package everything in a Jar file. The default screen does show a progress bar with some small ability to customise. You can write custom code to keep track, manage and download files but I would personally advise against this route. If you search for applet loaders you will find more information.
I'm not 100% sure what you mean, but you can use Swing components in the same way you can use them in applications. Use a JButton with an image is quite trivial, then hook the event code in the actionPerformed method.
The biggest problem you will probably come across is animation and the EDT. I asked about this earlier.
This page has a whole bunch of useful links for game development. Pulp core is an open source framework worth checking out - even if you don't use the framework you can investigate the code.
Whether you should use Java applets or not seems out of scope of this question, but a lot of the above answers give objective (or no reasons at all) about whether to use Java applets. If it's a game for a personal exercise to learn Java then it's a great approach. If you wish to make it public you need to consider whether the current adoption levels are high enough for your needs.
Things have changed in the applet world recently. Since 1.6 update 10 it is much more competitive with Flash - the download size is smaller (at typically under 4Mb), the startup time is reduced and a new scaling look and feel was introduced.
http://nehe.gamedev.net/
Has tons of tutorials from basic to advanced using OpenGL from various languages and systems, from C to C# and Python to Java.
I found this very very useful and is a great resource to bookmark.
It should get you started with the basics of game/3D programming on your platform/language of choice.
good luck!
As others have said a java applet is probably not the medium in which you want to present your game. The second most people see an applet start to load they run in fear.
If you have no game design experience at all, you are setting the bar very high with a multiplayer RPG. You may want to start with a simpler project such as recreating something like tetris, pacman, or even pong so you can get an idea of all that goes into creating a game.
Flash is great if you are set on doing an online game, Java plus the Jogl open-gl wrappers are also a great option.
Personally I would suggest using Microsoft Xna. C# is similar enough to Java that you should be able to pick it up fairly quickly and Xna does a good job of abstracting away some of the lower level details involved in graphics programming. The community is also very active and helpful.
Don't go the java applet route.
If you want to make a quick casual game, make it Flash; else, develop a full-blown java app and run it via java web start.
Try Tower to see how far you can go using java as a platform, and also how Java Web Start works.
As for progress-bar thing, I recommend you to implement those files' loading and actually use them before you go for progress-bar eye-candy :)
Responding to question 3. If you are really keen to start developing games, I recommend you read this short article by Jeff Howland.
Q1 = 1% of your time.
Q2 = 40% of your time.
Q3 = 59% of your time.
You might as well be asking how could I write Halo3 for a web browser.
Aim a little lower to start with....
opencourseware class on game theory and design. It also comes with a reading list.
Since I can't add a comment, I'll add an answer. I'd recommend NOT using threads for moving characters, etc. For file loading, playing sounds, and even server side networking it works well but any sort of AI/Graphics, it tends to cause endless headaches.
Also, as other people have mentioned, Java may not be the best choice. The simple reason that people say this is that it's difficult. The amount of support/tutorials for Java game development is rather lacking when compared to C++ (GameDev.net is great resource, but it's moved its focus more towards professional development over time), Flash (decent tutorial on Kongregate as well as being a spot that could host the game for you), or even C# (using XNA). Java game development has improved over the years and you can do some amazing things with it, but it may end up being more difficult going that route. No matter which language you choose, definitely look into using a graphics/game engine as it will cut down on the amount of work on your end and allow you to hopefully create a better game.
If you're looking for a gentle entry path to game development and don't mind learning C#, XNA has an entire community built around learning how to write games. It has samples of all sorts of things -- the Game State Management sample shows a good way to implement screen transitions and loading, and there's a similar Network Game State Management sample for networking stuff. They also have entire games available as source code to download.
Whether or not your long-term goals are to make a Java applet, Flash game, or you want to work in C/C++ with OpenGL, XNA is a great way to ignore all the hairy implementation details of rendering/sound/etc. That's very very helpful when you're just trying to make your first game, believe me.
Don't go with the java applet approach; applets are generally annoying, and slow.
If you really want it to be playable from the browser, consider Flash (actionscript), or maybe silverlight (I don't know much about games in silverlight).
Gamedev is a great resource for general game programming stuff
And ...
I'll shamelessly steal the link from yx's answer:
MIT Open Course Ware: Game Theory and Mechanism Design