Mayan Forest Simulation Diary

The following is a direct transcript, typos and all, of the diary I kept while working on my Mayan Forest Simulation. I hope you enjoy it. It is a true revealing of my inner thoughts and feelings during this project and I lay it bare for your amusement and boredom. Enjoy.

Diary of my thoughts on the design of a 3D Mayan ruin site exploration computer game

040609

I am starting this diary a few days after coming up with the original idea, so the first entry incorporates several days worth of thought on the topic and several revisions of the original idea.

Inspired by my May, 2004 trip to Mexico, I returned home with a renewed fascination with ancient Mayan archeology, mainly architecture and written language, but secondarily my sheer love of the feeling I get when I am at a ruin site surrounded by rainforest.

I immediately began dreaming up the concept for a computer game. The primary purpose I had for the game was originally to capture that magical feeling I get when I am in the rainforest exploring Mayan ruins. I quickly hit upon the additional idea of having the game incorporate authentic Mayan heiroglyphics as well. In particular I thought I could use the rather simple to understand numbering system. Other elements of Mayan writing are much harder to understand without some study and may not work well in a game, but perhaps I can find a way to do this.

In contemplating the general appearance of the game I originally considered something similar to Myst, a series of still images, 3D rendered, that are hyperlinked together. The user would explore a ruin site set in a rainforest by clicking their way through a series of these images, basically exactly like Myst.

However, given that I have had some experience with 3D programming, such as Vertigo (a game I wrote in 2001) and a robot simulator I wrote for my earlier PhD work, I wondered if I could make a true 3D game that is explored by the user in a fashion much smoother and more visceral than the Myst style. In particular, I felt inspired by games such as Nanosaur (for which I had the sample code to study) and Tombraider, both of which convey a nice forest-like feeling despite limitations of 3D programs at the time, such as flat square-shaped objects with minimal surface texture. Could I create something like that, but with a setting more accurately representative of a Central American Mayan ruin site? I got Michael Coe's The Breaking of the Mayan Code out of the library and finished reading it in a matter of days (about 2 thirds done at the time of this writing) in order to familiarize myself with the history and basics of the Mayan written language. I believe it will be difficult to put more than a rudimentary degree of hieroglyphics into the game as no user other than a professional Mayan archeologist will be able to make sense of them. I can use them for decoration, but probably not as decipherment puzzles.

I have spent a few days scouring the web for information on good game design. Vertigo was a flop, I don't think anyone enjoyed it very much. I would really like to make an engaging fun game, but it is hard. I'm not sure what the point of the game will be yet, since the original reason-for-being was simply to recreate the feeling of being at a Mayan ruin site. I believe the player's character will be an archeologist, but will be the point of the game? One obvious and rather cliche goal would simply be to collect the most treasure possible. To make the game ethical, I could argue that the collection is for a museum. I contemplated inserting the challenge of racing nonplayer character thieves who are after the loot as well, but I don't really want the game to be fast-paced or to "hurry the player along". I want it to feel like Myst, riveting exploration, but in a sort of relaxed fashion. The motivation to explore should come from the player's dire curiousity about the world they are in, not the ticking of a clock beating them along like a paddle on the backside.

Should the player see themselves from behind, like Tombraider, Nanosaur, and Oni, or should it be purely first person like Doom, Myst, and Halo? The latter is easier to program because it doesn't require a 3D animated body for the person. I would like to avoid animated models as much as possible (I have considered swaying trees and a jaguar so far as other shape-changing models, but birds and doors don't really require changing a model's shape). I don't know if removing too much model animation makes the game "flat" and static. There are other forms of animation, such as moving and rotating objects and shifting textures across the surface of objects (a good effect for flowing water). Myst had very little animation, but in a true 3D world, that may not be as tolerable.

040610

Not sure I finished my wrap up of the initial days' worth of thought in yesterday's entry, so today's might have some of that, along with today's developments.

Here's a quick list of thoughts I've had, ideas for the story/gameplay or the technical aspects of the game.

Prehistory of the game would have a group of archeologists find and partly excavate the site and then abandon it quickly for some reason. The reason for this is that it allows me to display the ruin site in both forms, half covered by forest and half excavated.

Likewise, by having them abandon quickly I can have them leave stuff behind for the user to find, such as batteries for a flashlight and a notebook to get the user going on various tasks.

Part of the mystery of the game could be to determine why the previous team left in a hurry. Of course they would have simply given the reason they left when they got back to civilization...unless they were lost and never returned, but that's kind of cliche.

Terrain can be represented in large tiles, large enough to reach most of the way to the clipping horizon. Only 4 tiles need to be "live" at any moment, corresponding to the 4-tile intersection the player is nearest to. In this way, tiles aren't swapped in and out when the player crosses a tile boundry, but rather when the player crosses the midsection of a tile on either axis.

It would be cool to have authentique background noises in the forest, rainforest birds mainly.

Are flocks of red macaws only indigenous to South America or do they occur in Central America too? Would be nice "confetti".

How do I make the user want to play or to care about the world or its story? Do they just want to collect all the artifacts and treasure they can? Is there a mystery, such as the disappearance or sudden evacuation by the previous archeologists? How do I make the player give a damn about any of that? Can I have a historical mystery, such as discovering the fate of some Mayan king...or princess perhaps, or is that stupid? To what degree do I want to adhere to concrete authenticity? Do I want to never present hieroglyphics or ancient stories that don't come off as true plausible Mayan history? Do I want absolutely no mystic aspect at all? Or can the player find some magic portal to other Mayan sites or ancient Mayan cities? Perhaps the player can see the city as it once was, in all its splendor, by traveling back in time and then interacting with the ancient city in some fashion. Or do I want a pure archeology simulation game, no frills, no magic, which might be pretty boring unfortunately.

Another thought on this fine morning. I perused Best Buy and some Computer Game store today. There are quite a few Adventure games that seem pretty good, at least in their visual presentation. What am I doing?! No one is going to want to play a stupid home-grown game when there are commerical titles to play instead. Ah me.

Would be neat to have afternoon rainstorms, which raises the question of time in the game. If it is truly realtime, then it will be tedious to march across a large ruin site, which in a real situation could take up to half an hour.

Should definitely have Easter eggs, or other kinds of secrets? Cheat Codes?

040614

Been doing quite a bit of work on the game, both on the computer and in my head. I have created and initial model of a buttressed canopy tree, a pyramid, and some cloud-sky texturing. Have Carbonized Queeg from Quesa v1.6d18 and done some basic speed testing. The tree is quite slow on my Powerbook pismo. Any reasonable number, such as would be required for a forest effect, would kill my computer. It runs okay on Angie's ibook however, and I haven't done any testing on my G5 yet. I also succeeded in animating a water texture so that it flows over the surface of a model, like running water. Unfortunately, my present code has the bizarre effect of animating other textures on other models as well, but not all other textures on all other models. I have no idea what could possibly be causing such strange behavior yet.

I tried to make good cloud textures in Photoshop and in Bryce. I figured out how to use an alpha channel to give the clouds a sense of transparency but have not come up with a really convincing texture yet. I might try taking photos of real clouds for this purpose. Not sure yet.

Subscribed to the Quesa mailing list once again, having removed myself sometime last year.

I'm not sure if I like the idea of having a prior team of archeologists at the ruin site who then either disappear or leave early. Although it would add an interesting mystery, it is quite cliche and rubs me wrong. I need a different idea for drumming up mystery and motivation for the game.

Giving the game a sense of forward progress requires some sort of "path", or what game designers call "plot". I don't want the world to be a linear path geographically. I want it to be freely explorable. But that means the gameplay itself must follow a path toward some sort of grandiose conclusion. Pure treasure hunting doesn't do that because the only notion of progress is the percentage of stuff that has been found so far, which isn't very motivating. I think that perhaps combinations of relics will combine to form larger artifacts which then do something, such as act as keys to doorways or something like that.

040615

Making steady progress on the technical aspects of the game. Subscribed yesterday to the Quesa development mailing list (having removed myself from the list a year ago because I had no need for it at the time). I quickly discovered that the texture animation issue is known by other members of the group and that no definite solution is known yet. So I will put that aside for the time being.

I have made 2 nice philodendron models and textures. With proper object merging I will be able to build unique plants from sets of leaves instead of having cloned plants that look identical spread throughout the world.

I played some Tombraider III yesterday to refamiliarize myself with it. The world is very blocky with larger flat square faces everywhere. It's a fairly old game of course. I do like the water though. Very clear with hazy cloudy shapes that hint at the surface, but show underneath as well, with concentric ripple patterns.

I found a nice tutorial on using alpha channels in Meshwork. This should clear up issues concerning clouds, dust, fog, fire, and water.

I have made some progress toward grouping objects into a single TriMesh. This should render faster. I also read through the entire online PDF book Making Cool QuickDraw 3D Applications by Brian Greenstone (creator of Nanosaur). Good hints on optimizing trimeshes. It says to use only 1 texture per trimesh, so objects with multiple textures should either be wrapped in a larger texture that place the components of the texture on the right parts of the model, or such objects should be conglomerated from multiple separate objects (such as tree trunks and tree leaves). It also says to submit objects to the renderer in descending order of size. It also says to use 16 bit textures instead of 32 bit.

I am still mainly concerned about the gameability, to coin a phrase. Not sure what to do here.

Updated later this evening: I got object merging to work perfectly with textures properly mapped and all. In initial experiments I got a 4x speedup as a result.

040616

Still mulling about for a good theme or plot to the game, some point to playing it. I wanted to give the player both hints to puzzles and motivation in the form of a mystery by leaving previous archeologists' notebooks to be found. I have had another idea along these lines. If a previous archeologist were attacked by a jaguar, the notebooks might be torn up and spread over a large area, leaving bits and pieces to find all over the place.

I started working on a second pyramid model this morning. It started out based on Temple V at Tikal in terms of the number of tiers and basic staircase appearance, but for the top I used Temple I from Tikal, so it's kind of a mix of both with liberal differences thrown in to boot. I like it so far.

I started researching the layout of Mayan sites. Since there are different periods in Mayan history which reflect different forms of architecture and art and perhaps different attitudes toward city planning, I am focusing on Tikal and the late Classic Period during which I believe the grandest pyramids were built. I have also begun sketching out tentative ruin site layouts.

I want to incorporate many aspects of different ruin sites I have seen in person, while at the same time I want a notion of consistency so that the site doesn't look like a mix of Classic and Post-Classic time-periods or a mix of Mayan, Puuc, and Toltec style architecture.

I checked Peter Harrison's The Lords of Tikal out of the library today.

040617

I've been thinking about the terrain. The terrain is a huge object spanning the entire world and when represented as a trimesh of elevation it can have an enormous number of vertices and triangles. I have been shooting for elevation resolution of 1 datapoint per meter in the world. If the world is only 1 kilometer square, pretty small, that's a million elevation points, or vertices. The number of triangles is roughly twice as large. Clearly the solution is the break the world up into segments or tiles and only work with active tiles at any given time. The required size of a tile is easy to calculate. Where ever the user is in the world, the active tiles must reach the visual horizon. There will always be 4 active tiles, corresponding to the corner the user is nearest to, so active tiles are switched in and out when the user crosses the halfway point of a tile, not the boundry between tiles. If the user stands at the halfway point and looks toward his nearest corner, then the horizon distance is 1 1/2 tiles, half a tile that the user is standing in looking into and another whole tile that the user is looking into beyond the edge of user's standing tile. However, if the user looks away from his nearest corner from a tile midline the horizon distance is only half a tile since only the present tile stretches to the horizon and then there are no more active tiles, so the final answer is that a tile must be twice the horizon distance, so that half the tile can reach the horizon.

What is the horizon distance? It depends of course. In thick understory rainforest it's a couple of meters, maybe a little more to see tall tree trunks in the distance, in a clearing it is as far as the edge of the clearing, conceivably hundreds of meters, and from on top of a pyramid it is literally infinite (well, the curvature of the Earth at any rate). Utilizing fog to truncate the horizons I can set a maximum horizon of any distance I want. However, realistically, this should still be several kilometers from on top of a pyramid. I'm not sure how to handle this yet. I have imagined large simple shapes that represent huge distant areas, not clear on this point at all yet.

On the ground I can impose a much shorter horizon, especially with realistic fog which is a natural occurance in rainforests. Let's assume I set the fog horizon at 100 meters, just as a starting experimental number. A tile must be twice that size so a tile must be 200 meters square. With a resolution of 1 meter that's 40,000 points per tile, and there must be 4 active tiles at all times for an outrageous total of 160,000 points. That's a lot of vertices and that doesn't include any models such as trees and buildings. I'm not sure how well that is going to work. I will have to experiment and see how that is handled.

Okay, I ran a little experiment. I created a "terrain" in Meshwork, a flat plane of points, 9 across and down for a total of 81 points. I mapped the terrain to a 64x64 texture. I opened this terrain into Queeg 100 times for a total of 8100 points, plus the racer model and background sky/ground pattern. On my 1.6 GHz G5, that scene rendered at about 120 fps. Although that sounds fast, the experimental number of points is still noticably lower than my calculation above. I am worried that once the scene becomes more complicated with numerous objects the rendering speed will come down dramatically. I would like for the game to run smoothly on computers weaker than my G5.

I reran the same test but instead of cloning the object 100 times, which creates 100 separate objects, I extended the original object as a merge of itself 100 times. This yielded a framerate of 180 fps, a 1.5x speedup. Regardless, 8100 is quite shy of the 40,000 mentioned above and I don't think it will handle a more complex world. I will have to come up with a different solution.

Let's crunch the math for a moment on half the resolution, 1 point every 2 meters. Should could to 1/4th the previous total, but just to be sure: 200 meter tiles now have 100 points per dimension for a total of 10,000, with 4 active tiles that's 40,000, so that's 1/4th, and that's still unacceptable. I don't want the terrain to require more than 10,000 points, so I have plenty left over for beautiful complex trees and buildings.

