This is not the latest approved version of this apprenticeship. View the latest version

This apprenticeship has been retired

Key information

  1. Status: Retired
  2. Reference: ST0953
  3. Version: 1.0
  4. Level: 7
  5. Degree: non-degree qualification
  6. Typical duration to gateway: 24 months
  7. Typical EPA period: 6 months
  8. Maximum funding: £19000
  9. Route: Digital
  10. Date updated: 03/01/2023
  11. Lars code: 650
  12. EQA provider: Ofqual
  13. Review:

    This apprenticeship standard will be reviewed after three years.

This apprenticeship has options. This document is currently showing the following option:

Hide contents

Contents

Hide contents

Contents

Print apprenticeship summary

Apprenticeship summary

Overview of the role

Program reliable and efficient software.

Occupation summary

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.

Typical job titles include:

Developer relations engineer Game programmer Game server programmer Gameplay engineer Gameplay programmer Mobile game developer Rendering / graphics engineer Software development engineer

Duties

  • 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 10 (Game software programmer) 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 (Game software programmer) 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 (Game software programmer) Work collaboratively with other developers to maximise the combined value of the team’s effort to the player experience.
  • Duty 13 (Game technology programmer) 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 (Game technology programmer) 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 (Game technology programmer) Work collaboratively with a wide user-base to support their use of technologies and inform and improve their design and documentation.

Apprenticeship summary

ST0953, game programmer level 7


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.

What is an end-point assessment and why it happens

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:

  • fail
  • pass
  • merit
  • distinction

When you pass the EPA, you will be awarded your apprenticeship certificate.

EPA gateway

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:

  • achieved English and mathematics qualifications in line with the apprenticeship funding rules
  • for the project with presentation and questions, the project's title and scope must be agreed with the EPAO and a project summary submitted

  • for the professional discussion (underpinned by portfolio), the project's title and scope must be agreed with the EPAO and a project summary submitted

Assessment methods




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 0 (with a 10% tolerance).




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


You will have a professional professional discussion with an independent assessor. It will last 90 minutes. They will ask you at least 10 questions. The questions will be about certain aspects of your occupation. You can use it to help answer the questions.


The EPAO will confirm where and when each assessment method will take place.

Who to contact for help or more information

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.


Reasonable adjustments


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.

Print occupational standard

Details of the occupational standard

Occupation summary

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.

Typical job titles include:

Developer relations engineer Game programmer Game server programmer Gameplay engineer Gameplay programmer Mobile game developer Rendering / graphics engineer Software development engineer

Core occupation duties

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

K1 K3 K4 K5 K9

S1 S2 S5

B1 B2 B7

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.

K1 K2 K4 K5 K6 K7 K8 K9

S1 S3 S4 S5 S6 S8 S20

B7

Duty 3 Diagnose and fix errors in complex technical systems that involve many interacting factors, making use of automated testing systems to optimise workflows.

K2 K5 K6 K7 K8

S2 S3 S6 S8 S11 S17

B7

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.

K1 K5 K8 K12

S5 S11 S20

B1 B2 B7

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.

K7 K8 K11 K12 K17 K18

S9 S10 S11 S12 S14

B1 B7

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.

K4 K5 K7 K8 K9 K10 K11 K12 K13 K14 K17 K18 K19 K20

S3 S7 S9 S11 S12 S13 S14

B1 B3 B4 B5 B6 B7

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.

K7 K8 K14 K16 K17 K19 K20

S6 S13 S17

B1 B4 B5 B6 B7

Duty 8 Lead research into new technologies and identify opportunities for their potential application within the business.

K15

S15 S16

B1 B2 B4 B5 B7

Duty 9 Practice continuous self-learning to keep up to date with latest industry developments, and support their effective communication within the organisation.

K14 K15

S16 S17

B5 B6 B7

Option duties

Game software programmer duties

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.

K1 K3 K4 K5 K6 K21

S5 S18 S20 S22

B7

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.

K4 K5 K9 K10 K12 K13 K22

S4 S11 S14 S19 S20

B1 B2 B7

Duty 12 Work collaboratively with other developers to maximise the combined value of the team’s effort to the player experience.

K5 K13 K18 K23

S7 S13 S14 S18 S19 S20 S21

B1 B3 B7

Game technology programmer duties

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.

K1 K3 K4 K5 K6 K24

S5 S23

B7

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.

K4 K5 K9 K12 K13 K25

