JUMG - Java Utilities for Making Games

WIP games, tools & toy projects
#1

Ladies and Gentlemen,

May I introduce you to my latest piece of work, JUMG:

What is JUMG? (https://github.com/TheBrenny/JUMG/#what-is-jumg)
JUMG (pronounced ‘Jum-Gee’, acronymed ‘Java Utilities for Making Games’) is a library that contains multiple utilities to make Java Games the most efficient way. JUMG utilises the concepts of separating certain portions of code from the rest, to allow one main class to bring them altogether.

As JUMG is in development, it is necessary for a checklist to be made of what needs to be added, and what is added. This can be found over on the JUMG GitHub page: https://github.com/TheBrenny/JUMG/.

Who is BrennyTizer? (https://github.com/TheBrenny/JUMG/#who-is-brennytizer)
BrennyTizer is not a person, it is merely a blog/portfolio of one’s work. That person who’s work is being collected is Jarod Brennfleck. He is the guy who is constantly working hard to develop programs while achieving good grades at school. Currently a Year 11 student, Jarod has completed a few programs for some classes which he will be releasing soon online! For all the news and updates, check out his website at: http://brennytizer.com.au/

Why do I need JUMG? (https://github.com/TheBrenny/JUMG/#why-do-i-need-jumg)
You don’t * NEED * JUMG, it’s simply a tool to speed up the process of creating games with Java. JUMG just simplifies the process by extinguishing the boring bits of code from your main class. Consider the following:


// Without JUMG
public static void main(String[] args) {
  Dimension size = new Dimension(600, 500);
  JFrame jf = new JFrame("Title");
  jf.setPreferredSize(size);
  jf.setMinimumSize(size);
  jf.setMaximumSize(size);
  jf.setSize(size);
  jf.setLocationRelativeTo(null);
  jf.setFocusTraversalKeysEnabled(false);
  jf.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
  jf.setLayout(new BorderLayout());
  jf.add(new OverridenPanelWithAwesomeRender(), BorderLayout.CENTER);
  jf.pack();
  jf.setVisible(true);
}

This clump of code (plus extra, woo!) can be condensed down into just a few lines such as the following:


// Using JUMG
public static void main(String[] args) {
  Dimension size = new Dimension(600, 500);
  Frame f = new Frame("Title", size);
  f.addDisplay(new Display(size, new MyRenderer(), null));
  f.show(true);
}

Now how much of a clamp-down is that?! JUMG just removes the boring code that we all dread to write repeatedly, and plonks it in nice little classes that allow you to have full control of. Yes, that’s right. Nothing in JUMG has a private modifier - although it’s bad practice - but as far as this library is concerned, there is no need to privatize anything. That frame that just got created in the JUMG example has a public JFrame in it’s class. If you don’t like it how you can’t resize the frame, you can call the JFrame.setMinimumSize(Dimension) and JFrame.setMaximumSize(Dimension) by using Frame.frame.set*Size. Or you can set it to your own customized frame - provided it extends JFrame in some way!

How to use JUMG (https://github.com/TheBrenny/JUMG/#how-to-use-jumg)
Due to JUMG’s unique style of a multi-library mode, you can select which libraries you want to implement. This allows for a slim development of your game - if that’s what you’re after. There a not many necessities that come when it’s time to implement, but one of these is the utils package is a must, no matter what package you’re after. The utils package is an all round package which implements the most important tools into the library. The utils package contains methods such as logging, images, and certain units of measurement (which are annoying to implement with java - cough angles). But then again, that’s what JUMG aims to do. Cut down your boring code so you can work faster.

So if the previous paragraph was a tl;dr for you, you can find the instructions over on GitHub: https://github.com/TheBrenny/JUMG/#how-to-use-jumg

Do note that editing these packages are NOT against the license that is held on JUMG. IT’s encouraged that you edit the library, but also don’t forget to send a pull request to the main GitHub repo! You work will be credited, so help out!

Get it now from GitHub: https://github.com/TheBrenny/JUMG

Now that that is out of the way, I can get down to more of a 1-1 developer style. I look forward to working with many of you game creators on developing this library to get it up to a very high standard of work!

A really good way to help out is to email me at my email which you can find on my profile (I don’t want to express it here because robots and crawlers can nab it…). On top of that, get yourself a copy of Saros for Eclipse and install it. That will allow us to work collaboratively.

I understand that this library doesn’t compare to LWGJL, jMonkey, or any other Game engine, but this library is to provide support for the guys who don’t like all the aesthetic carp such as frame building when all they really want to do is code a wildly great engine.

Here’s a screenshot of all the packages:

~TheBrenny

#2

What does your engine do that these engines don’t?
http://www.java-gaming.org/topics/sjgl-simple-java-game-library/34723/view.html
http://www.java-gaming.org/topics/red-game-2d-engine-unfinished/34367/view.html
http://www.java-gaming.org/topics/introducing-mercury-a-simple-2d-game-library/30862/view.html



I wouldn’t say that lwjgl is just “aesthetics”; it is one of the best ways to get openGL in Java, and because it is hardware accelerated it’s always going to be miles faster than AWT.

#3

…and OpenAL, and OpenCL, and newly GLFW.

#4

Oh my, another engine/library/framework… Are you sure there’s not enough already? Like, don’t get me wrong, you can make it, but I don’t think sharing it will do anything. LibGDX is still going to be used much more (no offense). And most engines/libraries/whatever–you-get-it aren’t even finished. And no-one wants more dead threads here.

#5

Orange451, my library contains extra methods and functions, such as events and message routing, already implemented level design, straight up path finding, and other utilities that will evolve into enhanced packages. My library also has no cross package referencing, excluding the utils package. One does not need every package, only the utils package and the ones they want. As far as I can Dee, each library will just increase the size of someone’s game. Sure, I admit, my sound manager is a little bit undercooked; it doesn’t support a lot. But it’s still better than nothing, right? In the end, the user can just nab their own library, and in the case of a Dev, they can add to JUMG.

MrPizzaCake, I agree, LibGDX, Open*, and other well known libraries will be used MUCH more often. But those libraries carry weight, (including LWJGL despite its name). This library, doesn’t include outside dependencies. And the developer can choose what they want to include. This allows for smooth and fluid control over what gets implemented.

#6

Just because LWJGL isn’t in the standard library doesn’t mean it’s not lightweight.

The standard library rendering pipeline (Java2D) uses OpenGL underneath (not by default on some platforms), but in a convoluted and unpredictable way that gives you very little control over how you want something rendered.

LWJGL is more lightweight and allows far more control of rendering than the bloated black box that is Java2D.

(That’s not to say nobody should use Java2D. It certainly has some uses, but it isn’t good for high-performance games)

#7

HeroesGraveDev, interesting point. I will take this into account, as I move closer the the release. ;D

#8

I just have a little constructive criticism after skimming over the source.

I notice that the engine uses Java2D for rendering. This is generally not a good rendering backend to use for games. Your tiling system is also based off a BufferedImage, which could slow the game down if you attempted to load multiple maps. I also don’t like the practice of doing things like extending Buffered Image or Rectangle2D “to make it easier”. I also feel like the classes in utils should generally be small standalone classes, and I don’t like one-class packages

I know that some of these are personal qualms, and I also think that creating an engine can be good for learning. However, don’t expect people to just pick it up and use it.

My advice is to learn some OpenGL, and have fun making games, not making libraries that simply don’t do as much as the highly popular competitors.

#9

CopyableCougar4, cheers! After the previous posts relating to the use of OpenGL and such, I’ve realised that it is ideal to use it. As for tiling with a BufferedImage, when creating maps, I generally load the maps needed at startup, leading to an expensive start, but then draw all the tiles to one big BufferedImage, so I’m only rendering one image, instead of many. I understand, this could be optimised if OpenGL was implemented, so I’ll see what I get up to.

I don’t quite understand what you mean by “Standalone Classes”… But they’re in the utils because they’re used library wide.

And the one-class packages? The updating package is it’s own package - for the reason that it is a singular component of th library. It doesn’t need much more. And the compression package is its own project. It’s going onto GitHub soon. :slight_smile:

#10

I had a little skim over the source as well and wanted to raise some issues.

So you have the Frame class that covers up the horrible initialisation methods that any Java2D project is littered with, however all your doing is hiding functionality and adding extra class.

For example:

// Without JUMG
public static void main(String[] args) {
  Dimension size = new Dimension(600, 500);
  JFrame jf = new JFrame("Title");
  jf.setPreferredSize(size);
  jf.setMinimumSize(size);
  jf.setMaximumSize(size);
  jf.setSize(size);
  jf.setLocationRelativeTo(null);
  jf.setFocusTraversalKeysEnabled(false);
  jf.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
  jf.setLayout(new BorderLayout());
  jf.add(new OverridenPanelWithAwesomeRender(), BorderLayout.CENTER);
  jf.pack();
  jf.setVisible(true);
}

This here is the typical init code most Java2D projects start with, as you have stated it looks like shit, really it does. However, you could easily just slap all that in a method and call it, cleaning up the constructor or whatever and hiding it anyway. So your way is actually just hiding preferences behind a class and making it a little more hassle to get access to one of these preferences.

Like so:


// This is your way
Frame f = new Frame("someTitle", size);
// Now what if I want to change the minimum size? (for whatever reason)
f.frame.SetMinimumSize(smallerSize);

It just seems like most of the library hides code from you (which is fine) but does not extend on the functionality of the already existing code.

Why don’t you just have Frame extend JFrame? Literally solves that problem anyway lol.

Also is it an Engine or a Framework? At the moment it’s like a hybrid, either do one or the other. Or expect project implosion.

#11

A good way to incur users hate on you…
… as soon as you change implementation details - what will happen sooner or later.
Exposing each and every member means extending the public interface that a library offers its user base.
And changing internal details will break people’s code quite probably.

A special problem occurs when on the one hand synchronizing stuff for thread safety but at the same time making locked members public.

#12

Reading through this on Github, and the code is odd. Public members that still have mutator methods, which are intended to provide encapsulate of private members… That doesn’t quite make sense!