|
|
|
|
|
|
by johnnyanmac
2222 days ago
|
|
|
big difference is teams. If you're fine working by yourself, then an engine where you have 100% knowledge scope is great. The moment you introduce another dev or artist or any individual that needs source access to work on your game, you'll probably have them hitting every pain point mentioned in the article and more. Why's your UI buggy (or does it even exist?), why's rendering this thing slow? So time is spent teaching them (and there's likely zero help on the internet unlike Unity/Unreal), or making tools/bugfixes to accomadate for them. i.e. less time on the actual game. Hence the mantra: make games, not engines. If you like making engines, that's a good reason in and of itself to ignore that mantra. But if your goal is to make a game, then you shouldn't have to worry about the nitty gritty until it needs to be addressed. |
|
|
I focus on making the game, and the engine is the thing left over at the end.
But in so many ways, I have learned that a really productive game engine programmer should be spending his/her time building tools for the team. That's kind of the point.
You're making these tools that unlock the creativity of others, so they can help you with the team's creative vision.
I would expect any programmer I hire to be a problem solver, first and foremost, the kind of person who wouldn't need hand holding to modify the engine. I would hire people who I expect to make sensible decisions.
That's going to rule out a lot of people, and that's fine. When it comes to hiring, I select. I don't instruct.