S4 S14 S24

B1 B2 B7

Duty 15 Work collaboratively with a wide user-base to support their use of technologies and inform and improve their design and documentation.

K5 K10 K13 K18 K26

S7 S11 S13 S14 S24 S25 S26 S27

B1 B3 B7

KSBs

Knowledge

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

Skills

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

Behaviours

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

Qualifications

English and Maths

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.

Print EPA plan

End-point assessment plan

V1.0

Introduction and overview

This document sets out the requirements for end-point assessment (EPA) for the game programmer apprenticeship standard. It explains how EPA for this apprenticeship must operate.

It provides the EPA design requirements for end-point assessment organisations (EPAOs) for this apprenticeship standard. It will also be useful for apprentices undertaking this apprenticeship, their employers and training providers.

The EPA must be conducted by an EPAO approved to deliver EPA for this apprenticeship standard. Each employer should select an approved EPAO from the Education & Skills Funding Agency’s Register of end-point assessment organisations (RoEPAO).

Game programmer is a core and options apprenticeship standard. Apprentices must be trained and assessed against the core and options, either:

  • Game programming
  • Technology programming

Full-time apprentices will typically spend 24 months on-programme (before the gateway) working towards this occupational standard. All apprentices must spend a minimum of 12 months on programme.

All apprentices must spend a minimum of 20% of on-programme time undertaking off-the-job training.

Before starting EPA, an apprentice must meet the gateway requirements. For this apprenticeship they are:

  • The employer must be content that the apprentice is working at or above the occupational standard
  • apprentices must submit a portfolio of evidence to underpin the professional discussion
  • apprentices must have achieved English and Mathematics at Level 21

The EPAO must confirm that all required gateway evidence has been provided and accepted as meeting the gateway requirements. The EPAO is responsible for confirming gateway eligibility. Once this has been confirmed, the EPA period starts. This EPA should then be completed within an EPA period lasting typically for 6 months.

This EPA consists of 2 discrete assessment methods.

It will be possibble to achieve the following grades in each end-point assessment method:

EPA method 1 - project with presentation and questions:

  • fail
  • pass
  • distinction

EPA method 2 - professional discussion (underpinned by portfolio):

  • fail
  • pass
  • distinction

Performance in these end-point assessment methods will determine the overall apprenticeship standard grade of:

  • fail
  • pass
  • merit
  • distinction

EPA summary table

On-programme - typically 24 months

Training to develop the knowledge, skills and behaviours (KSBs) of the occupational standard.

Training towards English and mathematics qualifications at Level 21, if required.

Compiling a portfolio of evidence.

End-point assessment gateway

The employer must be content that the apprentice is working at or above the level of the occupational standard.

Apprentices must have achieved English and mathematics at Level 21.

For the project with presentation and questions, the apprentice will be required to submit the following supporting material: project brief requirements.

For the professional discussion (underpinned by portfolio), the apprentice will be required to submit a portfolio of evidence to underpin the professional discussion.

End-point assessment - typically 6 months

Grades available for each method:

Project with presentation and questions

  • fail
  • pass
  • distinction

Professional discussion (underpinned by portfolio)

  • fail
  • pass
  • distinction

Overall EPA and apprenticeship can be graded:

    • fail
    • pass
    • merit
    • distinction
Re-sits and re-takes
  • Re-take and re-sit grade cap: pass
  • Re-sit timeframe: typically 2 month(s)
  • Re-take timeframe: typically 3 month(s)

Duration of end-point assessment period

The EPA will be taken within an EPA period lasting typically for 6 months, starting when the EPAO confirms the gateway requirements are met.

Any supporting material which underpins an EPA assessment method should be submitted at the Gateway.

EPA gateway

The apprentice’s employer must confirm that they think the apprentice is working at or above the occupational standard as a game programmer. They will then enter the gateway. In making this decision, the employer may take advice from the apprentice's training provider(s), but the employer must make the decision.

The EPAO determines when all gateway requirements have been met, and the EPA period will only start once the EPAO has confirmed this.

In addiition to the employer's confirmation that the apprentice is working at or above the level of the occupational standard apprentices must meet the following gateway requirements before starting their EPA.

