2D Alpha Release 2 leaked... again

I get an error stating that a pro license is required to test this release.

Any word on when or if wake and sleep on distance settings might be added to the Inspector panel? The following is what I am hoping for (settings for selected object):



I think it's important to be able to set an objects wake and sleep on distance settings, as well as whether or not it can destroy the player on collision, all from the Inspector panel.

 

I've been searching around for a projected release date for the various upcoming 2D tools and I can't find one... especially interested in the upcoming tile map editor as I may switch over to Unity's for my current project if it releases in time. Is there any ETA or is it a "it will come when it comes" type thing?

 

I have request regarding the new Buoyancy Effector.

Currently, the buoyancy force seems to only be calculated based on the horizontal water height line. Even when using a non-rectangular collider to control where the buoyancy force should take effect, the calculation uses the water height value to calculate the buoyancy lift. It would be nice if the buoyancy force was calculated using the collider intersection with the floating objects instead.

Really what I'm looking for is the ability to have water waves (ie. a water surface that is not flat) that still accurately applies buoyancy. I thought I'd be able to do this using a dynamic polygon collider to represent my waves. Unfortunately, the current buoyancy calculation doesn't allow this to work.

-Jeff

 

Hi, What about my question: "Any word on when or if wake and sleep on distance settings might be added to the Inspector panel?"

 

Sure. With the help of @inthemilkywat I was able to create a wake on distance script, but I could only get the distance part to work. It's these other settings (Target, Go to Sleep, Sleep Distance) that would actually make the script useful, but I don't know how to code them:



But if I use a custom script to add in features that should already be there, there is the risk that the script will not work with a future Unity release. Using built-in features means less time coding, and more time building my game.

Also missing from Unity's 2D feature set (from the inspector panel anyway) seems to be the ability to set an enemy object to destroy the player on collision.

 

Actually, my AwakeOnDistance script already appears to be in conflict with Unity build 5.1.0f3. If I add the Enemy script to an object that has the AwakeOnDistance script, I get the following error:

But even the Enemy script does not appear to have a setting for targeting another object (or the Player), and destroying it on collision.

 

That's not missing, because you're expected to be able to do such things by yourself. Such a system is so project-specific I don't think it should be there at all. Also, I don't think this is quite the thread to be asking about problems with your script Sorry if that sounds harsh to you, but don't wanna clutter this thread up
---

Awesome to see these new toys! Very excited to start playing with the spline smart sprites and masking will be super useful.

 

Of course they should be there. Rigidbody 2D has Sleeping Mode and Collision Detection. Adding the ability to wake on distance is a no brainer! So is Destroy on collision. These are not project specific features. They allow the physics of objects to become activated when the player in a platformer or endless runner type game gets close enough, and to kill the player on collision.

Where did you read that I am asking about problems with my script? My point was to show why I preferred to have these features added to Unity, not to get help fixing a broken script.

 

I never talked about wake on distance I only quoted you on death-by-collision. Having a setting in the inspector for "destroy player on collision" is rather redundant as it's such an easy thing to code yourself, and you would normally have that event accompanied by death animations and maybe some particle effects, no? So already that's getting more case-specific, and there are many more things people might like to happen. It's not a hard thing to add by yourself, and you could have it far more customised to your needs and your game. You could have a component that calls a death function on your player that does all the effects etc for you (but I'm an artist so I won't suggest coding practices heh)

You were talking about null reference errors you got when using your script? Sorry if I was wrong but looked to me like you were asking for help with it. Anyways, no point me discussing this any longer really

 

Scratch that. The Enemy script is not an issue.

 

@ tweedie,

First, what I feel is missing more than anything from the Rigidbody 2D settings, is a way to enable (awaken) the physics of an object based on a specific distance from the player (target). The ability to disable (put back to sleep) the physics of that same object after the player (target) is a specified distance away would also be useful.

