Hard-coding games vs Soft Coding games.

[gargantual]

This ones for anyone whose dabbled gone deep into or has some idea of the game programming experience. I really could've just made a curious email to Shamus Young but ahh what the hell. Just consumer's curiousity. Not looking for a direct answer, suppositions and guesses based on varied experience are just fine too.

After reading about modders fixing the features for Watchdogs back to E3 2012 graphics, and thinking about other games that allow for easy patching or are expected to like GTA 4's, driving fix, or Max Payne's sound fix vs AAA games that just play vanilla or uncomfortable on PC

I couldn't help but wonder are there more reasons why developers in AAA or those using graphics heavy engines hard-code their games in very fixed ways vs. soft-coding to allow for changing data and features to come from multiple outside sources.

Is it entirely because of DRM? - to inhibit how the game is played (hard coded), as opposed to encouraging easy modification, continued player interest and user generated content (soft coded)? This is what I strongly suspect but can't really say as a consumer.

Or are there other practical internal reasons.... such as keeping the development process uniform stable and organized, and dealing with other programmers experience, different middleware and tools?

I know...weird post but can't shake the thought for some reason.

 

[josemlopes]

To me I think that its very related to both DLC and product control, if people start doing their own levels and weapons (shit, even skins) then there isnt much reason to buy the DLCs (or at least it wont justify them as much).

I honestly dont think its that connected with DRM, there are plenty of heavy DRM filled games that do have some mod support, even GTA 4 had how many? Securom, GFWL, Rockstar Games Social Club and Steam if you went with that.

 

[Weaver]

I really don't understand your question to be honest, I'm finding it vague and unspecific with confusing use of terminology.

Hardcoding means that (at least in the world of software I work in), say, my character has a height of 10 in-game units I will simply use "10" every place I want to do a calculation with a character's height. If I want my character to jump twice his height, I would say 10*2. If I wanted to see if he could fit into a door I would make sure the door is > 10.

If I wanted to change his height to 8, now I have to find every single place I used a 10 and turn it into an 8. I've hardcoded the 10. This particular case is also what we call "magic numbers".

A better way is to say write:
int getCharacterHeight(){
return 10;
}

Then I only have to change it in one place.

Similarly, softcoding is not used as a positive term. When someone says something's been softcoded it means you've abstracted so much out of the program it's become a maintenance nightmare.

Imagine the game wouldn't run unless I added a config file that had the player's height, which never changes. Furthermore, this may be accessible to the user and now they've just broken the game you made because they made their character half as high and all your levels were designed with them being a certain height and being able to jump a certain distance.

Basically, for the sake of sanity when developing something, you simply can't make everything input. It will make everything 30x longer to make for no actual reason.

Anyways, I don't think I know your real question here, sorry x_x.

 

[MeChaNiZ3D]

From my limited knowledge of programming, soft-coding is just good practise and makes everything you write easier to expand and re-use. If there's obfuscation I assume it's either product control or people being lazy as they try to cram things in that work and call it a day rather than build an accessible system.

 

[Jadak]

Typically it has more to do with the development process. Generally, it's fairly easy to develop in a manner that leaves any sort of data in a user-editable format, and taken far enough that can lead to a fairly high level of user customization. The same is also often true of things like art and audio assets.

However, the actual code handling game functionality is a different matter. Generally speaking, it's going to be compiled from the original source files the developers used and from that point effectively beyond editing, and there's not a simple way around that short of releasing the original source code, effectively giving the public complete access to all of your work, not something a studio with potentially millions invested in that code is likely to do.

When you get things that do seem like arbitrary values yet can't be changed, it's likely going to be a design choice, simply a case of the developers leaving said value in actual code that gets compiled along with everything else. It could simply be an oversight, or it could have been viewed as impractical to try and abstract the file into a static external value.

When all is said and done, any given development process can vary by about a billion factors, and can only really be judged on a case by case basic. But for the most part, it is very impractical to make the actual functional code accessible to edit.

 

[nomotog_v1legacy]

Hard coding something makes it easier to get it in. You just code it in. If you want to soft code something, you have to write code to import and export the data. Though if you have a lot soft coded, then you have an easier time making changes as you can have non programers making changes in config files. You will see more soft coding in games that have a lot of stuff that is repeated. Like in an RPG where you can have a 100 swords that are really just shifts in numbers. It's worth it to write the code to let you just import them on mass. Meanwhile, if you just have 4 weapons that all need unique code, it's less time to hard code them.

 

[ThriKreen]

I couldn't help but wonder are there more reasons why developers in AAA or those using graphics heavy engines hard-code their games in very fixed ways vs. soft-coding to allow for changing data and features to come from multiple outside sources.

I think you are mixing up two types of development practices.

1) Data-driven design