It is almost impossible to make sense of the Nanosaur terrain code by the way. Ugh.

Another possibility is to remove vertices in flat areas, making single large triangles. Clearly, that should be done anyway, but what if the terrain isn't really flat? To force it to be flat for the purpose of removing points would take away from the naturalness of the terrain, and no natural terrain is perfectly flat. Even a grassy plaza such as the 1 at Tikal (which I will probably put in the game) isn't totally flat, and even if I use a huge flat area for a plaza I will still need rough terrain everywhere else, mainly in the forest...or do I not need too much resolution? Is 1 point for every 10 meters acceptable? I just don't know.

I have read the docs that came with the public Nanosaur code. They are extremely terse but if I understand them right, and if I interpret the code right, there is an absolute dearth of elevation data at any given moment. Each tile is 32 pixels square (and has an associated 32 pixel square elevation map) and a supertile is 25 tiles and 36 supertiles are active at any given moment, so that would be a very large number of points. However, it appears as if each supertile has only 1 elevation point in the elevation trimesh, for a whopping grand total of merely 36 elevation points at any given moment. I must be interpretting it wrong, that just seems impossible to me. I will have to carefully study the running code in the debugger but I can't do that on the G5, only on the powerbook at home because the OS 9 and Classic programs can't be debugged under OS X, so I will have to wait until I am at home this evening to debug the program in OS 9 so I can figure out what the heck is going on here.

Side thought on the topic of authentique background rainforest noises: howler monkeys! Duh. And maybe tree frogs too.

Looking at the Nanosaur terrain code again, I think each tile in a supertile gets 1 elevation point, so that's 25 points per supertile with 36 supertiles so 900 active elevation points at any given moment. That seems much more reasonable. An interesting question then is how large is a tile. I will probably have to observe this using the debugger and running the actual program and observing the size of things in the world before I can know for sure. If the user can only see 3 supertiles ahead (half of the 6 by 6 dimensions mentioned above), then the horizon distance is 3 times the dimension of a supertile which is 5, so fifteen. If the horizon is 15 at a meter per tile (seems like about a meter when I run the game), the horizon is 15 meters. I guess that's actually what I remember observing when running the game, I'll have to check, but that's way too shallow for my hopes and dreams for my game.

040618

Since it is impossible to decipher the complex terrain code in Nanosaur I hacked it last night to present me with a bird's eye viewpoint so I could visualize how supertiles are loaded and unloaded as the user moves through the world. I now have a much better understand of how this works. I'm not sure if I prefer to use Nanosaur's approach or my own 4-tile-at-a-corner approach yet. I also figured out how Nanosaur handles the complexity and diversity of texture patterns on the ground. As a supertile is loaded, the 25 tiles and their respective textures are patched together into a single large texture which is applied to the entire supertile trimesh as a single unit. This is a very clever idea. I wasn't sure how I would render the ground since each piece of ground would need its own texture and trimesh's work best when there is a single texture per mesh.

One thing that I find tedious about Nanosaur is its use of smaller tiles. Why are supertiles composed of 25 small tiles instead of being the base tiles themselves? The answer is that small tiles allow one to construct a fine-grained world which is then patched into large supertiles only at runtime, but by the same argument the map could be constructed of larger tiles in the first place. The textures would have to be uniquely tailored to each supertile, which would take up more diskspace, but the large patch texture would not have to be built on the fly at runtime, thus saving computational resources. Not sure which approach I will prefer yet.

I dug into the texture part of the trimesh a little bit. I figured out how to get access to the texture and it's underlying image so I can modify textures at the pixel level. I might need to use this if I need to generate textures at runtime the way Nanosaur patches textures together to make supertiles. I also wanted to figure out how to make multiple trimesh objects use the same texture for the purpose of saving VRAM. I'm not totally clear on this yet, but I have a fairly good idea of what's going on here.

Now, if only the game had a clear plot/mystery/overview, I could start designing the darn thing.

I'm about half way through Lords of Tikal.

040621

I finished Lords of Tikal over the weekend and made moderate progress on a number of other fronts. I also purchased the 10th anniversary edition of Myst, Riven, and Exile. Played some Myst to reacquaint myself with the game. A large proportion of the puzzles are simply beautified combination locks, for which the combination is discovered elsewhere in the game. This happens so many times in Myst that it becomes kind of hum-drum after a while. I will have to be careful not to put too many combination locks in my game, if any.

I also found some material discussing and presenting Uru. It is realtime 3D, with a third person (Tombraider/Oni) presentation although you can apparantly switch to first person. I am quite daunted by the realtime 3D photorealistic appearance of Uru. I don't know how they do it. I am not convinced that any but the fastest computers could pull that off. I will have to see as this project progresses.

Along similar lines I was able to run the RealMyst demo on Angie's 800 MHz G3 powerbook. Again, I am unsure how this was accomplished.

I have experimented with creating terrain, terrain tiles, and a background "wall" image. The wall image is a background hemisphere that surrounds the user (or the entire world). I got the idea from Queeg. I'm not sure if I will end up using this idea in the game. I have created a surface of bumpy terrain that consists of individual tiles. The basic illusion of ground stretching off to the background wall works quite well. I am trying to decide what the tradeoff will be between fog, yon, and the background wall. Fog will present a nice misty appearance and will help truncate the world, but also cuts out the background wall. Perhaps this is okay. I'm not sure yet. The yon will have to be large enough to encompass the visual range of course, which in turn governs how large the tiles must be in order for only 4 present working tiles at a time to reach the limits of vision. This is all tricky stuff and I'm not sure how it will pan out yet.

I also did a little bit of work on creating the proper camera and body motions. The primary controls in this regard will probably be forward/backward movement, left/right rotation (yaw), and up/down rotation (pitch). The trick is that yaw governs the body in that it affects the direction of forward motion, but pitch does not. In other words, pitching the head up to look at the sky should not make the body move up into the sky when it is moved forward. I have figured out how to perform yaw when the camera is pitched up (which is tricky since the body's Y axis doesn't match the world's Y axis after pitching), and I have figured out how to move across the ground without flying up into the sky by ignoring the Y component of the body's forward-facing vector, but I haven't yet figured out how to make the camera snap back to vertical center (0 pitch) when forward/backward commands are issued.

After reading Lords of Tikal I have a better idea how to plan the layout of the ruin site. Tikal has very clean right-triangle relationships between most of the important buildings, stelae, and pyramids. I will certainly take this into account in the design of the ruin site.

With Angie's help I have fleshed out a rather interesting plot or quest for the player. I was inspired by an account in Lords of Tikal that claims that Temples I and II, the primary pyramids facing each other across the Great Plaza, are in fact associated with a king and queen and that the temples intentionally face each other for all eternity. It's a very romantic notion and filled with legends of powerful love. This will be great for the game. I think I will have a tomb of a king somewhere on the site, under a major pyramid of course. The user will find hints guiding him to that tomb. It will then somehow be discovered that another pyramid at the site, facing the first one belongs to his beloved queen. But her temple will have partially collapsed so that their "souls" can no longer view each other from the respective tops of their pyramids. The user will be sent on a quest to bring the queen's remains to the king's tombs so that they may be reunited. Upon eventually finding the queen's tomb under the second pyramid it will be discovered that her remains are missing! Good plot twist. They have been removed. I will alleviate concerns that it may have been looters (because that means the remains could be gone), and instead redirect toward the theory that a vengeful foe of the king and queen in ancient times intentionally raided the queen's tomb and moved her remains to another location at the ruin site, so that she may not face her beloved king. The user will be sent on a further quest to seek out the queens' remains and finally transport them to the king's tomb.

I don't know. It's an idea Angie and put together in a matter of minutes. Nothing is solid yet. I like it because it has just enough mysticism to dodge the perpetual boredom of true-to-Earth archeology while not having such raucous magic and spiritualism as to come off as a hackneyed Indiana Jones scenario. The catch as yet is that this is a fairly linear plot and that was one of my strongest objections in my initial design ideas. Do I force linearity by preventing the user from finding things out of order (such as finding the queen's empty tomb before finding the king's tomb and the associated story between them and relevance of the positions of their pyramids?) or do I allow the user to discover things in any order such that the user might have already found the queen's tomb but not known what to do after then until eventually finding the king's tomb? How do I add parallel plots, side quests? Are there multiple endings? It would be nice if there was no primary ending, but a plot like this of course has only the primary ending. Nothing else is of consequence if the main goal is not satisfied. I'm not sure how to fully enrich this idea yet, but it's a good start. The "gameness" is really starting to flesh out.

Here's my take on why Myst comes off as successfully nonlinear. It actually is linear in some respects. It has only 1 start node since the game can only start 1 way and basically has only 1 or 2 end nodes depending on whether you complete the red or blue book first. However, the basic gameplay consists of gathering red and blue pages and returning them to the central node. In this way the game is not linear like links in a chain because you don't follow the sequence of: find something, use it to open a new path in the game, follow the path and find something else, such that each step progresses to the next step. That makes a game linear and makes the player feel like they are cogs on a deterministic conveyer belt. Myst isn't like that for the most part. In Myst, each thing that you find is returned to the central node instead of the next node in the sequence. This makes the game shape more like a wheel with the central node at the center and the paths as spokes. You explore out a spoke, find something, and return to the center. This provides multiple possible sequences for the entire game since you can complete the various spokes in any order you want since none of them necessarily precede the others.

There are drawbacks however. By continually returning the same point the game loses some of the feeling of major progression that a linear path would offer. It feels a little repeatative after a while. Even though each spoke is a new place to explore, the basic challenge never changes: find the red and blue pages, pick them up, and return to the central node, then repeat. However, linear chain links feel repeative in the same way: find something, unlock the next path, follow it, find something again, and repeat.

Perhaps some redundancy is acceptable because it lends the game a certain characteristic that defines the game. Myst is defined by seeking out multiple red and blue pages for example. Perhaps my game can have a repeatitive quality for the sake of defining what the game is all about in the first place, but that is obviously a tricky and very touchy balance, to make it repeatitive enough that the game has a sense of cohesiveness yet not so repeatitive that the game loses interest.

Also note that Myst basically has only 1 or 2 endings despite parallel paths from the start to finish. I'm not sure how to handle that yet either.

Later this evening I succeeded in zeroing the vertical rotation when the camera starts moving forward or backward. I did this by zeroing the x and z components of the camera's orientation quaternion. I found a sudden zeroing to be visually jolting so I also made it pan to the horizontal position over a period of about a quarter second. This will work nicely for the game.

040622

I'll start this entry by following up on the business of auto-centering the camera when the player enters "walk" commands. I believe another way to accomplish this is by assigning points of interest to the camera horizontally level in front of the camera. This should work, although the trick mentioned yesterday evening works as well.

I've come up with some interesting ideas for the story and underlying mystery, and for the puzzles.

I think the queen will have been murdered. She was abducted and thrown into the ruin site's cenote. Her body was then retrieved the next day and her pyramid was built over her tomb after that. Hints will lead the user to seek out the cenote. It will have a small temple or platform where sacrificed victims used to be thrown into the cenote. The user will find a clue here, something the queen dropped as she wrestled with her abductor. Presently I envision a necklace of flat pieces of jade with Mayan numbers on them. The numbers will be a combination to some sort of vault located in the main palace of the site.

Another idea I had for a puzzle was to have the user find the broken shards of a ceramic dish and piece them together like a puzzle to reveal an image that would provide another hint. I'm not sure how all of this will work together of course. A dish is better than a vase because the user can view the entire top at once without the need for rotating it.

Myst has some puzzles that are not combinations. The rocket ship age (the age depending on sound primarily) has a combination at the end but the puzzle for discovering the combination (aligning parabolic antennae with one another) is very clever. It would be nice to incorporate interesting puzzles like that, and yet such puzzles should fit into the Mayan framework.

One idea I had, inspired by the fact that the Tikal pyramids form lines of sight with one another for viewing astronomical events rising and setting over the horizon, is to have a set of vertical markers in one place (on top of a pyramid perhaps) which are sited from another pyramid. The user would watch the sunrise or sunset to learn which marker is "the secret marker", where the user could then do something interesting, find a secret passage or something like that. There are 2 problems with this. 1, the whole point of true astronomical observations is that equinoxes and solstices happen on only 1 day of the year, not every day of the year, so the alignment wouldn't be generic. I could quietly dodge this issue I suppose. However, the other problem is that this sort of puzzle requires the user to be at the observation point at exactly sunrise or sunset. This raises numerous questions. Is the game realtime? If so the user would have to wait 24 hours for the sun to rise or set and be in the right place at the right time. Even if time is faster than realtime the user still can't solve the puzzle "at any time" just by being there. The user has to be there at the right time, which is irritating because it requires pointless waiting around...unless the game has commands akin to "wait for an hour" which would zip through time quickly. Ugh.

Alternatively, instead of watching the sun rise and set over a marker, the user could observe the linear alignment of 2 markers from a crucial vantage point (on top of a pyramid) and use that to find the secret location, but this doesn't really have anything to do with the fascinating truth of Mayan astronomy and sunrise alignments with relation to Mayan architecture. Hmmm.

Another idea for a puzzle, watching a shadow move across the ground to some crucial point, another secret location. Just an idea.

More thoughts on time, barely touched on in some earlier entries as well. Is the game real time? Does 1 hour of player time equal 1 hour of game time? This means nice environmental effects like sunrise, sunset, nighttime, rainstorms, etc. don't happen very often and are missed by the player in the experience of the game. This can also make some things tedious, such as hiking across long stretches of the ruin site. Perhaps the user can speed up and slow down time? This is weird though. If game time is sped up by a factor of 8, then the player must also move through the world 8 times as fast and must witness birds flying and clouds moving 8 times as fast. This is probably a very strange experience. This would alleviate long hikes, but it puts a very strange element of control in the hands of the user, to literally alter the speed of time in the game. Now, when the user needs to simply wait a long time for something to happen (such as sunrise over a pyramid alignment), it is easy enough to have a "wait" command that skips ahead in time (say the player's character took a nap, it doesn't matter what the excuse is), but if the user needs to do something, such as shorten a long hike, in other words if the character has to be awake during the altered time, then this is very strange because the player's mental experience is not affected by the change in time of course.

I could have something like zip mode in Myst where the player has to get to interesting locations the hard way once, but then can instantly jump between locations thereafter (and instantly update the internal game clock by the associated jumped time of course). This could have the strange effect of beginning a jump under certain environmental conditions and arriving with a sudden change in those conditions, such as night and day, or a rainstorm. Nevertheless, if used, this could be implemented by bringing up a map of the ruin site and having the user click to jump between previously visited locations.

However, the user still has to traverse a few kilometers of rainforest the first time in order to get to distant remote temples and cenotes and such. There are limited solutions to this problem. Either the user's character can run through the world unnaturally fast without affecting time (a common feature of many games as a matter of fact), or the user can speed up time and consequently "run faster" and "shorten a trip", or a user can perform a Myst-like jump even without plodding to a location the first time (which won't really work if the point of the game is to discover the parts of the ruin site)...or finally I can simply not have the ruin site be very spread out, but that isn't realistic. If every part of the ruin site is required to be within a 1 or 2 minute hike of every other part, then the entire ruin site is the size of a football field and that's all there is to it.

