There are three game "states" (stored as an enum) in my game. The overworld (where the player walks around) the battlescreen (where the player fights enemies) and the inventoryI am trying to organize this as nealty as possible

In my "GameDisplay" class (which makes the game window, which I have successfully done) I made a method called "render()" which is called in the game loop

If you're using Silck2D, it has utilities for states and such.If you're using only Slick-Util, and you want to do things from the ground up, then you'll need to write your own states. It's relatively simple to do with classes.

The basic idea:

Your Game class has a list of GameState objects, and keeps track of which one it's currently showing. Depending on your game, you may want to load all the state's resources during the init() of your game (like Slick2D). Or you might want to load and destroy resources as you enter/exit states (i.e. only keeping what's necessary in memory). The Game class simply renders/updates whatever current GameState is selected.

How you decide to organize this is up to you. Maybe you'll use enums? Or maybe you'll use generic objects, to allow for an infinite number of states?

Maybe you'll want a single game state to hold multiple "screens" -- i.e. an InGameState which holds different "screens" for each level, or a MainMenuState which holds "screens" for options, help, credits, etc. It all depends on the complexity of your game and how you'd like to implement it.

Actually, I have already implemented something very similar, it looks like what davedes suggests but in more general as I use states to handle the weapons too. I use Fettle API which is really a tiny and simple API to create state machines. I don't directly store the states, I store the transitions between them. I can detect whether I enter a state or whether I get out of another one. Each time I go to another state, I hide all others and I show only this one. Each state is bound to a controller that updates the model (think about MVC) and renders the view(s). You can put some memory managements in transitions as davedes suggests, for example to destroy direct NIO buffers. I use a kind of task manager to handle the progress of loading, some states are then only used to display a progress bar and load all data for the next one. My source code does not explicitly rely a lot on a specific binding so you might be able to reuse it. If you already use Slick2D, you don't need my help, ra4king's suggestion is more appropriate in this case.

A few things:1. I've never touched init() ever, this is a application, not an applet, so I don't use init(), right?2. I'm using Slick-Util and not Slick 2D, but I could install that if necessary3. Which opengl initializations does it want? I've made another class that makes a blank window, and it uses these initializations

Then you can increase Display.sync() to somewhere higher than 60, like 75, to cover for computers that are a little older and don't support vsync.

1) The init() function should contain the code you need to initiate OpenGL and the display window. It has nothing to do with applets except naming the method the same.

2) If you want to use Slick2D you will have to discard all that code that you have there and follow the tutorials offered on the Slick2D website. Slick-util works fine for writing LWJGL applications, however.

Slick2D is easier and more Java2D like, but if you are a beginner in Java game programming you REALLY should just stick to Java2D.

3) You might also want to enable transparency with the following before the rest of your OpenGL initialization code.

That import had been there. It really just doesn't seem to want to accept the opengl initializations I put in the Overworld class (in the constructor)(Also thanks for the vsync and transparency tips, I put them in)

Is there another way anyone knows of to separate the rendering of the display in different classes?

A few things:1. I've never touched init() ever, this is a application, not an applet, so I don't use init(), right?2. I'm using Slick-Util and not Slick 2D, but I could install that if necessary3. Which opengl initializations does it want? I've made another class that makes a blank window, and it uses these initializations

1. Generally "init()" is a method you define that loads images, sounds, setups up orthographic projection, and so forth.2. Slick-Util is a small subset of Slick2D. It's basically a couple of core classes extracted from the full library. If you want to keep learning OpenGL, stick with Slick-Util, or use another library like LibGDX. If your main goal is to just make a game, then you might find it easier to use Slick2D, LibGDX or another high-level library.3. Game states has nothing to do with OpenGL initialization. It's just a matter of object-oriented design: moving what you have now (a switch statement) into classes.

You should also enable texturing: glEnable(GL11.GL_TEXTURE_2D) before rendering.

but if you are a beginner in Java game programming you REALLY should just stick to Java2D.

Nah, I disagree. IMO Java2D is much harder to use than Slick2D for a beginner. And aside from the obvious performance gains of using Slick2D (OpenGL vs software rendering*) you also get a lot of features related to game development, which obviously Java2D does not include. Things like game states (hence this thread), Tiled integration, bitmap fonts, themable UIs, basic pathfinding utilities, OGG decoding/streaming, etc.

[size=8pt]* You can enable hardware acceleration in Java2D with a JVM switch. Unfortunately, it's unreliable -- some users report a decrease in performance, others report no change, etc.[/size]

but if you are a beginner in Java game programming you REALLY should just stick to Java2D.

Nah, I disagree. IMO Java2D is much harder to use than Slick2D for a beginner. And aside from the obvious performance gains of using Slick2D (OpenGL vs software rendering*) you also get a lot of features related to game development, which obviously Java2D does not include. Things like game states (hence this thread), Tiled integration, bitmap fonts, themable UIs, basic pathfinding utilities, OGG decoding/streaming, etc.

