Main

June 24, 2008

SWG Dev Diary – Beast Masters in Game Update 5



24/06/08
Hello again! I'm Thomas "Hanse" Eidson and I've been working hard on Beast Master adjustments and a couple new pieces of content for them. I'll go through what all I've done the past few weeks, so you can get a good gist of what to expect with Update 5 for beasts.

In 2007, we finished our first incarnations of the profession expertise systems. The recent updates that we've performed were to improve those expertise systems. Luckily, the last expertise system added to the game was for Beast Masters, so it is very up-to-date. We felt that the expertise system for beasts is balanced and does not need tweaks in Update 5. This allowed us to focus on other areas of the beast master system for improvement.

I was chosen to work on the Beast Masters, due to my knowledge of their systems. I wrote the original framework that beasts use in the game. Many large additions for beasts were added (data storage, retrieval, initialization, combat movement, etc) instead of using the older pet system. To make systems such as those, you must have information on everything that the system must do. This gives me a unique insight into fixing issues with beasts.

The areas of the beast master system worked on were taken directly from player feedback. A few of those are:

Loyalty gain to become a best friend with a master is too slow.
Eggs and enzymes are not labeled adequately for finding them on the bazaar.
Beast reviving becomes interrupted by involuntary movement.
Beasts cannot be stuffed.
Beasts cannot be colorized.
Beast Empathy, an expertise that increases beast happiness, is not working.
Beast food must be used through the radial menu instead of simply double-clicking on it.
Beasts move slower while walking up slopes and run slower than they should.
Beast abilities are not evenly distributed across all beasts.
There are various other tweaks to the beast master system, but those are the primary issues we addressed in this update.

Loyalty Gain

When looking at loyalty gain, I felt that lowering the cap would effectively steal the sense of accomplishment of getting your beast to be your best friend. So, I approached the issue through the gain itself. On live, it is currently affected by a 25% bonus through happiness, if your beast's happiness is maximized. This is actually rounded down to 20%, since the gain is small. I doubled the gain to a 50% bonus in Update 5, although we raised the cap on happiness from 25% to 50%.

So, at maximum happiness, you can double your loyalty gain in Update 5 (200% instead of 20% - you gain twice as fast at maximum).

Eggs and Enzymes

With eggs and enzymes, I followed the player advice on the forums and renamed them to display specific information in their title (a couple examples: "bageraset egg" and "red isomerase enzyme"). This information is updated on eggs and enzymes, if they are not in the bazaar when the update goes live. So, you may need to pull your current sales and resell your eggs and enzymes, but finding these objects on the bazaar will be much easier now.

Reviving a Beast

Supposedly, coughing and other emotes can stop the countdown timer for reviving a beast. My solution was to simply remove the restriction on no movement during the revival process of a beast. It will still check distance from the beast corpse and damage will interrupt it, of course.

Stuffing Beasts

With the addition of the beast master system, we allowed folks to convert their old pets to the new system as well as stuff them. The current beast master system does not have the ability to stuff beasts. So, I added a new option on the beast control device to stuff your beast.

It is a one-way transaction, so it will ask you to confirm the stuffing. Your beast's control device will be deleted and a platform will be placed in your inventory.

Once the platform is placed, the beast will appear with its correct size based on its level and coloring. You can rotate the platform and move it around and the beast will move with it. Although, you cannot raise and lower the platform and expect your beast to float off the floor.

Colorizing a Beast

Colorization of beasts is a request we've seen often. An armor colorization interface was made some time back that I wanted to use for a beast dye item. I spoke with Jaskell, as he'd used it before, and he filled me in on the details of how it works. The task turned out to be a large one, as I had to make it compatible with the incubator colorization and have both versions (incubator and beast dye) stored and retrievable from the beast control device.

The naming conventions for the palettes on all creatures vary, so I could not predict what those names were for accessing creature colors. In the end, the task took me twice as long as I expected it would. However, the end result looks very good…

Once I had a working beast dye item, I went ahead and put a new collection in the game. The design goal was to make the collection easy and repeatable, and the reward tradable.

Beast Happiness

After the colorization tool, beast happiness expertise needed to be looked at. To fix the problem, I found I would have to modify over 53 areas of the code that governs beasts. If ever a problem occurred with that system, the next person would have to modify 53 different places in code. Most of our skill bonus modifiers are added into code in one or two places. So, what should have been a five minute change and a few minutes of testing turned out to be three days worth of work. I had to consolidate all the happiness code and make sure the modifiers are centralized. The process for reworking code to make it simpler, efficient, and functional is called "refactoring". After refactoring happiness, the skill bonus modifier was added to one place in the code.

