Here you go.
That's a really good overview of the topic.
There is a lot of great stuff there. The author makes the content freely available on his website, but also sells in it print and multiple ebook formats if you care to help support him.

I must have misinterpreted your passionate hatred of Unity for defensiveness :)
I get that, but I suppose I was making a poor analogy that these engines were all originally conceived with a completely different purpose in mind than what they are being used for today, including large sandbox style games. It's really quite impressive.
I see where you were coming from now, but I guess I just never considered memory management the hard part.
Thanks for your thoughts on the subject, but I fear that I may have derailed the thread from where the OP was headed and for that I apologize.

Tangletail - I wasn't attacking you friend, I was just legitimately curious what the limitations were in your opinion I certainly don't want to start an engine vs engine battle, since everyone has their bias and opinion on this and ultimately it just really doesn't matter.
I will call you out on this though: Unreal and CryEngine were both originally developed and optimized for first person shooters - so what? I'm also not sure that I would call C# easy per se, but then again everything is easy when compared to assembly.
Completely agree with you on both of these points.
They promised native multi-scene editing in Unity 5, but it did not make it into the first or second major Unity 5 releases.
I am really not sure why the engine requires a transform for anything that derives from MonoBehaviour. It seems like they should have written something like ScriptBehaviour to account for GameObjects that won't have a physical presence in the game world. This is most likely the result of a design oversight early in development. Although, aside from being awkward it doesn't really hurt anything.
This is completely possible, and actually was possible in Unity 4 if you had a pro license (though it was kind of ugly and had its hiccups). http://docs.unity3d.com/ScriptReference/Application.LoadLevelAsync.html and http://docs.unity3d.com/ScriptReference/Application.LoadLevelAdditiveAsync.html

It doesn't really sound like you are looking for a Unity tutorial to me.
It sounds like you are looking for more of the artistic side of things like modelling, skinning, texturing etc. I would recommend that you look at tools for each of those areas and look for tutorials specific to those tools.
If you want to use Unity that is fine, but the things you are talking about wouldn't be generated from within Unity.

I agree with all of that. There are so many different writing styles and learning methods out there that you really just have to know what suits you best.
Yeah, sometimes you will blow money on a book that ends up being shitty, but if you do your due diligence and look at the sample excerpts you can really reduce the number of times that happens.

The answer is that it depends on what you intend to do. However, you should focus on learning the basics of C# and Unity first.
Other things that you might need to learn down the road depending on your goals are shader programming and SQL.

Yes, when the Xbox One gets Windows 10 there will be a unified Windows store and development platform.
https://dev.windows.com/en-US/games
This actually makes me really excited to be writing a windows game in DirectX right now and to have thrown away the xna requirement for my game
I am right there with you :)

I would say that the answer depends on how long you expect your development cycle to take.
If you were to release it today, it would probably be worth it. If development is going to take 2 years then it probably wouldn't be worth it.

I mean just think about it...
BallPrefab is a GameObject that has a Rigidbody component attached to it.
You want to instantiate a copy of BallPrefab, and then access the Rigidbody component of that copy for modification.
A GameObject will never be able to cast to a Rigidbody; that is just not how the relationship between the objects works. That is also why they provide methods for accessing the components of a GameObject.
Let's pretend for a moment that you were able to successfully cast a GameObject to a Rigidbody, why would you need to then use GetComponent<Rigidbody>() to apply force instead of just applying it directly to your instantiated object?
Why in the world you would want to loosely type your variable when you know exactly what it is going to be is beyond me but that is a completely different subject.

The scripting manual is quite clear about this; Instantiate is going to return an exact clone of the object that you pass to it. Therefore, if you pass it a GameOject, you will get a GameObject in return.
If you were to step through the code with a debugger, you would find that ballTransform is null as you currently have it coded.
From MSDN:
Please make the following adjustments:
var ballTransform = Instantiate(BallPrefab,trans.position,trans.rotation);
rbBall = ballTransform.GetComponent<Rigidbody>();
rbBall.AddForce(trans.forward * Speed);