Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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?

share|improve this question
9  
The term you're looking for is "Data Driven" and yes, it's much faster in the long run to create new stations and ships with XML (or any format like JSON really) files than what you're doing on even a smaller project. Plus later you can remove and edit without having to touch code and recompile, for a second time savings. –  Patrick Hughes Jun 3 '13 at 3:01
    
@PatrickHughes While typing my answer, you already put it in comment! –  sm4 Jun 3 '13 at 3:04
1  
If we're trying to legitimize "soft-coding" as a real term, I propose firm-coding as "using a hard-coded input to a soft-coded data matrix." –  Sean Middleditch Jun 3 '13 at 3:39
1  
@Singular1ty this site is more forgiving of discussion than some other SEs. I think your question qualifies for "good-discussion" status. –  Seth Battin Jun 3 '13 at 3:40
2  
@Singular1ty Ah, here it is. Couldn't find it when I posted my first comment. blog.stackoverflow.com/2010/09/good-subjective-bad-subjective –  Seth Battin Jun 3 '13 at 5:00

3 Answers 3

up vote 58 down vote accepted
+500

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.

share|improve this answer
3  
Wow, another fantastic answer! Thanks a lot. I definitely agree with the ability to change values quickly - and also on bug-hunting. Forgetting one or two little things is quickly turning into a nightmare, and I want to do whatever is necessary to cut down on repeating the same lines of code endlessly with only minor changes between alliances, names, and hull/weapon values. –  Singular1ty Jun 3 '13 at 4:25
    
Seth, welcome to your new privilege level. Use your close and reopen votes well! –  Byte56 Jun 20 '13 at 17:31
    
I appreciate it, thanks. I'm going to wait a short while to use them. I've been getting some rep fluctuation from up-voting accounts that get deleted. –  Seth Battin Jun 20 '13 at 17:48

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.

share|improve this answer
    
Thanks for the answer. I'm already finding that my system is getting quite out of hand. Because of extending things in java, my classes often have about ten to fifteen constructor arguments, and I always forget which order they go in. I'm used to doing 'quick and dirty' things, because my attention span is so short, but I would like to actually finish a project for once. Plus if I feel the need to tweak stats for things later on, I don't want to get stuck with trawling through a thousand lines of hard-coded objects... –  Singular1ty Jun 3 '13 at 3:07
    
@Singular1ty In that case, stop what you're doing right now. It is time to refactor like crazy. Forget about any new content and concentrate on improving existing overall structure. I work in a games company and I am always pushing for a period of taking a breather and refactoring. But of course, it falls on deaf ears and we always end up crunching like mad, wading through bug/hack infested quagmires. Ho hum –  DaleyPaley Jun 3 '13 at 4:04

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.
share|improve this answer
    
These are just some of the pros and cons I can think of right now; let me know if you think of more! –  Nick Caplinger Jun 3 '13 at 3:18
1  
I approved your edit to my title. –  Singular1ty Jun 3 '13 at 4:27

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.