The term for the first issue is "data-driven design", where various options are handled in external files (config text files, .XML or some binary database file). It makes it easier to change the game parameters on the fly to see the results right away (or after a restart), instead of having to change a value in code, recompile the whole game, then start it up to see the changes. Iteration is the key issue to resolve here.

As for why some options are locked away, sometimes it could be something used for promo purposes (i.e. render out the game at 4k resolution for print purposes), or hidden because they are dev options that the regular player shouldn't have access too (i.e. alter rendering order in a multiplayer competitive game).

Or they locked some options off for a console release, where the hardware is mostly known and standardized, and didn't bother to expand and expose them for a PC release (most likely).

And of course, there's the usual PEBKAC issue where the user could potentially muck with the config files too much and render their game unusable. At least locking it away offsets a support nightmare.

2) Modding

The second issue is exposing part or all of the game engine behaviour to the user in some scripting language: LUA (most common), Python, UnrealScript, NWScript, etc. The advantage of this system is that usually being a language that is interpreted "on the fly", or at least separated from the game code, you skip having to compile the code before hand. I can't image what a support nightmare it might be to also have to explain how to install a compiler and editor for that.

You have to write an API to hook the game code to the scripting language, which often runs into the problem of how much to expose and such - expose too much and again, someone could cheat or ruin their game install by mistake, run into sync issues with multiplayer, the usual. Plus, often they'd only expose what's required for the base game, and not have to think "Well, maybe someone, somewhere will want extra options for this action, add some extra parameters". Then on top of that, tons of error checking to make sure it doesn't break the game (seriously, I think half my code when writing art tools for artists is error-checking and data validation).

Replacement of graphics, again, depends on the complexity - some games might use baked lightmaps and require a renderfarm, do you want to include a 24 cluster rackmount to everyone doing environments? I recall the pipeline changes from NWN to DAO, and yeah... things got complex, even with some of the streamlining I did.

Unless you make modding a big part of the game design for release (see: Valve and Source, Bethesda, NWN, less so Dragon Age Origins to DA2), it's a lot of work to expose that stuff, as well as write documentation for public use (that's not internal-dev talk which is probably often filled with expletives . Some studios just don't bother and let people discover things on their own, but it's often unsupported.

It's less locking the game for DLC, and more of an initial dev, support, and maintenance issue. You'd have to dedicate a team to handle the pipeline from the start of the project, which takes away from the main dev of the game itself. And easy modding is not really something you could tack onto a game engine mid-way - nowadays there's a lot of backend linking of resources to a database for management and handling of them that we can't easily just "give out" the system to the public. Also licensing issues - Look up Obsidian's problems with NWN2 and the Granny3D plugin, also a lot of studios make use of version control systems like Perforce.

Hope that clears things up for you!

 

[gargantual]

Thanks for the responses. I see its now more a matter of design and stability. Not everyones going to approach it the same way. No wonder when interviewed Gabe said that Valve looks for more versatile, and independent developers. I see there are protocols for keeping a game stable but I see that makes companies Valve, Bethesda and Rockstar more unique.

It would be great if there were a few more companies that designed titles with the intent of modification. Especially considering how many mods have turned into portfolios, and with people discussing the importance of game design education to different demographics, I figure loosely designed games with mod potential are a good place to start, alomg with a formal comp sci education

 

[wizzy555]

In the literal sense a lot of things will be softcoded. The game engine will be reading things from some settings file and running scripts. But in most cases these are hidden away from the user.

This is usually because allowing the user access just complicates things and runs the risk of introducing unexpected bugs.

If for instance you opened every graphics setting to the user they will have a completely incomprehensible list that they would need days (at least) to understand.

If you market a game as mod-able you are suddenly under an obligation to ensure it works and offer support if it doesn't work. If you don't then you are making less work for yourself.

 

[McKitten]

Is it entirely because of DRM? - to inhibit how the game is played (hard coded), as opposed to encouraging easy modification, continued player interest and user generated content (soft coded)? This is what I strongly suspect but can't really say as a consumer.

It has nothing to do with DRM.

Or are there other practical internal reasons.... such as keeping the development process uniform stable and organized, and dealing with other programmers experience, different middleware and tools?

Yes and not. There are practical reasons, but not those you mentioned. Basically, there are good technical reasons from a programming standpoint. Hardcoded elements are generally (read: should be but some programmers are bad) easier, quicker to program, more efficient to run and easier to alter during the development process.
Imagine the most basic of all programs, the hello world algorithm. You could make it moddable, but that would require your program to open another file and look at its content to find out what to print on the screen ("hello world").
If hardcoded, it can be as short as: print "Hello, World".
So, short version: making a game moddable requires more effort from the programmers and might actually make performance worse, so it's only really worth it if mod are going to be an important feature, or if the development process requires it anyway (if you have a large team with dedicated level designers, 3d modelers, quest designers etc. their output needs to be managed in a modular fashion anyway).