Marc Price

Design-Build-Test a Persuasive Minecraft Mod

Ciocarlan et al (Ciocarlan, 2018), developed a wellbeing game that utlised some of Cialdini's well-known principles of influence and persuasion (Cialdini 1984) to persuade players to perform real-world acts of kindness.  The artefact was used to address a number of research questions including the impact on subjective wellbeing.  Although this was a significant piece of ongoing research, the artefact they used would make an interesting muse for a Minecraft mod.  Although Ciocarlan et al's results were inconclusive, the results could be used as a steer to scope-down to something achievable in the timescale for a Computing project.

This would be a DBT project, so research on the effectiveness of the artefact in behaviour change would NOT be required.

Experience of Minecraft modding, as well as keen interests in Persuasion Psychology and Positive Psychology would be needed to do something worthwhile in the timescale available to you.  Are you persuaded?

Supervisor

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

New Software for OO Design & Development Module

This is an exciting opportunity to use your software development skills to contribute to the specialist teaching materials we use here in the Computing Department.

If you did the OO Design & Development module (COMP2431) in your second year, you will be familiar with the 'JavaFish' version of the 'Fish-O-Rama' software framework.  This framework makes use of 3rd party libraries that are now legacy, and we need to upgrade the framework software accordingly.   At the same time we would like to improve its design so that students can be given a choice of IDEs rather than being tied to BlueJ.

This will be a Design-Build-Test project, and 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
  • a development plan/log based on the above design

 

Please make contact with Marc Price if you are interested in this project.

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

Cloud Simulator

Design, Build, Test a Cloud Simulator.

Description: This is a design-build-test project to produce a piece of software using a language of your choice that simulates the visual appearance of clouds in real-time.

Key challenges: study and understand state-of-the-art techniques for simulating the appearance of clouds in real-time, then implement one of them and test that it works (the test needs to verify that the code works and that the intended model used is actually implemented).  This would be a challenging project.

Although the artefact (ie your software prototype) 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, showing how the model is interpreted into code
  • 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 strategy and log, showing the planned approach to verification and the results of your tests.
Supervisor

Anomalous Event Trigger for MS Kinect Point-cloud Recorder

An interesting feature of the Microsoft Kinect depth sensor is the occasional/spurious appearance of 'orbs' in the infra-red camera output.  A number of reports have been made about this, and we have seen them a few times ourselves when working with the device.  Setting aside the heated discussion as to what these 'orbs' are (as they cannot be normally seen by the naked eye), it would be interesting to see how the depth sensor component of the Kinect interprets these anomalies (ie in terms of the resulting point-cloud data).

To this end, we would like you to Design-Build-Test an application that detects orbs in the infra-red camera image, and upon detection, it triggers a recorder, so that the Kinect's point-cloud data output and infra-red video output is captured to disk.

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
  • a development plan/log based on the above design
  • a test strategy and log, showing the planned approach to verification and the results of your tests.  As a part of this, you will need to include a method for 'cheating' the Kinect sensor using an infra-red element of a scene that is not in the visible spectrum.

Please make contact with Marc Price if you are interested in this project.

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