Oh, yes, I was, but I think that approach might make a much cooler end result.
I was going to keep the 8x8x8 cube system in place; I was just thinking about ways to better organize the stuff within it.
It might, but it introduces somewhat of a new set of challenges, on one hand. On the other, they are "how to index all the charlie foxtrot that will inevitably appear with so many files in a way that a human being is still able to mod them" and "In what order are the pieces being used" which, I imagine, will be source of some "why are those arches growing through the columns?!".
It might, but it introduces somewhat of a new set of challenges, on one hand. On the other, they are "how to index all the charlie foxtrot that will inevitably appear with so many files in a way that a human being is still able to mod them" and "In what order are the pieces being used" which, I imagine, will be source of some "why are those arches growing through the columns?!".
Yes, that's a whole different issue... file that one under "future ideas" for now, I think just the placement of modules should be the main focus at the moment. Once that's figured out, we can start looking into ways to make modules more varied without requiring a ton of user generated content. I still think the sub-themes is a good idea, even if we don't do all the crazy module construction.
The virtual chunks is looking more and more like the way to go, simply because it will make towers and large rooms much, much less of a headache. I think I might start with getting that to work in a little test program.
Yes, that's a whole different issue... file that one under "future ideas" for now, I think just the placement of modules should be the main focus at the moment. Once that's figured out, we can start looking into ways to make modules more varied without requiring a ton of user generated content. I still think the sub-themes is a good idea, even if we don't do all the crazy module construction.
The virtual chunks is looking more and more like the way to go, simply because it will make towers and large rooms much, much less of a headache. I think I might start with getting that to work in a little test program.
Nothing like good old finding stuff where you left it, eh?
Well, I've hammered out a prototype of the virtual chunks. Not much to show for it, but it's something. I'm now working on figuring out some generation schemes. I have an idea on how to do modules of arbitrary size, but it would require that they form convex shapes in the xz grid of cubes (i.e. they can't wrap back on themselves). However, there may be a workaround if we allow some form of the linking earlier; you could form any shape just by linking square rooms together.
Edit: Actually, nevermind. I think there's a way to deal with modules of any shape (provided they take up 8x8x8 cubes, that is).
I had another thought for a district - we seem to have districts representing classical elements:
Foundry: Fire
Venice: Water
Garden: Earth
But we're missing air. So perhaps we could have some sort of airy district, where the actual ground is kind of sunk down (maybe to the 4th level or so), and the upper levels are all just floating walkways and buildings? Alternatively, instead of the ground being sunk down, maybe the area above would be far more densely packed? Just a thought, I don't think there's any real world architecture that does this, unless you look at really complex highway systems...
Edit: Here's more what I was thinking: http://cdn.magicspoi...Art-615x670.jpg (It won't let me just put the image here... odd)
Every district is probably going to have towers, but in this one they should be everywhere.
The idea for the air district sounds awesome. That painting is a amazing too. An intricate lattice of towers and skyways, stretching off the horizon, more than you could explore in a thousand years....
The idea for the air district sounds awesome. That painting is a amazing too. An intricate lattice of towers and skyways, stretching off the horizon, more than you could explore in a thousand years....
Yeah, Magic the Gathering has some pretty good artwork. It's from a plane called Ravnica, which is covered entirely by cityscape (not too unlike Mazeworld, though it's filled with beings of all different kinds). If you do a Google search for Ravnica land art, there's quite a few good pictures that could serve as inspiration. I particularly like the forests.
Alright, so little update on what I'm working on. I've created a class for storing all of the connections within a certain area. For each connection, there are two true/false values - whether or not it's connected, and whether or not its state can be changed. This way, larger modules placed in can mark certain areas as being incapable of making a connection (so, say, if you wanted a sculpture against one wall and didn't want walkways to try to come through that way). There is also an integer marker on each cube, and my plan for this is that when connecting larger modules with hallways, a hallway will spread out from one open connection and continue until it connects to another open connection with a different marker than the originating building (or the current hallway being worked on). This should help prevent isolated rooms.
Now I'm trying to work out the interface between literal representations of the world and module blueprints. The trick here is to somehow get them to talk back and forth through an intermediary class that translates between the relative coordinates in the blueprint to different relative coordinates in the virtual chunk.
The isolation fix sounds interesting, although I can't think, how it will go wrong...
How do you mean?
I had another interesting thought regarding larger modules, and I'm already working on implementing it. They should not only show up rotated different ways, but also mirrored. This way one larger, asymmetrical room can show up in 8 different orientations.
Edit: Small update, got the rotating and mirroring working in the underground test generation. It's supposed to work off of a series of randomly divided "regions" of 3D space, with a general rule of thumb that 1 region = 1 large module (and hallways will be placed to connect the regions). The regions themselves are abstractions of the space within the virtual chunk.
What this means is all a large module needs to concern itself with is that it has a region of space to work with (with the x-coordinate always the same length or longer than the z-coordinate). It can place itself in pretty much the same orientation every time, and the region itself will handle all the messy rotation of the module. The one rule that goes along with this is un-editable connections shouldn't be placed right on the edge of a region, as neighboring regions (or neighboring virtual chunks) might try to connect there, leading to unintentional dead ends or "orphaned rooms".
Next up, figuring out the internal hallways. Should be fun...
Well so far the only issues I've had to iron out was the math behind the rotation, i.e. using the wrong length and width. At least I think I've ironed it out now...
Now that you mention it, there may be some spectacular failure with the virtual chunks if anyone ever travels out far enough for the numbers to overflow (probably a null pointer exception, causing Minecraft to crash), though I don't expect this to happen in normal gameplay. It would occur around chunk number 2,147,483,647 in any direction (though I think the game has issues with this far, far before this might occur).
Edit: GTG3000, you must be a psychic or something... I'm having issues with dividing the regions, and I can't quite tell where it's coming from. Furthermore, the more I look at the debug output I can produce, the less it looks like it will be a useful endeavor given the relatively small size of the virtual chunks. I could increase that, but any bigger than 4x4 and suddenly the generation will take that much longer, and the buffer will fill up more. I was planning on a larger virtual chunk size for "epic" structures (8x8 chunks as opposed to 4x4), but that would be excusable given that they're such a rare phenomenon.
The thing is, 4x4 chunks is good enough for one, maybe two at most, larger rooms per level. Any more than that and you run into issues with orphaned rooms, lack of space to put hallways, and regions being too small. The splitting algorithm, at least in the naive way I set it up, isn't what we want, I think.
Anyone have any thoughts on how to better place larger structures?
I suppose the real question is, what do we want the ratio of hallway to room to be? I suspect at most one large one (say, larger than 4x4 cubes) or two small ones (4x4 or smaller) per virtual chunk (on a per level basis, though multi-leveled rooms would be counted for both levels) may be optimal. There would still be plenty of space for winding hallways, and I'm pretty sure it would be easy enough to avoid orphaning rooms. Now, I think height transition pieces should be considered separate kinds of modules than either rooms or hallways, and should be placed after the main hallways are put in (with some connecting hallways added). So this way the underground generation should work as follows:
Rooms reserve a space in a randomly determined area, with free connections where connections can be made..
Required connections along the edges are marked as required.
Hallways reserve spaces to connect free and required connections.
Height transition pieces reserve space and add hallways to connect to nearby reserved areas.
All modules add themselves to the virtual chunk, using the reserved space as a guide on how to connect to neighboring chunks.
Any thoughts on this, anyone? Otherwise I'm just going to go ahead and try implementing it in my little test project.
Also, I found this on the interwebs. There's a little bit in there about generating buildings by merging polygons. I'm not sure how well this would translate to modules or Minecraft's blocky representation of everything (or even if that's what we want out of the generation for surface buildings), but it's an interesting idea. http://www.infinityl...raphite2003.pdf
Perhaps one type of tower structure could be a "stacked" tower, where it is rather thin cube-wise at the top and grows as you go down? A bit like this famous landmark:
Keep in mind here that I'm talking about arranging smaller modules in certain ways, not making a single module that looks like this. In fact, arranging rooms as components of smaller modules might be interesting, too... but I'm getting ahead of myself.
I'm not psychic, I'm just somewhat of a depressed pessimist. Considering module size being small enough to fit 2x2 square in a chunk, last time I checked, how big were those separated rooms you were trying to generate?
Are the rooms being put in first or last? Having the stairs as a separate class might be a good idea, if you have some way to check exactly that at the generation stage. You sound like you have a pretty good idea of how it all is going to work, and a much better idea than someone like me, eh.
I don't think polygons and raster modules mix all that well, honestly. It would require some sort of a conversion process, and thats too long.
I don't think the spikes on the towers would look too good in a medievalish setting we're getting one way or another, but that could be a nice idea, either way it requires testing.
It liked to make either really large rooms (8x4 cubes) or really small, oblong ones all over the place (1x3 or something weird like that), leaving no room for hallways. The region splitting just left too much space for rooms either way, not to mention that there is probably a bit of overhead involved in all the random splitting.
Rooms would be put in first. Yeah, the polygons would just end up looking ugly and taking too much time, unless they were all rectangles. The spikes on the towers wouldn't be there, I just meant the overall shape - notice how different segments go to different heights?
Kind of, yeah. An irregular, blocky pyramid. Some other ideas are crazy, twisting tower structures generated by a recursive algorithm, and bunches of "plain", straight towers of varying heights. I suppose we could also experiment with generating castle structures with towers and buildings. Generally we would want at least a couple different random tower generation algorithms to keep it varied.
As for stairs, I've been wondering about that myself. I don't think I want to add up and down connection variables to the entire structure for keeping track of modules in the virtual chunk, as this would result in a lot of wasted space.
Now, rooms have a bounding box class that acts as the interface between the room's "blueprint" and the actual world; you can think of it as a box where the room will be built. It handles all the translating, rotating and mirroring of the entire room so the room doesn't have to deal with any of it. I was thinking something similar for towers would be a good idea. Maybe those could keep track of the up/down connections?
The green and blue spots with the red connections represent rooms, and the red spots with the orange connections are the hallways. There will probably be more hallways in the actual generator, to connect neighboring areas. This is just a test run.
Edit: And it would appear as a little side effect of the random hallway generation, heading clockwise around the edge tends to form long hallways, as there's a 75% chance of it just continuing along that edge. While I have no problem with long hallways forming, showing up right on that edge will look a little ugly when the other side does the same thing. I think I have a trick or two up my sleeve to fix this, and it involves sometimes searching the opposite way.
Edit #2: And here's a rough idea of how this will mesh together:
The orange is hallways, and the green and blue are just little rooms I put in every virtual chunk. I'm not sure how I feel about the little squares cropping up everywhere... it's mostly an artifact of having that edge there. I could attempt to do something about it if you guys want.
I wasn't really satisfied with the hallways, so I played with them a bit.
Still has the little squares, but the hallways are a little more convoluted, and there are now dead ends. I think the number of connections along the sides needs to be more limited, though...
Edit: Alright, apparently being a perfectionist today.
Passive mobs at best.
It might, but it introduces somewhat of a new set of challenges, on one hand. On the other, they are "how to index all the charlie foxtrot that will inevitably appear with so many files in a way that a human being is still able to mod them" and "In what order are the pieces being used" which, I imagine, will be source of some "why are those arches growing through the columns?!".
(terrain/mobs/armor)
Yes, that's a whole different issue... file that one under "future ideas" for now, I think just the placement of modules should be the main focus at the moment. Once that's figured out, we can start looking into ways to make modules more varied without requiring a ton of user generated content. I still think the sub-themes is a good idea, even if we don't do all the crazy module construction.
The virtual chunks is looking more and more like the way to go, simply because it will make towers and large rooms much, much less of a headache. I think I might start with getting that to work in a little test program.
Nothing like good old finding stuff where you left it, eh?
(terrain/mobs/armor)
Edit: Actually, nevermind. I think there's a way to deal with modules of any shape (provided they take up 8x8x8 cubes, that is).
The idea for the air district sounds awesome. That painting is a amazing too. An intricate lattice of towers and skyways, stretching off the horizon, more than you could explore in a thousand years....
Yeah, Magic the Gathering has some pretty good artwork. It's from a plane called Ravnica, which is covered entirely by cityscape (not too unlike Mazeworld, though it's filled with beings of all different kinds). If you do a Google search for Ravnica land art, there's quite a few good pictures that could serve as inspiration. I particularly like the forests.
Now I'm trying to work out the interface between literal representations of the world and module blueprints. The trick here is to somehow get them to talk back and forth through an intermediary class that translates between the relative coordinates in the blueprint to different relative coordinates in the virtual chunk.
(terrain/mobs/armor)
How do you mean?
I had another interesting thought regarding larger modules, and I'm already working on implementing it. They should not only show up rotated different ways, but also mirrored. This way one larger, asymmetrical room can show up in 8 different orientations.
Edit: Small update, got the rotating and mirroring working in the underground test generation. It's supposed to work off of a series of randomly divided "regions" of 3D space, with a general rule of thumb that 1 region = 1 large module (and hallways will be placed to connect the regions). The regions themselves are abstractions of the space within the virtual chunk.
What this means is all a large module needs to concern itself with is that it has a region of space to work with (with the x-coordinate always the same length or longer than the z-coordinate). It can place itself in pretty much the same orientation every time, and the region itself will handle all the messy rotation of the module. The one rule that goes along with this is un-editable connections shouldn't be placed right on the edge of a region, as neighboring regions (or neighboring virtual chunks) might try to connect there, leading to unintentional dead ends or "orphaned rooms".
Next up, figuring out the internal hallways. Should be fun...
(terrain/mobs/armor)
Now that you mention it, there may be some spectacular failure with the virtual chunks if anyone ever travels out far enough for the numbers to overflow (probably a null pointer exception, causing Minecraft to crash), though I don't expect this to happen in normal gameplay. It would occur around chunk number 2,147,483,647 in any direction (though I think the game has issues with this far, far before this might occur).
Edit: GTG3000, you must be a psychic or something... I'm having issues with dividing the regions, and I can't quite tell where it's coming from. Furthermore, the more I look at the debug output I can produce, the less it looks like it will be a useful endeavor given the relatively small size of the virtual chunks. I could increase that, but any bigger than 4x4 and suddenly the generation will take that much longer, and the buffer will fill up more. I was planning on a larger virtual chunk size for "epic" structures (8x8 chunks as opposed to 4x4), but that would be excusable given that they're such a rare phenomenon.
The thing is, 4x4 chunks is good enough for one, maybe two at most, larger rooms per level. Any more than that and you run into issues with orphaned rooms, lack of space to put hallways, and regions being too small. The splitting algorithm, at least in the naive way I set it up, isn't what we want, I think.
Anyone have any thoughts on how to better place larger structures?
Rooms reserve a space in a randomly determined area, with free connections where connections can be made..
Required connections along the edges are marked as required.
Hallways reserve spaces to connect free and required connections.
Height transition pieces reserve space and add hallways to connect to nearby reserved areas.
All modules add themselves to the virtual chunk, using the reserved space as a guide on how to connect to neighboring chunks.
Any thoughts on this, anyone? Otherwise I'm just going to go ahead and try implementing it in my little test project.
Also, I found this on the interwebs. There's a little bit in there about generating buildings by merging polygons. I'm not sure how well this would translate to modules or Minecraft's blocky representation of everything (or even if that's what we want out of the generation for surface buildings), but it's an interesting idea.
http://www.infinityl...raphite2003.pdf
Perhaps one type of tower structure could be a "stacked" tower, where it is rather thin cube-wise at the top and grows as you go down? A bit like this famous landmark:
Keep in mind here that I'm talking about arranging smaller modules in certain ways, not making a single module that looks like this. In fact, arranging rooms as components of smaller modules might be interesting, too... but I'm getting ahead of myself.
Are the rooms being put in first or last? Having the stairs as a separate class might be a good idea, if you have some way to check exactly that at the generation stage. You sound like you have a pretty good idea of how it all is going to work, and a much better idea than someone like me, eh.
I don't think polygons and raster modules mix all that well, honestly. It would require some sort of a conversion process, and thats too long.
I don't think the spikes on the towers would look too good in a medievalish setting we're getting one way or another, but that could be a nice idea, either way it requires testing.
(terrain/mobs/armor)
Rooms would be put in first. Yeah, the polygons would just end up looking ugly and taking too much time, unless they were all rectangles. The spikes on the towers wouldn't be there, I just meant the overall shape - notice how different segments go to different heights?
(terrain/mobs/armor)
As for stairs, I've been wondering about that myself. I don't think I want to add up and down connection variables to the entire structure for keeping track of modules in the virtual chunk, as this would result in a lot of wasted space.
Now, rooms have a bounding box class that acts as the interface between the room's "blueprint" and the actual world; you can think of it as a box where the room will be built. It handles all the translating, rotating and mirroring of the entire room so the room doesn't have to deal with any of it. I was thinking something similar for towers would be a good idea. Maybe those could keep track of the up/down connections?
The green and blue spots with the red connections represent rooms, and the red spots with the orange connections are the hallways. There will probably be more hallways in the actual generator, to connect neighboring areas. This is just a test run.
Edit: And it would appear as a little side effect of the random hallway generation, heading clockwise around the edge tends to form long hallways, as there's a 75% chance of it just continuing along that edge. While I have no problem with long hallways forming, showing up right on that edge will look a little ugly when the other side does the same thing. I think I have a trick or two up my sleeve to fix this, and it involves sometimes searching the opposite way.
Edit #2: And here's a rough idea of how this will mesh together:
The orange is hallways, and the green and blue are just little rooms I put in every virtual chunk. I'm not sure how I feel about the little squares cropping up everywhere... it's mostly an artifact of having that edge there. I could attempt to do something about it if you guys want.
Still has the little squares, but the hallways are a little more convoluted, and there are now dead ends. I think the number of connections along the sides needs to be more limited, though...
Edit: Alright, apparently being a perfectionist today.
There. That should be good.
I gotta say, that one looks really nice.