5033CMD #Defining Gravity: High-Performance Physics Simulation CWK Resit Assignment Brief– Term 1 2025-26

5033CMD Assignment Task – Implement a physics engine for a game scenario

This coursework is a make-good assessment.

You are able to reuse your submission and use the feedback received from that submission to improve upon it. This is not classed as self-plagiarism.

If you did not submit a coursework, you are to continue development on the software you began during the semester, aligning it to the assignment specification.

There are no differences between the original coursework specification (Assignment 1) and this Resit specification, other than the due date and this added text.

This coursework assesses learning outcomes 1, 2, 3 and 4, and represents 15 credits of the module. This assignment is an individual assignment.

For this assignment, you are asked to create from scratch, using C++, a 3D physics simulation of a crazy golf style game.

The crazy golf game should:

• Have a game scene including:
• A golf ball that can be hit to move it around the scene
• The end goal of a golf hole that the golf ball should enter to complete the game
• A golf course that is marked in some fashion (with objects, lines etc.) so the player knows where the playable area is and where to sink the golf ball
• The player normally starts at one side of the course with the golf hole on the other side so that the golf ball has some distance to travel
• If the ball gets hit out of play, the ball should be reset to a viable position on the course
• Obstacles present on the course that the ball has to avoid (such as walls and barriers, windmills, gates, bunkers, tunnels etc.)
• Which can be collided with
• Some obstacles should not move on collision
• Some obstacles should move on collision, meaning the ball or other objects could push these around
• Some obstacles may move such as windmill blades, gates moving up and down etc.
• Collectables in the course that the ball can pick up when colliding or the player can pick up
• Which allows pick-up but does not stop the ball/player when collided with
• These could affect the ball for a short time such as speed boosts, removing some of the obstacles or adding to a score value.
• Different areas on the course that affects the friction between the ball and the course surface
• This could be fake grass, mud, sand, wet/dry surfaces from fairways, the rough, sand bunkers, wooden areas, grassy areas etc.
• Different areas on the course that contain a force that affects the player
• Such as speeding up, slowing down, add or removing friction, wind in the area
• Should be “resettable” with a keypress
• Allowing the player to revert the game scene back to the original setup
• When playing the ball and moving objects in the scene should:
• Have realistic movement with acceleration/deceleration
• Be able to interact with the scene with non-deforming realistic collision response
• The ball should be “hittable”:
• The first approach for this should be applying a force directly to the ball via a keypress so it moves in a direction (either camera or ball forward)
• From that approach, you should then allow a player defined direction to aim the shot such as chipping the ball into the air/over obstacles
• r a slightly sideward force so it can be hit around obstacles
• A more advanced approach would then be to use a golf club object that moves and then collides with the golf ball so that the club hits and moves the object
• For any of these approaches, the user should be able to vary the power of the shot, from a small tap to powerful hit For general inspiration for the crazy golf game genre and the genre’s tropes:
• 2020’s Golf With Your Friends, developed by Blacklight Interactive and Team17
• 2022’s Wonderputt Forever, developed by Damp Gnat
• 2023’s Golf It!, developed by Perfuse Entertainment

Figure 1

A screenshot from the game Golf With Your Friends

From Golf With Your Friends review
Various mechanics are on show here such as the golf ball start on the left side of the windmill, moving windmill blades, a tunnel through the windmill and from the top to the bottom and the golf hole (with a flag).

Once the physics engine has basic working functionality, you should identify and evaluate key areas in the physics engine where optimisations could be incorporated. To pass this section of the rubric, you should identify and evaluate these areas with comments and pseudocode in your codebase.

For higher marks, implementing these optimisations into your codebase is required. For even higher marks, optimisation metrics should be shown “live” with switchable optimisation methods by the user. For example, being able to turn each optimisation on and off with key presses to see the real-time effect of having the optimisation present (or not) with the metrics reflecting this.

It is suggested that students use metrics such as time taken (via the GLFW library functions or the Chrono library), frames per second, counters for how many times a function is ran per frame, amount of objects updated a frame etc. as evidence for these optimisations actually improving the physics aspects of your work.

Optimisations could include:

• Broadphase collision detection such as spatial partitioning methods
• Hierarchical bounding volumes for objects
• Sleeping physics bodies that no longer require physics calculations and waking these up when physics calculations are needed
• Multithreading of physics calculations

The scene you create for the software implementation should contain examples of all the markable areas without code/project changes. You can use keypresses to spawn, change or tweak objects if needed.

As the focus is on the physics aspects, the graphics are not accessed. However, some level of graphics are needed to show the physics working and in action – This can be basic geometric shapes with colours only.

For rendering the software implementation, you are allowed to use your 5042CMD coursework as the renderer without this being classed as “self-plagiarism”, but this should be copied into a new repository for this module, and the original 5042CMD repository should not be changed or added to.

If you do not wish to use your 5042CMD coursework as the renderer for this coursework, a basic graphics renderer will be covered in the lab material which should be used instead.

