Year's end and looking forward

1. I added small rocks to the scene. Even with just one texture, they add a huge amount of visual interest.
2. I've implemented additional fragments of the unified movement engine. Notably, movement and AI are now separate processes, and movement has been tested a little bit. Lots to go, but progress is being made.

I think I'm going slowly at this point partly because I'm afraid of failure - that the engine won't be fast enough, and that it will thereby bring the entire project to a flaming halt. It's a deeply-ingrained fear, born of three generations of coding "dead points."

3. Normal mapping is now fixed for terrain (before now, it was far too dark at sunrise/sunset)


Finally, I have a writeup of one of my "long term goals" for the game - that of ecology. This is basically guidance for implementation, based on projected things I want the system to achieve. It may not be complete, and not everything here may make it in.


Long-term goal 1: Implement ecology.
Subgoal 1: Silent running. Ecology should have less than 5fps effect on game speed.

Subgoal 2: Animal movement. Animals should move when appropriate, and enough to give an approximation of life.

Subgoal 3: Animal numbers. There should be about 50 predator groups and 100 prey groups on the map. Predator groups should consist of 1-5 animals; prey groups of 1-10. Average total animals on the map should be ~500-1000.

Subgoal 4: The hunt. Predator animals should attack nearby prey animals (when they approach through wandering). They should start running after a given closest animal (as communicated to them by random localized AI checks), and if they catch it, should kill it. Its neighbors should keep running for a while after.
Facilitation 1: Each animal in a group knows all other animals in the group.
Sub-subgoal 1: Predatory groups should regard workers in the same manner as they do other animals, and have the possibility of electing to hunt nearby citizens.

Subgoal 5: Herds. Herd animals should move with brownian motion normally, but if they have elected to move and are outside the herd's target point, they should move there. This will allow natural migration to watering holes/grazing areas.
Facilitation 1: Target points are set for groups every so often. They are determined for a group when the group spawns (loading time)

Subgoal 6: Hunting. As animals are designed to be hunted, they must be designed to be replenished. Groups should add new animals to replace ones that are lost - if they are below a certain threshold, and if there are at least two animals remaining in a group.
Facilitation 1: Each group has an optimal population count, set at load time and typically 50-75% of the group's starting population.
Side benefit 1: Predators and large animals (like mammoths!), which have smaller groupings, will be more likely to die out - erasing "rare" species from the map over time and reducing the danger involved in hunting.
Side benefit 2: A growing city will likely be forced to change its food source from hunting to something else, as all the local animals disappear.

Bushes, specular, etc.

1. I was able to add specular elements to the terrain shader with no speed repercussions. This means that various "shiny" elements of the terrain now properly show up - highlights on grass, snow, shiny rocks, and wet sand are all possible.
2. I created a third paged geometry manager to handle bushes in the local regions (around the camera). This has the effect of increasing ground cover in regions otherwise devoid of anything but grass - adding a good bit of visual interest to the scene. They are set up to have density dependent on fertility and temperature.

3. I implemented several optimizations for the unit manager. Units will now do no per-frame code execution unless they are both visible and moving. They update their positions every N frames, where N is the number of frames it takes to move ~8 feet in any direction - and between these updates, they use a combination of original position, original timestamp (when they were at said position), and velocity to maintain their curent location. This has the added benefit of being highly useful for multiplayer.

Hypothetically, I should be able to handle upwards of 4000 units in an active game, or 200 for each of the 16 players plus 800 animals. I have high hopes for this system.

4. I have additionally created a graphics settings program- it contains all the useful graphical settings in one easy-to-use and easy-on-the-eyes location.

5. And finally, I have been experimenting with normal mapping on the foliage in the game, with mixed results. Generally speaking, it looks nice in close-ups of the trunks, but is invisible at standard playing distances. Overall, it probably ain't worth the extra cost in shaders.
On the other hand, I did manage to get the deciduous trees to render with lit trunks and unlit foliage, which does wonders for their cohesiveness. This is an optimization that may well be worth the effort... and it's possible I could add self-shadowing to complete the shading effect. I'll have to investigate this particular concept farther.