Of the solutions mentioned above, I would probably prefer the "super fast runner" solution, which doesn't affect the speed of game time but simply allows for a 20 to 40 mile per hour player character. It is not a perfect solution though. The player will have the visual experience of seeing the forest and other surroundings fly by at an unbelieveable speed as they move through the world.

I could give the user a little 4-wheeler I suppose. Ugh, what a pain.

I have looked closely at the scale of Tikal and it looks like the central area of concentrated architecture is about a half kilometer square with other areas within a half kilometer of the borders of the central area, yielding a total area of about 1 1/2 kilometers square, with only the most distant locations residing outside this range. This slightly alters my assumptions above. I thought a square kilometer would be too small, but it really isn't too small at all. Now realistically, how fast can a person traverse a ruin site that spans a square kilometer? An average walking speed of 3 meters per second translates to 5.5 minutes per kilometer. Will a player want to spend over 5 minutes traversing relatively redundant rainforest to get across a site. This is generally an extreme since it consists of going fully across the site but I should allow the user the option of doing this without unnecessary tedium and I might want 1 or 2 far off temples that are perhaps 1.5 kilometers distance. Perhaps I should allow the user to run at 5 or 6 meters per second. Ugh, what an irritating detail to have to mull over.

040623

I bought Michael Coe's The Art of the Maya Scribe yesterday and started reading it. It has tons of illustrations which should be helpful for constructing samples of hieroglyphic writing for the game.

I started laying out a ruin site using Tikal as an inspiration, along with a Chichen Itza cenote. I am trying to use right triangles to design the layout. It is difficult to understand the architecture of the palaces and acropolises. They are complex manageries of walls, steps, platforms, and ceilings. I'm not sure how to do that yet.

I am trying to flesh out the plot and quest of the game. Right now I am planning on having 2 major goals. 1 is to reunite the queen's remains with the king's. The other is to solve the mystery of who murdered the queen in the first place.

I started looking into how the player can interact with items on the screen. This is helpful for having the player push buttons or shove objects or take objects, etc. This can most easily be done by having the player click with the mouse on interesting parts of the rendered image. Taking a screen coordinate and finding the 3D object rendered at that location is apparantly called "picking" in the QD3D manual. I'm just scratching the surface on how this is done. Not at all clear on the details yet, but I think it will work nicely in the long run.

I did quite a bit of pen and paper work in which I tried to complete more of the story and come up with more puzzles.

The queen will have dropped a necklace at the cenote while struggling with her killer. The necklace has a series of mayan numbers that are a combination to a vault in the palace. The vault contains a shattered dish that must be reconstructed. The dish leads the player to a "sighting" pyramid where a distant column can be sighted with sunrise to find some artifact which must be returned to the king's tomb.

The queen's remains will be in a distant temple in the forest which can only be accessed by tunnel.

The add clues to the mystery of who killed the queen I will supply motives for a few suspects, such as a rival king in another city, a royal priest, the son and heir, and king's general, who might be in love with the queen, I'm not sure. Clues about the queen's death must suggest each of the suspects.

The final clue will be a picture of the murderer, but with no means to identify the person. Once the identification of the picture is made, the mystery is solved.

Here are all the puzzles I've come up with so far: necklace provides combination to vault, broken dish, sunrise sighting over distant temples or columns, translucent jade artifact which shines a green light beam on the wall at sunrise hilighting a glyph, gold artifacts which reflect light in a similar way to the jade mentioned above, placing the 5 Mayan color/direction stones on the right directions on an alter, glyph translation, first to syllables, then yucatec to english translation.

040624

I started Riven yesterday, which I completed a long time ago. I probably won't play the whole thing, I just wanted to familiarize myself with it. Other then better graphics, water animation, and larger movies clips, it's basically identical to Myst.

During one of my typical, but rather extreme, bouts of insomnia last night I had a chance to mull over several aspects of Myst and of my game.

All Myst puzzles serve the exact same purpose, to allow the player to bring red and blue pages to the library, (note, I said in an earlier entry that Myst had 2 endings, it actually has 4), in other words to allow the user to transport physical things around the world from starting locations which are "wrong" to final "correct" locations which push the game toward completion. This is rather similar to my idea of having the player of my game seek the primary goal of transporting the queen's remains and perhaps some tomb artifacts to the king's tomb. Must all games in this genre come down to moving objects in the world from initial game-start positions to final game-end positions, after which the goal of the game is considered completed? Further analyzing the Myst puzzles, there are 3 flavors of puzzles. Some puzzles directly reveal red and blue pages, some puzzles reveal Myst linking books, and some puzzles reveal new parts of the world that the user couldn't get to before. Fundamentally, the last kind of puzzle just mentioned purely leads to 1 of the other 2 kinds of puzzles. At no time does a puzzle reveal a new part of the world that doesn't serve 1 of the other 2 purposes, either to find red and blue pages or to find Myst linking books. The Myst linking books are similar in that they allow access to other parts of the world, but different in that instead of allow forward progress into new areas, they allow backward progress to old areas. Without them the user is trapped, unable to return to the main flow of the game. Note that these puzzles are basically like the third kind in that they simply allow the user to complete the task of the primary puzzles, which is to seek out and return red and blue pages. They serve no other useful purpose without that fundamental goal.

So all puzzles are either doorways to new places and subsequently chainlinks to more puzzles, or reveal physical items that must be transported around the world. Is this the only way it can be? Is there no other kind of puzzle? Some puzzles in Myst aren't doorways per se in that their solution doesn't directly reveal a new part of the world but their solution allows doorway puzzles to be solved, so their solution is no more than a combination to another puzzle. Most "combinations" in Myst work this way. The clock tower bridge is a puzzle that basically can't be solved without finding the right combination for the clock first, so seeking out and finding the combination is a puzzle that doesn't directly open a new part of the map but does directly allow the solution of such a puzzle. Just more chainlinks of puzzles when you come down to it.

One of the overarching puzzles of my game is to solve the mystery of who murdered the queen and who desicrated her tomb (could be 2 different people of course). However, I have been having trouble motivating why the player should care about the solution to this mystery. I have partly solved that problem but it does have the effect of reducing the mystery to one of the standard puzzle types defined above. The goal of the game will be to transport not only the queen's remains, but also many artifacts from her tomb, all to the king's tomb. The main "thing to transport" will be the queen's actual remains. Without too much linearity, it would be nice if this is one of the last items that is found. To give it a feeling of grandioseness compared to the other tomb relics to be transported, I will make the queen's remains unfindable without having solved the mystery of who her killer is. To lend to the goal of having this be one of the last items found and transported, the clues to the mystery will be found by seeking for the other items first. Notice that this gives importance and interest to the murder mystery, but reduces the solution to a standard "reveal part of the world, find physical thing, transport the thing" puzzle.

There are major problems with this idea presently. I really haven't figured out how to make the mystery's solution reveal the queen's remains. One idea is that the queen's remains will have been moved to the pyramid and associated tomb of the killer, so solving the mystery reveals which tomb to look for the queen's remains in, but if there are only a handful of suspects the player can easily search them all without needing the answer. I am not at all sure how to prevent finding the queen's remains without the murder mystery solved yet.

I have a few more ideas for puzzles. Similar to the sunrise sighting there will be a different kind of sighting puzzle. Instead of sighting the sunrise with a column to be explored, the player will sight a field of columns such that it must be sighted from 2 different locations, each one providing 1 axis of location data. The intersection of the sightings will be the solution column.

Another puzzle is that the queen's remains will be inside a ceramic container. The lid must come off so the user can see bones in it and the outside must have the queen's name so the user can identify it, but the lid will be too small to remove the bones and the container will be too big to fit through the tomb's doorway. The solution will be to smash the container.

I have been trying to think of astronomical puzzles. Without having thought of many I have thought of a number of interesting game issues, primarily the presentation of a nightsky. The sun will rotate around the scene in 24 hours of course, and likewise the moon will too (well actually at lunar rate, not 24 hours), changing phase along the way. As for stars, the most obvious solution is to map a texture of stars onto a sphere and rotate it around the world too, but I don't think this will work. Even if the texture is quite large, say 1024x1024, it will not have the required resolution and stars, even single pixels, will look like big blurry disks instead of points. I will have to experiment with this. One solution is to use a bigger texture, or to use smaller textures on smaller pieces of the sky, but that's a hell of a lot of texture data. The other solution is the one I used for the exact same purpose in Vertigo, which was to create a single triangle for each star and move it out to a sufficient distance to appear as a dot. This requires a ton of vertices, edges, and triangles though, even at a single triangle per star. If I only want the basic 1000 or so stars, that's 3000 vertices and 1000 extra triangles in the scene (only at night of course). Perhaps there can be a tradeoff. At night I don't need very detailed models of the trees and such. It would be cool to put a smokey milky way in too. It had strong meaning to the Mayans.

What is the point of bogging down resources with a nightsky? It lends to the ambience and in a realtime game is almost a requirement, at least if I am going to have parts of the game depend on sunrise. It would be nice if it mattered in some other way, such as for a puzzle. Not sure about this yet.

Puzzle idea. Perhaps the player can find a musical instrument and have to play a tune on it, or perhaps that's stupid.

040625

I'm thinking about terrain again. First I will start with a correction from previous entries. The docs for the Nanosaur public code suggest that supertiles are composed of 5x5 tile blocks and that 36 supertiles are active at a time. The docs are blatantly wrong in this regard. There are 42 supertiles active at a time, 7x6. I have no idea why. It clearly has nothing to do with fitting a screen's rectangular dimensions because the 7x6 grid is resilient to the rotation of the world against the orientation of the screen. In other words, it's still 7x6 even if the character (and subsequent world-view) are rotated so that the 7 long axis is vertical to the screen and the 6 long axis is horizontal to the screen. Oh well.

I had previously made a bunch of calculations on the elevation resolution. However, I had not carefully considered texture resolution. Nanosaur uses individual tiles with 32x32 textures. 25 of these are loaded into a supertile (for a total dimension of 160x160) and then downsampled to 128x128. As described above there are 42 supertiles active at any given time, so the total texture data for the terrain in Nanosaur at any given moment is 128x128x2x42, 128 square per supertile, 2 bytes per pixel, 42 supertiles, for a grand total of 1.3 megs of texture data. Not bad at all, especially on modern machines.

However, I want my game to have a much further viewing distance than Nanosaur, and possibly a tighter resolution for better detail. This presented problems in earlier entries pertaining to the vertex geometry but it also presents serious problems for terrain texture. Say I want a horizon of 100 meters and a terrain texture of merely 10 pixels per meter, which is quite low actually. Nevertheless, this works out as 200x200 (each of my 4 tiles is twice as long as the horizon for reasons explained in earlier entries) x100 (10x10 pixels per square meter) x4 (4 tiles active at a time), for a total of 16 megs. This is managable on modern machines, but sucks up 1/2 to 1/4 of the VRAM, and ideally I would like a finer grained texture than 10 pixels per meter, and finally to make matters even worse, I might want a more distant horizon than 100 meters, so this isn't going to work.

I've figured out how I can do this, but it's quite a bit more complicated than the 4-tile scenario I have considered up to this point. The tiles will be much smaller, perhaps 8 meters square. They will still be centered around a 4 tile set corresponding to the camera's nearest 4-way tile intersection. There will be concentric rings of tiles spreading out from the 4-tile center out to a distance corresponding to the required horizon, so for a horizon of 128 meters, there must be a 128/8 tile radius, or 16 tiles radius, so a grid of 32x32 tiles for the arbitrarily chosen numbers presented so far. The central tiles would be represented by high resolution elevation geometry and terrain texture. Concentric rings outwards would have decreasing resolution. The resolution can probably drop off exponentially for the desired effect so there would be very sparse data representing most of the tiles, both in vertices and texture.

