[2022] Game Development Reddit Q&A with Mod Breezy

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, participation in reviewing news posts and so on. In my time here the ones i've not really interacted with much would be the business based ones such as HR and finance for example. Everyone else i've pretty much interacted with to some extent regularly.

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 prioritised it's not really too different but there are still nuances. Critical/major bugs would be things that affect core systems OR things that players come into contact with on a high frequency. Sometimes we'd also have "blockers" which would be things like players not able to progress through a quest, for example. Sometimes, if possible to do so, these would come under the hotfix umbrella. On rarer occassions, we might grade a minor bug as major simply due to being spammed with reports because so many players are encountering it. If those who are investigating the bug reports keep having to spent valuable time dealing with duplicate reports of a minor issue, then it's best we stop that by solving the issue quicker.

Any number of people might be involved with grading bug severity, typically it's on the reporter but sometimes it's also taken to production/product owners to assess how we handle it.

The other response to your question from Keltas is also correct, things can be different in different work places so it just falls to nuances in workflows.

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 methodologies and productivity tips, as well as various sources of knowledge from game developers. Youtube, GDC Vault, Gamasutra and such (google too) are great tools for learning good and productive workflows.

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 industry specifically, having a good few projects under your belt (on your portfolio) is one of the best things you could do. Showing your experience and learning with some well executed prototypes or finished projects is the best way to communicate that you know your stuff. You know what it takes for a project from start to finish. You clearly know the skills and toolsets required to make a game or app. You know the challenges you faced and how you overcame them.

TLDR: a relative degree is great especially if the school offers a good variety of classes/modules, but it's more important to be an employable person and also show real stuff on a portfolio (e.g. side projects, prototypes, gamejam games).

Also, don't listen to the other comment. I did a degree in game design and here i am, and others who i work with did straight up software dev and here they are. It's a challenging world, and a competitive industry but if you focus on getting the most out of your time in education effectively, you'll go far (but also don't overwork and burn yourself out). While i was in uni, i tried to participate in gamejams and side-projects, and other extracurricular stuff that grew me as a person and my skillsets.

Best of luck :)

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 are better, but again you could go into game dev courses and go into tech too. Hopefully my other response also elaborates on that :)

Good luck!

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.

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.

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/marketing
• Creative services
• Player support
• Video
• Audio

Those are just a few off the top of my head. Annoyingly I know i'm forgetting quite a few.

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 related, could be physics. Most game engines have physics built in but RS doesn't (as far as im aware). If we wanted to add content with physics we'd need to first make the game engine understand what physics even is e.g. collision, gravity, forces - before we could make any content that utilises any of that.

So, when we say we need engine work, it means we need the game's engine to support whatever it is we want to do as it can't be done via regular content means. Or, maybe sometimes it can but it's a dirty patchwork fix that could introduct lots of risks and or consume much more time than would be worthy. Hope that explains it :)

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

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

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 deliver new content.. or some form of balance between the two. If we do update older content, how frequently do we do it and will we actually just end up forever refreshing older content instead of creating new content and delivering a well rounded service to subscribing players?

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 things and i wanted to link this tweet he posted a while back https://twitter.com/JagexDolan/status/1397622149385437193

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.

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 :)

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 and agreed upon, final assets are gradually plugged in so the game begins to look more and more like the envisioned final product. Believe it or not, most games tend to look like 'crap' up until near the end of their production lifecycle. This is sometimes why you see unfinished or janky looking trailers for games soon to be released.

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.

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.

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.

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.

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

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.

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 workplace is most of it is online so there's not a lot you can't do. I think all the updates we've released since the move to WFH are a testament to how effective we've been despite the change.

Is the RuneScape backend that runs "beneath" RuneScript still Java-based

I'm not entirely sure of the whole situation and i don't think there's really a useful answer i could give . There's a bit of java, and a good bit of not-java.

How does development and Q&A for RuneScape prioritize taking different platforms into consideration

Runescape is a multi-platform game. There isn't a prioritisation for one platform over the other. In any scenario we're considering and testing with all platforms and complying to anything they may need. There are times where changes will only affect a specific platform and as such we only need to test primarily on that platform and less so on others, for example.

What in-game tools do you use when doing Q&A on a piece of content?

There are quite a few that have been created over the years. Sometimes it may be spawning "players" or items for performance testing, some may be spawning NPCs for testing the effect of an AoE, we have tools for testing out animations on different outfits, or blocking in environments, and generally graphics performance etc. All of these make us much more efficient and such.

Do you have any fun technical workarounds that you can tell us about?

Nothing comes to mind immediately, if i think of anything i'll get back to this

Having worked on the Mining and Smithing rework, are there any fun or otherwise interesting bugs or issues that you had to iron out?

More of a design bug but i noticed initially that salvage alch values didn't look right. I compared all the alch prices of those to the items they replaced and found that in quite a few areas, mostly high level slayer, they meant less GP than before. It wasn't a huge gap but it was noticeable enough to be an annoyance so we readjusted it. Some other work on balancing i tried to do here got me invited into the balancing council

Are there any Jagex Q&A in-jokes that you can share?

Good question haha, not really sure most would make sense without context. One that comes to mind is the mispelling of commands. DisplayDPS instead of displayFPS for example, or references to dangerous or just otherwise critical bugs that were caught before the release of a project if they were especially funny in nature or very obscure

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'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 Interface?

Most shops and their restock times etc. will just match what current 'standard' we have in game atm. We'll generally look at a similar shop for 'inspiration' here. Restock times and quantity might be a consideration for balancing or maybe not. Shops have changed a lot over the years and come in many different forms so it's just whichever context its best suited to.

What do you use as criteria for an NPC's wander radius and the boundaries of the location?

These are custom chosen as a maximum range within their configuration. It might change based on where that NPC needs to be.

What are some of the technical challenges in making some content like old holiday events a "permanent" piece of content?

Much the same in revamping any form of old content and as always very context dependant. Some things that come to mind are... There may have been changes in certain functions or code standards, they may have to be "patched" or completely rewritten to actually function now. Graphically they might be broken due to various changes and improvements in our tools or engine, they may have to be reworked in some form. We might have to rework how the rewards are given out, if any. They'd have to be plugged in to the quest system - this could potentially involve quest points, the quest journal, May's Caravan content, adventurers log and so on. NPCs and environments may have to be moved around if that physical space is occupied now.

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.

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.

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.

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 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.

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.

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 :)

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 Runescape) use agile, or waterfall?

In Runescape we work in Agile. Some teams use kanban periodically or permanently, but mostly Agile.

How do you manage weekly releases?

We have various content streams in development. When projects come to be released (when they hit RC), those streams are merged into the "live game" stream and then eventually deployed.

How commonly is Java used in modern day Runescape still?

Not sure on this one sorry. Far as i know there are bits of Java here and there.

Is there a way for developers or QA to propose ideas for the future of the game and have that implemented?

Yes, at all times. Anyone can pitch a change or update, if agreed upon then it'll be put on the schedule in some form. Other ways include occasional brainstorms or planning sessions where anyone can get involved. We have a lot of freedom and opportunities at Jagex to get involved in this sense.

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.

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 redesign and develop/test and so on and so on.

It's a lot of work and i'd love to do another skill rework, and it was a fun project for as long as i was on it, my favourite - but nowadays with the learnings we took away i'd be more in favour for smaller scale "reworks" or improvements that take less time but still provide beneficial and big changes, a bit like the Divination improvements Mod Shogun did last year.

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