I don't really understand what is wrong with using stuff that other people made, that is basically how real world works... waste 3 weeks making it yourself, or find something that works and probably works better than coding it yourself although it might cost a buck or two and use that? Like if you use the 3rd person controller and it works then boom. Spending 2-3 weeks to get something like moving cube to work, while fighting against null pointers is more likely going to burn people and prevent them from doing anything.

And even if you use ready made scripts, you can try and test how to adjust things to figure out how stuff works. I just cannot really see why someone would rather advice beginner game developer to go use SFML over Unity.

Thing is, if you never even try to make something yourself, you will always be dependend on outside help... not a comfortable situation to be in for a lone wolf Indie or hobbyist.

Of course, once you have the skills, you shouldn't continue to try to bake your own stuff. But you need to be able to fix the stuff others broke. You need to be able to integrate stuff, write glue code, work around limitations and optimize.

There usually is no magic button in an engine "integrate downloaded thirdparty asset"... sometimes it is as easy, sometimes not. The amount of helpless people posting in the unity forums, hoping for an asset dev to fix simple compile errors they could have fixed themselves in minutes if they had spent some time looking through the code and at least vaguely understanding what is going on in the third party asset is staggering.

Sometimes that guy is me, yeah. Sometimes the thirdparty devs are quick to respond and I get the fix quick and easy. Sometimes I wait weeks while the thirdparty dev is most probably busy, you know, actually earning his rent (which often is not coming from Unity assets alone).

Sometimes the dev actually ABANDONED the asset, and you are on your own. Either you find an alternative asset, you fix the original asset yourself or you rewrite from scratch.

Happened to me in 3 instances. One thirdparty asset I needed badly, but the dev was gone. So I had to support it myself. One system was in quite a bad shape, and I needed to customize it. Dev didn't react for 6 months. I had used some of the high level ideas of the thirdparty asset to implement my own system, which was way better, cleaner, AND customized to my needs in that time. And then there was the Physics engine that should have replaced the horribly broken current PhysX version in Unity. Dev "has left the building", leaving me and others in my shoes back with the choice of either spending an insane amount of time integrating an open source physics engine, writing our own custom small scale physics engine, or spending just as much time massaging PhysX to do our bidding.

I often wished I had more time to work myself further into coding in Unity... its worth the time you spend on learning it in gold. Nothing worse than having to klick into the asset store everyday hoping somebody finally releases a system that solves your problem... or the horror finding out one of the assets you rely on most is no longer supported.

There is neither a magic button "fix messed up 3D model". If it is messed up after import, you either need to fire up Blender and see what exactly is wrong, or you go hunting for an alternative model.

And of course there is no "optimize my game" button either. Without intimate knowledge of 3D engines, and all the Systems that are at work in it, you will have little chance to get good performance as soon as you leave ultrasimple 3D or 2D games.

Unless you happen to stumble over one of the few good guides out there... and then you are often left with useful recommendations for people with exactly that knowledge, like "implement object pools", "use occlusion culling", and so on.

Now, I am not suggesting "you need to write your own 3D engine to be able to use 3D engines"... but jumping right into the editor, cobbling together your scene, overloading the physics system while blindly adding 1000's of trees without using any instancing, and then expecting "profit" after that is maybe also not the right thing to do.

And others before me have also not suggested to stick to DIY. It is just the more commonly suggested, and more failproof way of getting the skills needed for being able to work on complex game projects.

There are people who went a different route, myself included. I did ONE basic game in Java, and years later jumped right into the Unity engine. A lot of swearing, shelfed, way overscoped projects and banging the head against the wall later I finally also start to get quite good at it. And I am starting to home in on the scope I am able to realistically achieve.

Would it have been easier to start the more conservative way, creating small clones, moving up the video game timeline before trying my hands at Unity? Maybe... but I am sure without having a thick skull and being a little bit crazy I would have abandoned game development by now. Most guys are motivated by success, and not simply challenge. And directly jumping into the deep end and overscoping is certainly challenging, but leads to consecutive failures, not successes. At least at the beginning

I see where you are coming from with the low level plumbing woes. But lets be honest here. As long as you don't have the financial capabilities of a big studio, you will at some point have to get your hands dirty, no matter what thirdparty solution you use to speed up your development (see the unity thirdparty asset compile error woes).

If you are not ready for that, and have no expierience handling low level problems like that, you will loose the speed you just gained again.