[h1]Monster Run[/h1]
Monster Run is a simple platform jumping game, developed in just under 10 hours including art and music. The mechanics are incredibly simple, all you need is perfect timing to make the monster jump by hitting the SPACEBAR key. The game is made in Java 8 and requires a GPU with OpenGL 3.2 or more with core profile.
Who said that Monsters necessarily need to be bad huh?
Windows | Mac OS X | Linux | GitHub | LD Entry Page
Game runs a little choppy on my machine.
MacBook Pro Retina 2012
2.6 GHz Intel Core i7
16 GB RAM
NVIDIA GeForce GT 650M 1024MB
Constructive Criticism:
Jumping feels awkward, almost a bit too slow and too rigid looking.
Collision bounds are slightly too large, I can land on the little patch of air before the grass block.
Just curious, why use OpenGL, this game could be written much more simply in java 2D
I’ll flip that question back on you; why write it in Java2D? I think SHC is using his own game library/framework which he would be very familiar with. Really in the end it doesn’t matter what was used to create the game, what matters is the programmers knowledge of the technology they want to use. Not trying to be mean, that’s just how I see it!
SHC, you should lock the window size. I resized the window and the now the game is all messed up!
Ran well here (OS X 10.10). Kudos for being able to put the whole thing together so quickly.
Since this was developed in a short amount of time I’m guessing you may not be looking for feedback, but I’ll mention that it felt like it could be faster overall (that is, a higher ‘monster speed’ would make it more challenging and engaging). Also, I’m wondering if the (presumably) random level generation can create situations that can’t successfully be navigated? Or maybe they can and I just failed to do so 
Good point, I just think that OpenGL is overkill for most 2D applications tbh.
I just had the vertical velocity on always (gravity) and reversed it when jumping, so it appeared like on the sides of a triangles, flat jumping. Should have tried Arc’d jumping this time. Regarding the collision bounds, yes, I simply used rectangles, while I could have used polygons. Even better I could have scaled the polygons down, forgot that. Will do that next time.
That’s just because I was refactoring my graphics engine and the progress was left in the middle of the process due to LD. I should have used a previous stable build of my engine, but used this since there were a lot of features I’d like to have (since I removed some things and replaced them with new implementations). These however ran fine on my system, but not on yours, will have to investigate that.
Maybe the reason was that I allocate a large bytebuffer that can hold 1024 * 1024 * 16 bytes in my batcher. I know that it is a lot, will be soon modifying the system to use instanced rendering instead of batching all the data every frame. Or even I can stop unmapping and mapping them again and again when the data doesn’t change. Will look into that too, I learnt a lesson.
I just wanted to say that I’m more comfortable in my own engine than in Java2D. As you have stated, I don’t think OpenGL is overkill, it’s nothing wrong in using it to get hardware acceleration. Ever thought why Java2D based engines like GTGE and JGame had ports to JOGL/LWJGL while they are just 2D?
And more over, I wanted to try to create an engine that can do both 2D and 3D games, in a pretty similar way. I know the mechanisms differ a lot, but I’m more interested in building a tool that gives a high level way to create games easily. That is my primary inspiration that made me take computer science as my college course and learn programming in the first place.
Yeah I agree with you. I just set the camera projection to the window width and height in the initialization of the camera, but I never resized the camera. I used to configure the camera to keep the aspect ratio, but this time, I had to keep to do it in the time, where I had only 10 hours in 48 hours to focus on my game (due to college, and cultural party we’re having tomorrow, I’m doing a skit) with other things like eating, classes, etc., cutting the rest of the time. Will improve this once the judgement is over, and I’ll remember this next time.
Thanks a lot for giving me my valuable feedback on my game. I’m pretty sure I’m improving myself in this area of making games (aside from programming tools).
Nice work. It’s cool to see another JGO-er doing Ludum Dare!
The whole point of Ludum Dare is to create a complete game in 48 hours, and you succeeded at that. Like others have said, it would probably be more fun if it was a little faster (right now the player feels big and slow, smaller and faster feels more fun). But you’ve got a playable game with a beginning, middle, and end, so great job!
