A little discouraged

General Feedback & Requests
1

Hi.

A year ago, or so, I was a subscriber for UE4. I loved (still love) coding C++, and I really enjoyed my time spent doing it within the context of UE4. However, I halted my project to wait for UE4 to get better.

Fast forward to now and I’ve become discouraged again with what appears to be an insurmountable road ahead as a hobbyist programmer. I re-discovered why I got annoyed with UE4 in the first place. It’s most likely due to my lack of understanding of UE4 internals which is a real absolute possibility.

When I’m programming C++ for UE4, I’ve reached a point where I feel like I’ve gotten into a pigeonhole. I often feel like some things in UE4 haven’t been developed in a way that make it applicable for all use-cases without hacks or direct engine modifications (which I feel like is a waste of my time at this point). Is it because of UE4’s historical background where Unreal was once-upon-a-time was used for very specific games?

The unfortunate reality for me, is that it feels more realistic for me to learn advanced OpenGL and finish what I started, rather than use UE4. And I suppose there’s nothing wrong with that. I just wanted to use UE4!

In any case, my recommendation in this post is:

  1. assume that not all developers are equal – assume that not all developers want to make the same ol’ thing over and over again.
  2. provide the power for developers to be creative with the functionality, even if it doesn’t fit your own games goals.
  3. focus less on the feature list, focus more on fully fleshed out – quality – features.

Thanks!

2

I think the biggest issue is their documentation tbh. I’ve only been working with UE4 for like 6 months, but in that amount of time I’ve only encountered a few things that required engine modifications. Most of the time, the feature was present, but poorly documented (a problem I’d like to help solve if they merge my PRs).

If you’re a strong developer you should be able to dive into the engine source code to see how they do things. Helps figure out the undocumented features.

Also, its probably still easier to modify UE4 than to start from scratch, but it depends on the type of game. 2d game engines aren’t too hard to write.

3

Cheer up, schetle, you’re not alone!

I agree with Brandon that documentation is a big issue. But I think you may have hit the nail on the head with your list, especially number 3.

I really, really like Unreal Engine 4 and am going to stick with it for at least the near future. And since my game is not a multi-player FPS, I’ve run into a lot of obstacles, just like you. However, I’ve yet to hit anything that couldn’t be fixed or worked around. And the effort it took to do so is more than justified by the quality of the engine. It’s an AAA engine for free. Don’t let the amazingness of that get lost when you run into little problems.

But speaking to your complaints, if I could change just one thing about the whole design of UE4, it would be to have the option of ditching the entire editor thing. It’s a spectacular feat of engineering, the way it recompiles code on the fly, interfaces directly with Visual Studio, plays the game in the editor, and so on. But I don’t know why any serious C++ developer would want it.

Visual Studio is incredibly good at organizing your code, compiling, debugging, and so on. So let Visual Studio do those tasks and don’t try to move them into the game engine. Having to say “Add Code” in UE4 every time I want to add a new class is infuriating. Any project beyond “Tappy Chicken” will easily grow to have hundreds of classes. Just let us create code the way we’ve been doing it for decades. If you want to provide a level editor, material editor, particle system editor, and whatever else, then please do – but make them independent, stand-alone tools and don’t force the developer to use this all-in-one environment for everything. Programmers (at least the ones I know) hate that kind of environment. Most can appreciate having the option to point and click and create a new C++ class (or whatever), but any experienced programmer looks at that feature and says “that’s neat” and never uses it again.

Where it really causes you grief is when you have to do something beyond the usual routine. Merging two projects, for example. I just had to do this and it was a nightmare. It’s a difficult enough process, even without the added complexity from UE4. You have to copy tons of files, rename files, change variable and method names, refactor, yadda yadda. But in UE4, now you also have to worry about all the added crud that the editor tacks on. Am I going to break all these “generated” files? Do I have to click “Add code” all over again for every class I’m bringing in from the other project? Uh oh, my class names can only be 32 characters long because of UE4’s arbitrary limitation. Hmm, how do all these C# files affect the build? Can I put some source in this other directory or will the editor not see it if it’s in there? Oh no, one project is from 4.7 and the other is 4.8!

None of that is a dealbreaker, of course, but it turns a task that should take an hour or two into a headache that takes multiple days. I’m sure anyone who just wants to play around with blueprint scripting finds the all-in-one design very convenient. I can’t imagine any experienced C++ developer finding it anything other than unwanted overhead.

Anyway, my advice is to stick with it, because there’s nothing out there that’s better. But I totally empathize with your frustration.

4

@Pat-Level17: I never use the in-editor Add code/class functionality, and almost never make use of hot reload either. These things aren’t forced on you, there’s nothing to stop you adding code manually or doing all your compiling from within VS.

It’s true there are a few restrictions with source folder hierarchies and such, these are related to having to use the unreal build system, not the editor specifically.

