Game Engineering

Game Engine Plug-in: Broad-phase Collision Detection using Quad-tree Partitioning

This project is specifically for students who have already developed a Game Engine through their work on the 2nd year Games module and are continuing that work on the 3rd year Games module.  Your Game Engine Architecture will need to be developed to the extent that a Collision Management element already exists.

In this project, you will design, build, and test an extension to the Collision Manager of your Entity-based Game Engine Architecture, that introduces a 'broad-phase' test alongside the already functional narrow-phase test (eg the Monogame Rectangle 'hitbox'), that employs quad-tree partitioning to cull the number of narrow-phase tests needed per update.  Testing will require verification of your Engine + demo software against the requirements.

Supervisor

Game Engine Plug-in: Narrow-phase Collision Detection using Separating Axis Algorithm

This project is specifically for students who have already developed a Game Engine through their work on the 2nd year Games module and are continuing that work on the 3rd year Games module.  Your Game Engine Architecture will need to be developed to the extent that a Collision Management element already exists.

In this project, you will design, build, and test an extension/modification to the Collision Manager of your Entity-based Game Engine Architecture, that replaces the built-in Monogame Rectangle based 'hitbox' with a bespoke implementation of the Separating Axis algorithm for arbitrary convex polygon shaped hitboxes.  Testing will require verification of your Engine + demo software against the requirements.

Supervisor

Game Engine Plug-in: Physics Behaviour Simulator

This project is specifically for students who have already developed a Game Engine through their work on the 2nd year Games module and are continuing that work on the 3rd year Games module.  Your Game Engine Architecture will need to be developed to the extent that a Behaviour Management element already exists.

In this project, you will design, build, and test an extension to the Behaviour Manager of your Entity-based Game Engine Architecture, to allow entities to exhibit 'realistic' physics behaviours, including propulsion, gravity, and 'bounce'.  Testing will require verification of your Engine + demo software against your chosen physics model.

Supervisor

Game Engine Plug-in: Directed Search Path Finder

This project is specifically for students who have already developed a Game Engine through their work on the 2nd year Games module and are continuing that work on the 3rd year Games module.

The problem of Path Finding in games is broken down into two (slightly) smaller problems: environment mapping and graph search.  Environment mapping is where the game levels are 'filtered' (usually manually) into meaningful maps of obstacles, navigable regions, and route costs.  Graph search is the problem of finding shortest/least-expensive path through a graph of data.

Additionally, NPCs need to be able to navigate along paths returned by a path finder system in a realistic-looking way.

In this project, you will design, build, and test an extension to your Game Engine that allows game developers to add Path Finding to NPCs in their game.  Testing will require verification of your Engine + demo software against a model of a chosen directed search algorithm (eg A*), environment map, and NPC movement behaviours.

Note that this is likely to be a challenging project.

Supervisor

Game Engine Plug-in: Team-based NPC Behaviour Simulation

This project is specifically for students who have already developed a Game Engine through their work on the 2nd year Games module and are continuing that work on the 3rd year Games module.  Your Game Engine Architecture will need to be developed to the extent that a Behaviour Manager element already exists.

In this project, you will design, build, and test an extension to the Behaviour Manager of your Entity-based Game Engine Architecture, to allow NPCs to be implemented with team behaviours (eg shoaling or 'squadding').  This will require a hierarchical approach to the AI Components of your Engine.  Testing will require verification of your Engine + demo software against a model of a chosen team-based behaviour.

Supervisor

Entity-Component-System (ECS) Game Engine Architecture

If you completed your 2nd year games module with a more-or-less complete game engine architecture, you might enjoy the challenge of creating a component-based (ECS) game engine for your 3rd year project.

This would be a DBT project that is primarily focused on Software Engineering and Game Development. You can use any programming language of your choice, however, you might find it less challenging to use a language that you are already familiar with. Although some kind of demo will be required to test and showcase the software, producing a playable game prototype would be beyond the scope of the project.

Key challenge: how to design, implement, and verify an engine with the component-based paradigm.

Considerable background research on the component-based approach would be necessary prior to starting this project.

As this is a DBT, the question is what would be an appropriate test?  To a certain extent, this is something that you would have to answer yourself, via secondary research.  However, the most often cited reason for opting for ECS architecture over an OO entity-based architecture, is performance.  This isn't the only lens you can take, but if you choose this, then your test could be a comparison between a newly created ECS engine and an OO entity-based engine.  Your secondary research would then need to also look at benchmarking tests to see how comparisons have been done by others, and which would be most suited in this context.

Another comparison test might be to look at software analysis of ECS  vs OO (eg in terms of Cohesion and/or Coupling).  In this case, your secondary research would need to also look at how others have measured these things.

Although the artefact (ie your software) will be a key deliverable, we will also need to see:

Supervisor

Entity-based OO Game Engine Architecture in C++

This is a Design-Build-Test project to produce a game engine using modern C++.

This would be a DBT project that is primarily focused on Software Engineering and Game Development.  Although some kind of demo will be required to showcase the software, producing a playable game prototype would be beyond the scope of the project.

Key challenge: how to design, implement, and verify a performant game engine in C++.

Considerable background research on modern C++ (eg C++ 14) would be necessary to succeed with this project.

Although the artefact (ie your software) will be a key deliverable, we will also need to see:

  • a requirements specification and plan, developed through background research/study and discussions with your supervisor
  • a detailed and reasoned software design, highlighting any key design patterns that have been employed, and descriptions of how these are implemented using modern C++
  • a development plan/log based on the above design (it is normal practice for a design to evolve throughout the development process, especially if using an agile approach)
  • a test design/strategy and log, showing the planned approach to verification and the results of your tests.

 

Your test would probably be best done as a comparison between two engines with the same design, but coded in C# and C++ (hence you could use your engine from COMP2451) as the basis for the C# version.  The comparison would probably need to explore some aspect of performance, however, you should also consider portability - a C# program is likely to be better optimised for a Windows-based OS than any others.

WARNING: this is likely to be VERY CHALLENGING for anyone who has never used C++ before!

Supervisor