Team Comment - Skills and Stat Gain - September 20, 2001
In today's comments, we would like to discuss an issue that has been a considerable point of contention for some time, and has recently leapt once again to the forefront of player discussion: Skill & Stat Gain. (Note: For the remainder of this essay, we will be using the word "skill" in reference to both stats and skills so we don't have to type skills/stats each time.)

First we'd like to outline where we feel Ultima Online stands right now in regard to skill gain, and the aspects of the system we'd most like to address. So, without further ado...

Skill gain in its current form

When many players think of skill gain, they think of the "power hour" system, which was designed with the intention of helping players gain stats and skills through normal game play. "Normal game play" is defined for these purposes as simply playing the game in whatever manner a player desires, without the intention of tailoring their actions for the purpose of maximizing skill gain (ie: an adventurer might be on a dungeon crawl using various adventuring related skills, or a craftsperson could be fulfilling an order for several pieces of armor).

Unfortunately, the power hour system has suffered a number of problematic side-effects, including:
  • Excessive power gaming potential
    While the power hour system does in fact improve the casual player's chances to gain skill during normal game play, it also creates an environment that is drastically easier for a hardcore player to take to an extreme, resulting in greatly shortened total time in maxing-out a character.
  • Only modest benefit to casual players
    Casual players do not necessarily play on a one-hour daily schedule (something the power hour system practically assumes). For example, many players play several hours at a time, but only one or two days per week, forcing them to cram all their skill gain game play into the first hour of each play session, and denying them the opportunity for significant skill gain at higher levels for the rest of the session.
  • Unintuitive for new players
    The power hour system is unfamiliar to most RPG gamers, and must be actively taught to new UO players in order for them to understand the unique on-again, off-again skill gain results they experience.
Desired elements for UO skill gain system
  • Gains through "normal" game play
    We feel that most gamers want to use most of their play time to do the things they enjoy in an RPG (adventuring alone or with friends, crafting items for sale to other players, etc), without having their game play dictated by the need to maximize skill gain. Players should be essentially guaranteed to gain some amount of skill during any casual play session, provided they use their skills in ways that are at least mildly challenging for their level of expertise.
  • Support for some power gaming
    Hardcore players should be able to take a newly created character to a "maxed-out" state in less real time than a casual player. The assumption here is that the majority of hardcore players feel cheated by a game if there is no measurable advantage to the extra time investment they make beyond that of a casual gamer. At the same time, it's important to see that hardcore players cannot max-out characters in an unreasonably short amount of time, since this can greatly cheapen (for all players) the feeling of accomplishment derived from developing a character.
  • Reasonably long total time investment to "max" a character
    In a persistent world RPG that aims to be easy to get into, but hard to master, we need to work to maintain the integrity of the "hard to master" element. Generally, this is accomplished by enabling players to quickly gain skill at the low end, and progressively increasing the time (sometimes expressed as "difficulty") required as skill levels increase. As mentioned earlier, this total time investment must not be excessively long for casual players, or excessively short for power gamers.
  • Actions performed to gain skill must be reasonably achievable at the player's current skill level
    In order to see that players can effectively gain skill through normal game play, we must ensure that the actions required to gain skill fit the skill level of the player (they should not have to gain skill through the repeated failure of a very difficult task, and they should not be able to easily gain skill through the repetition of overly easy tasks).
A Possible Solution:

Keep in mind that this is only a proposal at this time, and we're not locked into anything just yet! However, we believe that we can address the points listed above by proposing a modification of the current skill gain system. In essence, this modification would eliminate the need for "power hour" by providing opportunities for guaranteed skill gain during normal play.

We're calling this proposal the Guaranteed Gain System (GGS). The core of this system is the guarantee that if you play "normally", you will gain skill. As always, you can only gain skill when you successfully perform an action. The difference under the GGS system is that if you have not gained skill under the current use-based system after a certain time period, the system would recognize this and force a point of skill gain (point meaning a tenth of a point, as in moving from 70.1 to 70.2). The length of the time period, or timer, is based on the level of skill.

To ensure that this would not allow characters to become Grandmasters overnight, players with higher skill would be guaranteed fewer skill points over the same time period. This means it would still take longer to gain skill in the 90's then it did in the 10's or 50's (this is nothing new). The time periods between guaranteed skill gain are based on the server system clock, meaning that you wouldn't have to be logged in for your timers to refresh.

