It's a 2D randomly generated abstract shooter. Everything except the music (code, art, etc.) has been created by me.

I'd recommend downloading either the EXE or the executable Jar over playing it as an applet. It's a bit more fun as a fullscreen desktop game, and it allows the user to use the persistent high scores and soundtrack features.

That's intentional, actually. When you first see the initial loading screen, the game first tries to load everything in a separate thread (using context sharing). If that succeeds, the loading screen is animated, If context sharing fails, you get an error message but no crash, and you can design the game to do an alternate loading process.

It occurs to me that adding an option to turn off this error message would probably be a good idea.

I actually brute forced the background; since it's 2D I couldn't get actual perspective without having the rendering code be completely custom. Each node in the "grid" is a separate object.

Basically, as the player moves around, the instant that a portion of the Grid goes offscreen, it places itself on the other side of the screen, and randomizes its image and transparency. That way, there are only as many Grid cells in the game that you can see at any time.

EDIT: I gotta say, this is extremely well done. The game, the engine, the code, the organization....you sir have accomplished a great feat. However, I feel like you have overused static classes just a bit

I noticed that, and have no clue what caused it. It should be working now.

Quote

I gotta say, this is extremely well done. The game, the engine, the code, the organization....you sir have accomplished a great feat. However, I feel like you have overused static classes just a bit

Thank you VERY much for the compliment. It means a lot to know that 1.5+ years have been worth it. And yes, using so many static classes did concern me, but it seemed like the best idea at the time for a number of reasons:

1: They offer functionality which is best if universal.Consider the input code: KeyboardHandler and MouseHandler. For each instance of the game, there will only be one keyboard and one mouse. Additionally, virtually any section of the game may need to access input data. Thus, I make the input data static, so that it can be accessed from anywhere in the engine and will always be consistent.

2: I wanted the API to be as simple as possible.It seemed simpler to be able to say

which seemed to me to be the logical extension of not using static classes.

Maybe this is just due to my inexperience, though. That's why I wanted it to be open source, actually.

Quote

Obviously you need tutorials and stuff

I do need tutorials, I agree. The reason I don't yet is from juggling college classes, a programming internship, and a general desire to finish this project up.

However, I'll see what I can do. Don't expect them right away, though.

Quote

This is relevant to my interests.Using Slick Canvas, for applications in which you want OpenGL rendering, is a pain; that canvas is unstable as hell.

Perhaps I should add the caveat that I support using a single AWT Canvas. The current functionality is basically some utility functionality based upon Display.setParent(). I've worked with AWTGLCanvas before (which is how you obtain multiple OpenGL views), and it is truly a pain. I didn't include it because it is so unstable.

However, if you simply want a single canvas, go right ahead with jRabbit.

This is relevant to my interests. Using Slick Canvas, for applications in which you want OpenGL rendering, is a pain; that canvas is unstable as hell.

From my experience with 2.7.1 lwjgl, it doesn't mix well with Swing components in the same window and the AWT event queue is borked on Windows (i.e. you won't be able to attach any kind of listener to the canvas). It really is meant to run in its own window/fullscreen and use its own input handling (and at this it excels).

For all the bad rap that it gets on these forums, I think JOGL is more suitable if you want to embed one or more OpenGL canvases into a traditional Swing app with lots of Swing controls. Likewise if you want to use AWT event handling, call Graphics2D to paint on top of the canvas, and/or do passive rendering on the EDT.

I was reading over the javadocs for your engine, the zip file hasn't even finished downloading yet and I am in love! Of what I can tell from the docs this is very well thought out and implemented. Great work, and I can't wait to use it for my next game!

[edit] well i got everything set up and working, now where to begin. Perhaps a 'make a standard game' tutorial is in order. If I knew more about the implementation I would do it!

Hello! Is there any way you can write some documentation on this? This really seems comparable to slick2d and libgdx. I want to use to badly, but I'm not good at learning things by just looking at the source for micron. Once, I learn it, I can help you write lots of tutorials, though!

@8keepI'm not the developer but here my two cents. If this lib acts as higher level (API helper) to lwjgl, then you can use this lib as long as lwjgl doesn't change hardly their API. Mean you can update this lib by replace the lwjgl lib to newer version so you'll gain the performance update. But if lwjgl's API hardly changed like libgdx, there's chance current version of RE can't be used with new one.

which seemed to me to be the logical extension of not using static classes.

Not really a fair comparison. A fairer version of 2) would be :

1

if (getParentGame().getKeyboardHandler().isKeyDown(Keyboard.KEY_X))...

another alternative would be to 'push' the keyboard handler to the client, rather than the getParentGame().getKeyboardHandler() 'pull'. Which would give you client code of :

1

if (keyboardHandler.isKeyDown(Keyboard.KEY_X))...

The main benefits of an approach like this are :1 Unit testing is easier - you can inject in different Test Doubles2 Polymorphism. You could have different implementations of these classes. This could make your code more flexible.

The main cost being the extra overhead & complexity. I would say that this is quite small but definitely non-zero.

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