5

Hey Schetle,

Cheer up bud! :smiley:

I agree that documentation is still extremely lackluster but since 4.0.0 released, I’ve learned the majority through threads, AnswerHub posts but mostly through exploration. Also, many C++ functions have a plenty of comments in the source to help you understand what you’re looking at. For beginners, there are also a ton of awesome community videos on YouTube ranging from basic to advanced to help push you in many different directions.

Please don’t take offense but I’m confused at this one however… “provide the power for developers to be creative with the functionality, even if it doesn’t fit your own games goals.” I completely disagree that this is the case unless you happen to have a specific use-case that would require extra work (maybe an extremely large universe/persistent world maybe? That I could possibly see as a hurdle but is getting better). If so, you can still modify the engine and/or write plugins/modules to add the functionality that is lacking. It is true that Unreal Engine 3 was for the most part, targeted towards first person shooters however I never found a case where I wasn’t able to modify/adapt it for my needs, even in the case for a couple applications that weren’t even games mind you. I even created an extension via C#/UnrealScript to add Kinect support to UDK and control a character rig in real-time as well as a couple other crazy things the engine was never originally intended to support.

Unreal Engine 4 also comes with a ton of templates for different types of games so I highly doubt you are limited by the engine but if you are willing to share what you are trying to accomplish, maybe a couple of us could help point you in the right direction. :slight_smile:

