Why 2D might deserve more attention than it is getting

General Feedback & Requests
1

Let me start by saying that I am a huge fan of Unreal Engine. Over the past few years, it has probably become my favourite engine of them all. I have tried looking for a game engine that suits my needs for a while. I tried using Gamemaker, Unity, Godot Engine, Cocos and probably a couple of others that I forgot about, and was never never quite satisfied with them because some important feature was either missing or broken. Needless to say, no game engine can be perfect, so that is to be expected, but Unreal Engine seemed to be the exception to that. Even after using it for an extended amount of time, there was very little that I would have liked to changed about it. However, there was one thing I couldn’t help but notice, which is the quite apparent lack of 2D support. I have seen a small number of suggestions regarding that matter, but rather than just complaining about it, I would like to bring up a few points about why the 2D part of Unreal Engine might deserve more attention than it is getting. I understand that I am just an individual with no knowledge of what Epic Games, as a company, is concerned with at the moment, so surely there is reasons for 2D not being as actively developed anymore, but here are just some points that might be worth considering.

1. The people using 2D are a silent majority
Most of the people who are interested in developing 2D-Applications in Unreal Engine are simply not as loud as those who will be using features like virtual reality or impressive graphical effects. Whenever there is an announcement about support for some “new” technology (say VR) there is a huge hype about it. Big companies, students, gamers or simply people interested in the newest trends make a huge fuss about it, write about it on their blogs and tell their friends about it. It is a nice attention-getter of course, but let’s face it: A lot of those will never even attempt to make a playable game using these features. They will have a look at them, be impressed and leave. New features are always welcome of course, but seeing how we now have a VR editor and fancy, complicated lights and reflections, I can not help but feel that those features, which frankly, the majority of indie developers have absolutely no use for, came at the cost of some more basic features, that would be used by a much wider audience. (After all, 2D has been stuck in experimental for what I believe has been 2 years now)
On the contrary, when a new 2D feature is released, there is very little talking about it, but you can bet that there will be a ton of people using it, and in fact it might be a must-have for a lot of them. To me this seems to be the classic dilemma of what the people (seemingly) want vs. what the people need. (Well, that and I guess it might simply be more entertaining for the UE-Staff to add those new features, rather than plain old 2D) You can give a homeless man an expensive, impressive-looking car that he doesn’t know how to drive, but he would be much better off with something to eat.

2. The fundamentals are there, and they are great!
While I was looking for an engine to use, I noticed that the majority of them do not feature a tile editor. Godot is extremely lacking when it comes to importing tilesets and Unity (Which mind you, pretentiously announces itself as a fully-fledged 2D engine) does not feature a built-in tile editor at all! Neither does it have support for 2D pathfinding (which I got to work in Unreal Engine rather easily once I got the hang of it, albeit with a bit of effort). I tried developing a small 2D game with what I had available in UE (I can share that, if someone is interested), and made much quicker progress than with Unity. The issue was that at some point, I hit a wall in development due to 2D collider and rendering shenanigans and it was simply impossible to continue after that without breaking the game. Nevertheless, up to that point, I felt UE performed better than Unity, seemingly without even trying, since the 2D-features were (and still are, sadly) experimental. I am no business expert, but after putting this much work into a project already, is it not a better idea to finish it fully, rather than leaving it in an almost-finished state that makes it pretty much unuseable in most applications that are meant to be published?

3. The lack of 2D support is one of the few things holding UE back
If there was decent 2D support, I personally would not see any reason not to use Unreal Engine for just about every game I develop. Sure, sometimes you want to be extremely memory/performance-efficient and build the game from scratch, without a big game-engine, but other than that, I think it would put UE ahead of all the other engines I tried. The biggest weakness of UE is, that it simply does not appeal to a lot of Indies, and the lack of 2D is the primary reason for that.

