Editing Video game development (section)

== Development process ==

Game development is a software development process, as a video game is software with art, audio, and gameplay.<!--4--> Formal software development methods are often overlooked.{{sfn|Bethke|2003|p=4}} Games with poor development methodology are likely to run over budget and time estimates, as well as contain a large number of bugs.<!--3--> Planning is important for individual{{sfn|Bethke|2003|p=3}} and group projects alike.{{sfn|Bethke|2003|p=15}}

Overall<!-- as opposed to individual parts; not a weasel word --> game development is not suited for typical [[Software release life cycle|software life cycle]] methods, such as the [[waterfall model]].{{sfn|Bates|2004|p=225}}

One method employed for game development is [[Agile software development|agile development]].{{sfn|Bates|2004|pp=218–219}} It is based on [[Iterative design|iterative prototyping]], a subset of [[software prototyping]].{{sfn|Bates|2004|pp=226–227}} Agile development depends on feedback and refinement of the game's iterations with a gradually increasing feature set.{{sfn|Chandler|2009|p=47}} This method is effective because most projects do not start with a clear requirement outline.{{sfn|Bates|2004|pp=218–219}} A popular method of agile software development is [[scrum (development)|Scrum]].{{sfn|Chandler|2009|p=41}}

Another successful method is [[Personal Software Process]] (PSP) requiring additional staff training to increase awareness of project planning.{{sfn|Chandler|2009|pp=41, 43–44}} This method is more expensive and requires commitment of team members.<!--44--> PSP can be extended to [[Team Software Process]], where the whole team is self-directing.{{sfn|Chandler|2009|p=44}}

Game development usually involves an overlap of these methods.{{sfn|Bates|2004|p=225}} For example, asset creation may be done via waterfall model, because requirements and specification are clear,{{Sfn|Bates|2004|p=227}} but gameplay design might be done using iterative prototyping.{{sfn|Bates|2004|p=227}}

Development of a commercial game usually includes the following stages:{{sfn|Moore|Novak|2010|p=70}}{{sfn|Bates|2004|p=203}}

=== Pre-production ===

''Pre-production''{{sfn|Bates|2004|p=204}} or ''design phase''{{sfn|Bethke|2003|p=26}} is a planning phase of the project focused on idea and concept development and production of initial design documents.{{sfn|Bates|2004|p=203}}{{sfn|Adams|Rollings|2006|p=29}}{{sfn|Oxland|2004|p=251}}{{sfn|Chandler|2009|pp=5–9}} The goal of concept development is to produce clear and easy to understand documentation,{{sfn|Bates|2004|p=203}}{{sfn|Chandler|2009|p=6}} which describes all the tasks, schedules and estimates for the development team.{{sfn|Bethke|2003|p=102}} The suite of documents produced in this phase is called [[production plan]].{{sfn|Bethke|2003|pp=101–102}} This phase is usually not funded by a publisher,{{sfn|Bates|2004|p=203}} however good<!--that is how source describes them--> publishers may require developers to produce plans during pre-production.{{sfn|Bethke|2003|p=102}}

The concept documentation can be separated into three stages or documents—high concept, pitch and concept;{{sfn|Moore|Novak|2010|p=70}}{{sfn|Bates|2004|pp=203–207}} however, there is no industry standard naming convention, for example, both Bethke (2003) and Bates (2004) refer to ''pitch document'' as "game proposal",{{sfn|Bates|2004|p=204}}{{sfn|Bethke|2003|p=102}} yet Moore, Novak (2010) refers to ''concept document'' as "game proposal".{{sfn|Moore|Novak|2010|p=70}}

The late stage of pre-production may also be referred to as ''proof of concept'',{{sfn|Bates|2004|p=204}} or ''technical review''{{sfn|Moore|Novak|2010|p=70}} when more detailed game documents are produced.

Publishers have started to expect broader game proposals even featuring playable prototypes.{{sfn|Bethke|2003|p=103}}

==== High concept ====

''High concept'' is a brief description of a game.{{sfn|Moore|Novak|2010|p=70}}{{sfn|Bates|2004|p=204}} The high concept is the one-or two-sentence response to the question, "What is your game about?".

==== Pitch ====

