Godot version:
4.x.x
Greetings.
For the sake of extended 2D capabilities and to make the life of gamedevs easier, please include a 2.5D editor in Godot 4.x engine for it to have the same experience as Cocos. I invite you to read the english part in this :
https://github.com/cocos-creator/creator-docs/pull/744/files/103595ca2ad38db38a3883d0628d6befbe491c32
Can you explain what this will allow you to do vs the current 3D view set to Front, using Shift+MMB to pan, and/or using Orthogonal view mode? And why the 3D view is unsuitable?
Can you explain what this will allow you to do vs the current 3D view set to Front, using Shift+MMB to pan, and/or using Orthogonal view mode? And why the 3D view is unsuitable?
It would allow to still make 2d games with nothing more than sprites and textures, except that movable objects will have an {x, y, z} coordinate system and collision boxes will feature a z-height property (in pixels).
That way, we'll be able to have object jump and elevation simulated in a top-down/isometric 2d game world...
You can already use sprites and textures in 3D, with nodes such as Sprite3D.
So you're saying I can build my 2D map and objects with Sprite3D ? Will my tilemaps appear in the 3D viewport ?? I mean, can I switch between them while building my game ?
Because, I don't want to use any 3D models...
Just use a GridMap
with flat planes and using the tile textures.
I don't want to use any 3D mesh, flat or not...
It says I need a 3D mesh to use GridMap...
About that 2.5D editor viewport, an idea of the character movement is as follows :
-> Moving an object upper on the y or z axis moves the characters one pixel up. So for instance,
if myobject.pos = (x:0 , y:-1 , z:-1)
, then the object's position from the origin is about 2 pixels up...
Here is an example of how it'd look like when you build your map with tiles :
https://www.youtube.com/watch?v=ERflSDM5lF8
Here is an example of how it'd look like when you build your map with tiles :
https://www.youtube.com/watch?v=ERflSDM5lF8
can't this be done already with a tilemap? just set the cell_size
to achieve an isometric style. it'll look just like that video. heavily dependent on the art you use though. the art/sprites have to be rendered at the right camera angle
can't this be done already with a tilemap? just set the
cell_size
to achieve an isometric style. it'll look just like that video. heavily dependent on the art you use though. the art/sprites have to be rendered at the right camera angle
Thanks. But it doesn't solve everything, because there are heightmaps in the video. Besides, I'm not talking about building an isometric game but rather simulate height elevation in a pure 2D game...
Like in this example :
I was thinking about this recently.
Currently it IS quite hard to make 2d games with proper depth ala CrossCode, Mario and Luigi or Ultima 7, 8 and online. You'd have to do a lot of the editor "plumbing" yourself most likely sneakily doing a lot with 3d collision and rigging up some system to display the results in a 2d scene. (Or just render the whole thing in 3d and use tricks to make it look more 2D)
I'm very interested in what the core devs have to say about this. Obviously research needs to be done on how best to implement it.
@ElfEars oh yeah, that's def possible already i think. regarding that gif, they are just doing clever collisions and the depth/height simulation is from the art. that can be done already. it really just depends on the art used.
the thing is, i don't know how a 2.5d editor would get "implemented", as changing the cell_size in the tilemap node or using specific art already creates the 2.5d effect? i could be wrong however, or maybe i'm just not understanding the suggestion correctly, if so, i apologize
There is no 3D necessary to create the effects in @Steph155's image. The staircase can just be left as "flat" terrain, and the cliffs can just be impassible from one side, perhaps offsetting your character on the Y axis when entering to simulate an elevation change.
To create the effect of jumping while keeping track of the character's ground position, you can just offset the sprite from the character's origin, on the Y axis.
@aaronfranke
I just checked Cocos Creator's engine(v2.1) and their 2.5D engine behave like a 3D one. Except that, you don't have to use a different node to view your sprite(2D or 2.5D, there's no 3D mode but you can use Vector3 transformations on sprites)...
Hence, we can conclude that every 2d node virtually possesses a third coordinate as well.
The third coordinate appears when you click on "2.5D" in the top right side of the properties panel.
By default the z-axis is orthogonal to the camera's view. So changing the z-value of a sprite makes it bigger or smaller(depth simulation)...
@reduz
Greetings. I was thinking again. And I thought about something different... It might still not be perfect though.
It's about rewriting/extending the entire 2D engine to suits 2.5D games in Godot 4 since version 3.1 is already feature freeze. Yeah, like I said before, this would require including something like a Position3 class for sprites position(possibly a custom class with three variables( x, y, and C, not forcefully z. Also, the "relative height"(C) would be linked to the y coordinate. It'd have an "y + k" equation(C = y + k) where k is the height offset of an object in the space in pixels. I dont't know.
Regarding topdown tilemaps with walkable area above at a given height(ground ontop of them). The best example I could find to handle the story is a 2D terrain/heightmap collision box editor.
I'm not really an expert coder, so taking care of that alone will cost me years probably...
Here's a video with a perfect demo/example of this must-have feature for the 2.5D viewport...
www.youtube.com/watch?v=Un9urBgX91c&t=520s
Please, sir, please mister Juan Linietsky, if you read this, plan something to make our gamedev lives easier about this. The physics in games like CrossCode should be demystified for all and possibly easier to implement thanks to the hardwork you put in the game engine's features...
@Steph155 Based on how you describe it, I would imagine a "Transform2.5D" would have Vector3 position, and 3 Basis vectors, but all Basis vectors lie on a single plane. This way the Z axis could be changed to mean along Y, along X, between Y and X, or zero (doesn't change position) and optionally grow in size. Bonus: you could even use this behavior to swap around axes and have a 2.5D game where you can toggle between side view and top-down view.
This would basically be the same as using Transform (3D) for math and then casting positions to 2D. I can definitely imagine how this could be done manually with built-in nodes and structures.
This would be a great idea for an external module or something.
Based on how you describe it, I would imagine a "Transform2.5D" would have Vector3 position, and 3 Basis vectors, but all Basis vectors lie on a single plane. This way the Z axis could be changed to mean along Y, along X, between Y and X, or zero (doesn't change position) and optionally grow in size. Bonus: you could even use this behavior to swap around axes and have a 2.5D game where you can toggle between side view and top-down view.
This would basically be the same as using Transform (3D) for math and then casting positions to 2D. I can definitely imagine how this could be done manually with built-in nodes and structures.
This would be a great idea for an external module or something.
@aaronfranke Okay, so what's left to do now ?
If things really are clear in your mind about how to do it with current built-in nodes, then would you mind making a 2.5D topdown prototype project including :
* A tilemap with platforms of different heights;
* A sprite character capable of jumping;
* Carefully commented scripts well organized;
* A short documentation explaining with clarity how to handle the collisions with the characters and the sorting/draw order of sprites... ??
Here are some video links for an ideal result :
@aaronfranke , @reduz
Another conceptual idea is to make Godot's 2.5D collider have a size with 3 coordinates : x, y and z with z defining the height in pixels. This means that having a (x:1, y:1, z:0) results in a flat topdown 2d plane. A positive z values defines walls around the flat ground. Sprites can then be attached to corresponding nodes to help build a 2.5D game world...
New demo videos :
https://www.youtube.com/watch?v=IwJ_ofKG9_Y
@Steph155 I spent the past few days creating this 2.5D prototype: 2.5DTest.zip
Controls: WASD to move, Space to jump, R to reset, and UIOPKL to change view modes.
The project was made with Godot 3.1 beta 8 with Mono. It uses new structs called Basis25D and Transform25D to calculate 2D positions from 3D ones. For getting a 3D position, I used KinematicBody and StaticBody (3D), but these only exist for math - the camera is 2D and all sprites are 2D.
There is a script called Node25D which uses the above to position a Node2D. Node25D can only be attached to Node2D nodes, and the first child must be a Spatial.
I implemented top down, front side, 45 degree, isometric, and two oblique modes. To implement a different view angle, all you need to do is create a new Basis25D, use it in all your Node25D transforms, and of course create textures to display that object in 2D.
I am thinking of polishing this up a bit and submitting it to the Godot demo projects repo later.
@aaronfranke
It's probably impossible to remake this in godot 2.1.5 given the fact that it doesn't have C# support for more coding power regarding customization... Well maybe with C++ then... 2.1 is outdated though...
I have to say that I'm impressed by how you managed to do it...
But the character's movement needs a tweak, he's weirdly slow...
Anyway, thanks for your help and efforts. It really is something...
Don't forget to handle the sorting of sprites when polishing it...
@Steph155 Setting the Z-index will be a challenge. I suppose it should be based off of the vertical axis value, but in Godot it must be on a fixed integer range between -4096 and 4096, so it will probably require looking at each and every item in a list and sorting them, but there would be a limit of 8000 items.
@aaronfranke
What about the built-in YSort node ?
YSort won't work because you'd need to sort by Y in 3D. Otherwise, you'd be behind a platform when you're on the closer part of it.
@aaronfranke Could you check the following link and see if it helps make it simpler ?
Source links are dead though...
@aaronfranke It could create a navigation / waypoint / navmesh where the enemy follows the player in 3d csharp.
I'm closing this issue because I have merged the 2.5D demo projects. These allow you to create games like the one featured in the above GIF:
It uses 3D nodes for math and displays everything in 2D, just as @ElfEars suggested here. The system is very flexible, allowing you to use any kind of 3D node for math, any kind of 2D node for displaying, and there are even multiple modes for converting 3D positions into 2D ones. Included are 45 degrees, isometric, top down, front side, and two oblique modes, and you can also create your own if you understand matrices and transforms by simply defining three Vector2 values.
Thanks to the magic of Godot editor plugins, this is made seamless in the editor:
Most helpful comment
Thanks. But it doesn't solve everything, because there are heightmaps in the video. Besides, I'm not talking about building an isometric game but rather simulate height elevation in a pure 2D game...
Like in this example :