For some reason, my blog editor won't let me insert the link (icon is greyed out - bastards!)

Here's the document location on massively: http://www.massively.com/2009/07/09/star-wars-galaxies-dev-diary-let-the-pvp-battles-begin/

I'll put it up in my archive section later on. :)

Other than that, I had a little anonymous debate with someone about MMO's part in the future of gaming.  It was a fun debate and I'll look at collecting all of the thread and posting it here.

The new system I'm working on has been published by SOE as a PvP battlefield system.  I've done many PvP updates in the past, but this is an entirely new system.  A battlefield requires many moving parts.  The main parts of the system missing are (per battlefield object):

1) Tracking who wants to play

2) Tracking who is joining

3) Tracking who is playing

4) Battlefield statistics

The above list seems simple.  The devil is in the details.  I'm over 4000 lines of code, not including datatables tracking objects, game rules, and map modifications.  I expect I'll spend four more weeks finishing up and fixing bugs.  After that, I will spend some more time blogging and doing pet projects on the side (XNA 3.0 is really fun to play with).

I knew friends and family beta opened up for WoW that next summer, but I refused to ask Tom for entrance into it.  I wanted to be pleasantly surprised by the game, as Blizzard had never let me down (and still hasn't) with a game.  I finally caved in and joined beta later on towards the end of the summer.

I've played in a couple guilds, did 40 man raiding, and so forth.  I've been playing and making MMO's for so long, but WoW really has a good bit of what I like in a game.  My last geared character was some years ago, though.  I didn't bother with heroics in Burning Crusade due to my newborn son, at the time.

Now that I have some time, I've been raiding three times a week with my guild.  I know my character is not where I want it and that my build is not the top DPS for PvE, but I like the build I have.  I finally got a lil sword that I've been drooling over for my character's appearance (not to mention its stats).  Just have to say "thanks" to Scalebane for putting up with my shit for so long.  I'll have more shit to sling in the future.

I'll post some serious MMO topics for system designers on this blog.  I have been mulling my first topic for some time.  I just want to get the outline and rough draft down.

I've sketched out a graph for it, but for some reason the newest version of Excel doesn't have the graphing feature to modify axis labels (probably does, but it's hidden or something).

Other than that, I finished up my system designs this past week for SWG and I'll be starting up brainstorming on the next set of sprints (guess everyone is being trendy using the scrum system for game development these days) this week.

And now... a childhood pondering of what happens below Qbert...

Dungeon Master had a ton of firsts.  3D realtime combat, 3D realtime movement, 3D audio, falling damage, dynamic spell system, and on and on...  I could gush about this game for hours.

When I think of spell systems that are fun, I think of Dungeon Master.  Its spell system allowed you to combine symbols to make spells.  Symbols represented different things such as amount of power, elemental, types, etc.  You could spend hours trying to find spells in their system.  You could find scrolls that had complete spells in the dungeon, as well.  Skills trained up through usage, so if you discovered a fireball spell early on (before you found the scroll) and used it over and over down a hallway, you would train up the relevant skill (and be able to cast better fireballs).

Items falling onto the ground had been done before.  I don't remember a game that would let you throw items down a hallway and have them hit a target (psuedo-3D), then fall to the ground for you to collect.  Throwing stones down a hallway for them to land on a pressure plate to cause something to happen (doors open/close, pits open/close) was a mechanic they used in their puzzles.

Death in the game made you haul your friend's bones to a resurrection altar.  The sight of seeing a party member die and all their stuff fall to the ground with their bones on top of it I don't remember seeing before, either.  Those bones were heavy to carry and you had to dump all sorts of stuff to haul some dead schlub back to the altar (if there was an altar nearby).

Combat had cooldowns on actions.  I'm not sure which RPG had combat actions with cooldowns first (Final Fantasy and Dungeon Master shipped in the same year - 1987).

I played this game with many friends looking over my shoulder.  We coined the phrase "left is best" for navigating mazes.  We'd chant our maze phrase whenever we came to a branch in a hallway (I found that I did that in Fallout 3 last month, so it's stuck with me).

A free java version of the game is available at:

http://homepage.mac.com/aberfield/dmj/

Until then, you can find me doing my usual thing through mail, AIM, guild chat lines, etc...

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.

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!

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!