A ''pitch'',{{sfn|Moore|Novak|2010|p=70}}{{sfn|Bates|2004|p=204}} ''concept document'',{{sfn|Moore|Novak|2010|p=70}} proposal document,{{sfn|Bethke|2003|p=102}} or ''game proposal''{{sfn|Bates|2004|p=204}} is a short summary document intended to present the game's selling points and detail why the game would be profitable to develop.{{sfn|Moore|Novak|2010|p=70}}{{sfn|Bates|2004|p=204}}

Verbal pitches may be made to management within the developer company, and then presented to publishers.{{sfn|Bates|2004|p=274}} A written document may need to be shown to publishers before funding is approved.{{sfn|Bethke|2003|p=102}} A game proposal may undergo one to several ''green-light meetings'' with publisher executives who determine if the game is to be developed.{{sfn|Bethke|2003|p=27}} The presentation of the project is often given by the game designers.<ref name=":0">{{Cite book|last1=Zackariasson|first1=Peter|url=https://books.google.com/books?id=oQKFmX9m25sC&q=pitching+a+video+game&pg=PA61|title=The Video Game Industry: Formation, Present State, and Future|last2=Wilson|first2=Timothy L.|date=2012|publisher=Routledge|isbn=978-0-415-89652-8|language=en}}</ref> [[Game demo|Demos]] may be created for the pitch; however may be unnecessary for established developers with good track records.<ref name=":0" />

If the developer acts as its own publisher, or both companies are subsidiaries of a single company, then only the upper management needs to give approval.<ref name=":0" />

==== Concept ====

''Concept document'',{{sfn|Bates|2004|p=204}} ''game proposal'',{{sfn|Moore|Novak|2010|p=70}} or ''game plan''{{sfn|Chandler|2009|p=8}} is a more detailed document than the pitch document.{{sfn|Moore|Novak|2010|p=70}}{{sfn|Bates|2004|p=204}}{{sfn|Chandler|2009|p=6}} This includes all the information produced about the game.{{sfn|Chandler|2009|p=8}} This includes the high concept, game's genre, gameplay description, features, setting, story, target audience, hardware platforms, estimated schedule, marketing analysis, team requirements, and risk analysis.{{sfn|Bates|2004|pp=204–205}}

Before an approved design is completed, a skeleton crew of programmers and artists usually begins work.<ref name=":0"/>  Programmers may develop [[quick-and-dirty]] prototypes showcasing one or more features that stakeholders would like to see incorporated in the final product.<ref name=":0"/>  Artists may develop concept art and asset sketches as a springboard for developing real [[game asset]]s.<ref name=":0"/>  Producers may work part-time on the game at this point, scaling up for full-time commitment as development progresses.<ref name=":0"/> Game producer's work during pre-production is related to planning the schedule, budget and estimating tasks with the team.<ref name=":0"/> The producer aims to create a solid production plan so that no delays are experienced at the start of the production.<ref name=":0"/>

==== Game design document ====
{{Main|Game design document}}

Before a full-scale production can begin, the development team produces the first version of a [[game design document]] incorporating all or most of the material from the initial pitch.{{sfn|Bates|2004|p=276}}{{sfn|Oxland|2004|pp=240, 274}} The design document describes the game's concept and major gameplay elements in detail. It may also include preliminary sketches of various aspects of the game. The design document is sometimes accompanied by functional [[Software prototyping|prototypes]] of some sections of the game.{{Citation needed|date=April 2010}} The design document remains a [[living document]] throughout the development—often changed weekly or even daily.{{sfn|Oxland|2004|p=241}}

Compiling a list of game's needs is called "requirement capture".{{sfn|Bethke|2003|p=3}}

==== Prototype ====
[[File:Battle for Mandicor 0.0.5.png|thumb|Placeholder graphics are characteristic of early game prototypes.]]

Writing [[Software prototyping|prototype]]s of gameplay ideas and features is an important activity that allows programmers and game designers to experiment with different [[algorithm]]s and usability scenarios for a game. A great deal of prototyping may take place during [[pre-production]] before the design document is complete and may, in fact, help determine what features the design specifies. Prototyping at this stage is often done manually, (paper prototyping), not digitally,{{Citation needed|date=March 2016}} as this is often easier and faster to test and make changes before wasting time and resources on what could be a canceled idea or project. Prototyping may also take place during active development to test new ideas as the game emerges.

Prototypes are often meant only to act as a [[proof of concept]] or to test ideas, by adding, modifying or removing some of the features.{{sfn|Brathwaite|Schreiber|2009|p=189}} Most algorithms and features debuted in a prototype may be [[Porting|ported]] to the game once they have been completed.

Often prototypes need to be developed quickly with very little time for up-front design (around 15 to 20 minutes of testing).{{Citation needed|date=March 2016}} Therefore, usually very prolific programmers are called upon to quickly code these [[testbed]] tools. [[Rapid application development|RAD]] tools may be used to aid in the quick development of these programs. In case the prototype is in a physical form, programmers and designers alike will make the game with paper, dice, and other easy-to-access tools in order to make the prototype faster.

A successful development model is [[Iterative design|iterative prototyping]], where design is refined based on current progress. There are various technology available for video game development{{sfn|Bates|2004|p=226}}

=== Production ===

Production is the main stage of development when assets and [[source code]] for the game are produced.{{sfn|Chandler|2009|p=9}}

Mainstream production is usually defined as the period of time when the project is fully staffed.{{Citation needed|date=April 2010}} Programmers write new [[source code]], artists develop [[game asset]]s, such as, [[sprite (computer graphics)|sprites]] or [[3D model]]s. Sound engineers develop sound effects and composers develop music for the game. [[Level designer]]s create levels, and writers write dialogue for cutscenes and [[non-player character|NPCs]].{{Original research inline|reason=a bit or'ish if you ask me; need to cite individual tasks or write overview from below section|date=April 2010}}  Game designers continue to develop the game's design throughout production.

==== Design ====
{{Main|Game design}}

Game design is an essential and collaborative{{sfn|Bates|2004|p=xxi}} process of designing the content and rules of a [[game]],{{sfn|Brathwaite|Schreiber|2009|p=2}} requiring artistic and technical competence as well as writing skills.{{sfn|Adams|Rollings|2006|pp=20, 22–23, 24–25}} Creativity and an open mind are vital for the completion of a successful video game.

During development, the game designer implements and modifies the game design to reflect the current vision of the game. Features and levels are often removed or added. The art treatment may evolve and the backstory may change. A new [[computing platform|platform]] may be targeted as well as a new [[demographic]]. All these changes need to be documented and disseminated to the rest of the team. Most changes occur as updates to the design document.

==== Programming ====
{{Main|Game programming}}

The programming of the game is handled by one or more [[game programmer]]s. They develop prototypes to test ideas, many of which may never make it into the final game.  The programmers incorporate new features demanded by the game design and fix any bugs introduced during the development process. Even if an off-the-shelf [[game engine]] is used, a great deal of programming is required to customize almost every game.

==== Level creation ====
{{Main|Level design}}

From a time standpoint, the game's first level takes the longest to develop. As level designers and artists use the tools for level building, they request features and changes to the in-house tools that allow for quicker and higher-quality development. Newly introduced features may cause old levels to become obsolete, so the levels developed early on may be repeatedly developed and discarded. Because of the dynamic environment of game development, the design of early levels may also change over time. It is not uncommon to spend upwards of twelve months on one level of a game developed over the course of three years. Later levels can be developed much more quickly as the feature set is more complete and the game vision is clearer and more stable.

==== Art production ====
{{Main|Game art design}}

During development, artists make art assets according to specifications given by the designers. Early in production, concept artists make concept art to guide the artistic direction of the game, rough art is made for prototypes, and the designers work with artists to design the visual style and visual language of the game. As production goes on, more final art is made, and existing art is edited based on player feedback.

==== Audio production ====
{{Further|Video game music}}

Game audio may be separated into three categories—sound effects, music, and voice-over.{{sfn|Bethke|2003|p=49}}

Sound effect production is the production of sounds by either tweaking a sample to a desired effect or replicating it with real objects.{{sfn|Bethke|2003|p=49}} Sound effects include UI sound design, which effectively conveys information both for visible UI elements and as an auditory display. It provides sonic feedback for in-game interfaces, as well as contributing to the overall game aesthetic.<ref>{{cite web|url=
https://www.asoundeffect.com/sci-fi-ui-sound-effects/
|title=How To Design Superb Sci-Fi UI Sound Effects|date=22 March 2017 |access-date=January 6, 2022|archive-date=March 15, 2021|archive-url=https://web.archive.org/web/20210315164614/https://www.asoundeffect.com/sci-fi-ui-sound-effects/|url-status=live}}</ref> Sound effects are important and impact the game's delivery.{{sfn|Bethke|2003|p=363}}

Music may be synthesized or performed live.{{sfn|Bethke|2003|p=50}}

There are four main ways in which music is presented in a game.

* Music may be ambient, especially for slow periods of game, where the music aims to reinforce the aesthetic mood and game setting.{{sfn|Bethke|2003|p=344}}
* Music may be triggered by in-game events. For example, in such games as [[Pac-Man]] or [[Mario]], player picking up [[power-up]]s triggered respective musical scores.{{sfn|Bethke|2003|p=344}}
* Action music, such as chase, battle or hunting sequences is fast-paced, hard-changing score.{{sfn|Bethke|2003|p=345}}
* Menu music, similar to credits music, creates aural impact while relatively little action is taking place.{{sfn|Bethke|2003|p=345}}

A game title with 20 hours of single-player gameplay may feature around 1 hour.{{sfn|Bethke|2003|p=345}}

==== Testing ====
{{Main|Game testing}}

[[Quality assurance]] of a video game product plays a significant role throughout the development cycle of a game, though comes more significantly into play as the game nears completion. Unlike other software products or productivity applications, video games are fundamentally meant to entertain, and thus the testing of video games is more focused on the end-user experience rather than the accuracy of the software code's performance, which leads to differences in how the game software is developed.<ref name="gamedev survey">{{cite arXiv | last1 = Politowski | first1= Cristiano | first2= Fabio |last2= Petrillo | first3= Yann-Gäel |last3 = Guéhéneuc | title = A Survey of Video Game Testing | eprint=2103.06431  | date = 2021 | class= cs.SE }}</ref>

Because game development is focused on the presentation and gameplay as seen by the player, there often is little rigor in maintaining and testing backend code in the early stages of development since such code may be readily disregarded if there are changes found in gameplay. Some [[Test automation|automated testing]] may be used to ensure the core game engine operates as expected, but most game testing comes via [[game tester]], who enter the testing process once a playable prototype is available. This may be one level or subset of the game software that can be used to any reasonable extent.<ref name="gamedev survey"/> The use of testers may be lightweight at the early stages of development, but the testers' role becomes more predominant as the game nears completion, becoming a full-time role alongside development.<ref name="gamedev survey"/> Early testing is considered a key part of game design; the most common issue raised in several published post-mortems on game development was the failure to start the testing process early.<ref name="gamedev survey"/> 

As code matures and the gameplay features solidify, then development typically includes more rigorous test controls such as [[regression testing]] to make sure new updates to the code base do not change working parts of the game. Games are complex software systems, and changes in one code area may unexpected cause a seemingly unrelated part of the game to fail. Testers are tasked to repeatedly play through updated versions of games in these later stages to look for any issues or bugs not otherwise found from automated testing. Because this can be a monotonous task of playing the same game over and over, this process can lead to games frequently being released with uncaught bugs or glitches.<ref name="gamedev survey"/> 

There are other factors simply inherent to video games that can make testing difficult. This includes the use of randomized gameplay systems, which require more testing for both game balance and bug tracking than more linearized games, the balance of cost and time to devote to testing as part of the development budget, and assuring that the game still remains fun and entertaining to play as changes are made to it.<ref name="gamedev survey"/> 

Despite the dangers of overlooking regression testing, some game developers and publishers fail to test the full feature suite of the game and ship a game with bugs. This can result in customer dissatisfaction and failure to meet sales goals. When this does happen, most developers and publishers quickly release [[Patch (computing)|patches]] that fix the bugs and make the game fully playable again.<ref name="gamedev survey"/> Certain publishing models are designed specifically to accommodate the fact that first releases of games may be bug-ridden but will be fixed post-release. The [[early access]] model invites players to pay into a game before its planned release and helps to provide feedback and bug reports.<ref name="gamedev survey"/> [[Mobile games]] and games with live services are also anticipated to be updated on a frequent basis, offset by pre-release testing with live feedback and bug reports.<ref name="gamedev survey"/>

=== Milestones ===
[[File:Software_dev2.svg|thumb|right|200px|Video game development milestones follow a similar process as with other software development.]]

Commercial game development projects may be required to meet milestones set by the publisher.<!--244--> Milestones mark major events during game development and are used to track game's progress.{{sfn|Chandler|2009|p=244}} Such milestones may be, for example, ''first playable'',{{sfn|Bethke|2003|p=293}}{{sfn|Chandler|2009|p=244–245}} ''alpha'',{{sfn|Bethke|2003|p=294}}{{sfn|Chandler|2009|p=245}} or ''beta''{{sfn|Chandler|2009|p=245}}  game versions.<!--The refs mention these being milestones, not just mention versions.--> Project milestones depend on the developer schedules.{{sfn|Chandler|2009|p=244}}

Milestones are usually based on multiple short descriptions for functionality; examples may be "Player roaming around in-game environment" or "Physics working, collisions, vehicle" etc. (numerous descriptions are possible).  These milestones are usually how the developer gets paid; sometimes as "an advance against royalty". These milestones are listed, anywhere from three to twenty depending on the developer and publisher.  The milestone list is usually a collaborative agreement between the publisher and developer.  The developer usually advocates for making the milestone descriptions as simple as possible; depending on the specific publisher - the milestone agreements may get very detailed for a specific game.  When working with a good publisher, the "spirit of the law" is usually adhered to regarding milestone completion... in other words, if the milestone is 90% complete the milestone is usually paid with the understanding that it will be 100% complete by the next due milestone.  It is a collaborative agreement between publisher and developer, and usually (but not always) the developer is constrained by heavy monthly development expenses that need to be met.  Also, sometimes milestones are "swapped", the developer or publisher may mutually agree to amend the agreement and rearrange milestone goals depending on changing requirements and development resources available.  Milestone agreements are usually included as part of the legal development contracts.  After each "milestone" there is usually a payment arrangement.  Some very established developers may simply have a milestone agreement based on the amount of time the game is in development (monthly/quarterly) and not specific game functionality - this is not as common as detailed functionality "milestone lists".

There is no industry standard for defining milestones, and such varies depending on publisher, year, or project.{{sfn|Bethke|2003|p=192}} Some common milestones for a two-year development cycle are as follows:{{sfn|Chandler|2009|p=244}}

==== First playable ====

The ''first playable'' is the game version containing representative gameplay and assets,{{sfn|Chandler|2009|p=244}} this is the first version with functional major gameplay elements.{{sfn|Bethke|2003|p=293}} It is often based on the prototype created in pre-production.{{sfn|Chandler|2009|p=244–245}} Alpha and first playable are sometimes used to refer to a single milestone, however, large projects require first playable before [[feature complete]] alpha.{{sfn|Bethke|2003|p=293}} First playable occurs 12 to 18 months before code release.  It is sometimes referred to as the "Pre-Alpha" stage.{{sfn|Chandler|2009|p=245}}

==== Alpha ====
{{See also|Alpha release}}

''Alpha'' is the stage when key gameplay functionality is implemented, and assets are partially finished.{{sfn|Chandler|2009|p=245}} A game in alpha is ''feature complete'', that is, the game is playable and contains all the major features.{{sfn|Bethke|2003|p=192}} These features may be further revised based on testing and feedback.{{sfn|Chandler|2009|p=245}} Additional small, new features may be added, and similarly planned, but unimplemented features may be dropped.{{sfn|Bethke|2003|p=192}} Programmers focus mainly on finishing the codebase, rather than implementing additions.{{sfn|Bethke|2003|p=294}}

==== Code freeze ====

''Code freeze'' is the stage when new code is no longer added to the game and only bugs are being corrected.<!--245--> Code freeze occurs three to four months before code release.{{sfn|Chandler|2009|p=245}}

==== Beta ====
{{See also|Beta release}}

''Beta'' is a feature and asset complete version of the game, when only bugs are being fixed.{{sfn|Bethke|2003|p=294}}{{sfn|Chandler|2009|p=245}} This version contains no bugs that prevent the game from being shippable.{{sfn|Bethke|2003|p=294}} No changes are made to the game features, assets, or code.<!--245--> Beta occurs two to three months before code release.{{sfn|Chandler|2009|p=245}}

==== Code release ====

''Code release'' is the stage when many bugs are fixed and game is ready to be shipped or submitted for console manufacturer review.<!--245--> This version is tested against the QA test plan.<!--245--> First code release candidate is usually ready three to four weeks before code release.{{sfn|Chandler|2009|p=245}}

==== Gold master ====
{{See also|Release to manufacturing}}

''Gold master'' is the final game's build that is used as a master for the production of the game.{{sfn|Bethke|2003|p=295}}

==== Release schedules and "crunch time" ====
{{see also|Crunch (video games)}}
In most [[AAA (video game industry)|AAA]] game development, games are announced a year or more in advance and given a planned release date or approximate window so that they can promote and market the game, establish orders with retailers, and entice consumers to pre-order the game. Delaying the release of a video game can have a negative financial impact on publishers and developers, and extensive delays may lead to project cancellation and employee layoffs.{{sfn|Moore|Novak|2010|p=20,48}} To ensure a game makes a set release date, publishers and developers may require their employees to work overtime to complete the game, which is considered common in the industry.{{sfn|Moore|Novak|2010|p=241}} This overtime is often referred to as "[[Crunch (video games)|crunch time]]" or "crunch mode".{{sfn|McShaffry|2009|p=17}} In 2004 and afterwards, the culture of crunch time in the industry came under scrutiny, leading many publishers and developers to reduce the expectation on developers for overtime work and better schedule management, though crunch time still can occur.{{sfn|Moore|Novak|2010|p=48, 241}}

=== Post-production ===

After the game [[Release to manufacturing|goes gold]] and ships, some developers will give team members ''comp time'' (perhaps up to a week or two) to compensate for the overtime put in to complete the game, though this compensation is not standard.{{Cn|date=January 2021}}

==== Maintenance ====
Once a game ships, the maintenance phase for the video game begins.{{sfn|Moore|Novak|2010|p=97}}

Games developed for [[video game console]]s have had almost no maintenance period in the past. The shipped game would forever house as many bugs and features as when released. This was common for consoles since all consoles had identical or nearly identical hardware; making incompatibility, the cause of many bugs, a non-issue. In this case, maintenance would only occur in the case of a [[Game port|port]], [[sequel]], or [[enhanced remake]] that reuses a large portion of the engine and assets.{{Cn|date=January 2021}}

In recent times popularity of online console games has grown, and online capable video game consoles and online services such as [[Xbox Live]] for the [[Xbox (console)|Xbox]] have developed. Developers can maintain their software through downloadable patches. These changes would not have been possible in the past without the widespread availability of the [[Internet]].{{Cn|date=January 2021}}

[[IBM PC compatible|PC]] development is different. Game developers try to account for the majority of configurations and hardware. However, the number of possible configurations of hardware and software inevitably leads to the discovery of game-breaking circumstances that the programmers and testers did not account for.{{Cn|date=January 2021}}

Programmers wait for a period to get as many bug reports as possible. Once the developer thinks they've obtained enough feedback, the programmers start working on a [[patch (computing)|patch]]. The patch may take weeks or months to develop, but it is intended to fix most accounted bugs and problems with the game that were overlooked in past code releases, or in rare cases, fix unintended problems caused by previous patches. Occasionally a patch may include extra features or content or may even alter gameplay.{{Cn|date=January 2021}}

In the case of a [[massively multiplayer online game]] (MMOG), such as a [[Massively multiplayer online role-playing game|MMORPG]] or [[MMORTS]], the shipment of the game is the starting phase of maintenance.{{sfn|Moore|Novak|2010|p=97}}  The maintenance staff for such an online game can number in the dozens, sometimes including members of the original programming team,{{Cn|date=January 2021}} as the game world is continuously changed and iterated and new features are added. Some developers implement a public test realm or player test realm (PTR) in order to test out significant upcoming changes prior to release. These specialized servers offer similar benefits as beta testing, where players get to preview new features while the developer gathers data about bugs and game balance.<ref>{{cite web |last1=D'Onofrio |first1=Matthew |title=New World Devs Discusses Their Development Process And How They Tackle Bugs |url=https://www.mmobomb.com/news/new-world-devs-discusses-their-development-process-how-they-tackle-bugs |website=MMOBomb |access-date=12 June 2023 |date=9 May 2023}}</ref><ref>{{cite web |last1=Tury |first1=Jord |title=How To Access The PTR Server In World Of Warcraft |url=https://www.thegamer.com/world-of-warcraft-ptr-server-login-access-guide/ |website=TheGamer |access-date=12 June 2023 |date=12 October 2022}}</ref>