Think River City Ransom on the NES - two axes of movement, and jumping, for 3D movement, using 2D pixel art. What are best-practice suggestions for implementing such an engine in Godot?
To begin, I need an extension of the sprite node that takes X, Y, Z coordinates and draws the sprite at (X, Y+Z)) when rendering, as well as a collision node that can take X, Y, and Z coordinates.
You can do that all in 3D and just use 3D Sprites and an orthographic camera (it would essentially be 3D, and all the Nodes exist to do that now). I mean, you could also do it in 2D like they did back in the day, depends on the look you are going for.
@cybereality said: You can do that all in 3D and just use 3D Sprites and an orthographic camera (it would essentially be 3D, and all the Nodes exist to do that now). I mean, you could also do it in 2D like they did back in the day, depends on the look you are going for.
I'm going for a very old-school look. NES, or SNES. I'd prefer to use a few layers of 8x8 pixel block grids and sprites - but if I can still have those in the 3D engine, that's fine.
You can in 3D, but you probably want 2D for a pixel perfect look (like NES, etc.).
Sorry to revive this after so very , very long, but I don't recall there being a rule against necroposting and it seems like a shame to throw away a perfectly good discussion.
I've been looking deeper into making a 2.5D game. The commentary I've heard often suggests that's it's better to use Godot's 3D systems with billboarded 2D sprites. Solutions like this: https://www.gdquest.com/tutorial/godot/3d/2.5d-tips/
Objections to using the 2D engine include lack of support from the physics engine. Even if you could design a typical solution, like making heightmaps to extrude your 2D shapes into the Z axis, it isn't obvious how these would be integrated into Godot's existing physics engine. You could move objects, ask the physics engine what 2D geometry intersects , then check the heightmaps yourself and pull the objects apart if necessary, but at this point, but you're rewriting half the physics engine, which isn't why we use Godot.
However, it seems to me that if you work with pixel art in 3D, you'll end up having to design a bunch of custom 3D rendering stuff to make sure your 2D art is snapping to the actual pixels of your viewport, not distorted by whatever geometry is used to represent it, and rendered at the correct depth independent of the geometry used to represent it.
Does anyone have any insights into how to solve these problems?
What would it take to render pixel art to a 2D viewport, have 3D physics engine running in a separate environment (not drawn) and have the two communicate as necessary, what would that look entail?
@Lake said: Sorry to revive this after so very , very long, but I don't recall there being a rule against necroposting and it seems like a shame to throw away a perfectly good discussion.
That's because there isn't one. ;)
Wow, I even got a badge. The internet is a strange and mysterious place.
@Lake said: Does anyone have any insights into how to solve these problems?
I don't have any insight or experience with this directly, but I know that Unity struggled with this issue a lot for 2D games before they started supporting 2D officially. There might be discussions and solutions about 2D pixel art in 3D for Unity that may be usable for Godot, since the issue is very similar.
What would it take to render pixel art to a 2D viewport, have 3D physics engine running in a separate environment (not drawn) and have the two communicate as necessary, what would that look entail?
Theoretically, you'd just need a way to tell the 2D pixel art where to draw itself, what scale to draw at, and what Z-index to use, so it should be doable. I have no idea how difficult of a path this would be though, nor if the effort would be worth it. I imagine it could be difficult to manage the communications between 2D and 3D in a way that doesn't make the code confusing or difficult to manage.
In my opinion godot should have access to z axis in 2d world anyway, even if people dont use it, also it should be x, y and z or x and y by choice ( so you disable z), so Vector2.5D oor something similar would be great addition if you dont want to break backwards compatibility. Currently you can only do flat 2d or pure 3d, thats quite limiting, there are tons of cases where you would need z sort and axis but also jumps in y axis , unless its a mario clone or rpgmaker clone. Also new type of collission shapes with z axis depth, or add z depth to existing collission shapes. Im baffled that people arent requesting this more often here. From what i gathered till now its either flat 2d with x and y only or broken 3d with slopes bugs at the moment, they keep adding stuff but basic 2d funcionality from mid 90s games still isnt there yet .
Well, technically a request of this nature would be on the Github instead. A proposal's worth thinking about, but on the other hand, I imagine it would take quite some time to actually get approval and do the work. Like, years? Version 4.0 has them pretty busy. The other thing is that, as I see the culture of the GitHub, you'd need to have a very concrete and well articulated proposal that describes the problems your use case would encounter and how you propose the engine handles them.
Personally, I love Godot, so I've been working on my own workaround with my own very basic 3D physics object with a child that draws a 2D sprite. Already, in terms of the engine, I wonder how you would account for the different kinds of projection a 2.5D game would want to map between 2D and 3D space.
Anyway, if you have any thoughts on the subject, I'd love to hear them.
Looking online, I found someone else's 2.5D sample project too: https://github.com/godotengine/godot-demo-projects/tree/master/misc/2.5d
