Team Project 2020-2021

Task Description

Introduction

For this module you will produce a video game in a team using Java. You must use Java. Each team will produce its own game. The exact type of game that each team makes is to be decided by the team. However, each game must have certain core features. These are listed below.

One of the most important aspects of this module is that you work together in a team to create a product. The product must be the result of teamwork, not of individuals taking little parts of the project away and working alone, without communicating with each other. You must meet regularly online to discuss your progress as an individual and as a team, and all members of the team are expected to attend these meetings and to contribute. You must use a shared git repository for your code. The teamwork aspect of this task is assessed.

The assessment for the module will be described in a separate document.

Core features of your game

Your team can decide which type of game you want to make. However, it must have the following core features. How these are reflected in your game depend on the type of game that you decide to make. They will not be the same for each team. Some games may have more emphasis on some features rather than others.

1. Competitive play. Your game should allow multiple players to compete with each other. You can also, optionally, include co-operative modes. If your team feels that co-operative only is the best model for your game, please discuss that with your TA. It will be possible to do that if it makes sense for your game.

2. Networking. Your game must allow multiple players to play across a ‘network’. Considering that for this year you will be unable to sit in the same room together the minimum requirement is that you get this working on localhost. Your team may wish to investigate how you can implement this across a wider network but that is optional for this year.

The specific networking arrangement depends on the type of game but, for example, you might create a client-server type arrangement in which multiple clients connect to a server that controls the game.

3. Artificial Intelligence. Your game must have computer-controlled players. They do not need to be present in all game modes but they must be available in at least one game mode. The computer-controlled players might be individuals or teams, depending on the type of game. Your game may have only one game mode but sometimes there will be multiple game modes - each one have different objectives, etc. You do not need to consider, and don’t have time for, the implementation of ‘advanced AI’.

4. User Interface. Your game must have a user interface, i.e. a convenient way for players to interact with the game. This will almost certainly require a menu as a minimum but will more than likely also require other interface entities such as dialog windows that have a range of controls, clickable icons, etc. The user interface will also include crucial feedback information for the player.

5. Audio. Your game should include audio in the form of music and spot effects, as a minimum. You must be able to switch the music off!

Implementing the game

How you implement the game is up to you. Your team will need to do some research on this in the early stages. Which components will be needed? How could they be implemented? It would be a good idea to ask individual team members to research one or more areas of the implementation, perhaps in line with their interests and/or responsibilities allocated to them (see also below). Team members can also team up to work on something rather than researching alone. You do not have time, however, for an extensive research phase. You need to get on with the implementation. Do not be tempted to allocate the first three weeks to ‘research’.

Video game software architecture

A video game program contains a number of key components. Some of the components are related to each other but you should to treat them as independent decoupled components as far as possible. You won’t need all of the components found in a modern video game, and may choose to organise your program differently, but you should not simply create a ‘monolithic’ architecture into which you dump all of the code. Good software engineering principles must be observed. At the very least you will need a good OO structure in your code. The appropriateness of your code design will be assessed in your final submission.

Some common components

Renderer. The renderer is responsible for drawing the game on the screen. There are libraries available in Java to draw graphics for you. You can use something like lwjgl or simply use JavaFX. Don’t use Swing. You may also choose to create your own rendering library. If you choose to use an existing library you may be able to create better graphics but note that you team will not receive credit for code it did not write. That doesn’t mean you shouldn’t use a library because the library will possibly give you the capacity to create additional features (by freeing up time). However, your team may want to create its own library. That is fine.

It will be very important to consider the decision you make over the renderer with the decision you make about the UI (below). You will probably want to use the same library for both. You can use JavaFX for both.

Networking. Your game will need a networking component, i.e. a component that establishes connec-tions between machines and manages the flow of data between them (as stated above, this can be on localhost only). Networking functionality is well-established in Java and can be implemented easily using the available libraries. However, there are some issues to be faced when implementing networking in a game context. One of the issues is deciding which machines in the network are the ‘authority’ on the game state. In the client/server model, for example, is the server the authority on the game state or are the clients? In any case, the key issue is that you must reflect a consistent game state on all clients.

Physics and collisions. Your game might not have much by way of requirements for physics but even if you only have the ability for player characters in the game to ‘jump’ (i.e. in the ‘platform game’ genre) then you will at least want to take gravity into account (if in an atmosphere in which gravity applies ...). This component also often takes care of the crucial task of collisions. The collisions system provides the ability for collisions between objects to be detected and resolved (i.e. to decide what happens when a collision has occurred). This part of the system will almost certainly need to interact with other components. For example, the renderer to show an explosion, and the networking component to communicate the collision.

