A little discouraged

[anonymous_user_a006f79c]

@ExoGames;360801

I sympathize with you as well schetle. This is a topic I’ve discussed more than once with other developers on the nature of commercial engines. Roadblocks and hurdles are inevitable in any commercial engine because nearly all commercial engines fall into 1 of 2 (or both) of the categories I have labelled as follows:

Adapted engines
These are engines which are derived from a studio’s successful game title and adapted into a commercial offering. These engines, while often being heavily modified to be more abstract and viable for more target projects, still come hard-coded with many design patterns and practices that were intended for a very specific game implementation. Fundamental foundation systems such as reflection systems, RPC infrastructures and serialization implementations are quite often so tightly coupled that a custom re-implementation can mean modifying too much of the engine to be worth while without a large team and resource pool ($$$ + time). The difficulty of these engines typically arise from their legacy-code that gets dragged into the mix, requiring hacky workarounds for special requirements you may have. Documentation usually falls behind the pace of development with an engine like this due to the fact that the documentation wasn’t complete from the start during initial development because it was originally an in-house engine and wasn’t planned for prying eyes.

Abstracted engines
These engines are built standalone as a target-independent engine from the get-go. Designed to be viable for as many target project types, everything is designed in a very abstract and modular manner. The crutch of this type of engine is lack of specialization(s). To be blunt, certain genres of games require certain implementations. These engines usually allow for custom implementations to be plugged in easily but at the cost of you being fully responsible for design and implementation(s) of the specialized system(s). The difficulty of these engines typically arise from their goal of trying to cater to everyone/everything. Documentation is usually very complete and up to pace with development because it was designed with outside developers in mind from the get-go.

Unreal Engine is a unique mix of the two more so than any other I have ever seen. It does drag with it a ton of legacy code AND legacy patterns from both it’s founding title (Unreal Tournament) as well as it’s predecessor engine versions (kismet system internals, etc). Epic has done a great job with UE4 in the level of abstraction provided and they are definitely trying to make UE4 a viable choice for almost any type of game, however certain genres of games are undoubtedly going to run face-first into a brick wall with certain aspects of their game design. Blueprints, while being fully capable of designing a game entirely with it’s system, really is the entry-level design tool for the engine if used on it’s own. For seriously ambitious design you are going to HAVE to work in c++ for advanced scenarios. Unfortunately, for an engine of this size, learning the flow of the engine is the real hurdle. Hacky workarounds are a staple for many advanced scenarios and this is where the documentation becomes extremely important.

The documentation in UE4 is lacking a bit but the fundamentals are there and it is definitely getting better. The thing I find is off in the documentation consistently is the presentation approach. There’s still too much missing in some of the more advanced areas. And often times, when it comes to example code there is either way too much (no need to write a running project to show how a single call works…) or else there is none at all. Hopefully they’ll catch on eventually.

All in all, I feel that UE4 is the best commercial engine on the market but it’s doing way too much for me at times and to add my own implementation of many things is just not so easily pluggable. Example: Physx, I dont want it lol. It’s heavy and unnecessary and would much rather go with something like bullet but to swap physx out for bullet woul dbe a huge undertaking on it’s own. It would have been great if subsystems like this were a bit more pluggable but for the amazing rendering pipeline of UE4, I can deal with not getting my way lol

I guess the bottom line is that I think while UE4 is amazing in so many ways, it still may not be the best choice for all. That’s just something you will have to evaluate before you start your project. If you are a big studio, an in-house engine may be your better option depending on your scenario but for indie teams or hobbyists, bite the bullet and learn the ways of UE4. The time you will save will register in the thousands of man hours. Thats a LOT of man hours…

p.s. UMG is still very weird to me… Just putting that out there.

Thing is, who is it for then? If you say you’re a big studio go for an “in-house” engine, than what’s logically left from a commercial standpoint is small indies and one man bands. Which means smaller ranges of skillsets, certainly less time to spend on anything but the game they’re trying to develop and it’s to a point where fancy rendering features and advanced this and that mean nothing. Because all they’ll be concerned with is not getting overwhelmed and getting a game released before the lights turn out, trying to get the art pipeline done and core mechanics is time consuming enough…

Personally I’m fine with UE, I fully agree it does seem tacked on a bit to an old framework. I don’t believe it’s “that” difficult to use, if you’ve ever used CryEngine or Torque / XNA it’s refreshing to use a top tier grade engine that’s not a complete waste of time.

But I bet most “indies” will stick to Unity tbh!, it’s simply much easier to get stuff done. Even if the end result will be inferior, it doesn’t matter because really a good game is a good game.