I wish and imagine UE4 to start up like this.

General Feedback & Requests
1

During production a user creates multiple UE projects constantly with different categories. For instance there can be a dozen new individual projects created to serve different aspects such as particleFX, animation, logic and so on.

Imagine every time a new project is created you have to re-optimize UE entirely and give it a restart or modify .ini files to somehow automate all this partially. Not only this but imagine you must do further optimization turning things off for packaging and performance reasons.

So I imagine an UE4, by default, to start up like this:

1- Menu pop up to choose if it is Forward rendering or Deferred and consecutively if MSAA or TAA should be used. (this prevents an editor restart if changed after). And a separate window for Mobile devs only choice with mobile plugins enabled only in that area.

2 - Strangely a “Blank scene” in library window startup comes in by default with Skylight, sun, an awful SphereSky :), atmosphere fog and of all things missing a postProcessVolume (ironically the most important element needed) because there is a horrible “Autoexposure” that is on by default.

  • A blank scene should appear by default without any of the above and “Autoexposure” turned OFF by default.

3 - Turn OFF ALL unnecessary plugins, these include:

A - All Android and mobile plugins.

B - All Mac plugins (Sorry mac users you are a minority, you can enable these if you need to), also tired of getting mac related errors during packaging randomly.

C - All VR plugins if there are any enabled.

D - All Google and cloud based plugins and other similar ones.

4 - My favorite: Middle mouse button invert pan ON by default, just like every other 3d software on the planet please.

5 - I’m sure there are others i missed.

This would be a good start.

Also It would be great if someone from the UE dev staff can take an hour and make a video or blog explaining what every single plugin is used for and why. It will help to determine what we can and cannot disable and if there are dependencies we should watch out for.

2

Different “presets” for the engine start are the kind of thing that should be the 1st priority on usability. Configuring the engine is a painfull thing to do on every new project. Unreal has too many “just fancy” things by default that can tank your framerate in no time, and they are a heavy barrier for newcomers. Not everyone should know how the hell all the internal “magical checks” of the engine works to kick a project starting.

3

We should have more options when creating a new project so we can uncheck all the plugins we don’t need. But we’d need proper descriptions on each, since we cant be sure whether it’s useless or not. We need to know what each plugin is for exactly.

Or we need an update on the tooltips of most of the plugins UE4 has installed by default.

Or when installing a new UE4 version, to have advanced options there, so we can uncheck whatever plugins we won’t need.

Or it should happen automatically depeding on that OS we are running on. If that makes sense.

4

Great suggestions. I agree that selecting “Desktop or Phone” and “2D or 3D” is not enough, simply because most of the games out there have many common, similar properties besides these ones. Of course the screen can’t precisely set up everything instead of you, but it should set up a good project settings / editor settings / ini template which is a good starting point for your type of game.

What might be a great reference is the way new JetBrains projects work. You select a framework, you select the most common plugins you would like to use (see attached), set up source control, and you’ll have a default project that’s relevant for your project.

For example if you currently want to develop a game which is using physics, the editor could ask you a few questions like:

  • Do you need physics in your game?
  • Is physics a critical game element of your game?
  • Does frame rate matter in physics simulation?
  • Is stacking, or energy conservation more important?

Et cetera, so even if you’re a beginner, you won’t face all the deepest and most disgusting parts of the engine in the first 15 minutes of development. Of course, in time, you can’t save people having to know what those parameters are doing, but I believe we should prevent them giving up on the engine in the first days, especially if all that’s missing is a checkbox tick, which is only mentioned in the 348th page of the answer hub in an unaccepted answer’s comment (but could have been easily deducted and set by the New Project screen if it actually asked if the developer wants localization support or not).

I also agree to update tooltips, but also in the project settings, like in physics “Enable Async Scene” says: “Enable the use of an async scene”. Wow. Unexpected. Thanks. Now I know if I need it or not. It could either be a short description when do we need it, why do we use it; and / or provide a link to a more detailed documentation. There are many tooltips which are great and very explanatory tho, others could follow the same example.

5

Hmmm… :confused:

6

This most likely won’t happen soon, if ever. I sound like a parrot at this point but people forget that UE4 is a big boy engine. Scales up to projects that have thousands of GB of assets in them etc. Last time I saw the new project screen was almost a year ago. You don’t make projects every day, and any serious project will tweak values regardless of any preset so for all intents and purposes making this would be a waste of man-hours.

