Hey guys, first let me introduce myself I'm just your average 19yo boy I'm here because I have great game design ideas and I'm trying to make a MMORPG like minecraft but instead of cubes I will use DINOSAURS!That was the mandatory "i want to make new minecraft/mmropg joke" but seriously I came here because our teacher said we will make a little game in java at the end of semester and since then I'm lurking about java and games.As a filthy webdesigner I really like java, it's really "clean" compared to stuff I usually do (I can't code in php anymore) and I love the fact that you can create objects and use them, but on the other hand recommendation for beginners in gamedev are just plain confusing let me show you :

What I'm supposed to do? Is java2d really awful? I don't want to make fancy stuff I just want to experiment and at the same time don't want all this knowledge to be wasted (if java2d isn't viable anymore everything I learned will be null?). I looked some java2d tutorials and I noticed they all use the same "boilerplate" code (basically notch code, on youtube atleast) so yeah..Slick2d seems to be nice if your focus is "make 2d games" since you can work more easily on content but that's not my case I'm more interested in experimentation than releasing content.So what should I do?

Java2D is really cranky; it's hard to get it to perform reliably across operating systems, JRE versions and sometimes even across drivers. Few people know all its tricks and ins and outs, and almost nobody uses it for games.

If you fancy getting low level, use LWJGL and write straight to OpenGL and OpenAL. There's a bit of a learning curve but it's only a little bit steeper than Java2D. It's relatively simple, has more or less guaranteed performance, and has tutorials everywhere on how to do mostly anything. Mostly everybody uses LWJGL for games written in Java.

If you want some of the work done for you, use libgdx and pick and mix from the extras it provides on top. On the desktop, libgdx just uses LWJGL. libgdx biggest attraction is that it abstracts the underlying APIs so that your game will be runnable on the desktop, Android, HTML5, and even eventually iOS as well, at the expense of a little extra space in your brain. The API abstraction is really just the tip of a very complex iceberg though so don't go imagining it to being a magic bullet.

Slick2D was designed for people who already knew and liked Java2D and wanted to migrate to a faster solution, however whether it's actually faster these days is moot as much of Java2D was accelerated adequately anyway.

Java 2D was improved from Java version to version, though. It used to perform fairly well on Windows, but often had problems on Linux, at least that is my experience in my projects. I have no experience on other platforms.

I use it, because it is available in each Java installation, and does not require any additional libraries. This usally means less sources of deployment troubles, and easier distribution.

It also depends on the game you are going to make. An action-shooter aimed at twitch reactions of players will most likely not work well with Java 2D. If you make a strategy game, port a card game on a board game to a computer game, it should be good enough for sure.

Even in 1998 when I made a boulder dash clone as an applet to see if Java can be used for games, it was "good enough" for that. Since then it became a lot better, and surely still is good enough for many games.

Java 2D is a very powerful API IMO, and even if it doesn't have top-notch performance it has a lot of inbuilt goodies which can be very useful. I assume this is exactly the reason why it doesn#t perform so well - it can do a lot, and this causes some overhead even for simple operations.

I want to second this. I work with it so long now, and there are still a lot of features which I never used, and/or which I didn't master. But I think I'll stick with Java 2D until I make something fast paced, or something that needs 3D anyways.

Slick2D was designed for people who already knew and liked Java2D and wanted to migrate to a faster solution, however whether it's actually faster these days is moot as much of Java2D was accelerated adequately anyway.

