JagexBreezy

Yeah! That was my suggestion too!

This gave me a little giggle. I get to say "I told ya so!"

Pre-release, Mod Shogun and I had a small back and forth conversation on if we should add the Elder Rune alloy effect text to the Abyssal variant. I argued that players would need it to understand they don't lose the alloy effect when upgrading, while he argued that it would be implied/inherent and also make the tooltip way too long otherwise. All of which are points others have stated in other comments, and all are fair.

Anyway, this post is my ammunition to add it, and I've written up a feedback job for it :)

Appreciate the comment :) hope you enjoy and learn something new!

It's an incredibly long and difficult job. You first have to design how the new core mechanics will work and then finetune those. You have to do a huge amount of balancing to make sure it all lines up as you intend and that going for 99/120 is still similar to before. Then you have to design how literally every other thing that plugs into a skill would work. For Mining & Smithing this took more time in development than the core skilling just because of how much content there is in this 20+ year old game. You have to change quest requirements and any M&S mechanics in those, you've got to consider things like invention perks and how those must be redesigned, you've got treasure trails to consider like clue that require M&S armours, there will be a million random miscellaneous items from around the game that somehow plug into M&S like a collector's insignia, you'd have to adjust the entirety of the skill guides, and then you've got all the drops from basically every combat NPC ever to...

How do you choose what scenarios to test for an update?

Context dependant, we'll usually look at what changes are made and to what pieces of content it affects. We'll look at existing game mechanics and functionalities to see how they interact now. We'll look for any mysterious ways something could interact and so on.

And how do you automate testing?

As i've detailed elsewhere about automation, it's not something we've typically had but overtime are introducing it more and more. Feel free to check out my other answers in this thread for some more info on it :)

Are there some tests that are performed before every game update or is it always case specific?

Yeah absolutely, we'll look at typical flows of play and golden paths to ensure things still work as expected. Even this might depend on what changes have been made though.

Can you detail the lifecycle of a project (EG: how does a project go from idea to release)?

Ideas may come from a few places. First we'll look at what type of update we need to deliver. Then we'll take ideas from past brainstorms, player feedback, data etc. and developers will begin designing the high level concept, then core elements and such. Once pitched and greenlit we'll begin development that may go from skeleton > core mechanics > polish for example, and then release. That's a very abstract and high level overview.

How large is an average project and how long does it take on average from conception to release?

It varies a lot though so none of this is set in stone, but i'd say the average skilling update/quest ranges from 2-4 months. Bosses tend to take anywhere around 3-6+ months. Skill reworks and new skills have previously taken around 18+ months.

Does Jagex (specifically R...

We work in scrum teams that consist of devs and QA, as well as any artists necessary for that project. We have a well established workflow at this point so it's easier for us to plan ahead with what assets we may need from each discipline (character, animation, audio, marketing etc.).

Our producers ensure things are going as smooth as they can at all times, although the responsibility also falls on everyone to be raising any concerns or issues and apprehending anything coming up. Some of my other answers in this thread will give you some insight as to how our teams work too :)

Beta servers actually take a lot of effort and time to setup and maintain, on top of already having to keep one live game updated and maintained.

You also need more resource and time to collate and parse any feedback you get. In the past we've also not seen an incredible amount of participation. Considering everything involved, we have to weigh up the effort required vs. the output gained.

That's not to say they're useless or we don't like them by any means. I personally think in the past we've used them exactly when necessary (M&S rework, weapon diversity) and i know there's people internally who are advocates for it too. It's just finding the right balance to deliver it.

There are a few different ways we go about doing this.

One way is just via talking to players. We'll either jump in game and discuss content, or take feedback and discuss on various social media sites.

Another is via our analytics and data science team, they'll often provide data and attribute mechanics to that data.

We do actually A/B test various things too though obviously not with content updates for bosses and such. One popular place for this has been with new players around Burthorpe/Davendale/Tut Island etc.

In pretty much every scenario i've seen this occur it's just talked out. Pros and cons are weighed up, design intention and objectives are considered etc.

Sometimes we might prototype something to see how A or B work, or pitch it to a council or the wider RS team to get opinions and consensus. Don't think i've ever seen something get so serious that people have "called it a day".

I actually enjoy when design problems occur because i love problem solving and it's very fun to work with others and explore ideas and consequences, and come to a conclusion that works (or works best).

There's a distinction to be made here between testing for QA purposes, and playtesting for playability, for example.

In terms of QA testing, typically mechanics and structures are tested as a solo player or using multiple accounts and checking to see if you get expected results from whatever you're doing. Checking to see what occurs when you do an action or that numbers look correct and so on.

When it comes to playtesting, we'll group up with others and try to take the boss on as players would. This is done pretty regularly, Raksha, Rex Matriarchs, and all 4 fronts of EGWD had a wider team playtest once a week during development to ensure it was getting the attention it needed at all times throughout development. In the past i know we've even brought players in to try them out, and sometimes even outside of team playtest folks such as the combat council will try taking group bosses on together.

See my answer here for unit testing https://www.reddit.com/r/runescape/comments/sttlkk/game_development_reddit_qa_with_mod_breezy/hxgdb3t/

RE: Integration testing, that's typically done in our "Release Control" or RC phase. Content will be merged with an environment as close to the live game as possible and tested with its own criteria to suit.

Has anyone worked on AI for testing content or even for the actual game but has been scrapped off?

We do have "bots" in a sense but they work differently to how you'd imagine them. Generally AI would probably be too bespoke or too general to suit what we'd need for testing.

Within content QA we don't typically have unit tests no. I think unit testing within games generally is rare simply due to how games work. That's not to say it doesn't happy at all, and in some departments it may be more common such as engine/platform.

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.