I never expected I would ever state the phrase "refactoring happiness".

Let's go ahead and look at how happiness works now. Here's a chart for the addition and subtraction of likes and dislikes along with all the other modifiers that affect it. The chart represents the new happiness system that is in Update 5. Five bonuses go towards the highest happiness value of 50. Without one of those bonuses, you cannot achieve the highest happiness. Only three dislikes are available, so the lowest happiness value is -25. Because the maximum happiness is 50, instead of 25, your beast will gain loyalty faster, gain experience faster, and do more damage in combat!

Beast Food

After beast happiness, I changed the beast food over to a different object type, which would allow it to be double-clicked for beast feeding. Before this change, feeding a beast required using a radial menu. With this change, food can be placed on your quick bar for efficient beast feeding.

Beast Movement

I scripted follow, stay, and attack movement for the beast master system. I spent a great deal of time testing and tweaking how beasts move. When I wrote the flow of how beasts move, I attempted to make them run when far away from their master and walk when the master only shuffled a couple steps away from them. Combat movement needs to know its target, follow that target at a run, and know to run to a new target if it is in multi-combat. Passive beasts need to follow their masters, instead of running off into combat. There were a lot of pieces that I needed to make sure were working. With all of this, I overlooked slope movement.

Slope movement was originally in the game to slow movement of anyone walking up a slope and allow faster movement down slopes. A skill bonus to move up slopes reduced this negative effect. At some point, slope movement was deemed to be something that isn't very fun, so now everyone has the skill bonus, except beasts. With Update 5, beasts gain slope movement and are able to run up and down hills at an improved pace.

Beast Abilities

Finally, I worked on special actions for beasts. I found that frogs, camels, and horses were all low on special actions. This would make some of the beasts in the game sub-par in combat.

Frogs were roughly ten attacks below the average amount of attacks that can be learned by other beasts. Non-beast frogs have a bite attack, so I added the bite line of attacks to frogs. Next, I added a new line of attacks called "Spit". A spit attack does damage and temporarily increases action costs for the target affected by its debuff. The debuff time does not increase with each spit level learned, but its damage does. This brought frogs in line with other beasts in the game. Also, chubas look like frogs, but for some reason were mis-categorized as wolves. I fixed chubas to use the frog category.

Next, I added the new spit line of attacks to camels. This brought camels up, but they were still missing five attacks. Horses were also missing five attacks, as well. So, I introduced a new line of attacks called "Kick". A kick attack does damage and stuns a target for one second. After adding in the kick line of attacks, camels and horses are brought up to the average 20 or so abilities.

So, there you have it! There are a few other details I left out, such as being able to call your beast while in combat, eggs on the Test Center frog for testing, and removal of the delay for storing a beast after combat. This dev diary contains a lot of information to digest. I hope you enjoyed reading about the beast update and I look forward to your comments!

Thomas "Hanse" Eidson
Star Wars Galaxies System Designer

November 09, 2007

SWG Gunships

2/16/2009: I wrote much of the original text for this article and it was later edited by our community folks.  The art team had these blueprints of the space ships, so I used them in the article to spice it up.  These three gunships were one of the more difficult publishes I did, due to no-one on the team having experience adding spaceships to the game.
 
 
A video of the Rebel gunship (my favorite) was put on youtube by Baconhead Ilthorian.
 
 
 
11/09/2007:
Friday Feature – Witness the Firepower -

Space-faring adventurers will have new ships at their disposal in Chapter 8! These gunships, loaded with firepower for supporting the Empire, the Rebel Alliance, or those wishing to remain out of the sight of both, are sure to appeal to all pilots.

Blacksun AEG-77 Vigo

The Black Sun's transports became a common sight in both the underworld and legitimate shipping with the advent of Xizor Transport Systems. This particular transport class became well known as lightly defended. Pirates from a variety of bands began picking off the freighters, particularly those smuggling illegal cargo for Black Sun.

Instead of dedicating fighters to escort transports carrying valuable cargo, Black Sun began modifying some of their transports to carry heavy firepower and act as escorts for the rest of the convoys. Named after Black Sun's lieutenants, the Vigo, this once-merchant class vessel has been elevated to the status of "gunship."

This gunship comes equipped with two forward mounted guns, four top mounted turrets, and two bottom mounted turrets. The gunship, originally a transport ship, is still large enough to hold a number of items and passengers inside.

