Dynamically create datablocks?

#1 I think the easiest way to accomplish this is to simply create a text file with multi-lines, each line representing the stat of which you want. You could also throw in // every other line to specify what stat is which and when you read in the file just omit reading in those lines. From there, you would assign each line read as a variable (probably local, but global would work as well), and then input that data into the datablock which you want to adhere it to.

You can look into the readLine function for TGB on the forums here, so I won't get into that too much, unless you need it. But when you read in the lines you'll want to store each read variable independently.

When you create your datablock simply reference those read variables and providing the code adheres those stats properly, it should give you the effect you are looking for.

I'm not certain about the XML support per se, so I can't help you there. But, if you'd like I could put some code up that'd more or less do what you're asking.

#2 Thanks for the help, Doc.

I think maybe my question was poorly phrased (and I didn't put enough info in the first time around). Actually, the file part I have more or less down pat at this point. It seems to work well enough and goes something like this:

%FileReader = new FileObject();
	%fileMundanes = "game/data/mundanes.tmt";
	
	%FileReader.OpenForRead(%fileMundanes);
	
	echo("file reads: " @ %FileReader.readline());		// the first line is just our headers for human readability of the file
	
	while(!%FileReader.isEOF())
	{
		%line = %FileReader.readline();
		
		%numWords = getWordCount(%line);	
		echo("# Words in line: " @ %numWords);
		%counter = 0;
		
		while(%counter <= %numWords - 1)
		{
			%curWord = getWord(%line, %counter);
			if(strlen(%curWord) > 0)
			{
				echo("Word " @ %counter @ ": " @ %curWord);
			}
		%counter++;
		}		
	}

In my file, the first line contains headers so that a user can easily figure out what is what, and modify the values accordingly. The info for each unit type takes up a line and all of their stats/data is held there.

For simplicity, lets assume there are only two fields per line (i.e., unit): Name and Health. In order to create datablocks from this dynamically, would I do something like this once I've parsed the fields:

new t2dDatablock(%UnitName @ "Data")
{
     UnitName = %UnitName;
     Health = %Health;

     // then whatever additional, internal goodies I might need to add to it ...
};

From that, I'd have a datablock for each unit type slurped from the file, but is that the best way to go about it, I wonder?

For example, would I be better off creating a SimSet that holds an instance of each unit as a template from which all *actual* units in the game are created/cloned from? Is that inefficient compared to the dynamic generation of datablocks, or do they roughly equate to the same thing (as both result in a theoretically equal number of objects)?

I'm now, somewhat, leaning toward the use of the SimSet rather than the datablocks, but I can't quite see the longer term pros and cons that might be involved with either.

It seems as though they might be markedly similar ways of accomplishing the same thing but something tells me that the datablocks might be the wiser way to go--I just can't put my finger on why.

Thanks again!

#3 Well, from personal experience, I don't think it matters too much one way or the other which methodology you persue. However, it might prove to be easier to have pre-exisiting datablocks configured for your units, and then create the clones off of that template with the custom data applied to it.
The reason behind this thinking is that once the game loads up, you will already have the configurations ready, and simply changing certain values. Whereas, you'd be dynamically creating the configurations the other way. In the end, it takes up the same amount of data, however there's a bit less processing involved when you already have a datablock set up.

The SimSet idea might prove useful for setting up your different types of units, as you could create multiple SimSets within a main SimSet, and allow the player to choose which one they want (or at least give them a representation of what is available).

For instance, let's just assume we have 4 classes, and each class would have a male and a female variant, and thus you would need 8 configurations. If that data is pre-exisiting, you simply display the correct image associated with the input. Now, each class would derive off of the same "main" variables, so as such, all you'd really do is change what those are, and I think you'd have what you're looking for.

Now, if you were to dynamically create you're information, you'd save some front-end loading, but wind up hitting some back-end loading. Granted, it wouldn't be huge, but typically (IMO), it's far better to get as much loading done when the game first loads, then have the user deal with it as they go along (at least as much as possible).

That's my sentiment anyways. Good luck with it.

#4 Civilization 4 does a great job of this.

#5 Doc:Thanks again for the help and info, Doc.

You said, "Whereas, you'd be dynamically creating the configurations the other way. In the end, it takes up the same amount of data, however there's a bit less processing involved when you already have a datablock set up."

Granted, no argument there. At the same time, the penalty can be less flexibility to the user/editor. The more exposed for them to modify, the more processing is involved but the greater breadth of freedom for them to get creative. A fair trade off, I think, both from a developer and a user perspective.

Keep in mind, even with the dynamic format, loading can be done at game start-up as opposed to doing so later when the actual game is under way. So the penalty may be more processing, but it is mostly or entirely done at startup, regardless (at least in my case, it appears).

Of course, there is another advantage; holding much of the data in human-readable files makes it easier for everyone! This, opposed to datablocks--which aren't bad in their own right--which are less accessible compared to simple flat files (or other text based files). To extend this, the files can be opened in, say, Excel or Open Office and edited or reviewed there, as opposed to in TorqueScript, ala datablock format.

In all, I've settled in (for the moment) with the use of SimSets--primarily because of what you have mentioned. The SimSets let me create a main "library" of units (and other data objects) that is very convenient from a bird's eye view.

Something I thought I would mention, as it may be of interest to others reading this thread ... peeking in the common/gamescripts/ directory (of any project) reveals an xml.cs file that refers to a SimXMLDocument() object type.

Naturally, the XML.cs file is all about reading/writing XML, it seems, though I haven't had the time to go through it to try and eek out the details. Unfortunately, in just the little snooping about that I've done, I can't find any referential information as relates to this SimXMLDocument object type. Nada.

The prospect is enticing, however, as XML support would be fantastic for SO...MANY...REASONS! I plan to investigate it more but I'm eyeball deep in other things.

Jason: I've played and even edited Civ4 a bit, so I'm curious as to what you are referring to exactly? Do you mean that it exposes the ability to edit units, and the like, in a very solid way? I'm glad you brought that up, actually, as it has me curious to go back and see what lessons I might be able to learn from how Civ4 handled things, in implementing my own variations.

#6 Absolutely look to Civ IV for an example. One of top priorities for Civ 4 was easy modification and they succeeded greatly with it.

Go into the game folder, then assets, then XML and you can see the units, leaders, civilizations, etc. Those paths might not be 100% accurate, but you're probably smart enough to find it.