I find it amusing that 'people' are willing to bend and twist and jump through hoops to recommend Unity for anything. It is very touching. laugh.png

I probably do the same when it comes to languages/frameworks/libraries I'm swooned by ;) I can definitely appreciate that Unity3d goes a long way in presenting something which is attractive to many; I'm trying to find a common ground for Unity and myself, it requires some programmer-framework relationship counseling though, which is why I took it to these forums.

Thanks for the link - it had some interesting stuff.

Approximately, how many MonoBehaviours go in to, say, a normal mob?

I grabbed a random mob prefab from the current build (since I have it on my home machine right now), here's the component list:

Mesh Renderer

Mesh Filter: [none]
Tk 2d Sprite

Tk 2d Sprite Animator

(those four come bundled together, tk2d is a 3rd party sprite handling library we grabbed since the project started before native 2d support really took off)
Audio Collection - our mobs own their sound collections

World Object - base component inheriting GameObject that we use for most in-game world-contextual objects
Character Module - component for anything that has sentience (self-movement and physics mostly)

Sprite Module - Where we control worldObjects' sprite changes (new animation clips/states)

Combat Module - component for any objects that can deal/take damage

Ability Module - component handling our ability system: any kind of "action" a combatant can perform (things like "meleeAttack, fireball, laser, etc")

AIControl Module - lets a tweakable FSM control this object's actions (player character has a playerInput module here instead)

And that's it.
All of those components have custom editors (the AI FSM even has its own visual scripting tool we wrote custom) and aren't light on the actual backing code.

Thanks, that gives me a much better idea of how to go about designing the components! Do you run any kind of automated tests on the MonoBehaviour level (the AI module comes to mind)? If so, any tips/resources on how to go about it?

Not really, we probably SHOULD but the game gets pretty constantly playtested and we're establishing some more structured testing rules now (to include a dedicated "build machine" and a better bug tracking db). One thing I've enjoyed about Unity is the constant prototyping environment. You can open a new scene just to test a specific component, muck about all you want, then just throw it out when testing is done or never include it in the check-in so you have a handy sandbox ready for other change-testing.

There are certainly unit test frameworks for C# ready to go, but there's so little lag time between writing a module and being able to test it in-game that we haven't really seen the need to get very test-oriented.

One thing I've enjoyed about Unity is the constant prototyping environment. You can open a new scene just to test a specific component, muck about all you want, then just throw it out when testing is done or never include it in the check-in so you have a handy sandbox ready for other change-testing.

This is one aspect of Unity I'm taking with me to my non-Unity projects. On the java side, I have a reflection-driven editor - somewhat like a much simpler version of Unity3d's - which I drop into most of my projects; I look forward to extending it with a static/origin state along a disposable play state. It's one of Unity3d's redeeming features and most persuasive bling imo.