Imperial Assault Gunship

Although this ship might look similar the Lambda-class shuttle at first glance, don't let appearances deceive you. The Galactic Empire uses the Imperial gunship in situations that call for aggressive firepower.

Two forward mounted guns, three forward mounted turrets, in addition to the two turrets on the top and one at the rear of the gunship, pack quite the punch. This combat-ready vessel can seek out and destroy any unsuspecting Rebels in its path.

Rebel Assault Gunship

The gunships employed by the Rebellion are armed to the teeth for occasions when Imperial entanglements cannot be avoided.

The Incom X4 gunship boasts two forward mounted guns, three mounted turrets on the top, and three mounted turrets on the bottom.

Like the gunships employed by neutral factions and Imperials, the Rebel gunship has a spacious interior with more than enough room to stretch your legs. Each gunship consists of multiple levels that can hold a number of items and cargo. Capable of lightspeed, storage, and combat, these gunships can fulfill a variety of needs for pilots and passengers venturing into space.

If you're new to space or a grizzled veteran pilot, these ships have something for everyone. If it's the pure firepower of a gunship you're looking for, or a fully stocked transport taking a journey across the stars, take a spin in the new ships in Chapter 8.

July 02, 2007

SWG Dev Diary: Thomas "Hanse" Eidson #3

Howdy! I'm Thomas "Hanse" Eidson with another designer diary for y'all to peruse. The first diary I wrote explained a little about what a system designer does. My second diary had a high level explanation of how I approached a balance issue with Player versus Environment (PvE). In this diary, I will explain how I approached the Jedi expertise in Chapter 2.

At the time of the first expertise chapter, Jedi had already been revised and given many special actions. Their special actions were way more powerful than any other class and they had a larger variety of them. The expertise's intent was to allow for players to customize their character in a way they wanted to play as well as make them slightly diverse. This also went in hand with something to look forward to spending points on as you advanced with the profession.

The brainstorming began for the expertise. One of the other designers had been assigned the expertise and already had a basic flow chart designed for them. I had been assigned the Jedi by Helios and took over. Since I had a limit on introducing new abilities, I roped a few into the expertise. Too many new abilities would have caused major problems for designing the other profession expertise, as we might not have had time to complete the entire profession changes needed. The theme for the two expertise pages were general and the other light and dark abilities.

I used Microsoft Visio to edit the flow graph of the pages for all the expertises. Every expertise page was first drawn out in Visio. We did a little grease board design and discussion to hash out ideas, along with our brainstorming, of course. Once the Visio page was completed, I worked through the expertise bonus names, descriptions, points to spend, and preliminary bonuses. The bonuses went through many iterations as we implemented and tested them. Many bonuses changed through player feedback on the boards, as well. After the final layout was completed, we submitted art requests with our documentation. Once our documentation was approved by our peers (design team), our leads (Helios and producers), and LucasArts, we began the implementation phase.

Here are the final draft Visio pages. The icons were added as our art department sent them over. We would approve or ask for revisions of the icons during implementation. You will also notice that Force Run is not on this image, due to player feedback.

Here is the second page:

From the previous diary, you will recall an average damage per second chart. That chart is actually without weapon damage and used special actions as a base for its damage graph. I used that graph to base the damage for all future expertise I would make, including the Jedi expertise. With a good base to compare my special action damage values, I could spread the total amongst the special actions.

I was able to plot out a new graph using the Dark Jedi path, purchasing through the expertise all the damage special abilities – and no healing abilities.

An example of this is if at levels 20 to 30, you were granted four actions and those were the top four on all your cooldown groups. If the average damage for that range of levels was 1000, I would spread that damage between the four actions. This is a simplistic explanation, as I had to take into consideration casting time, cooldown time, and damage over time. If all of those were the same, the damage was split an even 25% across the four abilities. This kept the damage values very close to the graph and allowed me to balance future expertise abilities to it.

The graph that I made is dynamic. A data point on the graph would change its position as I worked on balancing ability data. My Excel spreadsheet has linked cells to the values and would modify the values of abilities if I "spent" points in expertise. This simulated the expertise system on paper for me to be able to quickly find data issues. A huge spike in the graph instantly clued me in on a data problem.

Once paper design is completed, the implementation begins. The most time consuming part of implementation is data entry. Each ability has multiple files that must be modified. These files range from where the ability is on the tree, what it looks like, its name and description, data on how it relates to other abilities on the tree, its command data, its appearance, timing, damage, cooldown, and many other bits of data. A single new command for the game can affect around 20 files, if it is complex (such as Forsake Fear). A single typo can doom you to reviewing all that data repeatedly to figure out why it isn't working when you attempt to test it on your server.