This does not mean that players would be unable to gain skill until the timer refreshes, because the GGS would not be replacing the current use-based system, but it would be implemented in addition to it. You would still be able to gain skill under the current use-based system, but the GGS would now keep track of how long it has been since you had gained a point of skill. If the time period had passed and you had not gained skill through the regular method, you would gain a point through the GGS. The use-based system, though, would not be restricted by time. Even if you had just gained a point through the GGS, the system would still check for skill gain under the use-based system, although admittedly it would still be incredibly difficult to gain skill in this way at the high end range.

The most noticeable difference from the current system is that skill gains in the 90's while playing normally would not only be possible, they would be guaranteed (provided you are performing your skill in or around your current skill level). For example, casting Magic Arrow with a magery skill of 90 would provide no chance whatsoever to gain skill in magery, even with GGS. You would need to cast higher level spells to see guaranteed skill gain. Similarly, crafting daggers with a blacksmithy of 80 would provide no chance to gain skill in blacksmithy. Skills that are not difficulty based, however, would always have a chance to gain.

When we compare this proposed system to the our desired elements for our skill system we find that they match up very well:
  • Gains through "normal" game play
    GGS is designed to see that players who use their skills when needed will gain skill from time to time, without being required to repeat actions for hours or monitor their play time to maximize skills.
  • Support for some power gaming
    With the retention of the use-based system as a backup to the GGS, power gamers would still have the opportunity to raise skill faster by using the skills more often, thus "maxing out" a character faster than through GGS alone.
  • Reasonably long total time investment to "max" a character
    This is harder to determine, and would require tweaking during the system's test phase. Certainly with the GGS, if not properly balanced, it may be possible to GM a character easily. We would balance the system as best we can to prevent this from happening.
  • Actions performed to gain skill must be reasonably achievable at the player's current skill level
    This is exactly in line with the first point. In a normal game play session, players will not be attempting to perform skills well outside their achievable area on a regular basis.
The advantages of this solution would be threefold. First, casual players would not need to learn about "power hour" and how to tailor their play style to conform to its schedule. Casual players would be able to remain casual, while power gamers would be able to continue to push the envelope in attempting to get the most gains possible. Second, players would not be limited to 1 hour a day for maximum gain. In fact, just playing the game would be the best way to not only maximize your skill gain, but your enjoyment as well. Third, there would be no bookkeeping, timing or memorization necessary to determine when your character was last on, whether he/she is currently in power hour or when your next power hour begins. While it might likely take longer to "max" out a character, we believe that this is in fact what a large portion of our player base in fact wants: a system that gives real value to having high skills, but still allows players to reach those high skills through playing the game normally.

We strongly believe that the Guaranteed Gain System would address the concerns we are reading on the current power hour system, and we invite you to read the In Concept section of the UO site here for more detail on the workings of the Guaranteed Gain System. Let us know what you think on the boards!

Tom "Evocare" Chilton, Lead Designer
Chris "Prophet" Lassonde, Lead Programmer
Ultima Online

Team Comment - Prophet Speaks on Veteran Rewards - May 4, 2001
Hail Citizens of Britannia,

As we begin public testing of veteran rewards, I believe this is a good time to stop for a bit and discuss it. If I’m correct, many of you are thinking, “What happened? Why was the system so late in the first place? Why is it so late coming back?” Well, I hope to answer many of those questions in the following paragraphs, as I explain the history of veteran rewards from the beginning to the present. I apologize in advance for the lengthy nature of this document, but as we all know, veteran rewards have been in development for a long time!

I want to preface that explanation with a very short account of my history here at Origin. I started working on UO in September of 2000 as a server programmer, dealing mostly with the back-end server systems of UO. Since then I have touched just about every section of code in one way or another, either through bug fixes or new content addition to all the various servers and both clients. My first encounter with veteran rewards was in November of 2000, so all my information from before that time has been re-constructed from conversations I’ve had with the various developers who have worked on veteran rewards.

“Ok, so what’s so special about veteran rewards and why is it so complicated? After all, you did the Christmas gifts without a problem!” Well, with veteran rewards, we are trying to distribute a limited amount of gifts by account over all shards rather than by the number of established characters per shard. There were several reasons for this - for one thing, storing extra data slows backups down and generally decreases the performance and lifetime of the server. As well, by distributing fewer gifts, we make them more intrinsically valuable to the players.

So everyone involved at the office decided that the idea of distributing gifts by account was great. Right from the start, two significant issues were recognized as problems that would have to be solved. The first was that shards had never talked to each other before - ever! So we were going to have to design and implement a method in which they could trade information, and have this system operate in real time. The second momentous task was the calculation of account age. As it stood, a shard knew how old any one character was, but did not know the amount of billed months an account had. That information was stored in a database deep in the heart of the operations group - a completely different team than the UO live group.

