Elements carefully controlled on top of background (clouds, event animations);
Static actors which can change appearance when damaged (buildings);
What I am trying to do:
I am implementing a 2D level copying the context mentioned earlier. I don’t need tiles, grids, since the levels are pre drawn without them, or procedurally generated. The levels contain objects at different Z depths (bridge over water) which the player can go under / over. The levels contain custom collision bodies to serve as invisible walls. The objects placed in the level will be AActor based to precisely control visual changes and logic where needed.
I’m trying to find the correct workflow to implement these levels. I’m used to 3D design (import a mesh, make its collision, put a material on it and place it in a level etc.) which might just be the same for 2D. It just feels awkward to have a ton of 2D plane meshes?
What is your favorite method?
What I tried:
Paper2D. Gave me graphical glitches when loading a large background image within a tileset. Limited to usage with tiles / grids. Collision limited to single closed body.
Billboards. Locked to all camera axis causing trouble there.
Plane meshes with custom collision for every 2D object / background etc.
As far as favorite methods go, you likey aren’t getting answers because no one “likes” to use Unreal to make 2D stuff.
Using a 2D engine gives way better results, has less legal issues with licensing etc. So people who do it professionally wouldnt get caught dead
using unreal for it if they can at all help it.
Those who do use the engine (namely a couple of winning gamejam entires pre-covid come to mind) utilize a combination of modes/featurs however they saw fit to get their end content going.
Again, the engine is horrible at nearly everything by now, but it has always been really bad at 2d stuff.
Even a simple game like MarioBros(the first one in 8 bit) is technically impossible when done with the engine particularly if you want to hit the same memory footprint.
If you really cant look for a better engine, then use the widget system as much as possible rather than mesh planes.
The widget system allows you (at least once it did) to offset the objects with layer sorting options, which the engine is otherwise incapable of doing.
To achieve the same thing with planes you would need to physically offset them on the depth axis, which is nuts.
Backdrops for finite levels have to be done in tiling sets. Generally speaking, they handle well but at times they will sheer or glitch out while loading.
Mostly because everything you load in unreal has the lowest MIP first, and loads the full texture after. This causes scrollers to have issues when new backdrop slides load in…
I noticed I tried Unity but I’ve spent years in Unreal c++ already. The Unity editor viewport alone felt awful. Probably because I’m not used to it but compared to how quickly I can set up stuff in UE it’s not an option.
Which are you thinking of here? Is this 2D specific or Unreal specific?
I agree. Instead of plugging in what you need this engine throws everything at you of which 90% goes unused in smaller projects. I don’t want to remove the possibility that their might be 3D elements early on though. I might have scenes in which 3D models rendered “pixely” or with certain shaders to look flat are the better / faster option to produce and render on a 2D background. Either this is 2.5D pre rendered sprites (think early mario kart, donkey kong) or just full 3D.
The gameplay I have so far all plays out on a 2D virtual “plane”. Even if this plane rotates relativeley to the world all relevant gameplay elements play on its X and Y axis, basically attached to its transform. currently the Z axis is indeed used for depth, similar to the Z-Index of widgets. It’s both nuts. In Widgets I don’t use the Z-Index at all because I see it as a bad practice. I use the widget hierarchy to control depth automatically and only set the Z-Index on the first “master” widget I spawn.
I am actually very surprised to hear you say widgets because my experience with their performance has been awful. Most importantly this:
If you’d use many widgets at once in a game like metal slug, on the bullets for example, it will slow down to a crawl on pointer events and inefficient widget destruction. I can reproduce this by opening and closing an already optimized main menu rapidly (recreating the widget without garbage collecting the other first).
Ahhh… a shame UE doesn’t just work that well…
The tile set for the backdrop might still be an option. I tried it as a tileset and as a sprite (single big image) and funnily it rendered only properly as a sprite.
I just realized maybe there could be some use in the landscape editor, no idea. if I could snap landscape Z to a constant interval and texture the landscape. It’s just one idea of many. That could only be the backdrop.
One thing that could work is enabling VT and setting up the tiling as a single large image handled by the virtual texturing.
I have seen some examples of people rendering stuff out of a single 16k^2 image with it, and it seemed like the loading time(s) were handled entierly differently/appeared not to be mip-ping down…
That sounds extremely useful, haven’t used that. Going to test it out asap for the backdrop. For now I use a “battlemap” aka a dungeons and dragons map just to test backgrounds on a somewhat high speed top down game and I expect the backdrops to grow quite big. Some can be seamless and repeating, lucky me.
I tried Unity but I’ve spent years in Unreal c++ already. The Unity editor viewport alone felt awful. Probably because I’m not used to it but compared to how quickly I can set up stuff in UE it’s not an option.