All the tutorials below use Godot 4.1+ If you are using 3.5 then please utilise other resources.
This course utilities itch.io for playtesting purposes. Please contact your I.T. Support to ensure your game design students have access.
Using Godot 4, in order to export it in a HTML playable state you must make your game in compatibility mode at the moment. It will also not work on macOS computers. Godot 3.5 currently has better HTML support but is missing a lot of the other features. For a full explanation check out the current docs or list of current HTML 5 issues on Github.
Read the following team roles. Choose who is going to do what in your team and work to your strengths.
The ideal team number is THREE
More is not better as more time is wasted coordinating and less time is available actually developing. Most often, one team member is project manager AND another role. Discuss with your teacher and discuss with your team and make a decision. Then make sure you understand your responsibilities for the rest of this project.
The project manager is NOT the boss of everyone! They should be a good communicator and team member (as well as doing another role within the team). The role of the project manager is to:
Create and manage the project “board” (Trello)
Coordinate and help document the teams planning for the project and for each sprint
Facilitate the “Stand-ups” as you sit down ready to start work for the day to help keep team on track and communicating
Facilitate and document testing (at milestones, google forms etc.)
Run the sprint retrospective (discussion after sprint testing and feedback gained)
Coordinate tasks within team
Communicate with the team
Try to resolve problems regarding project progress and roadblocks WITH the team.
Keep a personal development log
Testing and Trialling
This team member should be an expert in programming. The programmer deals with giving the game its behaviour. They will often be working with “developer art” or placeholder graphics to create the game’s code so it behaves the way it should. Their main role is to:
Manage their tasks in the overall project board
Break down tasks into achievable steps
Plan/Code/Test each step.
Coordinate with the level designers and artists to ensure you are on the right track
Keep a personal development log
Participate in the stand-ups, sprint reviews and project planning meetings
Testing and Trialling
This team member should be an expert in the game engine. This job is harder than it seems and needs an organised person who can coordinate well with their team and integrate the components as they become available as well as adding polish to the game.
Their main role is to:
Manage the “master” project and its versions including the collaboration.
Manage their tasks in the overall project board
Integrate tested art and code assets into the main project for further testing
Create the game levels (eg. terrain, or blocking out the level before the art assets are complete)
Create level lighting in line with the project goals
Create particle systems
Create/Edit materials for the models in-game.
Integrate audio into the game
Create UI elements (menu/hud etc)
Keep a personal development log
Participate in the stand-ups, sprint reviews and project planning meetings
Testing and Trialling
This team member should be an expert in game art tools like Piskel, Inkscape or Blender.
Artists define the “look” of the game and usually have a real attention to detail.
Their main role is to:
Manage their tasks in the overall project board
Create art assets for the game (characters/props/static background etc)
Create animations (if required)
Keep a personal development log
Testing and Trialling
Participate in the stand-ups, sprint reviews and project planning meetings
Make sure you have Git installed on your computer. If you're working in a group, you'll need to set up a shared Git repository (e.g., on GitHub, GitLab, or Bitbucket).
Create a new repository for your project and push your initial project files to Git. If you’re working in a team, make sure everyone has access to the repository.
Decide on a branching strategy. For example, each team member should work on their own feature or task in a separate branch and only merge changes into the main branch when they’re complete. This keeps your project organized and reduces conflicts.
Ensure that all work is regularly committed and pushed to the repository to create backups. If something goes wrong, you can revert to previous versions of your work. Add your Backup Strategy to your document
There are a number of resources below to get you started. At a minimum every member of your team should understand the "Hello World" introduction in the GitHub Docs. One member needs to understand how to Merge branches into each other and they need to manage to repository.
At a minimum everyone in the team should understand the basics of Github as outlined in this walkthrough document.
With each new feature you should create a new branch. For instance someone might be working on the Enemy AI. They might make a brach called "Beatle Enemy AI"
One member of the team needs to become an expert in Github. Their job is when a feature is ready it needs to be committed back into the main.
As a group, begin planning your Project Backlog in Trello. The backlog should contain all the tasks that you think your game will need. And remember, you are using Agile so this can change and adapt as you begin development.
Make sure your Trello board’s visibility is public so that your teacher can see it. And make sure all members of your team are added to the board.
Now that you understand team roles and project managment add detailed tasks for each of the things you need in the most basic version of your game. Allocate those tasks to individual members of the team and ensure that the tasks are “bite sized” enough that they can be done in 1-3 lessons. Anything more and the task needs to be broken down further.
Add your Trello Board link to your development log and get it checked off by your teacher before beginning development.