Every week, we plan to bring you a set of journal entries from someone on the EverQuest II team. This week, we begin our series with the worlds of Emily "Domino" Taylor, a Game Designer who specifically works on tradeskills specifically in the upcoming Rise of Kunark expansion. She records her work for us.
Written by Emily "Domino" Taylor (Game Designer, EQII Tradeskills)
Monday, September 24, 2007
Today starts the last week before our beta cut off date, which is the 28th. I'm feeling more than a little worried about how ready tradeskills will be. The whole team is very helpful, but also all very busy, and none of them have actually been a tradeskill developer through an expansion cycle before either. I thought I was pretty much on track, but I discovered about 2 weeks ago that I'd seriously underestimated the time it would take to generate all the recipes for all the items. So I've been working extra hours for the past week, trying to get them finished off. Chalk it up to optimism and newbishness, but I'd only allowed about 1 week and it's taking about 3, so I'm feeling a bit frazzled.
So, I spent a relaxing Sunday yesterday watching DVDs and creating recipes and recipe books for woodworkers! I'm finishing up tailor books today and then that just leaves carpenters and the secondary tradeskills (and then adding in the extra stuff that I had planned to be adding in last week instead of still doing recipes). It may have to go in later in beta, unfortunately.
To make a set of recipe books isn't a quick task. First I have to have the items done -- these were completed a little while back, with the exception of a few special additions that we're waiting on code requests or art requests for, but the basic items that are just upgrades of the ones they got from 60-70 are done. Next I make up an Excel sheet, or more likely modify an existing one. Every column in the sheet is a piece of information that the recipe will have, and every row is the recipe for one of the items I've made. So, for example, the tailoring spreadsheet I'm doing at the moment has 243 rows and 62 columns. Who knew one simple recipe required 62+ different bits of information! I sure didn't, before starting work here.
I start out by listing all the item names in the first column of the spreadsheet, and the file names of the pristine quality product that they'll create in the "pristine product" column. Then the real work begins - filling in the other 60 colums on all 243 rows. For each, I have to enter the quality tier (common, or rare), the recipe level, the icon if it needs one, the technique and knowledge used, the crafting station type and name, how much progress is required to get to each of the 4 quality levels, and all the build components (both what the database needs to find them, and what the player needs to see displayed on the recipe). Then quantities of each, what each quality level returns and how much, and so on and so on...
Much of this can be automated off lookup tables with formulas, but certainly not all of it. For a class like sages where all the recipes are pretty much the same, it's much faster; but tailors have lots of different types of recipes. They may use either leather or roots as the primary; they may make armor or charm slot dolls or containers or range items (which count as weapons) or ammo containers or fancy dresses (in a no-stat category of their own) or cloaks (filed in with jewelry). Almost all of these can be either common or rare, and many of them can also be imbued. What type of item something is, and whether it is common or rare, and whether it is imbued, all affect what the build components should be, what products should be returned on failure to make pristine, the quantity of fuel, and lots of other stuff too. Which means reading and rereading every line for a common sense check each time to make sure I didn't give the wrong components to the wrong recipe type - one misplaced copy/paste and a recipe could return 10 rares on a crude instead of 10 fuels. This is of course the kind of error that QA and then beta testing should catch, but nonetheless avoiding it in the first place is definitely preferable!
Once the spreadsheet is complete -- which, for tailors, took well over a day's work -- then I run a perl script that reads in each line of the spreadsheet and spits out each recipe. There was an old script that my predecessor had used, but it didn't work for all recipe types so I had to modify it. I have taken only one perl training course, and that was about a year ago, so I am still pretty slow at that type of thing.
The recipe files are just created on my local machine, so I copy/paste them into the appropriate folder for that type of recipe and give them a quick look to make sure nothing too obvious is wrong. If I do spot something wrong -- which has happened quite often, even if it's a small thing like forgetting to enter the recipe level or marking something as a common when it's a rare -- then I go back to the spreadsheet, fix things up, and re-run the perl script.