These are:

  • achieved English and mathematics at Level 21.
  • for the project with presentation and questions apprentices must submit: project brief.

  • A project brief will be submitted to the EPAO at the gateway, thereby allowing the EPAO to agree the project's subject, title and scope. Following the gateway, the EPAO will confirm the title of the project within 2 weeks of the gateway to ensure suficient scope to meet the KSBs mapped to this assessment method.
  • The project brief must scope out the work-based project and should include a summary of the stages to be covered by the work-based project and an overview of the tasks as well as the specific responsibilities and duties assigned and to be undertaken by the apprentice.

  • for the professional discussion (underpinned by portfolio) apprentices must submit: portfolio of evidence to underpin the professional discussion.

Portfolio of evidence requirements:

  • Apprentices must compile a portfolio of evidence during the on-programme period of the apprenticeship. It should contain evidence related to the KSBs that will be assessed by the professional discussion (underpinned by portfolio). The portfolio of evidence will typically contain 12 discrete pieces of evidence. Evidence should 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: source code,executables, prototypes, screen recordings, project repositories, briefs, meeting minutes, audio clips. Feedback from colleagues and clients may also be included. Video clips should not exceed 10 minutes in total and should be carefully edited to highlight the pertinent features; a video screen capture with a voice-over by the apprentice can be used but the apprentice would need to initially identify themselves on camera before commencing.
  • This is not a definitive list; other evidence sources can be included.
  • The portfolio should not include refiective 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 EPA period starts when the EPAO confirms all gateway requirements have been met. The expectation is they will do this as quickly as possible.

The portfolio of evidence is not directly assessed. It underpins the professional discussion and therefore should not be marked by the EPAO. EPAOs should review the portfolio of evidence in preparation form the professional discussion but are not requireed to provide feedbakc after this review of the portfolio.

Order of assessment methods

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.

Project with presentation and questions

Overview

A project involves the apprentice completing a significant and defined piece of work that has a real business application and benefit. The project must start after the apprentice has gone through the gateway.

The project should be designed to ensure that the apprentice's work meets the needs of a business, is relevant to their role and allows the relevant KSBs to be the assessed for the EPA. The employer will ensure it has a real business application and the EPAO will ensure it meets the requirements of the EPA, including suitable coverage of the KSBs assigned to this assessment method as shown in the mapping of assessment methods. The EPAO must refer to the grading descriptors to ensure that projects are pitched appropriately.

This EPA method includes 2 component(s):

  • project with a project output
  • presentation with questions and answers.

Rationale

The rationale for this assessment method is:

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 project and any components must be assessed holistically by the independent assessor when they are decising the grade for this EPA method.

Component 1: Project with a project output

Delivery

Apprentices must complete a project which may be based on any of the following:

  • a specific problem
  • a recurring issue
  • an idea or opportunity.

The project may also be based on:

  • a development of live product where it is appropriate to do so. Where client confidentiatlity requires it the system may be demonstrated in a test harness, or using placeholder/white box assests which conceal the product and/or client.

Typical project titles could include:

  • A Third-Person close-Combat mechanic
  • An Aeriel Combat Mechanic
  • Procedurally Generated Level Content
  • Destructible objects
  • A Shader-Based Visual Effect
  • Parallelisation of an Existing Process.

To ensure the project allows the apprentice to meet the KSBs mapped to this EPA 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 project output must be in the form of a software artefact.

The apprentice must start the project after the gateway. They must complete and submit the software artefact to the EPAO after a maximum of 12 weeks. The employer should ensure the apprentice has the time and resources within this period, to plan and complete their project. The apprentice must complete their project and the production of all its components unaided.

The apprentice may work as part of a team which could include technical internal or external support. However, the project output must be the apprentice’s own work and will be reflective of their own role and contribution. The apprentice and their employer must confirm that the project output(s) is the apprentice’s own work when it is submitted.

The minimum requirements software artefact are

  • A complete working technical system, or collection of systems which executes and produces a verifiable outcome. Vertification 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 repsoitory evidencing its iterative development by the apprentice over the asesessment period, and not just the final codebase.
  • Typically the software artfeact would be a real-time system, but it could also be something which creates data for or from a real-time system.

Component 2: Presentation with questioning

Overview

Apprentices will be required to produce, subit and deliver a presenation to the independent assessor. A copy of the presentation must be submitted to the EPAO at the same time as the project and project output(s); 12 weeks after the gateway.

The independent assessor must have a minimum of 2 weeks to review the software artefact and copy of the presentation in advance of the presentation in order to prepare apropriate questions.

