Overview of Software Engineering
GAMES PROJECT - GROUP COURSEWORK
COMSM01109 (unit)
Coursework Brief
This is a group coursework, consisting of a project report and presentation, making up 50% of this module’s marks:
o 25% in class test A
o 25% in class test B
o 25% project report
o 25% project presentation
The aim of this group coursework is to design and develop a game, applying and reflecting on the software engineering methods you have learnt in the taught component of this module. Each team of 5 people (assigned randomly) will develop a novel computer game based around adding a twist to an existing game or game archetype. We would like your team to identify and discuss three major software development challenges in developing your game. You will need to come up with your own idea, but for example:
• Pac-man, but the ghosts can rearrange the map
o Challenge 1: The ghost’s AI
o Challenge 2: Data structure for storing the map
o Challenge 3: Global leader-board
• Asteroids, but you play as the asteroids rather than the spaceship.
o Challenge 1: Multiplayer implementation
o Challenge 2: Asteroids fragmentation.
o Challenge 3: Spaceship AI
• Tetris, but the blocks have different properties.
o Challenge 1: Development of physical simulation
o Challenge 2: Documentation and onboarding for block properties
o Challenge 3: Algorithm for collision detection
Remember that the primary aim of this module is to learn, apply and reflect on the principles of good software engineering. The quality of your process is the primary focus of assessment and not your game idea, though we hope that a quality game will be the outcome of a good process! You will be developing the game inProcessing, a language based on Java that allows for the rapid development of visual applications. We will not be teaching you Processing, your team will be expected to engage and learn from online resources available (we will link you to these). Processing has many libraries which you are free to use, but remember that you need to identify and overcome three challenges, so if you use a library (for say physical modelling) then this may negate the challenge. Please note that this is a software engineering module and not a game design module, so although good narrative/artwork/levels/content will elevate a game, we are ultimately interested in your team’s ability to develop software.
Project Report
Your group report will be written upon Github (formatted with Markdown) as the front page of your team’s repo, within the module’s Github organisation:https://github.com/UoB-COMSM0110. Please follow the report structure below. For each section we want to see that you’ve engaged with the taught material and reflected on your process. You can also demonstrate that you’ve gone beyond the taught component. We’ve given a rough indicator of how long each section could be, however we won’t be penalising you if you go under or over (within reason!). Include as many figures, tables, and references as you need.
1. Team
o Who’s in your team + team photo.
2. Introduction (5% ~250 words)
o Describe your game, what is based on, what makes it novel?
3. Requirements (15% ~750 words)
o Use case diagrams, user stories. Early stages design. Ideation process. How did you
decide as a team what to develop?
4. Design (15% ~750 words)
o System architecture. Class diagrams, behavioural diagrams.
5. Implementation (15% ~750 words)
o Describe implementation of your game, in particular highlighting the three areas of
challenge in developing your game.
6. Evaluation (15% ~750 words)
o One qualitative evaluation (your choice)
o One quantitative evaluation (of your choice)
o Description of how code was tested.
7. Process (15% ~750 words)
o Teamwork. How did you work together, what tools did you use. Did you have team
roles? Reflection on how you worked together.
8. Conclusion (10% ~500 words)
o Reflect on project as a whole. Lessons learned. Reflect on challenges. Future work.
• Quality of report writing, presentation, use of figures and visual material (5%)
• Documentation of code (5%)
• Individual contribution. Provide a table of everyone's contribution, which may be used to weight individual grades. We expect that the contribution will be split evenly across team- members in most cases. Let us know as soon as possible if there are any issues with teamwork as soon as they are apparent.
Project Presentation
Your team will be presenting the project as a playable demo in the last week of TB2 and in a demo video:
• Games Demo (50%)
o There will be a live games demo in the last week of TB2 (date to be confirmed). This is a chance to show your game off to the rest of the cohort and the department.
o We will play your game (so it must run!). Plan for a short play-through of maximum 5mins. Markers will circulate and play all the games.
o The marking criteria is simple. You will pass if your team has a working and playable game! Higher marks will be given if your game is fun and engaging and demonstrates challenge (refer to those three challenges). We look forward to playing your game! :-)
• Demo Video (50%)
o Include this at the top of the Project Report (can host it on YouTube / Streams)
o This is asnappy and fun video up to ~3mins long, for a lay audience to understand (just to confirm, we’re not penalising you if you go slightly under or over, but we may stop watching if it goes too far above 3mins!)
o Things to consider including: What’s your novel idea? Who is your team? And what were their roles? What were your three challenges? What does gameplay look like? What was your process? What’snext?
o This video should sell your idea and make people want to play! Think Kickstarter. Would someone want to fund further development after watching this?
o You don’t have to all appear in or narrate the video, we are assuming this is a team effort, so won’t be looking out for everyone to be in it!
o We will be marking this on: Presentation, use of visual material, clarity of idea,
discussion of the three challenges, discussion of process and teamwork, discussion of future work.