JagexBreezy

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.

Client restarts (coldfixes) are required whenever any client data has changed, which is almost every time we reboot the servers.

Hotfixes are purely server-only changes that take effect immediately; since no client data changes, no reload is needed.

We also have the ability to do "warmfixes" for some specific client changes. Those require a client restart to load the new version of the client, but you're still able to play in the moment.

Posted a long response to a similar question. https://www.reddit.com/r/runescape/comments/sttlkk/game_development_reddit_qa_with_mod_breezy/hxawyc5/

Any form of comp sci/game development is a great start. No matter what type of work you do, games related or not, if you're able to translate your learning and skills to match what's required of you, you'll be in a good spot. There isn't really a "right" answer, and if you'd like to give yourself more options, maybe general comp sci courses ...

Like one of my uni lecturers once said, a degree is simply a license to hunt, hunting successfully is down to you. Realistically, any form of degree will display your ability to do various things, and that's good on it's own. In any industry you'll be surprised to find people come from many backgrounds. A degree related to the field you're going in to, however, is of course a better start. Knowing software development, project management, game design and development etc. is a great platform to start from.

In my time at Jagex i've seen people come from some very cool and strange backgrounds and industries, and the game industry atleast doesn't discriminate in this sense... But thats because employability is more important. What each industry deems as employable will be different. In general though being mature, confident, professional, knowledgeable and just generally a good person to get along with in the workplace will do wonders for you.

RE: the games/tech indust...

A lot of what i'd suggest is going to be things you could apply to any situation in life. Generally you want to pace yourself and assess your productivity, but be nice to yourself.

I think one of the best ways to avoid this is to agree (with yourself or others) towards an iteration and work toward that and only that. Be it a prototype or something further down the line. Once you're at the end of the prototype "playtest" it and then write down your thoughts and ideas.

"Feature creeping" things in your head mid-development can be great for cool ideas but if it's leading you down rabbit holes and being overwhelmed then it's best to write them down somewhere whether it's a sticky note or spider diagram etc. and forget about them. Pacing yourself with your work will give you lots of breathing room, and most importantly allow you to view the product as a whole rather than being lost somewhere in the middle.

Hope that helps. I'd also recommend looking into working...

There's two ways to answer this. I'll start by saying the recent iteration of Ninja didn't focus on bugs, instead that's a shared responsibility amongst all dev team on a regular basis.

In terms of how we prioritised what work we did in Ninja, we would look at the impact vs. scope/risk. For every iteration of Ninja, the ideal was high impact, low scope. That is - deliver the most impactful QoL change that's also quick to develop. If a single delivery from the team consisted of only that then that's the best thing ever. Of course, real life doesn't work in ideals and so it varies. Realistically a typical Ninja strike would then focus on delivering at least a handful of high impact changes with slightly less regard for scope required.. and then other changes on any part of the spectrum. This is all to put it loosely, it could get quite complex as to how we assess our time and whatever else might be going on around us in that moment.

In terms of how bugs are prioritis...

Very often, on any given day you could be in contact with anyone anywhere.

Let's take a live bug as one example. You could be talking to people from various other teams/departments to investigate it. Maybe that bug is simple and just deals with some content so you only need to talk to a content developer, if any. Sometimes it's more in depth and requires engine or platform work so you need to speak to someone from those teams. Maybe you need to discuss item refunds or bug abuse with player support teams. If said bug requires removal/refunding of items or variables then maybe you need to speak to the analytics teams to gather data on who's affected, to provide to player support. If that then needs more, you might need to speak to the community management team to communicate said information.

That's just one example, but none of that is the typical flow, it could go any way. We also communicate with other teams as we're involved in risk assessment, triaging of issues,...

Hi all, I'm Mod Breezy, QA Analyst on the Content team for RuneScape, and I'm hosting a Q&A session about game development.

Whenever I can, I like to enlighten people on how different aspects of game development work because it's super fun and interesting. It can be very mysterious as to what goes on behind the scenes of any job, so whether you're a curious gamer or an aspiring game dev here's your chance to find out more about game development.

Do you want to know how mechanics are designed? How QA processes work? Do you wonder why or how we decide what mechanics of an update we keep or cut? Are you curious about the pipeline of production or… what a producer even is? This is your opportunity to find out!

Post your questions in this thread and I will reply to the most interesting questions over the following days. Feel free to up-vote any questions you like too.

I won't be answering questions unrelated to game development - anything such as "what up...

"not much to most" is definitely not true. Well done on an incredible achievement!