You are expected to make use of the code provided in the 5033CMD C++ tutorials and build upon this. You do not have to reference this material in your code. You must reference any external code used and any theory and/or tutorials from other sources.

If you use an external library that is the solution for a problem that should have been done from scratch, you may be awarded 0 marks for this as this is not your own work. If you are unsure, please talk to a member of the module team.

Video

You will also record a video fly-through (a singular video, totalling 5 minutes or less) which shows:

• A fly-through of the rendered output of the coursework, highlighting the significant aspects of the work (see the marking rubric below for the aspects that should be covered).
• You may want to use voice-overs and/or text overlays to explain what is happening in the video.
  The video should be uploaded to Microsoft OneDrive, and you should copy a link to the video which allows people to view the video (see Figure 2). You will include a link to the Microsoft OneDrive online hosted video in your Aula submission in the .txt file.

Figure 2

The sharing options that should be chosen to allow the markers to view the Microsoft OneDrive hosted video with the URL link

If you are uncertain about how to do this, contact a member of the module team well before the submission date. It is up to students to test this uploaded video so that it is viewable.

If the video cannot be accessed by the module team in any way (incorrect URL, privacy settings of the video etc.), this may result in a reduction in your mark.

Submission Instructions:

For your submission, you will create a .txt file that contains 2 links:

• The first link will be to your Coventry University GitHub coursework repository that is part of the GamesTechnology organisation.
• The second link will be to your 5-minute fly-though video that is hosted on OneDrive and made so anyone with the link can view the video.

External Resources

If you use any external graphical resources in your coursework such as textures, model data etc., you must reference these. You may not use third party code (other than the third-party libraries discussed as part of the module). If you are unsure about what you can use, ask the module staff before you use it.

These references can be placed into the .readme file or a separate references.txt file in your Git Repository as well as signposted in your codebase.

Coventry University GitHub

You must use the Coventry University GitHub with your Git Repository placed into the Games Technology organisation . You will include a link to the Git Repository in your Aula submission in the .txt file.

• Your Coventry University GitHub Repository should be named in the format of “5033CMD_2425SEPJAN_Your Student ID”.
  oFor example, if my student ID was 12345, the repository name would be 5033CMD_2425SEPJAN_12345.
• Your repository must be private.
• The module staff must be added to your repository as collaborators to allow them access. (Ian Evans – ab8809)
• If you do not use the GamesTechnology organisation and/or do not add staff as collaborators, you may receive a mark of 0.
  You are expected to use this repository through the assignment and make regular commits. If a commit is made after the deadline or if module staff cannot access the repository, this may result in 0 marks being awarded. It is your responsibility to make sure your repository is viewable by the markers.

Development of Skills and Attributes

Think Creatively

In the Games Technology course, creative thinking is a core skill. In many ways, it is the core skill, as it underpins the concept of programming, and as such it is assessed in almost every assignment students undertake.

By their second year, students will be expected to apply critical thinking approaches to solution of the challenges they face, whether in terms of performance, efficiency, scalability or maintainability. While they may not be able to fully evaluate their impact, they will understand how to analyse their effectiveness.

Students will create their own physics engine suited to address the requirements of a specified scenario. This will require them to apply algorithms appropriate to the requirements of the simulation and assess their effectiveness against the performance demanded of the final software deliverable.

Marking and Feedback

How will my assignment be marked?

Your assignment will be marked by the module team.

How will I receive my grades and feedback?

• Provisional marks will be released once internally moderated.
• Feedback will be provided by the module team alongside grades release.
• Marks and feedback can be accessed by going to the assignment’s submission point on Aula. Feedback will be downloadable as a Microsoft Word document.
• Your provisional marks and feedback should be available within 2 weeks (10 working days).

What will I be marked against?

Details of the marking criteria for this task can be found at the bottom of this assignment brief.

Assessed Module Learning Outcomes

The Learning Outcomes for this module align to the marking criteria which can be found at the end of this brief. Ensure you understand the marking criteria to ensure successful achievement of the assessment task. The following module learning outcomes are assessed in this task:

1. Apply physics concepts used in game development and demonstrate an understanding of more advanced techniques employed in high-performance simulations programming.
2. Critically analyse a game scenario and determine the required elements from a physics perspective.
3. Apply Newtonian principles to the modelling of a virtual environment.
4. Evaluate and apply optimisation techniques, such as multithreading, to improve the performance of demanding computational tasks.

Administration of Assessment

Assignment Category: Coursework
Attempt Type: Resit
Component Code: Cw

5033CMD Assessment Marking Criteria

	Object Movement (25%)	Collision Detection (25%)	Collision Response (25%)	Optimisation (15%)	Video (10%)
