Why is it bad to hard-code content?

Putting game content data in code means that to see any potential change or iteration of that game content data, you have to recompile the game itself. This is bad for two reasons:

• Many languages that games are written in have long compile times. C++ is particular can be very bad in this respect, and C++ is a very common language for large commercial games. It is less of an issue with languages like C# and Java, but still not as fast as being able to store game data in external files that can be hot-reloaded while the game is actually running to see changes.

• Many games are developed by teams which often consist of non-technical developers (designers and artists) producing content. Not only do non-technical people not want to have to recompile the game, or deal with "cumbersome programmer tools," to iterate on their content, it may be desirable to minimize source code exposure to only the programmers (because the fewer people who have access to source code, the fewer people who can leak it -- accidentally or not).

I think you're overestimating the complexity of loading data from text or XML files. Most of the time you should use a library to do this, which makes the process of parsing the XML/JSON/whatever much easier. Yes, there is a bit of up-front cost to writing a level loading system that is data-driven but it will generally save you a lot of time in the long run versus tons of unique classes to represent each level.

Smaller or simpler games may not have as much to gain from the longer-term investment of a data-driven approach, so unless the developers are using existing frameworks/engines that support it it may be more efficient for them to simply encode the data in the game code.

There are of course a host of reasons why any given game may choose to put their data in external files (or not); it's not feasible to list them all. At some level they will usually all boil down to the additional iteration speed or flexibility that not-having-to-rebuild-the-game can provide.

As always, as always, it depends. But first, I would like to argue that hard coding is not bad by itself.

I have hard coded content, specifically dialog text, in some simple games, and the world didn't end. We programmers love abstracting things, but remember that each layer of abstraction you make will make your program more complex and more difficult to understand.

If your game is simple enough so you can hardcode some content in it, I would certainly consider it for the sake of simplicity.

This, however, does not really scale too much. Certainly the most common reason for putting content in outside resources is to simplify teamwork, as one person or team can focus on writing the game, while another one can focus on creating and polishing the content.

However, drawing the line between program and content is not always really trivial. One could say that textures are 100% content; but what about procedurally generated textures? Dialog text could be considered 100% content; but what about when the dialog changes depending on your previous actions? Other elements that one may consider to be 100% part of the program, like scripts or shaders, could also be considered part of the content of the game. Should they be hardcoded? should they be loaded as an external resource?

Remember though, that each type of content you support in your game must have a loading and interpreting code related to it, so generally, if in doubt, I'd recommend hard coding content, and only taking it out to an external resource when you really need that flexibility (not when you think you -may- need it, but when you actually do)

Finally, one advantage of storing data in resource files is that you can load them only when you need them (therefore possibly speeding up game load times), and unload them when you don't need them anymore (therefore allowing you to have more content than can fit in memory). (Nitpickers' corner: resource DLLs could arguably be considered to be external resources)

For the sake of making changes faster, it speeds up development on larger productions by tons.

You don't need to teach everyone to learn how to go in and edit source to make simple changes. By dragging it out of the actual code, more people get the chance to fool around with, it's easier to find out what options you can play around with and the whole process of finetuning various parts of your game takes much less time. Even Q&A can help with that.

I think too easy to be the 'wither-than-white' guy, and recommend warmly using external text resource file.

Why ? Because there's a choice here that's about balancing each solution's cost/issues/advantages.

When using an external file... well i guess the other answers explain well enough the benefits. But what about the costs ? You have to define a valid formalism, build a interpreter, agree on a file format, and worse... build another application -an editor-. Wich is a 0.00% issue if you're member of a 50 coder team building a large project. But if you're alone : you're stalled.
Again i don't under-estimate the huge flexibility benefits of an external resource : data-driven programming seems to me the way to go for video-games. But let's not forget the cost.

On the other hand, having the text inside the code allow for quick prototyping, so it should be preferred in a first time. Then my advice would be, as the project mature, to analyse the kind of data required to modelize the dialogs (mood/history-state/...). Then at some point you decide of some classes/rules/file format and go for the real thing, allowing other people to edit/decoupling the code from the content and so forth. OR for a game with simple dialogs (Mario...) you just consider the cost too high, and you keep the few strings/behavior hard-coded.
Your call.

(Rq about localisation : it's just a hash table away, so it's an independent an easily solvable issue)

A big reason for storing in text files is reusability. Creating a text game framework that reads your maps, dialog, and other resources from a text file allow you to reuse your framework for other games. Going beyond text games this is how big budget titles like Call of Duty release a new game every year.

Another reason is portability. You can use the same files for web, pc, Mac, Android, etc. All you need to do is mock up your framework for these different platforms, and the bulk of the game data is untouched.

When going beyond text based games having a script and data stored in files will decrease recompile times and allow you to create an interface for manipulating the data easier.

I can't believe noone mentioned this yet, but a big reason is to make localization A LOT easier. If you need to support English, French, German, Spanish, Portuguese, Italian, Russian, Chinese and whatever other language you're aiming at, hardcoded requires you to have separate code-behind for every language. It also means that if you need to remove certain content (read: censorship), you need to change your code itself to avoid it, instead of saying "just replace this anal probing minigame with this passive-aggressive banner that graphically explains what's going on". It's also rather unfriendly for consumers, since it is likely they'll need to restart the game to change the language, since you need to load other libraries. Finally, that separate code-behind means that you need to apply every single bugfix to every single one of your language codebases, resulting in potential for language-specific bugs.

On the other hand, if you're using external resources, supporting different languages just means loading a different resource file. This can easily be done while the game is running. it means that you can have a single codebase, vastly simplifying development. And it also means that you can easily add after-release support for other languages. Finally, it means that you can let the user opt out of installing certain languages (a feature which doesn't happen all that often in games, but one which is still possible) to save disk space and bandwidth.