I think saying that you want to tackle your own game engine instead from scratch as a more viable option (unless its a 2D game engine) is an extreme undertaking. I’ve had to do it in the past a couple of times and its a tremendous amount of work and would rather not do it again and focus on making great content instead. However, if you’re doing it from a learning perspective, then in that case I think it’s a great idea as you’ll learn a lot as a programmer and may even use your own engines instead for your projects. If so, I’d suggest DirectX12 as that offers more currently until the new OpenGL (Vulkan) comes out but if you want to get into some DX12, here is a link to the DirectX Tool Kit (https://directxtk.codeplex.com/).

Not sure if you have past experience with XNA but if you were a XNA dev, you absolutely need to check this out as this is literally the C++ equivalent of XNA updated by a couple of the guys at Microsoft on the Xbox Team. They constantly update it but you might see a couple very familiar classes inside if you’ve used XNA :wink:

Anyways bud, if you want, let us know what you’re trying to accomplish and hopefully we can point you in the right direction! :slight_smile:

Take it easy.

6

As a programmer, I disagree mostly. Sure, adding classes via UE4 is dumb and I never do it (because its optional). It was nice initially to see how the editor sets things up, and I’m sure it would be good for beginners, but having everything in a top level folder and what not isn’t for me. So what do I do? I add files in Visual Studio like I always have. And everything works just dandy. Same with hot-reload, I almost never use it as it’s super glitchy, but occasionally its really nice for testing something that I don’t know how to do correctly (saves me from restarting the editor over and over).

I love having the level editor, particle editor and all the other tools in one editor. It’s super convenient. There is definitely room for improvement, don’t get me wrong, but I don’t think splitting up the tools is the correct answer. They just need to provide more tools for power users, while keeping the editor easy to use out of the box.

7

Well, crud… Thanks and Brandon for pointing out that the “Add class” procedure isn’t mandatory. I assumed it had to be done in order to create all those “generated” files. That’s a big time saver. And one more reason I’ll be sticking with UE4. If only I had known this last week, though…

8

Just to further explain, the .generated.h files are created when you compile the project by the UnrealHeaderTool and is part of the Unreal Build System. It’s what parses out the U* meta data (UCLASS, UPROPERTY, etc). This tool is standalone and invoked by Visual Studio because of the build files.

9

Thanks for all of your responses.

I don’t have a specific big problem, it’s all the little things that add up to the annoyances.

I don’t have a team of people to dedicate to my project, so I can’t delegate people to investigate things the engine is missing or things that are broken. I have to take that upon myself, and it takes me away from my project - and when it takes me away from my project, then I lose the sense of great enthusiasm I have about my project where I don’t feel like I’m learning anything truly important, but rather I’m learning about Epic’s implementation of something which isn’t a guarantee.

My first go around, last year, I was building a project for Tablets that would be a point-n-click RPG. I found many resistances in places where I felt like there shouldn’t be resistances at all, like Pathfinding being used as the primary mode of operation for the player. Not only was it clunky, it lacked pieces of it I would’ve thought were a given - like cancel movement! I haven’t given up on this project, it’s just sitting in my projects folder waiting for my second-wind.

You might respond with, well you can do it with: <insert obscure hack here> and I would respond with: I’m not interested in hacks, I’m interested in a solid foundation upon which I build a solid system.

I’m seeing hacks all over the place for UMG, and typical answers are hacks. I feel like that is poor design. I don’t want to build on top of something full of hacks, I’ve experienced that in my day job and I’m not going to bend on it here. I take pride in well designed software, and I will take the time out of my day to make it good. Even if no one ever sees what I’m building, I like the craftsmanship of it.

My second go around, this past month:

Re-implementing my prototyped C++/OpenGL compositing window manager in Slate, for example. It took me several weeks in my spare time (full-time job, wife and son) to build out the compositing pattern with event capturing in my own OpenGL project with nanovg helping me out with scalable graphics with what I know of Cocoa as inspiration. Not only does it perform significantly better than UE4 with excellent cpu response time (I realize UE4 is doing A LOT, and I’m only doing UI so this might not even be valid), it scales properly on my Retina Macbook and lo-dpi screens as well and uses simple, proven patterns and data structures so it’s easy to understand and work with. I felt like it was a very solid prototype, and I was proud of myself for doing it. I began doing it over, but using Slate. Not even compositing or events because Slate has that covered. The dynamics I require in this project just doesn’t seem to exist in Slate without quite a bit of resistance. There’s nothing stopping me from even ditching Slate and going lower than that, it’s just a new can of worms that I’m not ready to open up yet.

The goal of that compositing window manager – taking it further, is to allow embedded Python to manipulate it; which I also finished in a prototype. But I don’t see that as a problem with UE4 at all, at least right now…

The point of mentioning this is that: I believe I feel more comfortable building from scratch, than prototyping in UE4.

10

Well, be fair, there is no engine in existence that is 100% fully implemented and documented and bug-free. Even if you go without an engine and program directly to DirectX or OpenGL, you’ll still find plenty of weirdnesses that you’ll have to work around or hack. This is the life of a game dev. Embrace it!

Yes, UMG is “hacky.” It’s very new.

Honestly, you seem like more of an engine developer than a game developer. That’s cool! Build us all an engine that is rock solid and easy to program. I’ll be first on your list of backers. I tried to go that route, years ago, and realized that having something like UE4 is a colossal time saver (if what you want to do is make a game, not an engine).

Just know that it’s tough to compete these days. The graphics features that engines like UE4, Unity, Cry, etc offer are extremely complex and are built on decades of evolution in what GPUs and CPUs are capable of. By the time you release your custom engine, it will be a year behind what everyone else is doing, sadly.

11

I absolutely see the benefit of using UE4, for it’s rendering capabilities alone. It’s quite a feat, and nothing I would ever be able to match. UE4 rendering is why I even attempted this project.

I’m not really interested in building an Engine – I’m not nearly knowledgeable enough for that, but rather tools for a specific environment and then build my game on top of those tools.

12

Sometimes I don’t understand what kind of developers they target. There is this whole blueprint system, which seems to me like almost a one-on-one mapping for calling C++ functions. What’s the deal with that? When you want to create a fully functional game, is blueprints really going to be easier? I understand it might seem more appealing to people who don’t know how to program, but do they expect that people without programming experience can suddenly make fully functional games when they have blueprints? With blueprints you still have to follow the same path as normal and translate your gameplay ideas into algorithms that the engine can run and making sure those algorithms are safe and robust and what not. That’s the hard part… without some background in programming, I don’t think you’ll be able to translate your gameplay ideas into algorithms with sufficient quality anyway. And (at least this goes for me), if you already have experience in programming, you’re not going to enjoy yourself with blueprints, you just want to code C++ :slight_smile:
So for what kind of developer is this blueprint system designed? For beginning hobbyist? Why would such an advanced engine target them as users? Wouldn’t they be better of starting in Game Maker or sometihng like that? Eventually Unreal should target professional developers more (if they want to make money), and focus their documentation more on C++ and the internal workings of the engine, and indeed, perhaps get rid of the monolithic all-in-one editor. and replace it with a more modular design that allows more flexibility…

13

I’ll preface this by saying I’ve been programming for 8 years and have a decent grasp of C++.

To me, Blueprint is a fantastic system for prototyping games. It allows me to iterate and test things out far faster than I could with C++. Eventually it does get messy and there are many things done easier in C++, which is when I will transfer most of my blueprints into C++ after things are working how I want.

Then you have non programmers. I’ve seen people with no programming experience whip up some pretty incredible things in Blueprint. Code scares people for some reason. Blueprint is nicer, things are more tangible. Then you have the use case where a programmer can create some complex functionality, expose it to Blueprint, and allow level designers and other non programmers to rapidly build things out without needing a programming to wire everything up. This is what I feel holds the most value.

I definitely see Blueprint as a prototyping tool and a tool for non-programmers (e.g. artists).

14

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.:stuck_out_tongue:

15

Very interesting thread. I have been silently complaining about lack of documentation in some advanced areas for some time. :slight_smile:

I agree with those of you guys who talk about modularity and pluggability. For an engine like UE4 (which is marketed heavily towards indie and mobile developers) it is extremely important. Imagine you are making a simple 2D game, like Mario or Tappy Chicken, in this case you won’t really need most of the features of the engine! You won’t need the next-gen rendering pipeline, you won’t need networking, you won’t need landscapes and foliage, you probably won’t even need PhysX. But all these modules will still be present in your game build and will waste memory and CPU and GPU times. I really don’t think it’s fair when a game with graphics from 1990s requires DX11 and has a 60-megabyte executable file. :slight_smile: The engine itself is very modular but some modules are still somewhat tightly coupled. Splitting them is much easier than if the whole engine was monolithic, but still isn’s very convenient. I really hope that some improvements will be done in this area.

Advanced documentation for programmers is also very important. While heavy engine modifications aren’t necessary in most cases, small changes to the engine might be not necessary but very useful for many projects (especially for the purposes of optimization). Understanding the engine is really necessary in the majority of cases. I come from low-level C++ programming background and I really like to know how things work when I use them. I think many fellow programmers will agree with me. We need a kind of map that can help navigating through the millions lines of code: we need to know what features and subsystems are implemented in the engine and where the implementation can be found. A nice optional addition would be some kind of design overview for the whole engine and for important systems: what goals a particular system was trying to achieve and how? :slight_smile:

For me, UE4 currently is the best engine on the market. But it could be even better! :slight_smile:

Thanks, Epic!

16

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.

17

An in-house engine may be a large studio’s better option. It entirely depends on their scenario. Just because a large studio is, well, a large studio does not mean it should roll it’s own engine. It’s all about using the right tools for the job, and sometimes UE4 will be the right tool, sometimes it won’t. There’s quite an impressive list of large studios using UE4 now, and you’ll notice that they aren’t using it for all of their games, just the ones that it is a good fit for.

As for small teams and hobbyists, unless their requirements are so simple that a commercial engine would be overkill, they should definitely choose the right tools for the job, and as many as possible! Time = money and game development eats up both pretty fast.

18

That’s fair enough. My main point of frustration right now is finding a suitable team and suitable funding. It doesn’t have to be outrageously profitable, just enough for a 1/4-time salary for the 2-5 team members.

I’m trying out Unreal because some of the things you mention do affect Unity 5 as well. For example, Unity 5 static lightmapping is still quite unstable for certain market segments.

As for Unreal 4, out-of-the-box I find many impressive things.

As for gameplay and shipping a product, that is something quite different because from my experience with web development, one can never deliver something 100% perfect all the time.

It’s what the customers and clients can deal with and not drive the development process into the ground.

I am starting to really admire groups of indie developers (say 2-5 team members) and how they work together and how they ship games.

Finally, as for the engine itself, I think that’s what the community is here for, it seems vibrant enough and the source code is all released… So at least there is somewhat less of a guessing game, of course a game developer is not expected to debug the engine, that’s what the Epic in collaboration with the community can do.

My 2 cents.

19

Would you be able to clarify further the areas you think we are lacking in the most and what we could be working on to help you and others?

We just merged some pull requests last week so hopefully your additions will be available and helping others very soon. :slight_smile:

That certainly sounds like something that would be very useful to a great many people. We will look into what we can do to make this available.

20

I can express my point of view, at least:
You guys need someone in “our level” to help writing clearer documentation; I.E, Unity has super simplified docs because they understand that not everyone using their engine, even experienced gameplay programmers, not all of them are in engineer level. I mean, there needs to be someone less specialized, but with a vast knowledge on the basics of how everything works in UE4 and how we put them together in a project, to explain (make docs) in practical and simplified way with code snippets everywhere.
I see people actually learning how to program in Unity because their docs are made and explained the simpler way possible thus most people can easily understand what they’re talking about. In your docs, you assume that someone reading through the C++ API has some level of experience with C++ frameworks, but since UE4 became free to use that’s not the case anymore and, a lot of people run away from UE due to lack of understanding your documentation well.
The same reason close to nobody is using CryEngine at all.
The community has few very dedicated people providing less specialized language in their public tutorials, but have no experience how to properly “educate” the C++ uneducated developer while not blocking them from keep developing their projects while learning.

For example, for the first time I had to load a third party DLL from a Plugin that I’m building and automate everything from plugin installation to standalone packaging, (how not break packaging and automatically copy the x32 or x64 files to the Shipping package when game is built instead of asking users to do it manually), and you have no idea how much I suffered to discover how to link external DLLs from within a Game Module Plugin, not breaking the packaging process…
How to do that should be in the “Plugins” section of your documentation, but all that is in there is a vague explanation on how the .Build.cs files work with no practical example.

Also an area of documentation dedicated to best practices and code performance is needed; uniformed new developers are building systems based on their own assumptions on how the engine works and for many times slow code is generated, even worse, some are selling these in Marketplace.