groxio-learning/barquinhos

Multiplayer destructive bingo for grownups

barquinhos's Issues

Players can take turns

Problem Statement

Currently, a user can cheat by clicking all the squares on the opponent board before their opponent has taken any turns. Instead, players should be forced to take turns when playing the game.

User Story

As a player
When the game starts
And a player makes the first shot
Then that player cannot make another shot until someone else has made a shot

A player should not be able to make more than shot before another player has their turn

Implementation Notes

• Use the core Board module to track which player made the last shot
• Use that info to prevent a player from taking a shot if they are the player that made the last shot

Step 1: Build the Core Module Functionality

# a function that stores the player that just made a shot
Board.last_shooter(board)
=> %Player{}

# a function that takes an arg of a player and returns true if that person is the "last shooter"
Board.is_last_shooter(board, player)
=> true/false 

Step 2: Use The Core Functionality in LiveView

• When a user fires a shot, we should update Board.last_shooter (we will prob. want a reducer here) for everyone . This means we can hook into the shot_fired event broadcast.
• When a user tries to fire a shot, we should prevent them if Board.is_last_shooter is true for them

Game Displays Shots as Hit/Miss

User Story

As a user
When I fire a shot against an opponent
Then that shot is displayed on my opponent's board as a hit or a miss
And the shot is displayed on my own view of my opponent's board as a hit or a miss

Implementation

Step 1. When a user's live view receives a shot message over PubSub, then the user's live view should:

• Check to see if the shot was sent by themself. If so, don't do anything. If the user who receives the shot is not the user who sent it, then...
• The live view should update its own shots_received list and display the shot with the appropriate color in the browser
• Publish a "shot_miss" or "shot_hit" message with:
• Their player ID
• The shot coordinates
• An indication that the shot was a hit or a miss

Step 2. When a user's live view receives a shot_hit or shot_miss message over PubSub, the that user's live view should:

• Check to see if the person who sent the message is the same as the person who is receiving it. If so, do nothing. If not...
• Update some portion of the live view's state, in socket.assigns, to track the list of shots fired there were hits/misses. It's up to you how you want to design this part of socket.assigns.
• Update the live view's template so that shots fired by a user show up on that user's view of their opponent's board with the proper color for hit/miss.

A Player can lose

User Story

As a user
When I receive a shot
And that shot is a hit
And that hit strikes my last un-hit point
Then the game is over for that player

Implementation Plan

Step 1: Check if a hit is the "last hit"

• When a user receives a shot over PubSub
• And we check if that shot is a hit or a miss
• And it we find that it is a hit
• Then we should check to see if the user has any un-hit points left - hint: where in socket.assigns are we storing the knowledge of which hits we've received?

Step 2: Game Over

• If that hit is the "last hit" and the user has no more points that are open, then the game should be over for that player

What does it mean for the game to be over? Keep in mind that more than two players can play the game. So, if one player lost that doesn't necessary mean the other player one. A player looses when they have no more points to get hit and a player wins when they are the last player standing. So, if there are only two players, and one loses, then the other did win. But if there are more than two players, then one loses and the others are still in the game.

Here are some ideas we might build:

• When a player looses, broadcast a "player lost" message with the player ID.
• When the live view receives that message, check to see if the player ID from the message is the same as the player ID of the current live view. If it is the same, display a game over message to the player that lost and remove the opponent game board from the view so that they can't fire any more shots.
• If it is not the same, determine if there are more than two players. If there are more than two players, display a "player #{id} lost" message but let the remaining players keep playing. If there are only two players, display a "You won!" message and end the game by removing the opponent board from the current player's view.

LiveView - TODO's List

• use flash message to give more hints to the player when it needs to pick orientation and ship
• validate the boundary for the board
• validate when try to put ship above other ship
• remove the button after picking the ship on board
• improves the variable names to tells more about the context/action they have
• register shots dynamically instead of hardcode

More LiveView ToDo's

Some more ToDo items that came out of "Group Attack" (@SophieDeBenedetto Mohammad @jacquelineIO @graceinwonderland)

• Timer optimization (if you don't make an attack in X minutes, the game makes one for you)
• Thinking about accessibility - should we disable points so that you can't make the same attack twice?
• Display difference between a hit/miss

Next time...

• Integrate PubSub to make attacks against another player

Barquinhos tutorial project

We'd like to write up some pieces of documentation that will allow other mentors and mentees to go through the process of building the Barquinhos app to learn more about Elixir, Phoenix, and LiveView. We''ll produce the following docs:

• Overview - this document will outline the goals of the project and the desired end result. It will explain the game that will be built and how the game works.
• Project Phases:
  • Part I: Build the Functional Core - This document will explain what needs to built into the functional core---the board, player, ship and any other modules and their attributes and behaviors.
  • Part II: Set Up LiveView - This document will explain the next set of work: Setting up a new live view so that a user can visit /game and see some welcome message
  • Part III: Game Play - This document will break down all of the game features, starting with something like: "a user visits /game and sees the game board", "a user visits /game and sees the game board and ships", "a user visit /game and can place ships", all the way through to our complete game play in which users take turns and can win/loose.
  • Part IV: Refactoring and Tests

We'll write up each document with some sections that outline deliverables like this issue does #37. We can leave off technical implementation details for now though.