marlatte / battleship

A classic board game built with TDD.

Hi there 👋

I'm a front-end developer educated through The Odin Project who also enjoys:

• Making music 🎸 🥁 🎤
• Designing logos and layouts 🖼️ 🖍️
• Tearing my hair out over soccer ⚽️ 🛡️

Skilled with

battleship's Issues

Bug: cannot place ships on opposite sides diagonal

Ship placement rejected at [70] because there was a ship occupying [69], which is on the other side of the board.

Integration tests!

• Integrate and test in the console

Add random ship placement

End game!

• Write conditions for game over
• Write checker fn
• Publish GAME_OVER event

Write Unit tests!

Red - Green - Red - Green ...

De-pubsubify

Too many messages getting passed back and forth. Code is getting convoluted when trying to return info from a fn call. playRound, checkCompTurn, and checkGameOver could all be one fn if I use import instead of PubSub.

Also, having the game-controller decide where to place comp ships will take too many steps/msgs with PubSub.

Write simple HTML

No more than is necessary to capture main elements for visualizing and attacking ships.
Do not get fancy yet!!!

Fix pre- and post-game screens

Sinking ships mark nearby spots as missed

• Collect all coords where that ship sits
• Calc adjacent coords
• Attack those coords automatically

Bug: multiple turns firing

Rapid clicking on squares fires computer turns that can also shoot at its own board.

Could be solved by a universal setTimeout var that removes the event listener for the same amount of time comp decision takes, though I suspect there's a better way.

Fill out the skeleton

Problem-solving time!

Iterate over the pseudo outline, getting more specific with each pass.

If you don't know how to solve a specific challenge, mark it for the next pass or get to googling, but DO NOT skip things without making a note. That leaves unpleasant surprises for later.

This step should take a while, since it's actually several rolled into one. It ends when you run out of abstract ways to describe the steps and the pseudo is half JS anyway.

Lessons from past projects:

• Event delegation can solve issues with dynamically created elements like buttons
• Template literals are great for element.innerHTML; you don't have to create and append so many things.

PubSubify!

Decouple modules by switching fn calls to event publications

Hand-draw the UI

Logical flow

Logical flow:
A few sentences on general functionality and the steps necessary to do all those things.

Bug: Computer can't show win

endGame screen doesn't display on computer win, though the game stops.

Write 30k ft pseudo outline

Bottom Up

• What are the building blocks of your program? What units will it have?
• List out any tools, methods, or patterns you want to use (e.g. Pubsub)
• Mark places where you'll use Unit Tests.

Top Down

Walking through logical flow from first task, write out the top-level steps necessary to get this done. Don't worry about details or specific properties/methods, just finish the prompt, "Okay, then I'll need a function to do ___" for every step. Focus on what information is being passed from unit to unit. In the end, you'll have a skeleton to flesh out in the next steps.

VERY basic CSS

Black / white only, basically just do the borders and minimally acceptable spacing to make it useful.

Don't get fancy, and DO NOT make any big design decisions yet!!

Let computer take a turn automatically

Currently, only mouse clicks trigger playRound()

• Start by switching the preset computer attack btns to fire randomly.
• Then trigger this capability automatically in playRound()