Moar Functionality

Published September 15, 2013
Advertisement
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.

[font='comic sans ms']Moar Functionality![/font]



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.

previousui1.png
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 biggrin.png

[font='comic sans ms']

Purrformance

[/font]
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 tongue.png

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 unsure.png

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.

[font='comic sans ms']Prototype! (Disclaimer: Not the game)[/font]


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:
uimockup1.png

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.

[font='comic sans ms']Broken Stuff be Broken[/font]



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.

[font='comic sans ms']Extra Benefits[/font]



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 biggrin.png
Previous Entry Apps n' Rivers
Next Entry GUI Advanced
0 likes 0 comments

Comments

Nobody has left a comment. You can be the first!
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement