> Buuuuuut.... the early stages of starting game development these days are, "What engine do you use?"
As someone who started from raw OpenGL and cobbling together various libraries (OpenAL, OpenIL, etc.), I think it's bad for pedagogy, but I love it for productivity. Just like React.js.
I think there's a huge advantage to not having to spend time writing code to glue together asset management to physics to animation to graphics to audio to AI and UI, etc., and also because scene graphs and entity/component systems are like game programming's equivalent to REST and MVC.
So once you know how to work with that stuff, jumping into an engine is a great way to get right to prototyping and skip all of the setup. But for building up the conceptual understanding... it's rough. It's just a totally alien way to think about programming if your background is classic frontend/backend.
> And honestly it can be a daunting choice. They're all quite large and have their own jargon and way of doing things. I can get through a "Hello, world!" tutorial in an afternoon but it'll take months before I get something useful to work and load my brain with all of the jargon to navigate the documentation and forums...
That's absolutely a problem, and I totally agree that it's exacerbated by starting from Unity as opposed to learning the component concepts individually. But that said, Unity genuinely saves me a ton of time, even if the result isn't as optimized. That goes double for VR, where the sheer conceptual load of designing/coding the interaction models makes doing it without an engine not really worth it.
> versus writing everything from scratch. It's a slower start but I have already learned a good programming language and can go from there. I don't end up with a black box of performance problems. Nor do I end up trying to shoe-horn my round game into a square peg. It's quite common going down this route to write your own data formats and tools as well: level editors, compilers, debuggers. And the productivity starts going up fast as you build momentum.
I think this is a difference of what you're trying to accomplish. An engine gets you off the ground much faster if you have trained on it because enough of the abstractions are common to most games that, for example, reusing a not 100% ideal graphics/physics/skeletal animation rigging/key framing/audio/collision detection system still saves you a lot of programming.
As someone who started from raw OpenGL and cobbling together various libraries (OpenAL, OpenIL, etc.), I think it's bad for pedagogy, but I love it for productivity. Just like React.js.
I think there's a huge advantage to not having to spend time writing code to glue together asset management to physics to animation to graphics to audio to AI and UI, etc., and also because scene graphs and entity/component systems are like game programming's equivalent to REST and MVC.
So once you know how to work with that stuff, jumping into an engine is a great way to get right to prototyping and skip all of the setup. But for building up the conceptual understanding... it's rough. It's just a totally alien way to think about programming if your background is classic frontend/backend.
> And honestly it can be a daunting choice. They're all quite large and have their own jargon and way of doing things. I can get through a "Hello, world!" tutorial in an afternoon but it'll take months before I get something useful to work and load my brain with all of the jargon to navigate the documentation and forums...
That's absolutely a problem, and I totally agree that it's exacerbated by starting from Unity as opposed to learning the component concepts individually. But that said, Unity genuinely saves me a ton of time, even if the result isn't as optimized. That goes double for VR, where the sheer conceptual load of designing/coding the interaction models makes doing it without an engine not really worth it.
> versus writing everything from scratch. It's a slower start but I have already learned a good programming language and can go from there. I don't end up with a black box of performance problems. Nor do I end up trying to shoe-horn my round game into a square peg. It's quite common going down this route to write your own data formats and tools as well: level editors, compilers, debuggers. And the productivity starts going up fast as you build momentum.
I think this is a difference of what you're trying to accomplish. An engine gets you off the ground much faster if you have trained on it because enough of the abstractions are common to most games that, for example, reusing a not 100% ideal graphics/physics/skeletal animation rigging/key framing/audio/collision detection system still saves you a lot of programming.