I am wondering, as a fundamental Game Design philosophical / theoretical / practical choice, whether there are any compelling reasons to not give the final end user / player access to the UE4 Dev console.
So fundamentally I’d be shipping the game not in shipping mode but in Development mode.
I’ve already overridden the cheat manager to disable all cheats, forever, via the player controller class.
Is there anything else I should be aware of?
Other console commands that players just should not have access to?
Keep in mind I am making a competitive multiplayer game with e-sports potential.
But I really would like to allow users to use console commands to accelerate their help with early-release debugging, just additional tools that are accessible to the UE4-versed end user.
Are there any other significant console commands to nullify besides the cheat manager?
Please note this is not a legal question, I am more-so asking if anyone knows of console commands that no one should have access to during competitive play that are not Cheat Manager commands.
I am not sure how powerful the dev console is, but I am pretty sure that a player is able to do something in it that gives them a competitive advantage in a multiplayer game (change render settings, print other player positions, etc.).
Also, does shipping the development mode mean that your code can be opened in a debugger? If so, there is nothing to stop a player from doing all kinds of things you would consider “cheating”.
Wireframe should be disabled (it can be used as a see-trough-wall hack), unlit mode should probably be disabled too (the different contrast could give a visibility advantage in shooters for example).
Also show collision etc.
There might be more commands that change what is visible.
I like the idea though… at least I think most of the rendering commands (those starting with r.) should be available in all games to allow for more in depth graphic settings fine-tuning.
Hackers don’t need debug symbols to make these cheats. They don’t even touch the game, they go directly into the DIrectX API.
But shipping Development build will allow them to look into the code just like if it were a .NET program, anyone with intentions will see what is in there.
Yes, there is no 100% protection against cheating, you can only make it harder for people to cheat. And I think giving out the dev build invites a lot more people to cheating.
I mean who knows how to use the DirectX API to manipulate the game? And how many of those play your game? Probably not many.
A lot more people know how to use a debugger.
But, if you limit the “dev” part of your game to the in-game console with a whitelist of commands then that would be cool
Ahh that’s a great point about wireframe and various collision renderings Thanks!
Yes bugitgo and all the other cheats are disabled very simply in the player controller class, I learned through experimentation:
//Disabling the UE4 Cheat System
public:
virtual void AddCheats(bool bForce = false) override {}
I would love to show you game footage, I can’t yet but as I am getting closer to release / steam greenlit I really can’t wait to share with you all what I am up to and develop a beta testing crew with all of you invited
There are some advantages to granting full access to the developer console if you wish to allow 3rd party modding. Most game engine though will only allow this ability via command line switch
I have not used it (yet), but there is a ‘Test’ build configuration which sits between Development and Shipping configuration. It allows console etc but running on Shipping configuration but it may need to be enabled.
You should be able to make a custom interface for entering console commands, like a widget with a text box and have the text in there go and execute a console command. You could also have it check for any specific commands that you want to disallow.