Second, a simple setting that would allow an object to kill the player on collision just makes sense to me. It would save me a world of time. Isn't that the point of having a visual editor in the first place? Why does Unity have visual controls and settings if not to help game designers to save time? Why code if you do not have to?

 

Hi webmagi,

Can I suggest something like playmaker if you want to extend the functionality and do not wish to code. Most people do not require what you're asking for. You require it but its a trivial couple of lines of code. Let us know if you need any help on forums for your issues in a separate topic.

The visual controls are to assist in authoring content, not executing content for your specific game. They're after all, on the editor side of things.

 

Playermaker looks very interesting. I will check it out.

According to the manual: "The Inspector displays detailed information about your currently selected GameObject, including all attached Components and their properties. Here, you modify the functionality of GameObjects in your scene." That's all I'm trying to accomplish. But the functionality I would like to modify (Awake on Distance, Target, Go to Sleep, Sleep Distance, etc.) do not yet exist. And it's not just about my game. I'm looking for a better solution for building games for my clients. The more time I have to spend attempting to code in functionality that already exists in other 2D game engines, the less likely I am to choose Unity for those projects. Currently I am using Construct 2, and I'm doing my best to avoid the crazy expensive Buildbox. But while Buildbox may have a very limited feature set at version 1.2, it has the features I am after. And the games being built with it are far from trivial: https://www.buildbox.com/showcase/

If adding the following controls to the Inspector really is just a trivial couple of lines of code, I would be happy to pay someone to create it for me:


If not, and if the Unity team fails to ever see the importance of these features, that's OK. I'm still only committed to playing around with the free version of Unity in my spare time. I would need better 2D features to shell out $1,500 + another $3,000 for iOS and Android builds.

 

Well the problem is the rest of us don't really want bloated builds nor do we want unity to be working on something that takes anyone a couple of minutes. So you're actively fighting me for example, for unity's attention. I want Unity to optimise, bugfix and generally finish big thinking features like Director, while you want them to do a little 5 min job. Now you might say "oh it only takes Unity 5 mins to put this in so no harm done" but does it end there? I'm 100% sure it doesn't. Next you'll be asking for some other feature and so on until you realise you just made Unity add playmaker.

If it sounds like I'm putting you down, I'm not. Unity has big plans in future for some kind of visual scripting system and so forth (see roadmap) but that time is not now, and wasting time on something nobody (including you) will use once Unity adds visual scripting, is a pointless waste of their energy.

Of course you don't need to shell out any money. Are you earning more than 100k a year right now? If not then you don't need to pay for pro. Personal has the same feature set. You could buy playmaker and that would solve all your issues since you can't or won't code.

 

To say that extending the existing Sleeping Mode functionality in Rigidbody 2D to wake on distance as well as collision is bloat is just plain ridiculous and short sighted. Whether or not Unity decides to add this feature, or whether it takes them 5 minutes or 5 months, I refuse to be pushed around because you think your needs outweigh mine. I have as much right to be here asking for features as anyone else. Tell me I'm wrong!!!

 

You're wrong because you don't know enough about game development or Unity to understand why you're wrong. If you can't accept that, it's fine but Unity isn't a click game maker, it's actually designed for programmers. Currently it is not designed for non programmers, it's that simple.

As I said before, Unity is doing something about it in the longer term but for now you could use Playmaker. Arguing and making ultimatums because you're not capable of coding isn't really helping.

 

I agree this can get pretty expensive. I'm actually doing this with my own custom solution. It works fine, but definitely have to be mindful of the collider setup.

This might work for some scenarios, but I agree it'd be confusing to most and not sure it'd even give me the results I'm looking for.

I like this idea. Please consider it.

 

BTW, the other way I tried to use the new buoyancy effector to handle a dynamic (wavy surface) was to create multiple effectors arranged side by side horizontally. I then thought I could just dynamically set the water level height of each to match the current wave height at it's location (Think of a stereo equalizer where the bar heights represent the water height.)

