Achilleon
August 17, 2016, 7:37pm
4
– 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.
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.
My 2 cents, yet again.
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.