I dunnit !

Finally sewed all the seams together! This screenshot shows a patch of 4x4 chunks.

features:

• - chunked LOD


• - 1 chunk = 64x64


• - 4x4 chunks


• - simple LOD algorithm (based on 2D distance from centre-of-chunk to camera, height does not count)


• - 1 single texture for every chunk (to downsize demo and because I don't have texture mgmt)


• - normally, one texture per chunk (no multi-texturing) with red edges to find chunk edges


• - direct-mode passing of all data (no display lists, no vbo)


• - 1 dynamic light, just to enhance landscape features a bit

keys:

• - arrows = navigate


• - CTRL+arrows: yaw/pitch


• - Q/W = change the height (I'm on AZERTY, so you may need to press A/Z)


• - A/Z = change FOV (same remark)


• - D = print debug, including FPS


• - T = toggle wireframe

Known issues:

• - fps is calculated based on currentTimeMillis(), and is only updated every second (to compensate for lack of accuracy)


• - popping


• - performance (init is slow, + very inefficient storage of heightmap)


• - ridiculous memory consumption

TODO:

• - compare display lists / VBO


• - geomorphing?


• - multi-texturing (will allow pre-rendered lightmap)


• - refactor my chunked code into something actually usable

fixed the level of detail seams !

st0op!d bug, returning the wrong height values at the seams, resulted in cracks. Fixed that, so the north-south connection now has its cracks eliminated. Now I need to do the textures correctly, THEN I can go to the east-west connect (+ textures), and THEN there's this little crack in the north-east corner because I don't have that neighbor (yet).

Phew, making a terrain is hard work!

First level-of-detail

This cyber landscape is a wire-model of the heightmap I've loaded. You can cleary see the landscape being divided in 4 "chunks". Each chunk has a simple level-of-detail algorithm: if the distance between the center of chunk, and the camera is big enough, the number of "patches" for each chunk is divided by a power of 2.

Now I just need to figure out how to sew these chunks together with their neighbours, because there are wide gaps between all of 'm.

Everybody loves screenshots :-)

This a much more "normal", and natural-looking chunk of terrain, wouldn't you agree? This is the straight-forward one pixel = one vertex solution. The colors come from a simple texture that I sort of derived from the heightmap. The texture contains as many texels as the heightmap contains pixels. The darker lines/smudges in the fore-ground for a text. This was the easiest way to make sure the texture wasn't inadvertedly mirrored.

Now, I'd like to do shadows. For performance comparison, I will turn on dynamic lights and see the difference, and then I'd like static, but on-the-fly lightmapping for the terrain.

And then, it's up to level-of-detail ! woohoo !

This screenshot shows a JOGL application displaying a 128x128 heightmap, but with a little twist. Instead of each pixel giving the height of 1 vertex, a pixel defines the height of 4 vertices. That means I need extra quads just to weld everything together. I added the extra quads in one direction, but not in the other. You get "slices" of land!
The effect is funny, but not the least bit natural, because of the lack of sloped surfaces. Back to the drawing board :-)

However, drawing 128x128x3 quads, each containing 4 vertex coordinates and texture coordinates, is still running smoothly. I like "smooth"!

NextStep

Next stop = terrain rendering!
Since it is a part of so many other games, and it can be nicely isolated, it is a logical thing to be working on. It also has plenty of literature.

I'm still wrestling with a good class hierarchy for the rendering process. In my simple previous examples, all renderables implemented the same interface, and they were added to an ordered list. This flat model cannot be maintained for more complicated scenes, I think.

On another note: I've thrown up another ball about a generic 3D Model converter/loader interface. If that takes off, I'd be thrilled to cooperate.

GAME 3,4,5,...

smaller dreams:

1. Scorched Earth 3D: turn-based, or interactively
2. A heli sim: but I would rather play it than program it.
3. I've been told (many times) I should start small, like Tetris, Arkanoid and Invader clones. Meh.
4. Giant Pinball: multiplayer game where each player is a ball inside the pinball machine. Might make for interesting visuals, but I would need a bit of physics, and level design is extremely important. And what exactly would be the goal of the game?
5. Epic clone! Or, since Epic is really a rip-off of the Battlestar Galactica series, I could call it a BSG clone as well. Where most space-shooters have their dogfights in the middle of open space, I believe this makes for boring dogfights (point ship - empty guns). In Epic, you were a fighter pilot who defended the fleet against enemy attacks. I just really like the idea of small fighters dogfighting in the midst of giant battleships and transportships of the fleet. IMHO, it's more interesting to fly between those ships and having to dodge tankers etc than it is to fly in empty space.
6. A 4D Stunts clone used to be part of this list, but then came TrackMania. Shame on me for still not having bought it! It's great!

GAME2: Dune

(we continue the day-dreaming :-) )

I'll describe this in the setting created by Frank Herbert, because that's how I imagine it. But I mean no copyright infringement, and so I might have to relocate this.

Every player starts with a basic "sand buggy", capable of harvesting spice on the surface, and a little gun. By harvesting spice, and selling the part you don't need (your buggy runs on spice), you gain money. You can use this money to upgrade your ride, and possibly specialize its purpose. Someone who wants to be a pirate would secure himself a fast vehicle, incapable of harvesting by itself, but capable of stealing spice from another vehicle, and blasting them to smithereens. Someone who fancies flying could secure himself an ornithopter or carry-all, to move spice harvesters, scout for spice ground, or air-to-surface attack.

The original idea was that players could also have "parts" of vehicles, that they needed to connect through standard couplings. There are a number of disadvantages: the physics engine would need to be more complex, the network delays would be more visible, multiplayer might be less rewarding because of the higher degree of cooperation.

GAME 1: Earth, Wind & Fire

Can I dream for a second?
Or rather, for a couple of years? I'm only doing my first steps in Java 3D programming, and I'm already fantasizing about big-budget A-title games. Oh well :)

MMORTS; the new killer-genre!
Every user takes one of three roles.
Fire is the basic role: this user can command fighter units, and will engage enemy units
Earth is the builder: this user can create buildings, dig trenches and blow up/convert enemy buildings. Example buildings are garages to store friendly units (while players are offline), automatic turrets, to defend everything even while players are offline, and silos to store resources.
Wind is the economist of the group; this user will gather resources, control the units that transport and harvest the resources. They will also assign these resources to other players as they see fit. This makes them powerful, but also an attractive target for extortion, attack, etc.

• Alliances are not explicit, and only very loosely enforced by the system. If a player decides to switch sides, he should be able to do so very easily.
• If a machiavellian "Wind" player decides to deliver resources to two different, fighting factions, he should be able to do so.
• Because of the previous, "ownership" of buildings, or units, is a very relative thing. When a player goes offline, what should happen to his units? Divided over remaining players, or ready to be captured, or stored away until the user returns? If the units are not stored, a player is severely punished for going offline.
• The number of units controlled by a single user should be limited, in order to force cooperation, and to stop a single player from overwhelming a band of newer players.
• The https://games-darkstar.dev.java.net project looks promising, and might very well be an excellent way to program this type of game.