Ahdno
| Title | The Mystery of Ah D'no |
| Date | 2005 |
| Platforms | Windows |
| Created For | Senior Design final project |
| Source | source (19.3 MB) |
| Executable | Win32 (28.1 MB) |
After persistently nagging the professor of our Senior Design class, he relented and allowed us to create a game for our final project. While the rest of the class dove into financial software, schedulers, and planners, we got to work on a 3D RPG, of sorts. I volunteered to be the leader of the graphics module, and created the terrain renderer from scratch. From there, my job expanded quite a bit to being the lead programmer.
My main focus was originally the terrain engine. I came up with my own terrain paging system, which would adjust the level of detail of each page based on distance from the player. I created a fairly complicated method for patching cracks between pages of a different LOD, without subdividing further, since my method involved forcing all subdivisions on each patch to be uniform. It also culled out pages that were outside the viewing frustum, and forced models to conform to the LOD of the page in which they resided. Five different detail settings were implemented, with the highest detail causing considerable slowdowns on my machine, while the lowest ran at several hundred frames-per-second.
In order to create somewhat realistic terrain, I used a very simple multitexturing method of alpha blending two textures based on the gradient at each given point on the terrain. I had originally wanted to use a more complicated method of blending three or four textures based on various other parameters, but this proved to be exceedingly complicated, would not run on many graphics cards, and seemed like it would actually generate less realistic results than the simple two-texture model was able to produce. Also, at the last minute, we decided that paths would be fairly useful, so I just implemented a simple second pass to draw them, which worked well, since there were not many paths to draw.
I also created a few different lighting models, because each seemed to have major drawbacks. I tried to use vertex lighting, with each vertex sub-sampling from a high detail lighting array. This seemed to conflict with some of the other methods I was using, such as the multitexturing and the separate pass for drawing paths. More importantly, it looked terrible on pages with a lower level-of-detail; the vertices were farther apart, but the lighting was simply choosing the nearest light value at each point. Eventually, I ended up using textured lightmaps, with each page having its own grayscale lightmap, pre-calculated when the terrain was loaded. This reduced the jarring changes that would occur when the LOD changed at the expense of requiring extra work for the graphics card.
It is also important to note that we took upon ourselves only the programming aspects of this game's creation, and that the models, textures, and other such content was not created by us. Most of the textures are from Half-Life 2, and most of the models are freely available user-made models for Quake 2. Considering how short we fell with the deadline, to have created our own content would have led to a significantly less complete game.
My second major focus was the rendering of our underground dungeons. Another group member created a dungeon map generator, and I was in charge of graphically displaying its output. I parameterized things such as wall height and width, which textures to use, roughness of the floor, and others so that each time a dungeon was generated it would be somewhat different. I also implemented several lighting models, wherein stationary torches would cast flickering light around their rooms, and the player cast a dynamic light wherever he went.
In addition to graphics work, I also worked on the user interface. I made it almost entirely mouse-driven, with the left button used to select where a player would walk to, and the right button for repositioning the camera. Aside from the occasional other keys, such as switching weapons or quitting the game, the player could use just the mouse to get around. I imported code to read in and display .md2 models, which we used for most of the game's objects and characters, and I wrote my own basic particle engine to display various magic, blood, or fire effects.
The terrain itself is read from a gigantic heightmap file. This file could be generated however a user wishes, as it is simply an array of heights, but for this game I used Vistapro, so as to create somewhat pleasing approximations of land. On loading a heightmap, the game applied additional calculations so as to smooth out sharp edges, generate paths, place houses and terrain decorations, and generate mountainous borders at the boundaries of the map -- this accounts for the significant loading times. Having an external tool to pre-process a heightmap so as to only need to do these calculations once would have been extraordinarily useful, but that is just one of the many things we did not have time for.
Overall, though, this ended up being more of a technology demo for the terrain and dungeon engine than it was a game, as we just did not have the time to fully implement everything we had planned. We also had an extensive storyline, various characters, and a slew of items and creatures, none of which was integrated properly, and the game's depth suffers greatly for their absence. There is still a lot going on, in terms of graphics and AI, but just these things do not make for a fun game by themselves. I think this seems to be a common trap many games have fallen into, and it's one I will be trying to avoid from now on.