This almost works. The problem is if my object in the water is in contact with multiple effectors, which it almost always is, the buoyancy force created is to large. Each effector applies it's own buoyancy force and they are additive so the end result is a larger then desired upward force.

If the effective area used to compute the buoyancy was the intersection between the effector rectangle and the collider of the object then I think this would have worked. Instead it seems the area used is always the total area below the water level for each effector.

-Jeff

 

I do have the right to be here, and unless Unity Technologies says otherwise, I'll be staying.

I get it. The purists here get really annoyed when designers like myself come and ask for features that any coder could do in his or her sleep. That makes sense. I understand. But I believe the features I am asking for should already be there in the first place. If you don't agree, that is fine. Duly noted. But I have the right to request features like anyone else.

 

Yes, for the purposes of my game, the surface simulation needs to be somewhat accurate. It doesn't need to be perfect by any means, but things floating on the surface need to move with the waves in a realistic, physics driven manner. And some of the waves can get quite large.

I'm not to sure this would be that much better than just using my custom solution for buoyancy. I'd still need to do some of the same calculations I think.

Thanks for continuing to think on this. Currently, I still like the idea of having the option to turn on complex surface clipping.

BTW, my custom solution was taken mostly from here:

http://www.iforce2d.net/b2dtut/buoyancy

And I use this for my poly-poly collision

http://rosettacode.org/wiki/Sutherland-Hodgman_polygon_clipping

 

The tile map features sounds awesome! Can't wait for this release as I am currently working on a tile based game.

The only feature/problem that I would love you guys to fix is the stuttering that seems to exist on some hardware (even top line hardware like my GTX 970) even on high frame rates. There are multiple questions in the answers section about stuttering in 2D games NOT related to bad programming and/or high frame rates. I'm not sure if there is some difference to the rendering pipeline other than the shaders, but the stuttering does not seem to appear in 3D games (I am not sure about this one, but all of the questions/reported issues are regards to 2D games), and it seems to appear at completely random times (nothing visible in the profiler => Windows 7 + Unity related?). Both cameras and rigidbodies start to stutter (stationary camera does not fix the stuttering).

Oh. Pixel perfection would also be neat. There seems to be some tearing and glitches with pixel snap if the camera is not placed perfectly. There are work arounds, but they are not elegant.

And I agree with hippcoder. Don't bloat Unity with things that we can code ourselves in a few seconds/minutes. Sleep on distance is _not_ something that everyone want or need.

 

I get the sense you're not actually reading what I'm saying.

I'm saying you will get what you ask for in a year or two. Until then, a good idea is to bridge the gap with Playmaker or similar. Currently, stock Unity cannot make games without code. And it won't for another year or two, or whenever they make a visual scripting system which is entirely absent.

It's nothing to do with what imagined scenario you've come up with, it's just a fact. Unity want to make things easier, but they can't ever fully meet you without visual scripting.

 

So every feature and every visual control in every component currently available in the Unity interface is used/needed by every game developer on every game?

Of course I am, but you made my feature request about you, which made communication from that point forward next to impossible.

If Wake on Distance never gets added, that's fine, but I'm happy to continue this conversation.

 

No, but that should be the aim. The strength in Unity and Unreal Engine are as hippocoder described: these are engines for programmers. Seeing your functionality is so easy to implement, there is not really any good reason to add it. If there is no reason to add something, then do not add it. Adding things that are unneccessary for 99% of everyone to the GUI while also being easy to implement is probably one of the more stupid things a designer can decide to do.

 

The functionality that interests me solves a need that I would think affects at least 99% of game developers, and that is activating objects and animations during key moments of gameplay. Currently, in Unity, the only way to achieve this is by collisions/triggers. How is distance based triggers any less viable an option?