Last I tested, Java2D with its various accelerated pipelines was still a few magnitudes slower than Slick2D (keeping in mind that Slick2D doesn't use any of the newer and faster OpenGL techniques). Java2D and its AWT/Swing parts just weren't designed for games.

Java2D with its various accelerated pipelines was still a few magnitudes slower than Slick2D

A magnitude usually means ten times difference, a few magnitudes implies something like 1000 (4 magnitudes) difference. On windows where Java 2D can use hardware acceleration, I have troubles to imagine that. Is the difference really that big?

Java2D with its various accelerated pipelines was still a few magnitudes slower than Slick2D

A magnitude usually means ten times difference, a few magnitudes implies something like 1000 (4 magnitudes) difference. On windows where Java 2D can use hardware acceleration, I have troubles to imagine that. Is the difference really that big?

I think (and speaking with my own experience) he is talking about java2d being ~2-5 times slower.

Well, in this case, you may not want to use anything other than what your teacher expects. And when a teacher says "we will make a little game in java", he either supplies a little framework or will just use Java2D.

So I would really ask before you dive into something because OpenGL and Java2D are entirely different.

For the pros: In Java2D you might learn how to get an image to be "managed", useless knowledge for later opengl coding.And in OpenGL you may learn that its ideal, most of the time to use power of 2 textures and that binding textures takes a deal of performance, so spritesheets make sense.

My journey was Java2D -> Slick -> LibgdxOn that journey I have ported a game from Java2D all the way to now Libgdx.

Apart from the libraries, which have to be included and stuff, which might be confusing, Slick2D is probably the easiest, then Java2D, then Libgdx

Problem with Java2D is you have to write your own gameloop, throttle frames, get to know what and how you can draw on some elements like canvas, double buffering - a lot of stuff you dont have to deal with, when using other options.

So my advice is ask your teacher =PIts no use when your teacher tries to explain bufferedimages, canvas, affinetransform and you are using something other than java2d...

Problem with Java2D is you have to write your own gameloop, throttle frames, get to know what and how you can draw on some elements like canvas, double buffering - a lot of stuff you dont have to deal with, when using other options.

I know I keep parroting these lines.... But for a newcomer who is learning, actually having to manually do all the low level stuff is a good learning experience.

Think of it as a car. You don't need to know about the inner workings of a car to drive it, but it sure helps when you inevitably need to do some maintenance.

And if the game is really simple (let's think PONG simple), the infrastructure requirements are low enough that doing it all "by hand" is feasible.

(And if you're starting with game development, you should be aiming at PONG simplicity... Ok, you can make the paddles out of Dinosaurs.)

Cero, those problems generally exist in any low-level API (incl. LWJGL and JOGL).

Oskuro, I prefer to adjust your analogy: think of game development as a making a car as opposed to playing games which is driving a car. Suddenly cars are a lot more complicated than anyone thought. Who knew?

Problem with Java2D is you have to write your own gameloop, throttle frames, get to know what and how you can draw on some elements like canvas, double buffering - a lot of stuff you dont have to deal with, when using other options.

I know I keep parroting these lines.... But for a newcomer who is learning, actually having to manually do all the low level stuff is a good learning experience.

Think of it as a car. You don't need to know about the inner workings of a car to drive it, but it sure helps when you inevitably need to do some maintenance.

I dont fully disagree, of course it can be interesting and helpful, but it comes at a cost: time.You may waste time worrying over low level problem that already have been solved.If you are really a high level game developer / designer, you want to get things done. A technician might be interested in the inner workings.

My point is: Unless you start at assembly language, you will always have a level of ignorance between you and what is happening under the hood. If you want to make a product, these libraries are tools to make it possible.I may be able to open a can of food without a tool... during that process I may learn things to build my own tool, and then if my bought can opener break, I might understand why and may be able to fix it.But normally, when you are product focused, get tools, learn how to use them and choose the high level route.

My fridge keeps stuff cold. I need my food to be cold. I dont care how it does it - its a black box.

As LibGDX improves, there is becoming less and less reason to use LWJGL. At the lowest level, LibGDX is just a thin OpenGL ES wrapper that ports to Android, WebGL, and iOS in future.

Slick is nice as it abstracts concepts like frame buffers, matrices, "orthographic" projections, blend functions, etc. However; it's buggy, not suitable for larger projects, relies on old techniques, doesn't port to OpenGL ES, and is now pretty much dead.

Hey guys, first let me introduce myself I'm just your average 19yo boy I'm here because I have great game design ideas and I'm trying to make a MMORPG like minecraft but instead of cubes I will use DINOSAURS!That was the mandatory "i want to make new minecraft/mmropg joke" but seriously I came here because our teacher said we will make a little game in java at the end of semester and since then I'm lurking about java and games.

Obligatory, default, dull, response.Do not start with a multiplayer game. Takes forever to debug plus you have to deal with servers etc etc etc.Try to develop by your own. Chances are the class will move too slowly, and your professor/teacher might not know that much about game programming, it's not exactly all the same as "normal" java (excuse my terminology).

Also,

LibGDX is THE ANSWER. Although it's fine to start with Java2D. Just use a game loop.

Oskuro, I prefer to adjust your analogy: think of game development as a making a car as opposed to playing games which is driving a car. Suddenly cars are a lot more complicated than anyone thought. Who knew?

Actually, the car in my analogy is the system upon which you're building the game (Say, the JVM and its related classes, etc...)

But let's not get into an analogy fight..... I mean, that'd be like two parrots arguing over which one is polly and wants a cracker.

Oskuro, I prefer to adjust your analogy: think of game development as a making a car as opposed to playing games which is driving a car. Suddenly cars are a lot more complicated than anyone thought. Who knew?

Actually, the car in my analogy is the system upon which you're building the game (Say, the JVM and its related classes, etc...)

But let's not get into an analogy fight..... I mean, that'd be like two parrots arguing over which one is polly and wants a cracker.

Well you do know that this analogy is wrong, bringing the JVM into it. Because Game dev and Software dev in general is done using other languages and there is no JVM equivalent with C++. Unless you say its the OS then, but that would be ridiculous =D

JavaFX is the new hotness when it comes to "standard" Java doing realtime graphics I think.

Cas

JavaFX is a much improved successor to Swing for doing traditional component GUIs with edit fields, checkboxes, grid controls, and some multimedia and animation functionality.

JavaFX is not appropriate for games at all in the same way that Swing wasn't. Actually people would often use the very basics of Swing just to setup a drawing context. JavaFX isn't applicable on that level.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org