Runescape Dev Tracker

What's changed in terms of the tools you use for "graphical work" of today versus what you did 2 or 5 years ago?

I reached out to some of artists for this one - We've been using industry standard tools for a long time now, although there was a point where we used all in house created tools for modelling and texturing. Advancements with our engine capabilities and style choices meant we could move to more standard tools, and utilise 3ds Max and Maya much better. Stylistically we have changed from more hand painted texturing, where we were using 3D Coat to texture our models, to a PBR based system, which allows our materials applied to assets to react with the environment around them. For this type of texturing we use Substance painter. We also use Zbrush for sculpting our high detail meshes, which are used for the texturing stage by baking the high poly detail onto our low poly in game mesh.

How do you develop a shop's User Int...

None that come to mind as we really do tend to avoid it, but we discuss these if we are considering it and we always consider what risks they may introduce for example

What tools and systems do you use for development?

Quite a few different ones across all the different disciplines and departments. We use a mix of in-house tools and other popular tools for anything ranging from scripting and map editing to what artists use for character art and animation. I don't know in-depth what each department uses but on a regular basis i'm personally using our in-house tools more.

How has working from home affected your workflow?

Things are just generally not the same as they used to be. For the most part though we've adapted quite well to doing things remotely. Meetings, reviews, brainstorms, playtests still happen with lots of us in the same spaces over zoom for example. Some things are even better such as playtesting. We might have been at our own desks before whereas now we're in the same zoom call discussing things in the moment and such. The nice thing about a tech-heavy wor...

All mediums although in my example i'm referring to in-game reports mostly as they are a queue that can get cluttered, so in that sense it's important they're clear of spam and duplicates.

Had liver, had pineapple, never had either or both on pizza. Maybe one day, though i'm in the "uhhh nah" camp.

No problem, it's also worth noting many folk don't even have degrees. Some make mods and such for various games and are able to use these as their portfolio pieces.

It's pretty well balanced, i'd say a good 50/50 or sometimes 60/40 weighted towards hands-on.

We have our regular sprint ceremonies which are consistent meetings to cover our sprint to sprint workings, various forms of team syncs, and other project specific meetings.

Outside of that i'm at my "desk" doing hands-on stuff. It can vary a lot though, at different points of a project we'll have different frequencies of meetings or no-meetings.

Core playtesting for the purpose of playability falls on everyone, not just QA. There aren't hard requirements to be familiar with Runescape but it is very much encouraged as it helps A LOT. That being said, we have a lot of RS players that vary from casual to more hardcore, and specialise in their own forms of content i.e. "PvMers" or "Questers."

Designers, developers, artists, and QA are all part of ensuring playability meets the standard they're aiming for, and each project and team might handle that differently. At a baseline, we do have at least one QA playtest for every project but also have things called bug bashes where we'll try to "QA" an update as a team.

As part of the agile workflow we also have regular sprint reviews where other teams and stakeholders are able to play and review updates, for example. There's other opportunities for playtesting across the lifecycle of a project too i won't bore you with, but it can take many forms.

Sorry, this is a very vague question so you'll get a vague answer.

LOTS and LOTS and LOTS. Whether they're in the ideation phase or prototype phase, lots of things don't make it to the final stage. Game design and development is an evolutionary process, whereby the things that don't work for whatever reason get culled as projects progress.

It may be because the idea isn't great, maybe because the surrounding designs don't allow it, maybe the games technology is not advanced enough to allow it, or maybe people just disagree on it... could be any number of reasons. Game development is a creative medium and has lots of challenges and obstacles at every stage.

Yes indeed. This is common practice in the industry and can be known as whiteboxing when referring to a level or gameworld.

Generally graphical assets take longer to create than functionality and so we work with placeholder assets. Those may be blue boxes (or any other colour), or an NPC model borrowed from elsewhere. Whatever it may be, we just need something physical to carry out our work and testing on. What you never want to do is create a bunch of beautiful finalised assets that took months to create only to realise they don't work for whatever reason. Doing that earlier with placeholder boxes and NPCs is a perfect way to avoid that :)

These types of iterations also serve as quick ways to prototype and test the flow of a mechanic or level without doing basically everything. When prototyping boss mechanics for example, we tend to use cabbages as a physical means of testing - for example a dragon breath and its radius.

When all these things are finalised...

Mining & Smithing was my favourite project to work on. I only joined in the final ~6 months of its ~18 month long production cycle but i enjoyed it because it was my first project in the industry, i got to learn an incredible amount about everything game dev, it was a huge project and i like those better than smaller ones, and we were very open and communicative with our players on it. It also was a project that allowed me to shine in a lot of areas and prove myself and my knowledge and experiences.

