What exactly prevents you from releasing the console as it is now?

I know you've said before that there are technical limitations which prevent you from putting the console in the released game as it is now, but I'm curious as to exactly why that is. I can see how something like a level editor would be designed to work with internal Volition systems (like network servers and source control systems designed to release content, etc.) but I don't know how something like a console, which AFAIK only does things internal to the game, can require anything extra that you can't release. I'm not saying I don't believe you or anything, of course. I'm just wondering why it wouldn't work if you release it in the final product. Certain commands may require things that can't be released, but if the console were in my copy, wouldn't those functions just give an error? What exactly is different between a development build (which includes the console) and a release build, that prevents you from releasing it?

(I'm aware knowing this won't necessarily help with making any mods, but I can certainly see it being of interest to the community.)
 
Last edited:
The console isn't designed to work internally only like the editor, but instead it is scattered across thousands of source files and not wrapped in something easy to enable by itself #if defined(__CONSOLE), but instead #if !defined(__RELEASE_FINAL). This means that all the other code that is not made for the final version of the game would be enabled at the same time and we simply can't do that. Someone has to take the time to dig through all the files and find code related to the console and manually change the ifdef to something that we can enable by itself. Then we need to go through 8 years of console commands to find out what works and what doesn't and try to clean it up some. I agree the cleanup can come later, but it is just a pile of manual labor. :)
 
The console isn't designed to work internally only like the editor, but instead it is scattered across thousands of source files and not wrapped in something easy to enable by itself #if defined(__CONSOLE), but instead #if !defined(__RELEASE_FINAL). This means that all the other code that is not made for the final version of the game would be enabled at the same time and we simply can't do that. Someone has to take the time to dig through all the files and find code related to the console and manually change the ifdef to something that we can enable by itself. Then we need to go through 8 years of console commands to find out what works and what doesn't and try to clean it up some. I agree the cleanup can come later, but it is just a pile of manual labor. :)
What kind of other stuff is there that isn't intended for the final version that you don't want to release?
 
If i had to guess, stuff that outputs text to the console and to the screen to help understand what's going on in the engine at that moment. The visual elements could be distracting. It could be things that add a significant performance hit, because while you're debugging, framerate isn't the most important thing.
 
If i had to guess, stuff that outputs text to the console and to the screen to help understand what's going on in the engine at that moment. The visual elements could be distracting. It could be things that add a significant performance hit, because while you're debugging, framerate isn't the most important thing.
This wouldn't be the most elegant solution, but what are the chances of including a separate EXE with all that stuff compiled in? That would be pretty cool.
 
This wouldn't be the most elegant solution, but what are the chances of including a separate EXE with all that stuff compiled in? That would be pretty cool.

Saints Row IV uses CEG encryption (custom executable generation) so that each user gets a unique exe. Releasing a separate exe with the console like you're suggesting is simply not going to happen.
 
Saints Row IV uses CEG encryption (custom executable generation) so that each user gets a unique exe. Releasing a separate exe with the console like you're suggesting is simply not going to happen.
No, I mean it could be included in the files downloaded from Steam. That EXE could be encrypted as well, of course.

(Off-topic for a second, I really wish Valve had thought of people who want to modify the game's EXE when they designed CEG.)
 
The big problem is that the non RELEASE_FINAL version will have a large amount of debug information in it. (Because it's for testing and you need to see what's going on when something breaks). So in essence they will almost be giving away their source code. As programmers I'm sure they would love to do this but as a company, that needs to keep a competitive edge, they know that they can't.
 
The big problem is that the non RELEASE_FINAL version will have a large amount of debug information in it. (Because it's for testing and you need to see what's going on when something breaks). So in essence they will almost be giving away their source code. As programmers I'm sure they would love to do this but as a company, that needs to keep a competitive edge, they know that they can't.
Ah, I forgot about that part. Still, there's probably tools to remove that, but I guess they could always miss something.
 
Also keep in mind that hind sight is 20/20. To really make a game that malleable you have to build it like that and from my experience you rarely get something like Saints Row. I have long felt that Saints Row's greatest achievement has been insane stability. Like when Havok loses it's mind and you are lodged inside the geometry of a burning car, and then suddenly you respawn a few feet away. Bethesda's "Creation Engine/GameByro" gains flexibility at the expense of stability. Similar to Valves Source engine. These engines where designed from the ground up to be easy to manipulate. I'm not a gaming engine guru, I just know that the more a game is aimed at being mod friendly, the more likely it is to crash, lock up, have various graphical errors, or stutter, no matter the platform.
 
Back
Top