[Official] 2D Improvements

Makes sense to me. Having not messed around with the 2d tools, I was kind of under the impression that physics2d was more like a rigid body. Anything that keeps a 2d and 3d development mindset thinking the same way is probably the best.

 

Who are you?
Gameplay/tool programmer at Swing Swing Submarine.
Previously gameplay programmer on Rayman Origins & Rayman Legends at Ubisoft, part of the core team working on the UbiArt framework.
Currently in pre-production of Seasons After Fall with at least one year of production ahead of us (team of 5).

What kind of game are you trying to build or would like to build?
Modern 2D game: flat 2D rendered in perspective 3D, 2D gameplay, organic feel, no square tiles, no pixel art.
Technically similar to what we did on Rayman, but the gameplay will be much slower (exploration/puzzle rather than hectic platforming).

How does 2D fit into that? What use-cases do you have?
See above?

What are the GOOD things about the current 2D system you like?
Sprite atlasing is great, we just reason in term of sprites and artists don't have to worry about packing sheets anymore.
Custom sorting is... promising.

What are the BAD things about the current 2D system you dislike?

• Sprite references break if we remove a sprite from a sheet: this is quite ridiculous! This completely breaks the awesomeness of Unity's asset database.
• Physics is way too limited: no edge index/t info on collision! even on raycasts! We don't want any physics per say, only collision detection (the player is purely script-driven, we have 0 rigidbody, nothing driven by forces). Using our own port of Farseer at the moment, just for collision detection.
• Sorting is a pain for pseudo-3D. We want perspective, so we use the z, but at soon as we inject sorting layer/order it takes precedence over everything. The thing is, we DO want to control the order in some cases (eg terrain with bevel: the bevel should always be drawn behind, not intersect with anything). At the moment it's all or nothing, so we may end up having our own sort manager that will set the order on everything, but setting the sort order means touching serialized data, which sucks...
• around the same subject: Graphics.DrawMesh doesn't accept a sorting layer/order, that's a pity! It should be way easier to draw procedural geometry and integrate into the editor (DrawMesh == no sorting, no picking !), give us a proper ProceduralRenderer that we can derive from.

How can we make it BETTER?