Shadows added!

Since I started modifying the terrain shader, I have had no luck getting shadows to work in the engine. Through a combination of wholesale stealing and careful modification, however, I have been able to add shadows to the terrain shader, making it slightly slower and a whole lot prettier. Forests, especially, epitomize both the speed issues and the prettiness bonus.

In other optimizations, I cleaned up a lot of the nonsense code in the terrain shader, removed a couple of if statements, and got rid of a lot of division. It's still not as fast as I'd like, but it's probably about as fast as it can reasonably be. (Translation: Without diving into the assembly code!) Other code needs my optimizing attention more!

Working things out

Working things out before coding is important if you have a complex project that needs to be done, and needs to be done right the first time. It's also important in a general sense, but I don't do it that often.

Right now, I'm working out exactly how to handle units without classes. (It's significantly more efficient to do things this way in GM)

Basically, I can separate the unit functionality into four components:
* Data - this is inert, nonactive stuff stored in arrays that describes the unit in question. It is referred to, and acted upon, but never acts itself.
* Loops - this is where the simulation and the unit interact. This includes the movement loop (which is designed only to act on units that are actually moving) and various AI counter loops (which only act when needed).
* Grid presence - units will show up on a variety of maps and grids that help expedite AI speed. I figure I've got memory to spare (Especially on modern PCs - 8 gigabytes is middle-of-the-road nowadays!) and so I can use as much of it as I want, in order to increase optimization.
* Visual presence - Oddly enough, this is almost completely separate from the rest of the unit's "existence." When the player camera moves within range of a unit, a model is loaded and "synched" with that unit's data. It will follow the unit and act as a UI tool (if you click it, you select that unit), but is not otherwise linked with said unit.

The end result of all this complexity is this: A unit at rest, and out of range of the camera, is free. A moving unit, out of range of the camera, is worth two lines of code per frame, plus short AI scripts every 8-12 frames. A unit at rest, in camera range, is worth the polygons it takes to render it. A moving unit in camera range is worth that code and the polygons.
This does not take into account other forms of AI. Battle awareness and long-range pathfinding are both "heavier" scripts that I hope to offset by various methods.

Anyway, I believe that this is as well-optimized as I can make the unit system. I'm not quite so worried about buildings. And once the base code is in place, well... all that remains is to make a game out of it!