Some of the framework for the expertise system was coded the previous chapter. Although, I did have to extend the code quite a bit to get the Jedi abilities to all function. Forsake Fear required a larger amount of code due to its countdown bar. The combat system needed a few new expertise modifiers added to its combat loop. A special case change was made for Saber Block.

Each code change required testing. I like to beat up on Jabba Assassins when I test damage abilities. I think a few thousand Jabba Assassins were brutishly slain on my server during the chapter's development phase. I make sure to kill a few of them every chapter. Here is a picture of a Force Shockwave test with a debug window below it from today (as I write this document). The designers on Star Wars Galaxies use many tools to debug our changes, but the debug window in the image below is invaluable for run-time testing.

The entire process for designing the tree, calculating the special ability values (damage, duration, cooldown, etc), requesting art, and writing the documentation took roughly a week and a half. Implementation took roughly three weeks after that. I would test each change on my local server before submitting it. Testing internally and externally took a few weeks, as well. I did one expertise per publish up until I was asked to do the four trade professions. Each expertise was challenging and I enjoyed doing them.

In the next designer diary, I will explain the Beast Mastery system and the tasks I performed to complete the system.

June 19, 2007

Star Wars Galaxies Developer Diary On "Creature Balance"

Published Jun 19, 2007

 

Dev Diary: Thomas "Hanse" Eidson #2

Howdy, folks! I’m Thomas “Hanse” Eidson, a game designer on the Star Wars Galaxies team. In this second designer diary, I will outline the process behind creature balance, the first design feature I worked on as a system designer.

When I was first brought onto the team a little over a year ago, I was tasked with looking over Non-Player Character (NPC) balance. Normal creatures were too easy to fight at some levels and too hard at others.

At the time, Helios explained that very few stats were used in combat for NPC’s. The feature had to be published soon and I was to review and revise them quickly. I chose a simple stat to modify - their hit points (HP).

When approaching a systemic issue such as creature balance, you would not normally modify only one statistic. Modifying one statistic for creature balance makes your creatures bland and boring during combat. Our current game does not rely on a single statistic for combat. We use a master data table that is level based, which means the statistics rise as the level increases.

The table at the time that I worked on the balance looked almost exactly like this, in logarithmic scale:


You will notice that the values have some fluctuation, but for the most part are smooth. The armor line trend is totally flat, because normal creatures had zero armor. This is very close to a typical NPC/creature difficulty curve. Special NPC’s and creatures are modified by scripts or noted as a higher difficulty (Elite and Boss creatures are not on this chart).

At the time I was charged with making a balance change with NPC’s and creatures, we wanted a target range of ten seconds per creature for each fight. We had a target range of three creatures to take about 30 seconds or so. Our final target range was five creatures being almost too hard to handle. The only caveat was to make sure that low level opponents were easy to dispatch (lower than level 10).

With such a simple graph and no other balance concerns (no special abilities, no dodge values, weapons did not affect damage per second, etc), the balance task became simply a matter of raising the bars on the graph, right? Wrong. The graph approach may be simple, but you must also take into consideration the power graph a player has. I proceeded to graph each class to see what their effective damage over time was.

This chart shows my research for average damage per second multiplied by ten. It excludes burst damage a class may have and averages all the damage abilities. This is dated back to March 2006.


The graph fluctuates and the top-end is actually lower than the previous graph’s maximum HP value. In testing, we found that the low-end creatures took longer to kill. We found that at certain spots in a player’s progression, creatures were just too tough for stretches of levels and simply too easy at others. Quality Assurance tested the new HP values and found some levels were taking too long to defeat and others too short. We adjusted our charts and came up with the following, which was live on the service until Chapter 6.


The HP graph follows the damage over time curve above. The action, minimum damage, maximum damage, and armor values are unchanged. I later reused the average damage over time player graph as a guideline for the expertise damage over time values.

Obviously, with all the changes we made for Chapter 6, we have very different values for creature balance. Here’s the spoiler chart for folks that wish to get a peek at it. The HP values have not changed, but the rest of the data has been modified for combat balance, taking into consideration expertise abilities and the new special abilities of NPCs and creatures.

To get an idea of the timeline it took to make this feature change, I spent roughly two weeks to complete it, with testing. I had to do research to support my data changes, which resulted in the average damage over time chart. The DPS chart took roughly a week of data mining special abilities of all classes and averaging them out. The data changes took only a couple hours. The testing and tweaking of the feature took roughly four days.

