Storing prefab pieces
#1
I'm considering the options for storing the prefab pieces (aka "Gallery areas for the generator"), so that MCS can use them in the world generators. There are several possibilities, each with a different twist.

1. Have them exported as .schematic files, load them at runtime.
2. Have them exported as C++ code, compiled into the server, converted to cBlockAreas in runtime.

Option 1 is a bit difficult on the setup side - the admin has to make sure the schematics are in the proper folder relative to the server, and if one schematic is missing, the entire generator can't really work. Also metadata for the prefabs, such as the connectors (how to connect them together) will have to be stored somewhere, probably yet another external file.
It could be possible for the admin to actually modify the set of pieces that the generator uses, but the generator would need more robust error-checking for this.

Option 2 is easy to set up, the admin doesn't need to do anything special for it to work. However, it makes the executable larger not only on disk, but in the runtime memory as well - each prefab would be stored in the RAM twice - once as the in-source image, and once as the cBlockArea used for the actual generating. The generator will not need any error-checking, because all of it would be done while developing / adding content.

So what are your thoughts?
Reply
Thanks given by:
#2
With the second option. How much would it affect the memory usage? If it's only about 5 mb it's fine, but if it's over 200 then I don't think it's such a great option. I suppose it depends on the size of the structure, so lets say one 10x20x10 structure?
Reply
Thanks given by:
#3
That really depends on how we want to store the structures in the C++ source. I was thinking about this way (inspired by the XPM3 format, http://en.wikipedia.org/wiki/X_PixMap#XPM3 ):
static const cPrefab::sDef g_TestPrefabs[] =
{
	{
		8, 4, 8,  // SizeX = 8, SizeY = 4, SizeZ = 8
		"A:1:0;"  /* E_BLOCK_STONE */ \
		"B:0:0;"  /* E_BLOCK_AIR */ ,
		
		// Level 0:
		"AAAAAAAA" \
		"ABBBBBBA" \
		"ABBBBBBA" \
		"ABBBBBBA" \
		"ABBBBBBA" \
		"ABBBBBBA" \
		"ABBBBBBA" \
		"AAAAAAAA" \

		// Level 1:
		"AAAAAAAA" \
		"AAAAAAAA" \
		"AABBBBAA" \
		"AABBBBAA" \
		"AABBBBAA" \
		"AABBBBAA" \
		"AAAAAAAA" \
		"AAAAAAAA" \

		// Level 2:
		"BBBBBBBB" \
		"BAAAAAAB" \
		"BAAAAAAB" \
		"BAABBAAB" \
		"BAABBAAB" \
		"BAAAAAAB" \
		"BAAAAAAB" \
		"BBBBBBBB" \

		// Level 3:
		"BBBBBBBB" \
		"BBBBBBBB" \
		"BBAAAABB" \
		"BBAAAABB" \
		"BBAAAABB" \
		"BBAAAABB" \
		"BBBBBBBB" \
		"BBBBBBBB" \
	},
	// Another prefab here
};
This could be fully automated by an export plugin accompanying the Gallery plugin, and it is also somewhat human-readable, so it could be tweaked in-source if needed.

This format would require an additional RAM of about 1 byte per block stored, so a 10x20x10 structure would need ~2 KB. To give some perspective to that, most our houses in the Gallery are about 10 x 6 x 10 on average, consider some 20 different houses, that amounts to (20 * 10 * 6 * 10 = ) 120 KB extra RAM consumed (and diskspace as well, by the MCS executable). Multiply by some generous 5 village types, it's 600 KB, still acceptable.

Come think of it, we could do both - have some structures built in and later add the possibility for the generator to load structures externally.
Reply
Thanks given by:
#4
Yea I think 600 kb is acceptable even though I expect about 7 or 8 different types, but that woudn't be too big either.

xoft Wrote:Come think of it, we could do both - have some structures built in and later add the possibility for the generator to load structures externally.
Yea I think that would be a great.
Reply
Thanks given by:
#5
How about writing a generator to generate houses and other structures for us?
Reply
Thanks given by:
#6
That shouldn't be too hard to do. All a house is is a collection of rooms. And rooms are just a floor, walls, perhaps a door, and a roof.
Programming Telekinetically
The practice of programming a computer without touching an input device of any kind, such as a keyboard or mouse. Easily confused with doing nothing at all.

Johnny might be sitting and staring at the computer, or he might be programming telekinetically.
Reply
Thanks given by:
#7
You're back!
Reply
Thanks given by:
#8
If we do decide to go down the generated c++ code route can we just commit the generator and schematics and not the generated source so the source is always up to date with the schematics.
Reply
Thanks given by:
#9
I've been around; just hanging around in the shadows of the forums.

I think that we should take both routes: build a generator for random buildings, but also be able to generate structures from schematics. That way we don't have to hardcode any buildings into the source, but can still have constant structures from the prefabs.
Programming Telekinetically
The practice of programming a computer without touching an input device of any kind, such as a keyboard or mouse. Easily confused with doing nothing at all.

Johnny might be sitting and staring at the computer, or he might be programming telekinetically.
Reply
Thanks given by:
#10
worktycho, the C++ writer needs to be run inside MCServer (because it needs access to cBlockArea, which is rather difficult for the build process. Also we can have other prefabs that don't come from the Gallery server.
Reply
Thanks given by:




Users browsing this thread: 1 Guest(s)