Polo-Rican posted:

Kind of annoyed that I can't do something simple like var particlesystem1:ParticleSystem = this.[NAME OF CHILD] as ParticleSystem.

dupersaurus posted:

You can do that in AS3 since names are unique because objects are saved on their parents mapped by names. Well, they're more unique than in Unity. You can't in unity because names aren't unique at all. I always try to avoid the iterating-through-GetComponentsInChildren thing by 1) linking the particles to their own script variables in a prefab, or 2) creating them pro grammatically and saving the reference then; but I tend to work in things that lend themselves to that (for example, my prefabs almost always have a custom script on them), so YMMV.

Shalinor posted:

The spawning stuff only works if you have PoolManager2... but you really, really want to get PoolManager2, generally speaking. Instantiating things will cause you endless pain and hitching.

Obsurveyor posted:

Are you talking about this one?

xgalaxy posted:

Why spend $30 when all you really need is this:

code:

	public class BasicPool<T>
	{
		private Func<T> _createFunc;
		private Action<T> _resetFunc;
		private Stack<T> _store = new Stack<T>();

		public BasicPool(Func<T> createFunc, Action<T> resetFunc)
		{
			_createFunc = createFunc;
			_resetFunc = resetFunc;

			_store = new Stack<T>();
		}

		public BasicPool(Func<T> createFunc)
			: this(createFunc, null)
		{
			//
		}

		public T Acquire()
		{
			if (_store.Count > 0)
			{
				return _store.Pop();
			}

			return _createFunc();
		}

		public void Release(T item)
		{
			if (_resetFunc != null)
			{
				_resetFunc(item);
			}

			_store.Push(item);
		}
	}

Shalinor posted:

Because it's worth a few bucks for an elegant, well-designed solution as opposed to quickie hack approach. This ends up at the core of literally you entire game... it's worth making it more than "useable."

Polo-Rican posted:

Yeah, that works, thanks! I'm just being a whiny baby but it's annoying that you have to iterate through an array of results in a system where you can give each object a unique name.

Polo-Rican posted:

Yeah, that works, thanks! I'm just being a whiny baby but it's annoying that you have to iterate through an array of results in a system where you can give each object a unique name.

Unormal posted:

If you are cranky with the behavior of GameObject, it's also pretty easy to extend classes via partial classes in C#, just jam this in your code somewhere:

(I'm not necessarily condoning this technique as a general purpose tool, but sometimes it's just a practical way to keep from repeating the same stupid bullshit over and over again in a way that's a nightmare to maintain)

code:

namespace UnityEngine
{
    public partial class GameObject : Object
    {
        public ParticleSystem SuperDuperGetAParticleSystem( int TheOneIWant )
        {
            return whatever dude;
        }
    }
}

SupSuper posted:

You can also use Extension methods which are specifically designed for this purpose (doesn't work for static classes though).

Unormal posted:

If you are cranky with the behavior of GameObject, it's also pretty easy to extend classes via partial classes in C#, just jam this in your code somewhere:

roomforthetuna posted:

Can that kind of thing also work for splitting your own classes into two files, given Unity's insistence on having the filename match the class name?

Fake edit: I asked Google and the answer is yes, so long as one of them uses the class name as its filename the names of the others don't matter. Sweet. That'll make organizing the occasional overwhelmingly giant class much easier.

xgalaxy posted:

Debug.isDebugBuild is an abomination though.
I hate runtime checks for things that should be done at compile time.

Unormal posted:

coffeetable posted:

The most important thing I've learnt about Unity is to minimize the amount of code that talks to the engine, because you need to load a game instance to test anything that does. Classes that make no reference to Unity can be instantiated in any old unit testing framework, which means you can iterate on them much faster.

e: oh poo poo, they released an integrated framework for unit testing last month

Shalinor posted:

This would matter a ton, if anyone actually used unit testing

(yes, I know, some actually do, but everywhere I've worked, the unit testing framework is a sad, dejected thing that the tech director forced in and then no one ever really made use of)

coffeetable posted:

I was just speaking from experience on personal projects, so welp. Does the game industry consider version control and bug tracking to be passing fads too?

coffeetable posted:

I was just speaking from experience on personal projects, so welp. Does the game industry consider version control and bug tracking to be passing fads too?

Manslaughter posted:

Imagine creating a unit test to see if you can go through a block by jumping backwards in mario.

coffeetable posted:

That's not unit testing, that's validation testing. Unit tests are intended to be on single units of code (ie, methods or classes), to ensure they do what the author intended them to do. You achieve this by isolating the unit from the rest of the system. What unit tests don't cover the author's intended behaviour being different from how the system expects the unit to behave.

In your example, the unit tests would be things like "Is Mario considered a physics object?", "Is a block considered a physics object?", "Do physics objects from each of these position/velocity/size equivalence classes always report a collision?". Those cover a whole bunch of developer fuckups, but they don't cover things like the developer making special snowflake physics object for Mario and hand-crafting its interactions with normal physics objects.

Hughlander posted:

Came to post basically this. The Unit Tests would be more like, "If the input system has full right and on the same frame full left and jump is pressed simultaneous is the output to the physics system correct?" That and if the team has a strong culture of "Any bug fixed must show a failing test first." Then the tests will quickly help regress these issues. Once you get to cross-concerns you're out of the realm of unit tests.

coffeetable posted:

In your example, the unit tests would be things like "Is Mario considered a physics object?", "Is a block considered a physics object?",

Zlodo posted:

I always wondered whether a lot of "you can't possibly do anything without unit tests" stuff comes from using dynamically typed languages. In a statically typed language you don't usually need this type of test, but I can see how you absolutely need them to compensate for the ineptitude of dynamic languages.

coffeetable posted:

Those hypotheticals weren't literally "the Mario type has interface/ancestor PhysicsObject", they were "Does Mario register correctly with the physics manager?"

To be fair I'm a newbie, but I work exclusively in strongly typed languages and tests are still indispensable.