So there you have it! There is a bit of math involved in many of the system changes we make. A balance system change needs careful consideration and testing. You have to be careful how you approach your data research and make sure not to overcompensate with your tweaks. Quality Assurance was a huge help in testing the feature change.

In the next diary, I will discuss the approach to the Jedi expertise system in Chapter 2. Thank you for reading!

June 04, 2007

Dev Diary: Thomas "Hanse" Eidson

Howdy, folks! I'm Thomas "Hanse" Eidson, a designer on the Star Wars Galaxies team.

It's been slightly over a year since I started working on Star Wars Galaxies. I've been keeping an eye on the message board and posting in threads on systems that I was working on at the time. So, if you kept an eye on developer posts, you've probably seen one or two of mine. If you haven't, then this diary and future ones should bring you up to speed on what I've been working on over the past year. I'll also include some insight into the publish contributions I've made.

I'll begin things by providing you with a little more background on who I am and how I became a System Designer on Star Wars Galaxies for Sony Online Entertainment. I've been a professional game designer for the past eight years. The majority of that time has been spent designing massively multiplayer games (MMO's). I've been playing MMO's (I consider hundreds of players online at the same time enough to technically qualify as requiring "massive" game mechanics), since text games in the 1980's (Multi-User Dungeons). I began developing games as a hobby after I was first introduced to computers in the 1970's (TRS-80's, Coco, Apple //, etc). So, I've been on the fringe and in the thick of the gaming industry for over 20 years (almost 30! Yikes!).

A System Designer on SWG has many responsibilities. The tasks I've performed for the past year have focused on balance, maintenance, modification, and much more. These ranged from small tasks of simple data changes, to larger data change overhauls, to the addition of brand new systems. We make changes to the game many different ways -- through programming, spreadsheets, text files, and proprietary tools. All of the designers on the team make some sort of systems change at one time or another. However, System Designers usually do not make additions of content (such as quests, storylines, world building, etc).

Our publishes follow a development cycle of brainstorming, design documentation, peer approval, development, bug fixing, release, and post release fixes. Over that cycle, we also have a list of bugs to fix. A previous "bug bash" publish would consist of trying to fix as many bugs as possible. I typically try to fix eight or more bugs per day when I'm tasked with doing bug fixes. Many of those are not discussed on the message board, due to them being possible exploits, oversights, or just plain irrelevant. However, I'm not averse to asking for opinions on the board when a bug fix may affect you adversely. Sometimes I get stumped for a day, but I try to solve all issues before going home so that they do not nag at me overnight or (heaven forbid), over the weekend!

I've worked on seven major publishes to the game. The first publish, I worked on NPC balance issues. After that, I worked on the Jedi expertise. My third publish, I added the Smuggler expertise system. Once that publish was released, I implemented the Commando expertise system. Over the holiday season, I worked on the Trader expertise systems. When the expertise systems were completed, I worked on a bug fixing publish. The latest publish included the Beast Master system and I was one of five designers that worked on beasts. In a future diary (or diaries), I will discuss the steps I took to implement each system.

Thanks for reading this first installation, and please be on the lookout for future diaries from me!

May 30, 2007

SWG Dev Diary: Thomas "Hanse" Eidson #1

Howdy, folks!  I’m Thomas "Hanse" Eidson, a designer on the Star Wars Galaxies team.

It’s been slightly over a year since I started working on Star Wars Galaxies.  I’ve been keeping an eye on the boards and posting on topics that I was working on, at the time.  So, if you kept an eye on developer posts on the boards, you’ve probably seen one of my posts.  If you haven’t, then this and following diaries should bring you up to speed on what I’ve been working on over the past year.  I’ll also include insight into the publish contributions I’ve made.

To bring you up to speed on who I am, I am a System Designer on Star Wars Galaxies for Sony Online Entertainment.  I’ve been a professional game designer for the past eight years.  The majority of that time has been designing massively multiplayer games (MMO’s).  I’ve been playing MMO’s (I consider 100’s of players online at the same time enough to technically qualify as requiring “massive” game mechanics) since text games in the 1980’s (Multi-User Dungeons).  I began developing games as a hobby after I was first introduced to computers in the 1970’s (TRS-80’s, Coco, Apple //, etc).  So, I’ve been on the fringe and in the thick of the gaming industry for over 20 years (almost 30!  Yikes!).

A System Designer on SWG has many responsibilities.  The tasks I’ve performed for the past year have been balance, maintenance, modification, and addition of systems.  These ranged from small tasks of simple data changes to larger data change overhauls to adding an entirely new system.  We make changes to the game through many different ways such as programming, spreadsheets, text files, and proprietary tools.  All of the designers on the team make some sort of systems change at one time or another.  However, System Designers usually do not make additions of content (such as quest, storyline, world building, etc).

Our publishes follow a development cycle of brainstorming, design documentation, peer approval, development, bug fixing, release, and post release fixes.  Over that cycle, we also have a list of bugs to fix.  A previous “bug bash” publish would consist of trying to fix as many bugs as possible.  I typically try to fix eight or more bugs per day, when I’m tasked with doing bug fixes.  Many of those are not discussed on the boards, due to them being possible exploits, irrelevant, oversights, etc.  However, I’m not averse to asking for opinions on the boards, when a bug fix may affect you adversely.  Sometimes I get stumped for a day, but I try to solve all issues before going home so they do not nag at me overnight or (heaven forbid) over the weekend.  My favorite bug fix is a bug that I can turn into a fun feature in the game.

I’ve worked on seven major publishes to the game.  The first publish I worked on NPC balance issues.  After that, I worked on the Jedi expertise.  My third publish I added the Smuggler expertise system.  Once that publish was released, I implemented the Commando expertise system.  Over the holiday season, I worked on the Trader expertise systems.  When the expertise systems were completed, I worked on a bug fixing publish.  Your latest publish included the Beast system and I was one of five designers that worked on Beasts.  In a future dairy (or diaries), I will discuss the steps I took to implement each system.

Thanks for reading and look forward to future diaries!

April 03, 2002

Team Comment - Hanse on the Bulk Order System

This time around in my comments from the team, I’d like to talk more about the Bulk Order System and the additions/enhancements we’ve added to the system. On our development and crafting boards, I dropped hints as to what is coming in our next publish in regards to blacksmith rewards. I’ll try to sum up many of the hints that were spread out over all the threads.

A mistake we made with the blacksmith bulk orders was releasing rewards for the easy bulk deeds that were not very appealing to veterans, and the appealing rewards were almost too difficult to obtain for a veteran that is a casual player. While our new players do benefit from our lower rewards, veterans wanted something more substantial for their efforts. At the same time, some veterans felt that the low-end deeds became worthless after collecting a gob of durable shovels, pickaxes, and mining gloves.

Here are the enhancements we’ve posted on our boards, so far (for Publish 16), for Blacksmithy bulk orders:
  1. Currently, GM smiths have a bonus to get exceptional bulk order deeds. The exceptional bonus percentage will be significantly increased.
  2. Currently, GM smiths do not have a bonus to get colored bulk order deeds. A significant bonus will be added to get colored bulk order deeds (if the object selected is colorable).
  3. Weapon deeds are not appealing to veteran smiths, because they are not colored and give small rewards, while hardly giving any fame. Instead of increasing rewards for individual weapon deeds, we will be introducing five weapon large bulk orders that give new rewards (axes, swords, fencing, maces, and pole arms).
  4. As with #3, we will be adding seven new rewards to the system. Three of the rewards will be low-end rewards. These rewards have not been released yet. They will be available on Test Center when Publish 16 is available for testing.
  5. Any colored deed or weapon large bulk order will get an increased bonus to its rewards if it is exceptional (object reward, fame reward, and gold reward).
  6. A context menu option will display how many hours until your next deed will be available. Minutes are rounded up to the closest hour.
  7. Ancient smithy hammers were increased from 150 uses to 600. This is retroactive for hammers that were obtained prior to the increase.
  8. Runic hammers will have their color displayed as part of their description (i.e.: “a valorite runic hammer”).
  9. To prevent scams, all hammers will state how many charges they have left.
And now, a summary of Tailoring Bulk Orders…
  1. There will be 55 craftable Tailoring items in the system. These items do not include cross-skill items (such as house add-ons) and will not include oil cloths. This means 55 small bulk orders will be available as offers. (Hint: Tailors only have 51 craftable items, currently.)
  2. There will be 14 large bulk order deeds in the Tailoring system. All items that can be crafted will be included in at least one of the large bulk orders. This makes all the small bulk order deeds valuable.
  3. There will be 19 new colors of cloth (not currently available in the game as colors of cloth) as low to medium rewards. This will make all the low-end rewards valuable and usable. Only one color is not original and that is pale blue, but it is not available as a dye.
  4. There will be 44 different rewards (colors of rewards included) with the Tailoring bulk orders.
  5. As with Blacksmithy, we felt that in order to add depth and difficulty to the bulk order system, colored resources would be needed. We explored other avenues of creating depth in the system, but settled on three new types of colored leather. This means there will not be as many deeds in the system, so the system will be easier than Blacksmithy.
  6. GM tailors will receive the same bonus as GM blacksmiths in regards to getting exceptional and colored deeds, mentioned above.
  7. Exceptional quality deeds will yield a higher monetary value than normal deeds.
We have learned a lot from our previous release of Blacksmithy bulk orders, and hope you’ll enjoy both the new changes to Blacksmithy and the new Tailoring bulk order system!

Now that I’ve told you about the stuff most folks are probably interested in, I’ll go into the design steps required for making Tailoring bulk orders.

I was challenged by Evocare to make a bulk order system design. I had predicted that Carpentry would be the next obvious choice, but was surprised when Evocare decided that tailors would benefit from the system.

Tailoring does not have the depth or usage that Blacksmithy does. With only 51 items, it would have been very difficult to make a challenging and rewarding mini-game with the system. Different approaches were plotted out, but I still felt it would be too easy and not on par with the Blacksmithy bulk order system. It was decided that Tailoring needed to be changed to give it more depth.

This meant that the Tailoring system would need to undergo some modification and new additions. New leather resources and an as-of-yet undisclosed resource were created (the new resource is stackable). With a resource system much like that found in Blacksmithy, we now had a foundation to make a bulk order system that was on par with the Blacksmithy system.

After finishing the changes to tailoring itself, everything fell into place with the bulk order system. The rewards were culled from player posts on the boards, and a few twists were added (like the new colored cloth). Now, I’ll go rest my eyes from staring at spreadsheets, graphs, and localized text. :)

Hanse
UO Live Designer

Team Comment - Hanse on the Bulk Order System

This time around in my comments from the team, I’d like to talk more about the Bulk Order System and the additions/enhancements we’ve added to the system. On our development and crafting boards, I dropped hints as to what is coming in our next publish in regards to blacksmith rewards. I’ll try to sum up many of the hints that were spread out over all the threads.

A mistake we made with the blacksmith bulk orders was releasing rewards for the easy bulk deeds that were not very appealing to veterans, and the appealing rewards were almost too difficult to obtain for a veteran that is a casual player. While our new players do benefit from our lower rewards, veterans wanted something more substantial for their efforts. At the same time, some veterans felt that the low-end deeds became worthless after collecting a gob of durable shovels, pickaxes, and mining gloves.

Here are the enhancements we’ve posted on our boards, so far (for Publish 16), for Blacksmithy bulk orders:
  1. Currently, GM smiths have a bonus to get exceptional bulk order deeds. The exceptional bonus percentage will be significantly increased.
  2. Currently, GM smiths do not have a bonus to get colored bulk order deeds. A significant bonus will be added to get colored bulk order deeds (if the object selected is colorable).
  3. Weapon deeds are not appealing to veteran smiths, because they are not colored and give small rewards, while hardly giving any fame. Instead of increasing rewards for individual weapon deeds, we will be introducing five weapon large bulk orders that give new rewards (axes, swords, fencing, maces, and pole arms).
  4. As with #3, we will be adding seven new rewards to the system. Three of the rewards will be low-end rewards. These rewards have not been released yet. They will be available on Test Center when Publish 16 is available for testing.
  5. Any colored deed or weapon large bulk order will get an increased bonus to its rewards if it is exceptional (object reward, fame reward, and gold reward).
  6. A context menu option will display how many hours until your next deed will be available. Minutes are rounded up to the closest hour.
  7. Ancient smithy hammers were increased from 150 uses to 600. This is retroactive for hammers that were obtained prior to the increase.
  8. Runic hammers will have their color displayed as part of their description (i.e.: “a valorite runic hammer”).
  9. To prevent scams, all hammers will state how many charges they have left.
And now, a summary of Tailoring Bulk Orders…
  1. There will be 55 craftable Tailoring items in the system. These items do not include cross-skill items (such as house add-ons) and will not include oil cloths. This means 55 small bulk orders will be available as offers. (Hint: Tailors only have 51 craftable items, currently.)
  2. There will be 14 large bulk order deeds in the Tailoring system. All items that can be crafted will be included in at least one of the large bulk orders. This makes all the small bulk order deeds valuable.
  3. There will be 19 new colors of cloth (not currently available in the game as colors of cloth) as low to medium rewards. This will make all the low-end rewards valuable and usable. Only one color is not original and that is pale blue, but it is not available as a dye.
  4. There will be 44 different rewards (colors of rewards included) with the Tailoring bulk orders.
  5. As with Blacksmithy, we felt that in order to add depth and difficulty to the bulk order system, colored resources would be needed. We explored other avenues of creating depth in the system, but settled on three new types of colored leather. This means there will not be as many deeds in the system, so the system will be easier than Blacksmithy.
  6. GM tailors will receive the same bonus as GM blacksmiths in regards to getting exceptional and colored deeds, mentioned above.
  7. Exceptional quality deeds will yield a higher monetary value than normal deeds.
We have learned a lot from our previous release of Blacksmithy bulk orders, and hope you’ll enjoy both the new changes to Blacksmithy and the new Tailoring bulk order system!

Now that I’ve told you about the stuff most folks are probably interested in, I’ll go into the design steps required for making Tailoring bulk orders.

I was challenged by Evocare to make a bulk order system design. I had predicted that Carpentry would be the next obvious choice, but was surprised when Evocare decided that tailors would benefit from the system.

Tailoring does not have the depth or usage that Blacksmithy does. With only 51 items, it would have been very difficult to make a challenging and rewarding mini-game with the system. Different approaches were plotted out, but I still felt it would be too easy and not on par with the Blacksmithy bulk order system. It was decided that Tailoring needed to be changed to give it more depth.

This meant that the Tailoring system would need to undergo some modification and new additions. New leather resources and an as-of-yet undisclosed resource were created (the new resource is stackable). With a resource system much like that found in Blacksmithy, we now had a foundation to make a bulk order system that was on par with the Blacksmithy system.

After finishing the changes to tailoring itself, everything fell into place with the bulk order system. The rewards were culled from player posts on the boards, and a few twists were added (like the new colored cloth). Now, I’ll go rest my eyes from staring at spreadsheets, graphs, and localized text. :)