The presentation will provide an overview of the apprentice's project outpu(s). This will be followed by questioning by the indepndent assessor.

As a minimum, all presentations must include:

  • An overview of the project
  • The project scope (including key performance indicators)
  • Summary of actions undertaken by the apprentice
  • Project outcomes and how these were achieved.

The presentation should require the apprentice to fully demonstrate the KSBs that are mapped to this assessment method.

Delivery

The presentation will provide an overview of the apprentice's project and the software artefact. Independent assessors will ask questions after the presentation.

The presentation will be arranged by the EPAO in consultation with the employer. It will be presented to an independent assessor on a one-to-one basis, either face-to-face or via online video conferencing. If using an online platform, EPAOs must ensure appropriate measures are in place to prevent misrepresntation.

The presentation and questioning must last 90 minutes This will typically include a presentation of 45 minutes and questioning lasting 45 minutes. The independent assessor has the discretion to increase the total time of the presentation and questioning by up to 10% to allow the apprentice to complete their last point. Further time may be granted for apprentices with additional needs, in-lin with the EPAO's reasonable adjustments policy.

Questions must be asked: The purpose of questioning is:

  • To verify that the software artefact was created by the apprentice
  • To follow up on any areas of KSbs that the assessor feels haven't been sufficently covered in the presentation.

The independent assessor must ask at least 5 questions. Questions may be taken from an EPAO question bank or be generated by the independent assesor. Independent assessors must use the question bank as a source for questioning and are expected to use their professional judgement to tailor those questions appropriately. Follow up questions are permitted where clairifcation is required. Independent assessors are responsbile for generating suitable follow-up questions in line with the EPAO's training and standardisation process. Quesions must be designed to allow the apprentice to demonstrate the KSBs mapped to the assessment method. Questions must be open and should be holistic in nature to enable the apprentice to cover several KSBs as part of their response.

KSBs observed, and answers to questions must be recorded by the independent assessor. The independent assesor will make all grading decisions.

The independent assesor must use the full time available for questioning to allow the apprentice the opportunity to evidence occupational comptence at the highest level available, unless the apprentice has already acheived the highest grade available.

Those KSBs that the apprentice did not have the opportunity to demonstrate during the project, product output(s) and/or presentation can instead be covered by questioning, although these should be kept to a minimum.

To deliver the presentation, the apprentice will have access to:

  • A PowerPoint or equivalent presentation software
  • Source control archives for the project or suitable visual evidence of their use
  • An appropriate development environment for explaining and demonstrating code
  • Computer with internet connection.

KSBs met and ansers to questions must be recorded by the independent assessor. The independent assesseor will make all grading decisions. Apprentices must be given at least 2 weeks notice of the assessment method.

Assessment location

The presentation with questioning must take place in a suitable venue selected by the EPAO for example the EPAO's or employers premises. The presentation with questioning should take place in a quiet room, free from distractions and influence.

Question and resource development

Questions must be written by EPAOs, be relevant to the occupation and assess the KSBs mapped to this project with presentation and questions. It is recommended that this be done in consultation with employers of this occupation. EPAO's should maintain the security and confidentiality of their questions when consulting employers.

Each EPAO must develop a question bank of sufficient size to prevent predictability and review it regularly (at least once a year) to ensure it, and the questions it contain, are fit for purpose.

EPAOs must ensure that apprentices have a different set of questions in the case of re-sits or re-takes. .

  • independent assessor EPA materials which include:
    • training materials
    • administration materials
    • moderation and standardisation materials
    • guidance materials
    • grading guidance
    • question bank
  • EPA guidance for the apprentice and employer.

Independent assessors are responsible for generating suitable follow-up questions in line with the EPAO's training and standardisation process. Questions must be designed to allow the apprentice to demonstrate the KSBs mapped to the assessment method. Questions must be open and should be holistic in nature to enable the apprentice to cover several KSBs as part of their response.

Professional discussion (underpinned by portfolio)

Overview

In a professional discussion, an independent assessor and apprentice have a formal two-way conversation. It gives the apprentice the opportunity to demonstrate their competency across the KSBs as shown in the mapping.

Rationale

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.

Delivery

A professional discussion must be structured to give the apprentice the opportunity to demonstrate the KSBs mapped to this EPA method to the highest available grade.

Questions must be asked. The purpose of questioning is:

  • to explore the apprentice's experience and understanding in which they apply the KSBs in a work context.

