Java4K framework WIP / discussion

Contests nK Game Competition - 2015
#1

In an effort to breath life back into Java4K, I’m testing the waters with a Java4K platform. I’m sharing this WIP early, and plan to have a ton of revisions, based on your feedback, and/or my gut feeling.

My plan for Java4K is to lower the barrier to entry that haunted the last few years of Java4K. The toolchain required to build a tiny *.jar.pack200.gz was daunting, even for experienced members of the community. A newby would find that his bare bones main-loop would consume ~2500/4096 bytes, while those in possession of said toolchains could fit over 30KB of sourcecode in their 4KB binary. Suffice to say that this played at least some role in the Java4K contest participation rate dropping over the years.

To lower the barrier to entry, we have to make some radical changes to how the contest is setup - to the point where ‘Java4K’ may be a bit of a misnomer. Instead of focusing on binary size, we will focus on sourcecode size to which asset-sizes will be added. Entries (source + assets) will be limited to, say, 16K of sourcecode, which previously would have yielded a ~4K compressed binary for somebody with a reasonably advanced toolchain.
The result will be compiled & packed (serverside on JGO) in a JAR of which the final size plays no role. Both newbies and experts will likely find such a limit challenging enough to write a decent game with enough features, while still being restricted enough to ‘get it done’, reducing chances of feature creep.

To lower the barrier to entry even further, I will provide a game-loop, and people simply have to implement render() and/or update(), where a minimalistic valid contest-entry would be like:

[icode]MinimalisticEntry.java[/icode]


-public class MinimalisticEntry extends Java4kRev1 // which extends javax.swing.JPanel
+public class MinimalisticEntry extends Java4kRev2 // which extends java.awt.Canvas
{
   int x;

   // called 60x per second
   public void update() { // move across screen at constant rate, regardless of framerate
      if(++x >= w) x = 0; // 'w' & 'h' provided by superclass
   }

   // called at most 60x per second
   public void render(Graphics2D g) {
      g.setColor(Color.YELLOW);
      g.drawRect(x, mouse.y, 64, 64); // 'mouse' provided by superclass
   }
}

[icode]Java4kRev#.java[/icode] (superclass of your entries)

[tr]
[td]Rev 2[/td]
[td]http://pastebin.java-gaming.org/154eb0e2a231e[/td]
[td]Backend now uses active rendering[/td]
[/tr]
[tr]
[td]Rev 1[/td]
[td]http://pastebin.java-gaming.org/e71548e1b2e1a[/td]
[td]Initial dump[/td]
[/tr]

TODO:

  • Add Keyboard support (alongside current Mouse support)
  • Add active-rendering backend, as opposed to current EDT piggyback/hack
  • Add support for identifying mouse buttons
#2

A slightly more elaborate entry

[icode]OddEntry.java[/icode]


import java.awt.*;
import net.indiespot.java4k.Java4kRev1;

public class OddEntry extends Java4kRev1 {
	@Override
	public void render(Graphics2D g) {
		// print instructions
		g.setColor(new Color(128, 64, 128));
		g.drawString("Drag the mouse a little...", 8, 20);

		// draw something mesmerizing for average Joe
		g.setColor(new Color(0, 64, 128));
		int b, r, a, c, q, t;
		for (r = 150; r >= 30; r -= 15) {
			t = ((elapsed() + 130_000) / ((200 - r) / 25));
			b = r / 3;
			a = (w - r) / 2;
			c = (h - r) / 2;

			q = (int) (t % (r + b));
			g.drawLine(a + Math.max(0, q - b), c, a + Math.min(r, q), c);

			q = (r + b) - (int) ((t + r) % (r + b));
			g.drawLine(a, c + Math.max(0, q - b), a, c + Math.min(r, q));

			q = (r + b) - (int) ((t + r - b) % (r + b));
			g.drawLine(a + Math.max(0, q - b), c + r, a + Math.min(r, q), c + r);

			q = (int) ((t - r) % (r + b));
			g.drawLine(a + r, c + Math.max(0, q - b), a + r, c + Math.min(r, q));
		}

		if (mouse.dragArea != null) { // 'mouse.dragArea' provided by superclass
			g.setColor(new Color(128, 64, 128));
			Rectangle w = mouse.dragArea;
			g.drawRect(w.x, w.y, w.width, w.height);
		}
	}
}

Result (please note the erratic framerate is caused by the GIF, not the game-loop)

810×633 381 KB

#3

Very cool, thanks for this. Might try my hand at a “4K” game soon!

#4

Threads in the correct board(s) will automatically have the required forms to manage your contest-entry. Just copy/paste your source, upload your assets and press ‘publish’, and it will… happen. Visitors will see the *.jar and/or signed applet in the opening post.

#5

You’re investing a lot of time into this, I’m glad to see this happen. I might finally submit a game for once!

#6

I realize it’s against the principle of the contest, but I guess there’s nothing to stop participants from String-encoding compiled code - essentially turning it into a “16KiB minus encoding & instanciation overhead” contest.

#7

Abuse: I don’t care really :slight_smile: If people want to be jerks, then so be it. :cranky:

Similarly, nothing prevents a contestant from fetching a JAR from the web, and attaching it to the ClassLoader. It’s against the spirit and the rules of the competition. If anyone wants to ‘win’ like that, hoping to get away with it, then I feel sorry for the bastard.

#8

This looks promising!

#9

The main reason I never got into J4k was the necessity to use Java2D.
Will this still be a requirement in the new compo?

I don’t really want to learn a new API simply to participate in a jam.
Maybe I’m the odd one out though, still using LWJGL2.

#10

Where would/will we draw the line? LWJGL? LibGDX? Any library?

Besides, if you’re familiar with LWJGL, and willing to enter a sourcecode restricted contest with LWJGL, then Java2D is peanuts.

#11

I’m excited to see how this goes and maybe participate in my first Java4k :slight_smile:

#12

Well libgdx is bloated and lwjgl leaves a lot of work for the developer, not really much in between that I am aware of.