I'm a bit confused about this article. One one hand Unity is criticized because it's a black box. The project was complicated, early days of VR and so on.
"It was not fun. It was well worth the high rates we charged. It didn't help that we're still in the early days of VR, I'm sure."
On the other hand they did a very small project that was simple and for that they built their own engine and that was a lot of fun.
"Building our own actually turned out to be a joyful experience. It was a simple app, didn't require a lot of features. It was an unexpected, fun breath of fresh air."
While I see how building something small and simple can really be a joyful experience, building something huge and complex for a client and supporting VR in this day and age is probably far from that.
Am I reading it wrong or is this apples and oranges?
And while I agree that having the source for the game engine is always preferable, often reading the comments (usually on facebook groups) makes it sound like EVERYONE has 20 years of experience in C++ and could actually fix everything as long as the source was provided.
Engines tend to orchestrate the flow of control. This breaks your app into small pieces that are easy to reason about. When things don't work however you are helpless as there is a black box in the center of your application with black internal state.
Having the sources is often useful as it helps you to
* partition the black box
* observe the internal state
* observe critical control flows
* maybe not 100% diagnose and fix but mitigate an issue
Generally engines and frameworks are bigger than needed. They may be well tested but the sheer volume means there are a lot of corner case defects of holes left. Frameworks are particularly risky as they are supposed to be adapted to new situations and as a rule writing software for future requirements is fraught with problems.
Special purpose frameworks often beat general frameworks hands down in size, performance and cost. Going with a large established framework from a "commercial" vendor is often seen as a safe choice by management and as the article shows it is not. Then on the other hand there have been plenty of teams going down naively the road of custom engines and finding that they did not have to re-invent the wheel but build an advanced gasoline engine and were failing at that. As always understanding your requirements, options and capabilities priceless.
My point was actually something else. On one hand it seems they've been struggling with Unity on a big project (where source might have helped) and on the other she said how they made this little app with their own little engine.
If you're building something simple and small It's easy-ish to build everything yourself. While if you're doing something big, the cost/benefit of doing it from scratch might be something else entirely.
My point was that for the second little project Unity might have worked brilliantly anyway. Or godot, or maybe any little 3D engine. While doing the first thing for a client, with VR support and God knows what might have been really really difficult.
Not sure if I made my point any clearer at this point really :D
I think The Witness might do it: it's a relatively big game, build with a custom engine. And it's quite clear it couldn't have been build with a classic engine such as Unity though telling why would be a bit spoiley. Likewise, Braid couldn't have been made with a generic 2D engine: its time mechanics are just too alien.
Another reason why Jonathan Blow chose not to use any 3rd party engine is, he wants his games to last. He wants the ability to port them to new platforms, and that ultimately means owning the code —if only to separate clearly the platform dependent parts from the rest. (I hope he'll release the code at some point, so others can continue that work.)
Being able to fix issues was also a reason. When you not only have the source code, but also have written the damn engine, you can fix anything.
No, you missed my point. I'm perfectly clear why Jonathan Blow made it's own engine and why anyone who's capable of that would want the same thing. I was talking about the article and about some members of the game community and for that I have two criticisms
First: in the article she says that they struggled on one very complex project while using Unity. And then she says (or that's my understanding) that she made a completely different project on her own engine. That's why I said apples and oranges. I can't build unity, u4 or frostibe from scratch but if you want Pong or a simple platformer, sure, I can do that from nothing. That would be me saying: "well I had serious problems recreating the Witness in Unity but look at my space invaders which i made in Elm for browser without an engine".
The second problem I have is with some members of the gamedev community. Feel like a lot of people are ready to jump on the "I wish the source was available" train while very few of them (or at least that's my perception) know what to do with the engine source. Actually I could extend this point to a lot of advocate of the open source community. There is this false perception that anyone can fix anything that's broken because the source is available and yet a lot of those apps are sadly still very much broken and sometimes the authors of those apps have difficulties in finding people who might help them. But if you read any post about it online it's usually "closed source sucks and open source is brilliant cause we can always fix that anytime".
Sorry, this is a lot of generalization and obviously not everyone is like that but I tried to make point clearer this time 'this all.
About the second problem, I think it is one of control. Source code access at least gives you a fighting chance.
That said, I have used Qt a couple times, and never dared to delve in its source code, it's just too big. If I have a problem, I just work around it. If you want control over your engine/framework, you pretty much have to have written it in the first place.
Here I agree very much with you. With stuff so complex I can't imagine going through all that code. That's why I don't get people saying "if only I had the this or that source code".
Well, there is a middle ground: when you haven't written that big framework/engine, but could have, delving into the source code in an as-needed basis may sound like a decent option.
Of course, you're hoping your framework is fit enough for your purpose, so that you rarely have to inspect it —if at all.
On the other hand they did a very small project that was simple and for that they built their own engine and that was a lot of fun. "Building our own actually turned out to be a joyful experience. It was a simple app, didn't require a lot of features. It was an unexpected, fun breath of fresh air."
While I see how building something small and simple can really be a joyful experience, building something huge and complex for a client and supporting VR in this day and age is probably far from that.
Am I reading it wrong or is this apples and oranges?
And while I agree that having the source for the game engine is always preferable, often reading the comments (usually on facebook groups) makes it sound like EVERYONE has 20 years of experience in C++ and could actually fix everything as long as the source was provided.