Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update instructions-intermediate.md #34

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update instructions-intermediate.md #34

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 0 additions & 20 deletions instructions-intermediate.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,23 +19,3 @@ solution is better avoids thinking of **why** it is actually better.

The purpose is to experiment with design alternatives, so it is not necessary to refactor to perfection, and it is optional to use tests.
The purpose of first explaining the problem in the design is to make sure that the new design is not just different but also adresses one or more specific problems.


---

## Existing bugs and weaknesses (in trivia)
Beware that this list spoils part of the fun :)

* A Game could have less than two players - How could we make sure it always has at least two. Is this a runtime check or can this be enforced "statically"?
** What can be done in a language like javascript?
* Someone could try to create a game with 7 players, make sure that's impossible.
** or slightly easier, allow for 7 players or more
* Existing BUG: A player that gets into prison always stays there.
** Other than just fixing the bug, try to understand what's wrong with the design and fix the root cause
* Existing BUG: coins are added to the wrong player. Try to understand what made this bug likely and fix the design so that it becomes very unlikely.
* Introducing new categories of questions seems like tricky business. There are business rules: categories are evenly distributed on the board, there are an equal amount of each category.
** Could you make sure all places have the "right" question and that the distribution is always correct (i.e. same number of each category, distance always the same between categories)?
* The deck could run out of questions
** Make sure that can't happen (a deck with 1 billion questions is cheating :)
* Similarly changing the board size greatly affects the questions distribution. i.e. how do we ensure that there are as many of each category and that they repeat in a cyclic way?
** Is there a design where it is guaranteed that the question category distribution stays the same