Development Diary: Updates
From the RuneScape Wiki, the wiki for all things RuneScape
Updates is a Development Diary about how updates are made to RuneScape.
Contents |
[edit] Part 1: Upload Manager
Some of you may recognise me from the forums, particularly around the times we update. This is for a good reason as I'm the one usually responsible for organising game updates.
I'd like to spend a bit of time explaining my week, which will actually start with a Wednesday just for fun! This is usually the start of the following update, be it quest, minigame or something else.
After a project has been developed, it gets tested in our Work in Progress (WIP) environment by the QA team. Any bugs found here are fixed and, when that's all okay, it stays here until we're ready to release it.
I'll look at the release schedule to determine what we're launching in the following week, then copy changes to the code relating to each of the projects being launched to our Release Candidate (RC) environment.
This 'copy' process includes images, textures, models, animations, audio, interfaces and maps. These are all tied together with RuneScript to form the content update we're releasing.
This is once again tested by QA to ensure that any differences between WIP and RC (of which there can be quite a few at any one time!) don't affect the project and that it all still works as expected. These differences can include such things as a newer version of the game engine with extra features, or different versions of our tools used to produce the above files.
While this is going on, there's a lot of other teams preparing for the update as well...
- The Game Engine team may be building a new version of the server and/or client to support any new features the content might use (which was quite a lot for Mobilising Armies!).
- The graphics artists and developers of the project are busy fixing any issues that are found in RC.
- Our Web Content department are busy updating the Knowledge Base with the changes as a result of the update, e.g. new items or additions to skills, as well as any accompanying images.
- The Web Systems team might be preparing to launch a new module or changes to existing ones such as Game Notes or Hiscores, which is in turn tested by their own QA team.
- Translation are busy localising any phrases from the game into their respective languages and then checking the game to make sure text doesn't spill out or get cut off.
All of the above usually takes us to the end of the working week, and may creep into the early part of the following week if it's a particularly large update or there have been delays to any part of the process.
Having updates most weeks means that if time-lines slip it can have fairly large consequences. If a Monday update slips to Tuesday, the next one probably moves a day too, and so on until we would be updating on a Thursday or Friday (which we try to avoid for obvious reasons, but are sometimes unavoidable).
Update day! Usually a Tuesday, but as early in the week as possible is preferred. In the morning, I'll run through a huge checklist of things that need to be done by the various teams in the office. The content that's been tested in RC is then moved to the Live environment and copied out to all the game worlds around the globe.
This requires a huge amount of coordination, but, when everything's ready, we press the 'red button' of updating. When I say 'red button', I'm exaggerating slightly - it's actually me running around the office, timing everything to perfection, so you see the "System update in x minutes" message, the news and forum posts, and Knowledge Base updates all at the same time. Ten minutes later, the game worlds kick everyone off, load the new version of the game and everyone downloads any updates necessary to play again.
Several staff have commented that my running speed correlates to how hectic things are. I vary from a brisk stroll to full out sprinting if there's something urgent. I've not had to hurdle over desks...yet!
QA, the content developers and myself then keep several eyes on the live version of the game to ensure there aren't any further problems or hiccups. Once we're satisfied there aren't any major problems and any feedback has been taken on board, the whole process starts again for the next update.
I hope you've enjoyed reading this and have a bit more of an insight into my role as the Upload Manager, and how the game updates actually happen.
[edit] Part 2: Trust Us, We're QA
The forums have been bustling with questions recently regarding the process of QA with projects, and why some projects have bugs in them. Well, hopefully, this Developer Blog will explain the process of QA a little, so that you can better understand how content takes the step from a design proposal to being enjoyed by hundreds of thousands of players worldwide.
[edit] The step into QA
When a piece of content comes into QA, it typically takes no more than few hours to find errors, glitches, bugs and concerns. Worry not, though, as this is expected and it’s our job to discover these things! From this moment to the content being released, we work through specific test plans on testing each element of the content, known trouble areas and general exploratory testing.
Any issues found are then sent to the designated developer for fixing, be it anyone from a graphics artist to a content developer to web content. An example of the scope of issues found in a project: an upcoming quest currently stands at 123 bugs, has been in QA for one week and is being tested thoroughly to get it released in time to be enjoyed by everyone.
[edit] More than breaking things
While a large portion of the task at hand is to break and destroy content sent our way as much as possible, which can be extremely enjoyable and equally frustrating at times, we are also very opinionated and believe we understand the players.
When a piece of content comes into QA, it is inevitable that opinions on how to improve design decisions or gameplay mechanics will fly about, trying to make the content more appealing to players. This can be anything from making a weapon look more deadly and suited to the style of RuneScape, to simplifying or increasing the difficulty of puzzles to keep the players engaged (but not bored or frustrated), and even completely redesigning core gameplay mechanics.
These feedback decisions are then relayed to the developers, and with the projects being their own, the decision rests on their shoulders. If the QA team feel particularly strongly about a decision, the concern can be raised to the leader of the particular department, who will weigh up the feedback given, the developer’s feelings, and the most important variable of all: time.
[edit] Priority
Time is extremely important when working on any MMO, and even more so when that MMO receives updates on an almost weekly basis (as opposed to the more typical three- month cycle). It’s rather remarkable, actually.
Unfortunately, given the strict schedule for release the game has, priority has to be put in place for what can be done in the time allocated. Being given two weeks to fully QA a quest, for example, means that the QA team working on it have to determine where to allocate time, as in those two weeks, the quest has to be tested twice - once in the work in progress (WIP) test environment and once in the release candidate (RC) test environment.
Further on from this, to maintain such a quick turnaround on releases, the QA team typically has anything from four to ten projects on at once, split between the team (which also have to be balanced alongside any fixes for previous projects or improvements that could not have been implemented in time), as well as fixes for bugs found by players and relayed to us via the Bug Reporting Forums or Bug Report feature on the homepage (we read and investigate every report!).
[edit] Why is content broken?
There are typically three core reasons why a piece of content contains bugs at release:
Time
This applies more to game ‘features’ than outright bugs. We know of a feature that might cause issues, but, unfortunately, the time it would require to try out and test alternatives may be longer than is available for the project. For issues such as this, we start to consider changes straight after the content is released and wait to see what feedback the players give, so we know the best direction to take. A good example of this is Mobilising Armies, which we’ve recently tweaked to iron out some issues players have had with it since launch (e.g. the number of briefing rooms).
Test Environments
As detailed above, and in even further detail by Mod Nexus in his ‘Upload Manager’ Developer Blog, the content has to be tested in both WIP and RC. WIP is the core environment that all developers use to create content for RuneScape, be it for an update scheduled for the next week, or one for next year.
Even a small change in WIP can have a large impact on the game. It is not uncommon for one change to affect just a single item or feature from a selection of millions - something that is nigh on impossible to locate even if given a year to find. Not only this, but when the piece of content moves from WIP to RC, it’s like moving content from a copy of RuneScape that is six months in the future to current-day RuneScape. The differences can easily break content, requiring us to quickly discover what, where and how this has been caused - as this move into RC means the content will go up as the next update, the clock is ticking.
Bugs Missed
Given the scope and scale of the game, along with the constant progression of updates, bugs are occasionally missed. Only a small percentage of bugs actually fall into this category.
When you consider that, for example, there are 713 head items, 211 cloaks, two graphical modes and 12 graphical settings, that creates 3,610,632 possible combinations. And that’s just regarding helm and cloak graphical issues; the concerns are far greater when considering there are currently 12,988 objects, 11,037 NPCs, 47,451 item locations, 2,531 interface sprites...the list goes on.
Rest assured that the QA team work tirelessly on getting updates in the best shape possible for players, each and every week. Personally, being a large fan of MMO games (and typically being subscribed to many at a single time), you are getting every second worth of your time and membership investment into RuneScape.
Hopefully, this will answer some questions and raise more. Feel free to ask any questions you have on the forums. Happy adventuring!
[edit] Part 3: Within the Launch
- Date of release: 16 October 2009
- Author: Mod Chris L
Within the Light is in the game now and this blog entry is to describe what a developer goes through in the later stages of a project's life cycle. This will cover taking a project from RC to LIVE and beyond. If you want to know the details of what goes on before this stage, have a read of Mod John A's blogs on the development of the recent dwarf quest (Forgiveness of a Chaos Dwarf).
[edit] RC
When the project is in WIP, development and QA can span across weeks or months. When the release date closes in, a certain Mod Nexus will copy it all to RC, as detailed in this blog, which is what will become the version of the game you all play following an update. This is usually done the week before release, so QA (and me!) had a very limited time to check through everything again and make sure Mod Nexus hasn’t missed copying anything and that it’s all still bug free!
[edit] Release
Next comes release! This is where it leaves our hands, really, and I get the most nervous! As the elven curator, and a fairly high-level player myself, I know how much prestige the elven quest line holds in players' eyes, so I was especially nervous. Not only because Within the Light was my first quest, but also because it had a lot to live up to.
As I said, after release, it is generally a process of watching the forums, having an in-game presence and trying to gauge feedback on the content. I’m happy to say the majority of the feedback I’ve seen was very positive, and I’m glad people enjoyed the puzzles.
[edit] Why release this and what is to come?
*Spoiler alert*
The question that many seem to have is, "Why, after all these quests, do we still not have the city of Prifddinas?"
The answer is one of time or, more specifically, resources. We know it has been years since Mourning's Ends Part II was released and there has still been no elven update in this time. The time between ME:II and Within the Light could have been spent creating resources (graphics, audio, code) to build the city - however, this would have been in place of us working on things like Summoning, While Guthix Sleeps, RuneScape HD or other such projects that require a lot of time to make assets for.
While this update didn’t bring the city with it, it did bring an important plot point to why it’s not quite where players thought it was. We released this quest as it had been years since ME:II's release and players were missing the continuation of the quest series.
It was also never planned to release the city with the quest that was to follow ME:II as it does not fit with the story we have planned. If you follow the quest line on the world map, it starts in Ardougne, snakes through the Underground Pass, through Isafdar, back to West Ardougne and then somewhat dead-ends at the Temple of Light. Within the Light was an important quest to not only refresh you of the whole story if you hadn’t played it for years, but also to advance that story and show that it didn’t actually come to a dead end at the Temple of Light at all!
So, what’s next for me post-release? I’ve obviously got other projects on the go, one of which (not elf-related) I hope you all see and enjoy before the year is out! In regards to the elves, I’ve got a rather large document of where I’m aiming to take the series with the next quest. Again, as a RuneScape player capable of doing these quests, writing this document is particularly exciting, as I am writing something I cannot wait to play myself due to the scope and scale of it. I'm also getting input from a few other Mods here that are getting hooked on the story too, so we can all develop it into something that everyone will enjoy!
Thanks for reading!
P.S. Personally, I didn’t save the gnome.
