This apprenticeship has options. This document is currently showing the following option:
Program reliable and efficient software.
This occupation is found in the games and interactive entertainment industries where programmers create software designed for entertainment. This includes organisations which develop games for games consoles, desktop computers, mobile devices, websites and TVs. This is a core and options apprenticeship standard, which means that apprentices must complete the core, and one option out of Game software programmer or Game technology programmer. Companies which employ Game software programmers range from large, international studios employing hundreds of staff, to small indie studios made up of a few developers. Game technology programmers are often employed by hardware developers (e.g. console manufacturers), middleware providers (e.g. game engine developers) as well as large game studios, and would include specialists like server programmers in mobile game development companies.
The broad purpose of the occupation is to program reliable and efficient software within the constraints of real-time graphical environments running on contemporary gaming platforms. Such programmers lead the development of technical systems which feed directly or indirectly into the player experience of a game. These technical systems could range from gameplay mechanics (e.g. programming a system of different attack moves and their effect on enemies) to asset pipelines (e.g. engineering tools which process geometry data in order to support a character customisation system) and custom technologies (e.g. a new graphics rendering system for displaying realistic-looking dragon scales). They collaboratively plan and coordinate the delivery of their work within a larger team and provide technical insight to a broad spectrum of creative disciplines. They create and maintain appropriate technical standards and stay informed of the latest technical requirements for gaming platforms, exploring new technologies and their potential application within the business. They diagnose and fix problems in complex systems that involve many interacting factors, initiating changes to software architectures to support an evolving design. Game software programmers work on a specific gaming title and their audience are the consumers of that product (gamers). Game programmers select and apply game engines and tools to realise a game design. They are responsible for the development of bespoke asset pipelines and work collaboratively with other developers to maximise the collaborative value of the team’s effort to the player experience. Game technology programmers work on the technologies that underpin videogames and their audience are other game developers. Game technology programmers design and create libraries, engines and tools which target specific hardware architectures or gaming platforms. They initiate and lead the development of standardised technologies and work collaboratively with a wide user-base to inform and improve their design and documentation.
In their daily work, an employee in this occupation interacts with a diverse creative community of developers, providing technical authority and insight to Game programmers, Designers, Producers, Artists, Animators, Audio engineers, Quality Assurance (QA) staff and Project managers. They may also interact with external stakeholders, such as publishers, platform holders and external QA. They work independently and collaboratively as required, reporting to Development directors, Technical directors, Producers, and senior staff. This applies to both options.
An employee in this occupation will be responsible for leading the design and development of bespoke technical systems which affect the allocation of significant project resources. They are responsible for planning and coordinating the delivery of work for themselves and junior programmers and provide technical insight and leadership to a range of creative disciplines within a larger team. They create and maintain technical standards across the organisation and its clients. This includes technical requirements needed to submit titles to console platforms. They lead research into new technologies, identifying potential opportunities for their application. They work under limited direct supervision, responsible for the quality and accuracy of their own work and sometimes the work of others. They ensure work is completed within agreed timescales and within budgets. As their work includes communicating with external stakeholders, they must present a professional image of their employer and themselves. This applies to both options.
This is a summary of the key things that you – the apprentice and your employer need to know about your end-point assessment (EPA). You and your employer should read the EPA plan for the full details. It has information on assessment method requirements, roles and responsibilities, and re-sits and re-takes.
An EPA is an assessment at the end of your apprenticeship. It will assess you against the knowledge, skills, and behaviours (KSBs) in the occupational standard. Your training will cover the KSBs. The EPA is your opportunity to show an independent assessor how well you can carry out the occupation you have been trained for.
Your employer will choose an end-point assessment organisation (EPAO) to deliver the EPA. Your employer and training provider should tell you what to expect and how to prepare for your EPA.
The length of the training for this apprenticeship is typically 24 months. The EPA period is typically 6 months.
The overall grades available for this apprenticeship are:
When you pass the EPA, you will be awarded your apprenticeship certificate.
The EPA gateway is when the EPAO checks and confirms that you have met any requirements required before you start the EPA. You will only enter the gateway when your employer says you are ready.
The gateway requirements for your EPA are:
For the game programmer, the qualification required is:
A project with a software artefact
You will be asked to complete a software artefact. The title and scope will be agreed with the EPAO at the gateway. As part of the project, you need to write a software artefact and submit this to the EPAO. The software artefact should be a maximum of 5000 (with a 10% tolerance).
You will have 12 weeks to complete the project and submit the software artefact to the EPAO.
You need to prepare and give a presentation to an independent assessor. Your presentation slides and any supporting materials should be submitted at the same time as the project output. The presentation with questions will last at least 90 minutes. The independent assessor will ask at least 5 questions about the project and presentation.
Professional discussion underpinned by a portfolio of evidence
You will have a professional professional discussion with an independent assessor. It will last 105 minutes. They will ask you at least 10 questions. The questions will be about certain aspects of your occupation. You need to compile a portfolio of evidence before the EPA gateway. You can use it to help answer the questions.
The EPAO will confirm where and when each assessment method will take place.
You should speak to your employer if you have a query that relates to your job.
You should speak to your training provider if you have any questions about your training or EPA before it starts.
You should receive detailed information and support from the EPAO before the EPA starts. You should speak to them if you have any questions about your EPA once it has started.
If you have a disability, a physical or mental health condition or other special considerations, you may be able to have a reasonable adjustment that takes this into account. You should speak to your employer, training provider and EPAO and ask them what support you can get. The EPAO will decide if an adjustment is appropriate.
This occupation is found in the games and interactive entertainment industries where programmers create software designed for entertainment. This includes organisations which develop games for games consoles, desktop computers, mobile devices, websites and TVs. This is a core and options apprenticeship standard, which means that apprentices must complete the core, and one option out of Game software programmer or Game technology programmer. Companies which employ Game software programmers range from large, international studios employing hundreds of staff, to small indie studios made up of a few developers. Game technology programmers are often employed by hardware developers (e.g. console manufacturers), middleware providers (e.g. game engine developers) as well as large game studios, and would include specialists like server programmers in mobile game development companies.
The broad purpose of the occupation is to program reliable and efficient software within the constraints of real-time graphical environments running on contemporary gaming platforms. Such programmers lead the development of technical systems which feed directly or indirectly into the player experience of a game. These technical systems could range from gameplay mechanics (e.g. programming a system of different attack moves and their effect on enemies) to asset pipelines (e.g. engineering tools which process geometry data in order to support a character customisation system) and custom technologies (e.g. a new graphics rendering system for displaying realistic-looking dragon scales). They collaboratively plan and coordinate the delivery of their work within a larger team and provide technical insight to a broad spectrum of creative disciplines. They create and maintain appropriate technical standards and stay informed of the latest technical requirements for gaming platforms, exploring new technologies and their potential application within the business. They diagnose and fix problems in complex systems that involve many interacting factors, initiating changes to software architectures to support an evolving design. Game software programmers work on a specific gaming title and their audience are the consumers of that product (gamers). Game programmers select and apply game engines and tools to realise a game design. They are responsible for the development of bespoke asset pipelines and work collaboratively with other developers to maximise the collaborative value of the team’s effort to the player experience. Game technology programmers work on the technologies that underpin videogames and their audience are other game developers. Game technology programmers design and create libraries, engines and tools which target specific hardware architectures or gaming platforms. They initiate and lead the development of standardised technologies and work collaboratively with a wide user-base to inform and improve their design and documentation.
In their daily work, an employee in this occupation interacts with a diverse creative community of developers, providing technical authority and insight to Game programmers, Designers, Producers, Artists, Animators, Audio engineers, Quality Assurance (QA) staff and Project managers. They may also interact with external stakeholders, such as publishers, platform holders and external QA. They work independently and collaboratively as required, reporting to Development directors, Technical directors, Producers, and senior staff. This applies to both options.
An employee in this occupation will be responsible for leading the design and development of bespoke technical systems which affect the allocation of significant project resources. They are responsible for planning and coordinating the delivery of work for themselves and junior programmers and provide technical insight and leadership to a range of creative disciplines within a larger team. They create and maintain technical standards across the organisation and its clients. This includes technical requirements needed to submit titles to console platforms. They lead research into new technologies, identifying potential opportunities for their application. They work under limited direct supervision, responsible for the quality and accuracy of their own work and sometimes the work of others. They ensure work is completed within agreed timescales and within budgets. As their work includes communicating with external stakeholders, they must present a professional image of their employer and themselves. This applies to both options.
| Duty | KSBs |
|---|---|
|
Duty 1 Lead the development of technical systems governed by the principles and constraints of real-time graphical environments for contemporary gaming platforms (e.g. games consoles, desktop computers, tablets and phones). |
|
|
Duty 2 Engineer robust, performance-driven software using programming languages, game engines and frameworks appropriate to the requirements of the projects being developed (for example C++, C#). Conceptualise and address performance bottlenecks and optimize complex software systems and resource pipelines. |
|
|
Duty 3 Diagnose and fix errors in complex technical systems that involve many interacting factors, making use of automated testing systems to optimise workflows. |
|
|
Duty 4 Lead the development of technical systems which feed directly or indirectly into the player experience, working iteratively to continuously adjust and refine their work. Initiate and implement modifications to software architectures to support future changes in design. |
|
|
Duty 5 Plan and co-ordinate the delivery of work for themselves and junior programmers within a larger team, using appropriate version control and project management tools to manage software changes and track progress within the context of a wider development methodology. |
|
|
Duty 6 Provide technical insight to a broad spectrum of creative disciplines from Game Programmers, Designers, Producers, Artists, Animators, Audio Engineers, QA staff, Project Managers, Analysts, Community Managers and Marketing to communicate technical constraints and opportunities. |
|
|
Duty 7 Create and maintain technical standards across the project, organisation and its clients and stay informed of the latest technical requirements for gaming platforms. Undertake reviews of code, documentation, testing processes and methodologies to maintain good technical practice across the business. |
|
|
Duty 8 Lead research into new technologies and identify opportunities for their potential application within the business. |
|
|
Duty 9 Practice continuous self-learning to keep up to date with latest industry developments, and support their effective communication within the organisation. |
| Duty | KSBs |
|---|---|
|
Duty 10 Select and apply industry-standard game engines and tools to realise game design, employing industry-standard tools to accelerate the development process and avoid unnecessary replication of effort and resources. |
|
|
Duty 11 Initiate and lead the development of bespoke asset pipelines, which affect the allocation of significant project resources, beyond the extent of their own tasks. |
|
|
Duty 12 Work collaboratively with other developers to maximise the combined value of the team’s effort to the player experience. |
| Duty | KSBs |
|---|---|
|
Duty 13 Design and create libraries, engines and tools which target specific hardware architectures or gaming platforms, applying both high and low-level approaches to their development and optimisation. |
|
|
Duty 14 Initiate and lead the development of standardised core technologies, software systems and workflows which affect the allocation of significant resources for the users of those technologies. |
|
|
Duty 15 Work collaboratively with a wide user-base to support their use of technologies and inform and improve their design and documentation. |
K1: How to approach the development of interactive, real-time applications for gaming platforms, including an awareness of industry-standard programming languages, application programming interfaces (APIs), tools, engines and frameworks.
Back to Duty
K2: The syntax and structure of an industry-standard programming language (above and beyond visual programming languages) used for the development of games (for example C++, C#).
Back to Duty
K3: The fundamental graphical and mathematical principles that underpin the operation of real-time graphics in two and three-dimensions.
Back to Duty
K4: The characteristics of modern hardware platforms and how they support the efficient function of interactive, real-time graphical applications.
Back to Duty
K5: Approaches to balancing quality and performance requirements to achieve, monitor and maintain acceptable frame rates and memory footprints for a real-time interactive application.
Back to Duty
K6: How to use tools to identify and optimise performance bottlenecks in real-time applications.
Back to Duty
K7: The role of debugging tools, crash reports, automated testing and continuous integration workflows in creating robust software.
Back to Duty
K8: The role of staged deployment, monitoring and analytics in releasing, tracking and refining games.
Back to Duty
K9: Common principles of good software design applied in the games industry including contrasting approaches and priorities (e.g. object-oriented vs. data-oriented)
Back to Duty
K10: How a complete asset pipeline for a game operates, including the technical requirements, processing stages and tools involved in bringing assets into the game.
Back to Duty
K11: How to use version control and project management tools to plan and coordinate the delivery of development tasks.
Back to Duty
K12: Common development methodologies and how they are applied in game development.
Back to Duty
K13: The broad range of roles involved in the game development process, and the different strengths and perspectives that multi-disciplinary teams bring to the creative process.
Back to Duty
K14: Where to find information on the latest technological innovations for the games industry.
Back to Duty
K15: The role of rapid prototyping and agile approaches in innovation.
Back to Duty
K16: The organisation’s standards with respect to coding, documentation and issue tracking, and how they relate to wider practice in the software industries.
Back to Duty
K17: Publisher’s technical requirements for target platforms, where to obtain them and the tools and systems available to support developers to meet those requirements.
Back to Duty
K18: The business stakeholders in a project and how multi-disciplinary development teams can generate value within the context of different business models.
Back to Duty
K19: Relevant data protection laws including GDPR.
Back to Duty
K20: Security approaches to prevent products being compromised, and everyday good practice in security including password policies, phishing and use of VPNs.
Back to Duty
K21: The relative merits of different game engines, third-party frameworks and tools, and when to use them to speed up the development process.
Back to Duty
K22: How to balance the requirements and availability of team resources (for example staff time, software licencing) with respect to the engineering and maintenance of a game’s asset pipeline.
Back to Duty
K23: The range of different disciplines involved in the development process and their typical skillsets and expectations in terms of technologies, tools and asset formats.
Back to Duty
K24: The specialist operation of a specific hardware architecture or gaming platform and how to engineer efficient solutions which target its specific capabilities.
Back to Duty
K25: How to balance the requirements and availability of team resources (staff time, software licencing) with respect to providing the maximum benefit to their users.
Back to Duty
K26: How to use externally facing support portals and project tracking tools in order to effectively track and document technologies for sharing with a wide user-base.
Back to Duty
S1: Program interactive, real-time applications for gaming platforms using an industry-standard programming language, incorporating APIs, tools, engines or frameworks appropriate to employer requirements.
Back to Duty
S2: Implement and adapt contemporary real-time algorithms in two and three-dimensional games.
Back to Duty
S3: Use profiling tools and techniques to achieve, monitor and maintain an acceptable real-time framerate for an interactive game.
Back to Duty
S4: Track memory usage and identify opportunities for reducing requirements.
Back to Duty
S5: Write code informed by the characteristics of modern hardware platforms (e.g. shader programming, multi-threading).
Back to Duty
S6: Use debugging tools and automated testing systems to develop robust code bases.
Back to Duty
S7: Use continuous integration workflow within the deployment lifecycle as part of a multi-disciplinary software team.
Back to Duty
S8: Write robust, well-tested, maintainable code which is easy to adapt to changing requirements.
Back to Duty
S9: Use an industry-standard version control system.
Back to Duty
S10: Use an industry-standard project management system from the perspective of a developer.
Back to Duty
S11: Adapt or extend existing tool chains to support new features and/or optimise workflows.
Back to Duty
S12: Apply industry-standard development methodologies within day-to-day working practice.
Back to Duty
S13: Manage complex relationships with diverse stakeholders and communicate information effectively to different audiences.
Back to Duty
S14: Provide technical leadership and direction with respect to the workflow of other team members.
Back to Duty
S15: Research, document and articulate the opportunities and threats presented by new industry technologies.
Back to Duty
S16: Follow studio coding best-practices and participate in keeping them relevant and up to date.
Back to Duty
S17: Give and receive feedback in code reviews in an objective and professional manner.
Back to Duty
S18: Develop games and/or prototypes using an industry-standard or in-house game engine.
Back to Duty
S19: Make justified choices about the implementation of different features and tools and their effect on the overall workload of the team.
Back to Duty
S20: Write software which contributes to the player experience while balancing the extensibility and performance requirements for an evolving game design.
Back to Duty
S21: Work as part of interdisciplinary teams.
Back to Duty
S22: Create innovative game mechanics for which solutions are unknown.
Back to Duty
S23: Develop reusable technologies targeting specific hardware architectures or gaming platforms.
Back to Duty
S24: Make justified decisions about the implementation of different features and their effect on quality and workload for their technology’s user base.
Back to Duty
S25: Work as part of a user-focused product team, incorporating multi-disciplinary input from outside of the team, for example from game software programmers, artists, game designers and audio engineers.
Back to Duty
S26: Communicate and evangelise technology solutions to promote engagement and uptake among the user-base.
Back to Duty
S27: Profile and optimise code created by their technology users.
Back to Duty
B1: Reliable, objective and capable of independent working.
Back to Duty
B2: Initiative and personal responsibility to overcome challenges and take ownership for project solutions.
Back to Duty
B3: Respect for other disciplines and an understanding of the role of diverse experiences and backgrounds in a successful creative process.
Back to Duty
B4: Commitment to continuous professional development; maintaining their knowledge and skills in relation to technology developments, and sharing best practice in their organisation around all aspects of game development.
Back to Duty
B5: Maintains awareness of trends and innovations in the subject area, utilizing a range of academic literature, online sources, community interaction and conference attendance.
Back to Duty
B6: Acts with integrity with respect to ethical, legal and regulatory ensuring the protection of personal data, safety and security.
Back to Duty
B7: A strong work ethic and commitment in order to meet the standards required.
Back to Duty
Apprentices without level 2 English and maths will need to achieve this level prior to taking the End-Point Assessment. For those with an education, health and care plan or a legacy statement, the apprenticeship’s English and maths minimum requirement is Entry Level 3. A British Sign Language (BSL) qualification is an alternative to the English qualification for those whose primary language is BSL.
V1.2
This document explains the requirements for end-point assessment (EPA) for the game programmer apprenticeship. End-point assessment organisations (EPAOs) must follow this when designing and delivering the EPA.
Game programmer apprentices, their employers and training providers should read this document.
A full-time game programmer apprentice typically spends 24 months on-programme (this means in training before the gateway). The apprentice must spend at least 12 months on-programme and complete the required amount of off-the-job training in line with the apprenticeship funding rules.
The apprentice must complete their training and meet the gateway requirements before starting their EPA. The EPA will assess occupational competence.
An approved EPAO must conduct the EPA for this apprenticeship. Employers must select an approved EPAO from the register of end-point assessment organisations (RoEPAO).
This EPA has 2 assessment methods.
The grades available for each assessment method are below.
Assessment method 1 - project with presentation and questions:
Assessment method 2 - professional discussion (underpinned by portfolio):
The result from each assessment method is combined to decide the overall apprenticeship grade. The following grades are available for the apprenticeship:
|
On-programme - typically 24 months
|
The apprentice must:
The qualification required is:
|
|---|---|
|
End-point assessment gateway
|
The apprentice’s employer must be content that the apprentice has attained sufficient KSBs to complete the apprenticeship. The apprentice must:
For the project with presentation and questions, the apprentice must submit a Project brief. To ensure the project allows the apprentice to meet the KSBs mapped to this assessment method to the highest available grade, the EPAO should sign-off the project’s title and scope at the gateway to confirm it is suitable.
For the professional discussion (underpinned by portfolio), the apprentice must submit a portfolio of evidence.
The apprentice must submit the gateway evidence to their EPAO, including any organisation specific policies and procedures requested by the EPAO. |
|
End-point assessment - typically 6 months
|
The grades available for each assessment method are below
Project with presentation and questions:
Professional discussion (underpinned by portfolio):
Overall EPA and apprenticeship can be graded:
|
|
Re-sits and re-takes
|
|
The EPA is taken in the EPA period. The EPA period starts when the EPAO confirms the gateway
The apprentice’s employer must be content that the apprentice has attained sufficient KSBs to complete the apprenticeship. The employer may take advice from the apprentice's training provider, but the employer must make the decision. The apprentice will then enter the gateway.
The apprentice must meet the gateway requirements before starting their EPA.
They must:
Portfolio of evidence requirements:
The apprentice must compile a portfolio of evidence during the on-programme period of the apprenticeship. It should only contain evidence related to the KSBs that will be assessed by this assessment method. It will typically contain 12 discrete pieces of evidence. Evidence must be mapped against the KSBs. Evidence may be used to demonstrate more than one KSB; a qualitative as opposed to quantitative approach is suggested.
Evidence sources may include:
This is not a definitive list; other evidence sources can be included.
The portfolio of evidence should not include reflective accounts or any methods of self-assessment. Any employer contributions should focus on direct observation of performance (for example, witness statements) rather than opinions. The evidence provided should be valid and attributable to the apprentice; the portfolio of evidence should contain a statement from the employer and apprentice confirming this.
The EPAO should not assess the portfolio of evidence directly as it underpins the discussion. The independent assessor should review the portfolio of evidence to prepare questions for the discussion. They are not required to provide feedback after this review.
The apprentice must submit the gateway evidence to their EPAO, including any organisation specific policies and procedures requested by the EPAO.
The assessment methods can be delivered in any order.
The result of one assessment method does not need to be known before starting the next.
A project involves the apprentice completing a significant and defined piece of work that has a real business application and benefit. The project must meet the needs of the employer’s business and be relevant to the apprentice’s occupation and apprenticeship.
This assessment method has 2 components:
project with a project output
presentation with questions and answers
Together, these components give the apprentice the opportunity to demonstrate the KSBs mapped to this assessment method. They are assessed by an independent assessor.
Programmers in the games industry are principally engaged in developing software, and each programmer will engineer many different technical systems as part of the development of a complete game. As the project cycle for games is often too long to assess a complete product, this assessment uses one of these technical systems as a practical way of demonstrating software engineering skills and their associated KSBs. Although it isn’t compulsory for this system to be assessed in isolation from its associated product, this may be necessary when the wider product is incomplete or subject to confidentiality requirements. The project and any components must be assessed holistically by the independent assessor when they are deciding the grade for this EPA method.
The apprentice must complete a project based on any of the following:
The project may also be based on:
a development of live product where it is appropriate to do so. Where client confidentiality requires it the system may be demonstrated in a test harness, or using placeholder/white box assets which conceal the product and/or client.
Typical project titles could include:
To ensure the project allows the apprentice to meet the KSBs mapped to this assessment method to the highest available grade, the EPAO should sign-off the project’s title and scope at the gateway to confirm it is suitable. The EPAO must refer to the grading descriptors to ensure that projects are pitched appropriately.
The project output must be in the form of software artefact.
The apprentice must start the project after the gateway. The employer should ensure the apprentice has the time and resources, within the project period, to plan and complete their project.
The apprentice may work as part of a team to complete the project, which could include internal colleagues or technical experts. The apprentice must however, complete their software artefact and presentation unaided and they must be reflective of their own role and contribution. The apprentice and their employer must confirm this when the software artefact and any presentation materials are submitted.
The minimum requirements software artefact are:
A complete working technical system, or collection of systems which executes and produces a verifiable outcome. Verification may be achieved through a test harness or other code framework which is not of the apprentice's own creation, but the technical system itself must be all their own work.
Typically, it would be supported by a code repository evidencing its iterative development by the apprentice over the assessment period, and not just the final codebase.
Typically, the software artefact would be a real-time system, but it could also be something which creates data for or from a real-time system.
The apprentice must complete and submit the software artefact and any presentation materials to the EPAO by the end of week 12 of the EPA period.
The presentation with questions must be structured to give the apprentice the opportunity to demonstrate the KSBs mapped to this assessment method to the highest available grade.
Apprentices will be required to produce, submit and deliver a presentation to the independent assessor. A copy of the presentation must be submitted to the EPAO at the same time as the software artefact; 12 weeks after the gateway.
The apprentice must prepare and deliver a presentation to an independent assessor. After the presentation, the independent assessor must ask the apprentice questions about their project, software artefact and presentation.
The presentation should cover:
The presentation with questions must last 90 minutes. This will typically include a presentation of 45 minutes and questioning lasting 45 minutes. The independent assessor must use the full time available for questioning. The independent assessor can increase the time of the presentation and questioning by up to 10%. This time is to allow the apprentice to complete their last point or respond to a question if necessary.
The independent assessor must ask at least 5 questions. They must use the questions from the EPAO’s question bank or create their own questions in line with the EPAO’s training. Follow up questions are allowed where clarification is required.
The purpose of the independent assessor's questions is:
The apprentice must submit their presentation materials to the EPAO at the same time as the software artefact - by the end of week 12 of the EPA period. The apprentice must notify the EPAO, at that point, of any technical requirements for the presentation.
During the presentation, the apprentice must have access to:
The independent assessor must have at least 2 weeks to review the software artefact and any presentation materials, to allow them to prepare questions.
The apprentice must be given at least 2 weeks’ notice of the presentation with questions.
The independent assessor must make the grading decision. They must assess the project components holistically when deciding the grade.
The independent assessor must keep accurate records of the assessment. They must record:
The presentation with questions must take place in a suitable venue selected by the EPAO for example, the EPAO’s or employer’s premises. It should take place in a quiet room, free from distractions and influence.
The presentation with questions can be conducted by video conferencing. The EPAO must have processes in place to verify the identity of the apprentice and ensure the apprentice is not being aided.
The EPAO must develop a purpose-built assessment specification and question bank. It is recommended this is done in consultation with employers of this occupation. The EPAO should maintain the security and confidentiality of EPA materials when consulting with employers. The assessment specification and question bank must be reviewed at least once a year to ensure they remain fit-for-purpose.
The assessment specification must be relevant to the occupation and demonstrate how to assess the KSBs mapped to this assessment method. The EPAO must ensure that questions are refined and developed to a high standard. The questions must be unpredictable. A question bank of sufficient size will support this.
The EPAO must ensure that the apprentice has a different set of questions in the case of re-sits or re-takes.
EPAO must produce the following materials to support the project:
The EPAO must ensure that the EPA materials are subject to quality assurance procedures including standardisation and moderation.
In the professional discussion, an independent assessor and apprentice have a formal two-way conversation. It gives the apprentice the opportunity to demonstrate the KSBs mapped to this assessment method.
The apprentice can refer to and illustrate their answers with evidence from their portfolio of evidence.
The EPA method is being used because while programmers in the games industry spend most of their time developing software, it is their ability to work productively with a much wider team of creative people that determines their real value to a game studio. As such this assessment allows apprentices to draw upon a wider portfolio of work created after the gateway to relate their KSBs to experiences involving interdisciplinary teamworking and professionalism.
The professional discussion must be structured to give the apprentice the opportunity to demonstrate the KSBs mapped to this assessment method to the highest available grade.
An independent assessor must conduct and assess the professional discussion.
Questions must be asked. The purpose of questioning is:
The EPAO must give an apprentice 2 weeks' notice of the professional discussion.
The independent assessor must have at least 2 weeks to review the supporting documentation.
The apprentice must have access to their portfolio of evidence during the professional discussion.
The apprentice can refer to and illustrate their answers with evidence from their portfolio of evidence however, the portfolio of evidence is not directly assessed.
The professional discussion must last for 105 minutes. The independent assessor can increase the time of the professional discussion by up to 10%. This time is to allow the apprentice to respond to a question if necessary.
The independent assessor must ask at least 10 questions. The independent assessor must use the questions from the EPAO’s question bank.
The independent assessor must make the grading decision.
The independent assessor must keep accurate records of the assessment. They must record:
The professional discussion must take place in a suitable venue selected by the EPAO for example, the EPAO’s or employer’s premises.
The professional discussion can be conducted by video conferencing. The EPAO must have processes in place to verify the identity of the apprentice and ensure the apprentice is not being aided.
The professional discussion should take place in a quiet room, free from distractions and influence.
The EPAO must develop a purpose-built assessment specification and question bank. It is recommended this is done in consultation with employers of this occupation. The EPAO should maintain the security and confidentiality of EPA materials when consulting with employers. The assessment specification and question bank must be reviewed at least once a year to ensure they remain fit-for-purpose.
The assessment specification must be relevant to the occupation and demonstrate how to assess the KSBs mapped to this assessment method. The EPAO must ensure that questions are refined and developed to a high standard. The questions must be unpredictable. A question bank of sufficient size will support this.
The EPAO must ensure that apprentice has a different set of questions in the case of re-sits or re-takes.
The EPAO must produce the following materials to support the professional discussion (underpinned by portfolio):
The EPAO must ensure that the EPA materials are subject to quality assurance procedures including standardisation and moderation.
Fail - does not meet pass criteria
|
Theme
KSBs
|
Pass
Apprentices must demonstrate all of the pass descriptors
|
Distinction
Apprentices must demonstrate all of the pass descriptors and all of the distinction descriptors
|
|---|---|---|
|
(Core) Programming competencies
K1 K2 K9 S1 S8 S9 S16 B1 |
The Project incorporates the development of an interactive real time application for a gaming platform which uses the syntax and structure of an industry standard programming language. K1, K2, S1. The Project application is created using the common principles of games industry software design. K9. The Project application demonstrates the use of a well-tested, maintainable code which can be adapted to changing requirements and adopts an industry standard version control system. S8, S9. The Project demonstrates up to date studio coding methods/techniques which the apprentice can justify as being current and relevant. S16. Acts independently in applying objective judgements to create the application within given time constraints. B1. |
Critically evaluates their application design justifying their choice of language features and APIs. K1, K2, S1. Critically evaluates the ability of their code to be maintained and its potential to be adapted to changing requirements. S8, S9. |
|
(Core) Debugging, profiling and optimisation
K6 K7 S3 S4 S6 B7 |
The Project outlines the tools used to identify and optimise performance bottlenecks. K6. The Project demonstrates the use of debugging tools, crash reports, automated testing and continuous integration workflows. K7, S6. The Project demonstrates the use of profiling tools and techniques, tracking of memory usage and identifies opportunities to reduce requirements. S3, S4. Establishes a commitment to the standard produced in work tasks which reflects the guidelines set out by the company/organisation. B7. |
Evaluates the tools used to identify and optimise performance bottlenecks. K6. Critically analyses the role of debugging tools, crash reports, automated testing and continuous integration workflows. K7, S6. Critically analyses the application of proflling tools and techniques to achieve, monitor and maintain real-time frame rate. S3. |
|
(Game software programmer) Game programming
S18 S19 S20 B2 |
The Project demonstrates game programming using an industry standard or in-house game engine, their choice of different features and tools is justified in consideration of the impact on workload. S18, S19. The Project demonstrates a balance between player experience and extensibility/performance requirements for an evolving game design. S20. Establishes an approach to work tasks which reflects their own independent initiative and personal responsibility which adheres to the code of conduct/ethics set out by the company/organisation. B2 |
Critically analyses the game software to determine the extent it contributes to player experience and an evolving game design. S20.
|
|
(Game technology programmer) Technology programming
S23 S24 S25 |
The project develops reusable technologies that target hardware architectures and/or gaming platforms in the context of a user focused product team. S23, S25. The implementation of different features and their effect on quality is justified with respect to workload. S24. Establishes an approach to work tasks which reflects their own independent initiative and personal responsibility which adheres to the code of conduct/ethics set out by the company/organisation. B2. |
Critically evaluates reusable technologies that target hardware architectures and/or gaming platforms in the context of a user focused product team. S23, S25. Evaluates the implementation of different features and their effect on quality with respect to workload. S24. |
Fail - does not meet pass criteria
|
Theme
KSBs
|
Pass
Apprentices must demonstrate all of the pass descriptors
|
Distinction
Apprentices must demonstrate all of the pass descriptors and all of the distinction descriptors
|
|---|---|---|
|
(Core) Project management and methodologies
K8 K11 K12 K15 S7 S10 S12 S17 |
Describes the role of stages deployment, monitoring and analytics in releasing, tracking and refining games. K8. Demonstrates the application of industry standard game development methodologies. K12, S12. Demonstrates the use of a continuous integration workflow within the deployment lifecycle as part of a multidisciplinary software team. S7. Describes the role of rapid prototyping and agile approaches in innovation. K15. Demonstrates the application of version control and project management tools in the role of a developer. K11, S10. Describes the giving and receiving of feedback in code reviews in an objective and professional manner. S17. |
Critically evaluates the application of industry standard game development methodologies. K12, S12. Evaluates and justifies the application of version control and project management tools in the role of a developer. K11, S10. |
|
(Core) Creative teams and asset workflows
K10 K13 K18 S11 S13 S14 B3 |
Explains how an asset pipeline works for a game. K10. Outlines the multi-disciplinary roles involved in the game development process and evaluates their value in the production of a game. K13. Demonstrates the management of complex relationships with diverse stakeholders, leading modifications to existing tool chains or optimisations to workflows, and manages the associated communication, selecting technical and/or non-technical language in reflection of the audience. S11, S13, S14. Identifies the business stakeholders and business models for their own projects which can generate value. K18. Establishes an approach to working with colleagues within their own and related disciplines that follows the ethical guidelines/policies/procedures set out by the industry/organisation. B3. |
Reflects on their management of stakeholders and multi-disciplinary teams justifying how their approach generates value within the context of a business model. K18, S13. |
|
(Core) Professionalism
K14 K16 K17 K19 K20 S15 B4 B5 B6 |
Describes the sources of information for the latest innovations for the games industry and identifies the opportunities and threats presented by new technologies. K14, S15. Outlines the organisation's standards on coding, documentation and issue tracking and relates them to software industry practices. K16. Understands publishers' technical requirements for target platforms and where to obtain information and support. K17. Describes relevant data protection laws and practices, evaluations their relevance to the games industry and their relationship to security. K19, K20. Assumes responsibility for their personal development and records show the expertise gained is used to share with colleagues. B4. Uses a range of sources of information to demonstrate awareness of current trends in the gaming sector. B5. Establishes a workplace approach to personal data, safety, and security which follows ethical, legal and regulatory guidelines for the industry/sector/organisation. B6. |
Critically evaluates the current opportunities and threats to the organisation presented by new technologies. S15. |
|
(Core) Real - time graphical applications
K3 K4 K5 S2 S5 |
Demonstrates code which is informed by the characteristics of a hardware platform that supports real-time graphical applications. K4, S5. Applies and adapts real time algorithms in two and/or three dimensions. K3, S2. Balances quality and performance to achieve, monitor and maintain frame rates and memory footprints. K5. |
Critically evaluates their approach to creating interactive real- time graphical applications for modern hardware platforms. K4, S5. Evaluates how quality and performance are balanced to achieve, monitor and maintain frame rates and memory footprints. K5. |
|
(Game software programmer) Game programming
K21 K22 K23 S21 S22 |
Evaluates different game engines, third-party frameworks and tools with respect to accelerating the game development process. K21. Understands the trade-offs in time and resources that underpin the engineering and maintenance of a game’s asset pipeline. K22. Distinguishes the typical skillsets and expectations of different disciplines involved in the development process in terms of technologies, tools and asset formats. K23. Demonstrates working in an interdisciplinary team on game programming. S21. The software implements game mechanics which solve problems where solutions were previously unknown. S22.
|
Critically compares the relative merits of alternative game engines, third-party frameworks and tools with those used in house. K21. Evaluates the role of different disciplines involved in the development process and their typical skillsets and expectations in terms of technologies, tools and asset format. K23. Evaluates their solutions to design problems. S22. |
|
(Game technology programmer) Game technology
K24 K25 K26 S26 S27 |
Describes the specialist operation of specific hardware architectures or gaming platforms and how to engineer optimal solutions which target its specific capabilities. K24. Understands the trade-offs in time and resources to provide maximum benefit to users. K25. Explains how externally facing support portals and project tracking tools are used to track and document technologies for sharing with the user-base. K26. Communicates and evangelises the technology solutions and promotes engagement and uptake among the user-base. S26. Demonstrates the profiling and optimisation of code created by their technology users. S27. |
Critically compares hardware architecture or gaming platforms from other organisations with those used in-house. K24. Evaluates the role of support portals and issue tracking processes in working with a wide user-base. K26. |
Performance in the EPA determines the overall grade of:
An independent assessor must individually grade the: project with presentation and questions and professional discussion (underpinned by portfolio) in line with this EPA plan.
The EPAO must combine the individual assessment method grades to determine the overall EPA grade.
If the apprentice fails one assessment method or more, they will be awarded an overall fail.
To achieve an overall pass, the apprentice must achieve at least a pass in all the assessment methods. Any FAIL = Overall FAIL Project PASS + Discussion PASS = Overall PASS Project PASS + Discussion DISTINCTION = Overall MERIT Project DISTINCTION + Discussion PASS = Overall MERIT Project DISTINCTION + Discussion DISTINCTION = Overall DISTINCTION
Grades from individual assessment methods must be combined in the following way to determine the grade of the EPA overall.
| Project with presentation and questions | Professional discussion (underpinned by portfolio) | Overall Grading |
|---|---|---|
| Fail | Fail | Fail |
| Pass | Pass | Pass |
| Pass | Distinction | Merit |
| Distinction | Pass | Merit |
| Distinction | Distinction | Distinction |
If the apprentice fails one assessment method or more, they can take a re-sit or a re-take at their employer’s discretion. The apprentice’s employer needs to agree that a re-sit or re-take is appropriate. A re-sit does not need further learning, whereas a re-take does. The apprentice should have a supportive action plan to prepare for a re-sit or a re-take.
The employer and the EPAO should agree the timescale for a re-sit or re-take. A re-sit is typically taken within 2 months of the EPA outcome notification. The timescale for a re-take is dependent on how much re-training is required and is typically taken within 3 months of the EPA outcome notification.
If the apprentice fails the project assessment method, they must amend the project output in line with the independent assessor’s feedback. The apprentice will be given 2 weeks to rework and submit the amended software artefact .
Failed assessment methods must be re-sat or re-taken within a 6-month period from the EPA outcome notification, otherwise the entire EPA will need to be re-sat or re-taken in full.
Re-sits and re-takes are not offered to an apprentice wishing to move from pass to a higher grade.
The apprentice will get a maximum EPA grade of pass for a re-sit or re-take, unless the EPAO determines there are exceptional circumstances.
| Roles | Responsibilities |
|---|---|
|
Apprentice |
As a minimum, the apprentice should:
|
|
Employer |
As a minimum, the apprentice's employer must:
|
|
EPAO |
As a minimum, the EPAO must:
|
|
Independent assessor |
As a minimum, an independent assessor must:
|
|
Training provider |
As a minimum, the training provider must:
|
The EPAO must have reasonable adjustments arrangements for the EPA.
This should include:
Adjustments must maintain the validity, reliability and integrity of the EPA as outlined in this EPA plan.
Internal quality assurance refers to the strategies, policies and procedures that an EPAO must have in place to ensure valid, consistent and reliable EPA decisions.
EPAOs for this EPA must adhere to the requirements within the roles and responsibilities table.
They must also appoint independent assessors who:
should have three or more years professional experience as a programmer on an interdisciplinary game development team and have released at least one commercial title.
Affordability of the EPA will be aided by using at least some of the following:
This apprenticeship is not aligned to professional recognition.
| Knowledge | Assessment methods |
|---|---|
|
K1: Core.
How to approach the development of interactive, real-time applications for gaming platforms, including an awareness of industry-standard programming languages, application programming interfaces (APIs), tools, engines and frameworks. Back to Grading |
Project with presentation and questions |
|
K2: Core.
The syntax and structure of an industry-standard programming language (above and beyond visual programming languages) used for the development of games (for example C++, C#). Back to Grading |
Project with presentation and questions |
|
K3: Core.
The fundamental graphical and mathematical principles that underpin the operation of real-time graphics in two and three-dimensions. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K4: Core.
The characteristics of modern hardware platforms and how they support the efficient function of interactive, real-time graphical applications. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K5: Core.
Approaches to balancing quality and performance requirements to achieve, monitor and maintain acceptable frame rates and memory footprints for a real-time interactive application. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K6: Core.
How to use tools to identify and optimise performance bottlenecks in real-time applications. Back to Grading |
Project with presentation and questions |
|
K7: Core.
The role of debugging tools, crash reports, automated testing and continuous integration workflows in creating robust software. Back to Grading |
Project with presentation and questions |
|
K8: Core.
The role of staged deployment, monitoring and analytics in releasing, tracking and refining games. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K9: Core.
Common principles of good software design applied in the games industry including contrasting approaches and priorities (e.g. object-oriented vs. data-oriented) Back to Grading |
Project with presentation and questions |
|
K10: Core.
How a complete asset pipeline for a game operates, including the technical requirements, processing stages and tools involved in bringing assets into the game. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K11: Core.
How to use version control and project management tools to plan and coordinate the delivery of development tasks. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K12: Core.
Common development methodologies and how they are applied in game development. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K13: Core.
The broad range of roles involved in the game development process, and the different strengths and perspectives that multi-disciplinary teams bring to the creative process. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K14: Core.
Where to find information on the latest technological innovations for the games industry. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K15: Core.
The role of rapid prototyping and agile approaches in innovation. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K16: Core.
The organisation’s standards with respect to coding, documentation and issue tracking, and how they relate to wider practice in the software industries. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K17: Core.
Publisher’s technical requirements for target platforms, where to obtain them and the tools and systems available to support developers to meet those requirements. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K18: Core.
The business stakeholders in a project and how multi-disciplinary development teams can generate value within the context of different business models. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K19: Core.
Relevant data protection laws including GDPR. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K20: Core.
Security approaches to prevent products being compromised, and everyday good practice in security including password policies, phishing and use of VPNs. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K21: Game software programmer.
The relative merits of different game engines, third-party frameworks and tools, and when to use them to speed up the development process. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K22: Game software programmer.
How to balance the requirements and availability of team resources (for example staff time, software licencing) with respect to the engineering and maintenance of a game’s asset pipeline. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K23: Game software programmer.
The range of different disciplines involved in the development process and their typical skillsets and expectations in terms of technologies, tools and asset formats. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K24: Game technology programmer.
The specialist operation of a specific hardware architecture or gaming platform and how to engineer efficient solutions which target its specific capabilities. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K25: Game technology programmer.
How to balance the requirements and availability of team resources (staff time, software licencing) with respect to providing the maximum benefit to their users. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K26: Game technology programmer.
How to use externally facing support portals and project tracking tools in order to effectively track and document technologies for sharing with a wide user-base. Back to Grading |
Professional discussion (underpinned by portfolio) |
| Skill | Assessment methods |
|---|---|
|
S1: Core.
Program interactive, real-time applications for gaming platforms using an industry-standard programming language, incorporating APIs, tools, engines or frameworks appropriate to employer requirements. Back to Grading |
Project with presentation and questions |
|
S2: Core.
Implement and adapt contemporary real-time algorithms in two and three-dimensional games. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S3: Core.
Use profiling tools and techniques to achieve, monitor and maintain an acceptable real-time framerate for an interactive game. Back to Grading |
Project with presentation and questions |
|
S4: Core.
Track memory usage and identify opportunities for reducing requirements. Back to Grading |
Project with presentation and questions |
|
S5: Core.
Write code informed by the characteristics of modern hardware platforms (e.g. shader programming, multi-threading). Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S6: Core.
Use debugging tools and automated testing systems to develop robust code bases. Back to Grading |
Project with presentation and questions |
|
S7: Core.
Use continuous integration workflow within the deployment lifecycle as part of a multi-disciplinary software team. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S8: Core.
Write robust, well-tested, maintainable code which is easy to adapt to changing requirements. Back to Grading |
Project with presentation and questions |
|
S9: Core.
Use an industry-standard version control system. Back to Grading |
Project with presentation and questions |
|
S10: Core.
Use an industry-standard project management system from the perspective of a developer. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S11: Core.
Adapt or extend existing tool chains to support new features and/or optimise workflows. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S12: Core.
Apply industry-standard development methodologies within day-to-day working practice. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S13: Core.
Manage complex relationships with diverse stakeholders and communicate information effectively to different audiences. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S14: Core.
Provide technical leadership and direction with respect to the workflow of other team members. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S15: Core.
Research, document and articulate the opportunities and threats presented by new industry technologies. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S16: Core.
Follow studio coding best-practices and participate in keeping them relevant and up to date. Back to Grading |
Project with presentation and questions |
|
S17: Core.
Give and receive feedback in code reviews in an objective and professional manner. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S18: Game software programmer.
Develop games and/or prototypes using an industry-standard or in-house game engine. Back to Grading |
Project with presentation and questions |
|
S19: Game software programmer.
Make justified choices about the implementation of different features and tools and their effect on the overall workload of the team. Back to Grading |
Project with presentation and questions |
|
S20: Core.
Write software which contributes to the player experience while balancing the extensibility and performance requirements for an evolving game design. Back to Grading |
Project with presentation and questions |
|
S21: Game software programmer.
Work as part of interdisciplinary teams. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S22: Game software programmer.
Create innovative game mechanics for which solutions are unknown. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S23: Game technology programmer.
Develop reusable technologies targeting specific hardware architectures or gaming platforms. Back to Grading |
Project with presentation and questions |
|
S24: Game technology programmer.
Make justified decisions about the implementation of different features and their effect on quality and workload for their technology’s user base. Back to Grading |
Project with presentation and questions |
|
S25: Game technology programmer.
Work as part of a user-focused product team, incorporating multi-disciplinary input from outside of the team, for example from game software programmers, artists, game designers and audio engineers. Back to Grading |
Project with presentation and questions |
|
S26: Game technology programmer.
Communicate and evangelise technology solutions to promote engagement and uptake among the user-base. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S27: Game technology programmer.
Profile and optimise code created by their technology users. Back to Grading |
Professional discussion (underpinned by portfolio) |
| Behaviour | Assessment methods |
|---|---|
|
B1: Core.
Reliable, objective and capable of independent working. Back to Grading |
Project with presentation and questions |
|
B2: Core.
Initiative and personal responsibility to overcome challenges and take ownership for project solutions. Back to Grading |
Project with presentation and questions |
|
B3: Core.
Respect for other disciplines and an understanding of the role of diverse experiences and backgrounds in a successful creative process. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
B4: Core.
Commitment to continuous professional development; maintaining their knowledge and skills in relation to technology developments, and sharing best practice in their organisation around all aspects of game development. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
B5: Core.
Maintains awareness of trends and innovations in the subject area, utilizing a range of academic literature, online sources, community interaction and conference attendance. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
B6: Core.
Acts with integrity with respect to ethical, legal and regulatory ensuring the protection of personal data, safety and security. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
B7: Core.
A strong work ethic and commitment in order to meet the standards required. Back to Grading |
Project with presentation and questions |
| KSBS GROUPED BY THEME | Knowledge | Skills | Behaviour |
|---|---|---|---|
|
(Core) Programming competencies
K1 K2 K9 S1 S8 S9 S16 B1 |
How to approach the development of interactive, real-time applications for gaming platforms, including an awareness of industry-standard programming languages, application programming interfaces (APIs), tools, engines and frameworks. (K1) The syntax and structure of an industry-standard programming language (above and beyond visual programming languages) used for the development of games (for example C++, C#). (K2) Common principles of good software design applied in the games industry including contrasting approaches and priorities (e.g. object-oriented vs. data-oriented) (K9) |
Program interactive, real-time applications for gaming platforms using an industry-standard programming language, incorporating APIs, tools, engines or frameworks appropriate to employer requirements. (S1) Write robust, well-tested, maintainable code which is easy to adapt to changing requirements. (S8) Use an industry-standard version control system. (S9) Follow studio coding best-practices and participate in keeping them relevant and up to date. (S16) |
Reliable, objective and capable of independent working. (B1) |
|
(Core) Debugging, profiling and optimisation
K6 K7 S3 S4 S6 B7 |
How to use tools to identify and optimise performance bottlenecks in real-time applications. (K6) The role of debugging tools, crash reports, automated testing and continuous integration workflows in creating robust software. (K7) |
Use profiling tools and techniques to achieve, monitor and maintain an acceptable real-time framerate for an interactive game. (S3) Track memory usage and identify opportunities for reducing requirements. (S4) Use debugging tools and automated testing systems to develop robust code bases. (S6) |
A strong work ethic and commitment in order to meet the standards required. (B7) |
|
(Game software programmer) Game programming
S18 S19 S20 B2 |
None |
Develop games and/or prototypes using an industry-standard or in-house game engine. (S18) Make justified choices about the implementation of different features and tools and their effect on the overall workload of the team. (S19) Write software which contributes to the player experience while balancing the extensibility and performance requirements for an evolving game design. (S20) |
Initiative and personal responsibility to overcome challenges and take ownership for project solutions. (B2) |
|
(Game technology programmer) Technology programming
S23 S24 S25 |
None |
Develop reusable technologies targeting specific hardware architectures or gaming platforms. (S23) Make justified decisions about the implementation of different features and their effect on quality and workload for their technology’s user base. (S24) Work as part of a user-focused product team, incorporating multi-disciplinary input from outside of the team, for example from game software programmers, artists, game designers and audio engineers. (S25) |
None |
| KSBS GROUPED BY THEME | Knowledge | Skills | Behaviour |
|---|---|---|---|
|
(Core) Project management and methodologies
K8 K11 K12 K15 S7 S10 S12 S17 |
The role of staged deployment, monitoring and analytics in releasing, tracking and refining games. (K8) How to use version control and project management tools to plan and coordinate the delivery of development tasks. (K11) Common development methodologies and how they are applied in game development. (K12) The role of rapid prototyping and agile approaches in innovation. (K15) |
Use continuous integration workflow within the deployment lifecycle as part of a multi-disciplinary software team. (S7) Use an industry-standard project management system from the perspective of a developer. (S10) Apply industry-standard development methodologies within day-to-day working practice. (S12) Give and receive feedback in code reviews in an objective and professional manner. (S17) |
None |
|
(Core) Creative teams and asset workflows
K10 K13 K18 S11 S13 S14 B3 |
How a complete asset pipeline for a game operates, including the technical requirements, processing stages and tools involved in bringing assets into the game. (K10) The broad range of roles involved in the game development process, and the different strengths and perspectives that multi-disciplinary teams bring to the creative process. (K13) The business stakeholders in a project and how multi-disciplinary development teams can generate value within the context of different business models. (K18) |
Adapt or extend existing tool chains to support new features and/or optimise workflows. (S11) Manage complex relationships with diverse stakeholders and communicate information effectively to different audiences. (S13) Provide technical leadership and direction with respect to the workflow of other team members. (S14) |
Respect for other disciplines and an understanding of the role of diverse experiences and backgrounds in a successful creative process. (B3) |
|
(Core) Professionalism
K14 K16 K17 K19 K20 S15 B4 B5 B6 |
Where to find information on the latest technological innovations for the games industry. (K14) The organisation’s standards with respect to coding, documentation and issue tracking, and how they relate to wider practice in the software industries. (K16) Publisher’s technical requirements for target platforms, where to obtain them and the tools and systems available to support developers to meet those requirements. (K17) Relevant data protection laws including GDPR. (K19) Security approaches to prevent products being compromised, and everyday good practice in security including password policies, phishing and use of VPNs. (K20) |
Research, document and articulate the opportunities and threats presented by new industry technologies. (S15) |
Commitment to continuous professional development; maintaining their knowledge and skills in relation to technology developments, and sharing best practice in their organisation around all aspects of game development. (B4) Maintains awareness of trends and innovations in the subject area, utilizing a range of academic literature, online sources, community interaction and conference attendance. (B5) Acts with integrity with respect to ethical, legal and regulatory ensuring the protection of personal data, safety and security. (B6) |
|
(Core) Real - time graphical applications
K3 K4 K5 S2 S5 |
The fundamental graphical and mathematical principles that underpin the operation of real-time graphics in two and three-dimensions. (K3) The characteristics of modern hardware platforms and how they support the efficient function of interactive, real-time graphical applications. (K4) Approaches to balancing quality and performance requirements to achieve, monitor and maintain acceptable frame rates and memory footprints for a real-time interactive application. (K5) |
Implement and adapt contemporary real-time algorithms in two and three-dimensional games. (S2) Write code informed by the characteristics of modern hardware platforms (e.g. shader programming, multi-threading). (S5) |
None |
|
(Game software programmer) Game programming
K21 K22 K23 S21 S22 |
The relative merits of different game engines, third-party frameworks and tools, and when to use them to speed up the development process. (K21) How to balance the requirements and availability of team resources (for example staff time, software licencing) with respect to the engineering and maintenance of a game’s asset pipeline. (K22) The range of different disciplines involved in the development process and their typical skillsets and expectations in terms of technologies, tools and asset formats. (K23) |
Work as part of interdisciplinary teams. (S21) Create innovative game mechanics for which solutions are unknown. (S22) |
None |
|
(Game technology programmer) Game technology
K24 K25 K26 S26 S27 |
The specialist operation of a specific hardware architecture or gaming platform and how to engineer efficient solutions which target its specific capabilities. (K24) How to balance the requirements and availability of team resources (staff time, software licencing) with respect to providing the maximum benefit to their users. (K25) How to use externally facing support portals and project tracking tools in order to effectively track and document technologies for sharing with a wide user-base. (K26) |
Communicate and evangelise technology solutions to promote engagement and uptake among the user-base. (S26) Profile and optimise code created by their technology users. (S27) |
None |
Contact us about this apprenticeship
| Version | Change detail | Earliest start date | Latest start date | Latest end date |
|---|---|---|---|---|
| 1.2 | End-point assessment plan revised. | 13/02/2023 | Not set | Not set |
| 1.1 | End-point assessment plan revised | 26/01/2023 | 12/02/2023 | Not set |
| 1.0 | Approved for delivery | 03/08/2021 | 25/01/2023 | Not set |
Crown copyright © 2024. You may re-use this information (not including logos) free of charge in any format or medium, under the terms of the Open Government Licence. Visit www.nationalarchives.gov.uk/doc/open-government-licence