Going to rant a bit before switching engines. I came to Unreal because of their world partition feature. But now I’m leaving in part because the process of simply deleting a cpp file (which should require no troubleshooting) is INSANELY difficult and time consuming. This is the WORST designed thing I have ever seen in a game engine. It is just… unacceptably bad. Whoever made the cpp features very obviously has no UX sense whatsoever.
Don’t tell me that cpp is complicated or that it’s impossible to sort out references. These are crap excuses. At the end of the day this is a terrible product, and the designers ought to be ashamed for shipping it in the state that it is currently in.
To delete a C++ class you should first make sure no assets in your project depend on it.
To help with finding those referencing assets you can right-click the C++ class in the Contend Drawer (make sure “Show C++ Classes” is enabled in the Content Drawer’s settings) and select Reference Viewer:
This will list assets that use classes in your module:
This list will contain all classes in your C++ module as the module itself is the most granular C++ unit we can reference. If you have a lot of classes there you might be better off using Content Drawer filters to see if any assets have your class as a parent class:
Then you can delete the .cpp/.h file from explorer:
Regenerate the solution and then launch your project from Visual Studio (or whichever IDE you’re using to build it) to launch UE without your class:
That’s the same as deleting a class in any language or game engine?
No, it’s not! This statement could not be further from the truth. In every other language or framework I’ve worked in, if you delete a class, then the IDE gets populated with errors, and you can fix them one by one at your leisure.
However, what UE5 does is just terrible. They bar the user from deleting the file to begin with. If they try, UE5 logs a cryptic error message. The UE5 dev must google that error message before being able to delete their file. They will find that the must learn how to use a clunky, jargon laden interface only comprehensible to people who are already veterans of the engine. After going through this infuriating process, sunk cost fallacy will kick in and they will stick with their choice to use UE5 despite coming to know its many flaws
It did not need to be designed this way. They could have just allowed the user to delete the file, then logged readable, jargon-light errors in the files where there are references. The error messages would tell the user that the references are referring to a deleted class, and nothing more. This is clearly MUCH better.
The technical specifications of C++ are not relevant here. This is not a bug or an issue with any technical aspect of engineering. It’s a design mistake, not an engineering mistake. It was designed badly when a better design was available and could have been chosen.
People like to view Unreal as the “Dark Souls” of game engines. It’s difficult to learn, but once you do, it feels like an accomplishment.
This perspective is extremely common. The people who love this engine want it to be difficult to learn in the same way a Dark Souls fan would not want the game to be easier.
However, here’s the harsh reality: although this is fantastic for Dark Souls, this is an objectively terrible perspective to have for game development. If an engine is easier to use, learn, and has better usability, then the devs who use that engine will be more productive and better at their jobs overall.
The design of UE5 is bad in some ways because it tries to be the “Dark Souls” of game engines, and there are a lot of fools who think this is a good thing.
Most of the extra layers of complexity come from the interactions with blueprints and some technical debt.
The cpp isn’t just a standalone file. It has it’s .generated counterpart used to talk to the blueprint layer. All of this has the extra layer of using redirectors instead of GUID’s that can identify assets in the engine (when you move or rename assets the changes are described in redirectors).
Some of the design decisions are also geared towards larger studios where data is spread out over many systems, that’s why there is another layer of abstraction.
Could it be done better, sure. I’m guessing rewrites of major systems to clean this up would take months to years. It would break many systems along the way. Something the engineers probably don’t want to risk.
For now Epic seams to be focusing on engine performance trying to battle the infamous stuttering of shader loading / compiling.
I’m all for simplifying things. The less moving parts the less things can break, but I am just a user like you sitting at the sidelines.
On the other hand as a programmer of systems myself I also know how tough refactoring can get when your codebase is millions of lines of code.
Quite literally all you need to do is delete the files. Personally, I delete them in windows explorer and remove them from the solution. It’s quick and you don’t even need to leave the IDE.
For obvious reasons, you can’t delete a C++ class from the editor. I don’t see how you could expect to do that anyway.
If you have serialized data/assets using that type, they will (obviously) be broken.
