People love exploring Minecraft. Discovering amazing mountains, caves, and valleys procedurally generated by the infinite world generator.
What if there was another world, also procedurally generated, but with randomly created buildings, corridors, streets, bridges, towers, stairways, and canals? A world of man made structures rather than natural terrain. But one where the random generator can create all kinds of mind boggling things that no human would have the time to create.
Mazeworld, a largely popular suggestion in the suggestion forum, is now being worked on as a mod. It is an infinite dimension of structures and dungeons, representing both chaos and order. The dimension is divided into various districts (analogous to biomes in the overworld).
At the moment this thread has become more of a discussion on how to better accomplish the structure generation, not only to introduce more variety but also so we have some open source code that can be used for other mods involving structure generation.
I'll try to update the OP for major changes.
Some suggested features include:
Garden District: An overgrown, lush district full of life. While garden districts represent nature in Mazeword, they should still be very orderly in some sense.
Temple District: A district of ornate buildings resembling places of worship. I'm picturing it as having a somewhat ancient Greek style, with columns everywhere, as well as perhaps having some repeated symbols etched into the architecture (for example, the symbol on the banner in my signature).
Foundry District: A fiery district representing industry. The foundry district should contain lava flows, minecart tracks, furnaces and anvils. Most of the structures should have kind of a burnt-earth color to them.
Venice/Atlantis District: A district that has been flooded with water. The surface should have plenty of canals and bridges (creating a Venice-like feel). Below, flooded hallways and hidden grottoes make exploration a challenge.
Tower District: A district that's basically a maze of towers and walkways going everywhere. Navigation in this dense city center should be difficult.
Libraries: One popular feature that has been suggested quite a bit is giant libraries. I'm not sure if an entire district could be designed around libraries, so I'm hesitant to describe this as a district in of itself, but libraries should definitely play a part somewhere.
Towers: Mazeworld's skyline should be broken up by crazy, twisting towers everywhere you look. Walkways should connect these towers in a very irregular and random fashion. These towers could have very different looks stylistically, though I think European castle styled towers should be fairly common.
Aqueduct System: Another striking feature of Mazeworld should be the enormous aqueduct system spanning across the map. This will be basically the most efficient way to travel long distances in Mazeworld, though the aqueducts themselves should form a maze on an epic scale.
Epic Structures: Every once in a while while exploring, players should come across vast, epic structures on the surface that seemingly defy all explanation. These would likely take up an entire district's worth of space.
Help would be appreciated, as fleshing out an entire dimension is a tall order for a busy college student with little modding experience .
Cool. I'll been watching the previous suggestion for quite sometime and I'm finally glad that's it's progress far enough to have a mod WIP page. I'll see what I can do after finals to create something to help out. From what I've gotten out of the previous thread, modules are chunk sized constructions that can be pieced together by the terrain generator to create larger structures, correct? Do you have any sort of special process you've been going thorough to create these modules?
Edit: FIRST! (I know, typically frowned upon. However on a project this epic, I can't resist.)
This is really nice. The idea, likely wouldn't have been implemented, I just can't see mojang doing it. But as most good suggestions do, it will make a great mod!
Modules are 8x8x8 cubes, that are put together into chink-sized constructions, using a pseudorandom generator to detemine the contents of not yet generated chinks (If nothing has chended, heh).
Btw, that's quite an awesome progress you've got there!
Almost motivates me to stop sitting on my hands.
Also, none of the threads feature any banners yet, nor any textures (thogh, I imagine, the marble ones have to be cropped and rescaled at places considerably)
I would gladly design some modules, just tell me what rules you want and I will create a flat world and space them out to build some, I think it would be fun to make a lords district, and area that has torches and nice building, but also with the look of abandonment
I would gladly design some modules, just tell me what rules you want and I will create a flat world and space them out to build some, I think it would be fun to make a lords district, and area that has torches and nice building, but also with the look of abandonment
I imagine first we have to let him have his fun with module-building.)
Cool. I'll been watching the previous suggestion for quite sometime and I'm finally glad that's it's progress far enough to have a mod WIP page. I'll see what I can do after finals to create something to help out. From what I've gotten out of the previous thread, modules are chunk sized constructions that can be pieced together by the terrain generator to create larger structures, correct? Do you have any sort of special process you've been going thorough to create these modules?
Edit: FIRST! (I know, typically frowned upon. However on a project this epic, I can't resist.)
Generally I sit down and work out how to make each module by working out the relative coordinates of each block. I currently have two methods for placing them, one for a single block and one for a rectangular prism of blocks. I found myself doing the latter quite a bit (floors, walls, ceilings, etc. are all rectangular prisms) without having that method, so I wrote it to speed up coding them in.
I would gladly design some modules, just tell me what rules you want and I will create a flat world and space them out to build some, I think it would be fun to make a lords district, and area that has torches and nice building, but also with the look of abandonment
As far as rules go, they need to be either 8 or 16 blocks wide and long (so 8x8, 8x16, 16x8, or 16x16). If it's not going to be on the surface, its height should be a multiple of 8, too (though you can generally just fill in extra space with blocks, seeing as how it's underground). Keep in mind that neighboring modules may want to connect to you, so if you want walls on the sides (or multiple levels for underground structures) you should design pathways to accommodate at least a 2 x 3 connection, centered on the cube's edge (and a 6x6 one, if you want it to be part of a larger room).
Edit: As far as dimensions go, that's just kind of the rough outline of sizes. If you want to make weird L-shapes or other things, those should be okay, too, so long as they can be divided into 8x8 cubes.
There were some that generated mazes, though they weren't popular for some reason...
Can't say the names, but they were mentioned in the "suggestions" thread...
Eyeofthedaev, so... And how do you put in the connections now? They're just holes you generate somehow?
How well would the building "caps" that I have designed work with all this?
If y'all think they will go well, I can design some more, including 8x8, 8x16, and 16x16.
I dont know them, but if i had to guess, i woud say they usually generatet "too less stuff". Like only underground mazes etc.
Probaly some "biome only" option woud help. Like that it doesnt generate a whole world and just implement a bunch of truly unique biomes together with normal ones.
WEll yeah, they made some underground mazes from what was on screenshots. I didn't use any, though, so maybe there was more to it... And, biome-only would be... tricky, considering the maze is made from cubes and biomes aren't that strict.
If any new blocks will be implemented, I would love to help with the textures. I really love this idea .
- Dylan
They are planned as a way of making people interested in exploring... If you wish, you can make your own textures, of course, though I would recommend looking through the textures in suggestion thread (okay, okay, there's so-so mine and awesome marble of some guys', but oh well) and seeing what you (maybe) will have to be neighbour with.
There were some that generated mazes, though they weren't popular for some reason...
Can't say the names, but they were mentioned in the "suggestions" thread...
Eyeofthedaev, so... And how do you put in the connections now? They're just holes you generate somehow?
More or less, yeah. To make it easier on myself, I made abstract subclasses for modules and walkways, with methods for adding the center (floor, ceiling, etc. - pretty much everything that's always going to be there), and methods for making one instance of each kind of connection - so I have one that makes a wall, another that makes a doorway, etc. These are called in the abstract subclass's methods accordingly, but don't really have to be dealt with directly, in order to avoid tedious duplication of code across every module.
How well would the building "caps" that I have designed work with all this?
If y'all think they will go well, I can design some more, including 8x8, 8x16, and 16x16.
The caps would look really nice on top of towers (which I have yet to make), I think. They would break up the skyline pretty well, and variety is always a plus. Shorter ones could probably be placed on smaller building modules a little closer to the ground, too. If you want to design more, that'd be good, though you may also want to start thinking about designing some buildings for them to go on top of.
They are planned as a way of making people interested in exploring... If you wish, you can make your own textures, of course, though I would recommend looking through the textures in suggestion thread (okay, okay, there's so-so mine and awesome marble of some guys', but oh well) and seeing what you (maybe) will have to be neighbour with.
Yes, new blocks are going to be a major feature. I think for the most part they're going to be purely decorative, though functional blocks aren't totally out of the question.
So, as for the modules with more detail than a box with holes, do you plan on making some rules, as, say, storing them as data bout what rectangles are filled with what in which order, or going for a "raster" approach, storing each module as an 8x8x8 array and data about cutout connections?
I'm asking because it would determine, how the modules can be made, and, more importantly, the amount of work spent on each module. (and because I have an itch in the back of my head, when i can't figure out something, that looks important to me)
Ideally I'd suggest somehow storing each connection as an 8x8x8 array of it's own, or at least an 8x8 plane, considering that they might vary more than just size, and pasting it over the module somehow... But maybe I'm just being stupid...
And, I don't think there's ever a need in new functional blocks...
It seems to me that storing everything in an array ahead of time would just needlessly add another layer of complexity. I mean, we're talking about entering in coordinates directly into the part where things are being added to the world vs. entering the same coordinates into an array then looping through the array to add to the world.
Well, you're going to have to implement that sooner or later. There will be plenty of modules, and I don't exactly see storing them all in runtime code as a good idea. At least because you'll have to code in each and every last one yourself.
If you say, that coding them in is a temporary decision, then you should remember, that there's nothing as permanent as temporary decisions. Expecially when you build the rest of architecture around them... I guess I could help you with some code by now, if you have any comments in your code.
...also, there seem to be forge for 1.4.5... What's the problem with that one (if you're still using the 1.3.something)?
There is a 1.4.5 forge? Huh. I'm not sure if switching will involve updating parts of the code or not. I could look into it.
Hmm... I think I see what you're getting at here. It would save a lot of time in the long run to develop a system to convert, say, text files into modules, because then anyone could easily create them. It's not so much a feature to save time in running time as it is to save development time. I would still like to keep the functionality of defining modules in the code, simply because some more complex modules might require features that would be difficult to include in a generic text file setup, but most (if not all) of the modules I've designed so far follow a similar formula.
If this system is something you guys want to pursue, it may be good to step back and work out how we want this to work before coding it all up. A few things right away:
We probably want some time saving shortcut commands for making certain shapes (i.e. rectangular prisms), because typing out every block by hand is time consuming. I've been noticing I've been making a lot of empty squares as well, perhaps another one for that?
Being able to set metadata is a must if you want vines, ladders, doors, stairs, mossy stone brick, etc.
We need some way to identify our own custom blocks, preferably without using their actual block ID's (as these may be subject to change). One idea for this is to indicate custom blocks with negative numbers, and in the code convert these to the actual block id's.
Edit: Thinking about this, for each module, we'll probably want to have the following:
The first line of the text file is a little descriptive blurb on what the module is. The program just ignores this line completely, it's there for humans only.
A line indicating the type of module (room or walkway, though I may need to add more types for larger module segments), rarity, and the levels it appears at. I'll probably just define a couple different preset values for this, i.e. top, upper-middle, lower-middle, bottom. There may be extra versions of these added later for interesting effects (for instance, for airier looking districts, it might be cool to have floating walkways that generate over the normal "top" walkways. This can be accomplished with different conditions for the top and upper-middle modules).
An optional "link" section (?). Ideally this would let you list other module files that generate alongside the defined one. The general format would be something like:
File name x coordinate y coordinate z coordinate check conditions (true/false)
The coordinates would be in cubes, of course, and relative to the current module. Check conditions would indicate whether or not it should check that module's conditions for placement (most of the time this will be true, but there may be cases where you wouldn't want to do this). So, for example, if I wanted to put another module defined in a file named "buildingRoof.txt" on top of my module, I'd have:
buildingRoof.txt 0 1 0 true
And, of course, I would have to have the buildingRoof.txt file. These links should only be included a single "anchor" module, so buildingRoof should not have one of these.
Center section: a list of commands to add the parts of the module that are always present (floor, ceiling, etc).
Corner section: a list of commands to add in a corner. These always get added, too, but unlike the center section they get added four times (one for each way of rotating it). This has been done extensively in the walkways I've coded in.
Wall section: a list of commands to execute when a 0 (no connection) is encountered. Due to the way the rotations are set up these should always be written for the right connection (so your x values should be between 5 and 7).
Walkway section: a list of commands for a walkway connection. Ditto with the directions.
Room section (room modules only): A list of commands for a room connections. Same with direction.
Well, there seems to be one on their download page, though I have no idea if it's single or multiplayer, so idk.
The rectangular prism is a must indeed, considering the amount of planes and walls... Though, as to save development time, maybe it would be a good idea to add a module, well, interpreter, that would build a module, using a linear array of commands in form of "#Blockid#BlockData#X1#X2#Y1#Y2" (yes, I know, there might be a better way to do this, so sue me), so it would be possible to store modules in text files (since, I bet, people would like to see their modules before they are presented out to the crowd and hard-coded into the system). Unless you plan to do that part single-handedly... Like a bawws!
The connections could be stored the same way, just running afterwards and replacing the blocks... Having only one file for their block data would limit the "can fit" function to checking, if there's a connection of that type in the module, considering there will be more than just walkway-bigroom, of course.
Just could be good to separate the daa and the generator itself, so that modules could be worked on separately from all the code.
The big room could be made a tad easier by adding to each module of it four references to other modules of this room, determining, which one should be put in from that side (and with some randomization, probably. would ease the aqueducts a lot).
Though oh well, I'm saying too much for a guy that isn't making anything but lousy textures. Storing maze-blocks as a negative value is good... Are you planning to redeem that into different blocks, based on the biome?
Well there's another API I'm using for the dimension, too, so there's that.
The idea is each module is stored in a text file, and made into a module object when the generator starts up. Then it's just as simple as pointing the mod to the right text files.
What would be really neat would be making some sort of debug block where people could right click on it and open up a GUI, enter in the connections and the name of the file, and the block would place the module right there. Then people could test their designs to make sure they work before submitting them. Doing this is a bit beyond my current level of expertise, but it's probably possible to do.
Different blocks by biome... that's an interesting idea. Actually, doing all the block id's like that (giving numbers that are then translated into blocks) would mean that modules could be reused in different districts simply be replacing their block id's with others (essentially a recolor).
Original suggestion here:
http://www.minecraft...infinite-ruins/
Mazeworld, a largely popular suggestion in the suggestion forum, is now being worked on as a mod. It is an infinite dimension of structures and dungeons, representing both chaos and order. The dimension is divided into various districts (analogous to biomes in the overworld).
At the moment this thread has become more of a discussion on how to better accomplish the structure generation, not only to introduce more variety but also so we have some open source code that can be used for other mods involving structure generation.
I'll try to update the OP for major changes.
Some suggested features include:
Garden District: An overgrown, lush district full of life. While garden districts represent nature in Mazeword, they should still be very orderly in some sense.
Temple District: A district of ornate buildings resembling places of worship. I'm picturing it as having a somewhat ancient Greek style, with columns everywhere, as well as perhaps having some repeated symbols etched into the architecture (for example, the symbol on the banner in my signature).
Foundry District: A fiery district representing industry. The foundry district should contain lava flows, minecart tracks, furnaces and anvils. Most of the structures should have kind of a burnt-earth color to them.
Venice/Atlantis District: A district that has been flooded with water. The surface should have plenty of canals and bridges (creating a Venice-like feel). Below, flooded hallways and hidden grottoes make exploration a challenge.
Tower District: A district that's basically a maze of towers and walkways going everywhere. Navigation in this dense city center should be difficult.
Libraries: One popular feature that has been suggested quite a bit is giant libraries. I'm not sure if an entire district could be designed around libraries, so I'm hesitant to describe this as a district in of itself, but libraries should definitely play a part somewhere.
Towers: Mazeworld's skyline should be broken up by crazy, twisting towers everywhere you look. Walkways should connect these towers in a very irregular and random fashion. These towers could have very different looks stylistically, though I think European castle styled towers should be fairly common.
Aqueduct System: Another striking feature of Mazeworld should be the enormous aqueduct system spanning across the map. This will be basically the most efficient way to travel long distances in Mazeworld, though the aqueducts themselves should form a maze on an epic scale.
Epic Structures: Every once in a while while exploring, players should come across vast, epic structures on the surface that seemingly defy all explanation. These would likely take up an entire district's worth of space.
Help would be appreciated, as fleshing out an entire dimension is a tall order for a busy college student with little modding experience .
Edit: FIRST! (I know, typically frowned upon. However on a project this epic, I can't resist.)
Btw, that's quite an awesome progress you've got there!
Almost motivates me to stop sitting on my hands.
Also, none of the threads feature any banners yet, nor any textures (thogh, I imagine, the marble ones have to be cropped and rescaled at places considerably)
(terrain/mobs/armor)
I imagine first we have to let him have his fun with module-building.)
(terrain/mobs/armor)
Generally I sit down and work out how to make each module by working out the relative coordinates of each block. I currently have two methods for placing them, one for a single block and one for a rectangular prism of blocks. I found myself doing the latter quite a bit (floors, walls, ceilings, etc. are all rectangular prisms) without having that method, so I wrote it to speed up coding them in.
As far as rules go, they need to be either 8 or 16 blocks wide and long (so 8x8, 8x16, 16x8, or 16x16). If it's not going to be on the surface, its height should be a multiple of 8, too (though you can generally just fill in extra space with blocks, seeing as how it's underground). Keep in mind that neighboring modules may want to connect to you, so if you want walls on the sides (or multiple levels for underground structures) you should design pathways to accommodate at least a 2 x 3 connection, centered on the cube's edge (and a 6x6 one, if you want it to be part of a larger room).
Edit: As far as dimensions go, that's just kind of the rough outline of sizes. If you want to make weird L-shapes or other things, those should be okay, too, so long as they can be divided into 8x8 cubes.
Can't say the names, but they were mentioned in the "suggestions" thread...
Eyeofthedaev, so... And how do you put in the connections now? They're just holes you generate somehow?
(terrain/mobs/armor)
If y'all think they will go well, I can design some more, including 8x8, 8x16, and 16x16.
(terrain/mobs/armor)
WEll yeah, they made some underground mazes from what was on screenshots. I didn't use any, though, so maybe there was more to it... And, biome-only would be... tricky, considering the maze is made from cubes and biomes aren't that strict.
(terrain/mobs/armor)
They are planned as a way of making people interested in exploring... If you wish, you can make your own textures, of course, though I would recommend looking through the textures in suggestion thread (okay, okay, there's so-so mine and awesome marble of some guys', but oh well) and seeing what you (maybe) will have to be neighbour with.
(terrain/mobs/armor)
More or less, yeah. To make it easier on myself, I made abstract subclasses for modules and walkways, with methods for adding the center (floor, ceiling, etc. - pretty much everything that's always going to be there), and methods for making one instance of each kind of connection - so I have one that makes a wall, another that makes a doorway, etc. These are called in the abstract subclass's methods accordingly, but don't really have to be dealt with directly, in order to avoid tedious duplication of code across every module.
The caps would look really nice on top of towers (which I have yet to make), I think. They would break up the skyline pretty well, and variety is always a plus. Shorter ones could probably be placed on smaller building modules a little closer to the ground, too. If you want to design more, that'd be good, though you may also want to start thinking about designing some buildings for them to go on top of.
Yes, new blocks are going to be a major feature. I think for the most part they're going to be purely decorative, though functional blocks aren't totally out of the question.
I'm asking because it would determine, how the modules can be made, and, more importantly, the amount of work spent on each module. (and because I have an itch in the back of my head, when i can't figure out something, that looks important to me)
Ideally I'd suggest somehow storing each connection as an 8x8x8 array of it's own, or at least an 8x8 plane, considering that they might vary more than just size, and pasting it over the module somehow... But maybe I'm just being stupid...
And, I don't think there's ever a need in new functional blocks...
(terrain/mobs/armor)
If you say, that coding them in is a temporary decision, then you should remember, that there's nothing as permanent as temporary decisions. Expecially when you build the rest of architecture around them... I guess I could help you with some code by now, if you have any comments in your code.
...also, there seem to be forge for 1.4.5... What's the problem with that one (if you're still using the 1.3.something)?
(terrain/mobs/armor)
Hmm... I think I see what you're getting at here. It would save a lot of time in the long run to develop a system to convert, say, text files into modules, because then anyone could easily create them. It's not so much a feature to save time in running time as it is to save development time. I would still like to keep the functionality of defining modules in the code, simply because some more complex modules might require features that would be difficult to include in a generic text file setup, but most (if not all) of the modules I've designed so far follow a similar formula.
If this system is something you guys want to pursue, it may be good to step back and work out how we want this to work before coding it all up. A few things right away:
We probably want some time saving shortcut commands for making certain shapes (i.e. rectangular prisms), because typing out every block by hand is time consuming. I've been noticing I've been making a lot of empty squares as well, perhaps another one for that?
Being able to set metadata is a must if you want vines, ladders, doors, stairs, mossy stone brick, etc.
We need some way to identify our own custom blocks, preferably without using their actual block ID's (as these may be subject to change). One idea for this is to indicate custom blocks with negative numbers, and in the code convert these to the actual block id's.
Edit: Thinking about this, for each module, we'll probably want to have the following:
The first line of the text file is a little descriptive blurb on what the module is. The program just ignores this line completely, it's there for humans only.
A line indicating the type of module (room or walkway, though I may need to add more types for larger module segments), rarity, and the levels it appears at. I'll probably just define a couple different preset values for this, i.e. top, upper-middle, lower-middle, bottom. There may be extra versions of these added later for interesting effects (for instance, for airier looking districts, it might be cool to have floating walkways that generate over the normal "top" walkways. This can be accomplished with different conditions for the top and upper-middle modules).
An optional "link" section (?). Ideally this would let you list other module files that generate alongside the defined one. The general format would be something like:
File name x coordinate y coordinate z coordinate check conditions (true/false)
The coordinates would be in cubes, of course, and relative to the current module. Check conditions would indicate whether or not it should check that module's conditions for placement (most of the time this will be true, but there may be cases where you wouldn't want to do this). So, for example, if I wanted to put another module defined in a file named "buildingRoof.txt" on top of my module, I'd have:
buildingRoof.txt 0 1 0 true
And, of course, I would have to have the buildingRoof.txt file. These links should only be included a single "anchor" module, so buildingRoof should not have one of these.
Center section: a list of commands to add the parts of the module that are always present (floor, ceiling, etc).
Corner section: a list of commands to add in a corner. These always get added, too, but unlike the center section they get added four times (one for each way of rotating it). This has been done extensively in the walkways I've coded in.
Wall section: a list of commands to execute when a 0 (no connection) is encountered. Due to the way the rotations are set up these should always be written for the right connection (so your x values should be between 5 and 7).
Walkway section: a list of commands for a walkway connection. Ditto with the directions.
Room section (room modules only): A list of commands for a room connections. Same with direction.
The rectangular prism is a must indeed, considering the amount of planes and walls... Though, as to save development time, maybe it would be a good idea to add a module, well, interpreter, that would build a module, using a linear array of commands in form of "#Blockid#BlockData#X1#X2#Y1#Y2" (yes, I know, there might be a better way to do this, so sue me), so it would be possible to store modules in text files (since, I bet, people would like to see their modules before they are presented out to the crowd and hard-coded into the system). Unless you plan to do that part single-handedly... Like a bawws!
The connections could be stored the same way, just running afterwards and replacing the blocks... Having only one file for their block data would limit the "can fit" function to checking, if there's a connection of that type in the module, considering there will be more than just walkway-bigroom, of course.
Just could be good to separate the daa and the generator itself, so that modules could be worked on separately from all the code.
The big room could be made a tad easier by adding to each module of it four references to other modules of this room, determining, which one should be put in from that side (and with some randomization, probably. would ease the aqueducts a lot).
Though oh well, I'm saying too much for a guy that isn't making anything but lousy textures. Storing maze-blocks as a negative value is good... Are you planning to redeem that into different blocks, based on the biome?
(terrain/mobs/armor)
The idea is each module is stored in a text file, and made into a module object when the generator starts up. Then it's just as simple as pointing the mod to the right text files.
What would be really neat would be making some sort of debug block where people could right click on it and open up a GUI, enter in the connections and the name of the file, and the block would place the module right there. Then people could test their designs to make sure they work before submitting them. Doing this is a bit beyond my current level of expertise, but it's probably possible to do.
Different blocks by biome... that's an interesting idea. Actually, doing all the block id's like that (giving numbers that are then translated into blocks) would mean that modules could be reused in different districts simply be replacing their block id's with others (essentially a recolor).