T w e n t y S i d e d

I think I’ve accomplished everything I set out to do when I started this project. I have an attractive terrain engine that runs well even on a two-year-old computer, and which leaves plenty of memory and CPU power for whatever game I might want to add.

From here, I may modify the engine and try to put it to use, but if I do it will be a seperate series.

There were several items I had left for this final post, but most of them were not part of the engine itself and would make for even duller reading, if such a thing is possible.

Stuff I learned:

1. An overhead engine is far, far easier to make than a first-person engine. This was easier than I’d anticipated. I imagine the real challenges of such an engine appear when you start putting foliage on it.
2. A lot of camera movement limits I’ve encountered in games probably exist due to engine limitations, and not because the designers wanted to annoy the users. I’m thinking back to the original Black & White (the link goes to B&W 2, the original website just redirects to the sequel. Jerks) and the way the overhead camera was always tethered to the ground in such an annoying way. At the time I thought it was just a poor interface, but now I see it was probably a way to keep poly count under control. I found limiting the camera movement speed covered a multitude of shortcomings.
3. Making a lot of textures on the fly is much faster than I expected. I cranked the number of distinct terrain textures to 1,024 and I was still able to turn them out fast enough to keep up.
4. In the future, I need to set more specific goals for projects like this. Without any guiding design, I felt a lot of my choices were arbitrary when confronted with various tradeoffs. For example, I never decided ahead of time how fast the user should be able to move around the landscape, how high or low their viewing angle was allowed to be, how far they should be allowed to see, or even what scale I was dealing with. Many games put limits on stuff like this, and deciding those limits ahead of time (or at least having an idea of how I wanted the interface to work) would have given me more to go on.
5. Agonizing over polygon counts with modern graphics hardware is often time poorly spent. It’s better to give the CPU a break, even if it means being sloppy and letting the GPU (your graphics card) pick up the slack.
6. The method I came up with in Part 6 for casting shadows is really fast, and a nice trick. I’ll have to remember that one.
7. Making an engine that can churn out good-looking rolling hills that are visible to the horizon is still a major challenge. It’s easy to come up with a couple of “square miles” of terrain, but reaching the horizon is very hard. Most games have fake mountains in the distance. Far Cry fixed this by setting the game on small islands, making the horizon all water. Flight simulators make the ground very simple up close. I think we’re still a little ways off from true expansive terrain that can be explored on foot.
8. Recording a project like this was useful. It was time-consuming, and probably wouldn’t make sense if I was actually making a game, but for an educational project like this it gave me a good look at what worked and what didn’t. Even better, it gave me a chance to learn from others who took the time to leave some very interesting comments.

UPDATE 2/25/2006: In response to inexplicable public demand, I have since released the source code. So, if you have some skill in C++ you can experiment with the code yourself.

Thanks for reading.

Shamus Young is a programmer, an author, and nearly a composer. He works on this site full time. If you'd like to support him, you can do so via Patreon or PayPal.