… wow dude, you’re bitter. Also, and not to be insulting, but magenta-on-black is perhaps not the most readable of website color schemes.
Your whitepapers go a lot more into the technical aspects (which is important) where I’ve mainly got content-related stuff like the various special abilities (magic, martial arts, etc.,) user-level interface function, the game system in the tabletop-RPG sense, a 3000 year plot for 1p/co-op Story Mode (the Prologue shows your character being created as one of a more-intelligent Star Wars Ep1 style robot army and having the responsible would-be-conqueror wiped out by government forces, then get assigned to a civilian contractor (read mercenary company, the replacement for fantasy-mmo guilds) who’ll try to integrate you with regular society while turning your skills to a marketable use. Customising or replacing your body is one of the core mechanics so you have no fixed lifespan;) a couple of minigames, that kind of thing. I also had a good dozen or so character and enemy models on the dead computer, but can’t find the one thumb drive I’m pretty sure I’d backed them up to recently, jammit.
Regardless, we shouldn’t hijack the thread for talking about our stuff, I suppose, where it doesn’t have relation to terrain generation. I’ve pretty much already covered everything relevant to that, so I’ll stop now.
ETA: Inspired by your whitepaper listing for non-spherical and outer space worlds (even though it’s just a “To be done” my system of having an overworld map that controls terrain gen by which pixel your location corresponds to would also apply there - just define how the cartesian texture map applies to the nonstandard shape, and as the user travels from one area to the next they’l automatically move around a whatever world shape you set. The only real issue would be working out how to tell the skybox to put in the other side of the ring when it should be overhead - though at least the overmap would make sure you already had a texture for it.
One possibility would be to actually create an example of whatever the world shape is and use render-to-texture to put it into the skybox - it would of course be FAR FAR beyond camera cutoff to just put the thing literally into the sky. This system would make it relatively straightforward to use, though. My own favorite shape for a world comes from a paper model I once made of a bunch of tetrahedrons assembled into a hollow tessellated icosahedron with a few of the faces missing so you could get into the hollow interior. I don’t at this point, remember how many or in which positions, but about thirty seconds looking at a d20 would solve that.
ETA2: Don’t be too impressed by my C courses - only the 300-level even touched on the basics of 2d graphical interfaces. 400 was entirely about data structures and manipluating them, IIRC… basically what having taken them means is that I know how to read an API document and can usually get the examples from one to work using my variable and function names, after a suitable amount of… “incantations” and time.
As to modifying the generated terrain, I’ve never actually played any of the Sims games so I don’t know what you mean by “Sims-Like” but essentuially all I’m saying in my previous post is that you have XY patch of “ground” that’s defined as flat or by a height map, and spot it into your infinite procedural section by defining a zone around it where the z-values get mixed from one to the other - like the way a soft-edge brush transitions from the background color to the active color using alpha mixing, or texture splatting on terrain image maps.
Exactly like texture splatting on a terrain image map in fact, if you’re using a height map. I’d expect a similar fuction to be necessary to transition between overmap-pixel regions.