Programmer Extraordinaire: Technical Challenges
Original Link (now dead) - http://acdm.turbinegames.com/featuredarticles/?action=view&article_id=148
Programmer Extraordinaire: Technical Challenges
By Alicia Brown
As srand herself has stated before, she's a game systems programmer, which means she works with the game systems code (known at Turbine as "weenie" code because, compared to graphics, physics, networking and whatnot, game systems is the easy "weenie" tasks).But just how easy is the "easy" stuff? The technical challenges faced by srand in the creation of Residential Quarters and changes in Portal Magic is the focus of this day's article in our continuing Programmer Extraordinaire series about her. Read on to discover how srand ultimately resolved both challenges in the same month, not long after joining the ACLive team.
Srand on Residential Quarters:
Not long after I joined the ACLive team, I was asked to work on a plan for residential quarters (RQ) - which is to say, dungeons filled with small housing units. The content team had to be able to place them in the world easily, because that had been one of the big slow-downs in getting more landscape housing in. The basics were already covered by our housing system, but there were several small problems that needed to be ironed out before we could just start plunking these things down.
The major problem involved ownership. Previous housing worked by marking one "landcell" as owned by a particular house ID and then keeping track of who (if anyone) owned that house ID. Also, any housing-related objects like hooks or storage chests "knew" which house they belonged to strictly by which landcell they were in. So if you put a house object and a hook in the same landcell, the hook was automatically attached to that house by the preprocessing code. But RQs, like all dungeons, occupy only one landcell -- so if you placed multiple houses in them, they all ended up being owned by the same house ID and the person who purchased one of those houses got 100 chests and 300 hooks. While I'm sure the owner of such a structure would be ecstatic over such a windfall, we here at Turbine generally feel there is a more valid and satisfying gaming experience to be achieved by the players getting only what they have earned and/or paid for. We weenies can be meanies that way.
Conveniently, however, there's another type of cell that we use indoors called an "env cell." An env cell is defined by the pieces used to make up the room in our dungeon builder - a small one-piece room is one env cell, but a large room made from several walls could be many env cells. The reason env cells were convenient for RQs was because, in the preprocessing code, env cells in most ways are treated exactly the same as landcells. So with minor adjustments of the preprocessing code, I could allow RQ ownership to be applied to one env cell, and landscape housing ownership to be applied to one landcell. As long as it was just one cell either way, most of the existing code would work fine.
Of course, nothing is ever that easy. You'll notice I said "most." There were issues regarding how to let the preprocessing code know whether this house was in a dungeon or on the landscape. There were issues regarding how to let it know whether this dungeon was an RQ dungeon or, say, a villa dungeon. There was, when everything else was worked out, a very amusing bug on the client where people would end up seeming to own sections of hallway (instead of apartment) env cells. In the end, however, we resolved all these issues and got RQs operational.
It was an interesting process for me inasmuch as I was working in code that I hadn't previously known existed. So I wasn't familiar with the housing code and didn't know two bits about the preprocessing code. Of the two main architects of the original system, one was hiking the Appalachian Trail and the other was extremely busy on a new project. (To be fair, he willingly made himself available whenever I needed him; I just felt bad dragging him out of meetings all the time.) So I ended up learning lots more than I needed while in the process of figuring out exactly what I did need to learn. My personal feelings about housing also developed during this time: I now classify housing as second only to magic on the list of things I wish AC didn't have. *smile*
Srand on Portal Magic:
Another project I was involved in which had some interesting technical challenges was the changes we made to portal magic. This actually went live the same month RQs did. (Looking back, I have no idea how I managed to do them both at once.) At any rate, the portal changes were fun for me because they involved clean-up of code that had grown up over the years. I was able to simplify and consolidate a lot of it - and that always makes me happy. On the other hand, these changes involved changing data on existing players - and that is nearly always a pain.
One of the particular difficulties of being a live team programmer is the fact that you generally have to live with existing data. You can't do a player wipe just because you want to change the underlying data structure into something more sane, so you have to include special-case code to transfer old data into new data. It's a pain to write, a pain to test and, if it's wrong, you run a serious risk of screwing up someone's character - a very bad thing all around.