well, put like that it seems pretty straight forward... point A might be a bit tricky, as i have no idea on how to do that...
I gotta admit the whole "big structure" thing kinda goes over my head, as I'm not really much of a programmer. I merely have some ideas and then hack together something that appears somewhat functional... I didn't actually put much thought into it when I wrote that generator.
Might as well scrap it and start over from scratch, with a real plan this time...
Actually, I'm working on that right now... I'll try to shift all info that the generator needs for placement and connections into the template files that I build the modules from, so that new modules can be added by simply dropping a new template into the config folder xD
Ditto with the starting from scratch, I think. I'm going to try to assemble some sort of plan for moving ahead this time, though, so I have everything I'm going to try to do accounted for before going and doing it.
Larger structures... well they'll be interesting to work with, to say the least. I'm not entirely sure how I'm going to do that, either.
So I now have a very vague list of things we want to get accomplished in the OP. Thoughts? We can talk about the actual implementation once we feel like we have everything we want to do as far as the generation goes set in stone (so to speak).
And, you still need to differentiate the biomes, so, I'd guess, adding a biome file with list of modules (or just having a unique biome number stated in them all) and a few settings like, say, rarity of the air gaps and the ranges for top-middle-bottom slices (and their vriation, maybe?) would be useful someday. Though maybe not.
It starts to look like a huge heap of text files already, heh. So very linux-like. Or bsd. Or whatever you prefer to dissect in vi/nano/emacs.
All I can think of for the towers, being connected from top to bottom is checking for stirs around and generating one if none found, but that's a tricky thing to make when you're not entirely sure if it's a tower or not. On the other side, would be safe to just leave some places unaccessible.
Yeah, very file based it seems like. I'm not sure about the biome definitions, although I figure each one will probably have its own include file.
Well, it's not like player won't be able to make stairs if need be, I suppose. Keep in mind, too, that I would really like to put in walkways between levels of towers, so by hopping from one tower to another a player could climb higher.
Well, that shader would be a bit of cluster, and would require lots of memory to store absolutely everything it needs to give any benefit.
Region generator would be nice, the only problem I see is the fact that you can't really controll, when the next chunk will be generated based on user movement. So it's either a lagfest with everything generating 'in one go', with the chunks somehow made to generate, or saving everything for later and then generating everything per chunk from that data. Only difference we can make is with "where the daa is stored", with choices of operative memory and hdd, with operative memory absolutely requiring us to have everything done the first time, because there's always a possibility that user will do something to erase it, like turning the game off. Hdd, as I see it, can make some lags on it's own, but ultimately will be easier on perception than making evrything at one go, especially if we allow for undefined size structures, like aqueducts, that take a random number to see if they should stop or turn. Just imagine, exploring with tiny rendering distance and then BAM - going to drink some tea because some big thing decided to happen.
What I'm meaning to say - it's not nonsence, it's just bit more complicated than it tries to sound.
A collaborative project would be neat. Maybe make it an open source deal for people to use with their various mod projects?
I think the region generator idea could work. I suspect (but don't quote me on this) that strongholds and abandoned mineshafts work on a similar system. When you get right down to it, my chunk filling object is basically a region generator that works over the whole area.
Edit: So basically, for things like aqueducts or large structures, you figure out where to put them in that region, then when you ask for a chunk you go to where you figured that out... interesting. I suppose if it were based on pseudo-random shenanigans it could even generate that data on the fly, every time it is needed (much like Perlin Noise).
Well, Java works on its own virtual machine, so I'm not sure if it can even get to the GPU... though it's an interesting thought.
open source would be the way to go I guess...
But we should try to release it as a standalone generator mod, not just an API thing for other modders. Its way too powerful for that xD
basically my chunk filling object is the same xD an additional region layer would allow to supply it with lots of useful additional data, i guess... its quick to generate 32x32 mazes of streets and aqueducts and so on, even if it happens very often...
Standalone generator mod. Oh hai there structure dimension.
Actually, it would be really cool to do the aqueducts recursively, like you start with preset ends in the region, and, starting at each one, keep going from each one until you hit something. Might be a tad slow, though...
"Science isn't a matter of WHY, it's a matter of WHY NOT? WHY is so much of our science dangerous? Why don't you marry safe science if you love it so much? In fact, why don't you invent a special safety door that won't slam you in the butt on your way out? BECAUSE YOU ARE FIRED!" -Cave Johnson
Heh. Or we could put it on git and motivate open-source solution.
It's a bit wrong to plan such a complex thing beforehand, since we don't know, what that API will be like at all yet, but it would certainly help to arrange all the incoming ideas into manageable "to do" lists and charts. Set up a vision we could show other people without having to explain every bit they 'visioned' wrong, perhaps?
If nothing better, we can just go back to stock-piling resources like module structures and textures, until we're up to actually using them.
Well, it's a good idea, since all the functions from actual minecraft can easily be called through custom functions (forgive me, my programmer slang is nonexistant, since most I learned I learned on my own (sadly)). But still, if we're making that, we have to see, how it works. How are you going to test an abstract framework? TDD? or by writing a simplified model? I'm just kind of worried about using functions, that look handy, but might not make it into the api. Those are usually a pain to replace.
I'm not entirely sure. Are we really going to be using anything beyond just placing blocks? I guess we could try setting up a simplified model program, though I'm not sure how that will work out in the long run.