First   >=70%	All of the below, including: Objects have both static and dynamic friction values and these differ between objects, such as different surfaces on the golf course. There are switchable integration methods present with at least 1 method more advanced than Euler. The scene contains “zones” of forces that affect objects inside of them such as wind, altered friction, speeding up or slowing down of the ball, moving obstacles in the scene etc.	Collision detection between 3 object types is present such as Sphere, Plane, AABB detection (including all combinations). Plane-Plane collision is not required. An attempt has been made at OBB detection but this may have issues.	There is a realistic impulse based response when objects collide with no issues. This affects both the linear and rotational motion of the objects involved in the collision.	There is a working broadphase collision detection phase such as using a spatial partitioning approach. There has been great use of optimisation methods such as sleeping and waking physics objects, hierarchical bounding volumes or multithreading. There are switchable optimisation methods that allow the user to turn on and off optimisation methods while the program runs to evidence their improvement when applied. Evidence metrics are calculated and displayed to the user live in a readable format such as via the console or on screen as evidence of optimisation results. There is a good range of test cases with evidence metrics to back these up.	The video fly-through shows all the physics areas working in great detail. There is narration or text overlay throughout, covering all key areas.

Upper Second 60 to 69%

All of the below, including: A force such as friction or drag is used to keep objects from moving forward forever. Objects use the same friction values (or a singular global value). An advanced integrator method (more advanced than Euler) has been used for movement. There has been consideration into allowing the player to aim their shot with more precision in direction and power that allows them to chip the ball into the air and over/around obstacles.

Collision detection between 3 object types is present such as Sphere, Plane or AABB detection (including all combinations). Plane-Plane collision is not required. There has been consideration with collectables with game logic and moving obstacles added to make an interesting golf course as well as the previous considerations.

There may be some issues with, or a limited implementation of, realistic impulse based response. This affects the linear motion of the objects involved in the collision.

There is a strong attempt at a working broadphase and phase such as using a spatial partitioning approach. There has also been a valid implementation attempt at another optimisation method such as sleeping and waking physics objects, hierarchical bounding volumes or multithreading. There is evaluation via comments in the optimised areas of the codebase explaining with evidence on how these actually do improve the physics engine. Test cases for this may be basic or singular. Evidence could include the recording of metrics from test cases such as frames per second, time taken, counters, collision check amount, bounding size changes, differing object amount, updating object amounts, different object types etc.

The video fly-through shows all the physics areas working in some detail. Narration or text overlay may lack some key areas.

Lower Second 50 to 59%	Objects move with both linear and angular motion. Objects use both acceleration and velocity to change their positions. An integrator method such as Semi Implicit Euler has been used for movement. The player can apply a few forced directional forces to the ball to allow the ball to be hit around the scene in a basic fashion, such as left, right, forward and backward. There is some basic damping to keep objects from moving forward forever.	Collision detection between 2 object types is present , including all combinations for Sphere and AABB detection (Sphere-Sphere, Sphere – AABB, AABB – AABB). Plane-Plane collision is not required. There has been consideration with collisions between the golf ball, the golf course elements and obstacles.	There may be issues (bugs, glitches, incorrect response, collision information might be incorrect/missing) with collision response but a meaningful codebased attempt at realistic impulse- based response is present. Some level of basic collision resolution does work	There has been a valid coding attempt at a basic optimisation method such as sleeping and waking physics objects, hierarchical bounding volumes but there may be issues/concerns with the attempt that stop this optimising the physics engine or causes bugs. There should be some evaluation via comments in the optimised areas of the codebase explaining how these could improve the physics engine.	The video fly-through shows all the physics areas working with no detail.
Third / Pass	Objects move with only linear motion.	Collision detection between 1 object is	There is basic collision resolution such as objects	There is some basic evaluation and discussion	The video flythrough shows some of the key physics

40 to 49%	Objects use only their velocity to change their position. A basic integrator method such as Explicit Euler has been used for movement. There has been consideration into allowing the player to hit the ball by applying a force to it via a keypress. Other considerations, if present, might have been attempted well but have issues.	present such as Sphere – Sphere detection. Plane-Plane collision cannot be used as the singular collision detection pair. There has been a meaningful codebased attempt at collectables and obstacles as well as the golf ball affecting obstacles, obstacles affecting the golf ball and moved obstacles affecting other obstacles.	instantly teleporting apart via changing their positions directly or velocity inversion.	in the codebase via comments and pseudocode on ways the student’s general physics engine could be improved, but these have not been attempted as viable working code in the student’s work. These evaluations are present at key areas in the codebase where the optimisations would be viable to include.	areas but could have showed more.
Fail   < 40%	The position directly changes, or objects do not move. There is no concept of acceleration and/or velocity. There are no forces present in the scene. There has been little to no consideration into the assignment scenario, or considerations have major issues.	No collision detection present, or heavily lacking in this area.	No collision resolution present, or heavily lacking in this area.	No optimisations have been discussed in the codebase, or optimisations are merely mentioned without any description or detail.	The video fly-through does not show the key physics areas.

Fail0 %

Late submission, code not accessible, commits made after the deadline, program does not run