The EPAO must give an apprentice 2 weeks notice of the date and time of the professional discussion.

Apprentices must have access to their portfolio of evidence to underpin the professional discussion during the professional discussion.

Apprentices 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 90 minutes. The independent assessor can increase the time of the professional discussion by up to 10%. This time is to allow the apprentice to a complete their last point.

For the professional discussion, the independent assessor must ask at least 10 questions.

Questions may be taken from an EPAO question bank or be generated by the independent assessor. Independent assessors must use the question bank as a source for questioning and are expected to use their professional judgement to tailor those questions appropriately. Follow-up questions are permitted where clarification is required. Independent assessors are responsible for generating suitable follow-up questions in line with the EPAO’s training and standardisation process. Questions must be designed to allow the apprentice to demonstrate the KSBs mapped to the assessment method. Questions must be open and should be holistic in nature to enable the apprentice to cover several KSBs as part of their response.

The independent assessor conducts and assesses the professional discussion.

The independent assessor must keep accurate records of the assessment. The records must include the KSBs met, the grade achieved and answers to questions.

The professional discussion can be conducted by video conferencing. The EPAO must have the processes in place to verify the identity of the apprentice to ensure the apprentice is not being aided.

The independent assessor will make all grading decisions.

Assessment location

The professional discussion must take place in a suitable venue selected by the EPAO. The venue could be the EPAO's or employer's premises. The professional discussion should take place in a quiet room, free from distractions and influence.

The assessment method can take place in any of the following locations:

  • employer's premises
  • other suitable location determined by the EPAO (e.g. assessment centre or training provider)
  • via video conferencing

Video conferencing can be used to conduct the professional discussion, but the EPAO must have processes in place to verify the identity of the apprentice and ensure the apprentice is not being aided.

Question and resource development

EPAOs must write an assessment specification and question bank. The specification must be relevant to the occupation and demonstrate how to assess the KSBs shown in the mapping. It is recommended this is done in consultation with employers of this occupation. EPAOs should maintain the security and confidentiality of EPA materials when consulting employers. The questions must be unpredictable. A question bank of sufficient size will support this. The assessment specification and questions must be reviewed at least once a year to ensure they remain fit-for-purpose.

EPAOs will develop purpose-built question banks and ensure that appropriate quality assurance procedures are in place. For example, considering standardisation, training and moderation. EPAOs will ensure that questions are refined and developed to a high standard.

EPAOs must ensure that apprentices have a different set of questions in the case of re-sits or re-takes.

EPAOs must produce the following materials to support the professional discussion (underpinned by portfolio):

  • Independent assessor assessment materials which include:
    • training materials
    • administration materials
    • moderation and standardisation materials
    • guidance materials
    • grading guidance
    • question bank
  • EPA guidance for the apprentice and employer.

Grading

Project with presentation and questions

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) Real-time graphical applications
K3 K4 K5 S2 S5

The Project demonstrates code which is informed by the characteristics of a hardware platform that supports real-time graphical applications. K4, S5.

The Project applies and adapts real time algorithms in two and/or three dimensions. K3, S2.

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

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

The software implements game mechanics which solve problems where solutions were previously unknown. S22.

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.

Evaluates their solutions to design problems. S22.

(Game technology programmer) Technology programming
S23 S24 S25 B2

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.

Professional discussion (underpinned by portfolio)

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.

(Game software programmer) Game programming
K21 K22 K23 S21

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.

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.

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

Overall EPA grading

All assessment methods are weighted equally in their contribution to the overall EPA grade.

Performance in the EPA will determine the apprenticeship grade of fail, pass, merit or distinction. Independent assessors must individually grade each assessment method, according to the requirements set out in this plan.

EPAOs must combine the individual assessment method grades to determine the overall EPA grade. Apprentices who fail one of more assessment method will be awarded an overal EPA 'fail

In order to achieve an overall EPA grade, apprentices must achieve:
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

Re-sits and re-takes

Apprentices who fail one or more assessment method(s) will be offered the opportunity to take a re-sit or a re-take at the employer’s discretion. The apprentice’s employer will need to agree that either a re-sit or re-take is an appropriate course of action.

A re-sit does not require further learning, whereas a re-take does.

Apprentices should have a supportive action plan to prepare for a re-sit or a re-take.

The employer and EPAO 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. 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.

Failed EPA 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 apprentices wishing to move from pass to a higher grade.