Hanse
UO Live Designer

May 29, 2001

Team Comment - Bug fixing, Hanse-style

Howdy!

It’s been a year since I started with the design team for Ultima Online Live. As I sat pondering whether I should comment on any hot topics debated on our web boards, I realized that I am just one person on a large team and any changes/additions being considered could not really be commented on accurately. Those changes can be altered at any point in the development cycle and be very different at the time of release, thus any specific comment I make on upcoming changes could be misleading. I’d like to discuss instead bug fixing by the Ultima Online Live team, rather than new and upcoming changes to the game.

Over the last year, I’ve helped squash many bugs in the game. Most of my development time has been bug fixing. It’s not the most glorious of designer tasks, but seeing something fixed, and seeing players enjoying the game more as a result of the fix, is a sweet reward.

Bug fixing continues as one of our big challenges for this year. In fact, we have more resources to devote to bug fixing now than we did last year. The past approach of “find and squash” has also been revisited and altered. Along with the previous approach, we will start separating bugs into classifications of bugs and attempting system-wide approaches to the fixes. Time to devote to systematic fixing was not available in the past. You may think that this approach is a “no brainer”, but last year was a busy one, with development split up between many new systems (after I came on the team, not including UO: Renaissance and before) and one expansion product.

The developers here devote their time to many different tasks, which are split into different groups. This allows us to work efficiently on the specific areas of the game we are assigned (a few examples are bug fixing for server code, bug fixing for the client that runs on your computer, and new content). The whole team does not stop what it is doing to create an “orc mask”. One or two developers can make an “orc mask”. Quality Assurance maintains a database of bugs for us to review and their priorities. Many of the bugs in the database were submitted by players or brought to our attention through posts on the MyUO boards. Usually, there is not a workday that goes by without someone deliberating over some kind of fix for the game.

Now that we have a larger group of developers working on fixes, the publish process is taking longer to QA. The next two publishes will be large, with some noticeable fixes to standing bugs as well as new content (some items left out of previous publishes for Ilshenar), more localization, some optimization, and various other changes (of course, this list is subject to change as dictated by our Quality Assurance team).

In closing, we’re aware of many of the issues in the game and are making good progress on strengthening our foundation. This process continues while many other systems are developed. It is my privilege to get my feet dirty squashing all these bugs. In fact, it’s one of the most rewarding positions I’ve ever held within a company. If you have knowledge of a bug within the game, please feel free to stop by our developer board on MyUO and say hello with a description of the bug. :)

-Hanse
UO Live Designer