# Why is it bad to hard-code content?

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.

• Text based games do hard code a lot of content, but I think that's just because of the time when they were developed and poor design choices. The same might apply to Dwarf Fortress. I personally have taken all my text-based games and moved the content outside of the source and into a database. It made my life so much easier. Sep 30 '14 at 20:53
• i18n would be very hard to do with content embedded in the source. Sep 30 '14 at 22:03
• Not so sure this is game development specific. In the future consider asking on the programmers SE or stackoverflow.
– House
Sep 30 '14 at 22:20
• just making every unique dungeon (content) its own class. That just made me shiver. Separation of data from logic is such a fundamental principle to me that I'm surprised there are still developers violating it. Oct 1 '14 at 9:02
• Whatever you decide, do realise that hardcoding content allows for a lot more special cases. Want a certain boss to only appear between midnight and 7AM (real time)? It's a lot easier to hardcode that than to create a generic way for monsters to only appear at certain times. Oct 4 '14 at 1:15

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).
• I wouldn't say that it would make your code a mess. Otherwise, content or not, anything can be considered a mess in bulk. You can structure content in a good structure just like code. But, the rest of the points still stand strong. Sep 30 '14 at 20:49
• Ease of localization/translation is another big benefit. Sep 30 '14 at 21:20
• @Christian: You can have a data-driven program where the data is embedded in the program in a format where it's directly usable in-place (e.g. in C or C++, large, hopefully-const arrays with static storage duration). This saves you all the code, and runtime memory cost, of loading/converting an external data representation at runtime. Of course all of your other reasons for keeping data external still apply. Sep 30 '14 at 23:35
• Personally I favor an even stronger approach for the same reasons enumerated here: Move most of your code in a scripting language as well. Build a core in C/C++, embed a language like Python or Lua and export an API to it. Don't Starve follows this approach and it's one of the best-written games I've seen. Numerous other games in the past and present also do this, as well as applications (and rarely utilities). I'd say that overall, outside of small projects and tiny utilities, heavy layering and separation are always your friend. Sep 30 '14 at 23:57
• – user1430
Oct 1 '14 at 19:49

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.

• I don't think compile times are really that important but as a developer we always strive for "neat code" ... this is a pretty good reason to separate things in it's own right ... content should be content not code!
– War
Sep 30 '14 at 21:15
• @Wardy Compile times are really important in C++. I have worked with solutions that took more than 15 mins to build, either because of the size of the project, aggressive use of templates or even developer laziness (including unnecessary headers). And I am sure this is the case with huge commercial games. Oct 1 '14 at 12:57
• @concept3d: I wish my project was 15 minutes. A clean build on a dedicated build server takes ~50 minutes. Oct 1 '14 at 20:43
• the fewer people who have access to source code, the fewer people who will suffer from brain damage that C++ causes. :P Oct 2 '14 at 15:37
• I think some people might be missing the point of a hot-reload - nobody cares if it takes 30 seconds to recompile the game, artists don't event want to restart the game, they want a keyboard shortcut, so they can test different animations and textures on the fly. In fact this is one of the things they want most. Seeing how things look outside the game is one thing but seeing them in game is what counts. Oct 4 '14 at 20:04

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)

• "but remember that each layer of abstraction you make will make your program more complex and more difficult to understand." I'd have to disagree, abstraction can make a program more simpler and certainly should make it easier to understand. Oct 1 '14 at 9:49
• @NPSF3000 abstractions will add complexity, but can remove more complexity than they add. Oct 2 '14 at 0:25
• @immibis, so the total sum of a project's complexity after implementing an abstraction should be lower than before. Oct 2 '14 at 1:26
• @NPSF3000: My point is that you should not create abstractions just because you can. Sometimes hardcoding data is simpler, more understandable and easier all around. More often than not, I've seen games go down the path to softcoding, which I find regrettable. Also keep in mind that adding abstractions is always easier than removing them, so I am a firm advocate of adding abstractions only when you need them. Oct 2 '14 at 2:21
• @PandaPajama doing something 'just because you can' is likely to cause a problem, regardless of what that something is. That doesn't mean that that something is inherently complex, which was my point of concern. Also, what makes you think adding abstractions is easier than removing them? Off the top of my head I'd think otherwise - adding an abstraction late can mean significant refactoring, but I can't immediately think of a case where removing an unnecessary abstraction would be complex. Changing from XML to hardcoded strings should be trivial. Oct 3 '14 at 10:43

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.

• Of course, having most of the stuff reusable tends to force you to avoid doing anything "special", out of the rules you already have. I'm definitely not advocating hardcoding big games, but it's extremely useful when you're prototyping or writing experimental games - it gives you much more flexibility. It comes with a price, of course, so it's usually a good idea to refactor everything once the gameplay actually works. Gameplay is the hard part - make sure you can test it without diving through architectural hell :D It's usually easier to find the general form after you have the concretes. Oct 3 '14 at 8:26

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 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.

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.

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.

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

• Some of these things are still true if you put the text into the code though. You still need a certain format, a way to navigate the tree, and so on. With that in mind, any additional cost for implementing an external content source seems relatively low, especially since mature libraries and editors exist for parsing, writing, editing and creating these files. Depending on the complexity of your dialogs, you might even get away without a specialized editor and just use a standard text editor. Sep 30 '14 at 21:49
• Sure : maybe i wasn't clear enough, i meant it's only after a few iteration you know what is the shape of your dialogs (from a plain straight line to a complex tree or state machine). In the first steps a few (most easy) ifs + some hard coded string are ok imho. Then when you can clearly forsee your needs, make a choice, after evaluating the cost/benefits of each solution. Sep 30 '14 at 21:58
• A middle ground I'm using on my current one-man game project is to have hard-coded content that is generated from parsed files ahead of compile time. In a lot of cases that would be a worst-of-both-worlds solution, but for what I need it's actually pretty good. Oct 1 '14 at 16:15

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