The task of getting the account age to the servers was given to the operations group, and the live team took up the task of getting the servers talking to each other. Development continued for a while as planned, and things appeared to be working out well. In the summer of 2000, problems surfaced in the account age determination method. The operations group suddenly discovered that the method they had designed was hindering operation of one of the back-end servers. They informed us that they would need to redesign their solution. In an effort to keep to the planned release date, it was decided to attempt to solve the account age problem from within the UO Live team. The UO team then started work on a completely different way of calculating the account age. The new method showed promise, and the shards were successfully talking to each other, so rewards were opened to the public for testing. This is about the time I came aboard. The programmer primarily responsible for veteran rewards was moving onto another project and they needed someone to maintain the system. I was given that responsibility.

During the initial testing phase, we received quite a bit of concerned player feedback, which convinced us to re-evaluate the rewards. We pulled rewards from testing and re-designed a number of the reward choices. By this time, veteran rewards was a few months behind schedule, and with factions on the way we were running out of resources to develop and test rewards. Factions were just about ready for launch, so a push was made to finish it. Development on rewards was frozen during this period.

Just before the Christmas holiday, we had a meeting on when we would launch rewards, detailing a plan that would launch the system without interfering with the final developments of Third Dawn. A major push was made to test the system and eliminate any bugs. It was launched on Sonoma, and a major problem was found and fixed. We then proceeded to launch on the rest of the North American and European shards.

I should pause in the story to mention some of the flaws in the system that we only found later. The veteran reward system was initially designed as a simple data storage system. Over time, it has been modified to be specific to veteran rewards. During all these modifications, one of the primary design goals was to have multiple safeguards to prevent a player from ever losing a reward during a backup and not being credited for it. The failure here was that little was implemented to prevent people from getting more rewards than they were supposed to.

This is the point where things really went awry. First of all, the central data server was getting requests for account age and reward information over 200 times a second. The problem was that each of the calls took half a second to compute. In other words, every 60 seconds the server was getting 100 seconds worth of work to do. This meant delays that quickly grew out of hand. People soon had to wait 5, 10, and even 15 minutes before they got to choose rewards. Then, to make matters worse, the server system would run out of memory at times, after which it would halt all work and try to reclaim that memory. This reclaiming period took approximately half an hour. Of course, during this 30 minute period, requests for information kept piling up, making the delays even longer.

So our first pressing issue was that it was taking over 500 ms to calculate the account age of a player. This was aggravated by aggressive information polling on the shards that caused it to “hit” the data server more often than it really needed to. We immediately got to work to come up with solutions as fast as possible. Within a day, we had come up with stopgap solutions to both these problems, and by prime time the next day we were looking much better.

Things appeared to be working fine, except for a trickle of reports from the player base that people were getting extra rewards on the European shards. We quickly investigated these reports. Part of the veteran reward system gives us the ability to see who is taking what reward, and how many rewards any one account has taken. Our generated reports told us that everything was fine. Little did we know that the server was telling us this because of a flaw in the program that was corrupting the data. The next day, the trickle continued, so we looked a bit harder at our reports and checked the raw data. Eventually we found one possible loophole that could have caused a few extra rewards. This was immediately fixed. However, we still hadn’t found the more serious flaw mentioned above. In a few more days, the trickle had become a flood. I just couldn’t believe the server would be lying to me - all the tests we ran showed things were working just fine! At this point, we looked hard at the raw data and uncovered some striking discrepancies in it. It was then that we finally found the problem and pulled rewards.

We stepped back, took stock in what had led us to this point, and discussed what we could do to fix rewards. A fix was found for the flaw but no one wanted to re-launch the rewards system without putting it back on a test center. The problem at this point was that we didn’t have the resources to test rewards, as we were well into the alpha of Third Dawn. In order to keep from skipping around and dividing our focus, it was determined that all development had to be put on hold until after Third Dawn launched.

After the release of Third Dawn, we took another long look at the rewards system. What we found was that too much had been patched into the system since its original design, adding too many unknowns. It was determined that we would clean up the back-end system. Over time, what started as a clean-up and an attempt to add more fail safes turned into an almost complete re-write of the system. The new system makes sure players will always get their allotted number of rewards, no more, no less. We also added more tracking and logging information, and we should be much better equipped to analyze what’s going on in the future.

So that’s pretty much were we stand today. We hope that you will take the time and test our rewards on our test shards. The more people we have trying out the system, the more confident we will feel that we indeed have a stable and robust system.

Yours truly,
Christian “Prophet” Lassonde
Lead Programmer
Ultima Online