As much as I love Unreal Engine, as long as I can not use it for 2D-Applications, I am forced to resort to Unity which has a lot less, albeit reliable 2D-Functionality. The things bothering me most about the 2D side of UE are (in order of importance):

  • 2D Collision Detection: Being forced to use 3D Collision on sprites simply breaks games. Although I can only assume here, I don’t think it would take forever to fix, either.
  • 2D Rendering: I am commonly getting rendering artifacts that make the game look blurry or cause flickering. This is not caused by the postprocessing, I tested this with all of that turned off, so unless there’s some arcane wizardry to perform in the settings, this is caused by the engine core and can not easily be fixed by the end-user.
  • 2D Volumes: This is pretty self-explanatory. 2D Volumes can be used in a lot of places and using 3D volumes instead is just as bad as having to use 3D colliders.
  • Reduced Filesize: Although this is not strictly related to 2D, I would disagree that a game of pacman should be using up 50+ MB of space. Surely there have to be ways to reduce the filesize for games using exclusively 2D.

I would be very happy to see Unreal Engine catch up with other game engines in that regard. If it does not happen reasonably soon or at all, it would at least be a nice touch to let all those people, who are waiting and getting their hopes up, know that this is the case. Thanks for taking the time to read this.

2

– 2D Collision Detection: Not sure why you think it that way. Can you give a reasoning? I did not have problems with 3D collision yet and I kinda needed for my 3D maps that I will create.

– 2D Rendering: First of all, if you see your 2D images gettin blurry or jumping from normal to blur, it might be because your textures have “Never Stream” off. Turn that on in the properties and you won’t have that problem.

– 2D Volumes: Again, why? I never had problems with them either.

– Reduced Filesize: Thats something one can optimize it himself aswell.

Just my 2 cents. :slight_smile:

3

– Using 3D collision is fine for a platformer/fighter game (such as the one I can see you are working on), however, when it comes to top-down RPGs, it’s a different story entirely. It just adds an additional layer that is technically not there, but that you have to pay attention to. For instance: When the player is in front of a tree, the tree should be rendered behind him, but if the player is in behind the tree, the player needs to be rendered behind the tree. The easiest way to accomplish this is by changing the z coordinate of the player, but that will move the collision along with him, having the collision box “hover” slightly above the ground. (Or push it into the ground which the physics engine will block and therefore you will get no effect at all, and it might take you a while to find the bug) If the player should now interact with something for which you forgot to adjust the collision box, it’s possible that this object will simply slip “under” the player, although technically he is standing right ontop of it. Sounds simple enough to avoid, but when you have a bunch of factors modifying the z-coordinate at runtime, it gets extremely confusing and difficult to manage. This is made even worse by the fact that the 3D colliders will affect which z-coordinate the Player and Enemies have. For instance, the player might (with a map at z-layer 0) end up on 2 because of his capsule collision. An enemy with a smaller capsule might only end up at 1.5 . If you now want to render the enemy ontop of the player you have to add 1 to its z-coordinate. At that point however, you will have to consider the trees again, which should be above both the player and the enemy but only if they’re behind them. However, trees might have yet another default height due to their collider and so on. You can see where this is going: which is a huge, needless mess, since the z-coordinate is linked to a number of things that you do not want to affect at all. Another problem is that the player HAS to be hovering above the ground. This is because the tilemap never has a perfect 90° angle, so the player will occassionally get stuck when trying to move him as if he was on a flat surface. It has been a month or two since I last worked on this project, so I can not remember everything in detail and why it was so difficult to fix, but if you try it yourself you will probably see what I mean. I am not saying they should remove 3D collision for sprites, but having properly supported 2D-collision is a must-have. If only for performance reasons.

– The artifacts are very subtle, and I might not have noticed them myself if it was not for my friend (who is a graphics artist) who pointed them out to me. I simply noticed something was off. It is not as obvious as the images simply getting blurry. It is a slight blur when moving and an occassional missing line of pixels as well as other artifacts, and I was not able to get rid off them by changing any of the settings or modifying the tileset in any way.

– Same as 2D collision.

– It is something I tried optimizing, and you can not go below 40-50MB. The size is not coming from the assets, but the engine itself, and that is after applying all suggestions on that matter I found online, so unless I was to modify the source of UE, which I do not think I would be able to do, there is no way to reduce it any further.

4

You can check the game called Wasabi Horizon in Work in Progress tab of forums. They have a top down 2D game going on and they have massive progress, not to mention they have no problem on the collision system that you mention. You might be right about the fact that 2D could be more welcoming, but those guys prove that it is quite possible when you work on it.

