When should I hard-code data versus load external data?

Question

I'm a thousand or so lines of code into making my own 2D space-based game, which creates networks of randomly generated star systems and populates them with a random selection of planets, stations, ships and weapons.

There will potentially be hundreds of different stations/ships/etc that the game will need to use - so here's what I was wondering. Should I spend the time to create a 'softcoded' data-loader, which would store all of this information in (for example) XML files, and would therefore be somewhat easier to modify later, or should I simply go with what I've been doing right now - hardcoding all of the objects into the main engine of the game.

I'm the only person on the project, and as I said, it's only a hobbyist thing I'm doing in spare time away from university. But would the community recommend investing in creating an entire extra system of storing data in additional files?

What are the benefits of softcoding data in a way like this, versus simply hardcoding it all via constructors? Is there a long-term benefit to having external files that can be modified - if I'm not looking for the game to have 'mods', is it necessary to have external files? If it's just a hobbyist thing that I might give up on in a few weeks or months, should I waste time on this?

Answer 1

Yes. You should implement a system to load content outside your main engine.

Headers for succinct answers.

No. It does not consume too much time.

I think the question of whether it is a valid allocation of your limited time is moot; even if only for the fact that it will be a small portion of total project time.

You will spend hundreds (thousands) of hours on a game project that you take to completion. Perhaps not on an Pong clone, but surely so for your complex space game. Compare that to a config file reader. Implementing a system to pipe XML into your main constructor, and subsequently restart to game process, will take maybe 10 or 20 hours. Even if it takes you 50 or 100, it will be a tiny fraction of total project time.

It will save time

It's not a time expense; it's a time investment. And it will pay off.

Workflow matters, and having a config loader will make your workflow better. By creating a system that allows you edit configurations on the fly, you will save countless rebuilds. You can look at the game while it's running, tweak XML, and recheck in seconds. Or you can look at code, find a line of code (among thousands), edit its values extremely carefully (you're in your main engine, afterall), rebuild, execute, get the game back to the testing state, try hard to remember what it looked like before the change, and see if your change had the effect that you intended. Assuming nothing breaks in your engine, your train of though is surely disrupted.

From a more fundamental comp-sci perspective, try to remember that the most time-consuming part of writing software is not having a few extra keystrokes or whitespace. It's bug-hunting. And if you spend a little extra time to make things clearer by writing more verbose code, you save yourself much more time later. In your case, writing a content importer results in cleaner code that will be easier to read. Instead of miles and miles of hardcoded values, your source will feature a simple file load. Likewise, you can read the config file without wading through game engine code. Both parts become more maintainable and easier to debug.

One-member teams benefit the most

If you hired an artist to generate some of that content, you would need to make tools for them to work with. They need to make pixel edits, and see the effects rapidly. You would not dare force them to rebuild code in order to see every change. Their time is expensive, and you don't want to waste it.

Now imagine that artist is very unskilled and slow (programmer artist), and has lots of other stuff to worry about because they are also the main programmer and musician. You definitely don't want to waste that time, or the project will never finish. And, that crappy artist will hate training to be a better artist, because they spend all their time renaming asset strings in code.

Don't do that to yourself. Make the tools, and you will have more time to make a game.

Answer 2

This is a good question and the best answer I can give is that only experience can really tell you when it's a good idea to take the path that is more difficult/time-consuming. If anyone tells you you should ALWAYS do it the 'proper' way, then they are simply wrong.

You already understand that it is a tradoff. On one hand, hardcoding is so tempting because it is quick and easy to get going, but in the long run adding features and debugging will become nightmarish. On the other hand, writing a great, flexible, expandable system requires a large initial investment, but makes life a hell of a lot easier in the long run.

The goal is to get something finished, and if you get bogged down in making a great system, the goal will recede further and you will lose motivation. Hard-coding stuff is fine in some circumstances but you must understand the ramifications of doing it. Here are some reasons why hardcoding is a bad idea:

• You may think your project is small, but it is possible that it grows as you decide to add more features. If you start off hardcoding, there is going to come a time when the energy required to maintain it (updaating it with new stuff and fixing the myriad of inevitable bugs) will start to seriously outweigh the initial gains.

• Hard-coding stuff is by definition specific to the current project. For the next project, you will have to start from scratch again, possibly hardcoding stuff again (because that's what you will be comfortable with). If you had put the time into a decent loading system, you could skip that work and headaches for all future projects.

• You may be working alone at the moment, but there may come a time when you wish to bring someone else onto the project. Are you going to take the time to explain your disgusting parochial system and write documentation for it?

• Hard-coding often involves having to know what certain magic numbers mean, or complicated class dependencies. You may be able to keep it all in your mind now, but just wait until you've been away from the code for a while. Even with extensive comments, a badly designed structure is hell to go back to.

I would say you should feel free to hard code stuff on only the smallest details. If you have even the slightest notion of the element you are working on being used by someone else, growing much larger, or being used in another project, then take the time to do it right, now.

On the other hand, I prototype like a madman and hard-coding certain things is quick and easy and leaves you free to concentrate on experimenting. It kind of depends on your style of working.

Answer 3

What you're talking about is data-driven programming.

For small projects, it may not be worth the time investment, as there are often much more important features that you could improve.

However, data driven programming can be VERY easy to implement. If you're serious about it, you should probably use XML, JSON, or YAML, but you can also use plain text files.

Data-driven Programming

Pros

1. Allows designers to access and modify game data without programming knowledge
2. You can make modifications to the game without needing to recompile. This should not be underestimated, as you can develop a game much more rapidly this way. Good games come after many iterations.

Cons

1. It takes time and effort to implement.
2. It may increase the complexity of the program.