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
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.
No comments:
Post a Comment