Artificial Intelligence (AI). The artificial intelligence system controls the computer-controlled players (individuals and teams). You will not have time to implement advanced AI techniques. The term ‘Game AI’ actually includes many things are not really AI. For example, it includes path finding. Don’t get too ambitious about the extent of your AI. After all, most commercial games have fairly basic AI.

Audio Manager. The audio manager manages all of the audio played in the game, including music and spot effects. Java libraries are available to help you use audio.

User Interface (UI). The UI system is responsible for all on-screen input and output. This includes any feedback given to the user that is not part of the game itself (an explosion is feedback but is not generally part of the UI. A message saying “You died!” might be part of the UI). Don’t underestimate the importance of the UI. Your UI should embody HCI principles.

Game Logic. Last but by no means least there is the game logic component. This is the component that embodies the game rules and how the game actually plays. The components above really exist to support this component.

Organising your team

You need to consider how to divide the task up across the team. Where team members have a special interest in a particular area it might be worth trying to accommodate that. There are a number of com-ponents that are fairly well-defined. For example, rendering, networking, AI, UI, etc. Each one of these might be taken by a particular team member. Workloads must be equalised as far as possible though and if a task appears easier than others then some redistribution will be required. For example, if someone takes ‘physics’ and then the only physics in the whole game is the use of gravity for jumping, then that person should not sit back having completed this less-than-onerous task. They should seek other work to do. Your teaching assistant and the module lecturers will be on hand to advise you in this regard.

All of the team members need to do programming. One person should not designate themselves ‘designer’ or ‘team leader’ or ‘artist’ and do no actual programming. Everyone needs to do programming and every-one needs to do a largely equal amount of programming. This will be part of the assessment.

Do not appoint a formal ‘team leader’. A team member may end up taking that role by default but it is not a role that receives any credit in itself.

However, since you will all be working remotely this year there are some additional considerations to the teamwork aspect of the project. Probably the most difficult part of the project overall is integration. Integration is the process by which you bring the code done by different team members together into a single project. Integration should be seen as a continual task, and definitely not left until the end. It should not even be left past week 3.

The task of integration is intimately linked to your use of the Git repository for your team. This might prove a challenging part of the project and, although all of the team must push code to the repository, you could consider asking one team member to take charge of the repository and to try and lead the effort to integrate the code. That is not to say that this will be viewed as that student’s responsibility by the module lecturers. All team members are equally responsible. But it might help you organise yourselves more effectively.

No individual should announce to the group “I am doing the networking” (for example) without a team discussion. Nobody has the right to demand that they work on a particular component. I will be listening out for cases like this and I will deal with them.

Code integration

You must seek to integrate all team members’ code from the beginning (or as near to it as possible - but see the assessment document). Do not leave integration until ‘later’ since that is likely to cause significant problems. You must use the Git repository provided for your code. Each team member can have at least one branch to themselves but their must also be a main branch that contains the integrated code. You will be assessed on your level of integration at the prototype demonstration stage (see the separate assessment document). If you have a team member who is not integrating their code, please contact the module leader. The balance of Git commits across the team will be part of the assessment of your final report and product.

Types of game

You may make any type of game apart from ones that involve controversial themes and content. Games that the module leader decides have inappropriate content will be scrapped and you will need to start again.

If you are not much of a gamer, do some research on game types. By now, most people have at least played some kind of game on their phone. Talk to your team members and the module leader if you really have no idea about types of game.

If you do not like ‘violent’ games then try and persuade your team to try a different type. Not all games need to involve killing things. Other types of game include role-playing games, platform games, strategy games, simulation games, puzzle games, adventure games, stealth games, rhythm games, sports games. Thus, there are many options.

Graphical style and art

You should probably make a 2D game. 3D games are harder to get right in the time you have available, although not impossible. Your team needs to be very confident to get a 3D game right.

There are many 2D game options too. The hardest type to get right is the isometric game. This is a sort of 3D view but is implemented as a 2D game. Isometric games can be very attractive but, as just stated, are not as easy to implement.

Most teams will probably implement a 2D game with a ‘top-down’ or ‘side-on’ view. Do some research on those if you are not sure what they are. Some 2D games have ‘scrolling’ screens too. This isn’t too hard to implement and is very effective in certain types of game. The easiest type of 2D game to implement, however, simply replaces the entire screen each time the player enters a new area of the game.

Clearly, you will want your game to look as nice as possible. However, unless you have someone in the team who can create good artwork in a short space of time, you should focus on creating a game with a simple but effective look. Simple-looking games can be very effective. Also, a team member who does only artwork will fail the module. Everybody needs to do programming.

You could use art that you have found online for this, provided it is genuinely royalty free. You need to acknowledge where the artwork has come from in your final report. However, this might seem like an easy option but it is still hard to get a game made with other people’s artwork to look good rather than just looking like a ‘Frankenstein’s monster’ of a game.

Speak to the module leader for more advice on this and anything else in this document.