Vanilla generation.

[JeppeKlitgaard]

At the moment generation seems, for me at least, slow, buggy, and bland. This is of course not meant as an offense to whoever coded the generation code, as they sure did a much better job than I would ever be able to, but even so, it is no match for vanilla terrain generation.

At the moment I am not sure I feel confident enough to implement vanilla generation (or very close to). But maybe some other, braver coder out there wants to give it a go?

_A few approaches I imagine would be viable are:_

Bukkit with JNI

Use JPype along with Bukkits.
This seems like the best solution, especially long term.

pymclevel

Use pymclevel (This is what MCEdit uses) to generate world.
This option seems somewhat less great, since _pymclevel_ just starts a vanilla minecraft server in the background to do the generation (As far as I've been able to see, in the 2 seconds I looked at it)

Try and implement the exact vanilla generation code in Python

This option is mostly here for completion, I don't think this option would be very smart, especially from a maintenance standpoint

Keep current generation.

This is also a quite viable option, although vanilla generation would probably be best.

[MostAwesomeDude]

I'll agree with you on "bland." "Slow" isn't right; try running the benchmarks under PyPy and see the difference. As for "buggy..." What's buggy, exactly? Could you nail it down?

For licensing reasons, we can't carry any code that depends on Mojang code (which is proprietary) nor Bukkit code (which is GPL and owned by toxic people.) Any solution along those lines would have to live outside of Bravo and use the plugin interface or operate offline. This is actually the reason why plugins are so flexible; somebody suggested JPype years ago, and I told them that they should go for it.

Reimplementing the vanilla algorithm is a great idea, except that it changes all the time. Because of the way that the noise generation is structured in vanilla, any refactoring or fix to that section of code causes the entire algorithm to change, because the order of random numbers changes. (One of Bravo's design goals was to not have this problem.) It would not be hard to maintain; you would add an extension to Burger to version the generation code, and then update whenever that code changes. Dirty but possible. I even created the java-random package on PyPI to provide a Java-compatible random number generator, so all the pieces are there for anybody who wants to try.

There is another option that you didn't mention: Add another generator! Bravo's generator pipeline is fully pluggable, and it would be possible to create new and different worlds simply by writing a new generator. Take a look at the current generators in bravo/plugins/generators.py and see what they do.