basketball

Trêsinformal's 2023 team basketball game

Branch
master
develop

Meetings

• Date: Weekly, every Wednesday
• Time: 17:00-19:00 Amsterdam/Stockholm time
• On Discord, see FAQ
• Considering to join? See the FAQ too :-)

Game design document

The game design document is written in English. Ideally each sentence is SMAR (specific, measurable, assignable, relevant, see SMART criteria), linked to (at least) one Issue. The game designers decide what is in the game design document. (see Issues what are the criteria for a good Issue)

• The game has two players #11.
• The game finishes when either player reaches 20 points #20.
• The game has one basketball #14.
• All objects follow the laws of gravity (Newton's Second Law) #15.
• There is an option to play on either one side or two sides.
• There is either one human player and a player controlled by computer or two human players.
• There are two hoops, one in each half of the yard.
• The player's clothes should have different colors.
• The game has music.
• The music can be muted.
• The game counts a time #61.
• During the game the time shows.
• The game can be paused.
• If the player scores from inside the line, she/he gets two points.
• If the player scores from outside the line she/he gets three points.
• If one player throws the ball, the other player can catch it.
• Both players can jump #66.
• When the ball is free, the players can run into it and take it.
• The ball bounces #65.
• A player can take the ball from another player by running into her/him and pressing a key.
• The key needs to be released to try again.
• The player can choose if she/he wants to play as a girl or a boy #67.
• The player can choose a flag for her/his team.
• Both players can't choose the same flag.
• The scores of both playes are visible on the screen.
• The player can choose the hair color #68.
• The player can choose the skin color.
• A basketball's center has a coordinate with an x and a y #30.
• The (one) ball starts at the top-center of the screen #25.

Issues

Issues are the technical translation of the game design document. Ideally each sentence in the design document results in one Issue.

There are two types of Issues:

• Testable: deal with the game logic and contains a test in pseudocode (when written by juniors) or C++ (when written by mediors and seniors).
• Untestable: deal with how the game looks like and needs to be verified by a human

We use the Model-View-Controller Design Pattern to separate the game logic, from the game visualization and input:

git branching model

Our git branching model:

• master/main: a working version
• develop: merging topic branches
• topic branches: where work is done, for example, Issue x is done on a branch called issue_x

Videos:

• Overview of the git branches
• Working with this git branching model

GitHub workflows

1. Modify README on main branch using GitHub web interface
2. Modify README on topic branch using GitHub web interface
3. Modify README on main branch using git
4. Modify README on topic branch using git
5. Merge topic branch to develop yourself
6. Merge topic branch to develop with a code review

Project workflows

• From design to feature
• Splitting up an Issues to smaller Issues