Getting started with 2D game development

General Discussion
1

Hello, I’m new around here. In fact, this is my first JME project ever. I’m a little lost and would like to see if anyone could help me with this.

So, the project I’m aiming to do is a 2D game with 3D backgrounds. Right now, I’m concerned about the 2D part; more specifically:

  • Build a sprite sheet system - Load an sprite sheet image as texture, render it in an object (like a Quad shape), run and loop sprite animation, etc.

  • Manage sprite rendering priority / order.

  • Sprite collision check.

Google didn’t help me much in my searches, the few stuff I was able to find related to the topics is either really outdated or extremely confusing.

With that said, I would be very grateful if anyone could indicate to me anything that helps me to build the 2D game elements. It could be a Youtube tutorial, others threads releated in this hub, guides, etc.

In short, I’m looking for anything that could help me getting started with 2D game development in JME3. Can you help me?

3 Likes
2

Well I didn’t made any 2D with JME, but i think you can use gui elements in jme to make simple 2D games but they are far from what you expect as a 2D GameEngine or framework, I suggest you take a look at libgdx framework, it has good 3D api too. you have lots of tools with docs to make 2d game with libgdx. You can have Bullet, Freetype, Box2d, and … with libgdx all easy to setup.

2 Likes
3

JME makes sense in this case. A purely 2D framework would require that you fake the 3D backgrounds.

Others have done this… but note that you could be pretty far along in your game development before that comes up. It’s more of a performance improvement for when you have thousands of sprites going.

Put the sprites in the guiNode and just use the ‘z’ value of their coordinates to sort them.

For anything more advanced than radius checks or axis-aligned box checks, you will probably want to integrate with something like dyn4j. Others have done it, I don’t remember if they’ve posted the code… it’s not particularly tricky but there would be a learning curve. Especially if you’ve never messed with a physics engine before.

Is this like a platform game or a bullet storm game or something else?

2 Likes
4

Yeah, learning how to use GUI Nodes would be an good starting point.

I’ll keep that in mind, though I’m inclined to try a bit more on this engine, I didn’t knew that framework and very likely I still wouldn’t if it weren’t for your suggestion. So, thanks for the recomendation.

1 Like
5

I’m assuming you’re telling me to use only basic shapes first and then, once the core features are ready, implement the sprite rendering, correct?

Well, my intention is to use radius checks on everything, so it shouldn’t be a problem.

Bingo, the game I want to make is something very similar to the “TouHou Project” game series. In other words, it’s a vertical shoot’em up with a dense amount of bullets on screen.

You might be wondering: “Why don’t you just use Danmakufu for that?”
Well, there’s two reasons:

  1. There are several aspects of that engine that bothers me a lot, which makes me look for other engines.
  2. This is less of an “I want to make a TouHou fangame”, and more like an “I want to test out my programming skills to see if I can implement the core features of a shmup on my own, without relying on engines designed for this game genre, and finally, prove to myself that all those years I spent studying programming were not in vain”.

(NOTE: The second reason also explain why I choosed JME of all things.)

Anyways, thanks for your advices. I’m gonna start by learning how to use the GUI Nodes.

6

Not really. I’m saying you can go a long with with Quads, textures, and swapping texture coordinates around. Much of it can even be automated with only a little code. Is it as efficient as batched sprites from one giant sprite sheet? No. Is it probably efficient enough to get started? Definitely. Probably 2,000-3,000 objects before you even care much.

For these sorts of games, the “feel” seems really important. I recommend iterating a lot on that before worrying about scaling up to 10,000 moving objects on screen at once. Make it feel “fun” and then iterate from there.

2 Likes
7

The 2D topic with JME is very interesting.

Using the guiNode node makes 2D games more difficult to maintain, as that node uses pixels and is UI specific, so I don’t recommend making a game under that node.

It is recommended to use rootNode that uses the world scales, as running a game at a different resolution will not warp the models.

I highly recommend these 2 libraries that can help you with your 2D game.

  1. jMe3GL2D [compatible with the latest version of dyn4j]
  2. Galago2D [not compatible with the latest version of dyn4j]

Both libraries work in a similar way, with some minimal features that differentiate them, it is worth mentioning that they incorporate the Dyn4j physics engine.

You can take a look at this post, where I developed a game that is in the godot documentation.
[Link]
Dodge the Creeps!

1 Like
8

Thanks buddy. Those were some very valuable information. The libraries and that game example are exactly what I was looking for.

9 
Node mySpace = new Node();
mySpace.setLocalScale(whatever you want)
guiNode.attachChild(mySpace);

If you use the root node then you will have to mess with the geometry comparator or sometimes z sorting will not happen as expected with the normal z = layer style sorting that is automatic in the GUI node.

It can definitely work but for starting out I think the guiNode is 1000x easier with basically no down sides once you create your own root node underneath it. Especially if the 3D background will never interact with the 2D foreground.

…though if you eventually want post-processing effects then the root node can be better for that. But from the game logic’s perspective, it’s just a matter of switching where the custom root node mySpace goes. (And then dealing with the other 3D space setup that has to happen… and potentially a separate viewport and so on.)

2 Likes