How much does the total come to? Let's consider texture first, then perhaps elevation geometery. Assume each tile is 8 meters square. Assume the central 4 tiles use a resolution of 32 pixels per meter, or 1 pixel per 3 centimeters, not too bad. Each of the 4 tiles then requires a 256x256 texture, totaling 65536 pixels and there are 4 of them, for a total of 262144 pixels, at 2 bytes each, 524288 bytes, or 524K, about half a meg. Say the next ring of 12 tiles uses half that resolution. So 128 squared for 16384 pixels per tile times 12 tiles is 196608 pixels at 2 bytes each comes to 393216 bytes, or 393K. Notice that this second ring, despite having 3 times as many tiles as the center 4, only uses 3/4ths as much RAM. Let's say the resolution drops off by half for each concentric ring until it reaches 1 pixel per meter. Let's assume a total dimension are 32x32 tiles, as suggested above. The center 4 at 32 per meter take 524K. The next 12 at 16 per meter take 393K. The next 20 at 8 per meter take 163840, or 164K. The next 28 at 4 per meter take 57344, or 57K. The next 36 at 2 per meter take 18432, or 18K, and the final spread out to the horizon of 924 tiles at 1 per meter takes 59136, or 59K. The grand total is 1215K, or 1 meg. Excellent! Circular radial geometery instead of the simplistic square radial geometry assumed above would cut off the corners and therefore reduce the total quite a bit.

Assuming I didn't make a mistake, that came out so small that I can probably expand on it to some degree. One obvious expansion is to increase the horizon. Another is to decrease the rate of dropoff in resolution, and yet another is to start the center at a higher resolution.

Alternatively I might be able to get away with using larger tiles. The advantage of larger tiles is fewer models and fewer textures (but not noticably fewer total elevation vertices or texture pixels overall). I'm not sure if the number of textures matters (I suspect it does). I know the number of objects matters because experiments in previous entries in which I merged trimeshes together produced very noticable speedups. Perhaps I can use tiles that are 16 meters square.

I won't run the math on the vertex geometry. I believe it will work out pretty much the same way. I have inquired on the Quesa list as to whether this is a viable trick, and the response is yes, so I think I will go with it. It will vastly increase the complexity of the terrain managing routines, but there is no other way to handle it.

I also thought about tunnels some. Vertically extruded terrain, such as I have considered so far, cannot have overhangs, caves, tunnels, or anything of that nature. I also cannot easily have holes without extra consideration, and any holes would be triangular shaped unless extra vertices were added that didn't fit on the primary terrain vertex grid. The cenote will be built into the terrain. It will be a round area that drops vertically very suddenly and then has a relatively flat bottom of course. Tunnels will not be represented as holes into areas under the terrain. Instead, a tunnel's floor and sides will be represented by a groove or sharp canyon in the terrain. Extra objects will then be added the world which will create an illusioury ground cover and tunnel ceiling. I am not sure if I can get such ground cover objects to blend smoothly into the terrain. Experimentation is required.

I finally found the QD3D manual. 1762 pages long. Wow.

I tried today to get Queeg to render shadows but so far have had no success. I'm not sure what's wrong yet.

Later the same day...a response from the Quesa list says that the "interactive renderer" can't do shadows because the old computers that QD3D was invented on couldn't process shadows fast enough, so I'm going to forget about shadows for the time being.

040628

Over the weekend I got a copy of RealMyst and had a chance to both play it and study it some. It is a really marvelous game. It is very beautiful with generally good quality textures, including a nice trick for moving water which appears to employee two transparant water planes texture-animating against each other at ninety degree angles. It also has a clever trick for creating the illusion of reflection (which is too hard to do in realtime renderers). Instead of an opaque mirror or water plane, they make a translucent plane with some tinting. Then they create a flipped copy of the object behind the plane. The appearance through the plane is of a reflection even though the effect is completely an illusion.

RealMyst also has beautiful atmospheric effects. The sky is nice but the sunset and drifting clouds and nightsky are beautiful. In one Age it rains and that looks quite nice. In another age it snows and that is also beautiful. I am not sure how the clouds are done, whether they are procedurally generated or whether they are a preexisting texture.

RealMyst also illuminates some thoughts on how time can work in a realtime game. It apparantly runs at a rate much faster than realtime since the daytime nighttime cycle is quite short. I haven't timed it precisely but I would guess that a day is perhaps 30 or 60 minutes long. At the same time the player generally only moves through the world at a believable rate, perhaps slightly exagerated, but not grossly so. This has a very strange effect but which is generally not too detrimental. Since time is faster in the game than in the real world and since the player can only move at a visually real rate, this all means the player can only get a fraction of a day's work done in one game day, both in terms of thought and in terms of movement. Thought because the player's mind isn't sped up of course, and movement because the player's character doesn't move very fast with respect to the speed of the game. This isn't a very serious problem because the game doesn't consist of long multiday marches in which a player would notice that they don't get very far in one day's time.

Ultimately I find the solution quite satisfactory and might consider it for my game. Alternatively, there isn't any really good reason to do it in the first place. The game could run in real time just fine. The only real reason to make it run faster, as described in earlier entries, is that the programmer wants to show off the beauty of their game engine, elegant sunsets, rich nighttime skies, fast drifting clouds, that sort of thing. Aside from that, speeding up the game serves no purpose at all. So will I ultimately do this? I won't know until I get the program running and have a chance to experience it firsthand and try different approaches out.

I also finished reading my latest Maya book, the Art of the Maya Scribe. It has some very nice pictures that will offer good inspiration when it comes time to design vases and other artifacts.

I started laying out the foundation of the actual CodeWarrior project I will use. Up until now my testing has consisted of hacks to Queeg without any attempt at creating a system I can develop into the final program. Queeg is actually basically ready to go, but I am trying to make a more object-oriented version that I can use for my project. I believe the approach I will take will be to get the complex terrain routines up and running as much as possible. Only after I have a fully terrained world in which I can roam around with the appropriate loading and unloading of tiles and the appropriate resolution upgrading and downgrading centered on the player's location will I then attempt other aspects of the game.

Finishing the day, I have a solid start on the terrain code.

040629

The terrain code is well under way. I have two classes at the present time. One for the full Terrain and one for each TerrainTile. The terrain extrusion data is read in from a file and the tiles are initialized, including four different meshes per tile as varying degrees of resolution. It works great. Furthermore, the Terrain object properly keeps track of which tiles are active based on their proximity to the player. I am not using a square grid as suggested in an earlier entry. Instead, I determine active tiles based on the actual distance between the player and the tile. This means the active tile area is circular, cutting off the extra corners from a square design, and is therefore more efficient. On top of all that, each TerrainTile properly submits one of its four meshes depending on its proximity to the player, with highest resolution directly around the character and lowest resolution as distance increases.

I am having a little trouble sewing up the edges between tiles. Since adjacent tiles share points, the points only stored in the terrain file for one of the tiles and the neighboring tile must get those points from the tile containing the points after the tiles have been initialized. For some reason this is not working perfectly yet.

As of this afternoon the tiles are working extremely well. I have increased the tile size from the previously proposed 8 meters to 16 meters. Decreasing the number of tiles yields a solid improvement in rendering speed. I might increase it to 32 later, but it doesn't matter too much.

So I have terrain geometry working. I have a file format for saving extrusion data. I can read that in and create the tiles, each with multiple levels of resolution, I can successfully submit only those tiles within a horizon radious of the player and I can keep the "active tiles" list updated as the player moves around the world, and finally, I can submit the correct resolution trimesh for each active tile based on its proximity to the user.

What I have not done yet is put texturing on the tiles. This will be a little tricky. I need to figure out how to create texture objects, register them with Quesa, and associate with the trimeshes (one texture per terrain tile). I will also have to correctly calculate the normals for all the triangles and the vertices. Right now I am doing neither of these correctly, just setting them straight up.

I want to get the terrain working almost completely before I move on to any other aspect of the game. It literally represents the "foundation" on which all of the objects in the game will rest, to use a pun.

040630