In terms of what's affected me most, i'd say Ninja albeit not exactly one project or piece of content. Not one single change we made in Ninja hasn't affected me in some way during playing. Every single day i'll come across something we changed and it makes me that little bit happier because it's an improvement to our games quality of life and a little bit less friction encountered :)

QA at Jagex functions as a service team. Within our roles we are allocated to products as required, with a focus on certain ones. Personally i've only ever been an analyst on RS but there are others who've moved between products and departments whether it was required or because they requested it.

In the past we haven't had much automation in a traditional sense. Testing was very much manual but we did have test scripts and various tools to make our lives easier. One such example is simulating drop tables after killing NPCs or populating areas for performance testing.

In more recent years, the departments gone through changes to introduce and bolster our automation capabilities. A few live projects have already made use of this such as Yak Tracks and Treasure Hunter promotions, as well as automated tests for graphical work we've done. We've also diversified the types of roles we hire for within QA such as engineers and SDETs to better work towards the goal of more automation.

Beyond that we've also started using more standard tools such as Xray for test writing and planning, whereby we could integrate automation and with the click of a button could execute an automated test, saving us lots of time!

Small aside - Mod Dolan is a big advocate for such th...

No, we don't explictly have tasks to go back and test and refine old projects/content.

In general we all (QA/devs etc.) play the game and have the freedom to pitch changes to content if we so wish. Agreeing upon those changes and getting them scheduled is a different topic. Typically though these may come as ninja/ninja-esque changes. You'll also find certain Jmods fond of certain content such as quests or bosses that they gravitate toward and want to "modernise".

We may also come across issues or just general friction while testing new projects or changes and those might lead to making changes mid-project for example, but that's not too common. More often than not, we're rewriting smaller functions and testing the updates to those to gradually eliminate tech debt, for example.

There's a deeper topic here to be discussed which is - how much, if any, of old content with such a longstanding game should or can we keep updating and is our time better used to del...

There are quite a few and i'm sure it'd vary from dev to dev but that's just the nature of a longstanding game. Personally I'd like for the equipment dye system to be reworked.

Currently every dyed piece of equipment is a new type of object, so on top of having "new" "used" "augmented" and "broken" versions you now have "new_ice" "used_ice" and "augmented_ice" variants which is not ideal - it inflates development and QA time and can get messy.

One way it could possibly work is similar to how invention perks work, whereby an item is always the same "augmented" version, but an object-based variable on the item says whether or not it has a perk and what level. The same could be done for saying "this item should show the blood dye model". I could be wrong of course, but that'd be a nice rewrite. Still doesn't solve how much art effort would be required for a new dye though :P

The OSRS Wiki page on it that someone else has linked is actually pretty descriptive and is about as much as i'd be able to share with you anyway, worth giving that a read :D

I'm trying to think of an analogy to best describe it so bear with me. In essence, a game engine acts as the platform and rulesets, if you will, for the game to be built on. They'll typically deal with how the game runs at its core, how things are rendered in the game world, how lighting and audio works, how the game loads itself, assets, levels or "scenes", and how it closes, what behaviours are allowed, what physics work and how (if any), and generally what behaviours are or aren't allowed.

When we say something might need engine work, that means we need the means of creating that functionality. A platform or foundation to build off of, the medium from which it can exist. My analogy in this case would be if we were, say, alive hundreds of years ago and i asked you to build a spaceship. Well first you'd need the tools and technology, and the knowledge to do so. How you go about actually building the spaceship would then be up to you.

Another example, more RS relate...

I don't really know the number off the top of my head nor do i have the time to do all the counting but really all departments across the business contribute to the development of the game in various ways. Here are just a few examples of our teams/departments, not extensive, some may even fall under the same umbrella.

• Core development teams. Content team and Live Ops. Within these are sub-teams all working on different projects for game updates. These typically consist of designers, developers (content or tech devs), and artists (concept, character, environment, animation, UI/UX)
• QA. We count as a 'service team' so we act as a shared pool for all Jagex products but typically have a focus on one, such as myself for RS. We have different types of QA too such as QA engineers for automation, and Tech QA for engine/platform teams.
• Engine teams
• Tech teams
• Platform (web for example)
• Community management
• Editorial/marketin...

I got into QA at Jagex as it was a good entry point into the industry. I had never done QA before and didn't really know what was involved either.

I studied game design in university. After graduating I did a stint as a researcher for a nearby university creating VR/AR app prototypes for their clients, and then went back to teach/mark projects at my old university for about a month. At that point i applied for Jagex and here i am.

QA and really any other role can differ depending on what company or studio you're at. At a baseline there are many similarities of course, and the knowledge/experience required is always invaluable.