7

Hey , I’m curious If you don’t make multiple project files how do you share assets with a team. I mean I can’t imagine sharing the entire core game project file when someone needs to work on a shader for one asset. Same for environment, or BP functionality and testing.

I mean these are all done in separate projects and then imported into the core one, that just has made more sense to us here, unless there is a workflow i’ve entirely missed?

If UE4 gives us an easy and quick way to save project presets It could prove to be a better option than having to setup everything again every time. I know some areas can be saved as presets, but it’s kind of all over the place right now.

8

Perforce integration.
Nobody should work a team project without version control in the engine.

9

Can you explain this a little further.

version control?

Edit: You mean something like TortoiseSVN?

10

I never ran an entire copy of a project in Unreal.
I only check out and develop specific assets in isolation on my own local project… Then submit the changes to the “real” project which is always a large beast stored in a Perforce server online where studio gives me a login and limited permissions to work on specific files/folders…

So “sharing assets through sharing projects” just seems like weird workflow to me. I thought everybody used Perforce.

11

At the place I’m employed at we’re using SVN, and on my personal projects I use Git LFS, choose one for your needs (but use one!).

12

I think you misunderstood me,

I didn’t mean sharing projects at all. I meant sharing specific assets like you put it. But in order to do that you need to be working in a “project file” in UE on your local machine or the same one. This “project file” needs to have the same settings or similar to the one that is being used in the main core project file which is the huge one where these assets will be migrated or imported to.

So in short if the core file workflow is using Forward Renderer with MSAA and a few other things turned off or On that are essential for a consistent development. Then the person creating the separate files ideally should have these settings in his local UE4 project file already applied. For example you wouldn’t want your shader artist working in deffered mode while creating an asset when you are using Forward as a main renderer.

As for version control, we found out using SVN type approaches to be counter intuitive in small teams of 4 or 5, at least for us. Coming from a VFX background we do version control in a different perhaps more traditional way but it still works just fine. And I know others do it in various other ways. As long as things are tracked and well organized.
So I guess this is a bit out of context to what is being discussed regarding the post.

13

So why you wouldn’t simply copy .ini files? Feature you’re talking about would be only an UI for editinig.ini file.
Should be enough if you’re interested in copying existing preset. And you could save many “presets” this way in cloud.

Adding such feature for brand new projects is extremely minor thing. It only saves you one editor restart during entire project’s lifetime.
If somebody would actually add it, it would be useful to expose all parameters which requires editor restart. Yeah, this way it could be quite useful.

BTW… SVN is the worst version control you could use in gamedev. The best thing about it you don’t have to pay for it.
Git is great for code, but not binary assets. And difficult to use for artists.
P4 is designed for any size of project, works awesome with small and huge projects. File locking is also essential while working on binary assets a lot. Basic usage is easy for everyone.
There’s also Plastic SCM, promising, but never used it.

14

I never experimented copying .ini files maybe I can try that next time.

15

Out of curiosity, how do you guys structure your projects for this to be a viable workflow? You need to have some sort of core folder with minimum functionality for the game to run, yes? Our project is still sub-100GB so we all have the entire thing copied over but I feel like we’re gonna have to think about this set-up before long.

16

Blueprints (and code) are designed to be self-contained.
This is why I make so many plugins. Almost everything I submit later to “my module” which is a set of systems I designed like it was meant to be uploaded to the Marketplace and should work on any project…
When someone change base classes type/names they have to warn when submitting to Perforce. But in general, there’s no hard-references or strong dependency on anything outside one’s module.

Artists sync larger amount of assets, but the majority of my levels are sandboxes for tests that don’t even exist on the real project.

And yes, a new project is just a copy of the original uproject file and its Configs, as mentioned above that’s the same result of copying a project “preset”, the skeleton of the project is simply downloaded from P4. We just don’t use the same map assets and don’t commit maps either, somebody is responsible for keeping final versions of real maps on real project (level designer).

17

Makes sense but how do you make this work in practice with something as “global” as say, the game mode, player pawn class etc?

18

Everyone build their own binaries from source code.
GameMode classes (main game module sources) are always the same for everyone.