I think I have pretty much figured out how to create textures at runtime and attach them to trimeshes. The code is falling to place pretty nicely. I am trying to decide on the best file format for saving terrain data. My present concept uses three separate files. The first is a 16-bit grayscale extrusion map at a resolution of 1 pixel per meter (I wasn't sure if 8-bit would be sufficient), the second is an 16-bit color texture palette that contains up to 256 kinds of textures that are available for 1 meter square cells (16-bit saves VRAM over 32-bit), and the third is an 8-bit grayscale texture assignment map at a resolution of 1 pixel per meter that assigns one of 256 possible textures to each 1 meter cell on the map.

I am unsure about efficiency issues. What is the proper tradeoff between tilesize and number of active tiles? As one is decreased the other increases. What is the optimal value? Will the optimal balance be the same on all machines? How much VRAM do I want to take up with terrain texture data? This governs another tradeoff between the texture resolution and the horizon distance (and in addition, the drop-off factor in resolution with respect to distance from the player's position).

More thoughts of woe and despair. Yesterday I watched the Macworld Keynote and they had a demo of Myst IV, coming out this fall. There was some commentary that it is written in OpenGL. I also believe that Nanosaur II is written in OpenGL. Quesa appears to be off the professionals' radar. Am I working with a lemon without knowing it? Maybe Quesa just can't provide demanding performance compared to OpenGL. Who knows? As of this afternoon the terrain texturing is coming along nicely. Still working out a few small bugs, but it's basically in place. I also haven't written the necessary code to compute the vertex normals along the edges between tiles yet.

040701

I got the terrain working perfectly last night, with textures. It has the required elements now. Namely, it opens terrain and textures from files, stores the entire world as a set of tiles, renders only those tiles that are within the horizon of the player, and renders each tile with both a mesh and a texture that is scaled in resolution corresponding to the tile's proximity to the player.

I haven't yet written the routines to calculate vertex normals along the edges of tiles, but although tedious, this is straightforward and can be worked through at any time.

There are two serious problems presently. The first is that the scaling in vertex geometry resolution has a serious detrimental effect. Whenever two adjacent tiles are rendered at different resolutions their shared edge doesn't merge properly. This can create a visual effect where the user can see under the edge into the black void under it. I'm quite worried about this. I'm not sure what sort of solution will help. One is to revert to the old idea of having all geometries render at the same resolution. The textures could still be scaled, but that would only help some. The intolerable number of triangles required for this method is a more serious problem. The only real solution on that track is to vastly reduce the resolution of extrusion points on the terrain. The alternative solution is to somehow blend tile edges together. A tile has two opposing neighbors on one cardinal axis. If those two neighbors are at different resolutions, the tile in the middle could use some sort of geometry which has the proper merged edge on both sides and blends their resolutions together. I'm not sure how complicated this will be, and it will have a combinatoric effect on the number of trimeshes required per tile, since all possible blends across both axes must be accounted for. If there are 5 levels of resolution (this occurs if tiles are 16 cells in diameter, with lower resolutions of 8, 4, 2, and 1), then there are 5 by 5 blends per axis and two axes, so 125 total combinations. It's possible that I can put a hard line between blends on the primary diagonal of a tile. The primary diagonal is the edge that occurs in the lowest resolution version of the tile, in which the tile is just two triangles. That edge is present at all resolutions. This means each adjacent pair needs to be blended, 25 combinations total, but doesn't need to cross with the other pair, producing a total of 50 instead of 125. That's still a ton of trimeshes for a single tile however.

I have had some other incidental thoughts as well. Perhaps instead of always aligning diagonals in the same universal direction, I should split each square (whatever the resolution of the trimesh) by putting the diagonal across the major slode of the square, so that the triangles hinge around the curvature of the slope. This would be done in the following way. Look at the difference in height for the opposing pairs of corners of the square. Use as the diagonal edge the edge whose opposing corners have the lesser different in height.

The other major problem I'm facing is that the camera field of view seems all wrong. The Queeg default is a 50 degree field, which seems small to me. Without periferal vision, I would estimate the human fov at about 90 degrees. However, with the 50, the fov is too big. For example, with the camera position 2 meters above the ground and looking straight down, I would expect about 1 meter to fill the fov at the distance of the ground plane (2 meters away). Bearing in mind that the individual texture cells corresponding to 1 meter cells in world units, I would expect to see one of those cells fill the field. But in instead I see about ten times that amount. I'm not sure what to do there. I need size frames of reference to study this problem so I am going to make a very basic human model and put it in the world in a few places and study how big it appears at various distances from the camera.

I have more or less put the necessary code in place to make the camera "ride" over the terrain, meaning it stays at a constant height over rough terrain. It looks really good. This also had the nice side-effect of fixing the camera fov problem mentioned earlier. I guess the camera was higher off the ground than I thought. Explicitly putting the camera at eye-height makes the world look just right. The problem now is that the Queeg code that check line intersections with triangles fails fairly often. This won't do.

Okay, I pretty much solved the problem with the triangle intersection error. It occurs when the line testing against a triangle is near the edge of the triangle. There is a very convenient "slop" factor involved which accounts for this kind of error and I have put into my code a system for steadily increasing the slop factor when attempting to find an intersection between a line and a triangle. It works very nicely.

This leaves me with the serious problem of deciding what to do about the unmerged edges of adjacent tiles that are at different resolutions.

Well, I altered the program so that instead of varying tile resolution with distance, all tiles are rendered at a single resolution. However, I left in the code that varies the texture resolution with distance. Overall, this works pretty well although it isn't what I wanted. I am not sure if I will be able to use my initially desired extrusion resolution of 1 point per meter. This may not be very feasible, but until further notice, this is the solution I think will have to go with. Maybe I'll come up with another way at some future point in the project.

One possibility, mentioned earlier, is to "blur" the extrusion somewhat by taking areas that are relatively flat and making them perfectly flat and then removing the internal triangles and making single large flat triangles for those areas. This could certainly help a lot, but at the same time damages the entire point of having a high resolution terrain. Making certain areas perfectly flat is very unnatural. Further experimentation is required.

040702

I made a small addition to the code last night which takes into account the framerate when performing actions like rotating or moving the character. Previously this had been a nuisance. I would rotate or translate by a constant amount. This meant that whenever the framerate changed (as a result of window resizing, or looking in a direction that reduces or increases the amount of stuff being rendered, or running the program on computer with different power processors, the rates of character movement always changed. Very inconvenient.

I've had an idea on how I might be able to deal with the unmerged edges between tiles when using varying resolutions. Only the edges between tiles need to merge. Within each tile I should have free reign to do whatever I want. So when creating a downsampled trimesh I need to preserve all the full res vertices around the edges, but can remove vertices within the tile. I have been using 16x16 tiles, so each edge has 17 vertices on it. That leaves 15x15 inside the tile that I can work with however I please. I will try this and see if it works better.

040706

I implemented the merged edge idea mentioned earlier. I reduced the resolution of vertices within individual tiles, but maintained the full resolution around the perimeter. I then used the tiles in the same way as in the previous reduced-res method, by using lower res tile trimeshes for distant tiles. The effects are mixed. The edges blend well, but there are still serious problems that result from the lower res trimeshes. The terrain looks like it is magically changing shape constantly, not a good effect of course.

The next idea I have is considerably more complicated. In fact, each generation of idea I have had on handling the terrain complexity has increased in complexity. The next idea consists of analyzing each tile's geometery individually and finding an acceptable method of decreasing the resolution of that tile. This would presumably work by analyzing each vertex in the high res mesh and deciding whether it is similar enough in height to its neighbors to be removed from the trimesh. The threshold of similarity would lessen with lower res trimeshes so that more vertices are allow to be removed. While the search problem is fairly well defined (simply compare a vertex with its neighbors for some threshold of height difference), it isn't as clear how to fill in the resulting holes with triangles.

Perhaps a wavelet decomposition of the heightmap could be used to find areas of "height detail", and could be used to determine where vertices can be removed? Over the course of an hour or so I have developed a recursive triangle decomposition algorithm that takes a tile and a set of "crucial" vertices in that tile and decomposes the tile in a series of triangles at various sizes that insure that all of the crucial points are preserved as the corners of triangles. This would be a two-pass algorithm. First, each tile would be decomposed. Then, any edge vertices that are used as a result of the decomposition would be added to the crucial vertex list of the adjacent neighboring tile. Then the decomposition would be done all over again taking into account the newly added crucial points. This would make the edges between tiles merge smoothly. Right now, I am not sure how such a system would work with multiple trimeshes for different distances. Clearly, I could produce such trimeshes with different sets of crucial points chosen on a sliding scale of "defect" tolerance, but once again, that raises the question of how to merge tiles. One possibility is to always add all edge vertices to the crucial list so all trimeshes for one tile will merge will all its neighbors, but that is extremely wasteful.

Although I have some ideas for properly handling terrain, I am beginning to wonder how much time I will spend bogged down on this problem. I need to make some progress on other aspects of the game or I will risk losing sight of the longterm goal.

I am trying to get the code written that calculates the vertex normals at the edges of the tiles. It's tricky because it requires the heights of the cardinal neighbor vertices, which are in neighboring tiles. There's not fancy or hard about it. It's just a bunch of details that have to be hammered out precisely.

040707

I got most of the code written for calculating vertex normals along the edges of terrains. I have given some thought to how to find "crucial" points in a tile, points that must be preserved in the recursive bisection algorithm mentioned earlier. I think that perhaps I can find the height of all the points above the main planes of a cell (the two primary triangles formed by the cell's corners and one major diagonal). Any points higher than a threshold would be deemed crucial. One problem with this is that in steep areas most points would be crucial even though the tile may have very little 3D texture. For example, a steep but flat slope does not require many triangles but would use many crucial points in the scheme described here. This may not be the perfect solution.

Okay, I think the vertex normal business is wrapped up. I can probably optimize the speed of the calculations, but I'll worry about that later.

Things are getting complicated with the terrain. After having tried a few different things, I believe the best idea is one I haven't implemented yet, the one mentioned most recently. This method optimizes the trimesh by turning large flat areas into a small number of large triangles. It has the same edge-merging problems as all the other ideas, but I think I know how to handle that. I also think I know how to find crucial points. Unlike mentioned previously, crucial points would not be found in advance. They would be found throughout the recursive subdivision on a triangle by triangle basis.

There are other advantages besides the simplification of the geometry. The optimized terrain can be precalculated and saved such that the terrain file with the game will be reduced in size. This should also speed up the process of launching the game because instead of extruding a full description of the terrain, only those points deemed important will need to be created.

The catch is that I kind of need to go back and rewrite everything I have done so far from scratch. Very little of the existing code is going to adapt very well to this scheme. Oh boy. Better get started.

040709

I have spent the last day or so rewriting the terrain routines. Actually, I am not writing within the game framework directly (within the Queeg model), but rather I am working on a separate program that takes a grayscale extrusion map and preprocesses it into a set of tiles, each subdivided optimally into triangles of efficient size given the complexity of the surface texture of the terrain. Ultimately I will dump this data out to a file format of my design, which will then be read into the game ready to go, without any need to process the terrain data at game launch time.

The terrain processing program works pretty well right now. There are two things that remain to be done. One is that tile edges don't blend yet. I need to incorporate the crucial points of one tile's edge into the crucial points of the neighbor tile. The other remaining task is to properly define a method for identifying crucial points. Right now I use a height different threshold. Any point higher or lower than a triangle beyond the threshold is deemed crucial. The threshold does not scale with the size and resolution of the triangles, and it is fairly arbitrary. I think I will start using the angle at a particular point instead.

040712

I'm starting to feel like I've been working on the terrain engine for years now. However, the terrain engine is both the largest and one of the most complicated aspects of the game, so I feel it is worth taking a little time to get it right. Hopefully I'm not wasting my time by focusing on it.

I have completely rewritten the terrain extrusion preprocessing program. Previously, this small program took a grayscale extrusion map and simply remapped it so that each tile appeared sequentially in the terrain file. That was it. The game itself would then read in the extrusion data on a tile by tile basis and extrude the terrain. This was time consuming and made launching the game rather slow. Additionally, it offered no optimization per se, since it presented the game with full resolution extrusion data. It was my intention to have the game calculate at launch time various methods of optimization, such as downsampling the resolution of the terrain. This has all been explained in earlier entries.

That is all gone now. The terrain program is growing into a fully functional program itself, although it isn't very large yet. What it does now is read in the grayscale extrusion map and break it into a set of tiles. Then it uses recursive subdivision to break the tile into triangles at various scales depending on the vertical roughness of the terrain. This has the nice effect of making large flat areas representable with only a few large triangles. This program also carefully merges edges of tiles together with neighboring tiles.

Lastly, this program fully calculates the arrays of points and triangles exactly as they will be used by a trimesh object so they can be quickly scanned into the game. It doesn't calculate triangle normals, vertex normals, or vertex UV coordinates yet. That would make the terrain file larger. I will have to decide eventually whether I think it is more important to precalculate that information, bloat the terrain file, and decrease the launch time of the game, or vs/va.

The next step is to incorporate the new terrain file into the game's file opening and trimesh building routines.

Okay, I have altered the game code so that it reads the new optimized terrain data. Things seemed to work pretty well. I have not put in any code that uses lower res textures in the distance yet, and I expect that will help quite a bit. I also have not calculated vertex normals for shading yet. That will be a little tricky with the new system. I need to think about how to do that.

040713

Moving right along. I am calculating the vertex normals with the new system. I do it quite differently than in the old system. The old system looked at the heights of the four cardinal neighbors of a vertex. This doesn't really work with the new system because the vertices can be arbitrarily spaced out. Instead I take the average normal of all triangles using a particular vertex and make that the normal of the vertex itself.

I discovered that the texture UV mapping has be be flipped on the Z axis in order to get a proper mapping. I have no idea why this is so.

There is a minor bug in the new terrain system. The problem can't possibly be in the game code, it must be in the terrain optimization and generation code. Sometimes there are slices in the terrain where you can see under the mesh. It doesn't happen very often.

I think I'm going to try to figure out how to get mipmaps to work. This way I don't have to explicitly load different dimension textures for a terrain tile that is distant. The mipmap will do that automatically.

Well, after inquiring on the Quesa list I have discovered that mipmaps are not yet supported. The best way is similar to my previous methods, to submit a trimesh with a texture of a particular dimension depending on the distance of a terrain tile from the user's location. However, I think I can avoid multiple copies of the same trimesh. Instead, I will try to only have copies of the textures and to redirect the trimesh's texture shader to the appropriate texture at any given time.

Okay, I got the texture switching to work. It works nicely, except that it switches textures too often, which makes the program jerk. I think I am going to increase the tile size from the present value of 16 to 32.

I've added a nice little routine that checks the slope under the player's position. If it is too steep, the player slips down the slope. Pretty cool.

I discovered an interesting quirk in the calculation of vertex normals. My optimized terrain system allows vertices of one or more triangles to reside on the edge of another triangle without making a vertex along that edge. Since I only calculate vertex normals by finding triangles using the vertex in question, I miss the triangle that such a vertex is along the edge of. This creates unsmooth blends across the edge of the triangle. This should be pretty easy to fix though.

040714

I have spent most of the day perfecting the routines for calculating vertex normals on the tiles and one the edges and corners of the tiles. It works very well now.

040715

Last night and this morning I altered the way in which terrain textures are read in. Previously, I would construct the highest resolution texture for a tile and then downsample that to form lower resolution textures for the entire tile. This was fairly slow. Now, I form textures for each cell at each resolution prior to constructing the larger tile textures, and then patch the cell textures together for each level. This is quite a bit faster.

There is a serious and irritating problem associated with vertex UV coordinates. They seem to wrap slightly at the edges, and they wrap by different amounts depending on which resolution texture I am using.

040716

I figured out yesterday afternoon what's going on with the UV coordinates. I had the boundry function set to "wrap" (it's just the default actually). Unfortunately, I tried switching it to "clamp" and it looked much worse, in a different way than the previous artifact. I'll just have to worry about it later I suppose.

The terrain engine is in pretty goood shape actually. I think I might try to reincorporate the idea of lower res meshes in the distance. With my triangle subdivision tile optimization in place, I will try to make other versions of a tile that don't recursively subdivide as far. I'll have to see how this works out. I'm also pretty sure I want to increase the tile size to 32 meters square.

Yesterday I tried to use Nanosaur's camera frustum testing routine to cull tiles that are out of view of the camera before submitting them to the renderer. It doesn't seem to work perfectly. It successfully tests for tiles (any object ultimately of course) that are behind the camera (and in front of the camera but beyond the yon limit), but fails to catch side objects outside of the camera's cone. Not sure what's going on here.

I found Queeg's frustum culling code and I'm using it instead of Nanosaur's now. I'm not sure if it's definitely better, but I'm not going to worry too much about that right now.

I have reincorporated the geometry scaling into the program. Each tile is turned into a set of optimized trimeshes using triangle subdivision. In order to make edges blend smoothly I insist on maintaining the highest resolution along borders of tiles, but not in the interior. The system works pretty well and definitely speeds things up considerably.

I have successfully increased the tile size to 32 meters square. This produced a significant speed increase by decreasing the number of tile objects by a factor of 4.

So I have both texture and geometry resolution scaling with distance. Overall this approach to terrain seems pretty good. I am getting very acceptable framerates. There is a problem however. For some reason, the animation of the program "hiccups" periodically. I assume this is associated with loading new textures or with submitting new tiles as the user moves around. However, that cannot be the entire explanation. I have tested the system with the lowest resolution textures and no resolution scaling, so all textures on all tiles, regardless of distance are at the lowest resolution. Since the tiles are 32 meters square now and the lowest resolution textures correspond to 1 pixels per meter, the lowest resolution textures are 32x32 pixels, or 1K pixels and 2K data at 16 bit color. That's positively microscopic. Loading these textures cannot possibly be causing the hiccup. I am presently unsure.

040720

In the past few days I have switched gears somewhat. The hiccup went away so it must have been a quirk, perhaps RAM was too loaded down or something. I am now concentrating on the next phase, populating the world with objects, primarily a forest of trees, and eventually pyramids and other buildings, and finally moving things like animals and flowing streams.

I am not working within the game itself right now. Rather, I am expanding the terrain generation program. Originally this program simply regurgitated the extrusion data on a tile by tile basis instead of a full terrain map. However, it changed radically when I switched to the new optimized trimesh terrain in that it created all the trimesh data in advance and saved that into a file which could quickly be digested by the game itself. I am now extending this program further to allow the reading in of a list of object types, and the placement of objects on the map, followed by writing of the object placement data for later use by the game itself.

040722

The basic terrain editing program is in place for placing objects on the tiles and writing and output file for storing the object locations. I might want to spruce up the object placement tools with fancier randomization and more control over where objects are placed when they are randomly placed (as opposed to located specifically where the user wants them), but for now the basic system is in place and I have an object placement file which I can try to incorporate into the game. So that's that I'm going to do next.

The game nows reads the object placement file and populates the tiles with their various objects. My previously barren terrain is starting to look like an actual forest now. Pretty slick.

040723

Since I am still slightly unsure about walking speeds I simply settled the matter myself today. The long hall in my building is 117 tiles long and the tiles are exactly one foot square. I timed myself in a fast "purposeful" walk and it took 18 seconds, or 1.98 meters per second. Any speed over 2 meters per second is going to be totally unrealistic as a walking speed. Naturally, in a rainforest environment, that speed should be cut drastically. Any speeds higher than 2 is going to have to be considered a jog. I'm not sure how to process this information, but that's it.

040726

The forest is growing nicely. I have created a few more tree models and have continued to develop the terrain creation program for placing objects on the tiles. I have also made a very nice visual effect to represent the pattern of leaf shadow and sun light that projects through the canopy on the forest floor. I even have it animating softly as if the trees are blowing around a little bit to project the sunlight. It looks cool.

I have had to step the depth buffer up from 16 bits to 32 bits to get a good look on a number of distant surfaces. This has not adversely affected the speed, thankfully.

I am a little concerned about framerate. The forest is not very thick yet and none of the tree have any textures on them, yet my framerate is between 30 and 80 fps. I have some ideas though. First of all, I think my tree models are too detailed in the branches. The branches account for most of the model, since they are complex cylinders while the leafs are just a few large flat triangles. I think can reduce the cylinder detail considerably. Also, I plan on using the same distance-trimesh detail trick with the plants that I am using with the terrain. This means only the closest tiles will use complex meshes for the plants, and distant tiles will use much simpler ones. This should help a lot.

One issue I am unsure about right now is how to best mark the edge of the world. In Nanosaur I (the old Nanosaur) the edge is easy since the entire world is sort of set down into a valley. The edge was a tall vertical impassable wall. In Nanosaur II the edge is marked by a wall that creates the illusion that the forest continues on but is simply too thick to pass. In reality it isn't too thick to pass, it's a flat wall with a picture on it. I will probably try to do it this way, but I'm not sure how well the illusion will work. In Nanosaur II the illusion works because the player can't stop in one place and look around. The character is always moving very quickly through the world. This makes it impossible to study the parallax of a flat wall and see that it is a flat wall. In my game the player can stand still and look back and forth, which will reveal the wall illusion very quickly. I will just have to experiment with it and see what works best.

040729

I have done a couple of nice things recently. First, I texture mapped a couple of the plants, primarily to see if rendering a textured forest would be noticably slower than the nontextured plants I have been using so far. The forest looks fantastic and still runs pretty fast, although the forest needs much denser trees and shrubs.

I also implemented an efficiency improvement. Previously, all tiles would be fully loaded into memory at the beginning of the game. This had two downsides. First, it took a long time for the game to start up. Second, I wasn't sure if everything would actually fit into memory simultaneously. I am now using a lazy evaluation strategy in which tiles are only loaded when they come into view, and then, only the trimeshes and textures which are needed are loaded. That way most of the peripheral tiles which the user passes by won't have to load their higher resolution geometries or textures.

040803

Previously, calculating vertex normals was really tricky because it required requesting triangle normals from adjacent tiles. This made a number of things messy. First, it was slow and tedious to perform the vertex normal calculations all at boot time, lengthening the game boot time. Second, my new efficiency trick of loading tiles only when I need them rather than all the the beginning effectively ruined any hope of calculating vertex normals because they would require requesting triangle normals from neighboring tiles that hadn't been loaded at all yet.

The solution I have come up with is to put a routine in that calculates the vertex normals all at once in the old-fashioned way, and then saves all the vertex normals to a separate file once and for all. In all future boots of the game, the vertex normals are pulled from the file instead of calculated on the fly.

The game is a little jerky now, with brief weak hiccups at regular intervals. I believe that has to do with loading all the large textures for the various objects that I am accumulating as the forest complexity grows. I need to make sure that there is only one global texture for a given kind of object in (instead of one copy per tile), and then I also need to put in geometry and texture scaling routines on objects the same way I did with the terrain, as a function of distance from the user.

Okay, I got the objects to share textures. The game runs smoother as a result, I guess because VRAM isn't constantly paging in new textures. Plus of course, this saves a lot of precious VRAM by not duplicating textures.

040806

A few days ago I got the code in place for using lower res objects in the distance, both in terms of vertex geometry and texture dimension. I have been tediously reducing the detail of my tree models to create these lower res models. It's coming along, but it takes time.

I increased the size of the test world from 256 meters to 512 meters. This gives me a deeper view "into" the forest, and man does it look good. It looks fantastic. I need many more species of trees and I need ground cover plants and vines and philodendrans and bromeliads, but it looks fantastic.

One concern is that even with my distance-dependent scaling of vertex geometry and texture dimension, the program is barely running at a good speed, somewhere between 20 and 40 fps most of the time. It will not survive a thicker forest unless I can solve this problem. I am unsure if the problem is the complexity of the models or merely the number of objects in the world. Further experimentation is required to determine the primary problem.

040812

Things have slowed down a bit on this project. I have been concentrating on my PhD recently. However, I know what I need to do next. As I wrote before, I am concerned about the potential performance hit that will result as the forest complexity is increased. I am not sure if the present slowdown is resulting more from the vertex and texture complexity of the models or from the sheer number of models. I will test this by substituting extremely simple models (cubes perhaps) in for all the objects and observing how the performance changes as a result.

After some testing, it appears that while the performance hit is coming from a number of things at once, including vertex geometry of the models, the number of unique objects in the world, etc. the major hit is coming from the terrain tile vertex geometry. I want this to be high enough in the viscinity of the player that the world doesn't appear to be changing dramatically as the player crosses distance-detail thresholds. Nevertheless, I believe I will turn the distance thresholds down and at the same time I will increase the number of levels so that the least detailed from of a terrain tile has even fewer vertices than the present design.

I have further determined that the translucent leaf shadow light pattern that I created to drift around on the forest floor has a serious performance hit associated with it. I just tried an idea but it didn't help much. Previously, the light pattern was created with a trimesh of the highest resolution regardless of the tile's distance from the user. I have altered it so the light pattern always gets a trimesh equivalent to the actual terrain trimesh for that tile, which scales with distance. However, this only helps a little bit. More to the point, there is a dramatic slowdown between having no light pattern at all and one that is drawn only within a very small radius of the user. Even if only the user's present immediate tile has the light pattern there is a serious performance hit. Since this effect is only for a pleasing appearance I will have to make it a user-controllable option.

040819

I created a nice little grass object to start filling in the forest floor. However, I was dismayed at the performance of the game. Then I started thoroughly testing the performance by removing the grass objects from the scene and eventually removing all objects except the terrain itself. Although the framerate is extremely high, the game is hiccuping really bad. I am attempting to track down the problem.

Okay, I'm back in business. I'm not sure what the problem was, but had nothing to do with the game itself. I tried quitting almost all the programs that were presently running on the computer and the game stopped hiccuping. With the present complexity, both in terms of distance based scaling of geometry and texture, and in terms of the number of kinds of plants I presently have (eight total) when I am in the middle of the map I get a consistent 44 fps or so from the head view and 27 fps from the overhead view. Although low, this is acceptable and can be worked with.

I am excited by how beautiful the forest is becoming as I add new kinds of plants to it. Needs more variety though, and eventually it will need specific areas. Right now I am generating plant-placements in the simplest way possible, by peppering the entire map evenly with all types of plants. Eventually I will want specific areas to have concentrations of certain kinds of plants, just like a real forest. Not only will this make things more accurate, but it will make things more interesting since all parts of the map won't look the same when I do that.

040825

I have finally made the UV mapping for one of the complex palm tree models. Meshwork doesn't make this sort of UV editing very easy, so it is quite tedious. Things look nice. Needs more...variety I suppose.

040830

I create a basic hanging U-shaped vine today, no texture for it yet. The basic goal at this point, before proceeding with the game in any other way, is to fully enrich the forest with a satisfactory diversity of plant models.

041021

Making a tiny bit of progress on a palm texture for the palm tree. This was one of my first models, but I never made any textures for it.

041115

Finally finished the palm texture that has been waiting for so long. At this point all the plant models are fully textured except the vine, which barely needs a texture at all. The forest looks really nice. It needs more diversity, but I don't think that will be my focus in the future. If I ever continue working on this project the next step should probably be to put Mayan ruins in the forest. Time will tell.

050107

I just got back from a trip to Belize, during which I went to some rainforest. This reinvigorated my interest in the project, but I am concerned that my shabby documentation will make it hard for me to pick up on it again since I will forget how things work.

Given that the project has been waning for several months and is more or less indefinitely suspended, I have written up a careful description of the various terrain setup programs so that I will be able to refamiliarize myself with the project relatively easily in the future.

I have created a second kind of vine. The previous kind is a giant U, with both ends in the canopy. The new kind is a vertical strand, like the vines that often hang from a tree down a trunk to the ground.

I have added a max distance to the object placement program, in addition to the previous min distance. This allows me to say that certain kinds of objects must be near other kinds of objects. This was helpful for placing the new vertical vines next to the trunks of canopy trees. It will also be helpful for placing philodendrans and bromeliads.

I have a couple thoughts on where the project should go next. The forest is not diverse enough. It needs a greater variety of plant species, especially ground cover. I would like to create things like philodendrans and bromeliads. I would like to create a way of placing and modeling water in the creeks that I have already designed into my test terrains. I would like to create models for partially excavated ruins and start placing them in the world.

I am not sure when I will dedicate the necessary time to any of these goals.

050109

I have created a few new plants, namely a new understory tree and a giant "aloe" type plant that was inspired by a photo I took in Belize.

I have added a border forest around the edge of the map. The intent is to bound the user in with a sense of impassable thick forest, as opposed to some other form of map edge. I'm not sure if the effect works very well yet, but it's just a first pass.

I've been thinking about how to put water into the game. There are a number of issues that need to be solved. The most important are the defining of water objects, which will probably be flat planes, and the implementation of water animation, using some sort of UV coordinate animation similar to the leaf shadow light effect.

050110

Started added water creation tools to the extrusion converter program. I'm not entirely sure how I will handle the UV mapping for such objects yet.

050111

I have finally figured out how to make a texture repeat tile-like over a surface. This enables me to use much smaller textures since the textures don't have to span and entire object. One nice consequence of this is that the textures can be much more highly detailed and yet be much smaller then before. Converting all the existing models over to the repeating textures is going to take a while though.

The repeating textures will also be helpful for the water objects. I wasn't quite sure how to map a water image to an arbitrary-sized water object without having scaling problems, but if I can tile the texture it won't matter how big a water object is, the water image will stay the same size and simply repeat tile-like across the surface.

I managed to convert all of the larger trees to repeating textures for their trunks (instead of having a vertically tall texture, the texture repeats up the trunk). The UV mapping on the trees is pretty hard with Meshwork. I can't get really good mappings with the tools it provides. I might write a UV editting tool at some point, but I'm not sure how much work would be involved.

050112

Trying to add water right now.

050113

I've got decent flowing water now. It doesn't look really pretty, but I think that is more the fault of the water texture I have designed than of the water implementation in the program. At any rate, it represents a good first version.

I've made a few more models. What the forest really needs is a thick understory and ground level so I'm trying to make more small trees, bushes, and grass.

To give the forest some life I really want to let stationary objects exhibit some natural motion. For example, the leaves of trees should sway a little bit. Things like that.

050114

The world building part of the project is in really great shape. I have added two kinds of philodendrans. Similar to the vertical vine that I created earlier, these plants must be placed more carefully than other plants since they have to be placed next to an existing tree. They are even more complicated than the vertical vine though becuase they also have to be aligned with the tree so they face away from the trunk. In order to add greater variety, I have also added the capability of repeating a model a few times when it is placed, along with a slight transformation in location. This allows me to stack philodendrons vertically to create variety instead of having all the philodendrons look identical. I might also use this trick for some other plants at some point.

Wow, it's really beautiful. I need to redo the geometry of a number of models so that they more carefully distribute their textures without showing the edges. Leaves projected onto flat planes should not have a sharp edge at the end of the plane. Instead, the leaf pattern should become looser toward the edge of a plane. I have done a reasonably good job of this so far, but I need to redo it in some specific cases.

I think I will work on movement next, to allow the canopy to sway and to allow plants to sway a little bit.

050116

Wow, what a productive weekend. I have done so much and the game is looking really really good now.

I have put in routines that allow the plant models to sway in the wind. My hope is that adding just a touch of movement to the vegetation will make the forest seem "looser", less like a concrete model. Once I add wind (at various altitudes) I can use the wind direction and strength to drive the plant swaying.

I have put in rain. The rain even falls at an angle. Once I add wind I will use the wind direction and strength to drive the rain angle. For now there is only one "heaviness" of rain, but I will add more later so the user can be in drizzle, a downpour, or anything in between. While doing this, I went to the Stoneship Age in RealMyst to remind myself how they did rain. I like my rain, I even think I like it more than RealMyst's. However, RealMyst does one have very nice thing. It has lightning. Lightning bolts are not very prominent, but the "cloud-glowing" kind that makes everything light up briefly is in RealMyst and it looks really good. I'm not sure how to do that yet. However, I'm not sure if rainforests have lightning very much. I guess they do, but don't know.

I have ditched the old ground-sky dome. It used to have a picture of clouds on the sky and a picture of ground on the ground. Now I have two separate objects, one for sky and one for ground. The ground object is actually textured to look like the top of a canopy, not like the ground itself. I'm hoping this will help in those situations where the user gets high enough to see a long ways off, such as from on top of a pyramid. The sky object has no texture at all, just a color. I have put in a color cycling model that follows a day-period and cycles through appropriate hues, blue in day, pink and orange at sunset and sunrise, and black at night. It looks fantastic. I need an actual sun disk at some point...and it would be nice if the sky color actually followed the sun disk. A real sky is orange in the west and blue in the east at sunset for example. My sky is all one color. I am also using fog dynamically to help aid the daylight cycle. I use bright thin fog in the day and black thick fog in the night.

I have added moving clouds. There is a second sky object (both are vertically flattened domes, the vertical flattening prevents the fog from destroying the sky color overhead, only at the horizon) that is slightly smaller than the sky dome. On this cloud dome I animate a texture of alpha clouds. It looks fantastic.

I'm not sure what the next step is. I would like to put birds into the world. They are one kind of animal that I think is relatively easy. Mammals are hard because they move in complicated ways. I might be able to hint at monkeys with some kind of lump in the canopy, but for the most part mammals are hard. Bird on the other hand just sit still and glide in a nonmoving manner. Alternatively they flap their wings, which is a pretty simply motion to create, compared to the complicated leg movements of mammals.

The game is in desperate need of sound. It looks real enough at this point that I am viscerally aware of the absense of certain sounds, such as rain, or wind-blown leaves. Insect noises would also be nice.

Many textures need to be redone. I have made cursory passes at most textures for the sake of getting the game up and running, but now the lack of attention to these textures is hurting the visual appearance of the forest.

I would really like to make the various geometry level models of the plants fade in and out as they cross distance thresholds from the user. RealMyst does this. There are a number of problems with this though. One, it is quite complicated and would take a lot of time and effort to program. Two, it would require all textures to be converted to 32-bit instead of 16-bit since it uses the alpha channel. That would double the VRAM requirements. 16-bit texture do have 1 bit of alpha and I need to test this to see if it is sufficient. However, I suspect it is not. Three, having multiple models for many plants in the world at any given moment will obviously hurt the framerate.

Later this night I added a second cloud layer. I have two layers at two heights now. I also started working on a sun disk. Getting it to orbit the world is hard since the world isn't spherical, it is a squashed dome.

050117

I did some thinking about the game plot again. Previously I was thinking about a historical mystery and moving a queen's remains around to let her be with her king's remains. The puzzles were all going to be "ancient" puzzles, built into the ruins. I'm not sure about that now. I really seems kinda stupid. Now I'm leaning toward a more basic idea. The player arrives to discover that the archeological team he or she was meeting is mysteriously missing. I think I will have the user find journals and hints that suggest that the previous lead archeologist was becoming a paranoid schozophrenic. This allows me to have him start encoding his clues in weird puzzles because he's paranoid about hiding things. I think I will have an assistant who also leaves journals around and question's the archeologist a lot. Ultimately, it should turn out that the archeologist wasn't completely crazy, he was actually on to something. I have no idea what yet.

Geez, designing the plot and the tasks has remained an unfinished challenge. I just don't know how to make the game interesting.

I have produced a decent performance increase on the plant-swaying that I recently implemented. My first approach would yield a small but noticable drop in framerate when it was turned on, usually about 15% to 20% slower. This does not result from the actual math that is required to move the objects around, it results from the increased number of individual objects in the world. Normally, all objects of a given type are unioned into a single trimesh for a given tile. However, to have individual plants sway on their own, I had to not union objects in tiles that are swaying, which are those tiles closest to the user. This inability to union the models into a single trimesh was producing most of the performance hit associated with this feature. I have redone it now so that only objects of swaying types in the first place are broken down into individual objects for a tile, while any objects that cannot sway in the first place are still unioned. This helped a lot because tree trunks don't sway (at least I don't have them set that way at the present time), and it is also true that tree trunks, roots, and branches account for most of the geometric complexity of the forest. Smaller plants and the tree canopies are much sparser in most cases. The approach yields a performance hit of about 5% or less.

050118

I have been working with a horizon of 128 meters for quite a while now. This doesn't mean the world disappears at 128 meters because the background objects such as the sky and ground extend to the yon parameter of the camera. However, I use the a horizon parameter to govern how many tiles to submit. I only submit those tiles within a certain distance of the user and I have been using 128 meters. This is a very short distance and I am becoming sensitive to it. It is annoying to see tiles suddenly appear at a fairly close range, only 128 meters away.

The problem with extending the horizon, of course, is that the program slows down. There are multiple reasons for this. One is that there are simply more triangles that have to be rendered. However, another is that more objects are being submitted to the renderer. I have long known that this second variable has a strong effect on the framerate even though it doesn't necessarily affect the number of triangles in a scene. It was for this reason that I started unioning the plant objects in each tile quite a while ago. I had to undo this union recently in the closest tiles to allow the plants to sway independently in the wind, but I still leave this unioning turned on for most of the tiles.

Unioning the objects within each tile is not enough though once I start extending the horizon. The sheer number of tiles becomes so large that even if each tile unions within itself, there are still too many objects in the world. I have had the idea of unioning groups of tiles together for quite some time now, but have never made any attempt toward its implementation. I have no run out of options and have had to try this approach. Last night and this morning I got most of the basic code laid out for union the plants of multiple tiles. For the time being I am only union tiles in blocks of four and I am not unioning the tile terrains at all. I hope that once this feature is up and running that I will get significant gains from it.

I implemented a basic tile-unioning routine. It only unions blocks of tiles 2x2 so far. I was shocked to discover that turning the new code on caused a significant slowdown to the framerate. However, upon closer inspection, I believe that the problem is in the code that searches for new active tiles. Active tiles are basically all tiles within the user's horizon. Unions make this a little more complicated because tiles that are unioned are not processed individually, so in one sense they are no longer active. Nevertheless, the general notion of active tiles is pretty basic. The challenge of finding new active tiles is a tricky problem, and I am pretty certain my union code is compounding that problem. I need to rethink the approach to finding new active tiles to see if I can come up with a more efficient method. Strictly speaking, I only need to check the neighbors of "frontier" tiles. Frontier tiles are presently active tiles that have at least one presently inactive neighbor. I need to check all inactive neighbors of frontier tiles to see if they should become active. The problem is that it is hard to know which tiles are frontier tiles to begin with. That is, in some sense, the original problem of finding new active tiles, although not identical.

050119

After initially coding up the tile-unioning last light I was disappointed. There appeared to be no performance increase at all. However, that was working on my Pismo at home. The theory behind unioning the tiles is that the renderer is slowed down by having numerous objects. In theory, given two worlds containing identical geometry, but where the geoemetry is in fewer total objects in one world than in the other, that world should render faster. I was not seeing this on my Pismo last night. It was possible that the nonrendering aspect of the program was running slower than the renderer could take data, which means any optimizations I implemented for the renderer would be fruitless. I decided that before writing off tile-unioning all together I would first test it on my G5 as well. My hunch seems to have been justified because I am seeing significant gains from tile-unioning on the G5, which suggests the G5 is doing its nonrendering processing fast enough that the renderer is slowing the program down by taking numerous objects. By submitting fewer objects I am therefore getting a postive result. Phew! Furthermore, I made a change to the code that is not directly related to tile-unioning. As said in my last entry, I converted the active tile maintainance to a frontier based system. While being theoretically more efficient, this approach requires considerable overhead to manage. I was unsure whether the result would be positive or negative. As it turns out, the old active tile maintanance method appears to have been one of the major bottlenecks of the program. In my new system it accounts for a signficantly decreased proportion of the computation the program is performing. Wonderful.

I have had another nice idea. There is no reason to perform active tile maintanance whenever the user is standing still, or even when the user is rotating or looking around, but not moving across the world. Therefore, I have put in a conditional that only performs maintanance when the user is moving. This won't help the general play of the program since the user has to be able to move with decent performance and probably spends most of his or her interesting time moving actually, but it will make things look "prettier" when the user stands still for a while.

Last night, while lying in bed, I think I finally hit on some really good story/game material. I have ditched the crazy archeologist idea now. I didn't like it anyway, it just gave me an excuse to have the wacko guy leaving puzzles around because he was paranoid in his schizophrenia and wanted to hide things so they couldn't be found. Whatever, screw it. Here's the new idea.

The user arrives to discover the archeological team missing. I know it's a little cliche, but it's pretty good and makes for a good mystery. The truth that the user must figure out is that the entire archeological site is a complex gateway to space. I know it sounds like some other things, but it's good stuff, really. Here's how it works. Several pyramids around the site have a puzzle. I think it will be placing the color/direction stones on a table. When all such pyramids are properly set, a primary location in the site will turn on and present a lightbeam that the user can ride to the stars at the end of the game. I didn't want too much magic or strange mysticism in the game, but I'm reconsidering a little bit now.

This idea has many nice features. It explains the mystery for one thing. The reason the archeologist and his team are missing is that they left on the lightbeam too. In fact, I can tie it in with Mayan history and say it is connected to the Mayan collapse. A few Mayans saw their fate coming and built the site to travel to a new home. I also like it because the solution to the mystery isn't violent. The team isn't missing because they were killed or went crazy and killed each other or anything like that. This idea as even more merits though. Since the main idea is traveling into space, it thematically ties into the Mayan obsession with astronomy which I was planning on putting in the game in the first place in the form of sun alignment puzzles and such. Also, this gives the game just the right amount of cohesiveness without too much repetition because each pyramid must be solved independently, but their puzzles' structure and solutions are all similar. It also gives the user a hierarchy of importance to the puzzles. Some puzzles help find the colored stones for the pyramids, some help find the pyramid alters where the stones must be placed, and the grand puzzle is to activate the lightbeam and end the game. I like it. I'll have to see how it works out.

Puzzle idea. I already had the idea of watching sun alignments from one pyramid to another, or observing column alignments across the site. An addition to this idea is that the user must find a relic that is a vertical marker, some statue that is tall and thin. This relic must then be placed in one of several available holes at the siting location to correctly make the siting. Both finding the siting relic and learning the correct hole to put it in will be separate puzzles, aside from learning about the alignment in the first place.

I have implemented a second level of tile unioning. Anytime four unions exist in a block, they are merged into a single union. Unfortunately, this doesn't provide any noticable speedup. The reason is that I am presently only creating union unions, as I call them, along mod 4 boundaries, the same way I only create level one unions along mod 2 boundaries. Blocks of 4 unions falling perfectly onto a mod 4 area don't happen very often. I might try the second level union as a 2x1 union area instead of a 2x2 union area. I'm not sure yet. There's a good chance that there are only minimal gains to be had from this approach and that is isn't worth the trouble.

I have come up with a solution to a problem that has vexed me for some time now. The biggest textures in the world are those that go on the terrain tiles when the user is near those tiles. I have been assuming a highest res of 32 pixels per meter and my tiles are 32 meters square, so the highest res texture takes up 2 million bytes (at 16 bit color). Paging in the highest res and even the second highest res textures causes an intolerable hiccup. As a result I have been only using the texture resolutions from 2 through 5 (32 pixels per meter yields resolutions of 32, 16, 8, 4, 2, and 1). However, I think I will load in the higher res textures whenever the user stops moving for a brief time, half a second perhaps. The blur during moving doesn't require the higher res textures anyway. Having thought of this, I now think I have witness this or similar "smoothing" effects in other games, where the textures look worse during motion and then "clear up" after a moment whenever you stop the motion.

The high res texture approach mentioned above works beautifully. Rather than wait for some timeperiod without movement I simply designate any frame in which a movement command is issued as a frame that is off limits to high res textures.

After all of that I have made an observation that I have never noticed before. Paging the large textures into VRAM might not be the problem. The problem might simply be the time it takes to initially create the textures in RAM. The reason I suspect this is that any tile that has already generated its high res texture flows smoothly when I come back to it later. It is hard to tell what is going on here because the texture might still be left in VRAM, in which case the original problem could still be VRAM paging. I just can't tell with the present information. I will have to study it some.

Well, I dunno now. Tile unioning had clear payoffs on an empty landscape, but when the world is populated with objects the program doesn't do very well. I can hear the harddrive thrashing. I believe the require RAM to keep track of the union trimeshes is too much to handle. One thing I will have to do is create even lower res models of the plants in the forest.

050120

Since the tile-unioning isn't working quite as well as I hoped I have done two other things. First, I had the idea that there is no sense in submitting small objects in the distance. Previously, when a tile was active, all of its plant objects were submitted. The individual plants of each tile are unioned together, but the plants are all submitted. I have now put in a max visible distance for each plant type. If a tile is active, it only submits plant objects that are within their specified visible range. So I don't submit grass and shrubs in the distance for example. With my present settings this gives about a 1.5x framerate improvement. Not incredible, but definitely worth taking advantage of. The other thing I have done, to see if the slowdown is the number of objects or the geometric complexity of the models, is I have substituted a simple model (a single triangle) for every model type and observed how this performs in a thickly populated forest. I am getting huge speed increases from this, so while I have been concentrating on unioning objects recently, it looks like there is a lot to be gained by making my models simpler as well, so that is the other thing I am doing. I am going through all my plant models and paring them all down. I am also making more levels of resolution of the models. I have up to 8 for the terrain, although I am only using 6 presently to keep it in agreement with the 6 terrain texture levels from pow(2,0) to pow(2,5). I only had three levels for the models however and I am adding a fourth now.

050121

I have spent almost two solid days on the plant models. I have tried to minimize the complexity of the existing resolution levels while adding a new extremely low level to be used in the distance. The speedup it offered was noticable, but not incredible, about 20%. However, the present settings make the forest look terrible. I need to step the resolution up. Hopefully this can be done only on the texture resolution without doing the same on the vertex complexity. I need to try that to see what effect it will have.

I really wish I could move on to other parts of the project, but if the forest isn't working right, which means looking good while running fast, then the entire project is worthless. I have to get this working properly.

There is a solution I can always fall back on. I am trying to make things work with a really distant horizon. I can always be more conservative with that expectation, shorten the horizon and the fog distance, and let the game work that way. That is how many other games work and I am starting to understand why.

050123

I have put a fog effect into the game for the purpose of clipping objects from the world. I didnt want to, but I don't think I have any choice at this point. Things do seem to be working relatively nicely now. I am getting decent, although not spectacular, framerates. I might try to use the tile unioning in conjunction with the fog to see what sort of an effect I can get.

I have added stars to the game, real stars. I downloaded a star catalog of the 9000 brightest stars in the sky and made the game read the catalog add any proportion of stars I want down to some specified magnitude. It looks pretty good. I should try to put a cloudy Milky Way in, but that will be hard since it would be an alpha texture and alpha textures don't get along very well with Quesa fog. I am using alpha textures in the game, but only on objects that I keep in front of the fog. The Milky Way wouldn't work that way.

050124

I have a pretty good Milky Way in the program now. The night sky now looks spectacular.

I am trying to get the main flow of the game figured out. I am trying to construct the puzzles and the sequence of events for the user by working mostly backwards from the end of the game. There are tasks that must be accomplished, and in order to accomplish them, prior tasks must be accomplished. By doing it this way I hope I can build that whole game back from the end right to the moment when the player starts the game.

New puzzle: there will be a colorful mural somewhere. When viewed through a colored-filter crystal of some sort a hint will be visible.

050125

I have thought through the puzzles and the sequences of challenges a bit more. To turn on the light beam the user must place the colored direction stones on four alters at four pyramids. To find the colored stone pattern the user must find am mural that shows the pattern. I'm not sure where the mural will be yet, perhaps in the central pyramid where the light beam is. To find the colored stones the user must open vaults with combinations that correspond to 260 day, 365 day, long count, and lunar settings. These combinations are found on a jade mask, a codex, a vase, and a stela.

I'm not sure if I'm going to do the sun-sighting puzzle. I like it, but I'm worried about requiring the user to wait for sunrise at a particular location. I can still do the column XY cross-sighting puzzle though.

I have put in preliminary object collision so the user can't walk through trees. I think I'm going to leave collision detection off for other plants though, like large grasses and shrubs. This lets the user move around a little more easily. Only thick tree trunks will be impassable.

050126

I am laboriously modeling the main pyramids now. It is arduous work to say the least. I have put in basic floor routines that enable the user to climb up the pyramids and climb inside the pyramids and walk around in the rooms in the pyramids. As a first pass I would say it works pretty well actually.

050127

Last night I added texture painting to the TerrainExtrusionConverter2 program, which really should be renamed to something like WorldBuilder. I can now take a palette of 1-meter squared 32x32 textures and I can paint them any way I want onto the terrain and then save them for the game.

I'm trying to get the collision detection to work smoothly. When the user walks down a hallway they shouldn't "stick" to the walls when they glance them at an angle. Instead the user should slide along the wall. I almost have it working, but the nitty gritty details are hard to perfect.

050128

I have been arduously working on the pyramid models and the interior halls and rooms of the pyramids. In addition I have been slowly improving the collision detection so the user can't pass through walls while allowing the user to smoothly move down the hallways without sticking to the walls. It's tricky stuff.

050131

I have been mainly concentrating on the creation of the architectural models recently. There are several aspects of this. There is the creation of the vertex geometry for the "clean" building, as it would have appeared if it were maintained. There is the creation of textures for various parts of the building. There is the creation of the UV map for the vertices with respect to the textures. There is the overlaying of a dirt mound over much of the clean model. And finally, there is the simplification of the model for various distances from the user so that simpler models can be used when the building is far away from the user during the game.

So far, I have four main pyramids which will constitute the cardinal edges of the map where the color stones must be properly placed on an alter. Additionally, I have the beginnings of an observatory like the Caracol at Chichen Itza, and I also have a large quadrangular courtyard surrounded by a basic palace. None of these models are complete through all the stages mentioned above yet...and I need additional models too. Wow, this is a lot of work.

050201

Still working on models. Also made some improvements to collision detection and floor detection.

050203

I spent most of yesterday making images of the front panels of the 260-day puzzle. This puzzle consists of two wheels, or gears, that rotate against each other, 13x20. The only real "puzzle" is to find the right combination elsewhere in the game. I would like to make an interesting puzzle of operating the wheels as well, but I haven't thought of anything good yet. The images are beautiful though, gray stone with shiny gold hieroglyphs and numbers on them.

I also made some progress on one of the pyramids.

Today I have been working primarily on mouse interactions. The user should be able to steer the point of view with the mouse and perhaps move forward as well. I have also added a basic cursor that will show a hand or something similar floating in front of the user.

050204

I tried to design a boolean logic based puzzle, but it's too easy to solve presently. I'm working on it. I also had the idea of a puzzle where the user has to throw rocks into a pool of water to raise the level of the water. I'm not sure what this would accomplish though. Perhaps the water raises to a level where it flows out a shaft and has an effect somewhere else. I also had the idea of requiring the user to open a water flow on an aquaduct at the cenote and then run water to or from the various pyramids, but again, I'm not quite sure what this would be for.

Well, I made a boolean algebra puzzle that I rather liked. It isn't too easy and isn't too hard. However, I tested it out on a friend and while he was able to stumble on the solution after working long enough, he didn't seem to enjoy it very much. In fact he seemed to pretty much dislike it because he couldn't discern any pattern or rationale to the puzzle's behavior.

050207

Over the weekend I devised a rather different kind of puzzle from the ones I was working on last week. This puzzle, rather than being arbitrary, like some random logic puzzle implanted in the game, is woven into the setting more. The challenge was to make t he tzolkin calendar into an interesting puzzle instead of merely requiring the user to rotate it to a magic setting. When the calendar is properly aligned, the intention is to reveal either a set of color-direction stones, or an altar to place the stones on...or both. My new design makes the calendar wheels much more interesting to interact with by requiring various levers and other things to be set properly. I've already started coding it up. I have the wheels rotating in "notched" fashion so they always stop rotating at a notch-aligned rotation. I also have a locking lever that flips into and out of the wheels. I also have sliding bars that move out of the way to let the user into blocked off areas. It's all pretty bood actually.

I'm still working on the puzzle for the tzolkin calendar. Needs running water and all kind of fancy stuff.

050209

Yesterday I pretty much finished the first major pyramid puzzle, which consists of getting two sets of bars to lower into the floor, allowing passage to a room where the color-direction alter will be located that the user must place the color-direction stones on.

I have started working on the next pyramid puzzle. One of the four direction pyramids I designed does not have a building on top of it and I wasn't sure what to do with it. I have figured it out now. The top of that pyramid will be an elevator that can sink deep into the pyramid allowing the user to explore the interior. In order to lower elevator it must first be unlocked. A set of horizontal stone pillars will prevent the elevator from lowering until they are retracted. The key will be a stone or jade artifact. The key will be on one of the columns in a column complex, and the right column must be found by siting the column complex from two vantage poins, one of which will be on the pyramid in question. Right now, the column complex has 18x20 columns, 18 for the number of months in the Haab calendar and 20 for the number of day signs in the tzolkin calendar. Alternatively, this entire pyramid may be based on the Haab, similar to the way the first pyramid and its puzzle are exclusively tzolkin in nature. In that case the 18x20 is 28 Haab months and 20 Haab days per month.

Anyway, that's what I'm doing right now.

050210

Still working on the column complex and its association with pyramid 2.

Ooo, I just textured the columns and they look beautiful, especially in sunrise or sunset light. Fantastic!

050211

I've been working on the second pyramid. It has a cool elevator that lowers the user deep into the pyramid. There is also a secret room under the elevator. I haven't decided yet how to hint that there is something interesting under the elevator. I have also made the sighting column that will go on top of the pyramid, looking down at the column complex. It has a hole cut through it. When the user looks through it, he will see the column complex, but only one particular row will be lined up with the sighting hole.

I'm thinking about the main structure of the game some. The user needs to find color-direction stones and place them on altars at each pyramid. I was thinking of having the stones located at the pyramids, but now I think they will be located in the central pyramid. The user will have to go to each pyramid, explore it, and find some kind of key or combination that he will take back to the central pyramid to gain access to one set of stones, which he will then take back to the direction pyramids to place on the altars. I'm not sure what the hints will be though. I think I should associate each cardinal pyramid with a direction and the corresponding direction sign and color, but I'm not sure how to use that quite yet.

050214

Things are slowing down a little bit. I have other projects I need to work on, such as my Ph.D. Additionally, the project is in a slow stretch right now because I am hindered by a lack of good puzzle designs. Recently, I have been creating the interior architecture of the pyramids, the hallways and rooms. The design of these structures is intimately connected to the puzzle designs since many puzzles consist of gaining access to various areas within the pyramids. As a result, I am a little stuck right now. I need a variety of puzzles which block and then reveal access to physical areas that contain altars and things like that. I am also trying to design the puzzle that will reveal the color-direction stones. What are the hints, what are the crucial pieces of information (combinations for combination locks, or something along those lines), and what is the physical structure of the container where the color-direction stones are obtained? These problems are holding up any significant progress. Meanwhile, there are a number of important issues that I can work on that do not pertain to the forward progress of the game plot. For example, right now I am not optimizing the pyramid rendering very much. I don't have low-res versions of the pyramid vertex geometry, and I only have an inkling of code that enables or disables rendering of structures that are necessary only under limited circumstances. For example, when outside a pyramid there is no need to render the complex architecture of the pyramid interior. Likewise, when inside a pyramid, the outer pyramid structure, as well as the entire forest and the terrain can all be ignored as far as rendering is concerned. This optimization feature would greatly speed up the game and needs to be done eventually.

050217

I've been making some progress on a new puzzle. This one consists of a room inside a pyramid with a bunch of columns in it. Each column has a mirror on top of it that the user can adjust in azimuth and altitude. The columns are different heights and the user must adust mirrors so that a lightbeam bounces around the room and hits a secret door that looks just like a block of stone. The light beam makes the door move, revealing a secret tunnel. I am not sure if the light source will be sunlight (which would require the user to use this puzzle during certain times of day) or a fire.

050221

I am making steady but slow progress. Other priorities have taken over recently. However, I am still working on the game. In particular, I am creating the mirrors and lightbeam puzzle for the third pyramid. I have most of the code laid out. I just have to debug it at this point.

I let a friend experiment with the first pyramid's puzzle today and observed his experience. This allowed me to see several things that have not been a serious problem for me but which are detrimental for other people. The collision detection is unacceptable. It is way to easy to accidentally pass through walls and other objects. Also, the movement is very very fast and my friend could not control the character at all. I have a command in that makes the character move slowly when the control key is held down and very fast otherwise. My friend could not remember this however and kept flying out of control, and through walls no less. It was never my intention to have the character move as fast as it does right now. I have put that in mainly to help me move around the world quickly during debugging, but I must remember to slow it down before letting other people use it.

050224

Yes! I finally got the mirror room working perfectly. It is so cool to watch the beams reflect off the mirrors as I push the mirrors around. The tricky part will be making a decent user interface for them, probably a bunch of knobs and sliders or something like that.

I have done some fine tuning on the mirror puzzle and it looks great. I alpha-textured the light beams and they look beautiful. The challenge for me now is to design a layout of mirrors such that it is an interesting puzzle to get the beam to go where you want it. With all the mirrors all over the place, it's pretty easy to point it anywhere I want without much to stop me. One cool thing I have is that the mirrors are double sided. I will try to make the solution to the puzzle require bouncing the beam off both sides of a mirror.

So that's that. What's next, besides creating user interfaces for these things? Right now, the user interface is a bunch of key commands. The game must of course use mouse interaction with mechanical levers and stuff like that.

I also want to make some render optimization. When the player is inside the pyramids, nothing outside should be submitted, including the outer walls of the pyramid. Likewise, when the user is outside a pyramid, none of the complex interior should be submitted. I think I will do this by putting event points in the world. Whenever the user comes within a target radius of a event point, that point's action will be triggered, which could be to change which objects are submitted for example. Likewise, when the user is in a building, the external light shouldn't be turned on. It doesn't make any sense to have daylight moving across an interior room for example.

Alternatively, I have a lot of work left designing the game. There are a lot of puzzles that need to be made.

Wow, this is a lot of work.

050302

I have come up with a few ideas for puzzles. I'm not sure what I think of them yet. One of the pyramids has three rooms in it. I was thinking that the three rooms could have a puzzle similar to the one inside the clocktower in Myst. There would be three rotating dials in each room, and the three dials would always look identical in all three rooms (so there really is only one set of three dials, but it is duplicated per room). Any one room would rotate two of the dials. The trick is to get the dials set to a particular configuration. I'm not sure if this is fun, or merely irritating.

Another puzzle builds on an idea I had a long time ago. I thought it would be cool to have the user throw stones into a pool to raise the water level, but I could never fully develop the puzzle. The idea I have now is that a machine raises and lowers pillars into a pool. The pillars are different sizes so they can affect the water level in different ways. A balance will be set up such that it hinges vertically against a wall with its opposite end floating in the pool. The user must make the floating end rise to just the right height (not too high) to even the balance. I'm not sure what else is involved yet. I imagine the balance is a groove with a ball rolling back and forth in it. When the ball is in the right position on the balance, it could fall through a hole, or something like that.

I finished Myst III, Exile, the other night. It had a bunch of interesting puzzles. Most are of the "supply power to a machine" type or of the "enter a combination to allow access to a new part of the world" type.

I have a lot of work to do on nonpuzzle problems too. The collision detection needs a lot of improvement and I need to create event points for changing the way the program works when the user is in various locations.

050403

The project is waning again. There are number of reasons. The most serious is that I don't have a really good set of puzzles to incorporate into the game. In addition, working on the game was taking a lot of time and I'm busy with other things right now. I really hope I come back to it at some point. It is so visually beautiful, I would hate to abandon it completely. Time will tell.

050603

No progress of late. Just thought I would put a quick entry in the diary since it crossed my mind recently. I am considering putting the "game" aspects on hold and reviving the "simulation" aspects. I might try to put in a few animals, mostly birds, and I might put in ambient sounds, like leaves, wind, water, birds, thunder, rain, etc. I am not sure if I will do any of this anytime soon however.

051103

I haven't done anything with the game in a long time. Today I am cleaning up some of the user interface key commands so I can write a simple documentation file that states what commands are available to the user. This is in anticipation of putting a webpage up about the program on my website so I can show off what I have accomplished during this project, afterwhich I intend to call the project "indefinitely suspended".

051105

In attempting to create scenes that would be used for screenshots for the final webpage, I discovered I had a little bit of work left to do on the program. In particular, I really wanted to let plants grow up the sides of, and on top of, the pyramids. This required finding the highest external face of a pyramid at a particular XZ coordinate within the pyramid's footprint so as to assign that face's height as the "ground" height for that XZ location. This is necessary so plants that reside within the pyramid's footprint can be lifted up above the actual terrain height, up to the pyramid's height at that location. Got this working today, took the screenshots, and got most of the webpage put together.

I'm a little sad. Running the program again today, for the first time in several months, I am reminded of how beautiful it is and how much I wanted it to pan out into a successful, completed, end-result. Oh well.