Slick2D has a lot of code that you don't understand until you've gained a bit more experience. Java2D, on the other hand, is simple and easy to understand from the start. Slick2D may have better performance, but it doesn't really matter at beginner stage. With Java2D, you just need some imports to be set up, but with Slick2D you have to download LWJGL, tell it where it has its natives, and then download Slick2D and install it. There are also a lot more tutorials on Java2D, compared to Slick2D which has only a handful to a dozen tutorials.

but if you are a beginner in Java game programming you REALLY should just stick to Java2D.

Nah, I disagree. IMO Java2D is much harder to use than Slick2D for a beginner. And aside from the obvious performance gains of using Slick2D (OpenGL vs software rendering*) you also get a lot of features related to game development, which obviously Java2D does not include. Things like game states (hence this thread), Tiled integration, bitmap fonts, themable UIs, basic pathfinding utilities, OGG decoding/streaming, etc.

Slick2D has a lot of code that you don't understand until you've gained a bit more experience. Java2D, on the other hand, is simple and easy to understand from the start. Slick2D may have better performance, but it doesn't really matter at beginner stage. With Java2D, you just need some imports to be set up, but with Slick2D you have to download LWJGL, tell it where it has its natives, and then download Slick2D and install it. There are also a lot more tutorials on Java2D, compared to Slick2D which has only a handful to a dozen tutorials.

Overall Java2D is better for when you're just starting out.

Exactly! This (and the reason that there are more graphical features in Java2D than Slick2D) is why I still say Java2D is the perfect beginner playground.

I think your problem here is that you instanciate your state classes in the attributes declaration which happens before the GameDisplay constructor is called ... you should do this in the GameDisplay constructor after the init of the Display instead.

Java2D, on the other hand, is simple and easy to understand from the start. Slick2D may have better performance, but it doesn't really matter at beginner stage. With Java2D, you just need some imports to be set up, but with Slick2D you have to download LWJGL, tell it where it has its natives, and then download Slick2D and install it. There are also a lot more tutorials on Java2D, compared to Slick2D which has only a handful to a dozen tutorials.

Overall Java2D is better for when you're just starting out.

It all depends on what degree of "beginner" we're talking about here. Something simple like tic-tac-toe doesn't require a game loop, and in that situation I can understand Java2D/Swing.

But when it comes to sprite rendering and a game loop, things that even basic games (pong, space invaders, asteroids) will want to utilize, Java2D will only complicate a beginner's life.

I see beginners doing android games all the time, and that requires even more setup than LWJGL. Seriously, adding a single native library is not the high barrier to entry people some people think it is.