...Which reminds me, I'd do practically anything for the chance to separate the Ogre process into its own task, to run on its own CPU core. I wouldn't have to worry so much about optimization if this were the case. (Not to mention it'd be wicked fast!)


Finally, screenie time! This one shows off the forests ingame, as well as some nice reflections and a pretty sky in the background.

Game Design 2: A History Lesson

Which is a grand-sounding way of saying, "this is where this project has been!"

Development started way back in the year 2006. I built a terrain engine using Game Maker's native 3D functionality, then expanded that into a small RTS engine. To be honest, it wasn't very good, either in design or in graphical power. (the latter may be explained by the engine I was using)
It looked like this: (Please ignore the lack of modeling)

By March 2007, it was obvious to me that this engine was just not powerful enough for what I wanted to do. So I began investigating exteral graphics solutions, and eventually decided upon one called Xtreme3D. I worked on this version of the game for about a year, improving significantly on the visual effects present in the game (Although not so much on the models). I added actual lighting and 3-dimensional trees, and animated models. This was the last version to use roads as a game mechanic: in subsequent versions, one could place buildings anywhere. Aside from that, however, most of the game design was solidified by this version.

Version three was started in mid 2008. I switched graphics engines again, this time scrapping all of my graphical assets and starting over. My modeling ability had much improved by this point, and the results actually looked acceptable! Additionally, I was able to greatly expand the scale of the game, introducing some important optimizations in the process. This was the first version of the game to make use of shaders.

By 2009, it looked like this:


An additional feature developed at this time was the map generator. Using diamond-square noise patterns, layered and combined in various manners, it was able to generate some very interesting, natural-looking maps, as well as the climate and fertility data for them.


And so we come to August 2010, when Dawn of Civilization Mark IV was officially begun. Already it is graphically superior to any of its predecessors, not to mention much faster. During the course of development, I have learned how to produce high-quality low-polygon models, how to create and apply textures, and how to program in HLSL. Moving forward, I am eager to continue development on DoC, and see where it may go from here.

Game Design 1

It occurs to me that the very nature of this project, besides as a progression of vague technical feature discussions, is not obvious.

So here goes: The preliminary game design behind Dawn of Civilization

Dawn of Civilization is a historical RTS. It is designed to reinvent the RTS genre, and does so in a number of key areas:

0. Empires. Your typical RTS facilitates matches between up to eight human players, with one winner and up to seven losers. This is a nice competitive idea, but it makes games between more than two people rather silly and unnatural. You're all squashed together, and all duelling to the death. It's quite obviously a game.
Dawn of Civilization inverts this trope completely. For each competitive human player, there is a noncompetitive AI player who will intentionally stay several steps behind the player. Various improvements in every aspect from multiplayer victory conditions to diplomacy are all designed to a single end goal: that by the end of the game there should be two or three sides, each composed of multiple players working towards the same goal, in an epic struggle for final domination.

1. Map size. Contrary to the typical RTS map, which is one or two square miles, maps in DoC are approximately ten square miles in size. This makes games longer, larger, and more tactical: scouting is essential, and it is possible to maneuver your own forces so as to render an enemy's slower troops useless. Harrying, attacking of supply caravans, ambushes, and more are all made possible by this feature.

2. Landscape camera. A major problem generated by large maps is navigation. RTS games normally make use of a minimap to let the player move quickly and accurately around the world; however, as the developers of Supreme Commander doubtless quickly discovered, minimaps become unfeasible once the main map reaches a certain size. There just isn't enough resolution and visual accuracy available in a minimap to differentiate between locations smaller than cities, or to quickly locate and zoom to one of your scouts, on a map this large!
Supreme Commander's solution was to introduce a full-screen minimap, accessed with the spacebar. This made it possible to navigate successfully and restored the functionality of the minimap; the problem was, it became entirely too possible to play the whole game in this mode, without zooming in to watch the battles play out on the surface level. Something was lost in this approach that Dawn of Civilization cannot afford to lose.
Dawn of Civilization combines several different approaches in an attempt to not only restore the fundamental functionality of the minimap, but to surpass it. The main, and most obvious, of these is the game's camera. Like Empire Earth, it is freely rotatable and zoomable via the right mouse button; unlike Empire Earth, you can zoom down until the horizon, with all its landscape features and distant forests, is clearly visible. Thus, navigation becomes a question of knowing the map, and familiarity with specific landmarks - mountains, deserts, oceans, peninsulae - will follow during the course of the game.
Additionally, there is a minimap present in the game to assist in cross-map navigation; while it will not differentiate between densely packed locations, it allows you to move from one spot to another with effortless ease.
Finally, there is the icon-based in-world interface. Taking a cue from X3: Reunion, every far-off object of note - cities, villages, or armies - is marked with a tiny icon that follows it along the edges of the screen, and on the horizon if the camera is looking along the landscape. These icons allow for instant navigation to friendly cities, sites of important battles, etc., as well as providing visual reference for the player when events (such as ambushes!) take place. They occupy the interface region easiest to move to for the mouse cursor - the edges of the screen - and stay neatly out of the way when performing normal RTS actions.
These icons may be navigated to with a simple click, or used to task units to by right-clicking them. This, for instance, should allow you to assign future units to a specific army, to go there when they are completed.

4. The Resource Production Chain. Dawn of Civilization is a hybrid design. While its battle engine is an RTS, it includes many elements common to city building games like Caesar or Anno 1701. Primarily, every resource must be harvested or traded for, then modified by buildings in your city to reach its final, usable form. Just as important, every soldier in your army will come from a specific house, and every working building in your city needs workers. As the final piece in this puzzle, every worker requires food and other resources for upkeep.
The net result of this system is that players will be given more to do during the early portions of the game, building cities rather than building bases, and armies will be naturally constrained by the strength of the cities that field them. Sieges become possible. Trade (and the disruption thereof) becomes a necessity. The whole game is made more complex, more challenging, and more fun.

5. Morale. Morale is common to all houses and soldiers in the game. For houses, it represents the satisfaction of their workers, and is reflected in how hard they work. A happy worker will produce more than the standard amount of resources; an unhappy one, less. For soldiers, it is divided into global and local morale: global morale is dependent on the happiness of that soldier's family back home, as well as how long he's been away from home. Local morale depends on food supplies, that soldier's state of health, and the way the battle is going. Retreats and routs are possible. A wave of arrows, even if not particularly effective, can cause an enemy army to flee in terror. Tactical possibilities are bolstered tremendously, without any complication to the battle controls or user interface.

6. Supply. An army marches on its stomach, and its stomach must be satiated by its home town. Likewise, siege weapons such as catapults and ranged soldiers will require wood and stone in order to keep fighting. For these purposes, the Caravan unit is designed. Each Caravan unit carries with it several hundred resources - food, wood, and stone - and distributes those resources to nearby allied units when needed. It will additionally call automatically for more resources from nearby allied towns - resources which will travel, visibly, across the map and may be raided. Disrupting supply lines becomes a viable tactic. Attrition becomes a very real danger. The player is not overburdened with micromanagement - he merely has to keep enough caravans with his army to support its full strength; more for extended campaigns - and a number of satisfying, interesting approaches are added to battles.

7. Diplomacy. The standard options are, of course, available: alliances and tribute may be employed by anyone. But when you conquer another player, things get interesting. You have the option to raze their city, effectively removing them from the game and giving yourself a small amount of loot. But far more tantalizing is the option to establish them under your rule: They work with you, win with you, or lose with you, as the case may be. You can exact regular tribute from them in the form of a certain percentage of their incomes, or a certain percentage of their soldiers, and it is in their best interests to march to war alongside you. But beware being too harsh, or too nice - for they have the option to revolt and become independent once again, or even to ally with your enemies - with the understanding that, should they fail again, they will be destroyed.
Thus, diplomacy and player-to-player relations are a much more interesting and varied aspect of gameplay, extending interest in the final portions of the game as two or three great empires clash.

8. Factions/Technology. You don't start out by choosing a faction like "Romans" or "Zerg." You start out with exactly the same options as everyone else does. Instead, you must perform research during the game, and make choices when you expand your city ("Era up") that will determine the course your civilization takes, the special units you have available, and more. This prevents players from losing before the match begins - for instance, you choose the Minoans, a civilization with advantages in naval combat, but spawn in the middle of the desert. It also makes player choices during the game much more dynamic and fun, compared to the normal grind.

9. Multiplayer matches. In the typical multiplayer match, everyone starts out level; then players are eliminated until one player, or one team, stands victorious. But this pattern is plagued by a fatal flaw: Rage-quitting. A defeated player, or one who sees he is on the losing side, will generally quit rather than face defeat - leaving the victor with a hollow victory, or perhaps no victory at all. By keeping defeated players in the game, but tying them to their conquerors as subordinates, we can not only make the endgame interesting, but keep the interest of even the defeated players through the last battle.
But this would be no fun if there were seven winners and one loser, as might well happen if it was not designed carefully. Thus, there is a cutoff point for victory: Once you conquer two other players (including villages), you become an Emperor, and from then on have only the possibility of an outright victory or an outright loss. Similarly, if you are conquered the points you get from completing the match begin to decrease. And finally, if you are wiped from the game entirely you gain no points.

Points (in ranked matches) for achievements are as follows:
10 points: Emperor, victor. There will always be someone who scores ten points.
9 points: Allied with the victor, never conquered.
8 points: Conquered once, originally vassal of victor.
7,6,5 points: Conqured more than once, originally vassal of victor.
4 points: Emperor, loser.
2 points: Originally Vassal of loser, conquered once before the end.
1-0 points: Originally Vassal of loser, conquered more than once.
0 points: Razed.

And that is the basic game design for Dawn of Civilization. More in-depth description will follow, including unit and building concepts and the tech/era tree. Also, more technical ruminations will follow - probably a lot more. 'Till next time!

Next on treeblog

No luck with the compressed normal map. It just looked horrendously ugly. I'm using a standard normal map instead.
I have one other compression idea to try, but it's not orthodox and would take forever to implement.
Also, I think it's more expedient for efficiency's sake to work on eliminating general code problems instead of focusing on one specific type, for now. I feel that I must be able to eke 10 or 20 frames per second more out of the terrain code.

Progress continues apace on other fronts, however. The forest generator has been updated to use all my current models, and looks great. I had to correct some problems relating to mipmaps. Speed is ~90fps in heavily forested areas, top down; dropping to ~60 when looking side-on. This is to be expected.

I have also linked lighting to the day/night cycle. Most things now work with this cycle; the main exception being the grass, which looks out of place. My deciduous trees, unfortunately, have been nigh-impossible to get perfect. I am going to have to implement a vertex shader for them, to deny diffuse lighting to vertices that fall within a certain region of the texture map. That way, I can light the trunks but leave out the leaves.


And finally, I created a "smoke" effect. This consists of a dual-layered material, with the first layer providing color information (with a scrolling UV coordinate) and basic alpha data, and the second layer providing a constant fade over vertical space. The end result is reasonably visually pleasing, and for only twenty non-processed polygons!

Next up: Making a movement engine for all units simultaneously. Basically, this has to be as lightweight as possible; ideally no more than a couple of multiplications or additions per unit. The simpler it is, the more units I can fit on my "payroll," so to speak. I need to handle at least four hundred in real time.

I'd like to do this by a series of linked lists, representing all the units that need to move in a particular direction. Say you need to move north (y+). You add your ID to the linked list labeled "global.yplusmovers" or something like that, and keep track of your node (and your parent node) within that list. Every frame, a simple counter goes through and increments the y position of all units in that list by 1. And every eight (or however many it takes to move one cell's worth) frames, your unit can check to see where it's going next, and remove itself from any lists it's done with. (Using its kept reference to its own link!)

