I have a plan to port my 2D videogame in 3D using JME3 with minimum changes (like Nintendo ported “Link’s awakening” from GBA/SNES to Nintendo Switch).
The original 2D game was created using Java. The camera in the game has no rotation and levitates over the game world like in classic action-adventures (for example: Legend of Zelda: Link’s awakening). See the example screenshot from “Legend of Zelda” bellow.
In the original videogame I used a 2D coordinate system where Y-axis is vertical oriented (it points on the top of the display). If I will try to make the same world in 3D using JME-Terrain editor I will have a trouble. The game world in the terrain editor lays on X-Z plane and the Y-axis is perpendicular to the monitor-plane. The Y-axis from the original videogame must transform into Z-axis in the 3D videogame on JME3 and the original Z-coordinate (it was always 0 in the original videogame) must be now Y.
I think - what is the best way to make minimum job with the coordinates by porting my videogame in 3D using JME3?
I can manually rewrite all the code and game resources to change the original Y-coordinate in Z-coordinate and Z-coordinate in Y-coordinate. I think it needs too many tests.
I can make the game world normally in JME-terrain editor and change the coordinates of the terrain and all the loaded meshes direct after the game world was loaded by AssetsManager from the code. But I don’t know how to do that. 3D models from the Blender can be rotated direct before exporting in .OBJ or .GLTF for JME.
Advise me please - how to solve this problem. What would you make to solve this axis conflict by porting from 2D in 3D with minimum work?
From personal experience, if you fight JME on this then you will be constantly sorting out bugs in your code only to discover it is once again another case of “y-up versus z-up”.
The original version of Mythruna was z-up. So much about JME is y-up that everything becomes a little bit harder. I tracked down many bugs that were related to this. Consequently, the new Mythruna just gave up and does everything y-up.
Most of my problems were because my game is actually 3D, though… for a mostly 2D game it’s usually pretty easy to do x/y as the ‘space’ and just ignore z. (You may also have to rotate all of your objects because quaternions think ‘z forward’ and you will fight that all the time.)
If you could just rotate the terrain into x/y then you’d probable be fine doing everything in x/y… but I suspect there are optimizations in the terrain mesh and shaders that would be unhappy with this.
My experience is that I just could never convince my brain that Y goes up and Z goes back and I was always making mistakes because of it.
Specially since my editor has a 2D top-down view and there is more natural to work on the XY plane.
In my game the jME’s presentation layer and the scripted logic layer are well divided so my solution was to make two simple transformation functions toJme and toGame then I use this to change coordinate systems in the layers’ boundaries (plus another pair for rotations).
When I’m working on the game logic, like enemy AI and so on, it’s one less thing to worry about and I rely on the part of the code that syncs game objects to their 3D scene geometries to fix the axis.
Then I don’t really have a lot of code that works on the 3d scene directly mostly things like frag shaders which are naturally Y-up.
This has worked very well so far and I make fewer mistakes since, perhaps you can consider a similar strategy.
Edit: My game is a FPS, but for a side/vertical scroller or top-down view I would stick to the default axes since XY is the main movement plane in those.
