Search Unity

  1. Dismiss Notice
  2. Looking for a job or to hire someone for a project? Check out the re-opened job forums.
    Dismiss Notice
  3. Unity 2020 LTS & Unity 2021.1 have been released.
    Dismiss Notice
  4. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

[Official] 2D Improvements

Discussion in 'General Discussion' started by bibbinator, May 26, 2014.

  1. bibbinator

    bibbinator

    Unity Technologies

    Joined:
    Nov 20, 2009
    Posts:
    507
    Hi all,
    This is a bit of copy paste from the Particle System thread, please forgive that. The core message is the same, so I optimized my time a little bit :)

    We would like to discuss the direction of our 2D system with you. Rather than pre-seed this discussion with what's on the roadmap, I want to be sure we don't miss anything, so I want to start this discussion with a relatively blank roadmap.

    To really help us though, like we have done in other threads, it REALLY helps for us to understand who you are and what your use-cases are to put you comments in context.

    Who are you?
    What kind of game are you trying to build or would like to build?
    How does 2D fit into that? What use-cases do you have?
    What are the GOOD things about the current 2D system you like?
    What are the BAD things about the current 2D system you dislike?
    How can we make it BETTER?

    And specifically to the 2D system...

    Do you like the Mecanim workflow for animation?
    How do you spend most of your time working with our 2D features? Anything bogging you down?
    When you learned to use our 2D system, what stumped you or had a steep learning curve?

    Again, it's super important we understand you and your use-case more than "add feature X now, do it!" without context.

    Thanks!
    Brett
     
  2. the_motionblur

    the_motionblur

    Joined:
    Mar 4, 2008
    Posts:
    1,738
    Who are you?
    Part time freelancer - part time In-House artist for a large Webgames Company. Sometimes teacher at University of applied sciences.
    Game and 3D Art enthusiast. I like games - either cutting edge or retro/indie. I grew up with the NES and Amiga500 and I started graphics with DPain IV on the Amiga. Also with a 3D program that took like 7 hours to render a 200 polygon robot ;)

    What kind of game are you trying to build or would like to build?
    Specifically with the 2D System I'd love to build wither sidescrolling action games (run and gun - I'm not a primary fan of space shoot em ups despite that these are the focus for many beginner tutorials) or top-down actioney RPGish games like Zelda and such. :)

    I successfully started prototyping a top-down shooter I was a fan of in the 90s. So far I'd consider it a hobby-project though. ;)

    How does 2D fit into that? What use-cases do you have?
    On a day to day basis my 2D work is mostly in the area of simply creating single rendered items or small anims - characters with few animations and mostly environment items. Mostly Isometric or Top down as well. Sometimes beauty-shots for backgrounds or environments.

    What are the GOOD things about the current 2D system you like?
    I like that it has the flexibility and workflow of Unity combined with a simpler more focused workspace.
    The sprite-slicing and animation helpers are surely a real time- and pain-saver.
    Physics for 2D games are really cool. Gotta love physics! :D
    Also there's unity's native multi-platform export of course.

    What are the BAD things about the current 2D system you dislike?
    HUGE HUGE No-Go: Since 2D is locked in to X/Y and Navmesh is Locked in to X/Z there's no way to use navmesh despite using a Pro license.
    This also means that things like the "look at" script don't use as expected (also rotated in the "wrong" plane). and either need hack-workarounds or a new implementation.
    Generally speaking I come from Scirra's Contruct 2 for 2D games. Mainly because in the beginning I was scared of trying to script. Now I find that scripting enables me to do much more focused work because I don't need to try and use building blocks for something they were not designed to. Construct is a really cool tool but I'd want something that feels like I can actually publish my game with it - for real.
    Then again: Construct DOES have an out of the box building block solution for nearly every basic 2D setup you need to have - sidescroller, top down action or racing game, "vintage" image effects like pixelation or screen flashes, navigation or even turret behaviour with predictive aiming, screen scrolling ... It's so nice to get an idea out of your system and onto the screen immediately.
    I think Unity could really benefit if there were more of these "building blocks" available since (as much as I love Construct) unity is the more professional engine for an actual game that is created in order to be published.

    Mecanim as a state-machine is surely powerful but I can't really put my finger on it what it is that makes me confused using it every time I fire it up. Animation - especially with all the features Mecanim provides - is an ultra complex subject. I know that. Yet it feels so oddly disconnected to the rest of Unity's workflow. I'm sorry that I can't really give any improvement ideas, either. I can just tell that despite eventually getting it to be where I want it to be eventually the whole process feels ... "off".

    How can we make it BETTER?
    As mentioned several times now: Top-Down Games and Navmesh. It's an absolute no-go for me that a Pro Feature is useless because 2D was designed with apparently only sidescrollers in mind.

    More building blocks - turret behaviour, player controller, screen scroller, 2D camera actions. At least have something there for prototyping and people scared of scripts. ;)
    As soon as these scripts don't cut it any more Unity DOES provide a scripting interface to go on and dive deeper. And that's absolutely good the way it is. Yet all these standard effects like paralax scrolling, pixelation etc.... I want them. Out of the box. even if they are available - I don't want to sift through various example projects and pick out the respective scripts from there.

    Also: A sprite shader that works with Pixel-Lights! :)
     
  3. Deleted User

    Deleted User

    Guest

    Tileable rects, ability to access generated mesh info (example for scrolling uvs). Reusable animations for sprites with the same rect structure.
     
  4. rootools

    rootools

    Joined:
    Nov 25, 2013
    Posts:
    16
    I am work with Unity about 6 month. I make different prototypes. And I lack the vector rendering in 2D and support vector images format for import. And also Tile system for RTS or Tycoon games will big things i think)
     
  5. soulburner

    soulburner

    Joined:
    Mar 25, 2012
    Posts:
    155
    A programmer, a member of a small indie studio. http://gamejam.ru


    Its quite obvious - we have lots of 2D sprites in both projects ;)

    Like sprites shape-detection to cut off the transparancy and to pack in atlases tightly.
    Like auto-packing atlases

    We couldn't use native 2D for our mobile citybuilder because we needed to use some tools for final atlases. For example, we're using two ETC textures (RGB + alpha) for the android build. That is achieved using our custom shader and converting atlases from one PNG to two pictures (RGB and alpha-channel).

    Also, is not quite obvious how to create some text/int link to a sprite. (For example, if I want ot create a downloadable bundle with sprite links but without sprite data and then to use sprites from the different bundle).

    Text/id links will be usefull also for swapping atlases (different atlases for different resolutions).
    I want some tools to manually post-process atlases (maybe some post-processing scripts?)
    Also, changing native 2D sprite shader is not obvious right now (but quite managable after a while).

    Mecanim looks a bit overpowered for easy animations right now, but it will be interesting to try.

    Most of the time we spend writing a game code. So, 2D functionality works fine ;)

    Everything is ok. I've watched a pair videos on YouTube and get it.

     
    Last edited: May 26, 2014
  6. SiegfriedCroes

    SiegfriedCroes

    Joined:
    Oct 19, 2013
    Posts:
    566
    Who are you?
    Full time Multimedia Designer, spending my free time on making games. Working on a 2D game since the introduction of the 2D tools.

    What kind of game are you trying to build or would like to build?
    I'm working on a 2D top down (Zelda style) RPG.

    How does 2D fit into that? What use-cases do you have?
    I chose low resolution pixel art as the style for my game so I use sprites for everything (no mixing of low res pixel art with, high res fonts or GUI elements!)

    What are the GOOD things about the current 2D system you like?
    - Sprite slicing and atlasing (+ keeping the drawcalls to a minimum)
    - Sorting layers
    - Addition of 2D physics

    What are the BAD things about the current 2D system you dislike?
    One thing I don't like about the Sprite slicing is that the origin point of the sprite is at the bottom left. In most cases this doesn't really matter but I have a sprite with all kinds of UI elements, including letters, numbers,... for the text in my game. I sliced all of those elements manually which is a bit of work. The problem occurs when I want to add more elements to the sprite and for that reason change the height of it. When doing that the previous slicing will offset... This wouldn't be the case if the origin point was at the top.

    As my game is in pixel art, I use sprite swapping for all animations. The problem with the current way of sprite swapping in animation is that the animation points to specific sprites. This means I have to make a separate animation for each walking direction of my character (8 in total) and when I have NPCs I will have to make 8 more for each of them, even though all of the animations are basically the same "show 4 frames in a row and repeat". For now I'm just thinking of writing my own SpriteAnimation system to take care of this but it would be nice to have it build into Unity :)

    Apart from that I've had some trouble getting my game 100% pixel perfect, I fixed this by adding small decimal values to the coordinates of sprites.

    How can we make it BETTER?
    It would be nice to have the things I mentioned above be fixed.

    Something else I would love to see is a build in Tilemap system.

    Last but not least it would be great to have access to a SpriteRenderer's mesh data.

    Do you like the Mecanim workflow for animation?
    As I said earlier, Mecanim is a bit too "advanced" for the simple sprite swapping animations I want to do.

    When you learned to use our 2D system, what stumped you or had a steep learning curve?
    Didn't have much problems with any of the 2D stuff so far :)

    The current 2D features are a nice start. I worked on 3D games in Unity in the past but when I decided I wanted to make a 2D game I was about to use Flash at first. Then came the announcement of the 2D features and after fiddling a bit with it I just stuck to Unity ;) Really looking forward to see what more 2D stuff will be added in the future :D
     
    Last edited: May 26, 2014
  7. freakdave

    freakdave

    Joined:
    Nov 18, 2012
    Posts:
    78
    Hi there:

    Who are you?
    A part time freelancer, working on several smaller projects

    What kind of game are you trying to build or would like to build?
    Casual 3D games

    How does 2D fit into that? What use-cases do you have?
    I am using 2D as a replacement for Unity's broken GUI, in short: I code my own custom GUI with 2D

    What are the GOOD things about the current 2D system you like?
    Automatic slicing of sprites, I really like it

    What are the BAD things about the current 2D system you dislike?
    Just being able to use the standard sprite shader kind of sucks. Also, animating 2D with mecanim is somewhat tedious.

    How can we make it BETTER?
    Allow us to use shaders with pixel light support!

    And specifically to the 2D system...

    Do you like the Mecanim workflow for animation?

    No, it does not feel very intuitive. But this might just be me.

    How do you spend most of your time working with our 2D features? Anything bogging you down?
    Making a simple animation with mecanim, animation controllers, etc, is too much for a 2D system

    When you learned to use our 2D system, what stumped you or had a steep learning curve?
    See above, in my opinion you shouldn't use mecanim for animating 2D sprites, it feels too heavy and too complicated
     
    Last edited: May 26, 2014
  8. DominoK

    DominoK

    Joined:
    Dec 2, 2012
    Posts:
    1
    Who are you?
    I'm a game development student with 4+ years experience working with Unity.

    What kind of game are you trying to build or would like to build?
    Whatever I feel like

    How does 2D fit into that? What use-cases do you have?
    The Unity2D makes it a lot easier to prototype simple game mechanics.

    What are the GOOD things about the current 2D system you like?
    It works nearly the same as Unity3D which kept the workflow nearly identical.

    What are the BAD things about the current 2D system you dislike?
    The lack of code generated sprites. In a current project I'm creating a procedurally generated world, but that's very difficult without the sprites. Right now I managed to hack around by using a mesh renderer to create shapes with 2D collisions.
     
  9. Grafos

    Grafos

    Joined:
    Aug 30, 2011
    Posts:
    223
    I am a mostly solo Developer. I created my company, Grafos, in late 2010.
    I have published a couple of educational titles on PC/Mac/iOS and Android.
    I started with Blitz3D/Blitzmax in 2007 and moved to Unity 3 years ago.
    I have been recently expanding to casual/indie titles. Even bigger dreams for the future :)

    I am currently making Fuzzy Bunny ,a game that I would best describe as a crossover
    of Rainbow Islands, Doodle Jump and Street Surfer (an old C64 game I used to play as a kid).
    It'll be the first time I am going to try In-App purchasing, Ads and Free-To-Play.

    Fits like a glove ;)


    It's great, pretty straightforward, I like it a lot.

    On Fuzzy Bunny I'd like to have an automatic resolution adjustment with many parameters (black screen, fixed Y, or fixedX axis).
    On animation, it seems to me you can only animate the global position, or am I missing something. Currently, if I want I can loop the y localPosition Up and Down and at the same time move upwards, I have to rely on extra parent GameObjects to allocate each movement. It's entirely possible I'm missing something obvious.

    Also, I was developing a 2.5D game at one point and I wanted to use 2d colliders and perspective cameras. They didn't seem to agree with each other, an automatic way to make the collider correct its position as 2d while keeping the depth and beautiful parallax of 3d scenes would be great (I am having trouble describing this, I hope I make sense)

    By taking care of the issues I just mentioned :p
    Also, native support for ads, in-app purchasing, facebook, twitter, game centres and all these social cr... services on all platforms. Hmmm... those are not really connected to 2d systems, but in any case. most 2d games on mobile require this now.
    And lower the price of Pro to match UE's subscription... ooooooops... sorry, I couldn't resist it :p
     
    Last edited: May 26, 2014
  10. Amakh

    Amakh

    Joined:
    May 26, 2014
    Posts:
    1
    Hello!

    Who are you?
    I'm a student 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 interactive video included 15 mini-games - AS3 games like.

    How does 2D fit into that? What use-cases do you have?
    It's really more intuitive than Flash/AS3, create small games is very easier.

    What are the GOOD things about the current 2D system you like?
    Multiple sprites, 2D Colliders and rigidbodies!

    What are the BAD things about the current 2D system you dislike?
    Animating a spritesheet when the file is not 100% correct.
    Using particle system in 2D is quite annoying!

    How can we make it BETTER?
    Make the animation system easier and improve sprite animations.

    Do you like the Mecanim workflow for animation?
    It's really good but I feel that it's not really user-friendly.
     
  11. funshark

    funshark

    Joined:
    Mar 24, 2009
    Posts:
    225
    Freelancer game artist
    Any 2D game
    well :)
    Anything that have been done is good and a step forward
    - The timeline is not really effective right now; it is better than before to visualize things and somewhat to animate but there are still things very frustrating.
    - the sprite editor could be better and we can't have a custom pivot point on single sprite currently.
    - the layer sorting could be more visible and with a better interface.
    - ho! one thing I currently HATE :) is the scaling mode in the scene view : if we switch from simple scaling to ALT or SHIFT , it doesn't revert it back to its original position so the sprite is moving and it's really annoying!

    Just look at ubisoft rayman engine :)

    - need a multi-res support ( camera textures )
    - need a better font/gui support
    - adapt shuriken to the 2D workflow
    - the possibility to see at any time the colliders, the camera frame, things like that... would be great

    It's not bad but could be better :
    - need a more easy way of doing instant transition
    - need an answer to this issue/questioning http://forum.unity3d.com/threads/247456-Mecanim-Animator-1-frame-lag
    - I still don't understand the atomic thing
    - Animating I guess? So anything better with the animation part would be great
    - mecanim
     
  12. Ferazel

    Ferazel

    Joined:
    Apr 18, 2010
    Posts:
    468
    Who are you?
    I'm a programmer at a small developer using Unity to create 3D/2D games and applications.

    What kind of game are you trying to build or would like to build?
    Both games and utilities that can mesh 3D and 2D assets together.

    How does 2D fit into that? What use-cases do you have?
    We've tried to use 2D to fit into the workflow for certain highlight and effects for our current 3D game. I have only used the 2D system lightly so I am not a pro at it.

    What are the GOOD things about the current 2D system you like?
    Tight Atlas Packing - I like the tight packing of atlases, and being able to create atlases for transparent areas that are the most efficient possible.

    Atlas importing - Being able to bring in an already created atlas and the system being able to rect out the areas that are necessary automatically.

    2D integration into the editor: I think that it's nice that you have sprite import settings build into the texture importer.


    What are the BAD things about the current 2D system you dislike? How can we make it BETTER?
    Atlas resource management - I realize that you wanted to make the atlas behind the scenes, but I really feel that instead of changing every sprite to change compression settings (for example) is kind of the wrong approach. I'd rather just change it in one spot rather than the 50 spots in order to get the compression working a certain way. Have an atlas management window that allows us better access to each atlas and each sprite that is used on that atlas. Making changes at this level will automatically change each of the used sprite's import settings.

    AssetBundles - Last I heard, the way of including sprites independently is to always include the atlases in each asset bundle. I think an improvement would be to allow us to have virtual resources and a better defined resource system as part of the build process. Allowing us to choose what to include in the build and what to include into external bundles. This is more of a resource management issue and may be beyond the scope of the 2D system.

    Tight Packing Algorithm - I get that the tight packing is a computed algorithm that is supposed to be more efficient than quads for fill-rate-limited system, but the mesh that is generated is often overly complex and inefficient. Something like a simple hex using 100 verts instead of 8. What I want is the best of both worlds. I want to have an ability to use tight packing, but be allowed to import geometry to use for a specific sprite when the automatic system is not efficient. Even better, would be a sprite vertex creator (similar to the 2D collider system) built-into the editor. This would allow us much more fine-grained control over the geometry that is generated by each sprite instead of relying on an often inefficient algorithm.

    Sprite Layers - I understand you wanted to give an easy way to handle z-depth, but there is already a way in the engine to handle that (material render queues). I think you should make layers use a render queue that is automatic (but overridable explicitly) in the layer manager. Having the 2D sorting system outside of an already determined ordering system seems weird and unintuitive. It burned me on my current project until I found out that the 2D layer sorting was rendered after all of my 3D geometry regardless of the render queue of the shader/material I used on the sprites.

    Edit:
    Better Mip-Mapping Control - This is more of a general texture import issue, but I would like to have an import setting that allows us to better control mip-map bias on a global level and per-sprite/texture level.

    As mentioned by others:
    Multi-Resolution Support - An absolute must! Allow us to create a "texture" fidelity that allows us to set Low/Medium/High resolution atlases allowing us to target different devices with the same project easier.
     
    Last edited: May 26, 2014
  13. bryantdrewjones

    bryantdrewjones

    Joined:
    Aug 29, 2011
    Posts:
    147
    Hello :)

    Who are you?
    I'm an independent designer/programmer. I've shipped a handful of 2D games using Unity over the past 4 years-ish.

    What kind of game are you trying to build or would like to build?
    Exclusively 2D games for a wide range of platforms.

    What are the GOOD things about the current 2D system you like?
    1. It's ridiculously easy to import 2D art and get my sprites on screen.
    2. I love the tight sprite packing. It saves so much space compared to a rectangle-based sprite packer like TexturePacker.
    3. I love that the meshes Unity generates are optimized for fill rate.
    4. It's great to be able to use a perspective camera and integrate with 3D content, if necessary.
    5. I don't use rigid body physics, but the physics API makes it super easy to do my own collision checking, which allows me to script tight and responsive controls.

    What are the BAD things about the current 2D system you dislike?
    1. There is no reasonable workflow for multi-resolution support! I know this is on the roadmap, but it seriously can't come soon enough. It's a huge limitation.
    2. Mecanim is super awkward and bloated for 2D animations. It's not intuitive, and it's a huge time sink trying to set it up right.
    3. As far as I know, there's no way to flip a sprite horizontally or vertically without setting its scale to -1. This becomes a problem when colliders are attached and I don't want the colliders to flip with the character.
    4. It's a bit annoying having to set the sorting layer through script on non-2D renderers, like particle systems.

    How can we make it BETTER?
    It can be made better by addressing the points above :) But please start by adding some kind of workflow for multi-resolution support! We need our 2D art looking crisp across all platforms -- regardless of the screen resolution.

    Do you like the Mecanim workflow for animation?
    Not at all. As I said above, it feels unintuitive and bloated. It's not designed with frame-by-frame sprite animations in mind. For instance, while 3D or skeletal animations can easily be blended, frame-by-frame animations cannot. I need the ability to transition to another animation on a specific frame (e.g., the walk animation can transition back to the idle animation when it's on frame 1 out of 10). It's also an incredibly time consuming task to set up all of the clips, states, and transitions.

    Semi-related, I feel like I would prefer a behaviour tree structure rather than Mecanim's simple state machine structure. That might make the transition setup more manageable.

    How do you spend most of your time working with our 2D features? Anything bogging you down?
    My games include a tonne of frame-by-frame animations, and I spend far too much time fiddling with things in Mecanim. It's tedious.

    When you learned to use our 2D system, what stumped you or had a steep learning curve?
    The animation workflow.

    Sorry for all of the Mecanim complaints :) I'm sure it's lovely for 3D content! :)
     
  14. hugosslade

    hugosslade

    Joined:
    Mar 24, 2013
    Posts:
    10
    Who are you?
    Games developer at Glitche.rs

    What kind of game are you trying to build or would like to build?
    Top-down and side on 2d / 3d with 2d elements.

    How does 2D fit into that? What use-cases do you have?
    I use 2d for the bulk of the visuals, with 3d elements mixed in

    What are the GOOD things about the current 2D system you like?
    Very easy to setup, similar APIs as 3d system for the Physics

    What are the BAD things about the current 2D system you dislike?
    There's a lot missing from the 2d Physics in unity, most importantly for me there is no IgnoreCollision in 2d, but there is in 3d.

    Also if it could be set which axis the world uses for 2d, now it's X,Y. If you could set the output axis to be X/Z but still use XY internally that would be great.

    How can we make it BETTER?
    See above.

    Do you like the Mecanim workflow for animation?
    Not used it, most animation is done with a few pieces that move by code.

    How do you spend most of your time working with our 2D features? Anything bogging you down?
    Mostly Physics2D and Sprites. Bogging me down is working around the limited Physics2D

    When you learned to use our 2D system, what stumped you or had a steep learning curve?
    It was a breeze from 3d to 2d, just add 2D on the end of the components and check the documentation for the rest
     
  15. 4notion

    4notion

    Joined:
    Apr 8, 2013
    Posts:
    1
    I'm a designer/artist in a small indie team. It's just the two of us really, and we've been working with Unity about 2 years now. I'm speaking for both of us here.
    We're mainly interested in creating 2D games for the time being as we're interested in creating cinematic adventures/platformers, and mobile games. Our experience with 2D unity has been mostly positive, we were really hyped to see Unity go in this direction. Our prior experience with 2D games boils down to Flash alone.

    A couple of things we miss / dislike in the current setup is: Tiling of sprites (this is one of the more important things to us), a 2D character controller, a particle system native to 2D (or at the very least, the ability to sort particles through sorting layers without hacking).

    The Mechanim system is very confusing. It's very powerful but is not always apparent how to proceed with things, how to organize parents/children objects... and flipping animations often produces errors (seemingly randomly).

    One pet peevee for me is having polygon colliders being applied automatically when I just want to get a basic pentagon to work with and customize it. So I'm either forced to create another empty game object for the collider or delete a ton of vertices (and end up with a ton of irremovable holes).
     
  16. RobinBrouwer

    RobinBrouwer

    Joined:
    Dec 9, 2013
    Posts:
    114
    Who are you?
    I started a small business with my brother called Battle Brothers. He's responsible for the art and I'm the one who puts everything together in Unity. We just started, so we're quite new to the whole game development scene. But we're liking it so far! At my current job I'm the technical lead at a web development agency, where I lead a team of Ruby on Rails developers. So game development is a part time thing at the moment, but we're trying to make it our primary job.

    What kind of game are you trying to build or would like to build?
    We want to focus on 2D games and build games designed around multiple players, co-op preferably (both top-down and side-scrolling). As brothers who like to game together when we're visiting each other, we see there aren't many games geared towards us anymore. So we want to build them ourselves. ;)

    We're currently learning how to develop games and I'm primarily focused on Unity. While learning Unity's 2D features, I created an asset called Acrocatic (http://battlebrothers.io/acrocatic/). It allows you to easily customise your own 2D platformer character. At the moment, we're busy updating that asset to version 1.1. We're loving all the positive reactions and feedback we're getting! Great community. :)

    How does 2D fit into that? What use-cases do you have?
    We're quite inexperienced in the gaming scene, so we figured that we should first get to grips with 2D. So that's why we're focussing on 2D at the moment.

    What are the GOOD things about the current 2D system you like?
    I really like how easy it is to slice sprite sheets and put them into your scene. Also love all the 2D specific features in C#. I've tried several 2D game engines, but I like Unity the most. Being able to publish to a lot of different platforms is also very welcome. Also love the stuff you've announced for multiplayer games. We're definitely keeping an eye on that!

    What are the BAD things about the current 2D system you dislike?
    I don't really like the level editor for 2D games. Viewing the scene, dragging objects and scaling objects isn't really intuitive for a 2D scene. It's more geared towards a 3D scene. I think that it would be better if there was a different 2D view with other controls.
    Also: snapping. You can snap things, but there isn't really a grid or something like that.
    It takes quite some time if you want to create a 2D level using prefabs. I like how Stencyl does this: select an objects and just hold down the mouse button on the grid to place multiple instances of that object. And it's all perfectly aligned because of the grid.
    It's a bit of a drag to change sprites in code. I haven't really found a nice and efficient way to change the sprite to something else in the Asset folder. If there is: I would love to know!

    How can we make it BETTER?
    Fixing the things listed above. ;)
    The animation system is quite complex for 2D games. I think it could be dumbed down a bit by default for 2D projects (but you can keep the advanced settings for the people who like it this way).
    Easy way to use tile sets.
    Make setting backgrounds and adding parallax backgrounds a bit easier.
    2D in Unity seems to be more aimed to side-scrollers at the moment. I would love to see how top-down would work (with the right kind of layering like in 2D Zelda games). The Unity live training session from Mike helped a lot, but I believe it needs a bit more attention.

    I really LOVE Unity's 2D features. I hope my feedback will help you make it even better! Good luck. :)
     
  17. imaginaryhuman

    imaginaryhuman

    Joined:
    Mar 21, 2010
    Posts:
    5,705
    About me:

    I focus almost exclusively on 2D game development. I come from a totally 2D background with the likes of Blitz Max - a primarily 2D game-development language which has no 'editor' or wysiwyg tools, and so am used to having to 'do it yourself' to make engines or particle systems or tilemaps etc. I've also seen Torque2D and a few others which attempt to remove some of the programming needs. I am a solo indie developer with little budget. I mostly experiment with out-of-the-box approaches to 2D, but have a strong awareness of the history of 2D game technologies and approaches dating back to the early 90's. When working in 2D I generally am only working in 2D and not 3D, so anything 3D-like or which is there to 'also support 3D' tends to be noise that gets in the way.

    About Unity:

    The current 2D system is pretty good in terms of an optimized shader, asset import, atlases, some 2D physics stuff. But this is of course only the start. In my opinion mecanim is not in any way suitable for 2D game development. That it even needs some explaining goes to show you that it is not intuitive and is not easy to use. I expect many 2D developers are much more toward the beginner's end of experience level, and things like putting together these funky charts which don't seem to really represent what things actually LOOK LIKE in the game, makes it too far removed from intuition to be given the time of day. Whatever happened to immediate feedback, simple wysiwyg editing? I understand there are a number of elements to game like setting up the atlases and gameobjects and scripts and materials and sound and all that, but these things all seem so 'separated out' into their own windows and interfaces, rather than much more immediately represented within the view of the game. I know the scene view is meant to cater to this, but honestly the separation between how the scene view looks and how the game view looks is the first mistake, and the separation between the scene view/game view and the runtime experience is another mistake. What I want is to be able to be in 'game time', at a given point in a game, wherever that may be in the level, and be able to tweak any part of it right there any then. This could include changing graphics, moving objects around, changing colliders, setting movement paths, painting tilemaps, etc.. What I want is much more of an artist's workflow where the game is 'painted live'. Unity is big and bulky and this forces all kinds of separations that hinder the intuitiveness of immediate feedback and in-game editing.

    I am not sure what can be done differently with regards to mecanim. State machines seem to be a hot topic but surely there is a more intuitive way to like fast-forward/rewind 'time' within the game view... something more along the lines of smoothmoves or something, where you can just 'visually' adjust things instead of all these extra boxes and lines which really make no sense and are hard to relate to. SHOW ME WHAT IT LOOKS LIKE!

    In terms of performance, one part of the 2D-engine puzzle is the transfer of texture data to the graphics card, plus the ability to modify texture data efficiently. This is currently not done well at all in Unity, at least not in Unity Free, and even in Pro it is much slower than it should be. There are many different 2D techniques which rely on this. For example, destructible landscape games (scorched earth, worms etc), games that allow you to paint in 2D (draw to texture etc), games that allow you to spool SMALL texture changes to a part of a larger texture etc. At the moment there are three main problems. Storage of a texture as Color32 is okay, although Alpha8 is stored as a float (what?). Where is a simple 1-byte format? Secondly, to get that texture data (modified by the cpu) into the graphics card you have to a) setpixels, even if not for the whole texture, b) upload the ENTIRE texture. This is bad. Anything bigger than maybe a 256 or 512 texture cannot be uploaded every frame with modifications at 60hz. On other platforms, for example in BlitzMax with basic OpenGL code, you can do like glTexSubImage2D() call to upload only a smaller portion of a texture into an existing texture, which is optimal for speed, AND the transfer goes directly from main memory to the texture. In my speed tests, Blitz runs several times faster than Unity at this simple operation. It could process a few 1024 textures per frame, fully updated, at 60hz, while Unity was dragging along at barely 1 512 texture at 60hz. What gives? It seems Unity tries to maintain its own internal memory copy of a texture which it has to transfer/convert the data to, then upload, which is silly. I know it's a kind of cache, but we need to bypass that cache to stream uploads faster. When I say 'upload this rect to the texture', which btw should also support cutting a small part of an image from a bigger image in main memory (e.g. use a byte array with a row skip value and row length), it should then zap just that data into a possible larger texture in video ram with no other processing taking place. It can be so much faster than it is now.

    The final part of this mess is rendertextures. OpenGL since like version 1 or so - over 10 years ago - has had support for rendering to a texture. It is currently a Pro-only feature, and understandably if Unity were to provide this in Unity Free it would open up some asset-store assets that substitute for missing Pro features.. e.g. shadows, screen effects, etc. But even for just 2D, being able to render to a texture opens up a tonne more game opportunities. Destructible environments, painting, textures processed by shaders, post-processing, etc. Even if you limit it to like 1 or 2 render textures per project or something that would be so much better than nothing. I really think Unity Free should have at least some kind of rendertexture support. GrabPixels or whatever is far too slow especially on mobile devices. On my Ouya for example, grabbing the screen can only run at like 20fps, all by itself, and yet rendering to a texture and re-rendering that texture can run at 30-60fps. So it would boost speed in a lot of 2D games, bypassing the extra transfer of graphics data.

    I think Unity definitely needs some way to do tile maps better.. it's okay to think of using lots of sprites aligned to a grid etc but there are more efficient ways to optimize for a grid. Also it must support animated tiles. And again, animation in general is just not obvious or intuitive in Unity. Some of the 2D tools have made it a bit easier to put together sets of frames etc with delays and whatever. Also Unity seems to already have hierarchical objects, which means joints, which means 'bones', so why isn't it more obvious how you can use this to set up joint animations, with IK and so on? This all needs to be much more visual and much less button-clicky.

    What's the difference between a sprite and a particle? A sprite with an AI script attached is basically a particle. I've always thought these two things are basically the same. Not sure what I'm saying here.. combine them? But how about being able to attach scripts to particles to treat them like they are mass-sprite systems, with 2d physics etc?

    It would help to be able to save images more easily from Unity.. save in png, jpeg, bmp formats. Also please provide LZMA compression library from scripts. Unity already uses it (e.g in webplayer). I want to be able to compress generic data (e.g. byte arrays, which may later represent procedural graphics).

    Unity needs to have some kind of high-speed, adjustable, properly antialiased, fully editable vector graphics. By vector graphics I basically mean, shapes, which can be composed from triangles. I know a triangle is just a basic unit of graphics rendering and Unity already has triangle meshes, and triangles can be used to build more sophisticated shapes e.g. filled beziers, ellipses, rectangles etc.. take RageSpline for example, it does much of this, but also it has things missing, not to mention some performance issues. It's hard to get the antialiasing right when objects scale, it uses a lot of polygons, and all of those polygons get SAVED into the project taking up a lot of room, instead of simply storing the graphics primitives e.g. 'draw a circle at 50,50 with 25 radius in red' opcodes, which would be far smaller, faster to download, and can be turned into meshes at runtime. There are also shaders you can use to draw some geometric objects such as circles, with a single quad. I think this should be highly optimized and integrated into Unity for maximum performance and optimization. This would open up a tonne of additional 2D game opportunities - being able to 'draw polygons' as the primary artistic medium, etc. Also don't forget about vertex animation.

    A game-length timeline would be great, above and beyond animation clips.

    I think you need to build in some kind of easy support for parallax... many 2D games use this technique maybe as a visual style nowadays but when you're not doing 3D you want to be able to simply create the illusion of different distances moving at different speeds, tied to a single scroll position.

    I would like there to also be some kind of standardized plug-in control systems... e.g. character controller for Sonic, character controller for megaman, etc.. platformer, shootemup ship, etc.. these should be easy to just choose/plugin and customize in some visual sort of way, instead of having to make mecanim trees or behavior trees or scripts or whatever... easily interact with the environment without having to worry about collisions and physics and all this stuff. Just plug it in, skin it, done.

    Also in terms of scripting, IF it is necessary, for a 2D game and for beginners it would help to have a BASIC-derived scripting language with very simple english-like non-syntaxy language, no brackets or semi-colons or case-sensitivity etc. BlitzMax makes it so much easier to write game code. Take a leaf! Get rid of Boo and use something more like this instead.

    The only other thing that comes to mind is lighting. 2D lighting. That means additional shaders for normal mapping at the very least, if not more sophisticated shaders. Shadows with automatic occluder calculations. Turning 2d images into 3d-lightable images (height maps?).

    Oh, and easy isometric games.
     
    Last edited: May 26, 2014
    rakkarage likes this.
  18. tonycoculuzzi

    tonycoculuzzi

    Joined:
    Jun 2, 2011
    Posts:
    261
    Who are you?
    Freelance and indie game developer. Previously a full time web/mobile game developer, and Unity advocate.

    What kind of game are you trying to build or would like to build?
    I like taking Unity in any direction I can, but right now I've been working on a 2D adventure game where I've run into many issues with Unity's current 2D implementation.

    How does 2D fit into that? What use-cases do you have?
    I'm using 2D for the sprites, and 3D for the environment. The entities only move along one axis (X and Z, when it should be X and Y), so the 2D physics could have played a big part in it, but don't because I needed to use the NavMesh system.

    What are the GOOD things about the current 2D system you like?
    • Setting up sprites is easy
    • Non-sprite-based animations are easy too (joint/rotation animations)
    • It's a great start to what could be an awesome system
    What are the BAD things about the current 2D system you dislike?
    • True, pixel perfect 2D is complicate, convoluted, and near impossible without major tweaks and workarounds. Even then, it's still not true 2D, with pixel crawling and filtering. This is a major issue for 2D game developers.
    • No NavMesh support for X Y. This is a huge issue for me, and caused me to abandon using the 2D physics system altogether while working on my 2D adventure game.
    • Sprite animations are a major pain in the ass. Mecanim makes it infinitely more complicated than it needs to be.
    • No support for tiling, or auto-tiling. (Think RPG Maker) This would be a huge boon, but understandably unnecessary because it would be limiting.
    How can we make it BETTER?
    I would suggest adding either NavMesh support for X and Y, or a new NavMesh2D system altogether. Also, I'd suggest making sprite animations a lot easier. More like the direction of the old animation system, instead of using Mecanim. A state-machine-based animation system for sprites is overkill and a huge deterrent.

    In my opinion, this is a great start for the system, but if you're doing 2D, you should support a fully 2D mode as well. Literal screen-space 2D, pixel perfect, etc. The thing that deters users from using 2D (from what I've heard at least) is that it's not true 2D. Doing a pixel-perfect sprite-based game in Unity is nearly impossible, and quite inefficient. If you provided a 2D canvas, as well as a 3D canvas, this could bridge the gap and make the entire 2D development experience desirable for people coming to Unity from other 2D engines.

    Think Flash's 2D layer on top of their 3D canvas. Just a thought. This would also really help with your GUI system that you guys have had so much issues in creating. You already somewhat support this with your current GUI system, but there is no canvas for it. Providing another scene view for just 2D would be an incredibly useful feature.

    And specifically to the 2D system...

    Do you like the Mecanim workflow for animation?
    No, I hate it. I feel bad saying it, but it is the absolute worst part of Unity's 2D system.

    How do you spend most of your time working with our 2D features? Anything bogging you down?
    Having to tailor it around the X,Z plane because of the NavMesh not supporting X,Y has been a big issue, but it was fairly easy to work around. That said, this completely breaks the 2D physics.

    When you learned to use our 2D system, what stumped you or had a steep learning curve?
    Animations, honestly. It's not overly intuitive, and very daunting when you haven't worked with it before.


    I hope this helps provide some insight! Feel free to contact me through email if you have any questions! And thanks for taking the time to ask us our opinions on the subject. :)
     
    Last edited: May 26, 2014
  19. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    26,899
    Simian Squared, purveyor of fine quirky entertainment.

    2.5D for consoles.

    Sprites are still used.
    Billboards are used.
    Animated fx, explosions.
    UI stuff.

    Can use animation events.
    Can trim out empty space.

    - Rubbish atlas workflow
    - Horrid integration with Animation, requires a clip for everything. Would prefer collections in a central database. Tired of animation clip management.
    - Mecanim. Why? Why add workflow steps?
    - Can't just swap a sprite on the same gameobject and use the same code. Can with 2D toolkit. For example 3 enemies, all same animation names, but different collection.
    - Animation timing is a chore. I have to use Constant, or I find I can't make weapon/hat attachments stay in sync. Attach point system weak, have to use hierarchical animation.
    - When animating with constant, need to double last frame or timing is off (!)
    - Feels forced into the existing system rather than designed with it's own system. This forcing stuff to fit is all well and good, but I'm not sure it's right.

    - Copy 2D toolkit. It does everything right.
    - give us a way to spew out thousands of the same thing - think shuriken or such. Bullet hell. Loads of explosions. That sort of thing. Do they need to be gameobects? perhaps a SpriteList[] of such. Loads of stuff going on.
     
  20. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    7,411
    I don't think it's possible to agree with these two points more. These were my primary hurdles when working with the new 2D system.
     
    calmcarrots likes this.
  21. TheLastHylian

    TheLastHylian

    Joined:
    Jan 10, 2013
    Posts:
    10
    I've worked with Unity for 2-3 years, I'm a student right now but plan to start a game company after graduation.


    I love the whole 2D system. That being said there are 2 major issues that I have. One you are using the Box2D framework for the 2D Physics, this is all well and good, but wee need access to the minimum collision detection velocities and angles. Right now not having access to them makes "ball" games difficult to make since sometime the velocity or the angle will not trigger a response and the ball will get stuck on an object or wall. Yes we can code around that but that's not the point. Two, you give us all the tools we need to make our own 2D pathfinding with the Polygoncollider2D's shapecount, we just need access to those shapes, or regions as you call them in your documentation. with that we could make our own NavMeshes simply in 2D.
     
  22. Yukichu

    Yukichu

    Joined:
    Apr 2, 2013
    Posts:
    420
    Who are you?
    Just some guy trying to make a sweet game.

    What kind of game are you trying to build or would like to build?
    2.5D bullet-hell MMO RPG shooter

    How does 2D fit into that? What use-cases do you have?
    It just does

    What are the GOOD things about the current 2D system you like?
    I don't know because I've refused to use it. I purchased 2DToolKit and have no need to use anything differently. I have yet to read of any reason to use the built-in system.

    What are the BAD things about the current 2D system you dislike?
    It seems limited in what it does compared to commercial product.

    How can we make it BETTER?
    Prettymuch what Hippocoder said.
     
  23. seitor

    seitor

    Joined:
    Feb 18, 2012
    Posts:
    36
    Who are you?
    Programmer, part time Unity freelancer

    What kind of game are you trying to build or would like to build?
    Side-scrolling games , platform games, bullet hell

    How does 2D fit into that? What use-cases do you have?
    I use 2dtoolkit. I have no reason to leave it unless unity 2d match its features

    What are the GOOD things about the current 2D system you like?
    See above

    What are the BAD things about the current 2D system you dislike?
    1)Multiple resolution asset solution, 2dtoolkit make it a non issue.
    2)Physic performance
    3) Shuriken

    How can we make it BETTER?
    To be honest, I can develop whatever 2d games I want with Unity 4.x , what move me away from UT is its price.
     
  24. jellybit

    jellybit

    Joined:
    Nov 21, 2009
    Posts:
    32
    I'm a developer who worked as a professional game designer for years, and is now going indie.
    I do a lot of 2D platforming, but I also make puzzle games, simulations, and other types of action games.
    I think 2D offers better usability for platformer games than 3D. I like to follow the lessons laid down by designers in the late 80s and early 90s.
    It's really easy to get art in there and running. I was happy that was as smooth as it is. Great atlas packing. I also like the Unity workflow, being able to drag scripts onto objects and build functionality quickly. A joy to prototype in.
    By far, the worst thing is that everything about your system assumes that we want to make physics-based games. I love developing platformers, but I do not really like to make physics-platformers. I like puzzle games, bu I don't necessarily want things to move with physics. Many of the old design approaches required careful control of movement and collision. While the physics make it super easy to start prototyping, I'd want to skip physics if I wanted to actually polish a game and finish it. I also would like the engine to be more pixel-art friendly. It's a very widely used art approach with a rich history, and any decent 2D engine should acknowledge that substantially. This pixel art should be aligned, and maybe should support a lower internal resolution. Also, PLEASE add "ignorecollision" to the 2D collision engine. Egads.
    Give us straight up collision checks without making us feel like we're hacking around a physics system. In other 2D engines, you can merely do collision checks for specific objects, and all you had to worry about was whether the objects had colliders. That was it. The end. No worrying about kinematic/non-kinematic, rigidbodies, mass, raycasts for movement, etc... Just move stuff and collisions happen. Also, we need to make it easier to build levels using tiles, and make this CPU efficient when doing collision checks. Again, some other 2D engines treat tiles differently and collision is simplified. Read any article about platformer design principles in 8 and 16 bit platformers, then sit down and try to make that game in your engine without physics, a requirement for the amount of control necessary for that kind of polish. You have to do some crazy amount of raycasts to pull off what should be far far simpler in a 2D engine. Also take a look at the UbiArt Framework videos. It looks magnificent.
    It's fairly nice. I like it ok. Better than I expected for a first try. I kinda miss just calling an animation, but I think I could learn to like Mecanim.
    I spend most of my time working around your physics engine. It can be done, but it feels like an elaborate hack when all objects should be able to check for collisions against each other easily without having to move using physics. I think it should be far easier to adjust animation speeds in specific states. Also, box collisions should be in the same place we deal with animations. Animation and collision are very closely related in 2D games.
    Collisions collisions collisions. If I'm using your physics engine to make a physics platformer, it's easy and obvious. Otherwise, it's a huge pain.
     
    Last edited: May 27, 2014
  25. TomasJ

    TomasJ

    Joined:
    Sep 26, 2010
    Posts:
    256
    Hi all,

    We've formed a focus group to iterate on 2D features with the following main targets:
    * Navigation/AI solution for 2D
    * Shuriken particle system features for 2D.
    * Animation system improvements to make simple use cases simple and to provide ways to reskin a bone-animated Sprite character.
    * SD/HD solution (we're designing this for everything, not just 2D)
    (Random smaller targets not mentioned)

    When these things will be done and in what order is yet unknown, but we're totally going to use all of your feedback to give you the best 2D development environment we can.


    Going to answer all the questions now, excluding the 4 topics above:
    @the_motionblur: we're planning to have more math functions for 2D use cases. As for constructs - that's not a bad idea. Our current approach is shipping tutorials users can pull code out of. Also what did you mean by pixel lights?
    @Neurological: I assume you meant write access to Sprite meshes. There's a few reasons why we don't want to do that but many people are asking for it. Maybe there's a reason behind it? Why exactly is write access useful? UV scrolling can be done in a vertex shader.
    @rootools: vector rendering is not currently in our scope, but we did have successful experiments with it.
    @soulburner: the use case of dual texture atlases is known and we have it on the roadmap. As for links - what do you mean exactly? Everything in Unity is an object reference.
    @DSSiege11: there's a pivot value for every Sprite. Changing the height should not offset anything. Either we overlooked a very specific use case or you haven't found out how to change pivot. If you think this is a Unity bug, drop us a repro case please! As for pixel perfect problems, they should be all gone in 4.5 (shipping shortly). We had some nasty floating point precision errors.
    @DominoK: is Sprite.Create API too limiting for you? What can be added?
    @Grafos: 2d colliders should work fine in 3d scenes setup for paralax. Post your problems on the forum, we'll look into them.
    @funshark: it's a good idea to always show camera bounds and colliders. We'll look into that. As for rayman - watch the vid. Fancy engine. Very much tailored for platformers hence we can't just aim at that immediately and abandon other use cases. But know that we're inspired :)
    @Ferazel: SpritePacker policy scripts let you define any logic for packing. You can override the formats if you wish. The design we chose allowed us to produce identical visual results when compared to non-atlassed output. Maybe a filter to grab all sprites of a single atlas would be a good idea. Then you could filter the hierarchy and change properties to all importers? As for tight packing algorithm - trying to improve it to the point where custom meshes are not needed anymore. Obviously for simple geometric shapes this is almost impossible to do. As to why your sprites are rendered after 3D geometry, it's because the default material is transparent and goes into the 2nd pass. Use a simple diffuse material and it should work.
    @bryantdrewjones: indeed currently flipping a sprite is done via a transform scale. If you don't want to flip the collider, you can put it on a sibling GO. Workaround for now. We have a prototype implementation for flipping so it will be available at some point (sounds simple, but has a number of dependencies behind the scenes).
    @hugosslade: ignorecollision is in 4.5 (releasing shortly). What else is missing that you need?
    @4notion: tiling is a wide concept with many possible implementations. I promise to start a new thread and discuss it with everyone.
    @imaginaryhuman: wow that's a lot of features. Gonna takes us ages to do all of them. Ignoring the Free/Pro split (which I can't really comment on right now, but which is a constant discussion internally), could you maybe select 2 or 3 highest priority things for you? I've shipped a destructible-terrain game myself and had to slice it and update pixels of those slices, so the pain in shared.
    @Tonzie - having a pixel-perfect scene view is possible, however that provides a lot of drawbacks as well (various devices). Is the current approach of setting camera ortho size appropriately not working for you? Is it because the coordinate system is not in pixels?
    @hippocoder - Why in your opinion is the sprite atlas workflow rubbish?
    @TheLastHylian - the velocities and angles you're talking about aren't available in Box2D, however we did expose many Box2D constants in 4.5. Maybe something will help you.
    @Yukichu - what commercial project?

    In general there's a very clear pattern in your feedback about what is wrong. Thanks!
     
    rakkarage likes this.
  26. PerrinAshcroft

    PerrinAshcroft

    Joined:
    Dec 29, 2012
    Posts:
    6
    Richard Perrin director of Locked Door Puzzle. We made Kairo and Journal, and are currently remaking an older game called the white chamber in Unity.

    Our games are primarily adventure titles for Steam and consoles

    This has varied from project to project. Kairo was fully 3D and so we only used 2D for GUI work, Journal was a mix of 3D and 2D using a 2D scene run through a render texture. the white chamber is fully 2D and is done using your new 2D system.

    Getting sprites imported and into the scene and displaying properly is really simple. Excluding animations the workflow is pretty fast and clean so I'm happy about that.

    The way the layering system is not really compatible with 3D elements has caused me problems working with things such as 3D Text or particle effects. And although I'm sure you have plans to improve text and particle support in 2D the problem is still there that the 3D and 2D systems sorting engine working against each other is always going to create problems. I like how easy the layering on 2D stuff makes 2D projects but there has to be some way to make that work seamlessly with the 3D engine.

    Creating animations feels like a hack right now. Dragging the frames into a scene or keyframing in the animation tool. It feels much more like you've shoehorned the process into the tools you already have. I think a 2D animation clip making tool is needed. Something less convoluted. Really what I want to do when making a 2D animation clip is drag in a bunch of a frames, re-order them and set the length of time for each frame. Maybe add more frames in later too. Right now it's really messy doing this.

    I've seen other people complaining about NavMesh not working for 2D, personally I don't want NavMesh made compatible as that's really designed around a 3D workflow. I'd rather some kind of polygon based navigation system was added. There's one in the store I've been using instead at the moment.


    I don't hate the use of Mecanim as a whole. I know a lot of people complain that at a beginner level it's needlessly complication but I think this is the exact same problem with Mecanim in 3D. Problem is at a higher level having state machines for animation is actually really helpful, so completely removing it to appease beginners would be a loss for my projects. Personally I think if it was easier to actually make animations (as I've described above) and there was some way for beginners to largely ignore the Mecanim system I think that would be the best of both worlds. (btw I think having the ability to override the default animation for a Mecanim animator in the inspector would make beginners able to ignore the system a lot easier in both 2D and 3D)

    To be a broken record it was the animation creation and making 2D and 3D elements compatible that have taken the most time and caused me the most trouble.
     
  27. soldmeadow

    soldmeadow

    Joined:
    Jun 23, 2011
    Posts:
    42
    Yes, b2_velocityThreshold = 0 will stop balls sticking to walls. Exposing all those constants in 4.5 is going to be a big help.
     
  28. keely

    keely

    Joined:
    Sep 9, 2010
    Posts:
    966
    Thanks for the feedback!

    Isn't this exactly what the current implementation of Animation Window does?
    Can you be more specific on where the pain is at?
     
  29. keely

    keely

    Joined:
    Sep 9, 2010
    Posts:
    966
    Thanks for the feedback!

    The way I see it, any animation system needs the concept of a clip. When you say "central database", I'm not quite sure I follow.

    Do you mostly feel like the problem is that you can't re-use existing clips smartly and need to always create new ones? I would love to hear a horror story of "clip management". I want to feel your pain.
     
  30. the_motionblur

    the_motionblur

    Joined:
    Mar 4, 2008
    Posts:
    1,738
    Yes - this is very much appreciated. Somehow I still think it yould be better to have generic functional assets to import.
    Maybe something along the lines of: "If you want to follow this tutorial - here are the sprites and music. Now create a new 2D template with [top down shooter, jump and run, isometric RPG...] functions. Now we are (separately) loading the arts and music files into it..."
    Sort of like the standard assets importer for various functions. I know that it's possible to import functional blocks from various projects. I do this all the time when I am prototyping art for a project I don't have access to. Sometimes these building blocks have a very weird way of interacting with each other, though. Sometimes as a user you don't know what is needed to import so that the examples work because the code interactis with way more things than you can see on import. Other times you just don't want to download 3 different projects just to cherry pick single functions from them - often even only functional code for which you would not need to download the whole project files.

    I really do like the complete projects you provide and I regularly look at all the new ones becaus it's a good learning ressource. But for a quick protoype or even just an easy-game for fun I find it rather long winded. And as mentioned - if there are interoperating scripts where not everything importet on a selected function then the console spits out warnings - sometimes a LOT of them. When I am looking for functions quickly get something running this can be frustrating because it distracts from what I initially wanted to do.

    So far I tried picking out functions from projects and made my own unitypacke for quick import. Only to find out later that while it seemes it would work there were actually some files missing. I think you know what I mean ...

    A weird phrased way of saying: A shader that interacts with lights. In my mind I was thinking about a pixel-shader but it came out as pixel light. :D

    Though I found that in conjunction with a particle shader and transparency 'sort-of' light sources can be faked and look pretty solid without the performance impact actual real lights might have. I'm thinging about an alpha image/light cookie thing - like the flashlight - that is then used to brighten and colorize the environment instead of an actual light source. That's a different thing, though.
     
    Last edited: May 27, 2014
  31. Deleted User

    Deleted User

    Guest

    I think he is pointing at just that, the spamming of clip needs. For example you got a 16x16 pixels sprite with an animation cycle that is made out of the same rect size, then you got another sprite that is from another atlas and should be animated the same way, with same rects and size, but you have to make another clip for that other sprite.

    Now think it with a simpel quad with a meshrenderer, you got one atlas and modify the uv to animate and can reuse the same cycle for everything else. This is also the answer TomasJ, my suggestion to be able to modify sprite renderer mesh info is mostly to bypass the use of animation clips. Sure I can forgot about mecanim then, but I'd prefer.
     
    rakkarage likes this.
  32. imaginaryhuman

    imaginaryhuman

    Joined:
    Mar 21, 2010
    Posts:
    5,705
    1) RenderTextures in Unity Free. Even just 1 full-sized render texture opens up a lot of options.
    2) Much faster upload of texture data to the GPU - ie
    a) mark a texture as used for constant streaming, so it bypasses any internal cache and just zaps a window of main memory pixel data (which may be only part of a bytearray and not have to be an entire array) to the gpu for fast per-frame updates, and
    b) add support for only having to upload a small part of a texture, not the entire texture. ie see glTexSubImage2D()
    3) Easier animation
     
  33. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    7,639
    Could you add a breakable feature to the 2D Joints. e.g. Tick box and breaking force limit.
     
  34. funshark

    funshark

    Joined:
    Mar 24, 2009
    Posts:
    225
    Not sure to understand your point since I can create one single animation clip and apply it on any object/sprite ?
     
  35. funshark

    funshark

    Joined:
    Mar 24, 2009
    Posts:
    225
    It is indeed good for many things, but not for skeletal animations afaik
     
  36. goat

    goat

    Joined:
    Aug 24, 2009
    Posts:
    5,180
    Maybe Unity can develop an art server to address Hippo's concern. Any art assets can be tagged descriptively and whether or not to archive them in a separate database: the SW that manages that dB would be a 'local Asset Store Kiosk'.

    A bit like DAZ Studio's Library interface although the search function on that is not great and because they've changed the format so much over the years it seems somewhat inconveniently organized. Example: You buy a character in DAZ Studio and clothing for the character and poses for the character and textures for the character and textures for the clothing and all those things are in logically dB Sections called: Characters, Posers, Accessories and so on but you can't put the dB in 'Character' mode when all those things that are associated show up on, e.g. 'Sailor Moon''s page.

    So basically create SW that allow one to create a local mini-Asset Store from their past works and if it so happens they decide to sell or given away assets they've create in the past then they can publish from their 'local Asset Store Kiosk' to the Unity Asset Store Kiosk.
     
    Last edited: May 27, 2014
  37. ViNull

    ViNull

    Joined:
    Apr 14, 2013
    Posts:
    6
    I've just read over the 4.5 release notes - the biggest issue that still remains for me is no support tile-based games.

    Allowing a single Spriterenderer to have a list of sprites would be a start. The problem in the current system is each sprite is an object on the GC and even just a single screen worth of tiles done this way is enough to bring things to a crawl. If you create a custom mesh you solve the performance problem, but are now in the world of 3D physics, which doesn't interact with the 2D physics system.

    Prior to Unity I worked in XNA and created a Tiled (TMX) map importer. I would like to bring this to Unity (and have started), but there is a lot that has to be left behind currently. An example is source tile properties - in XNA is was easy to look up custom properties of a place tile via it's link to the source tile (sprite) on the tilesheet. I've yet to come up with an "elegant" way to do this in Unity.

    I also didn't see if http://feedback.unity3d.com/suggestions/get-original-width-and-height-of was addressed. Making TextureImporter.GetWidthAndHeight public is a small code change, but very much needed.

    I'm glad to see the Box2D constant exposed, and hopefully fixes the problems I had with "pixel perfect" collision and rendering http://issuetracker.unity3d.com/iss...loating-point-number-for-position-slash-scale

    To address some of your other questions, I have used the Mecanim, though I'm far from really understanding it (it seems complicated for the simple cases). I've just made some scripts to get the animations I want, but given I am a developer I have that bias =) For the complicated stuff we tend to favor Spine (http://esotericsoftware.com/).

    RenderTextures and Sprite Packing seem to be odd "Pro only" choices. You have full rights to decide what is Pro and Free of course, and I fully support that. I just can't see many studios looking at those as the reason to go pro.

    Mike
     
    rakkarage likes this.
  38. Uttpd

    Uttpd

    Joined:
    Feb 27, 2010
    Posts:
    114
    I´v manage to build prototypes with 2dTollkit and Playmaker. At present I dont see much value in Unity2d over a plug-in like the mention, then again i´m only a n.. light user so i´ll describe "my" base 2d solution..
    The overall Idea is to be able to build the app visually on the go in the editor, no prior preparation.

    set in project/ editor properties:
    Define XY or Z or choose Side scrolling or Top Down
    Define units and define pixel size; exp. define meter as the unit, and say 1mt = 100pixels
    Define Grid; define size, toggle snap, toggle visibility
    those should not be buried in the menus.

    in editor window:
    Show my target resolution/ camera dimension overlay on the window, mark the 8 positions + center (toggle visibility) left up corner, middle up etc and let me hook any object to this overlay i.e. attaching sprites, Hud elements, to the corner, middle etc (or at list let me chose those hooks in the individual sprites properties)

    Editor tools,
    Draw primitive shapes, rectangle and circle; define line with or no line, pick solid color fill, pick opacity/ transparency --> allowing to build my sprites on the editor. (look at CAD applications or Sketshup)
    Allow Snap to Corners and intersections for positioning
    Pick/ change Font from list and allow to make a sprite of it, "rasterize"

    With those tools i can build any prototype and level, without having to import any art. If Unity then builds an atlas from my "made in editor sprites" I can export it and use as template in my art tool to actually draw the sprites and re-import replacing my squares by the final art.
     
  39. AndrewGrayGames

    AndrewGrayGames

    Joined:
    Nov 19, 2009
    Posts:
    3,823
    For my JRPG project, I've been experimenting with a pure-2D approach, using the 2D framework. I also notice the question on using Mecanim for animation. Back in The Hero's Journey, I wrote my own animation system. I would like to experiment with Mecanim, though - what are some good resources for learning Mecanim?
     
  40. firebelly

    firebelly

    Joined:
    Apr 22, 2013
    Posts:
    12
    Super newbie here, so my perspective is someone who is very skilled in simple 2D engines like Construct2 and Game Maker: Studio. I also have some XNA background, back is just starting Unity.

    What kind of game are you trying to build or would like to build?
    2D Pixel Art platformer and side scrolling shooter.
    How does 2D fit into that? What use-cases do you have?
    This game is pure 2D not 2.5. So it fits perfectly into the engine.
    What are the GOOD things about the current 2D system you like?
    I like that you can use components easily.
    Easy to set up collisions
    I can add scripts easily in my native language (C#)

    What are the BAD things about the current 2D system you dislike?
    Sorting Layers, it's hard to get to, it should be something that is 1 click away.
    Dealing with sprite animations is a little bit of a hassle. I would like to see an easier importing/animating process for sprites as animations. The current system is geared more towards 3D / parts of a sprites
    More Tiled/Tile sheet support. I would like to see more features for creating scenes with tiles.
    Support for more 2D centric objects. Tiled/Repeating BGs from sprites.

    How can we make it BETTER?
    See Above

    And specifically to the 2D system...
    Do you like the Mecanim workflow for animation?
    Still learning
    How do you spend most of your time working with our 2D features? Anything bogging you down?
    Understanding some of the 3D aspects of making the game, translated to 2D

    When you learned to use our 2D system, what stumped you or had a steep learning curve?
    Understanding how to use components
    Learning about 3D objects used as 2D
     
    Last edited: May 27, 2014
  41. SiegfriedCroes

    SiegfriedCroes

    Joined:
    Oct 19, 2013
    Posts:
    566
    The pivot problem I was talking about isn't really a bug, it's just something that works differently than expected. If it helps I could explain it better with some screenshots of the progress. Don't know if I should post it here then or as a PM to you?

    I can confirm that my game is now pixel-perfect without any tricks, YAY! Actually maybe I could've got it working in 4.3 cause I wasn't using a custom Sprite material with "Pixel Snap" enabled. Now I am and it all looks fantastic :D Very happy about that!
     
  42. bibbinator

    bibbinator

    Unity Technologies

    Joined:
    Nov 20, 2009
    Posts:
    507
    Hi all,

    To add to the discussion, we have also talked to people in Asia. We got the following feedback from China:

    2D Sprite:
    • 9-Grid Sprite [Strongly needed]
    • Tiling of Sprites
    • Tilemapping [Need a tiled map editor]
    • GameObject based render order [Be able to specify the render order of GameObjects]
    • Access to 2D Atlases from code [Currently, there is no way to do this(we can do this on light maps]
    • Convenient Sprite selection in scene editor [e.g., an occluded/hidden Sprite can be selected through multiple clicks]
    • Controllable parameters for polygon generation [Need to control the parameters for generating Polygon Colliders, e.g., vertex number, polygon number, etc.]
    2D Animation:
    • 2D Legacy Animation [2D Mecanim is too complicated to use currently, maybe an easier way should be provided for most basic cases]
    • 2D Skeleton [True 2D skeleton animation, with skinned mesh]
    • Editing of 2D Animation: IK [Nice to have IK when producing 2D animations. The workflow of a commercial software named "Spine" can be referred to]
    2D Physics:
    • PreSolve/PostSolve [To be called in the previous frame to filter/avoid some specified collision detections in the next frame]
    • NavMesh [Nice to have]
    • 2D Lighting [Nice to have]
    This doesn't mean we're doing stuff, just posting here what people in China came up with to add to the discussion.
     
  43. bibbinator

    bibbinator

    Unity Technologies

    Joined:
    Nov 20, 2009
    Posts:
    507
    And here is some feedback out of Japan:

    1. A lightweight movable collider

    Currently, if you want to do any moving 2d sprites, the rule of thumb is
    1. to add Physics2D
    2. set iskinematic
    But this is cumbersome and very often misunderstood by users, because
    - people tend to believe Physics2D is to do physics things
    - people tend to believe using Physics is slower than modifying transform directly
    Also, Physics2D consumes about 80 bytes per object and not very optimal for games with tons of tons of sprites but without physics movement.
    So the current setup is kind of complicated when users just want to do simple things.

    2. Simpler sprite animation

    Making sprite animation became simple, but it requires you to have Animator and AnimatorController to do animation.
    Animator + AnimatorController is a good and general solution, but it is again cumbersome when you just want one animated sprite, such as explosion.
    For this, I think we can improve our workflow by hiding processes around Animator and AnimatorController while we there is only one animation with one state.

    3. Tile map
    4. Line/Circle/Poly drawing feature (with line width/color configurable)
    5. Ensuring fixed framerate
    6. Resource encryption (prevent stealing illustrations)
    7. Stripping unused features (rigid body, navmesh, lightmap, etc - things not used by pure 2D games)
    8. Easy multi resolution workflow
     
  44. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    13,517
    Texture atlases in general, please!

    I'm making a footprint system at the moment where I want to have multiple footprint sprites in one atlas texture. This seems to be something that the 2D system already handles behind the scenes, but I can't find a way to take advantage of it for a custom system so far.

    Atlasing isn't just useful in 2D, and it'd be a real waste if people who want to atlas for 3D stuff couldn't use the built in solution.
     
  45. keely

    keely

    Joined:
    Sep 9, 2010
    Posts:
    966
    There are two features regarding atlasing:
    #1 Slice existing texture into separate Sprites (Sprite Editor in free)
    #2 Repack separate Sprites back into atlas textures (Sprite Packer feature in pro)

    Sounds like you want to do #1. You should be able to do that via scripts, too. Is there something specific you are stuck with it?
     
  46. StarManta

    StarManta

    Joined:
    Oct 23, 2006
    Posts:
    8,148
    The best way to do this would be to simply allow "Sprite" as one of the choices in the Shuriken renderer's dropdown menu, alongside Billboard and Mesh. And it should be SUPER easy to implement, too, as sprites are, for the most part, just specialized meshes, and meshes are already supported. Making them animate correctly would take a bit of work perhaps, but this is a situation where I'd be happy to accept "drag your sprite animation frames into this array on the particle system inspector" as a solution.
     
  47. StarManta

    StarManta

    Joined:
    Oct 23, 2006
    Posts:
    8,148
    It has this now. Select an object that does not have an Animator on it. Open the animation window, click the little drop down, and choose "[Create New Clip]". It automatically adds the Animator component, creates an AnimatorController for you, and adds the clip it just created into the AnimatorController.
     
  48. the_motionblur

    the_motionblur

    Joined:
    Mar 4, 2008
    Posts:
    1,738
    Hey - thanks for the Infos from the most requested Features from Asia. Pretty interesting to read.
    Also - after reading those points - I'd also be interested in a few of the features. :)


    I agree with China on these things:
    ... and specifically Lightmapping and Navmesh (as already stated).
    What does the tilemapper refer to? Is this meant as sort of a level-editor sprite-drag and drop toolkit?


    These would be the more interesting things from the Japan Top8 for me.
     
  49. zephyr7

    zephyr7

    Joined:
    Oct 12, 2013
    Posts:
    16
    Who are you?
    Small but experienced indigame dev.

    What kind of game are you trying to build or would like to build?
    Single Player jrpgs, 2D, PC+Console

    How does 2D fit into that? What use-cases do you have?
    2D for prerendered/handdrawn Maps like in the PSX-Era Final Fantasy Games, but with sprite characters as well. Tales of Destiny(both, original and remake) would be a great comparison.

    What are the GOOD things about the current 2D system you like?
    Great to have 2D Physics, thanks for integrating that. 2D In unity, wheeeee!

    What are the BAD things about the current 2D system you dislike?
    Navmesh/Pathfinding for the 2D Plane missing, also see below...

    -----------------
    The important part:


    How can we make it BETTER?

    I can only underline the statement that 2D Toolkit does everything right, it would be awesome if you could hire the guy who makes it!

    Most important to me:

    Optinal Legacy (or Legacy-Like) Animation for 2D Stuff that works, including Material Color Animation ( see http://issuetracker.unity3d.com/issues/cant-animate-color-value-of-materials )
    2D IK, and not just for human rigs
    2D Navmesh/Pathfinding


    - Fancy Nice2Haves:

    2D Skinned Mesh Rigs(IK, deformation and sprite swapping of different parts -see Spine)
    Tilemap with Autotile feature(i.e i paint the center part of a block of rocks, and edge parts around it will be added next to it automagically, like http://www.youtube.com/watch?v=3Ot8_y5Zfmk )
    9-Grid Sprites
    2D Physics Modifiers like Wind/Vortex
    2D Lights

    ----------------
    And specifically to the 2D system...

    Do you like the Mecanim workflow for animation?
    Mecanim's state machines are nice for many cases, but for many small things it's completely unnecessary and only adds work, etc etc etc, it's already been mentioned.

    How do you spend most of your time working with our 2D features? Anything bogging you down?
    I use 2DTK so i can't say much about your Sprite management, but i'm happy to have the 2D Physics. Good job guys!

    When you learned to use our 2D system, what stumped you or had a steep learning curve?
    No problems so far.
     
    Last edited: May 31, 2014
  50. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    13,517
    Actually, I couldn't get the Sprite Editor to work before. Now I can, and I believe it'll do the job perfectly. :)

    I think that my problem may just have been combination of a version mismatch with the docs mixed with looking at the wrong thing. Though they're correct now, the docs did say (and Google's search cache still contains this) to set the sprite mode to "Manual", where the options are actually "Single" or "Multiple". I did try "Multiple" anyway, but I now think I mistakenly opened the Sprite Packer rather than the Sprite Editor when I did that. Oops! And thanks for the pointer!
     
unityunity