Unity 3D thoughts

[Shrugging Khan]

Can you give me a quick opinion on what makes C# so good? (Heavens, I sound like an advertiser!)

Also, I heard some people are a little discomforted because it belongs entirely to MS. Is that a problem?

[x4000]

C# is publicly defined, and does not belong to MS.  Only the .NET implementation does.  Unity uses the Mono implementation, which is 100% open source.

The short answer about why C# rock is: it's reasonably concise, it's strongly typed, it has sensibly named and robust libraries, it has very fast JIT compiling, it has generics, it has reflection, it has a very good OOP model, it has very sensible methods for things like abstract/virtual inheritance, it has excellent threading models and options, it has the ability to call unmanaged code through p/invoke, it has the ability to run raw c++-like data crunching when (hopefully rarely) needed, and various other benefits.

And for those who are used to C/Java like languages, it just "feels right," as well.

[RogueDeus]

I started out with the SpriteManager script, but wound up going my own way.  I would suggest that the most effective way to render 2D stuff in Unity 3D is actually without GameObjects and instead with using the Graphics.DrawMesh.  It's actually super different from what Unity 3D would suggest, and is the only reason AI War is able to be run on it.  Tidalis uses more the standard methods, though, and certainly works fine.  So it depends how much you plan on doing on the screen at once, and whether or not you want to spring for Unity Pro.  But allocating and deallocating GameObjects is wicked slow, so do that as infrequently as possible no matter what.  And don't try to create more than a few thousand of those, heh.

Having started learning Unity3D this statement has me wondering... Are you speaking specifically in 'on screen' terms, or 'game wide' terms here? If I have 10,000 or 100,000 objects, but only ~1000 of them are on screen at any moment, does that still bog everything down as you say?

If it is an on screen problem, can it be addressed by simply reducing the number of draw calls?

[x4000]

Yes, it bogs that down that much simply by having them exist.

[RogueDeus]

Yes, it bogs that down that much simply by having them exist.

If merely having 10,000 GameObjects in existence bogs the game down, is it possible to use a form of ring buffer that creates and destroys them on a schedule that keeps relevant objects in existence, and caches irrelevant ones until they are relevant again?

Does it matter how complex the GameObjects are?

[x4000]

You're asking the wrong guy; I was uncomfortable with GameObjects from the start.  They looked bloaty to me, and when I saw that it took a couple of seconds to even instantiate 10k objects, I was about done with them.  I was in fact using a ring buffer to use them, assigning simple textured quads to them as needed, and activating and deactivating them as I went.  This was with Unity 2.61, but it was wicked, wicked slow.

I now just use Graphics.DrawMeshNow, and instantiate my own general C# objects to represent the gameworld.  If you're not using unity physics or what have you anyway (which I wasn't), there's no reason to have all the overhead of the gameobjects.

But things have changed a lot since 2.61, and so what I said above may no longer be true.  3.0 made a lot of things faster.  I still have no personal use for GameObjects, though.

[RogueDeus]

You're asking the wrong guy; I was uncomfortable with GameObjects from the start.  They looked bloaty to me, and when I saw that it took a couple of seconds to even instantiate 10k objects, I was about done with them.  I was in fact using a ring buffer to use them, assigning simple textured quads to them as needed, and activating and deactivating them as I went.  This was with Unity 2.61, but it was wicked, wicked slow.

I now just use Graphics.DrawMeshNow, and instantiate my own general C# objects to represent the gameworld.  If you're not using unity physics or what have you anyway (which I wasn't), there's no reason to have all the overhead of the gameobjects.

But things have changed a lot since 2.61, and so what I said above may no longer be true.  3.0 made a lot of things faster.  I still have no personal use for GameObjects, though.

Thank you VERY MUCH for clearing that up. You may have just saved me oodles of test time...

I am not as fluent a programmer as yourself but I too was looking at the way Unity used GameObjects and wondered if they may have been a problem. Especially after watching a few tutorials and how people go out of their way to reduce the number of new GameObject calls in scripts.

I hope you don't mind if I frequent this forum with Unity and C# questions! I am trying to learn as fast as I possibly can and I am finding it sometimes difficult due to my lack of experience and/or friends with similar interests. And there is only so much that StackOverflow and UnityAnswers can do for me in a pinch.

[x4000]

No worries, and glad I could help.  Oh, one thing to know: I don't think Graphics.DrawMeshNow works in Unity Indie, but I'm not sure.  I'm pretty sure you need Unity Pro for most of that.

[RogueDeus]

No worries, and glad I could help.  Oh, one thing to know: I don't think Graphics.DrawMeshNow works in Unity Indie, but I'm not sure.  I'm pretty sure you need Unity Pro for most of that.

You are correct, I just checked. The Graphics class is restricted in use to Pro only.

That is a bummer. But not entirely unexpected. I knew that there had to be a reason that they gave the tool set for free. If you wish to make a game that actually works well for more then very small projects, you need to buy it. Not complaining. It is actually quite well planned. Learn for free, pay to develop.

Before I shell out 1.5K for the Pro version, I really must make sure I need it... Lots of work to do then.

[x4000]

Well, you're able to do quite a vast number of things with their base game: mainly make 3D games with a similar scale to other 3D FPS, racing, and so on games out there.  If you want to do something outside those bounds, then that gets into the more "bare metal" area, and thus into pro.