Improve the Gameplay Framework by making it Opt-In, Instead of Choiceless

General Feedback & Requests
1

Today I want to talk about the Unreal Engine’s big assumption, the Gameplay Framework.

Yes, I know the framework has a lot of useful content built into it, and yes I realize that it provides a ton of benefits to users of UE4. However, the lack of choice you give developers when working the the framework is really very disappointing and frustrating.

UE4 developers should, by default, opt-in to using a feature in the gameplay framework, not be forced to accept everything with no questions. However, as it currently stands when you create a new project and create a blank level when you hit play you are automatically given an immense amount of things with no choice in the matter. For instance you are given a AbstractNavData-Default object, a GameMode object, a CameraActor object, a GameNetworkManager object, a GameSession object, a GameState object, a HUD object, a ParticleEventManger object, a PlayerCameraManager object, a PlayerController object, a PlayerStart object and a PlayerState object. None of these were explicitly asked for they are simply given to the developer and no options are presented to the developer asking if they want them or not.

The only choice someone can make is to remove the default spawning Pawn, that is literally the only thing that we are allowed to opt out of. Of the 12 different things that are forced on the developer most of them are simply not necessary and a waste of space and processing, for instance why is the AbstractNavData there if we haven’t set up a navigation mesh or added an AI controller or Player controller that can interact with a navmesh? Why is the GameNetworkManager there if we don’t intend to utilize multiplayer? That should definitely be a choice given to us, no? The same in regards to the GameSession. Why do we need a ParticleEventManager if we don’t even have any particles yet? Why aren’t these things introduced when we actually utilize the feature, or why aren’t we able to choose when we want to use them?

The point being, the developer has a bunch of potentially unwanted classes thrown at them by default, there is no choice in the matter, when the choice should most definitely be there. Why do I need a CameraActor and a CameraManager if I’m going to create the camera and manage it within my own pawn class? Instead it will just end up sitting there doing nothing. Why is it by default I get all of Epic’s assumptions about what I’m making thrust at me with no choice in the matter? If I don’t want multiplayer bits don’t give me those bits, If I don’t want you to create a bunch of camera things for me then don’t create a bunch of camera things for me, stop baking assumptions into the editor and stop forcing us to follow your framework. Yes, the framework is useful, yes being able to move around your level by default in play mode can be helpful. However, why is that something I get no say in? If I don’t want anything by default, then gee, I should be allowed to remove those components without banging around in the internal engine code.

This is my call to action for you, Epic. Improve the gameplay framework by making it optional, developers should be able to grab the part that they want to use and be able to setup their own default spawning without having to compete with your version. The framework should be clean enough that all of the parts are okay to be separate from each other, they should be able to be opted into piece by piece without issue. If I want to utilize a player controller let me spawn one for myself and then allow me to spawn and attach a pawn to that player controller, don’t force me to accept your assumptions, nor force me to repeat your logic if I don’t want to use yours. If I want to utilize the game mode then let ME tell YOU that, don’t force me into it.

If the answer is that you think I want them, check your assumptions. If your answer is that you didn’t design these pieces to standalone then perhaps you should recheck how hard you tried to make this a generic framework, since I know that you like to constantly assure everyone that UE4 was designed to be completely agnostic of game genre and workflow.

2

This sounds kind of ridiculous. It screams “premature optimization” at me. Why are you asking for this? Are you getting performance problems in a blank project which includes these framework classes? If so, that’s only a hardware upgrade away from being resolved.

To play devils advocate for a moment, try to imagine how many extra forum posts and answer hub questions people would have if the workflow to get a project started contained a whole bunch of extra esoteric steps which required intimate back-end engine architecture knowledge. The barrier for entry for new people would be much higher, and that’s bad for business. If a class isn’t used, then its update (tick) loop is very quick and the performance hit is minimal (like, nanoseconds!). I would challenge you to show empirical evidence which shows a non-trivial measurement of performance loss due to unused UE4 classes included within a project.

3

I must have failed to explain myself well, this post has nothing to do with optimization nor performance issues.

In fact I’m not particular sure where you got the idea that I’m complaining about performance in this post. I imagine it was the line about wasting resources, so I don’t fault you for jumping to that conclusion.

However, the purpose of that line isn’t to indicate that there is some performance issue due to the framework its purpose is to highlight the fact that you simply CANNOT remove those components without rooting through a ton of engine files, you are literally forced to have these items in your scene whether you want them or not, and whether you end up using them or not. It has nothing to do with the theoretical performance hit and far, far more to do with the fact that you literally aren’t given the ability to interact with the gameplay framework in anyway, the engine simply throws it up on you, shrugs and says “Use it or don’t, I don’t care.”

The goal of the post is to get Epic to seriously consider the ability to disable the default behavior of the engine, which is described above, and allow users to simply work with the framework as they want to, without attempting to sidestep all of the default behaviors that the engine thinks you would want. You might think that this would be a super simply task but its rather annoying to have to work around the engine’s assumptions, try it for yourself.