It is also hard to give a proper answer against that graphical “bug” without any visual. It can be your mistake, or a bug on the Engine that needs to be reported, or maybe it’s easy to fix. I have been working heavily on 2D stuff and I never had such problems myself.

About the size, I feel 50 MB is quite good enough. I got the feeling that we are pass the point of games being 5 MBs. :stuck_out_tongue: Unreal is a big engine. Those engines you worked before that you mentioned as “feature lacking” are low on size, because… well… they lack feattures.

My 2 cents, yet again.

5

Actually, you will find that they appear to have run into the exact same problems, or at least similar ones, as this sounds a lot like it.

Also, keep in mind that this is still in the early stages. It is well possible that they will run into new issues as it progresses, although it is certainly worth keeping an eye on. The game I was working on made it quite far as well, before things started falling apart more and more because of nasty hacks related to 2D.

The graphic artifacts will become more apparent the more sprites you are using. For my game I was using 32x32 tiles, which is why it was noticeable. That being said, the tilesets are not of extremely high quality, so that might be playing into it, or perhaps I am just seeing things after I went through so much trial and error in order to get the graphics to render correctly, I just do not trust it to ever be perfect anymore. Then again, I have read from other people experiencing trouble with the 2D rendering as well. The easiest solution would simply be providing a default setup for 2D so it is clear whether it is caused by incorrect settings or is indeed a bug. Wasabi Horizon is using a very artsy style where you will not notice a few pixels being off, so that might be why it works for them.

50MB can still be quite relevant on mobile or when downloading on a slow connection. At most 30MB in an uncompressed state would be nice. I disagree that the other engines are able to output smaller executables due to a lack of features. A tile editor will increase the output size by exactly 0kb, as it is an editor feature, rather than included in the game itself. UE is a big engine, but if features are not being used, they do not need to be included in the executable. I can only imagine how much bean counting that will be just for a little bit of improvement, especially for an engine of this size. That is why I put it at the very end of the list. Once everything else about 2D is running perfectly and only then, I think it would make sense to try and improve that.

6

Hi BrightC,

Have you tried the “Condition Tile Sheet Texture” option in the context menu for your tile set? It adds bleed padding around each tile to avoid texture sampling artifacts that can sample fractionally outside of the boundary of a tile and cause artifacts like shimmering gaps or color bleed.

For z-shifting causing issues with collision, I’d recommend decoupling the component doing the collision from the component being rendered. Keep the collision component (either a sprite set to hidden or a box/sphere/capsule) as the root component (or attached to the root) and attach the visible sprite to that component (you can still use the same sprite for both if you have complex collision, set one to hidden and the other to don’t collide). This will let you shift the visible component freely without worrying about what happens to the collision and is the same way 3D characters are handled for the most part; the capsule component and character movement component do all the work there and the skeletal mesh is just along for the ride.

Cheers,
Michael Noland

7

Hi Michael Noland,

thank you very much for the response, it is nice to see an Epic Staff is looking into this. Indeed I have tried the “Condition Tile Sheet Texture” option, but while it fixed some of the artifacts, I can not help but feel it still looks a bit strange. I guess it really might be easiest to explain if I just uploaded the project. Unfortunately I only have the executable uploaded at the moment, rather than the project folder, but I will edit that as soon as I find the time to upload it. (For now, here’s just the executable: https://dl.dropboxusercontent.com/u/70131214/DemoLevelSmall.7z When moving with the arrow keys, there just seems to be an unusual amount of flickering and blurriness in the environment. For those who are curious: The other controls are “a”,“s” and 1-3).

I definetly thought of decoupling the collision component. For some reason it did not work out, but I am afraid I can not recall why. That being said, I am not sure it was that exact setup. I think it might have had to do with me being unable to prevent the character from moving on the z-axis in some situations. The sprite moved along with that, potentially ending up behind the camera or behind other objects which had a strange z due to the aforementioned issue with the capsule colliders and such. Recalculating the z for the sprite every frame was not easily possible or frankly, maybe it was just a lot too much effort. Either way, I got stuck on something. In hindsight I really wish I had noted all of that down when I was working on the project. Maybe I will have another look at it when I find the time and see if I can get it to work, but let me be honest: Although I can only assume here, I think it’d save a number of people some pain if the 2D colliders were simply moved out of experimental, as I think that would solve most, if not all of those issues. :wink: