4 ms·

Unity gets shit on a lot because of how easy it is to churn something out with it (of dubious quality), but if you understand how it works at a fundamental leve

Unity gets shit on a lot because of how easy it is to churn something out with it (of dubious quality), but if you understand how it works at a fundamental level and also actually know how to code, you can pretty much do anything with it. It would be difficult do something of this scale procedurally, but you can definitely do procedural generation in Unity. You would just have to be smart about how you load resources at runtime to avoid hangups.

foobarchu 8y ago
> but if you understand how it works at a fundamental level This circles back to another key reason I think a lot of people choose to build their own engine, many people don't want to spend time learning the ins and outs of somebody elses creation. When you build your own engine, you know the entire api in and out from the start and as it evolves, you know what it can and can't do, and you know where to go if it's missing a feature or has a bug.
- barbecue_sauce 8y ago
  That's fine if you have the time and inclination and you need very specific features that existing game engines wouldn't have, but at some level it can just be technological masturbation. For the most part, you're just going to be re-implementing things that already exist in much more robust forms in the major engines that have had the benefit of dedicated teams and a solid user base sussing out the edge cases (like render pipelines with shader support, physics engines, collision detection, etc. ). Chances are, to build a game engine, you're going to have to research the features and architecture of an existing one anyway to know what you even need to make. Building a game engine and building a game have very little to do with each other, and having skill in one does not necessarily imply skill in the other. If you're an indie dev in a small team (or a team of one) your first priority should be validating your game mechanics. Gameplay is where you have the most chance of innovating; you're only limited by your creativity.

foobarchu 8y ago

> but if you understand how it works at a fundamental level This circles back to another key reason I think a lot of people choose to build their own engine, many people don't want to spend time learning the ins and outs of somebody elses creation. When you build your own engine, you know the entire api in and out from the start and as it evolves, you know what it can and can't do, and you know where to go if it's missing a feature or has a bug.

barbecue_sauce 8y ago
That's fine if you have the time and inclination and you need very specific features that existing game engines wouldn't have, but at some level it can just be technological masturbation. For the most part, you're just going to be re-implementing things that already exist in much more robust forms in the major engines that have had the benefit of dedicated teams and a solid user base sussing out the edge cases (like render pipelines with shader support, physics engines, collision detection, etc. ). Chances are, to build a game engine, you're going to have to research the features and architecture of an existing one anyway to know what you even need to make. Building a game engine and building a game have very little to do with each other, and having skill in one does not necessarily imply skill in the other. If you're an indie dev in a small team (or a team of one) your first priority should be validating your game mechanics. Gameplay is where you have the most chance of innovating; you're only limited by your creativity.