Where any assessment method has to be re-sat or re-taken, the apprentice will be awarded a maximum EPA grade of Pass, unless the EPAO determines there are exceptional circumstances.

Roles and responsibilities

Roles Responsibilities

Apprentice

As a minimum, apprentices should:

  • participate in and complete on-programme training to meet the KSBs as outlined in the occupational standard for a minimum of 12 months
  • undertake 20% off-the-job training as arranged by the employer and training provider
  • understand the purpose and importance of EPA
  • undertake the EPA including meeting all gateway requirements.

Employer

As a minimum, employers should:

  • select the EPAO and training provider 
  • work with the training provider (where applicable) to support the apprentice in the workplace and to provide the opportunities for the apprentice to develop the KSBs
  • arrange and support a minimum of 20% off-the-job training to be undertaken by the apprentice 
  • decide when the apprentice is working at or above the occupational standard and so is ready for EPA
  • ensure that all supporting evidence required at the gateway is submitted in accordance with this EPA plan
  • remain independent from the delivery of the EPA
  • confirm arrangements with the EPAO for the EPA (who, when, where) in a timely manner (including providing access to any employer-specific documentation as required, for example company policies)
  • ensure that the EPA is scheduled with the EPAO for a date and time which allows appropriate opportunity for the KSBs to be met
  • ensure the apprentice is well prepared for the EPA
  • ensure the apprentice is given sufficient time away from regular duties to prepare for, and complete all post-gateway elements of the EPA, and that any required supervision during this time (as stated within this EPA plan) is in place
  • where the apprentice is assessed in the workplace, ensure that the apprentice has access to the resources used on a daily basis
  • pass the certificate to the apprentice upon receipt from the EPAO.

EPAO

As a minimum, EPAOs should:

  • conform to the requirements of this EPA plan and deliver its requirements in a timely manner
  • conform to the requirements of the Register of End-Point Assessment Organisations (RoEPAO)
  • conform to the requirements of the external quality assurance provider (EQAP) for this apprenticeship standard
  • understand the occupational standard
  • make all necessary contractual arrangements, including agreeing the price of the EPA
  • develop and produce assessment materials including specifications and marking materials (for example mark schemes, practice materials, training material)
  • appoint suitably qualified and competent independent assessors
  • appoint administrators (and invigilators where required) to administer the EPA as appropriate
  • provide training for independent assessors in terms of good assessment practice, operating the assessment tools and grading
  • provide adequate information, advice and guidance documentation to enable apprentices, employers and training providers to prepare for the EPA
  • arrange for the EPA to take place, in consultation with the employer
  • where the apprentice is not assessed in the workplace, ensure that the apprentice has access to the required resources and liaise with the employer to agree this if necessary
  • develop and provide appropriate assessment recording documentation to ensure a clear and auditable process is in place for providing assessment decisions and feedback to all relevant stakeholders
  • have no direct connection with the apprentice, their employer or training provider. In all instances, including when the EPAO is the training provider (i.e. HEI), there must be no conflict of interest
  • have policies and procedures for internal quality assurance (IQA), and maintain records of regular and robust IQA activity and moderation for external quality assurance (EQA) purposes
  • deliver induction training for independent assessors, and for invigilators and/or markers (where used)
  • undertake standardisation activity on this apprenticeship standard for all independent assessors before they conduct an EPA for the first time, if the EPA is updated and periodically as appropriate (a minimum of annually)
  • manage invigilation of apprentices in order to maintain security of the assessment in line with the EPAO’s malpractice policy
  • verify the identity of the apprentice being assessed
  • use language in the development and delivery of the EPA that is appropriate to the level of the occupational standard
  • provide details of the independent assessor’s name and contact details to the employer
  • have, and apply appropriately, an EPA appeals process
  • request certification via the Apprenticeship Service upon successful achievement of the EPA.
  • agree the EPA price

Independent assessor