In the following video, at the 33minute, 10 second mark, the player is about to run past a door. The idea is to have the door open and the lights turn on at the right distance from the player, which is controlled by a Sphere Collider: https://unity3d.com/learn/tutorials/modules/beginner/live-training-archive/animate-anything

Why limit Unity to only collision based activations when distance from the player is the obvious objective?

 

As for the script, this is as far as I've managed to get:

Code (CSharp):

1. using UnityEngine;
2. using System.Collections;
3.  
4. public class AwakeOnDistance : MonoBehaviour
5. {
6.     [SerializeField] private Transform target;            // The target objects wake up to
7.     private GameObject player;
8.     [SerializeField] private float distance = 100f;       // Setting distance to target in the Inspector panel
9.     [SerializeField] private bool go_Sleep = false;       // Is the object going back to sleep?
10.     [SerializeField] private float sleep_Distance = 0f;   // Distance until object sleeps.
11.  
12.     // Use this for initialization
13.     void Start () {
14.         player = GameObject.FindGameObjectWithTag ("Player");
15.     }
16.    
17.     // Update is called once per frame
18.     void Update () {
19.         if (Vector2.Distance (transform.position, player.transform.position) < distance) {
20.             GetComponent<Rigidbody2D>().WakeUp();
21.             GetComponent<Rigidbody2D>().isKinematic = false;
22.         }
23.     }
24. }

 

Please add platform-dependent atlases.

It's a huge deal for mobile games to switch between -SD/-HD or @1x/@2x/@3x suffixed sprites.

So I just can set something like Application.SpriteResolution = "@2x" and all the sprites and uGUI images will pick the right sprite on enable.

 

Looking forward to sprite masking - I know an ETA is unlikely, but would sprite masking be likely to be in before 2016?

 

Everything I've been testing so far has actually been really great.

I've also already posted the wish for a random tile painter but as you've said it's in the works already.

What also needs to be available is probably a reliably colission component that produces slitly simpler results than the polymesh colider does at the moment.

And a way to maybe aid in swapping spritesheets for an existing tilemap.

Though as far as I am concerned even if you don't put in many more features than what is available now in the Alpha: If it is at all possible to do so - bring that over into the release and add more features later on. The tile editor is already so much fun to work with. The faster a working version of it is in a stable release the better.

 

Loving the Ferr2d-terrain and Tilemap/animation features!! As much as I love it so far, I passionately want to see it improved to be the best it can be -- so for that, I've got 2 questions and 2 features to request.

First, my 2 questions:

1. Are you guys thinking about allowing the "SmartSprite" to be animated too (maybe in a similar vein as the tilemap is animated)?
   
2. Can the smartterrains/tilemaps use various normal maps or whatnot for lighting/etc. ?

Second, I have two long-desired feature requests for the physics system:

1. A jumpthrough/one-way sloped platform solution that also works while the platform and player gameobjects are moving with perhaps a PlatformsUpdated() event to tell the player the platforms are moved to their new positions now so that it might be able to move without fear of a platform changing position in the meantime (I see a lot of complex efforts out there for this with no real universal solution. in-built one-way platform Unity solution seems to make sloped platforms impossible to emulate NES/SNES-era jumpthrough slopes without feature request #2 below, leaving us with a physics-system currently geared only towards creating the next Angry Birds, rather than toward creating the next Super Mario Bros. -- no offense intended toward Unity or Angry Birds of course, but games could be a LOT more fun with one-ways AND physics-simulations to work with.)
2. A way to simplify physics by setting absolute speeds (i.e. instead of adding a force of 10 to a relatively moving object, allow me to set the speed directly to an object if I know exactly how fast I want it to go -- only override this speed setting on collisions if it's necessary! No idea why this hasn't been added, but it's SO overdue!)

The second feature should be infinitely easier than the first, and it's also capable of making 2d Unity infinitely more user-friendly too! A lot of times when I'm making a 2D game (and even in a 3D one sometimes too!), I would like to tell the physics engine to tell the gameobject "go exactly this fast while inside a trigger area, but go even faster/slower outside of a trigger" or "move at exactly this speed while walking up a slope, down a slope, or straight on flat ground" and this is so difficult trying to do with something like "Drag" in the trigger volume. An absolute speed / direction setting would be the very best way to fix this issue.

If you're worried, you could let the developer set a flag/bool that tells the physics system it can/can't currently interact with the absolute speed they set in the gameobject (i.e. in the case of a collision, or when a force is applied to the object, allowing the object itself to decide whether or not to ignore the force or collision during its movement, since sometimes ignoring collisions / forces enacting is desirable -- e.g. Super Mario Bros. when Mario dies in place or in mid-air and falls off the screen through the ground.) This should be built-in imho, and any user migrating from competing 2d software such as Game Maker (like myself), would expect some semblance of familiarity in basic 2d movement. Most games are NOT Angry Bird clones, so give those of us who want to sidestep the physics-simulation style movement an easy way to do that, okay? Pretty please -- with sugar on top??

 

You are looking for a dedicated character controller 2D, right?
I agree - a dedicated character controller that can recognize what it's standing on, if it's hitting the ceiling or the sides. And a setting for dedicated speed, acceleration and precise/absolute jump height would be awesome.

If this was to be integrated datively it would be pretty cool but if you don't want to wait: Sebastian Lague has a complete tutorial set on how to create such a precise character controller manually.
https://www.youtube.com/playlist?list=PLFt_AvWsXl0f0hqURlhyIoAabKPgRsqjz

It's some advanced stuff in there, though.


(edit) also you might want to consider filing requests on BitBucket, rather than in this thread.
https://bitbucket.org/Unity-Technologies/2ddemos/issues

 

sorry for stupid question but I'm finally getting around to testing this out:

How do I make animated tiles?

Is there a video showing how to use the new features?

thanks,

 

There is a feature presentation here:

It doesn't go into animated tiles, though. Maybe @JuhaKiili can answer this.

Otherwise look around here: https://bitbucket.org/Unity-Technologies/2ddemos/issues?status=new&status=open
Maybe it's being discussed there somewhere.

 

Thanks for the video! I remember seeing it, good to see again.

Not finding any resources on animated tiles, although I'm thinking it's something automagic and undocumented, like the brushes?

In the video it's not really explained how the brushes are made, they are found somehow?

 

I'm curious how runtime alteration of tiles intended to be handled? I don't have a pro license, otherwise I'd check myself, but I'm curious as to what kind of options are planned through scripting and how expensive changing tiles procedurally would be. Has anyone done any benchmarks?

I've been finding a lot of tile solutions (which are otherwise pretty good) choke when it comes to lots of dynamic changes being made to the tile, due to the rebuilding and destroying (garbage collection) various sections of the map. I haven't been able get one performing satisfactory so far, even when only loading what changes on screen (something new moved into view, or something changed).

I'm going to try to make my own tile/mesh system for educational purposes in C#, and reuse as many elements as of mesh data as possible to avoid performance penalties, but I have severe doubts I'd be able to make a solution as effective as Unity. You guys are professional engineers directly involved with rendering pipeline and the engine itself. Even if I gave my best effort, in a managed scripting language, working with an engine I didn't make, I probably couldn't compete with you best efforts.

So if it's not already on the list, the small performance penalty for changing tiles would be very helpful for anyone making a procedural 2D game. It's a very popular genre (Terraria is a huge game, but it could be done with top down, or isometric tiles). It could open a lot of doors for 2D Unity users to make dynamic 2D games out of the box.

 

I'm not at home and able to test this so hoping this is an easy question to answer.

For the RelativeJoint, can the target angle between the 2 bodies be updated programmatically at runtime?

-Jeff

 

Thanks!

Curious, does the FixedJoint have similar offsets that can be set at runtime?