Besides, if Jonathan Blow, Casey Muratori, and Ron Gilbert are all awful, then count me in.

i think in the case of Johnathan Blow and his new language, its a matter of he has the time and money now to do some R&D, and work on a language that better suits his personal needs and desires in a language. not exactly the same thing as "i must build this tool for Braid 2.0 development".

for me, deciding to go CScript was always a case of long term efficiency increases vs short term dev costs. in hindsight, i should have gone CScript back in 1997 or so when i first developed it. it wasn't until 2013 or so that i finally made that big move. and god! its SO much better! but its a lightweight syntax, maybe 30 keywords, the whole compiler is only about 1000 lines of code maybe. so dev costs were pretty low. and you can freely mix CScript and c++ syntax in the same file, so no porting issues with existing code bases. and i use it daily as my primary development language now. so the payoff has been good in real world terms of getting games built. Caveman 3,.0 is at 115K lines of code and counting, ought to come in at about 130K-150K lines when all's said and done.

Now, whether you can afford to spend five years spending engineering effort on a tool is an entirely different story.

As a solo developer, I don't really want to spend time making tools. I like making games. But it doesn't do me any good to work on a game if when I try to deploy it using the tools, it doesn't work, and I can't fix it.

This was my recent experience with Game Maker. I did a game-a-month, but it doesn't run on anything. I did something "fancy" with alpha blending, which just broke the build. As far as I can tell, there is no way to fix this. If I want to use the tool I have to stay on the path and not think outside the box. That's no fun.

If I want to use the tool I have to stay on the path and not think outside the box. That's no fun.

engines tend to only be really good at the types of games they were originally designed for. IE they're awesome for making clones of the original title. past that, you're on your own.

its possible that some engines like unity are more "general duty" these days. from what i've seen, i suspect so. but i'm not a unity user, just perused the docs once to figure out its basic capabilities.

for me its a little different. i started writing apps in 1982 or so, and games in 1989. like any good programmer back then, i had my bags of tricks - code to do common stuff. this eventually evolved into my suite of in-house libraries and tools over the years. every once in a while, i'll add new capabilities as needed, such as just recently adding skinned meshes.

i also favor general purpose libraries vs engines. my one library could be used for every type of game i've ever made. from text mode d&d to starship flight sims.

as near as i can tell, the big difference between engine vs library is where the main loop code is located. in an engine, its in the engine code, accessed via callbacks or hooks.

with libraries, its in your source code, and calls library subroutines.

that fact that engines tend to be best at the game they were originally designed for has so far prevented me fro using 3rd party engines entirely. its only recently that the capabilities and price points have approached the realm of the possible.

Then why are many developers out there making all their own stuff?

Then why are many developers out there making all their own stuff?

Lots of reasons:
1: Not Invented Here
2: Underestimation of effort in involved in creating tool. Developers are REALLY bad at this.
3: perception of "I don't need all those features, I can write a simpler/more efficient/cleaner version"
4: A combination of Bike shedding, boredom, frustration. Developer runs into difficult problem and instead of doing the hard but boring work, decides to build a new tool from the ground up to fix it. Much more fun than wading through memory dumps.

I'm not saying no one should write their own tools, but it should be the last resort, and only by an experienced team who have clearly identified the risks and reasons of writing said tool.

I can't see starting a studio and writing everything yourself, but when you are a small team of two or three, it might not be a bad idea.

But again, my "will it take too long" step prevents me from making scripting languages and audio engines.

Pointing to The Witness as an example of people writing everything in house is laughable. They've spent about 8 years (including a 5 year delay!) writing Myst. I was baffled for years as they continued to post updates on their "progress", re-writing every possible piece of technology from scratch, completely losing sight of the forest for the trees. Seriously - I think that they're smart guys, but they completely fell into the NIH trap, which is something many smart people do. If you're enjoying the challenge for its own sake, that's fine - but it's not the most efficient route to finishing your product. Make intelligent and well-reasoned build vs. buy (including $0 purchase for free tools and libraries) decisions. There are plenty of great tools and libraries out there, and lots of very smart people have recognized that, and use them.

I will rework the flowchart. Everyone seems to get distracted by the "write it yourself" step. There is nothing wrong with making your own tools, but if you spend five years making the tools, then maybe you made a bad choice.

For the witness, when he started making the game, there were no free or cheap tools available to do that, so I don't think he was wrong at all. Unreal wasn't free, and Unity wasn't an option.

"Not Invented Here" is a real thing, and smart people do fall into it, but I'm reminded of a quote from Casey Muratori: "Those who don't write their own code end up customers for those who do."