As a minimum, independent assessors should:

  • have the competence to assess the apprentice at this level and hold any required qualifications and experience in line with the requirements of the independent assessor as detailed in the IQA section of this EPA plan
  • understand the occupational standard and the requirements of this EPA
  • have, maintain and be able to evidence, up-to-date knowledge and expertise of the subject matter
  • deliver the end-point assessment in-line with the EPA plan
  • comply with the IQA requirements of the EPAO
  • have no direct connection or conflict of interest with the apprentice, their employer or training provider; in all instances, including when the EPAO is the training provider (i.e. HEI)
  • attend induction training
  • attend standardisation events when they begin working for the EPAO, before they conduct an EPA for the first time and a minimum of annually on this apprenticeship standard
  • assess each assessment method, as determined by the EPA plan, and without extending the EPA unnecessarily
  • assess against the KSBs assigned to each assessment method, as shown in the mapping of assessment methods and as determined by the EPAO, and without extending the EPA unnecessarily
  • make all grading decisions
  • record and report all assessment outcome decisions, for each apprentice, following instructions and using assessment recording documentation provided by the EPAO, in a timely manner
  • use language in the development and delivery of the EPA that is appropriate to the level of the occupational standard.

Training provider

As a minimum, training providers should:

  • work with the employer and support the apprentice during the off-the-job training to provide the opportunities to develop the knowledge, skills and behaviours as listed in the occupational standard
  • conduct training covering any knowledge, skill or behaviour requirement agreed as part of the Commitment Statement (often known as the Individual Learning Plan).
  • monitor the apprentice’s progress during any training provider led on-programme learning
  • advise the employer, upon request, on the apprentice’s readiness for EPA
  • remain independent from delivery of the EPAO. Where the training provider is the EPA (i.e. a HEI) there must be procedures in place to mitigate against any conflict of interest.


Reasonable adjustments

The EPAO must have in place clear and fair arrangements for making reasonable adjustments to the assessment methods for the EPA for this apprenticeship standard. This should include how an apprentice qualifies for reasonable adjustments and what reasonable adjustments will be made. The adjustments must maintain the validity, reliability and integrity of the assessment methods outlined in this EPA plan.

Internal quality assurance

Internal quality assurance refers to how EPAOs ensure valid, consistent and reliable EPA decisions. EPAOs must adhere to the requirements within the roles and responsibilities section and:

  • have effective and rigorous quality assurance systems and procedures that ensure fair, reliable and consistent EPA regardless of employer, place, time or independent assessor
  • appoint independent assessors who are competent to deliver the EPA and who:
    • have recent relevant experience of the occupation or sector to at least occupational level 7 gained in the last 5 years or significant experience of the occupation or sector
    • meet the following minimum requirements:

      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.

  • operate induction training for anyone involved in the delivery and/or assessment of the EPA
  • provide training for independent assessors in good assessment practice, operating the assessment tools and making grading decisions
  • provide ongoing training for markers and invigilators
  • provide standardisation activity for this apprenticeship standard for all independent assessors:
    • before they conduct an EPA for the first time
    • if the EPA is updated
    • periodically as appropriate (a minimum of annually)
  • conduct effective moderation of EPA decisions and grades
  • conduct appeals where required, according to the EPAO’s appeals procedure, reviewing and making final decisions on EPA decisions and grades
  • have no direct connection with the apprentice, their employer or training provider. In all instances, including when the EPAO is the training provider (for example a higher education institution)

Value for money

Affordability of the EPA will be aided by using at least some of the following:

  • utilising digital remote platforms to conduct applicable assessment methods
  • assessing multiple apprentices simultaneously where the method of assessment permits this
  • using the employer’s premises

Professional recognition

Professional body recognition is not relevant to this occupational apprenticeship.

KSB mapping table

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
Project with presentation and questions
K4: Core.

The characteristics of modern hardware platforms and how they support the efficient function of interactive, real-time graphical applications.

Back to Grading
Project with presentation and questions
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
Project with presentation and questions
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
Project with presentation and questions
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
Project with presentation and questions
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
Project with presentation and questions
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

Mapping of KSBs to grade themes

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

(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 S22
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)

Create innovative game mechanics for which solutions are unknown. (S22)

Initiative and personal responsibility to overcome challenges and take ownership for project solutions. (B2)

(Game technology programmer) Technology programming

S23 S24 S25
B2

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)

Initiative and personal responsibility to overcome challenges and take ownership for project solutions. (B2)

Professional discussion (underpinned by portfolio)

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)

(Game software programmer) Game programming
K21 K22 K23
S21

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)

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

Employers involved in creating the standard: Sumo Digital Group PLC, Rare (Microsoft), PlayStation London Studio (Sony), Red Kite Games, Co-operative Innovations, The Chinese Room, Hutch Games, nDreams, Aardvark Swift

Version log

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

Is this page useful?

Tell us about your visit

Help us improve our website