One real problem with OpenGL development in general is the error messages, or the lack thereof. Setup instructions really should be using the debug library for development (I'm guilty of this too, but the debug lib isn't even in maven repos, so I can't do much about it in my instructions).

I see beginners doing android games all the time, and that requires even more setup than LWJGL. Seriously, adding a single native library is not the high barrier to entry people some people think it is.

One real problem with OpenGL development in general is the error messages, or the lack thereof. Setup instructions really should be using the debug library for development (I'm guilty of this too, but the debug lib isn't even in maven repos, so I can't do much about it in my instructions).

The people who begin Java games with Android are probably writing a lot of code that they don't understand, just like those that start with Slick2D.

And no, adding a native library isn't much. But it's yet another step you have to make to set up your project to even BEGIN to write your code. And a lot of the motivation from writing games, at least for me, is the instant results.

If enabling a single plugin or pasting in a pom snippet or configuring a system property sucks all the energy out of your project, your motivation is even more tenuous than mine. Sorry, but I'd point at things like lack of good documentation as barriers to entry, not basic setup steps shared with nearly every other library in existence.

I still think that Java2D is better for beginners than Slick2D, and so far you have only disproven my arguments without coming with any of your own.

I have to say that I'm happy I can even have this much of a discussion. There is no such thing on the Minecraft forums, except for things like how much $s graphic cards cost. And I'm not going to buy a new graphics card soon.

As a beginner, 99% of the game loops that you will be copy + pasting will go right over your head.

Who cares if they don't learn game loops on their first game? They will learn it when they are ready -- assuming they even want to learn it! You can write games without having to learn how to write the perfect game loop, in the same way that you can use a JFrame without knowing exactly what is going on under the hood.

ra4king -- where is the "super simple" and "beginner friendly" Java2D code which produces the test I asked for?

Need input handling? That's only a couple lines or so. Either way, that also proves my point that all the boiler plate is necessary to learn the basic game loop and organization of code. Otherwise, they end up with a super compact set that only does things, while they don't themselves learn. If you want results without caring about code, go with Slick2D fine, but I care about learning my way to the results.

(Java2D) is necessary to learn the basic game loop and organization of code

I'll reiterate what I said before...- You don't need to know how to write a game loop in order to make a game. There are thousands of Unity, Flash, etc. game developers who have probably never written their own game loops from scratch -- and maybe they will never need to.- Slick reduces this type of boilerplate and "low level" coding for the sake of simplicity and ease of use. Along the same vein, Java2D's Graphics allow you to use matrix transformations (rotate/scale/translate) through a high-level interface. You can "scale" the view without understanding exactly how the matrix math works, and without having to write your own matrix math boilerplate.- Many beginners will copy-paste code without fully understanding what it does. This is especially true on their first couple projects -- you just want something up and running. You have time to learn about matrix math, game loops, VBOs, etc. later in life.

Lower level knowledge is always good to have, but it's not necessarily the best place for a beginner to start, nor is it needed to make good games.

I agree that re-inventing the wheel can sometimes help you learn better practices, but most beginners (and experts alike) are not looking to re-invent the wheel. That's why high level classes exist: JFrame, ArrayList, Graphics2D, BufferStrategy, java.util.Properties, etc.

And to say that all Slick users don't care about code... that's a ridiculous statement.

Slick2D has a lot of code that you don't understand until you've gained a bit more experience. Java2D, on the other hand, is simple and easy to understand from the start. Slick2D may have better performance, but it doesn't really matter at beginner stage. With Java2D, you just need some imports to be set up, but with Slick2D you have to download LWJGL, tell it where it has its natives, and then download Slick2D and install it. There are also a lot more tutorials on Java2D, compared to Slick2D which has only a handful to a dozen tutorials.

Overall Java2D is better for when you're just starting out.

I'd disagree with the above, IMO its actually harder to get started writing Java games with Java2D than with Slick2D/LibGDX.

Some reasons are as follows:

Slick2D is designed specifically for games while Java2D is not.

To use Java2D you not only have to learn its API but also either AWT or Swing (or both) windowing API's.

With Java2D you have to write your own game loop and timer code while Slick2D comes with a built in tried and tested framework that provides both.

Java2D on recent OS X Java releases is pretty much dead performance wise, especially the all important active rendering.

Java2D's many different rendering pipelines lines provide very inconsistent performance and stability while Slick2D's one should be pretty much consistent.

JavaSound which you'll most likely use if you are avoiding natives is pretty crap for games while Slick2D's OpenAL backend is fast and provides low latency sound that is suitable for games while also providing support for formats like Ogg and XM.

Slick2D's built in framework and game focused API's mean you need less Java code than to do the same thing in Java2D.

Ask anyone that has done serious game development with Java2D, you need to jump through all sorts of hoops to get performance and smoothness out of it for fast games (like managing your own bufferstrategy for double buffering while this is done by default for Slick2D) and in the long run it is a dead end for games as you'll likely hit some sort of performance limit.

Slick2D is just a light wrapper around LWJGL and you can easily drop down to the lower level OpenGL API if you like (I even occasionally use it for prototyping 3d stuff as the framework is nice and fast for getting stuff up quickly).

Performance is much better on Slick2D and you can throw all sorts at it (including images with lots of transparency) before you need to worry about performance, not so with Java2D as it has a lower limit which can be hit much more easily thus causing frustration and less productivity.

Slick2D has a strong gaming focused community around it and thus easier to get game related help for it while Java2D's game community is more scattered.

Java2D, AWT and Swing are pretty much legacy API's at this stage with Oracles engineers and resources having been moved to their successor/replacement, JavaFX. Soon these old API's will be moved to some JDK module for backward compatibility only where they'll be left to slowly die.

As for the LWJGL step you don't have to download it separately, it comes with the Slick2D download bundle and is a simple 2 step process to set up (do note that Java2D/AWT also have natives, its just that they are added to classpath by default, for now ).

I agree with most of the points above, though I'd take issue with a couple. You learn Swing, period, and when you want clicky button UI elements or other Swing things, the integration is nice to have. Not that a swing UI is all that desirable for games, but it suffices for learning projects. Similarly, you already have a game loop dealing with your input, so it's really just a matter of scheduling redraws, which is hardly rocket science.

Performance-wise however ... java2d is a dead end. Worse than a dead end, a tarpit. JavaFX could be promising, but I think it's not going to be til jdk8 that it will ever feel really "official", and maybe not even then.

I'd disagree with the above, IMO its actually harder to get started writing Java games with Java2D than with Slick2D/LibGDX.

Agree on Slick2D and your arguments for it.Libgdx not so much.You have to have knowledge of graphics programming before using Libgdx.Like whats a power of 2 texture, and why cant I just load any image.Whats a spriteBatch or textureAtlas; why are these things needed or at least so very encouraged.

My time in Slick told my everything I needed to know; but our game still uses Slick and still loads some images which are not power of 2...

bottom line: Slick is very easy to use, but performance gets questionable when the project gets bigger, if you dont develop your opengl skills.Libgdx is better designed but harder to use. It's understandable because it has a heavy focus on android, and performance is very important there.

Of course its all better than java2D by far. Especially when Slick2D's API is so easy and straight forward and familiar to Java2D users.

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