"Hard coded" values? Thread

When I have stats in a game, let's say guns with different power, fire speed and ammo, I'd always put it somewhere centralised and out of the way, and basicly have an area where all the other stats live. A 2D array in it's own object/class that has all the guns in it usually, or whatever is appropriate for the engine I use. I'd like to make it read a txt file with all the stats in it, but I never got around to looking into it.

The book I'm reading at the moment says you should never "hard code" anything like this, and then spins off on a long and confusing chapter of adding a scripting language that, in the end, seems to give the exact same results.

I'm always wanting to expand my knowledge and become a better programmer, so what exactly is the difference, and why shouldn't you do it the way I've been doing it?

Thanks.

Never hard code.. ha! Doom 3 (and other games) keep a lot of this info in external files. The advantage? You don't need to recompile the code to run the changes. It doesn't REALLY matter, thousands of games hard coded this stuff and they're still wildly popular. Look at Half Life. All that was hard coded and people STILL mod for it.

Doing it in an external file (you don't need a scripting language, just read the external file) makes it easier to modify values in that external file, but it's slower at reading then a compiled file.

Scripting languages slow things down. Doom 3 tech runs 7 lines of C++ code for every *ONE* line of script. Scripting it easier though. A completly new game can be made with Doom 3 w/o ever cracking open the SDK because all the weapons, AI, maps, etc. are all in external files (.script, .def, .map...). For Doom3 BFG they binarized everything for faster access and (combined with some other changes) made the game many times faster.

So reading from an external file is what I was wanting to do anyway, for the same reasons I wanted to do it in the first place?

As for scripting, I'm going to assume this is something mostly related to the relatively simple form of my games so far, but how is writing and implementing a script system easier when you could just do the same thing in C++ (or whatever language you are using)? The result is the same, it's faster, and you haven't added a point of failure. Yeah, you don't have to compile, but unless you are making something huge, wouldn't the time to add the scripting language be longer than the compile times? I can understand making balance changes to item stats on the fly, but you said you don't need a script system to do that.

For small games it may not be worth the trouble and you may just want to use text files (or JSON, which is something I prefer) if you only want to expose weapon stats.

This approach is more powerful when working in a team, especially with members which don't program. At first you implement the tools (or interfaces) to generate or modify content, then everyone can work parallel for maximum efficiency. (best example: level designers)

Edited by: MausGames

It depends on the situation, there are plenty of developments for a variety of reasons hard coding is the quickest and easiest way.

Some kind of external file that is easily accessible - I wouldn't recommend hard coding. Most games will do this - for example the use of archetypes in UDK, or XML etc in other game engines.

If you can reload it on the fly without quitting the game, all the better.

Don't implement your own scripting language or it will either A: take forever, using up valuable development time, or B: Be highly restricted, costing valuable development time to work around when actually using it. Use something like Angelscript (Great for binding with C++).

Also, consider having most of the values inited from script by writing to an vector (array) in your program on startup. No need to have the script called just to check a value every time something is done, when all that could be loaded at start up from the script into the engine.

Having the script actually execute code comes in handy when you want to let the user (or yourself) easily reconfigure things and tweak behaviors.
There is nothing more annoying then waiting 5~25 seconds for a compile, just to check if the GUI element you moved 2 pixels over looks better now or if its still not far enough.

Its also much less restrictive then designing your own 'human readable' config format and much more likely to return decent error messages when a syntax mistake is made.