JGoldRunner | Beta Release

User Code & Projects
1

Hey Monkeys!

This is my first fully-functional game built with JMonkeyEngine, JGoldRunner! :tada:

goldrunner

Dowload from here (at the releases):

Would have released this much, much sooner except for some browser issues that have plagued me the last year kept me from releasing. So this code is at least a year old now, and I have since moved on to other projects.

I wasn’t able to connect my local git repository to github (some issue with the firewall), so I have manually released the sources until I can resolve the issue.

14 Likes
2

I’m attempting to build it from source.
Where could I find the source code for the codex.jmeutil.* and codex.j3map.* classes?

EDIT: Never mind, I found them and got it running…

image
image644Ă—510 57.7 KB

EDIT2: This is a cool game.

6 Likes
3

Thanks :grin:

1 Like
4

I think there might be a bug in “Tutorial: Training 8”. Every time I try to play the level, I get a “Fatal Error” dialog that says “The level cannot be escaped from!”

1 Like
5

A ladder is probably missing at the top of the level, making it impossible to beat the level. This can be easily fixed by editing the level to include that ladder.

Sorry about that.

1 Like
6

Each time I try to edit a map I get:

May 04, 2023 1:08:41 PM com.jme3.app.LegacyApplication handleError
SEVERE: Uncaught exception thrown in Thread[jME3 Main,5,main]
java.lang.AssertionError
	at com.jme3.scene.Spatial.updateWorldLightList(Spatial.java:589)
	at com.jme3.scene.Node.updateGeometricState(Node.java:250)
	at codex.goldrunner.editor.LevelEditorState.update(LevelEditorState.java:165)
	at com.jme3.app.state.AppStateManager.update(AppStateManager.java:371)
	at com.jme3.app.SimpleApplication.update(SimpleApplication.java:258)
	at com.jme3.system.lwjgl.LwjglWindow.runLoop(LwjglWindow.java:622)
	at com.jme3.system.lwjgl.LwjglWindow.run(LwjglWindow.java:711)
	at java.base/java.lang.Thread.run(Thread.java:829)

Note: I built the app using JME 3.6.0-stable, so this is the failing assertion:

7

I’m not sure if this is causing the issue, but you could try this…

This code is found in codex.goldrunner.editor.LevelEditorState:

@Override
public void update(float tpf) {
	grid.updateLogicalState(tpf);
	grid.updateGeometricState();
}

Moving grid.updateGeometricState(); to the render method might fix it.
Not sure though, since I have not seen this issue before.

1 Like
8

By disabling assertions, I was able to edit the level and solve the “Fatal Error” dialog.

1 Like
9

Is this a Lode Runner clone?

…soooo many hours of my youth “wasted” playing Lode Runner and designing levels.

3 Likes
10

A few bug fixes:

  • fixed assets
  • fixed impossible levels

…and added a bunch more levels.

Levels can be added without needing to rebuild the whole thing from scratch:

  1. Download sources.
  2. Go to the project’s assets.
  3. Go to the levels folder.
  4. Move the level packages you want to import to your main user directory.
  5. Run JGoldRunner.
  6. Import the packages using the “import package” button.

Edit: I think I forgot to mention that pressing the spacebar is used to boost the player.

2 Likes
11

This game is cool. I also remember the days when I played this game for hours.
I love the game speed of this game. Most people make games too slow but this one is just right.
Well done.

2 Likes
12

Thanks, that means a lot to me. :sweat_smile:

2 Likes
13

Tentitive windows release.
It mostly involved including the File.seperator constant in all my File instances.

I finally got a pushing issue figured out, so the GitHub repository now contains the source code and assets. A proxy server was blocking the push, and it took longer than I expected to fix it.

1 Like
14

Just a note: “/” works on all platforms, including windows. “\” only works on Windows.

I think I haven’t used the File.separator constant since the last time I let a user specify file paths (and then only when trying to compare one path to another). For everything else, “/” will work.

2 Likes
15

Ah, I wasn’t aware of that.

16

That is because the zip file separator is a part of the Unix file system specification, the forward slash won’t work with windows file systems outside zip files.

17

Not sure if this is correct. Are you certain about this?

From an Oracle blog post:

As a side note, in literal path strings, forward slashes (UNIX style) work properly on Microsoft Windows–based JVMs, but backslashes (Windows style) fail on UNIX-based JVMs. The flexibility on Windows JVMs is possible because a forward slash is not a legal character at the operating system level in Windows paths or filenames. Therefore, if the JVM sees the forward slash, it can safely swap that character for a backslash before handing the path to the Windows system. But if a backslash shows up in a literal path string in UNIX, it’s a legal—if rather odd—character in a UNIX pathname, so simply swapping would change a valid meaning.

18

Yes, the issue on jme3-alloc was original because of using the Unix File separator to construct an absolute file path on the Windows file system, the native code of jme3-alloc-logger also required me to use an escaped backslash as a file separator.

Maybe this statement means within JVM only (such as jar files and command line tools).

1 Like
19

Java is 100% fine with / on all platforms.

Windows native code will of course be different.

Cases where File.separator come up are when you are trying to do things like subtract or split paths from canonical files/paths… because of course that will be using native file separators.

Show me a case otherwise and I’ll show you how you misinterpreted it.

2 Likes
20

Yes, it’s a split path use-case, but that split-path use-case works fine with “/” for zip entries, but it didn’t for regular files on windows file systems.

1 Like