• Sorting: maybe have a mode driven by z THEN order (if same z); or, a callback to be able to output a custom order on the fly (so we can have our own rules for sorting).
• Sprites: it would be great to be able to extend the sprites/sprite editor to add custom metadata directly on the sprite (eg collision shapes, attach points, whatever). Doing everything in prefabs can be cumbersome (or, give us nested-prefabs-dammit

Do you like the Mecanim workflow for animation?
So far so good. Haven't used it all that much yet, but it looks like it'll be perfect for the main character's blend tree.
I was surprised to see we can't create custom nodes and I'm pretty sure it's gonna be an issue at some point.

How do you spend most of your time working with our 2D features? Anything bogging you down?
Honestly we don't spend that much time with it as we develop our own sub-systems for a few things, so the things that bother us are mostly API limitations rather than workflow issues.

When you learned to use our 2D system, what stumped you or had a steep learning curve?
Nothing that I recall...

 

Who am I? Summing up previous posts, I'm a dual-hatted Unity user with 2 concurrent Unity Pro licenses, that develops both professional training games (PC/Web) and indie titles (iOS/Android), with 11 years in game industry, including some AAA, and 3+ years with Unity.

2D Needs

- 2D Particle system - that plays well with new 2D system and forthcoming uGUI, including flat-plane spawn, sort order, per-axis emission shape adjustment.

- 2D Object Pooling

- GUI - Scrolling lists of complex menu options (ex background, with icon on left, 2-rows of text, and 'purchase' button on right, for multiple items in a scrolling list).

Gigi

 

Hi everyone,
Here's the summary of this thread so far. Both Juha and Tomas have posted some replies, but I'm including the complete list of feedback. Let me know if I missed anything. Inclusion in the list doesn't mean it will be implemented, this is just gathering feedback.

No particular order...

• Allow sprites in planes other than X/Y (X/Z especially)
• Integration with other systems such as particles, NavMesh
• Shaders that work with per-pixel lights, PBS, etc.
• Ability to atlas sprites with additional materials maps like normalmaps
• Tileable rects
• Ability to access generated mesh
• Reusable animations for sprites with the same rect structure
• Better atlas packing
• Ability to post-process atlases
• Specify the origin point for sliced sprites
• Mecanim can be overkill or too hard to use with 2D
• Better/easier WYSIWYG 2D animation system
• Ability to generate sprites from code
• Flipping sprites using scaling messes up things like colliders
• 2D physics improvements: ignore collision, more access via API, breakable joints
• Ability to reset the polygon collider to basic pentagon
• Better grid/snapping options for doing layout and placement
• Ability to modify sprite texture at runtime quickly, apply modifications
• Tilemap editor
• Ability to use sprites as particles
• Vector graphics support
• Easier way to do parallax scrolling/movement
• 2D character controllers
• Ability to swap out sprites at runtime and use same animations
• Queriable collision checks
• Better layering of 2D/3D elements
• 9-Grid Sprite
• Tiling of Sprites
• GameObject based render order
• Access to 2D Atlases from code
• Better Sprite selection in scene editor
• 2D jointed characters and IK
• 2D skinned mesh

 

You know what I thought would be... like... intrinsically sweet for a 2.5D / overhead 2D type game?

Built in render order on Y/Z position on the screen. Have it apply to only certain layers. I know you can set up tilemap layers, etc. but... this would be pretty cool. Not sure on feasibility, or if anyone would even use it, but it makes things interesting.

 

Most of this stuff you can actually implement in Unity right now pretty easily.

 

Take a look at this feature of editing levels in ubiart framework.
fantastic. Unity could implement this in future.

https://www.youtube.com/watch?v=XoLpPw864eA&feature=youtu.be#t=2m27s

https://www.youtube.com/watch?v=y-chi097uV4#t=7m54s

https://www.youtube.com/watch?v=y-chi097uV4#t=16m10s

This would greatly reduce time to edit levels.
Only need to drag a node, creating more texture, it's like a 2D terrain or array.
I do not know the most appropriate name for this feature. But add to this list please.

 

I refer mainly to the terrain 2D shown in the video. UE4 is implementing this feature too.

 

Seriously, if Unity could improve every part of the engine by using peoples suggestions, then I would never ever leave Unity

 

Nothing really comes to mind, and I don't have the time yet to answer everything in the OP. But...

I know this is a crazy feature request, but I have seen some amazing things done with particle effects, 3D lighting, and similar things in 2D games.

Forgive me if this is a stupid request, as Unity3D may already be fully able to do this easily. I have not yet dug in to research this type of stuff for 2D. So I may be asking for a feature that is already there, lol. I just thought I'd bring it up just in case, since Unity's 3D is perfect for this type of awesome 2D work.

Anyway, I was always impressed with that Ethanon engine, although it's gotten older. It pulled my eyes in though. Not just the 3D lighting in 2D, but the weather effects like snow accumulation. It is also huge eye candy, so it has the added benefit of pulling in people just based on the "Ahh man I need that!" cool factor.

Cool weather effects, all in 2D (although it's a bit outdated in terms of graphics quality, it's an example)

Lighting (which as I said, may already be very easy in Unity3D for 2D, since Unity is a 3D engine. However, I have not tried this so I assume others would know if it were well supported (easy to implement) or could use some improvements like so many 2D improvements were given in Unity 4.5 & 4.6)

Remember, this is all 2D. No 3D in these videos.

 

The lighting effects there are also really easy to implement, even the shadow one. They're all pretty standard shaders with a few extra twists to make the 2D have appropriate depth.

 

Good to know! I assumed that, but I really like that snow effect which I know isn't in Unity
Figured I'd throw the lighting thing in "just in case" or just to contribute some out of the box sparks of the imagination.

I haven't done anything in 3D with Unity at all, and have used very few of even its 2D functions. I nearly always shoot for 2D games no matter what I'm doing.

 

2D Lighting & Shadows is one of the most requested on the feedback.

http://feedback.unity3d.com/suggestions/2d-lighting-and-shadows

Examples:

http://indie.gameru.net/wp-content/uploads/screen01.png
http://operationrainfall.com/wp-content/uploads/2013/06/RL_Ocean_World.jpg
http://www.gamershell.com/static/streaming/53289/53289_medium.jpg

More examples in sample scenes: http://reverieinteractive.com/2DVLS/Documentation/sample_scenes.html

 

Who are you?
I'm a programer and level designer, working on a Unity 2D project.

What kind of game are you trying to build or would like to build?
I'm currently working on an run and gun side-scrolling.

How does 2D fit into that? What use-cases do you have?
Apart from the above, I produced some 2D games for mobile.

What are the GOOD things about the current 2D system you like?
Sprite editor, 2D Colliders and rigidbodies. Simples de aprender.
It was a good start to the 2D in Unity .

What are the BAD things about the current 2D system you dislike?
Lack the option of using the legacy system to animate in simpler cases.
Level editor can improve. It is not practical to mount levels.

How can we make it BETTER?
Legacy system for 2D animation.
Rig for 2D.
2D Lighting & Shadows.
Examples in sample scenes: http://reverieinteractive.com/2DVLS/Documentation/sample_scenes.html
Blend Mode like a Construct2:
http://www.lestradamus.com/awordpress/construct2/capitulo 4/4_archivos/image004.jpg
2D Terrain/ path, like a ubiart framework. To create organic scenarios and more practical to build levels.

Examples:
In 16m e 10s: https://www.youtube.com/watch?v=y-chi097uV4#t=16m10s
In 7m e 54s: https://www.youtube.com/watch?v=y-chi097uV4#t=7m54s

I put some examples in the posts above about ubi art and 2D Lighting & Shadows.

Do you like the Mecanim workflow for animation?
Yes, but lacks the option to use the legacy system. Mecanim work for more complex cases. Having both options will help everyone.

How do you spend most of your time working with our 2D features? Anything bogging you down?
Most of the time editing levels.

When you learned to use our 2D system, what stumped you or had a steep learning curve?
It's easy to learn. Intuitive interface and good documentation.

 

Stuff like in the first video is actually not simple to achieve (at least for me as I'm a shader noob), it uses a technique of depth testing using depth texture on each sprite. A depth texture is just a heightmap in greyscale, each pixel color of the depth texture result in a certain distance that is calculated sending info in the depth buffer trough some shader work.

Here some example done with unity:

Some interesting info here:
http://www.liberamegame.com/z-depth-compositing-in-unity/

 

i think what Neurological meant was:
what it each mob has 10 or 20 skins where the animation is exactly the same except the uv?



the 'official' solution is to change each sprite of each renderer each frame in lateUpdate with string find and replace?

but that does not really sound like a 'good' solution
but better then remaking so many duplicate animations
but maybe not if gonna have lots of objects performing this work each frame

is there any way to do this work at build/compile time instead of runtime?
i mean besides creating and updating many duplicate animations by hand

thanks

 

Don't forget to implement an easy way to control / use multiple atlases for multiple resolutions. Now we have to do everything manual.

 

We have made an asset to improve the Unity 2D SpriteRenderer with some cool FX : https://www.assetstore.unity3d.com/en/#!/content/42566 ( the thread is here if you want to talk about it : http://forum.unity3d.com/threads/released-2dxfx-2d-sprite-fx.344962/ )

As a game dev,

What kind of game are you trying to build or would like to build?
Enhanced 2D games, it's what we do, trying to do the best looking game and help the community by creating tools

What are the GOOD things about the current 2D system you like?
The layer system is simple and so, great !

What are the BAD things about the current 2D system you dislike?
The sprite management could be improve with new stuff

How can we make it BETTER?

We need tools for optimisation
The possibilities to manipulate the layers/order by code, we need more flexiblity
2D Physics Improvements ( with new cool stuff )
Easier way to create parallax scrolling and to manage the layers system
2D skinned mesh !
Better optimisation of the 2D sprite mesh !

Anyway, thanks to the Unity dev team for the 2D systems and for giving to us the possibilities to create and sale our new 2D tools.

 

Who are you?
Hobbyist, first 2D game but a decent amount of programming/software experience.

What kind of game are you trying to build or would like to build?
Physics based space shooter.

How does 2D fit into that? What use-cases do you have?
I kind of like 2d better than 3d. It's simple and has better performance on phones.

What are the GOOD things about the current 2D system you like?
Coming from my first two failed engines, spritekit/swift and cocos2d/swift, I can say everything. Low number of bugs, things work, things are functional, easy drag and drop polygon colliders(that actually work), world space to local space transforms don't have bugs, physics trigger and collision callbacks work properly. Easy to use, functional and works well. Also builds for other platforms? Very happy with the current 2D system and unity in general.

What are the BAD things about the current 2D system you dislike?
Nothing at the moment.

And specifically to the 2D system...

Do you like the Mecanim workflow for animation?
Haven't used animation yet.

How do you spend most of your time working with our 2D features? Anything bogging you down?
Using raycasts with layers and tagging and physics collisions and triggers can get complicated. What collides with what etc. That's a problem I had/have. Why is my raycast colliding at the center of my object? Oh my layer wasn't set right. Debug draw line/ray helped.

When you learned to use our 2D system, what stumped you or had a steep learning curve?
Very easy for me to learn as I had already learned two other 2D physics engines also based on box2d. I was pleasantly surprised when scaling worked with 2D colliders.
The steep learning curve was the asset store: what was done better than unity, did I need it, and why.
Currently I'm thinking a 2D polygon optimization tool for the colliders. I think 2D is all about optimization as it's likely it will be built for phones so, is there polygon optimization in unity? And will it re-optimize during a scale? And is that even necessary.

 

Who are you?
Just me.

What kind of game are you trying to build or would like to build?
Not any one particular game just 2D games in general. Platformers, shmups, top down action adventures and so forth.

How does 2D fit into that? What use-cases do you have?
I am mainly interested in making 2D games most likely in a retro presentation style.

What are the GOOD things about the current 2D system you like?
I like that it actually has sprites built into the later versions.

What are the BAD things about the current 2D system you dislike?

• The GUI-based workflow. I don't want to mess around in the Editor selecting sprites and attaching them to prefabs.
• The GUI-based workflow. I don't want to mess around in the Editor slicing sprites out a sprite sheet. Especially when the sprite editor is (or was anyway up to 4.6 which is the version I still use) bugged and does not correctly slice the sprites.
• The GUI-based workflow. I don't want to mess around in the Editor creating animation sequences and especially don't want to deal with Mechanim setting up states and such for them.
• The colliders. It seems illogical to have them associated with GameObjects. A GO with a SpriteRenderer can display any sprite (image).

How can we make it BETTER?

• Enhance the API to appeal more to programmers. By this I mean to add more code-oriented support for working with 2D. A method to load and slice a spritesheet from C# for example. A method to create the auto 2D colliders such as polygon and so forth.
• If I was making the 2D colliders system I would have the colliders be associated with the images (sprites in Unity terminology) themselves instead of the GameObjects. A GameObject with a SpriteRenderer can display any sprite image. That is fine. However, there is no connection as far as I know between the image the SpriteRender is displaying and the collider. The actual collider size and shape has nothing to do with a GameObject and instead has everything to do with the image that is being displayed. So it makes logical sense to have the colliders be linked to those images not to the GameObjects.

Do you like the Mecanim workflow for animation?
Not at all and I do not use the animation systems in Unity at all either Legacy or Mecanim. Mecanim seems like being asked to use a jackhammer when all that is needed is a ball peen hammer. This kind of thing just complicates an otherwise simple process and bloats the workflow.

How do you spend most of your time working with our 2D features? Anything bogging you down?
I use as little of it as possible for the reasons listed above. Most of the my time is spent on actually developing the game. Programming the systems, working around limitations of the current system (as noted above) and so forth as needed. As little of my time as possible is spent working in the Editor and using the existing Unity 2D workflows and so forth.

When you learned to use our 2D system, what stumped you or had a steep learning curve?
Bugs in the sprite slicer, dealing with glitches ("tearing") when displaying tiles and figuring out a solution to colliders not being tied to the actual sprite images.

 

Indie game developer

Has the navigation and particle system been adapted to work in 2D?

 

Completely disagree, sorry. It's quite common to use colliders that have no relation to images whatsoever. (Invisible trigger zones, for example.) Not to mention it's typical to use primitive colliders with complex shapes (a box collider for an animated character). Also you can use 2D colliders with 3D models for 2.5D games. It would go against everything else in Unity for colliders not to be components attached to GameObjects and it doesn't make any real sense to link them to images.

--Eric

 

That is fine. We can all disagree because we all want different things!

Yeah I get that. I can definitely see uses for being able to add colliders to the GameObjects for things you mention sure. Those are things that have nothing to do with the actual sprite images themselves. What I am talking about is Unity supports polygon colliders. That's cool because it is probably the closest they have to a traditional pixel-perfect collision checking. However, there seems to be no actual effective way of using it.

 

If you add a polygon collider to a sprite, it automatically creates a collider in the shape of the sprite, based on the alpha. Plus you can manually edit it to be whatever shape you want.

--Eric

 

Yes and that is how I ended up creating my own system as a workaround to use them.

Say you have an animated character walking, jumping and so forth. When you add the polygon collider Unity automatically creates the polygon based on the shape of the sprite (although the polygon shape mapping gets worse the smaller the sprite image is). Great so we now have a polygon collider for the sprite image currently being used. Now say the character ducks. So the Sprite Renderer is now displaying the ducking sprite image. Yet the collider is still mapped for the standing sprite image. And the same for the walking frames, jumping, etc.

I got around this by... at the start of the game... running through every sprite image that would be used and setting the sprite renderer to that image. Then adding a collider. Then storing that collider in an array. So, I ended up with a load of colliders attached to the game object. As the image changed the current collider is disable and the collider corresponding to the new image being displayed is enabled.

That works sure but it just seems like a very inefficient pain in the arse way of doing it. I mean this is pretty basic stuff. If the colliders were associated with the image (the way I ended up doing it in code myself) then the sprite renderer could automatically be doing this stuff behind the scenes to keep the colliders in sync with the actual image being displayed.

 

You rarely actually want to use that kind of precision, though. In most cases you just use a box collider or similar and scale it if needed. In most games you want a consistent collider shape, not something that's constantly changing.

--Eric