Blasted Crates

[Hsaka]

A simple, addictive and sometimes difficult one-button game requiring ninja-like skill and reflexes. More levels coming soon.
Made with LibGDX.

http://gamepyong.com/blasted_crates/index.php

Some videos:
Level 8.2
http://youtu.be/nQgHMBag4Tg
Level 8.3
http://youtu.be/X6HeT7LtxWI

Update 1:
- Added 3 new levels
- Capped the delta time to prevent cheating
- Added a few new types of crates
- You will now be able to continue from the round you reached
- Rewrote the storyline to be somewhat like a Bastion-esque narration (at least it sounds like the Bastion narrator in my head when I'm reading it )

[Riven]

I like the game, but for a game that requires lightning reflexes, the variable input lag is somewhat killing it. Sometimes when I hit the spacebar, I immediately jump, while on other occasions it waits for like '10px' (whatever that is in millis), meaning that I cannot physically make the next jump. Sometimes the input lag is so bad that I start jumping after respawning

[teletubo]

I couldn't beat the damned stage 3!

I didn't experience the lag Riven said.
However, when I first clicked on HighScores, I got a NPE:

1   2   3   4   5   6   7   8   9   10

Exception in thread "LWJGL Application" com.badlogic.gdx.utils.GdxRuntimeException: Error reading audio data.    at com.badlogic.gdx.backends.openal.Mp3$Music.read(Mp3.java:90)    at com.badlogic.gdx.backends.openal.OpenALMusic.fill(OpenALMusic.java:170)    at com.badlogic.gdx.backends.openal.OpenALMusic.update(OpenALMusic.java:157)    at com.badlogic.gdx.backends.openal.OpenALAudio.update(OpenALAudio.java:218)    at com.badlogic.gdx.backends.lwjgl.LwjglApplication.mainLoop(LwjglApplication.java:203)    at com.badlogic.gdx.backends.lwjgl.LwjglApplication$1.run(LwjglApplication.java:135) Caused by: java.lang.NullPointerException    at com.badlogic.gdx.backends.openal.Mp3$Music.read(Mp3.java:81)    ... 5 more

looking good so far!

Games published by our own members! Check 'em out!

[Hsaka]

Thanks for playing guys. About the lag, I'm not entirely sure how to resolve that because in LibGDX you can handle input either via their Polling mechanism or using Event Handling. Crates uses event handling because the LibGDX wiki says polling might produce missed events. http://code.google.com/p/libgdx/wiki/InputPolling

[Riven]

I'm in level 7 with ~400 deaths. It's really a challenging game, but annoying as ***** when you click and the guy runs straight into a tomato filled box!

[Riven]

About the lag, I'm not entirely sure how to resolve that

It might also be a logic error. Maybe there are certain conditions that are checked before a jump is allowed, which need to be fixed.

[teletubo]

Thanks for playing guys. About the lag, I'm not entirely sure how to resolve that because in LibGDX you can handle input either via their Polling mechanism or using Event Handling. Crates uses event handling because the LibGDX wiki says polling might produce missed events. http://code.google.com/p/libgdx/wiki/InputPolling

quoting libgdx:

Caution: If you rely on polling, you might miss events, e.g. a fast paced key down/key up. If you need to make sure a specific sequence of input action was completed, use event handling instead.

I don't think you'll miss an event, only if the guy presses and releases a key in less then 1000/fps milliseconds (I think that's what the caution is about).  If you're running at 60FPS, I think it's physically impossible to a human to press and release a key faster than that.

And, from my own experience (I'm writing a libgdx game right now), I've never experienced a key polling miss.

[Hsaka]

It might also be a logic error. Maybe there are certain conditions that are checked before a jump is allowed, which need to be fixed.

I believe the only condition I check is if the player is on the ground before attempting to jump. I'll see.

And, from my own experience (I'm writing a libgdx game right now), I've never experienced a key polling miss.

Thanks, I'll try this approach as well.

[kappa]

Events are best used for stuff like text input where you don't want to miss anything, however for real time input (e.g. jumping) polling should be fine.

I'm guessing though that the reason for the delay in input is a sudden drop in frames giving a large delta time value (causing the sprite to move forward faster and hence delay the jump). One solution is to cap the delta time value to something like 20-50ms to avoid these jump delays have too much of an effect on gameplay.

btw noticed that in your appletloader html code you use the al_bgcolor and al_fgcolor parameters, these do not work with the AppletLoader anymore and you should instead use the boxbgcolor and boxfgcolor parameters. You'll probably want the following as it'll match your logo

1   2

<param name="boxbgcolor" value="#000000"> <param name="boxfgcolor" value="#ffffff">

[Hsaka]

Events are best used for stuff like text input where you don't want to miss anything but can afford a little input lag, however for real time jumping polling should be used.

btw noticed that in your appletloader html code you use the al_bgcolor and al_fgcolor parameters, these do not work with the AppletLoader anymore and you should instead use the boxbgcolor and boxfgcolor parameters.

Ohh I see, I'll definitely switch to polling then. Thanks, I didn't know those params had changed. I'll push a new update tonight.

Games published by our own members! Check 'em out!

[Mads]

If you're polling, you should jump is the key is down as well. It's frustrating if you click just an inch too early.

Edit: I got to level six. The input lag and the problem above makes it really frustrating.

[gouessej]

Hi

It doesn't work. I get the following error message:
"An error has occurred while loading the applet. Please contact the support to resolve this issue. This occurred while 'switching applet'".

I use Firefox 14 under Mageia Linux 2, OpenJDK 1.7 update 3, Icedtea-web 1.2, ATI Radeon X1950 Pro (Gallium 0.4 driver). Minecraft demo shows me a similar message, I assume it has something to do with this bug (from Icedtea-web or LWJGL) preventing LWJGL applets from working with Icedtea-web. Xerxes uses a more recent version of Icedtea-web, he wrote that it doesn't reproduce this problem with the provided examples on the official website of LWJGL.

[Mads]

@gouessej
If this was a commercial application, I wonder if looking into this would even be worth it. I mean, how big of a userbase are we losing? Why don't you update to the same version of Iced-Tea as Xerxes?

[jonjava]

Level9 atm. Will continue when i get home.

[Hsaka]

I'm guessing though that the reason for the delay in input is a sudden drop in frames giving a large delta time value (causing the sprite to move forward faster and hence delay the jump). One solution is to cap the delta time value to something like 20-50ms to avoid these jump delays have too much of an effect on gameplay.

How do I cap the delta time?

Thanks for the help and trying it out guys. I'll post an update asap.

[kappa]

How do I cap the delta time?

Unfortunately I don't know enough about LibGDX to answer that, so hopefully some of the other members here will be able to answer that but basically the time value you use to move your sprites every frame should be capped.

[Rorkien]

Hmm, i have no input lag at all

But not being able to queue jumps makes me platinum mad 

[Riven]

Please note that the input lag is equal for both the keyboard and the mouse.

[Hsaka]

But not being able to queue jumps makes me platinum mad 

Not sure what you mean by 'queue jumps'. Please clarify.

[Rorkien]

But not being able to queue jumps makes me platinum mad  

Not sure what you mean by 'queue jumps'. Please clarify.

If you press spacebar while still jumping, you will jump again right after landing

EDIT: Not bunnyjumping, which while spacebar is pressed, you will keep jumping

[Hsaka]

Ah I understand. Thanks, I'll think about adding that in and see if it adds to the game.

Please note that the input lag is equal for both the keyboard and the mouse.

Hopefully, switching to polling will fix the lag. If not, I'll have to investigate the delta time cap.

[sproingie]

For maximum polish, you'll probably only want to process jumps that were queued within X amount of time before hitting the ground, where X is some fractional-second value that's smaller than the length of an entire jump.  Otherwise it's annoying if you accidentally bounce the button and queue jumps you didn't want to.

[Hsaka]

For maximum polish, you'll probably only want to process jumps that were queued within X amount of time before hitting the ground, where X is some fractional-second value that's smaller than the length of an entire jump.  Otherwise it's annoying if you accidentally bounce the button and queue jumps you didn't want to.

Makes alot of sense. I'll prototype this later tonight.

[Riven]

Before you start implementing that 'convenient' feature, think about how that takes all skill out of the equation. The entire point of this game is to have lightning speed reflexes, and by doing 'action queueing' they don't matter as much, only the timing of the first jump would be important.

[sproingie]

That's why you don't let people queue jumps at any time, just a small fraction before they hit the ground.  It's basically adding a little bit of tolerance to the mix, and it's pretty much a requirement to compensate for any input lag.  Obviously removing input lag is better, but even then it still provides a smooth experience without taking away too much difficulty.

[Hsaka]

Before you start implementing that 'convenient' feature, think about how that takes all skill out of the equation. The entire point of this game is to have lightning speed reflexes, and by doing 'action queueing' they don't matter as much, only the timing of the first jump would be important.

That's why you don't let people queue jumps at any time, just a small fraction before they hit the ground.  It's basically adding a little bit of tolerance to the mix, and it's pretty much a requirement to compensate for any input lag.  Obviously removing input lag is better, but even then it still provides a smooth experience without taking away too much difficulty.

The main reason I'd look at doing something like this would be for an 'easy mode', because people tend to curse alot while playing this game 

[Rorkien]

It is not a easy mode, just a human factor consideration. We queue actions everytime on our brain, even when walking.

It is hard to find the exact tick when you are able to jump again. It is just asking someone to have a near 0ms reaction time.
Of course the levels can be beaten without it, but if you add it, you can create even harder levels, which would need near perfect timing

[Zuka]

That is where your timing and skills come in.

[jonjava]

Never mind I got to level 8.

But Hsaka, I'm also 100% sure Level 8 round 2 is impossible to beat. The second leap has hidden boxes or something - it's NOTHING like the first leap even though the boxes are exactly the same.

Ie:

[Zuka]

Nope it's possible. They are not equal hence the tip "Watch your head"