Thread: 2D Java Applet Games

It is harder to use Java for games, but in my opinion using Java can provide much better games vs. flash. What language you use though doesn't matter as long as you design/implement your game well.

There are a lot more games written in flash (because it's so easy to get started), but the vast majority of these games are quite poor. I've seen fewer Java based games, but the ones I have tried tended to be of a higher quality (obviously due to more work put into the game design/implementation rather then just the base language being used).

Here's the way I see game design ideology between these two platforms (note that this doesn't hold for every project, there are many notable examples where the opposite is true):

1. Flash tends to focus on a more "artistic" based game design where-as Java focuses more on the programmer/technical based game design.
2. Flash games tend to focus on "smaller" games where-as on some larger web-based games Java is used (for example MMO's)
3. Flash games tend to focus on 2-D game development, where-as Java games tend to delve into the 3-D realm

I don't know of any books writen specifically about Java gaming, but you can try looking over suggestions at JavaGaming.org, or for a more generalized perspective look at GameDev.net (note that while most of the people at gamedev use C/C++ and they tend to focus on higher-end game design, the basic theory should remain the same in game development).

sidenote:

I'm making a tetris game, too I would recommend starting with this game because it has all the basic game design elements without being too complicated, where-as Space Invaders is a more complicated game to design/implement (need levels, different enemies, enemy AI, etc.).

I think Java kind of fits in the middle: it's just difficult enough that most casual game makers avoid it and use flash instead, but not powerful enough for serious game development like C/C++. However, if you give the time and effort, you can make some pretty cool browser or stand-alone games in Java.

Pick something you're comfortable with and run with it. If it doesn't have what you want, switch.

I avoid flash, too (can't quite quantify the price tag for getting flash devel tools when there are so many other free and/or better tools).

Originally Posted by helloworld922

I think Java kind of fits in the middle: it's just difficult enough that most casual game makers avoid it and use flash instead, but not powerful enough for serious game development like C/C++. However, if you give the time and effort, you can make some pretty cool browser or stand-alone games in Java.

Pick something you're comfortable with and run with it. If it doesn't have what you want, switch.

I avoid flash, too (can't quite quantify the price tag for getting flash devel tools when there are so many other free and/or better tools).

I don't agree with that statement. I am lazy to write a long story right now, so I'll just copy one guy post to ground my arguments.

The reason Java (and C#/.NET) is not a viable option for AAA titles at this point is the established game engines and their toolchains are written in C++. Game development is all about getting a title on the market in the shortest amount of time, and budgets don't allow for piddling in things like a new language/engine when several are already available, work well, and have an extensive set of editors and tools backing them.

Moving to Java (or C#) would also require a new performance-driven JVM (or CLI) across the big-3 (PC, X360, PS3) or big-5 (add Wii, iPhone). It's technically doable, but not financially viable.

Anyone with low-level knowledge of both virtual machines and the current state of game engines can tell you that a JVM or CLI could unquestionably be implemented with a new game engine to beat the performance of current C++ engines. The preventing factor is time and money, nothing more and nothing less.

I'm considering the "out-of-the box" JVM with any additional add-ons like LWJGL or JOAL, not a custom JVM build.

See OpenCL CPU benchmark: OpenCL vs. native vs. C# vs. java for someone's bench tests of computation times.

edit:

I didn't say Java was un-viable for game development (I actually enjoy making games in Java), I said that for games centered around performance most people choose C/C++ because they can get this speed bonus fairly easily (of course, the language doesn't dictate the quality of the finish product so it's unfair to compare a bad C/C++ program to a good Java program, but when it comes to the upper limits C/C++ is simply faster/uses less memory).

Ok, will do

Heres a bad review:
The author states: "In this book, I show you how to develop and program 3D games in Java technology on a PC, with emphasis on the construction of 3D landscapes. I assume you have a reasonable knowledge of Java, the sort of things picked up in a first Java course at school." The publisher prints "The Apress Java Roadmap" consistent with this.

The book, however, is quite different from what is stated, and it is difficult to see how the book would be useful.

The book claims to describe Java 3D, but is in fact little more than miscellaneous source code fragments of much larger programs, surrounded by text annotations. Annotated programs have been published before, notably by Donald Knuth, but this book fails to make the technique work on many levels.

Do not expect the book to provide an overview of Java 3D. The book describes where to download Java 3D from the Sun Microsystems Java Web site. That is all - there is no 'Hello World' program, and no introduction to the Java 3D classes and their organization. The 'overview' is approximately 2 pages of text without a single line of code, only the Web location of the Sun Java 3D 'HelloUniverse' program. If you use this book, you will be learning Java 3D from another source.

The book is structured as a sequence of chapters about specific topics, for example, Chapter 6 is 'A Multitextured Landscape'. Each topic is illustrated by a program, the chapter itself lists the source code of some methods from some classes in the program, with text descriptions.

Do not expect to be able to use the source code fragments as examples for Java 3D programming. The fragments rely heavily on other parts of the program, and the Java 3D calls (if any occur in a given fragment) are not obvious. The author apparently uses the Java 'import' directive to reference Java 3D classes, but does not list these imports in the source code fragments. Therefore, unless the reader already knows the Java 3D API, it is not possible to determine which methods and data types are part of Java 3D, and which ones are part of the larger program. In order to even find the Java 3D calls in a source code fragment, you must already know Java 3D.

Do not expect to learn what capabilities are included in Java 3D, and how to use them. The text description associated with the source code fragments tends to describe only the specific fragment implementation, and mixes descriptions of the fragment as a component of the program with a few mentions of Java 3D features being used. Even for the few mentions of Java 3D in the descriptions, there is no overall discussion of the Java 3D features, or why the particular implementation was chosen.

If you want to learn Java 3D and game programming, you will be better off without this book than with it. The book lists two technical reviewers, I do not understand what they reviewed or why. The publisher, Apress, produces some useful technical books. This is not one of them.

Good review:
There is some overlap between this book and the author's other book on Java game programming, "Killer Game Programming in Java", but overall there is enough new material to make it a worthwhile purchase. The author starts out trying to explain Java3D. His explanations are OK, but the best explanation I have ever found as an overview of the API is "Java 3D API Tutorial" on the Sun Microsystems website. It's old, but the basics haven't changed. For the specifics of working with Java 3D in the modern era, come back to this book. The author has done a good job of putting together some programming examples that show how to program in current versions of Java 3D including a 3D version of Conway's game of life. He then modifies the program to show off some of the features of Java 6 such as its ability to communicate with scripting languages. Further chapters show how to build creatures with operational limbs that demonstrate Java 3D's TransformGroups, how to handle physics and Java3D using a specific physics API, multitexturing for more natural looking outdoor scenes, and finally how to deal with level of detail problems using mixed mode rendering. In each case, the author just doesn't talk about how to do something, he produces working code that gets the job done and provides a blueprint for the reader to go further.

The section on non-standard input devices deals with interfacing devices such as webcams, game controllers, game pads, and the P5 Virtual Reality Glove to your 3D worlds and games. He mentions parts of Java that are seldom well-explained such as JInput to describe how to control these devices. In the section on webcams, the author talks about JMF and an alternative method of interfacing to cameras. This is good, since for all intents and purposes JMF is really a dead API with very little useful capability. One of the more interesting chapters in this section really has nothing to do with input devices, that being the chapter on JOAL, which is a wrapper around OpenAL, the OpenAudio Library. This is very practical since there are bugs in Java 3D's sound interface that have been there from the beginning and show no sign of being resolved. This chapter provides a practical way for Java programmers to get actual reliable 3D sound into their games and applications.

The final section of the book is on JOGL, which is a Java wrapper for the OpenGL graphics library. The author explains and illustrates the use of JOGL by first implementing a very simple application to clearly illustrate all of the steps needed. Next, a 3D world is written using JOGL that includes a floor with a checkerboard pattern, an orbiting earth, a skybox of stars, a billboard that shows a tree, overlays, and keyboard navigation.

This book, along with the Sun tutorial, is a good education in how to use the Java 3D API in general, and also how to build virtual worlds in Java as well as how to write 3D Java games, which was the book's original purpose. Highly recommended.

Depending on your application, It may very well be easier to use LWJGL instead of JOGL.

Java3d is indeed an abandoned project.

Depending on how "accurate" you want your collisions to be, there are several methods:

1. [inaccurate] Check the distance between two objects.
2. [inaccurate] Check to see if the minimum bounding boxes of the two objects overlap anywhere (for even easier checking, have the bounding boxes be axis aligned).
3. [accurate] Split every polygon in both objects into triangles (most meshes usually consist of triangles or quads, which you just need to split in half). Then, for every triangle in object 1, project 2 segments and treat them like lines. Find the intersection point between these lines and the plane described by a triangle from object 2. Use UV triangular interpolation to see if that point is inside that triangle. If it is, see if that point is also on the original segment.

All of these methods are more or less O(n^n), but there are various accelerator structures that can greatly reduce this complexity:

1. Octrees
2. Kd Trees
3. BVH (bounding volume hierarchy)
4. QBVH (quad bounding volume hierarchy)

Depending on the specific application, it's difficult to say which method is the best. In general though, I find that Kd Trees work pretty well.

Or, the alternative to all this math/programming, you can download bullet physics and let it handle this for you (not sure if there's a useable/good Java port, though)