[color="#1C2837"]So your saying that these sort of engines and programs exist because doing it on your own from scratch takes too long... if thats the case why isnt every developer using these tools? I mean, if your goal is simply to make a cool game and possibly get others to play it, and you dont really care about whats going on in the code, where is the incentive to sweat through learning opengl and sdl when you could drag and drop some stuff and script and basically make a game equivalent to someone who wrote a million lines of C++ code to achieve the same thing? I just watched a video on youtube for unity3d, and in the second tutorial in a series, this guy has a full on jungle environment that looks awesome, something that would take alot of work coding from scratch.
There's a number of reasons I can think of, and most of them are biased toward my belief that we
should be using middleware for
most games:
- Because the business side often equates "owning our tech" with "owning our game". They think that for some reason if they don't build the whole thing from scratch, they are beholden to some other company. Save a few special cases, this is not actually the case. But I've had alot of trouble convincing "the suits" that paying $250k for an engine license is more valuable than putting that money (and then some) toward building an engine from scratch, debugging it, testing it, writing the tools, delaying development until it's finished... and in the end, most off-the-shelf engines have better tools anyway.
- Because programmers like to reinvent the wheel. They're often the type that say "well, I didn't create that wheel so I don't
really know how it works. Therefore I don't trust it and I will create a new wheel that does the same thing... only
my way". I thought this way myself for many years. Then I learned that what I really want to do is understand
why the wheel works so I can make a better vehicle to use it. "Knowing what is happening is overrated" is a patently ridiculous response for a programmer, but "Knowing what is happening" is different than "Writing it myself". I find it equally ridiculous to go in and write the tech for a standard third-person shooter nowadays: between Unity, Unreal, Source, Torque, etc there is a solution at every price point.
- Because some programmers are fearful for their future employment. I hope nobody gets defensive about this answer: not
every programmer is this way. But some are. They're afraid that if development and scripting is so easy a designer can do it, that programmers become obsolete. This is also ridiculous: if designers/artists can do the
standard stuff, then programmers are free to do the
groundbreaking, awesome stuff. Instead they spend so much time rewriting the same damn pathfinding algorithm or rendering pipeline that they don't have time to really experiment.
- Because sometimes a game is so unique, it would be harder to write it with existing tools than to just roll your own. This is rare (I actually wish it were more common), but in my opinion it is the
only valid reason to not use middleware. Katamari Damacy, for example, needed to be able to do complex LoD and streaming not based on distance but instead based on the
size of the character. It needed to be optimized to display hundreds of low-fi models instead of a few hi-fi ones. The physics required a dynamically re-shaping ball. It was a game that they were better off writing their own engine for, or at least heavily modifying pre-existing tech.
In short, if you want a first-person shooter in a jungle environment, and you write it from scratch, I would argue that
you're not using the right tools. Middleware shouldn't be looked at as a way to replace programmers. It should be a way to empower them to innovate: a way to take away the drudgery of writing their 20th octree optimization and instead focus on coming up with new technologies that will make future games better.