I can't really suss out whether this would be faster or slower than a simple if-block, though. It removes pretty much all the if statements every step, doing everything by pretty much the most simple method possible - but on the other hand, it might require two instructions per update per unit.
If I use a while loop to traverse the lists, I can easily get it down to a simple addition and variable assignment. That should be lightweight enough for anybody...


Units should do nothing unless acted on by an outside force, or unless already doing something. (Basically, Newton's first law!)
Handling user input is easy enough - it's entirely driven by the player, and is furthermore constrained in how many objects it can affect at one time.
Handling AI input is also pretty easy - set up how often the AI works (for a wild animal, say every two seconds) and let it interact with the unit's movement scripting when needed.
Handling unit-to-unit input is slightly harder. I shall need to set up some sort of fast area-effect tool so that, for instance, one antelope getting hit by a spear excites the whole herd. (And likewise, so that one unit getting attacked puts all nearby units on alert as well! This is essential to a maintenance of immersion.)
It's the "already doing something" that may prove most difficult in the end... there are an alarmingly large number of factors to take into account, from cross-map pathfinding (Always a potential speedbump, especially with A* pathfinding - although I may be able to outsource this to native C++ code), to updating the minimap (if, that is, I decide to use fog-of-war; I may be able to find a better concept!), to being aware of one's surroundings, to local pathfinding. Ideally, I'll be able to limit most of these to per-group actions (EG pathfind only once for every order the player gives, no matter how large the group), and limit the rest to occur only once every ten-plus frames, at which point I can stagger their occurance in order to handle ten times as many units at the same speed.
My hope is to get units working with an average of four operations per frame per unit. That would put large armies well within reach.

It may seem like I'm taking an awful lot of preemptive caution here. I'm not. My graphics are running on a relatively up-to-date 2005-08 era engine... but Game Maker itself is the equivalent of a turn-of-the-millenium Pentium III. It's fast to develop with, and puts big projects within the reach of the individual programmer, but it's not well-optimized. I'll be truly lucky if I can get as much happening at once as Age of Empires II managed. And that... at LEAST that... is what I intend to do.

Excitement!

I realized that I could further optimize my terrain shader, removing two texture lookups.
The realization stems from the following fact: I am currently using an image to store the texture atlas coordinates for each tile, and doing additional lookups to obtain the tile types to the left, top, and top-left of each tile for blending purposes. However, the data contained in the image easily fits in just the R channel of the texture, and by adding data representing the texture coordinates for neighboring tiles in the G, B, and A channels, I am able to do just one texture lookup from the coordinate image!

Next, I plan to implement some form of "compressed" normal mapping for the terrain, hopefully storing the normal information in the alpha channel of the texture atlas PNG image. This will (hopefully) give me a 1/3 detail normal map - enough for my purposes! - without any additional lookups.

I have been toying with the concept of adding heightmap-related functions to the water shader; yesterday, I put this into effect. The water shader now fades out completely (normals, color tint, and reflection, although this latter I expect will be changed) very close to the shore, creating a visually pleasing effect. Additionally, the water is more choppy the deeper it gets! This has all been implemented basically for free as far as performance is concerned. I am investigating ways of adding waves to the shore using this effect, but this is less than certain to happen.

Small update

I messed a little bit more with the texture atlas script: to be specific, I expanded the noise mask that modifies the edges, creating a significantly less "tiled" appearance. I think that aspect of the engine is just about perfect by now.

I also scaled up both the water and deep water effect planes, creating an ocean that stretches to the horizon, preserving the illusion of a seamless world.

And, first screenshot time!

It's been modified a bit - adding a bit of extra glow, correcting a terrain texture aberration... but it does show off some of what I was talking about, particularly the high contrast.

In non-development stuff, I'm working my way through Thief 3 mission-by-mission. It's fun, especially in its more "sandboxy" elements.

Optimization

I tried a couple things with regards to shaders since the last post:
1. I attempted to make the violence of waves decrease with depth, by passing the heightmap to the shader. Unfortunately, this both slowed it down and allowed the low resolution of the reflection to show through in shallow water. I therefore consider this a failure.
2. I created a new version of the texture atlas shader, this time allowing for smooth alpha transitions between tiles. It unfortunately contains a few more 2Dtex lookups than the less-detailed one (putting it on par in speed with the splatting shader), but the effect is so much nicer I can't fault it. All I need now are truly irregular tile shapes... not quite sure how to start on that aside from messing with the noise sampler that drives the small irregularities already present.

The final thing I added is a "compositor" - a full-screen shader to adjust colors and other fancy effects. It does a number of useful things:
1. Dark colors have a sepia-effect applied to them, turning them slightly brown. This does not compromise their value, though - just their saturation and hue.
2. Bright colors are brightened, but not overly much.
The above serve to add contrast to the scene, bringing out color elements that would otherwise be obscured.

And finally, I have support for a "bloom effect" of sorts. At present, it is spreading white pixels around to their neighbors, creating a visually-pleasing "sparkle" effect on water. I need to figure out a way to do cheap, limited "bloom," however, as that would be better for my purposes. Also, the current effect requires four texture lookups - a potentially ruinous amount.

All detail objects have been textured. Now I need to put the system together into a regional forest system, defining bands of temperature, elevation, and fertility where plant types can occur.

The plan for steps following this is as follows:
* Front end, EG main menu - because I like designing them, and this feels like a good time.
* Options program (external to the main program) to adjust settings. It's essential to include this early so I can consolidate these options and work them into later features.

Cacti

World progress:
Sea: I modifed the reflections so they're actually visible at low zoom levels, and added a sort of "specular" highlight from the Sun. I may have to tone it down a bit, though.
Sky: As before.
Land: I implemented a texture atlas shader in place of the splatting shader I had before. It uses a noise mask to generate irregular borders between terrain color patches. The overall effect is currently somewhat too "tiled" for my taste, but it should pretty easy to change.
This change has two big positive effects for me: First, it increases game speed by 10-40 fps, overall. (I was able to, on average, triple the number of trees - while keeping the same speed!) Second, it allows me to include up to 64 terrain textures, instead of 8.
Camera: I adjusted the rotation-to-zoom ratio. The end result is that the camera zooms in on the terrain a bit before rotating to landscape view.

Today I built many of the "detail" objects: Cacti, rocks, bushes, fallen logs. I got some practice generating textures for the cacti.
Current prop count:
* 6 cacti proper, 1 desert thorn bush
* 1 general-purpose bush model
* 1 "bunch of reeds" model, untextured
* 3 "Fallen log" models
* 4 large rock models, untextured.

Next: Finish texturing, and figure out a way to add contrast to the scene. Currently the visual "feel" of the game is a flat, bright "Age of Empires" appearance; I intend to darken the dark spots and brighten the bright spots and give the visuals some true contrast. I believe this will greatly help the visual feel. I may have to resort to a compositor, but I hope I can make do with less, as full-screen visual effects are (generally speaking) much slower than in my last engine. The current background image shows the effect I'm going for - deep, rich colors with vibrant shadows and bright glows.

For a speed comparison to my last engine:
Last engine, with reflections, grass, "deep ocean" effects, and trees: 15fps.
This engine, similar scene: 50-100fps.

Trees

World progress:
* Sea: Mostly complete. Fresnel texture is slightly repetitive; will seek to add a second layer to diminish repetition. There is a visual artifact at certain camera angles that I must remove, and I await the arrival of custom rear clipping planes so I can make the reflections more accurate.
* Sky: Complete. Sky detail can be adjusted, at minimum using a skybox. I don't like the coverage given by the 3d cloud layers, though. I'll have to look more into that functionality.
* Land: Present, but slow. The multipass shader is much responsible for this; I intend to investigate texture-atlas painting to replace my current texture-alpha-splatting approach.
* Camera: Almost complete. I am not happy with the zoom-to-angle ratios; I will try to correct that tonight.


Trees.
I have completed twenty-three trees for use in Dawn of Civilization, as follows:
5 pine trees of various types, including the Mediterranean cypress.
4 palm trees. These will be supplemented by different leaf variations.
9 deciduous trees. Including Oak, Aspen, and Birch as recognizably different variations, these should make for quite interesting forests.
4 "jungle" trees. I can't remember the scientific name for trees of this type; they form the canopy of, say, the Amazon Rain Forest, and are the tallest trees in my collection.
1 Acacia. There's just one because, honestly, there's not much variation in shape!

Beyond this, there will be at least 2 palm tree texture variations, 3 pine tree texture variations, and 5 deciduous/jungle texture variations.
Additionally, all trees are rotated and scaled randomly. The sum result should be quite enough foliage to cover all the worlds in a nice green layer.


Additional "unmoving" objects to place in the game world, including:
* 5-8 cacti and similar desert plants
* 3-5 bushes
* 5-8 large rocks
* 2+ fallen logs (to add visual variety to forests)
* 3+ termite mounds (to spruce up the deserts and savanna.
* 2-4 bunches of river reeds
* 2-4 groups of flowers.

I may have these smaller objects use their own, shorter-ranged paged-geometry system so as to inflict less FPS damage.



I think that forestation may well be the single greatest cause of FPS problems in the game... especially with the "mega-forests" my map-generator currently puts out. I don't really want to lose the mega-forests, though; I shall have to think of a compromise. Maybe cut the big forests into several smaller groups...