Jump to content

April 2017 »

232425 26 272829

Recent Entries

Recent Comments

- - - - -

Moar Functionality

functionality more of it java terrain generator
4: Adsense

Hi! On this entry I talk about features I'm going to add to the terrain generator, to make it both more usable and prettier.

Moar Functionality!

In the previous entry I made a GUI for using the generator, you can go there and download the generator if you want.

The GUI I made for the terrain generator isn't all I wanted it to be. Ideally, it should be more "interactive". I had theorized that it should be possible to add ridge lines and/or river on already generated terrain, as it is, you set up all at the begging, let the random.nextFloat() do its magic, and you got a randomly generated terrain.

Attached Image
This is the GUI I made a week or two ago, I'm still pretty happy about the fact that resizing the window works perfectly as long as you use LayoutManagers in Java Posted Image

The way the terrain gets generated allows some quite nice ways to "sculpt" it. Well, its not like you can seamlessly add new ridges to it once all other passes have been made, but remaking the necessary steps shouldn't be too taxing unless you're doing 2k maps or something... weirdo Posted Image

Of course, using several threads for processing could speed up things considerably, but I should structure the whole program better before doing that. While I know the threading structures in Java and I have the theory worked out, I have yet to properly do a multi thread implementation of something.

For example, the Diamond-Square pass (I honestly don't remember if I ended up using diamond-square or midpoint displacement) probably lends itself well to multi threading once corner cases have been taken care of. Gaussian blur... I have no idea, probably yes, I have to look it up.

Ridge lines and river lines... now that's different. It would be basically a primitive multi threaded physics system, and I'm not sure of the benefits. Ridge lines are simple enough that 1 thread alone can do the work in 50ms or less on a 2k x 2k map (on a Core i5 2500 mind you), which is good enough.

Thing is, both rivers and ridges should check for collisions among themselves. Good thing is that height isn't directly writes on the heightmap while ridges/rivers are being generated, height values are written after the generation stopped. So the heightmap should be constant while the ridge/river generation is working, the particle map on the other hand needs to get written so particles know what other particles are around when they move. And that's when multiple threads don't look nice Posted Image

It is doable, sure, now, it is worthwhile? In the case of the rivers probably yes, river generation is expensive. In any case, muti-threading the generator is on hold for now.

Prototype! (Disclaimer: Not the game)
I prototyped a GUI that should expose tools kinda like a paint application. You'd have a panel of tools with buttons for selecting them (ridges, rivers, or something else) to the side, and you could create new heightmaps pretty much like you create a new image in paint.

I also changed the LookAndFeel to "Nimbus" because its nice and rounded:
Attached Image

Say that you want to place a new ridge, you'd select the ridge button, then click where you want the beginning of the ridge in the heightmap, then click on the end, the program should generate a random ridge line (with subridges) that starts and ends on those points.
Rivers would work differently, they would follow the "rules" of the maps, that means, rivers start at the top of ridge lines, and they fall accordingly to the heights surrounding them. So the river tool would allow you to place the beginning of a river only.

On a semi related note, I'm half sure I could implement coast lines not in a very different way than the ridge lines, but I have to investigate it further.

Broken Stuff be Broken

Now, say that we place two ridge lines, the program should be able to do the MDI and MD passes to show a terrain that somewhat conforms to those ridges. The problem right now is that I actually don't draw the ridges on the map, they're there just to act as a support for the rivers. The rivers are the ones who define the general shape of the map. Without rivers, placing a ridge or not will net you the same result, it doesn't affects the landscape at all.

If I do write the main ridge lines to the map, they end up as a soft line that looks much like a dry river or something like that, which isn't what I want.

Extra Benefits

One of the benefits of bringing such features is that testing the algorithms should be far easier now. Before I randomly generated everything, now I'd be arbitrarily set ridges and rivers where I want and see how they behave. Besides, it'll be more fun to use that way.

Well, I rambled enough I think! Cya on the next entry Posted Image

Note: GameDev.net moderates comments.