The three most engaging parts of The Oregon Trail – the travel screen, crossing rivers, and hunting – were covered in detail in the previous three chapters. However, there were many other aspects of the product that required our attention during the reality phase of the project. Some of these aspects included:
Below are some of the details for each of these aspects of the product.
A famous (or notorious) aspect of the 1985 game was our inclusion of tombstones. This was a new feature, not present in earlier versions of the game. Tombstones play a relatively minor role in the game, yet they are one of the best-known memes from the product. (For more details on the famous Oregon Trail memes, see Appendix 1.) However, the tombstones were a late addition to the design. For the first half of the project, this feature was not part of the project plan, nor had we even discussed the idea.
So what exactly was this feature, and how did it get into the product?
On the real Oregon Trail, there were a great number of deaths. By far the main cause of death was disease, but accidents also led to many deaths – such as drowning during river crossings. In the contemporary diaries, overlanders sometimes mentioned passing grave sites. Therefore someone on our team – probably Shirley – raised the question of whether this concept could play a role in the design.
I certainly liked the idea that the game would mention grave sites, but I assumed that we would incorporate the concept into one of the modules that we were already building. For example, in the random events engine, one of the events could be that you pass a site with many graves. However, I quickly realized that this would be a weak random event, because it would have no effect on any of the variables in the model. (All of the other random events affect at least one variable – supplies, health, speed, etc.) So my alternative suggestion was to incorporate the concept into the conversation system. If you stopped to talk to people, then in one of the conversations someone would mention having passed many grave sites. We did in fact do this, but the question remained as to whether we could take the concept a step further.
Someone on the team – possibly me, but more likely John or Charolyn – soon came up with an alternative approach. What if, after your entire party died, you could create a gravestone for yourself? The text that you put on the stone could be saved in a tiny text file on the disk. Then, the next time you played and you passed this same location, the program would show you the tombstone. Or better yet, what if we stored up to 10 tombstones on the disk instead of just one? The text file would still be quite small, not big enough to cause a problem.
I gave this idea serious consideration. The inclusion of tombstones would indeed add another feature of interest to the gameplay – and it would inject a light note to counterbalance the disappointment of failing to make it to Oregon. In the home market, where you may be the only person using the disk, it would remind you as you passed the point where you died on a previous play of the game. In other words, it would remind you that you are doing better this time around. In the school market, it might be funny and interesting to see where another player had died. But it would also be a reminder of one of the realities of the Oregon Trail – that many people died along the way. (NOTE: Most of the real grave sites would have had simple markers, not permanent gravestones like those in a modern cemetery.)
However, I soon realized that saving 10 gravestones would not be good for the gameplay. It would interrupt the game too much if 10 gravestones popped up at different points in a single game. Therefore I rejected the idea of including 10 gravestones, but after verifying with John the technical feasibility of the idea – and that he was okay with adding this feature – I approved the inclusion of two gravestones (one on each side of the floppy disk) as a new feature. There would be two separate interfaces – one for creating a tombstone after your entire party died, and another interface to show the gravestone when you passed it in a later game. The latest gravestone would always replace any existing gravestone on the current side of the disk.
Part of the concept was that the player could write a short epitaph – up to 29 characters total – which would appear on the gravestone. Each gravestone would include the player’s first name and the epitaph. The interface we built consists of three short steps. When the player’s character dies – as the last surviving member of his wagon party – a tombstone automatically appears, bearing the player’s first name. (Remember, the player enters his name at the beginning of the game, so the program already knows this information.) The player is asked if he would like to write an epitaph:
If the player says no, then the tombstone is saved to the disk without an epitaph, and the program exits the tombstone sequence. But if the player says yes, then he is allowed to type up to 29 characters using the Apple II keyboard.
After the player presses the Return key, he is given a chance to see the epitaph and to verify that he likes it:
In a later game, when someone passes by the point where you created the tombstone, the player is given the option of viewing the gravesite:
If you choose to view the gravesite, then you see the most recent tombstone that was stored on that side of the disk:
When we did the user tests of the pre-release product, the gravestone feature proved to be quite popular and memorable – and it certainly provoked discussion. So we concluded that this was a good feature, and we decided to keep it. But it was not long before we received an urgent communication from a teacher whose class had been testing a beta version of the game. She complained that this pre-release version of The Oregon Trail contained an obscenity. She conjectured that someone on our staff, during testing, had saved a gravestone containing the obscenity, and that this goof had gotten included in the copy of the disk that we sent to her.
We immediately checked our master copy, and we checked the other duplicated disks that were ready for testing. None of the disks contained an obscenity on the gravestone. In fact, none of them had a gravestone at all, because no one had “died” on those copies of the disk. (On a fresh copy of the product, no tombstones have yet been generated, and no default tombstones are included in the product.) So I called the teacher back and told her that one of her own students had undoubtedly typed the obscenity. She found this very hard to believe – her students would never do such a thing!
This incident made it obvious that we had a problem. However, it was not clear how best to solve the problem. Should we build an anti-obscenity filter that prevented kids from typing an obscenity into the input field? We considered this idea, but decided that it would be too easy (and perhaps too tempting) to defeat the filter by the use of creative spelling or foreign languages. Should we remove the gravestone feature entirely? We considered this idea too, but the feature had been a big hit during testing – so it would be a shame to remove it. Ultimately, we settled on a compromise: We kept the feature, but we added a third interface related to the tombstone. In the “Management Options” (accessible from the main menu by typing Ctrl-A), the teacher or any other user could simply erase the current tombstones. This new feature was included before we released version 1.0 of the product to the general market.
The screen below shows the full list of Management Options. Notice that option #4 allows you to erase the tombstones:
After the product was released, some teachers faced a problem that was similar to the tombstone problem. Sometimes a student, upon successfully completing the game, would enter an obscenity instead of his name on the high score list. However, all versions of the product – from the alpha version onward – included a feature that allows a teacher (or anyone else) to reset the high score list to its original state. (Notice option #3 in the Management Options above.) This allows teachers to deal with inappropriate entries in the high-score list – but only by using a sledgehammer, not a scalpel. In other words, you cannot remove a single name from the list – your only choice is to start the list over.
The biggest problem with the Management Options is that most people don’t realize that they exist. In the Apple II version of the product, we followed a MECC tradition of not listing the Management Options on the main menu. Instead, teachers and other users can access this hidden option by typing Control-A from the main menu, which is clearly explained in the teacher’s manual. Of course, this tradition did not make much sense in a home market product. Therefore, on some versions of The Oregon Trail, such as the IBM version, this option is explicitly listed on the main menu:
In recent times, if you download a copy of The Oregon Trail from the internet, then you may encounter the “peperony and chease” gravesite on your journey to Oregon. This tombstone message was not present on any of the disks that MECC distributed. However, many years later, someone posted a used copy of the disk on the internet for other people to download. The person who posted this copy did not reset the game to its original settings (using the Management Options). Since then, this copy of the disk has become widely distributed. Whoever Andy is, his creative spelling has achieved worldwide notoriety!
By the way, Andy’s epitaph was obviously inspired by the television ad for Tombstone pizza, where people are asked “What do you want on your tombstone?” Myself, I would have chosen "ham, mushrooms, and black olives" – a tasty combination that I can easily spell.
In designing the interactions at Matt’s General Store, I had several specific goals, each of which addressed features that were not present (or only partially present) in the original game:
Goal #1: Make the shopping experience as personal and real as possible.
In the original OREGON, before leaving Independence, the player simply types how much he wants to spend on each category of supplies. But in our design for The Oregon Trail, we provided a context for the experience. You (the player) enter a shop – Matt’s General Store – where a friendly proprietor assists you in making your purchases, providing helpful advice at each step of the process.
Goal #2: Get the player to think about actual quantities.
In the original OREGON, everything except for bullets was expressed in terms of dollars only. You could buy $100 worth of food, but you had no idea how much food this actually was – for example, how many pounds. You could buy $100 worth of clothing, but you had no idea what articles of clothing you were buying, or how many items you were buying. The original game required you to spend between $200 and $300 on oxen, but you never knew how many oxen you had actually purchased. And “miscellaneous supplies” – which represented both medicine and spare parts – was the vaguest of all. These design limitations were perfectly fine for a simple timeshare game designed in the early 1970s. But in a more complex game designed for a personal computer in 1985, I felt that I needed to go beyond these limitations.
And so, instead of asking the player how many dollars to spend on oxen, I ask the player to specify how many oxen to purchase. Because the oxen were yoked to the wagon in pairs, I worded the question this way:
This wording turned the question into a bit of a math problem. The player has to think to make the purchases. In our testing with kids, most players actually enjoyed these mental challenges.
The interaction regarding clothing was a bit trickier to design. I wanted the player to think in quantities – but quantities of what? If I itemized all the different types of clothing, and asked the player to specify a quantity for each, then the interaction would be pointlessly complex. Furthermore, I would have to include gender in the purchase interactions, distinguishing between men’s clothing and women’s clothing. I finally came up with the idea of itemizing the clothing in terms of “outfits”, as in “How many outfits would you like to buy?” But this wording did not test well with the kids, so eventually I changed “outfits” to “sets of clothes”:
Again the question became a math problem. If you need at least two sets of clothing per person, and there are five people in your party, then how many should you get? And should you go beyond the minimum and get a bit more?
Goal #3: Provide some details on what is actually being purchased.
The graphics associated with each purchase provide some concrete examples of what you are buying. But in the case of food, I wanted to provide additional historical context by actually naming the most common types of food that were purchased – even though I don’t require the player to purchase each type of food separately:
With the spare parts, I went a step farther. In this case, I do require that the player purchase each type of spare part separately, and the game tracks the quantity of each:
Goal #4: Allow the player to purchase the various items in any order, and to change his mind about the quantity of any item.
Achieving this objective was a bit tricky. In today’s user interface design, we take such flexibility for granted. But back in 1984, designing for an Apple II (which had no mouse or touch screen), such flexibility was rare. I tried several different approaches before settling on what became the final design. Consider the following screen, about halfway through the purchasing process:
So far, the player has purchased oxen, food, and clothing. Or more accurately, the player has indicated an intention to buy these items, but has not actually made the purchase yet. In today’s world, we would say the player has put oxen, food, and clothing in the shopping cart, but has not yet checked out. Note that the player has chosen to purchase the items in a 1-2-3 sequence, but he was not forced to do so.
Now, the player must decide what to do next. If he types “4” or “5”, then he will add ammunition or spare parts to the items to be purchased. But if he types “1”, “2”, or “3”, then he will be able to change his mind about the quantity of oxen, food, or clothing. When the player is satisfied that he has everything he wants or needs, then he presses the Space Bar to finalize the purchase and leave the store.
Even as I was designing The Oregon Trail, I was working on a new and improved set of standard conventions for handling menu interactions in MECC products – a method that does not involve typing numbers to select a menu option. Unfortunately, we were not able to retrofit The Oregon Trail with the new conventions, but I was able to include the new conventions in Word Munchers, which I was designing at the same time.
Goal #5: Enforce limits in a clear but friendly manner.
There are several limits that the player must observe when making purchases at Matt’s Store – such as not spending more money than you actually have. The game also places limits on how much food that your wagon can carry, and on how many spare parts will fit into the wagon.
In the original OREGON, you could stop at any fort to purchase any of the five categories of supplies – although you couldn’t buy more oxen:
The forts were never identified, but a fort would be available every second turn (which translated to one every four weeks), regardless of how much territory you had covered. The prices at all of the forts were identical, but the prices were 50% higher than at the starting point in Independence. This was handled in a rather odd way. At any fort, for every $30 you spent on supplies, your supplies would only increase by $20. However, you would not see your current supply levels until two weeks after you make the purchases – and so the price discrepancy is very easy to miss.
In my design for The Oregon Trail, the forts are in their actual historical locations, with their actual names and the correct distances between them. Therefore the amount of time it takes to reach any particular fort depends upon how fast your party is traveling. But the big question for me was how to handle the goods for sale at each fort. Should the forts differ in what was available for sale? Will there be times when a particular kind of supply is unavailable? How should I handle the prices?
As I did my historical research, it appeared that the same broad categories of goods were available at every fort – food, clothing, guns and ammunition, livestock, etc. So in my design, I did not differentiate between the forts as to what was available. But unlike the original game, my design allows the player to purchase additional oxen at forts. In the original, if one or more of your oxen goes lame, then it slows you down for the rest of the trip, and there is absolutely nothing that you can do about it – which is rather frustrating. In my new design, an ox can become sick or injured, or it could even die – but you can buy additional oxen along the route. Another strategy that my design allows is to buy extra oxen while you are still in Independence – so you are already covered in case one gets sick or dies.
My research indicated that the prices at the forts were highly variable over time, but that the general trend was for increasingly higher prices the farther west you went. I definitely wanted to simulate this feature of gradually increasing prices. My only indecision was whether to layer a random fluctuation over this pattern. I finally decided to go for simplicity, without the fluctuation, because this allows the player to better notice the increasing prices. As the player goes westward, the prices are consistently higher at each fort than at the previous fort.
Here are the prices I used for Fort Kearney, which are 25% higher than the prices I used for Independence, Missouri:
At each fort, I add another 25%, compared to the starting point of the trail. By the time you reach Fort Walla Walla, which is the last fort, prices are twice as high as at Fort Kearney:
From the research that Shirley and I did, it was clear that the concept of “cut-offs” (shortcuts) was a hotly debated topic on the Oregon Trail. Because the journey was so long and so difficult, some people were eager to believe rumors of new shortcuts that would save days or even weeks of time. Another strong motivation was to bypass a difficult stretch of trail. Most of these rumored shortcuts turned out to be worthless, even disastrous – but a few of them became viable alternatives to the original route. Any alternative route would have advantages and disadvantages compared to the original route.
Because these potential cut-offs – both the valid shortcuts and the false rumors – were a key part of the Oregon Trail experience, I wanted to include a few in my new design. This concept was not present in the earlier versions of OREGON, so I had to figure out which cut-offs to include and how to incorporate them into the game.
At first I explored the idea that a rumored cut-off might turn out to be effectively a dead end. In other words, after 10 or 20 miles the cut-off becomes too rugged for a wagon to travel. In such case the wagon would have to turn around and go back to return to the main trail. This was a genuine risk when following a supposed cut-off. As much as I liked this idea, there were some serious problems with implementing this idea, given the constraints on the product. So I finally limited the idea to three genuinely viable cut-offs – 1) the Sublette Cutoff, which bypasses Fort Bridger, 2) the cutoff to bypass Fort Walla Walla, and 3) the Barlow Toll Road, to bypass the Columbia River gorge. In each case, when the player reaches the fork, he must choose whether to take the cut-off or the original route. (The Sublette Cutoff was included as part of my original list of landmarks in October 1984. The other two cutoffs were added later.)
The first two cutoffs are fairly straightforward. In both cases, if the player is willing to by-pass a particular fort, thereby missing the opportunity to purchase goods there, then a few days can be saved by taking the cutoff. But the Barlow Road represented a more complicated idea. In the early years of the Oregon Trail, the trail ended before crossing the Cascade Mountains, about a hundred miles before the final destination. Until the Barlow Road was built, there was no trail over the Cascades that could be navigated by wagons. The only option in 1845 (and earlier years) was to build a raft and float it down the Columbia River in a perilous water journey. But in 1846 the Barlow Road opened, providing a safer alternative. That’s not to say that it was an easy road, but at least it was a road. The main drawback, besides the difficulty of the road, was that you had to pay a toll. If you could not or would not pay the toll, then you had to float down the river to the Willamette Valley.
All of this seemed to me to be essential material to include in the game, one way or another – even though none of it was included in earlier versions of the product.
Throughout much of the project, I intended to do something special with this last segment of the trail, regardless of whether the player chose the rafting trip or the Barlow Road. There would be a special game for rafting the Columbia River, and a special game for taking the Barlow Toll Road. But as the costs for the product mounted, and the timeline began to stretch out, I reluctantly discarded the idea of designing and building two new special modules. Instead, I decided to treat this cutoff in the same way that I treated the other cutoffs. Regardless of which fork you took, you would experience this last segment by means of the standard travel screen. But if you chose to raft the wagon, then the little animation on the travel screen would have to be different. Instead of an ox pulling the wagon, the animation would need to show a wagon floating down a river on a raft. But this idea had its own problems – as discussed in Chapter 17: “Restoring Abandoned Features”.
In the initial framework documents that I created in October 1984, I laid out a model where the journey to Oregon would consist of 16 segments, each ending at an important or well-known landmark. Some of the landmarks would be river crossings. Some of the landmarks would be forts, where additional goods could be purchased. Most of the remaining landmarks would be natural geographical features, such as Chimney Rock.
This aspect of the game design held up quite well throughout the 10-month project. The finished product did indeed provide a journey of 16 segments to get from Independence, Missouri to Willamette Valley in Oregon – or 15 segments if you bypassed Fort Walla Walla. However, because the final design includes three places where the trail forks – and the player chooses which route to take – the product actually includes 18 landmarks and 20 distinct segments, as summarized in the following table:
|Miles||Starting Landmark||Ending Landmark||Notes About Ending Landmark|
|102||Independence||Kansas River Crossing||Ferry available at this crossing|
|83||Kansas River Crosing||Big Blue River Crossing||No ferry available|
|119||Big Blue River Crossing||Fort Kearney||US government operated fort|
|250||Fort Kearney||Chimney Rock||The most famous landmark|
|86||Chimney Rock||Fort Laramie||Privately operated trading post|
|190||Fort Laramie||Independence Rock||Famous landmark|
|102||Independence Rock||South Pass||Rocky Mountains pass|
|125||South Pass||Fort Bridger||Privately operated trading post|
|57||South Pass||Green River Crossing||Shorter route bypasses Fort Bridger|
|162||Fort Bridger||Soda Springs||Famous landmark|
|144||Green River Crossing||Soda Springs||Shorter route to Soda Springs|
|57||Soda Springs||Fort Hall||Privately operated trading post|
|182||Fort Hall||Snake River Crossing||Indian guides are available for hire|
|114||Snake River Crossing||Fort Boise||Privately operated trading post|
|160||Fort Boise||Blue Mountains||Located in eastern Oregon|
|125||Blue Mountains||The Dalles||Shortcut bypasses Fort Walla Walla|
|55||Blue Mountains||Fort Walla Walla||Privately operated trading post|
|120||Fort Walla Walla||The Dalles||Two ways to finish from here|
|100||The Dalles||Willamette Valley||By taking the Barlow Toll Road|
|100||The Dalles||Willamette Valley||By rafting down the Columbia River|
This final list is quite similar to the tentative list in my original framework documents. Fourteen of the locations on my original list are still present in the final list. I dropped two landmarks that were on my original list – Bear River Crossing and Whitman’s Mission – and I added Blue Mountains, Fort Walla Walla, and Green River Crossing. (The user will encounter the Green River Crossing only if he takes the Sublette Cutoff to bypass Fort Bridger.)
For more details on my original plans for Whitman’s Mission, see Chapter 9: “Concluding the Imagination Phase”.
The original OREGON on the timeshare system was a text game, and therefore the game did not include a map. When this version was ported to the Apple II in 1980, one of the few additions was to include a simple map. This map showed your current location, relative to the modern boundaries of the U.S. states. However, these boundaries did not exist at the time of the Oregon Trail. The geographic features that did exist, such as rivers and mountains, are not shown on the map:
In my first document for The Oregon Trail, in October 1984 – when I didn’t even have a design yet, but was simply sketching out a few concepts – I wrote the following note regarding the onscreen travel map:
As this note indicates, I considered the idea of including detail maps of sections of the trail, in addition to an overview map of the entire trail. Due to the limited disk space and the desire to keep the user interface simple, I eventually settled on the idea of a single map. This map needed to show not only the rivers and mountains, but it also needed to show the locations of all the landmarks. I wanted forts to stand out distinctly from all other landmarks, because of their importance in getting additional supplies. To distinguish all of these details, it would be necessary to include a map key, indicating the meaning of the various symbols.
All of this turned out to be quite a challenge on an Apple II, which only has 6 colors and a fairly low resolution. Even worse, on the Apple II there are serious limitations as to what colors can be placed next to each other. So we had to eliminate green and purple from the map, and limit ourselves to black, white, blue, and orange. Charolyn had to work very hard to create a map that met my specifications and could actually be used. We went through several iterations before we had a map that seemed to work.
There were two crucial map details that were particularly problematic – the trail itself and the player’s current location. If we drew the entire trail on the map (with or without the cutoffs), then we would have to include a symbol showing the player’s current location. We tried this approach, and the map seemed hopelessly cluttered. So then I tried the idea that the map would only draw a line for the portions of the trail that the player had already traveled. This should make it fairly easy for the user to identify his current location. But it also meant that the route would not be an inherent part of the map. Instead, John would have to write program code to draw lines on the map to show where the player had been – taking into account which cutoffs (if any) the player had taken. It was a bit of a pain to program, but John did it.
Now that the program dynamically showed the route that the player had taken, an issue arose about showing the map when the player was between landmarks. John argued, quite reasonably, that this would overcomplicate the programming. He preferred to draw a line that always ended at a landmark, without having to calculate the endpoint of an incomplete journey to the next landmark. However, I felt that the player should be able to see the map at any time, even between landmarks, and that the map should be accurate – so John eventually accommodated me and programmed this feature.
In the Alpha version of the product that we took to the user tests, the map looked like this:
The first issue that became obvious in the user testing is that several of the rivers that are featured in the river crossing activities are completely missing from the map – such as the Big Blue River and the Green River. Even the Missouri River is missing. Therefore I asked Charolyn to greatly increase the number of rivers shown on the map.
As the user tests progressed, I soon realized an even bigger problem – a great number of kids were completely baffled by this map. Many of them, when they looked at the map, had no idea where they were currently located. Even though the map key at the bottom right indicates that “Your route” is a black line, most kids did not pick up on this. The problem was especially severe if player had not yet traveled very far, as in the above example. And even in those rare cases where the kids noticed and understood the phrase “Your route”, they did not necessarily know where they had started and where they were now.
To fix this issue, I realized that I needed to explicitly identify the start and end points of the trail – without adding any more items to the map key. So, using a paint program, I experimented with different possibilities. Finally, I ended up with the following result, placing a star and a boxed label at either end of the route:
At the same time, I also inserted an extra pixel of space between all the letters in the map key, so that the key would be more readable and have fewer false colors.
Because of the inherently coarse nature of the Apple II graphics, I was never completely satisfied with how the map turned out. But we certainly accomplished my goals of showing the real geography of the time, with rivers, mountains, forts, and landmarks all appearing on the map. In hindsight, I wish I had done one thing differently. On the map, we use a black dot to indicate all landmarks other than forts and river crossings. We used an open rectangle to mark the forts, and therefore the forts are obvious. But even though you can see several rivers on the map, the locations of upcoming river crossings are not clear at all. So I wish that we had included a black “landmark” dot for each of the river crossings as well.
Creating acceptable graphics for the Apple II was more challenging than creating similar graphics for most other home computers available on the market in 1984. The reason is that the Apple II originally came out in 1977, while the other computers popular in 1984 had been designed much later, incorporating better graphics systems. In the original Apple II there were three display modes:
In addition to these three display modes, there was a limited ability to mix two modes. Specifically, in either lo-res mode or hi-res mode, you could switch the bottom 1/6 of the screen to text mode, thereby providing space for four lines of text.
An early update of the Apple II included a tweak that permitted hi-res mode to display in color, while still being compatible with the software already written for the Apple II. However, this was really just a hack, and the rules for displaying color in hi-res mode were truly bizarre:
The upshot is that the effective screen resolution – when viewing a “hi-res” screen on a color monitor – was really just 140 x 192, because every bit of data affected two consecutive pixels, not just one. It also meant that you could almost never place two colors (green, purple, blue, or orange) exactly side-by-side – which was a very serious limitation.
This bizarre system allowed for fairly compact graphic files. A full-screen hi-res graphic (with 6 colors) only required 8K of disk space. By comparison, a 4-color full-screen graphic on a competing brand of computer (with a slightly higher screen resolution of 320 x 200 pixels) required 16K of disk space, while a 16-color full-screen graphic would have required 32K of disk space. Considering that an Apple II floppy disk only held 140K, the compact graphic files were truly necessary.
The upshot of all this is that creating acceptable graphics for the Apple II was always a huge struggle. Whenever we ported a game (such as The Oregon Trail) to a different brand of computer (such as the Commodore 64 or the IBM), the graphics tended to look a lot smoother and cleaner on the other computer. On the flip side, the graphics systems on the other computers tended to have their own limitations and idiosyncrasies. Consequently, whenever MECC ported a product design to another computer, porting the graphics was usually the hardest part.
In the following screens, the Apple II version is on the left, and a ported version is on the right – such as IBM or Commodore 64. All of the ported versions are based on the same game design as the 1985 Apple II version – the same sequence of screens, the same underlying models, and so on. The main difference is that graphics are rendered somewhat differently. However, sometimes other subtle differences are visible.