This is not the latest approved version of this apprenticeship. View the latest version
This apprenticeship is in the process of being revised or adjusted. In the meantime, the version below remains approved for delivery. Further details of this and other apprenticeships being revised or adjusted are available in the revisions and adjustments status report.
This apprenticeship has been retired
This apprenticeship has options. This document is currently showing the following option:
V1.1
This document explains the requirements for end-point assessment (EPA) for the game programmer apprenticeship. End-point assessment organisations (EPAOs) must follow this when designing and delivering the EPA.
Game programmer apprentices, their employers and training providers should read this document.
A full-time game programmer apprentice typically spends 24 months on-programme (this means in training before the gateway). The apprentice must spend at least 12 months on-programme and complete the required amount of off-the-job training in line with the apprenticeship funding rules.
The apprentice must complete their training and meet the gateway requirements before starting their EPA. The EPA will assess occupational competence.
An approved EPAO must conduct the EPA for this apprenticeship. Employers must select an approved EPAO from the register of end-point assessment organisations (RoEPAO).
This EPA has 2 assessment methods.
The grades available for each assessment method are below.
Assessment method 1 - project with presentation and questions:
Assessment method 2 - professional discussion (underpinned by portfolio):
The result from each assessment method is combined to decide the overall apprenticeship grade. The following grades are available for the apprenticeship:
|
On-programme (typically 24 months)
|
The apprentice must:
|
|---|---|
|
End-point assessment gateway
|
The apprentice’s employer must be content that the apprentice has attained sufficient KSBs to complete the apprenticeship.
The apprentice must:
For the project with presentation and questions, the apprentice must submit a Project brief. To ensure the project allows the apprentice to meet the KSBs mapped to this assessment method to the highest available grade, the EPAO should sign-off the project’s title and scope at the gateway to confirm it is suitable.
For the professional discussion (underpinned by portfolio), the apprentice must submit a portfolio of evidence.
The apprentice must submit the gateway evidence to their EPAO, including any organisation specific policies and procedures requested by the EPAO. |
|
End-point assessment (typically 6 months)
|
The grades available for each assessment method are below
Project with presentation and questions:
Professional discussion (underpinned by portfolio):
Overall EPA and apprenticeship can be graded:
|
|
Re-sits and re-takes
|
|
The EPA is taken in the EPA period. The EPA period starts when the EPAO confirms the gateway requirements have been met and is typically 6 months.
The EPAO should confirm the gateway requirements have been met and the EPA should start as quickly as possible.
The apprentice’s employer must be content that the apprentice has attained sufficient KSBs to complete the apprenticeship. The employer may take advice from the apprentice's training provider, but the employer must make the decision. The apprentice will then enter the gateway.
The apprentice must meet the gateway requirements before starting their EPA.
They must:
Portfolio of evidence requirements:
The apprentice must compile a portfolio of evidence during the on-programme period of the apprenticeship. It should only contain evidence related to the KSBs that will be assessed by this assessment method. It will typically contain 12 discrete pieces of evidence. Evidence must be mapped against the KSBs. Evidence may be used to demonstrate more than one KSB; a qualitative as opposed to quantitative approach is suggested.
Evidence sources may include:
This is not a definitive list; other evidence sources can be included.
The portfolio of evidence should not include reflective accounts or any methods of self-assessment. Any employer contributions should focus on direct observation of performance (for example, witness statements) rather than opinions. The evidence provided should be valid and attributable to the apprentice; the portfolio of evidence should contain a statement from the employer and apprentice confirming this.
The EPAO should not assess the portfolio of evidence directly as it underpins the discussion . The independent assessor should review the portfolio of evidence to prepare questions for the discussion . They are not required to provide feedback after this review.
The apprentice must submit the gateway evidence to their EPAO, including any organisation specific policies and procedures requested by the EPAO.
The assessment methods can be delivered in any order.
The result of one assessment method does not need to be known before starting the next.
A project involves the apprentice completing a significant and defined piece of work that has a real business application and benefit. The project must meet the needs of the employer’s business and be relevant to the apprentice’s occupation and apprenticeship.
This assessment method has 2 components:
project with a project output
presentation with questions and answers
Together, these components give the apprentice the opportunity to demonstrate the KSBs mapped to this assessment method. They are assessed by an independent assessor.
Programmers in the games industry are principally engaged in developing software, and each programmer will engineer many different technical systems as part of the development of a complete game. As the project cycle for games is often too long to assess a complete product, this assessment uses one of these technical systems as a practical way of demonstrating software engineering skills and their associated KSBs. Although it isn’t compulsory for this system to be assessed in isolation from its associated product, this may be necessary when the wider product is incomplete or subject to confidentiality requirements. The project and any components must be assessed holistically by the independent assessor when they are deciding the grade for this EPA method.
The apprentice must complete a project based on any of the following:
The project may also be based on:
a development of live product where it is appropriate to do so. Where client 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 assessment method to the highest available grade, the EPAO should sign-off the project’s title and scope at the gateway to confirm it is suitable. The EPAO must refer to the grading descriptors to ensure that projects are pitched appropriately.
The project output must be in the form of software artefact.
The apprentice must start the project after the gateway. The employer should ensure the apprentice has the time and resources, within the project period, to plan and complete their project.
The apprentice may work as part of a team to complete the project, which could include internal colleagues or technical experts. The apprentice must however, complete their software artefact and presentation unaided and they must be reflective of their own role and contribution. The apprentice and their employer must confirm this when the software artefact and any presentation materials are submitted.
The software artefact must include at least:
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 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.
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.
The software artefact must have a word count of 5000 words. A tolerance of 10% above or below the word count is allowed at the apprentice's discretion. Appendices, references and diagrams are not included in this total. The apprentice must produce and include a mapping in an appendix, showing how the output evidences the KSBs mapped to this assessment method.
The apprentice must complete and submit the software artefact and any presentation materials to the EPAO by the end of week of the EPA period.
The presentation with questions must be structured to give the apprentice the opportunity to demonstrate the KSBs mapped to this assessment method to the highest available grade.
The apprentice must prepare and deliver a presentation to an independent assessor. After the presentation, the independent assessor must ask the apprentice questions about their project, software artefact and presentation.
The presentation should cover:
The presentation with questions must last 90 minutes. This will typically include a presentation of 45 minutes and questioning lasting 45 minutes. The independent assessor must use the full time available for questioning. The independent assessor can increase the time of the presentation and questioning by up to 10%. This time is to allow the apprentice to complete their last point or respond to a question if necessary.
The independent assessor must ask at least 5 questions. They must use the questions from the EPAO’s question bank or create their own questions in line with the EPAO’s training. Follow up questions are allowed where clarification is required.
The purpose of the independent assessor's questions is:
The apprentice must submit their any presentation materials to the EPAO at the same time as the software artefact - by the end of week 12 of the EPA period. The apprentice must notify the EPAO, at that point, of any technical requirements for the presentation.
During the presentation, the apprentice must have access to:
The independent assessor must have at least 2 weeks to review the software artefact and any presentation materials, to allow them to prepare questions.
The apprentice must be given at least 2 weeks’ notice of the presentation with questions.
The independent assessor must make the grading decision. They must assess the project components holistically when deciding the grade.
The independent assessor must keep accurate records of the assessment. They must record:
The presentation with questions must take place in a suitable venue selected by the EPAO for example, the EPAO’s or employer’s premises. It should take place in a quiet room, free from distractions and influence.
The presentation with questions can be conducted by video conferencing. The EPAO must have processes in place to verify the identity of the apprentice and ensure the apprentice is not being aided.
The EPAO must develop a purpose-built assessment specification and question bank. It is recommended this is done in consultation with employers of this occupation. The EPAO should maintain the security and confidentiality of EPA materials when consulting with employers. The assessment specification and question bank must be reviewed at least once a year to ensure they remain fit-for-purpose.
The assessment specification must be relevant to the occupation and demonstrate how to assess the KSBs mapped to this assessment method. The EPAO must ensure that questions are refined and developed to a high standard. The questions must be unpredictable. A question bank of sufficient size will support this.
The EPAO must ensure that the apprentice has a different set of questions in the case of re-sits or re-takes.
EPAO must produce the following materials to support the project:
The EPAO must ensure that the EPA materials are subject to quality assurance procedures including standardisation and moderation.
In the professional discussion, an independent assessor and apprentice have a formal two-way conversation. It gives the apprentice the opportunity to demonstrate the KSBs mapped to this assessment method.
The apprentice can refer to and illustrate their answers with evidence from their portfolio of evidence.
The EPA method is being used because while programmers in the games industry spend most of their time developing software, it is their ability to work productively with a much wider team of creative people that determines their real value to a game studio. As such this assessment allows apprentices to draw upon a wider portfolio of work created after the gateway to relate their KSBs to experiences involving interdisciplinary teamworking and professionalism.
The professional discussion must be structured to give the apprentice the opportunity to demonstrate the KSBs mapped to this assessment method to the highest available grade.
An independent assessor must conduct and assess the professional discussion.
Questions must be asked. The purpose of questioning is:
The EPAO must give an apprentice 2 weeks' notice of the professional discussion.
The independent assessor must have at least 2 weeks to review the supporting documentation.
The apprentice must have access to their portfolio of evidence during the professional discussion.
The apprentice can refer to and illustrate their answers with evidence from their portfolio of evidence however, the portfolio of evidence is not directly assessed.
The professional discussion must last for 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 respond to a question if necessary.
The independent assessor must ask at least 10 questions. The independent assessor must use the questions from the EPAO’s question bank.
The independent assessor must make the grading decision.
The independent assessor must keep accurate records of the assessment. They must record:
The professional discussion must take place in a suitable venue selected by the EPAO for example, the EPAO’s or employer’s premises.
The professional discussion can be conducted by video conferencing. The EPAO must have processes in place to verify the identity of the apprentice and ensure the apprentice is not being aided.
The professional discussion should take place in a quiet room, free from distractions and influence.
The EPAO must develop a purpose-built assessment specification and question bank. It is recommended this is done in consultation with employers of this occupation. The EPAO should maintain the security and confidentiality of EPA materials when consulting with employers. The assessment specification and question bank must be reviewed at least once a year to ensure they remain fit-for-purpose.
The assessment specification must be relevant to the occupation and demonstrate how to assess the KSBs mapped to this assessment method. The EPAO must ensure that questions are refined and developed to a high standard. The questions must be unpredictable. A question bank of sufficient size will support this.
The EPAO must ensure that apprentice has a different set of questions in the case of re-sits or re-takes.
The EPAO must produce the following materials to support the professional discussion (underpinned by portfolio):
The EPAO must ensure that the EPA materials are subject to quality assurance procedures including standardisation and moderation.
Fail - does not meet pass criteria
|
Theme
KSBs
|
Pass
Apprentices must demonstrate all of the pass descriptors
|
Distinction
Apprentices must demonstrate all of the pass descriptors and all of the distinction descriptors
|
|---|---|---|
|
(Core) Programming competencies
K1 K2 K9 S1 S8 S9 S16 B1 |
The Project incorporates the development of an interactive real time application for a gaming platform which uses the syntax and structure of an industry standard programming language. K1, K2, S1. The Project application is created using the common principles of games industry software design. K9. The Project application demonstrates the use of a well-tested, maintainable code which can be adapted to changing requirements and adopts an industry standard version control system. S8, S9. The Project demonstrates up to date studio coding methods/techniques which the apprentice can justify as being current and relevant. S16. Acts independently in applying objective judgements to create the application within given time constraints. B1. |
Critically evaluates their application design justifying their choice of language features and APIs. K1, K2, S1. Critically evaluates the ability of their code to be maintained and its potential to be adapted to changing requirements. S8, S9. |
|
(Core) Real-time graphical applications
|
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 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 |
The project develops reusable technologies that target hardware architectures and/or gaming platforms in the context of a user focused product team. S23, S25. The implementation of different features and their effect on quality is justified with respect to workload. S24. Establishes an approach to work tasks which reflects their own independent initiative and personal responsibility which adheres to the code of conduct/ethics set out by the company/organisation. B2. |
Critically evaluates reusable technologies that target hardware architectures and/or gaming platforms in the context of a user focused product team. S23, S25. Evaluates the implementation of different features and their effect on quality with respect to workload. S24. |
Fail - does not meet pass criteria
|
Theme
KSBs
|
Pass
Apprentices must demonstrate all of the pass descriptors
|
Distinction
Apprentices must demonstrate all of the pass descriptors and all of the distinction descriptors
|
|---|---|---|
|
(Core) Project management and methodologies
K8 K11 K12 K15 S7 S10 S12 S17 |
Describes the role of stages deployment, monitoring and analytics in releasing, tracking and refining games. K8. Demonstrates the application of industry standard game development methodologies. K12, S12. Demonstrates the use of a continuous integration workflow within the deployment lifecycle as part of a multidisciplinary software team. S7. Describes the role of rapid prototyping and agile approaches in innovation. K15. Demonstrates the application of version control and project management tools in the role of a developer. K11, S10. Describes the giving and receiving of feedback in code reviews in an objective and professional manner. S17. |
Critically evaluates the application of industry standard game development methodologies. K12, S12. Evaluates and justifies the application of version control and project management tools in the role of a developer. K11, S10. |
|
(Core) Creative teams and asset workflows
K10 K13 K18 S11 S13 S14 B3 |
Explains how an asset pipeline works for a game. K10. Outlines the multi-disciplinary roles involved in the game development process and evaluates their value in the production of a game. K13. Demonstrates the management of complex relationships with diverse stakeholders, leading modifications to existing tool chains or optimisations to workflows, and manages the associated communication, selecting technical and/or non-technical language in reflection of the audience. S11, S13, S14. Identifies the business stakeholders and business models for their own projects which can generate value. K18. Establishes an approach to working with colleagues within their own and related disciplines that follows the ethical guidelines/policies/procedures set out by the industry/organisation. B3. |
Reflects on their management of stakeholders and multi-disciplinary teams justifying how their approach generates value within the context of a business model. K18, S13. |
|
(Core) Professionalism
K14 K16 K17 K19 K20 S15 B4 B5 B6 |
Describes the sources of information for the latest innovations for the games industry and identifies the opportunities and threats presented by new technologies. K14, S15. Outlines the organisation's standards on coding, documentation and issue tracking and relates them to software industry practices. K16. Understands publishers' technical requirements for target platforms and where to obtain information and support. K17. Describes relevant data protection laws and practices, evaluations their relevance to the games industry and their relationship to security. K19, K20. Assumes responsibility for their personal development and records show the expertise gained is used to share with colleagues. B4. Uses a range of sources of information to demonstrate awareness of current trends in the gaming sector. B5. Establishes a workplace approach to personal data, safety, and security which follows ethical, legal and regulatory guidelines for the industry/sector/organisation. B6. |
Critically evaluates the current opportunities and threats to the organisation presented by new technologies. S15. |
|
(Game software programmer) Game programming
K21 K22 K23 S21 S22 |
Evaluates different game engines, third-party frameworks and tools with respect to accelerating the game development process. K21. Understands the trade-offs in time and resources that underpin the engineering and maintenance of a game’s asset pipeline. K22. Distinguishes the typical skillsets and expectations of different disciplines involved in the development process in terms of technologies, tools and asset formats. K23. Demonstrates working in an interdisciplinary team on game programming. S21. The software implements game mechanics which solve problems where solutions were previously unknown. S22.
|
Critically compares the relative merits of alternative game engines, third-party frameworks and tools with those used in house. K21. Evaluates the role of different disciplines involved in the development process and their typical skillsets and expectations in terms of technologies, tools and asset format. K23. Evaluates their solutions to design problems. S22. |
|
(Game technology programmer) Game technology
K24 K25 K26 S26 S27 |
Describes the specialist operation of specific hardware architectures or gaming platforms and how to engineer optimal solutions which target its specific capabilities. K24. Understands the trade-offs in time and resources to provide maximum benefit to users. K25. Explains how externally facing support portals and project tracking tools are used to track and document technologies for sharing with the user-base. K26. Communicates and evangelises the technology solutions and promotes engagement and uptake among the user-base. S26. Demonstrates the profiling and optimisation of code created by their technology users. S27. |
Critically compares hardware architecture or gaming platforms from other organisations with those used in-house. K24. Evaluates the role of support portals and issue tracking processes in working with a wide user-base. K26. |
|
(Core) Real - time graphical applications
K3 K4 K5 S2 S5 |
Demonstrates code which is informed by the characteristics of a hardware platform that supports real-time graphical applications. K4, S5. 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. |
Performance in the EPA determines the overall grade of:
An independent assessor must individually grade the: project with presentation and questions and professional discussion (underpinned by portfolio) in line with this EPA plan.
The EPAO must combine the individual assessment method grades to determine the overall EPA grade.
If the apprentice fails one assessment method or more, they will be awarded an overall fail.
To achieve an overall pass, the apprentice must achieve at least a pass in all the assessment methods. Any FAIL = Overall FAIL Project PASS + Discussion PASS = Overall PASS Project PASS + Discussion DISTINCTION = Overall MERIT Project DISTINCTION + Discussion PASS = Overall MERIT Project DISTINCTION + Discussion DISTINCTION = Overall DISTINCTION
Grades from individual assessment methods must be combined in the following way to determine the grade of the EPA overall.
| Project with presentation and questions | Professional discussion (underpinned by portfolio) | Overall Grading |
|---|---|---|
| Fail | Fail | Fail |
| Pass | Pass | Pass |
| Pass | Distinction | Merit |
| Distinction | Pass | Merit |
| Distinction | Distinction | Distinction |
If the apprentice fails one assessment method or more, they can take a re-sit or a re-take at their employer’s discretion. The apprentice’s employer needs to agree that a re-sit or re-take is appropriate. A re-sit does not need further learning, whereas a re-take does. The apprentice should have a supportive action plan to prepare for a re-sit or a re-take.
The employer and the EPAO should agree the timescale for a re-sit or re-take. A re-sit is typically taken within 2 months of the EPA outcome notification. The timescale for a re-take is dependent on how much re-training is required and is typically taken within 3 months of the EPA outcome notification.
If the apprentice fails the project assessment method, they must amend the project output in line with the independent assessor’s feedback. The apprentice will be given 2 weeks to rework and submit the amended other.
Failed assessment methods must be re-sat or re-taken within a 6-month period from the EPA outcome notification, otherwise the entire EPA will need to be re-sat or re-taken in full.
Re-sits and re-takes are not offered to an apprentice wishing to move from pass to a higher grade.
The apprentice will get a maximum EPA grade of pass for a re-sit or re-take, unless the EPAO determines there are exceptional circumstances.
| Roles | Responsibilities |
|---|---|
|
Apprentice |
As a minimum, the apprentice should:
|
|
Employer |
As a minimum, the apprentice's employer must:
|
|
EPAO |
As a minimum, the EPAO must:
|
|
Independent assessor |
As a minimum, an independent assessor must:
|
|
Training provider |
As a minimum, the training provider must:
|
The EPAO must have reasonable adjustments arrangements for the EPA.
This should include:
Adjustments must maintain the validity, reliability and integrity of the EPA as outlined in this EPA plan.
Internal quality assurance refers to the strategies, policies and procedures that an EPAO must have in place to ensure valid, consistent and reliable EPA decisions.
EPAOs for this EPA must adhere to the requirements within the roles and responsibilities table.
They must also appoint independent assessors who:
should have three or more years professional experience as a programmer on an interdisciplinary game development team and have released at least one commercial title.
Affordability of the EPA will be aided by using at least some of the following:
This apprenticeship is not aligned to professional recognition.
| Knowledge | Assessment methods |
|---|---|
|
K1: Core.
How to approach the development of interactive, real-time applications for gaming platforms, including an awareness of industry-standard programming languages, application programming interfaces (APIs), tools, engines and frameworks. Back to Grading |
Project with presentation and questions |
|
K2: Core.
The syntax and structure of an industry-standard programming language (above and beyond visual programming languages) used for the development of games (for example C++, C#). Back to Grading |
Project with presentation and questions |
|
K3: Core.
The fundamental graphical and mathematical principles that underpin the operation of real-time graphics in two and three-dimensions. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K4: Core.
The characteristics of modern hardware platforms and how they support the efficient function of interactive, real-time graphical applications. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K5: Core.
Approaches to balancing quality and performance requirements to achieve, monitor and maintain acceptable frame rates and memory footprints for a real-time interactive application. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K6: Core.
How to use tools to identify and optimise performance bottlenecks in real-time applications. Back to Grading |
Project with presentation and questions |
|
K7: Core.
The role of debugging tools, crash reports, automated testing and continuous integration workflows in creating robust software. Back to Grading |
Project with presentation and questions |
|
K8: Core.
The role of staged deployment, monitoring and analytics in releasing, tracking and refining games. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K9: Core.
Common principles of good software design applied in the games industry including contrasting approaches and priorities (e.g. object-oriented vs. data-oriented) Back to Grading |
Project with presentation and questions |
|
K10: Core.
How a complete asset pipeline for a game operates, including the technical requirements, processing stages and tools involved in bringing assets into the game. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K11: Core.
How to use version control and project management tools to plan and coordinate the delivery of development tasks. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K12: Core.
Common development methodologies and how they are applied in game development. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K13: Core.
The broad range of roles involved in the game development process, and the different strengths and perspectives that multi-disciplinary teams bring to the creative process. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K14: Core.
Where to find information on the latest technological innovations for the games industry. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K15: Core.
The role of rapid prototyping and agile approaches in innovation. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K16: Core.
The organisation’s standards with respect to coding, documentation and issue tracking, and how they relate to wider practice in the software industries. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K17: Core.
Publisher’s technical requirements for target platforms, where to obtain them and the tools and systems available to support developers to meet those requirements. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K18: Core.
The business stakeholders in a project and how multi-disciplinary development teams can generate value within the context of different business models. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K19: Core.
Relevant data protection laws including GDPR. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K20: Core.
Security approaches to prevent products being compromised, and everyday good practice in security including password policies, phishing and use of VPNs. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K21: Game software programmer.
The relative merits of different game engines, third-party frameworks and tools, and when to use them to speed up the development process. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K22: Game software programmer.
How to balance the requirements and availability of team resources (for example staff time, software licencing) with respect to the engineering and maintenance of a game’s asset pipeline. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K23: Game software programmer.
The range of different disciplines involved in the development process and their typical skillsets and expectations in terms of technologies, tools and asset formats. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K24: Game technology programmer.
The specialist operation of a specific hardware architecture or gaming platform and how to engineer efficient solutions which target its specific capabilities. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K25: Game technology programmer.
How to balance the requirements and availability of team resources (staff time, software licencing) with respect to providing the maximum benefit to their users. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
K26: Game technology programmer.
How to use externally facing support portals and project tracking tools in order to effectively track and document technologies for sharing with a wide user-base. Back to Grading |
Professional discussion (underpinned by portfolio) |
| Skill | Assessment methods |
|---|---|
|
S1: Core.
Program interactive, real-time applications for gaming platforms using an industry-standard programming language, incorporating APIs, tools, engines or frameworks appropriate to employer requirements. Back to Grading |
Project with presentation and questions |
|
S2: Core.
Implement and adapt contemporary real-time algorithms in two and three-dimensional games. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S3: Core.
Use profiling tools and techniques to achieve, monitor and maintain an acceptable real-time framerate for an interactive game. Back to Grading |
Project with presentation and questions |
|
S4: Core.
Track memory usage and identify opportunities for reducing requirements. Back to Grading |
Project with presentation and questions |
|
S5: Core.
Write code informed by the characteristics of modern hardware platforms (e.g. shader programming, multi-threading). Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S6: Core.
Use debugging tools and automated testing systems to develop robust code bases. Back to Grading |
Project with presentation and questions |
|
S7: Core.
Use continuous integration workflow within the deployment lifecycle as part of a multi-disciplinary software team. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S8: Core.
Write robust, well-tested, maintainable code which is easy to adapt to changing requirements. Back to Grading |
Project with presentation and questions |
|
S9: Core.
Use an industry-standard version control system. Back to Grading |
Project with presentation and questions |
|
S10: Core.
Use an industry-standard project management system from the perspective of a developer. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S11: Core.
Adapt or extend existing tool chains to support new features and/or optimise workflows. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S12: Core.
Apply industry-standard development methodologies within day-to-day working practice. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S13: Core.
Manage complex relationships with diverse stakeholders and communicate information effectively to different audiences. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S14: Core.
Provide technical leadership and direction with respect to the workflow of other team members. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S15: Core.
Research, document and articulate the opportunities and threats presented by new industry technologies. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S16: Core.
Follow studio coding best-practices and participate in keeping them relevant and up to date. Back to Grading |
Project with presentation and questions |
|
S17: Core.
Give and receive feedback in code reviews in an objective and professional manner. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S18: Game software programmer.
Develop games and/or prototypes using an industry-standard or in-house game engine. Back to Grading |
Project with presentation and questions |
|
S19: Game software programmer.
Make justified choices about the implementation of different features and tools and their effect on the overall workload of the team. Back to Grading |
Project with presentation and questions |
|
S20: Core.
Write software which contributes to the player experience while balancing the extensibility and performance requirements for an evolving game design. Back to Grading |
Project with presentation and questions |
|
S21: Game software programmer.
Work as part of interdisciplinary teams. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S22: Game software programmer.
Create innovative game mechanics for which solutions are unknown. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S23: Game technology programmer.
Develop reusable technologies targeting specific hardware architectures or gaming platforms. Back to Grading |
Project with presentation and questions |
|
S24: Game technology programmer.
Make justified decisions about the implementation of different features and their effect on quality and workload for their technology’s user base. Back to Grading |
Project with presentation and questions |
|
S25: Game technology programmer.
Work as part of a user-focused product team, incorporating multi-disciplinary input from outside of the team, for example from game software programmers, artists, game designers and audio engineers. Back to Grading |
Project with presentation and questions |
|
S26: Game technology programmer.
Communicate and evangelise technology solutions to promote engagement and uptake among the user-base. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
S27: Game technology programmer.
Profile and optimise code created by their technology users. Back to Grading |
Professional discussion (underpinned by portfolio) |
| Behaviour | Assessment methods |
|---|---|
|
B1: Core.
Reliable, objective and capable of independent working. Back to Grading |
Project with presentation and questions |
|
B2: Core.
Initiative and personal responsibility to overcome challenges and take ownership for project solutions. Back to Grading |
Project with presentation and questions |
|
B3: Core.
Respect for other disciplines and an understanding of the role of diverse experiences and backgrounds in a successful creative process. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
B4: Core.
Commitment to continuous professional development; maintaining their knowledge and skills in relation to technology developments, and sharing best practice in their organisation around all aspects of game development. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
B5: Core.
Maintains awareness of trends and innovations in the subject area, utilizing a range of academic literature, online sources, community interaction and conference attendance. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
B6: Core.
Acts with integrity with respect to ethical, legal and regulatory ensuring the protection of personal data, safety and security. Back to Grading |
Professional discussion (underpinned by portfolio) |
|
B7: Core.
A strong work ethic and commitment in order to meet the standards required. Back to Grading |
Project with presentation and questions |
| KSBS GROUPED BY THEME | Knowledge | Skills | Behaviour |
|---|---|---|---|
|
(Core) Programming competencies
K1 K2 K9 S1 S8 S9 S16 B1 |
How to approach the development of interactive, real-time applications for gaming platforms, including an awareness of industry-standard programming languages, application programming interfaces (APIs), tools, engines and frameworks. (K1) The syntax and structure of an industry-standard programming language (above and beyond visual programming languages) used for the development of games (for example C++, C#). (K2) Common principles of good software design applied in the games industry including contrasting approaches and priorities (e.g. object-oriented vs. data-oriented) (K9) |
Program interactive, real-time applications for gaming platforms using an industry-standard programming language, incorporating APIs, tools, engines or frameworks appropriate to employer requirements. (S1) Write robust, well-tested, maintainable code which is easy to adapt to changing requirements. (S8) Use an industry-standard version control system. (S9) Follow studio coding best-practices and participate in keeping them relevant and up to date. (S16) |
Reliable, objective and capable of independent working. (B1) |
|
(Core) Real-time graphical applications
|
N/A |
N/A |
N/A |
|
(Core) Debugging, profiling and optimisation
K6 K7 S3 S4 S6 B7 |
How to use tools to identify and optimise performance bottlenecks in real-time applications. (K6) The role of debugging tools, crash reports, automated testing and continuous integration workflows in creating robust software. (K7) |
Use profiling tools and techniques to achieve, monitor and maintain an acceptable real-time framerate for an interactive game. (S3) Track memory usage and identify opportunities for reducing requirements. (S4) Use debugging tools and automated testing systems to develop robust code bases. (S6) |
A strong work ethic and commitment in order to meet the standards required. (B7) |
|
(Game software programmer) Game programming
S18 S19 S20 B2 |
N/A |
Develop games and/or prototypes using an industry-standard or in-house game engine. (S18) Make justified choices about the implementation of different features and tools and their effect on the overall workload of the team. (S19) Write software which contributes to the player experience while balancing the extensibility and performance requirements for an evolving game design. (S20) |
Initiative and personal responsibility to overcome challenges and take ownership for project solutions. (B2) |
|
(Game technology programmer) Technology programming
S23 S24 S25 |
N/A |
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) |
N/A |
| 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) |
N/A |
|
(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 S22 |
The relative merits of different game engines, third-party frameworks and tools, and when to use them to speed up the development process. (K21) How to balance the requirements and availability of team resources (for example staff time, software licencing) with respect to the engineering and maintenance of a game’s asset pipeline. (K22) The range of different disciplines involved in the development process and their typical skillsets and expectations in terms of technologies, tools and asset formats. (K23) |
Work as part of interdisciplinary teams. (S21) Create innovative game mechanics for which solutions are unknown. (S22) |
N/A |
|
(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) |
N/A |
|
(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) |
N/A |
Contact us about this apprenticeship