This is good knowledge for whatever your field is. I've created a few ORMs. I don't use any of the ones I wrote, but I learned a lot in doing so. I've created a few web routing systems. Again, you can learn a lot, but unless you actually want to spend a lot of time writing and extending one, just use what you learned to help you pick a good one.
Create your own Game Engine but don't use it
11–20 of 113 posts
Re: Create your own Game Engine but don't use it
#12Interesting contrast to the Carmack school of thought: _do_ build your own game engine and don't even reuse anything you made before, because you'll know better this time.
Also remember that id Software wrote an engine specific to the game they were creating (it's debatable whether you can call them engines at all, really). Things are a lot more streamlined if you take this approach because you rarely, if ever, have to answer the question "would this work for some other title?". Or worse, "would this work for any future title that may not even be in the same genre?"!
That, I think, is the mistake many game devs (who write their own engines) make. They make an engine for all possible games, then try to use it for their 2D match-3 puzzler, which uses about 5% of the code they've written, and even then they have to cludge some bits.
Re: Create your own Game Engine but don't use it
#13Interesting contrast to the Carmack school of thought: _do_ build your own game engine and don't even reuse anything you made before, because you'll know better this time.
Most of us aren't John Carmack, though. When you're the guy that basically invented the genre of code you're talking about, there's a very good chance that your next project will advance the state of the art. When you're basically a hobby coder looking to get an game in the app store, it's a slightly different story.
Beyond that, it's not the 90s anymore; what novel feature are you going to implement that is going to wow anyone in the way that Carmack's engines did?
Re: Create your own Game Engine but don't use it
#14This blogpost gives the other point of view:
http://www.spacesofplay.com/blog/why-we-built-our-own-tech-f...
Essentially that the engine you use can constrain what you create, so write your own.
Re: Create your own Game Engine but don't use it
#15I think a lot of developers who come into game dev have a mistaken view of Unity as the "budget" choice based on the poor quality of many of the indie titles shovleled out with it. But Unity is probably the most advanced game engine in existence today. Far beyond Unreal 4 in terms of both performance and tooling. The reason the average quality is so low with Unity titles is because of just how easy the technical aspe…
I have pretty much no experience with game development, but why is UE4 such a popular choice for commercial games if that's the case?
Re: Create your own Game Engine but don't use it
#16I think a lot of developers who come into game dev have a mistaken view of Unity as the "budget" choice based on the poor quality of many of the indie titles shovleled out with it. But Unity is probably the most advanced game engine in existence today. Far beyond Unreal 4 in terms of both performance and tooling. The reason the average quality is so low with Unity titles is because of just how easy the technical aspe…
I have pretty much no experience with game development, but why is UE4 such a popular choice for commercial games if that's the case?
Most big studios are still on UE as a matter of momentum and the aforementioned biases. Unity really only became viable in the past 3 years, which is shorter than the average AAA game development cycle. Also certain games such as FPS are still better off with UE, as that's what it was designed for.
Re: Create your own Game Engine but don't use it
#17Earlier quoted context omitted.
Most of us aren't John Carmack, though. When you're the guy that basically invented the genre of code you're talking about, there's a very good chance that your next project will advance the state of the art. When you're basically a hobby coder looking to get an game in the app store, it's a slightly different story.
Beyond that, it's not the 90s anymore; what novel feature are you going to implement that is going to wow anyone in the way that Carmack's engines did?
I wish modern games could get the basics as right as Carmack's engines did.
What good is the tech in No Man's Sky if visiting untold numbers of planets feels like a slog through mud?
Re: Create your own Game Engine but don't use it
#18Earlier quoted context omitted.
I have pretty much no experience with game development, but why is UE4 such a popular choice for commercial games if that's the case?
Most big studios are still on UE as a matter of momentum and the aforementioned biases. Unity really only became viable in the past 3 years, which is shorter than the average AAA game development cycle. Also certain games such as FPS are still better off with UE, as that's what it was designed for.
Well, the examples I had in mind are, like, Guilty Gear Xrd or Tekken 7, where there isn't any obvious history or genre reason (to me) to pick it. But maybe it's just old prejudices, as you said.
Re: Create your own Game Engine but don't use it
#19I think a lot of developers who come into game dev have a mistaken view of Unity as the "budget" choice based on the poor quality of many of the indie titles shovleled out with it. But Unity is probably the most advanced game engine in existence today. Far beyond Unreal 4 in terms of both performance and tooling. The reason the average quality is so low with Unity titles is because of just how easy the technical aspe…
Vanilla Unity tooling is a joke. Of course it's enough for most games. Store solves some issues, but not all.
Re: Create your own Game Engine but don't use it
#20This can be said about plenty of things. Encryption is probably the most obvious; there's a lot of benefit from reading about and implementing various encryption methods, and absolutely foolish to use any of that work in a setting where it might actually be attacked. The article is pointing out something that should be obvious; if you're making a widget as part of a larger task, your implementation will probably be l…
Indeed, but there are a lot of situations where a focused specialized widget made by a small team will be better than a general "best widget" made by a large team. The further you stray from the use cases of the "best widget" the worse it gets.
Writing another HTTP server does seem like an inefficient expenditure of time, but we wouldn't have Nginx or smaller tools like Mongrel if the existing "best tools" were good enough. Game engines benefit you even more to be custom because the further your game strays from another Unity game, the further it stands out from the crowd of 100,000 smartphone games.