In regards to your “devil’s advocate” attempt, think of it this way, I don’t actually care if this is the default behavior, keep it exactly how it is currently, just add the ability to set all default spawn objects to void like you can with Pawn and/or add a check box in game mode that allows you to disable default behavior. This literally wouldn’t cause any change or any difficulties to anyone, in fact it would probably help a lot of people who don’t want to fight there way through the poorly documented gameplay framework. After all, how many questions like “What is the GameMode for? What is a GameState for? What is a PlayerState for?” are there out there, I’ll answer the rhetorical question, a bunch. Literally, the only reason to fully utilize the Gameplay framework is the multiplayer benefits, exclude those benefit, aka, if you aren’t actually trying to create a multiplayer game, and the gameplay framework as a whole isn’t very compelling. Most single player games would only take from the framework a few things, the controller classes, the pawn and character classes, potentially the GameMode class; but other than that not many things are desirable.

Now, as to why this isn’t “bad for business” and a massive barrier for entry, lets just follow an example.

Take an actor, lets call him ASetupLevel, we can give him a few UProperties that relate to the classes that we want to have on this level, like our GameMode, our PlayerController and our character class (Lets ignore the fact that GameMode isn’t actually meant to work like this [which is silly, , since it really does a lot more than the documentation insists it does, and it shouldn’t] [maybe we can make another GameMode that is called GameModeActor and people can use that to spawn a “GameMode” in their level, since obviously SpawnObject isn’t nice for new people either, right?]). Now on ASetupLevel’s BeginPlay, we just dragged the object into the scene in this case, all we do is spawn and setup those classes, WHAM BAZAM BAM, done. That isn’t a particular difficult thing to teach people.

Alright, what if they want to spawn things at Epic’s absurd PlayerStart? Well Epic just creates a function in UWorld that lets us grab a list of all the PlayerStarts on the level and add a SpawnActor that accepts APlayerSpawn as the location and rotation values. And while they are at it epic can add a variable on the PlayerStart to make it easy for new people to specify what they want to call the PlayerStart (An FString, or what have you), which UWorld can then use to find the precise PlayerStart they want. Notice that these changes actually GREATLY demistify for new people what is happening, most people probably haven’t looked into what exactly is happening when PlayerStarts are being selected at the beginning of play, and thus its just “magic” to them.

And what if you want nothing to change? You love Epic’s system sooo much. Well then, you simply don’t disable the “Disable Default Behavior” check in your GameMode properties.

5

Well the issue is that there is no support for this first and foremost and secondly disabling these actors by overriding the GameMode functions sounds like a great way to introduce instability and bugs into your code when things that are supposed to have happened never happened because you override your GameMode functions (and I assume never called to Super).

Also I can’t find where in WorldSettings you are supposed to disable the Navigation one and where you are suggesting I am able to remove the GameNetworkManager and ParticleEventManager from?

I don’t need the camera because I give cameras to the pawns that I’m controlling which are utilized by the PlayerController when it possesses the Pawn, so I don’t need one thrown in for good measure.

And finally, the point is that I do want to utilize the framework, part of it at least, my desire is that I don’t have to pretend that the defaultly spawned framework pieces don’t exist and would much prefer I don’t have to mentally sweep them under the rug and pretend that they don’t exist, I’m not sure why your encouraging bad practices like that.

7

In almost every case it would be a terrible idea to roll your own any-of-those-things. If you want to write even the most basic stuff from scratch, why are you not writing your own engine? If you don’t want to write even the most basic stuff from scratch, then why do you consider it desirable to have less functionality available to you? Is your complaint just that more options show up in drop-downs than you currently have a use for?

The only practical example I can see is this:

“If I want to utilize a player controller let me spawn one for myself and then allow me to spawn and attach a pawn to that player controller”

You can do that in UE4 in like five seconds.

8

Alright, I give up, no one on these forums cares about cleanliness nor the principle of only paying for what you use, that’s clear to me.

It’s obvious to me now that I shouldn’t expect anything to come from discussions about non-standard workflows, I understand that now.

You all win, you’ve fatigued me, I won’t keep debating the merits and faults of this idea against a wall.

10

I guess that’s “The Good, the Bad and the Ugly” when an engine company also making games: they put what they need in the engine.
The methods like “ReceiveAnyDamage/ReceiveRadialDamage/ReceivePointDamage” in Actor always remind me that UE4 despite it’s already in 4th generation still got its big old FPS heart beating inside.

11

I don’t think anybody’s flat-out against non-standard workflows so far in this thread, I’m certainly not. You just don’t seem to be making much of a case for (or even making it completely clear what) you’re proposing.

12

I apologize for my previous reply and appreciate the responses that came after it.

To alter the direction of the conversion to something more productive, what would you guys suggest as the most beneficial way to separete my logic from the base implementation of GameMode, the ideal is to ignore the logic that is implemented in GameMode surrounding the entry point into the game, because, as Chariots said:

Whereas my goal IS to disable that logic and allow me to define my own entry point into my game. It may not be the supported workflow, but I’d much rather be able to ignore the GameMode and use my own class which acts as the scene manager, in charge of level initialization and what not, since I’m procedurally generating a bunch of stuff at the beginning of the level (tiles, the environment, monsters and waypoints for tile based movement, etc) and storing all my level information in that class. And I don’t want to use GameMode for this since I want to be able to have multiple of these particular class objects spawned in a single level, for instance this lets me nicely define different “phases” of the level, i.e. a beginning phase with one environmental theme, a middle with environmental theme, and a final with a third theme.

Because at this moment all I’m doing is disabling the GameMode from spawning a pawn and then ignoring everything else it spawns, which is a pain because it creates a lot of duplicated objects for me, for instance two player controllers (one mine, one theirs), etc.

My goal, and what I was hoping to get across in the post, was the ideal of being able to simply have a nice little bool in GameMode that allows me to shutdown its default behavior so I don’t have to stumble through the junk it creates by default.

If my goals aren’t clear please just ask for clarification.

14

I don’t know about Game Mode, Game State, or Player State, but the engine does rely on Player Controller and the viewport (hence the Camera) for a lot of things, such as knowing which world to act upon. The Player Controller and viewport are absolutely non-negotiable, but the other objects, as far as I know, can be safely disabled from a technical standpoint. I just don’t see why you’d want to since the only overhead they add are at the beginning of the game; these other objects don’t tick unless you have Tick logic. The only downside to having them really is clogging up your scene outliner with some extra objects.

15

It has been Epic’s stated goal to move everything to a more plugin based model that you can pick and choose what you need, and recent updates made that more and more possible. It is going to take a considerable amount of time for them to complete though. Probably years. Even then, there will probably be plenty of things that stay in the core build.

16

Lot of people misunderstanding what engine is, lot of people see it as “graphical engine” which is really isn’t. Engine is a base system for game, it has basic gameplay, world and object systems and responsible for rendering it. You can’t replace GameMode, PlayerController etc. because it’s integral part of engine’s central world menagement systems, but you can modify it or even override (not sure) to make world work diffrently

https://github.com/EpicGames/UnrealEngine/blob/8a80b5541f69a79abf5855668f39e1d643717600/Engine/Source/Runtime/Engine/Private/World.cpp

You need to keep in this engine was originally made to power single game (that lot of people forgot for some reason) which engine inherits name from, called Unreal:

And the way game framework is structured, didn’t really changed ever since. If you learned framework in UE4, i can guaranty you will find yourself in UE1 as well as diffrent UE versions very easily because everything is mostly essentially the same. Thats why in UE4 it’s easier to make action game, where if you want to do something else you need to work a little more. Before UE4, Unreal Engine even had inventory system with weapon system build in, which got (thats my guess, i know UE1 3rd party games used it anyway) removed as it being rewritten by 3rd party developers anyway as that inventory system was made for shooters (but personally i made work with different kind of game).

Now i don’t understand your frustration over spawn system which seems to be your main problem, I gonna supprice you … personally i never used it even in UE3 (UDK) due to nature of game we are doing which don’t need spawn points. All you need to do is to set default pawn to null so default spawn system won’t do anything and on BeginPlay of GameMode spawn actor where ever i like to and make PlayerController posses it. If you are worried with overriding it keep in mind you can just use super call and you can always view source code to see what you overrideing and see what potentially you need to rewrite, thats why it’s avaiable or you to see (a lot better situation then with UDK where some bits been done inaccessible C++)

As for cameras and CameraActor, CameraActor is nothing more then actor with Camera component (https://github.com/EpicGames/UnrealEngine/blob/8a80b5541f69a79abf5855668f39e1d643717600/Engine/Source/Runtime/Engine/Private/Camera/CameraActor.cpp) it’s really passive object which technically do nothing. The way camera system works in UE4 is that you have CameraManager which has set target view which is the selected actor and it asks on every frame that selected actor (which don’t even need to be physical actor, it can be GameMode or PlayerController) by calling CalcCamera function which is in every actor and by default it serches for camera component inside actor and set camera position at it… thats why CameraActor is so passive. You can override CalcCamera and set camera postion whatever you like, you can make managing actor which will manage camera position and set it as view target. Just remeber to set bAutoManageActiveCameraTarget to false in CameraManager, or else it will automaticly set view target on possession

As for modularity that Zeustiak mentioned, UE4 is already modular and you can opt out most of modules if you wish (but some modules require other modules to work so you need to watch out) by editing build scripts (i think, never did that but i know it’s possibility), plug-in system is just for easy distribution of 3rd party modules i don’t think engine modules will be ever be like a plug-in, there probably be different menu for that or somethign else, but who knows, thats a option too. But things like GameMode and PlayerController can’t be seperated, since again it a core of world management system and all of them are coded inside module called (suprice, suprice) Engine, so if you would seperate them, you would need to use them anyway as core module would refrence to them or make lot of macro flags to build specific potions of the code which would be nasty.

So yea if you use UE, you need to use it’s framework or modify engine all toghther which you can do too. But framework is not that bad either as i showed in 2 examples, you just need to learn how to hack it and modify it in non-invasive way which is not that hard once you learn how framework works. Looking on problems that people dealing with on anwserhub it’s good that that framework is there, since most people would not do what you want to do, they have problems with very basic things.