And functionality to SDL2
s s Assessment Details and Brief Module Title: Game Engine Fundamentals Author(s)/Marker(s) of Assignment Assignment No: 1 Assignment Title: Game engine components Percentage contribution to module mark: 100% Weighting of components within this assessment: Implementation 80% Report 20% Module learning outcome(s) assessed: LO1: Design and implement core components of a simple game engine applying appropriate mathematical techniques LO2: Integrate a range of assets including text, images and audio within a game engine LO3: Utilise core components of a game engine to implement a simple game demo LO4: Demonstrate best practice in implementation techniques and documentation The assessment is marked anonymously No Assessment Brief and Assessment Criteria: Develop an aspect of a game engine, alongside a simple demo showing the use of the developed aspect. Assessment marking criteria/rubric: See below Date of issue: 10.02.20 Deadline for submission: 14.05.20 by 15:00 Method of submission: e-submission Date feedback will be provided 04.06.20 Requirements Each student will undertake the design and development of: 1. a single game engine element, and 2. a simple application demonstrating the use of the developed element. Each student will also produce a technical report discussing the design and development of the chosen engine element. There is a wide range of engine elements that can be chosen for development, for example (list not exhaustive): AI, physics, visual effects, achievements system, quick-time events, cutscenes, randomly generated content, story or sophisticated UI design. The implementation must use C++ and the provided codebase. Details of the provided codebase are given and explained during the lectures and tutorials. Any non-original code must be clearly identified using comments within the submitted code and an accurate reference with an appropriate license must be included within the references section of the report Assessment Criteria Standard GEAR and CEM marking criteria will be applied. The criteria below provide an indication of what is expected from this piece of work. If a similar feature (not mentioned here) is delivered / implemented, it will gain marks as appropriate. Implementation: 80% Unsatisfactory (E/F 0-39%) Adequate (D 40-49%) Sound (C 50-59%) Good (B 60-69%) Excellent (A 70-79%) Outstanding (A+ 80-100%) Engine aspect: (25%) Technically too simple for L5 or not working. The aspect barely works, very limited/contrived use case. The aspect works to some extent, valid use cases exist. The aspect largely works, some work needed to make it more general. The aspect fully works and can be used generally by any application without major modifications. In addition, the aspect demonstrates use of original ideas, concepts or algorithms. Game demo: (25%) Technically too simple for L5 or not working. The game is barely playable, limited demonstration of engine usage. The game works to some extent, some demonstration of engine usage. The game largely works, appropriate demonstration of engine usage. The game fully works, excellent use of the engine aspects (both developed and existing). In addition, the demo is sophisticated enough (logically and visually) to be a publishable game prototype. Assets: (15%) Irrelevant, unused or no assets. Very few assets used. Assets do not fit any specific genre / theme. Assets form a single theme and of decent quality. Assets used are appropriate, include some high quality. Full range of assets: images, sounds, fonts, custom formats. Full range of assets with a professional level of quality, ready to be used in a publishable game. Code quality: (15%) 3rd party referenced code with no modifications. The code has been put together poorly and barely works. Layout is inconsistent, no documentation, code is monolithic. May contain some referenced 3rd party code. The code works to some extent but has some significant issues: crashes, little adherence to good programming practices. May contain some referenced 3rd party code. The code follows good programming practice and works as expected without major issues, OO approach is used appropriately, code documentation is present where required. Most of the code is original. In addition, the code uses correct software design patterns and the quality is consistent throughout. The code is fully original. In addition, the code demonstrates the use of advanced coding techniques and is professionally documented. Technical report: 20% Unsatisfactory (E/F 0-39%) Adequate (D 40-49%) Sound (C 50-59%) Good (B 60-69%) Excellent (A 70-79%) Outstanding (A+ 80-100%) Report Completely unsatisfactory and weak in all sections. A poorly structured report with vague language, may include some typos and require a lot of polishing. Covers key sections but to a poor extent. Weak response to technical content. A well-structured report, very few typos. Covers most sections but to a poor extent. A good response to technical content. A clearly structured well-written report. Covers all sections to a reasonable extent. A good depth and breadth of knowledge are shown. In addition, uses precise language (terminology) and concise in its narrative. Covers all sections, providing extensive links to other sources of information. Demonstrates clear understanding of the technical details. In addition, a deep understanding of the problem/solution in the domain is demonstrated, also with alternative solutions discussed. Sophisticated critical reflection. Professionally looking, clearly written report. Report structure The number of pages given is an indication of how much content is expected in that section. The aim is to write succinctly and to concentrate on the essence of the features discussed. In addition, you must include appropriate comments within the source code. · Chosen engine aspect (1 page): explain what engine aspect was chosen, how it was designed and implemented. You are expected to explain the data structures and algorithms used without including extensive code listing. · Game demo: provide gameplay screenshots from the game demo clearly showing the use of the developed engine aspect and explain how assets are used within the game, particularly any assets that you created yourself. · Critical review (1 page): identify three reasons why the design and implementation of the application are good. Identify three areas where the implementation could be improved and a summary of how the improvements could be made. · References: Clearly identify and reference any third-party tutorials / assets / code that you have used and provide accurate references to their source. Failure to do this may lead to serious consequences, including a 0 mark. Deliverables: 1. Full project (source code for game engine aspect and game demo, including assets). (80%) 2. Technical report. (20%) 3. A video demonstrating the game being played clearly showing the implemented engine aspect (used if the project cannot be built). Note: The video should have an appropriate resolution and quality. The video should be uploaded to YouTube. Do not submit the video but include a working URL to your YouTube video. The video does not have to be public, but it needs to be accessible via the submitted URL. Submission procedure: The work must be submitted through the Assessment area of this module on StudentCentral as a single Zip file. Note: Students are allowed to submit work within two weeks of the published deadline, or the last working day immediately prior to the feedback date if this is shorter than two weeks. Any work submitted later than 15:00 of the date shown on the front page without an approved extension will be treated as late and capped at the pass mark. Version 08/06/2019