Why is it bad to hard-code content?

Question

I know most games store dialogue text in files, but I've also seen a few text-based games actually program the content (map, choices, possible player commands, story text) into the game code.

I can think of a few reasons, but what is the major reason why even text games keep everything in files outside the program?

The implementation details differ little between holding content in something like the popular XML format, parsing it, then rendering maps/displaying text based on the variables created from XML file, and simply forgoing the XML file entirely. They both end up with strings which output to the screen. Isn't the difference just notation?

Some games even hold the graphics (ASCII art?) inside the code. I know this isn't right, and I can guess a few reasons why it is bad, but don't know the major reason why either.

It is very popular to have most of the content outside the program. Even Dwarf Fortress doesn't use actual ASCII characters, but images of ASCII characters loaded into memory.

I primarily ask because it is a bit of a PITA to create, parse, and work with XML files. You know... compared to the lazy alternative of just making every unique dungeon (content) its own class.

Answer 1

There are several reasons for that. I'm just gonna touch on a few:

1. It makes your source code a mess. If you have a lot of dialog (trees), a huge part of your codebase is just text that has nothing to do with your actual game code.
2. You'd need to recompile every time you change so much as a single character.
3. The dialog itself is hard to navigate. I imagine trying to implement a whole dialog tree, let alone several, completely inside your source will result in a nested mess of spaghetti and nested ifs, switches and so on. Which then results in code that is prone to errors, hard to read and harder to debug.
4. If you want to enable people to mod or expand your game, that's far easier if they don't have to deal with the source code to change something.
5. The above point is even more important if you work in a team. You don't want your writer to have to mess with the code just to enter a piece of dialog.
6. Parsing XML or other standard file formats is pretty easy to do if you use existing libraries, so the cost of implementing it that way is very low while giving you lots of advantages and avoiding the problems mentioned above and lots more.
7. As @MiloPrice pointed out below, it's also far easier to localize the game if your text is in external files. You can add a language by adding a file, your team can take care of translation without having to touch the source (which is especially important if you let people translate who are not supposed to see all of your code - think freelancers, people from the community that don't belong to your team etc).

Answer 2

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.

Answer 3

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)

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

I think a key phrase is separation of concerns.

If your code doesn't include the text than the code get's less complex. The programmer writing the code doesn't have to think about the specific text and can focus on the code.

He doesn't have to think about localization. The person doing the localization doesn't have to worry about the code.

Answer 8

I think it is too easy to be the 'wither-than-white' guy and recommend warmly using an 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 the benefits well enough. 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-. Which is a 0.00% issue if you're a 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.

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

Answer 9

I guess licensing can also be a reason not to include content in the code.

For example,

• your code might be FLOSS, but you don’t want to license your content at all (maybe you want to publish your game code so that others can use it for creating similar games with different content)
• your code might be FLOSS, but you want to use a Creative Commons license for your content (as software licenses don’t work great for content and vice-versa)
• your code might be proprietary, but you are reusing free content
• your code might be proprietary, but you want to publish your own content under a free/libre license