Home
Random
Recent changes
Special pages
Community portal
Preferences
About Sundering
Disclaimers
Sundering
Search
User menu
Talk
Contributions
Create account
Log in
Patches
|
Items
|
Quests
|
Creatures
|
Dungeons
|
NPCs
Attributes
|
Skills
|
Titles
|
XP Augmentation
|
Luminance Augmentation
|
Tailoring
Character Creation
β’
New Player Guide
β’
User Interface
β’
Glossary
Editing
Programmer Extraordinaire: Technical Challenges
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
{{Turbine 2001 | Link = <nowiki>http://acdm.turbinegames.com/featuredarticles/?action=view&article_id=148</nowiki> | Title = Programmer Extraordinaire: Technical Challenges | Text = By Alicia Brown<br><br> 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. <br><br> Srand on Residential Quarters:<br> 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. <br><br> 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. <br><br> 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. <br><br> 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. <br><br> 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* <br><br> Srand on Portal Magic:<br> 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. <br><br> 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. <br><br> The portal changes weren't particularly risky in this regard but I did have to do a lot of flowcharts to make certain we understood exactly how the data would end up. The changes we were planning made sense in the general case, but we also had to plan for weird cases, since there are always weird cases when human players are involved: If you'd never been through a portal at all, what was your spell "portal recall" supposed to be set to? What if you'd only been through unrecallable portals? Or if you'd learned portal tie but never used it? What if you'd only been through summoned portals? We also had to make sure we weren't wiping out useful data or leaving holes for clever players to exploit. And wouldn't you know it - despite all our care, we wound up having to fix an exploitable bug involving summoned portals in the next update - but that, of course, is another story. }} [[Category:Featured Articles]]
Summary:
Please note that all contributions to Sundering may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Sundering:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)
If you're new to the wiki, please take a moment to review our
Naming Conventions
and
Page Templates
. Using proper article names and image formats/sizes keep the wiki clean and helps avoid duplicate entries. Thanks!