Othello - HackMD

<img style="display: block; margin: auto; padding-bottom: 30px" src="https://hackmd.io/_uploads/BkaoT5yfke.png" alt="Step 1" width="500"> :::danger Code Checkpoint: Sunday, November 24th, 11:59 pm (in conceptual hours) Early Handin: Sunday, December 8th, 11:59 PM ET Regular Handin: Tuesday, December 10th, 11:59 PM ET Late Handin: Thursday, December 12th, 5:00 PM ET ::: **\*\*You should only use the late hand in if you are yet to meet MF. Note that you will get a -8% deduction should you choose to submit on the late deadline.\*\*** Watch the Othello demo [here](https://youtu.be/nt7sit6MWvE)! **Help Session:** Saturday, November 16th, 11:00 am **Minimax Help Session:** Wednesday, December 4th, 3:00 pm # Assignment Roadmap :::info [Introduction](#Introduction) [Collaboration Policy Reminder](#Collaboration-Policy-Reminder) [Helpful Resources](#Helpful-Resources) [Installing Stencil Code](#Installing-Stencil-Code) [Grading](#Grading) [Important Prelude](#Important-Prelude) ### **[FUNCTIONALITY](#Functionality)** [Rules of Othello](#Rules-of-Othello) [Coding Incrementally](#Coding-Incrementally) [Code Checkpoint](#Code-Checkpoint) \*\*[Minimum Functionality Requirements](#Minimum-Functionality-Requirements)** [Full Functionality Requirements](#Full-Functionality-Requirements) [Bells & Whistles](#Bells-&-Whistles) ### **[IMPLEMENTATION](#Implementation)** [The Computer Player](#The-Computer-Player) [Evaluating the Board](#Evaluating-the-Board) [MiniMax](#MiniMax) ### **[DESIGN](#Design)** [Design Questions](#Design-Questions) [Program Design](#Program-Design) [The Board](#The-Board) [The Controls](#The-Controls) [The Players](#The-Players) [Game Play](#Game-Play) [Getting User Input](#Getting-User-Input) [Final Design Note](#Final-Design-Note) ### **[STYLE](#Style)** ### **[HANDING IN](#Handing-In)** [README](#README) [Handin](#Handin) ::: ## Introduction Congratulations on choosing the BESSSST CS15 final project! Completing Othello will introduce you to the extremely exciting field of Artificial Intelligence. Your assignment is to write a program that will allow a person and/or computer to play the game of Othello. So cool right?! Never fear - you do not need any prior knowledge of Othello (i.e., what it is, what it looks like, how to play it, etc.), or of AI, to complete this final project. In fact, you can learn how to play the game when you come to conceptual hours because we have a physical Othello Board! ## Collaboration Policy Reminder If you ever have questions about the [collaboration policy](https://docs.google.com/document/d/10rbbd0Y6s1JUzPe8VmoWcL_Mz26XczX-i7p2LUFa9vc/edit?usp=sharing), refer to the collaboration policy or ask a TA! <img style="display: block; margin: auto; padding-top: 15px;" src=https://hackmd.io/_uploads/BkSOpo1nC.png width=600px> :::danger **Note:** The usage of any artificial intelligence technologies, except those explicitly endorsed by CS15, is *strictly prohibited*. Because of TAs reading your code and a software package we use called MOSS (Measure of Software Similarity), illegal collaboration is easily detected in CS15. ::: ## Helpful Resources * This handout! * [Othello AI Handout](https://hackmd.io/@Fall2024-CS15/SJZV8SCiR) * [Othello AI Help Session Recording](https://youtu.be/F-vLrqA82dQ) * [Othello Help Session Slides](https://docs.google.com/presentation/d/1gEAa-Ahlj3zqIEtry_xyl4eBXRbY3AhTz6Ws1InQyIA/edit?usp=sharing) * [Othello Help Session Recording](https://www.youtube.com/watch?v=PCpVHCfVfko) * [Othello Demo](https://youtu.be/nt7sit6MWvE) * [Style Guide](https://docs.google.com/document/d/1olSJxbrhuIystA_kVbmKu4V8JfN7HE-eDzM5blkoeFw/edit?tab=t.0#heading=h.b1nvuu1nggmv), [GitHub Guide](https://docs.google.com/document/d/1tSxfUIn-Ro6Pr1X4y21BbYKdsiK-nlWW3pGDfyh7SQ8/edit), and [README Guide](https://docs.google.com/document/d/1QJPit-_8ZC3r4l_f5F3ydMK34-NchBYgwtm0c21iwsU/edit?usp=sharing) * [CS15 JavaFX Guide](https://docs.google.com/document/d/1cOq649OLNp0-UHxz5W5KAOH-KyM2VXvq_TKmuGHv0Rg/edit) and [JavaFX Javadocs](https://docs.oracle.com/javase/8/javafx/api/toc.htm) * [CS15 Debugging Guide](https://docs.google.com/document/d/1UmARFvKHt5_llLrRJ61exDU-hj1mZ_LTVOTLBtIppmo/edit?usp=sharing) ## Installing Stencil Code Click [here](https://classroom.github.com/a/Vht5lQhr) to get the stencil from GitHub - refer to the [CS15 GitHub Guide](https://docs.google.com/document/d/1tSxfUIn-Ro6Pr1X4y21BbYKdsiK-nlWW3pGDfyh7SQ8/edit) for help with GitHub and GitHub Classroom. Once you’ve cloned your personal repository from GitHub, you’ll need to rename the folder from **`othello-<yourGitHubLogin>`** to just **`othello`**. You will have issues running your code until you make the change. ## Grading The grade for this assignment will be determined by [functionality](#Functionality) (50%), [design](#Design) (35%), and [style](#Style) (15%). See each of those sections for more details of this grading breakdown. An ‘A’ project would meet mostly all [full functionality requirements](#Full-Functionality-Requirements) with good design and style. --- ## Important Prelude This handout is quite long and dense! Remember that we will be having a help session very soon to explain most of the concepts (e.g., MiniMax) in gory detail. **Othello is more conceptually difficult than programming intensive** - think very hard about your design before you begin to code, and make sure you code incrementally! Also, **make sure you read** **both** **handouts** ***carefully*** **at least twice and watch the [demo](https://youtu.be/nt7sit6MWvE) a couple of times too. We recommend watching the demo before reading the handouts as it can provide helpful context. A thorough understanding of the handouts will help you grasp the concepts of the project. We know it’s hard to read every word of an assignment handout. We’ve been there. But it’s super important, particularly for this assignment.** # Functionality Your assignment is to create the game of Othello which should support three modes of play: human vs. human , human vs. computer, and computer vs. computer. A computer player will determine its moves with a standard Artificial Intelligence algorithm called ++**MiniMax**++. Your program should display the board and the game pieces graphically using JavaFX. At the beginning of the game, the program should display the initial board and the four initial game pieces (**We strongly suggest that you watch the [demo](https://youtu.be/nt7sit6MWvE)** for a more concrete idea of what the GUI might look like, and how the game works). The user should be able to select **either** player to be a human player or a computer player. (You can play as human vs. human, human vs. computer, computer vs. human, computer vs. computer) Computer players should be able to play at one of the three levels of intelligence. If both players are computers, they may play at different levels. A computer player should be able to make an intelligent move using the **MiniMax** algorithm and should make this move on a time delay so that moves are visible (especially in computer vs. computer games). Moves made by a human player should come in the form of mouse clicks. ## Rules of Othello The game of Othello is played on an 8 by 8 grid of board spaces. The game pieces are black on one side and white on the other (though you are free to use any colors you like, as long as they are distinct from one another). Each player is assigned a color. They take turns placing pieces on the board with the player's color face up. The goal of the game is to have the most pieces of your color on the board when the game is over. You can flip your opponent's pieces from their color to your color by "sandwiching" them. **A valid move must sandwich at least one of your opponent’s tiles.** The diagrams below should make this clear: **0. Initial Board and Pieces** The four initial board pieces are as shown. Either Black or White can go first. Suppose White goes first. <img src="https://hackmd.io/_uploads/Hk2nJuQn0.png" alt="Othello Step 1" width="220" style="float: left; padding-right: 30px">   **1. White to Move** Move Valid moves are 3d, 4c, 5f, and 6e. White sandwiches Black's piece at 4d by placing a tile at 3d and in doing so flips over Black's piece at 4d to white. At the end of this move, the score is 4 White, 1 Black (number of pieces in each color). <img src="https://hackmd.io/_uploads/HkhYXdm3A.png" alt="Othello Step 2" width="220" style="float: left; padding-right: 30px">   **2. Black to Move** Valid moves are 3c, 3e, and 5c. Black must now try to sandwich one or more of White's pieces. Black places a piece at 3e and sandwiches White's tile at 4e which flips to black, and the score is 3 for all. <img src="https://hackmd.io/_uploads/SJJHrd7hA.png" alt="Othello Step 3" width="220" style="float: left; padding-right: 30px">   **3. White to Move** Valid moves are 2f, 3f, 4f, 5f, and 6f. White decides to place a tile at 3f  and hence sandwiches two of Black's tiles, one at 3e and one at 4e diagonally. They both flip over to white. Score changes to 6 White, 1 Black. <img src="https://hackmd.io/_uploads/SJJHrd7hA.png" alt="Othello Step 4" width="220" style="float: left; padding-right: 30px"> **4. Black to Move** Valid moves are 2e, 3c, and 5c. At this point in the game, Black is behind because they have only one piece on the board while White has 6. One well-placed tile, however, can flip many other tiles in Othello. With each move, a player must sandwich at least one of their opponent's pieces - this constitutes a valid move. You must also consider the scenario where we’ve sandwiched *multiple* pieces of the opposing color, and must now flip each of these sandwiched pieces to become our color. For the rest of this handout, when we use the term “**move**”, we are referring to valid moves only. If no move is possible, then a player must forfeit their turn. The game ends when neither player can move (note that this includes when all the board spaces are filled). At that point, the player with the most tiles of their color on the board is the winner. ## Coding Incrementally At this point, you should be familiar with incremental coding! This is a complex program with many different parts to it. It's **incredibly important** to thoroughly plan your design before starting to code. The design of this project is quite complicated, so be sure to plan a *detailed* design before you start coding. That said, we **very highly recommend** that you implement human vs. human play including move and game over checking and turn taking before trying to incorporate computer play. This is because computer play requires functional game play methods in addition to a complicated intelligent strategy. :::success ### Code Checkpoint This project will have a checkpoint with TAs to ensure you’re on track to complete the project in time! *The checkpoint is **less than a third of the way** through the project and is there to make sure that you get started. The later parts of this project can be more time consuming than the first parts so please make sure you **keep working on it after you meet the checkpoint!*** ::: You must come to Conceptual Hours to get checked off for the code checkpoint by Sunday, November 24th, 11:59 PM with the following requirements: 1. Class and inheritance/interface diagrams completed with an explicit design of the entire intended final program 2. Board and initial pieces are set up. Human player can place pieces anywhere on the board using mouse clicks (at this point, you don’t need to have turn-taking or piece flipping done) ## \*\*Minimum Functionality Requirements** **REMINDER:** You have to achieve minimum functionality on all projects to pass the course, and since this is the final project, you cannot hand in again! MF Policy Summary: *In order to pass CS15, you will have to meet minimum functionality requirements for all projects. MF requirements are **not** the same as the requirements for full credit on the project. You should attempt the full requirements on every project to keep pace with the course material. An ‘A’ project would meet all of the requirements on the handout and have good design and code style.* To meet minimum functionality for Othello: * Play alternates between two players according to the standard [rules of Othello](#Rules-of-Othello). * Human vs. Human games run according to the rules. * Only the current player can make a move, and moves must be valid. * Pieces flip colors when a sandwich is made. * Computer vs. Computer and Computer vs. Human games can both be run. * Only valid moves are made and pieces flip colors properly. * For games with a Computer player, there is a timeline delay so moves can be seen on screen. * The computer player uses a recursive algorithm to choose its best move. * Move choices are made based on future configurations of the game. * **Level 1 intelligence works correctly**, and chooses optimal moves that take the number of pieces flipped into account – moves are not made randomly. ## Full Functionality Requirements To meet full functionality, you must complete all minimum functionality requirements as well as the following: * The game ends when the entire board has been filled or when neither players can move. A label appears saying who won the game. * When it is a human player’s turn, the board indicates valid moves by showing playable squares in a different color. * Level 2 and 3 intelligence work correctly. * All intelligence levels use the same single recursive method to compute best moves . * Score and current player labels are displayed and updated accordingly. * The user is able to use any of the buttons in the game between moves, even when computer vs. computer is running. * Pressing *Apply Settings* after the game has started continues the existing game with updated players. * Reset button resets the game to the initial 4 piece state (and resets score and player status labels too). * Quit button that quits the game. * No other minor bugs! * Computer moves should not be highlighted. ## Bells and Whistles There is plenty of room for creativity in this assignment. **Remember:** First get your program to meet the specs; then, if time permits, go ahead and add Bells & Whistles! Here are some suggestions for Bells & Whistles: * Animated piece flipping * Keyboard shortcuts * Display the last move made by a player * Custom board weights * Non-deterministic MiniMax algorithm * Drop-down menus * Snazzy graphics * Custom player colors * Anything you can think of! --- # Implementation ## The Computer Player The following is a brief overview of how you will teach the computer player to play an intelligent game of Othello. :::info There is a more detailed, [supplementary AI handout](https://hackmd.io/@Fall2024-CS15/SJZV8SCiR) that will describe the MiniMax algorithm in greater depth. ::: * The computer generates all the moves it could possibly make given the current **board state** (locations/numbers of each player’s pieces) * For each of these possible moves, the computer player tries out that move on a “dummy” board and sees what moves the opponent would be able to make from there * This recursive process continues for a finite number of iterations determined by the intelligence level of the computer player * The computer player looks at the final board states resulting from each of its hypothetical moves and determines which final board state is most desirable. * Computer player makes the move that corresponds to that board state           ### Evaluating the Board You will need to determine which board state, resulting from one of the possible moves, is most desirable for a computer player. You can develop a mathematical function that will take in a given board state and spit out a number representing the board state's relative score and positional advantage. Such a function could be called **`evaluateBoard(...)`**. The higher the value returned by **`evaluateBoard(...)`** for a given board state, the better a computer player's chances of winning from that board state. Usually, several criteria are used to evaluate the board from both the computer player's and the opponent's point of view. Then the difference between the two values (the computer's value minus the opponent's value) for a given move is used as a measure of the computer's relative advantage or disadvantage. The actual numeric value will be based on the number of pieces each player has and where they are located on the board. For instance, a corner square has more weight than a center square. We supply you with relative weights for each space on the board (see AI handout). However, these are not necessarily the optimal values. You may determine your own weight values if you wish!           ### MiniMax The MiniMax algorithm allows us to control the "intelligence" of the computer player, simply by restricting the number of moves it tries to predict. If the computer player were to just predict all of its possible moves from the original board, and stop there, it would be a fairly stupid opponent. **If it were to incorporate predictions of subsequent opponent moves, it would be more difficult to defeat.** For each level of prediction, the computer will get more intelligent. **Side Note:** The tradeoff here is memory and computing time. Each level you go deeper requires exponentially more time and RAM (random access memory) to compute. Othello is a relatively simple game, and our machines are pretty fast, so the AI could probably look ahead further and not get too slow. But some computers running more complex AIs such as Chess might take minutes – even used to take *hours* – to come up with moves. You should be aware that in order to implement the MiniMax algorithm, you will need to write a **single recursive method.** --- # Design ## Design Questions There are many parts to this project and a **thorough, well thought out design** will save you a lot of time in the long run. This is important because with a less extensible design, it will become harder to implement different player combinations (i.e. human vs. computer or computer level ‘x’ vs. computer level ‘y’). Below are a few questions to help you start thinking about your Othello design. We recommend reading these questions, reading the [Program Design](#Program-Design) portion of this handout, looking over the [stencil code](#Installing-Stencil-Code) and then coming back to these questions and answering them yourself or in hours. * How might we use an interface to synonymize our human and computer players? What methods might this interface have? * What classes will we need for this project? What might a containment diagram with these classes look like? * How can we make use of a Referee class? How will the referee interact with the players? **Hint:** Recall the **`CS15TicTacToeController`** from TicTacToe * What methods are shared between both human and computer players? Note, we may want to delegate some shared methods to the **`Board`** or **`Referee`**. * What methods should the **`Board`** class have? Again, you are always welcome to come to conceptual hours to discuss your ideas with other students and TAs! ## Program Design ### The Board The centerpiece of Othello's design is the actual game board where the players place their pieces. To logically represent an Othello board in memory, we need to specify each spot and the piece that occupies it. However, to see an Othello board on the screen, grid lines need to appear to indicate where the board spaces are, and each piece needs to display itself as a correctly colored circle. Does a player make moves haphazardly on the game board? No! That player is not likely to do very well. Instead, each player thinks about possible moves and their consequences before actually choosing and making a final move. A person can do this in their head. A computer player, lacking a head but having far more computing power than a simple mammal, can compute the results of many possible scenarios and choose the one which is the most advantageous. **Each scenario computed by the computer player should not be seen visually. Only the final move that the computer player chooses should appear graphically on the screen.** In addition to the board that a player makes moves on, you will also need a non-visual board that is only for the computer player to try out different moves on. There are multiple design options regarding how to do this. One option is to use a **copy constructor** – more about this will come in the help session. The Othello board should logically be represented as a two-dimensional array – kind of reminiscent of Tetris, huh? As in Tetris, there should be board spaces. You can also choose to make array checking easier by "padding" spaces surrounding the board.           ### The Controls This year, we are providing you with a **`Controls.java`** file which contains code that creates the control panel you see on the right side of the application in the demo. We’ve taken care of most of the logic for you, but anything you need to do in **`Controls`** is listed in **`TODO`** comments throughout the file. **`Controls`** is associated with an empty Game class that can serve as your top-level logic class. This association is made so the **`Controls`** can tell the **`Game`** which settings it should have (Human vs Computer) and when to start, end, and reset. You will have to do three things within the **`Controls`** class: * add score/game over labels to the **`controlsPane`** * reset the **`Game`** * let the **`Game`** know which player settings it should use As **`Controls`** has access to an instance of **`Game`**, we recommend writing helper methods in **`Game`** that you can call in **`Controls`** in order to perform these functionalities. Also, don’t forget to create an instance of **`Controls`** and add its Pane (**`controlsPane`**) to your root pane in **`PaneOrganizer`**. More on interacting with the **`Controls`** class will come in the help session!           ### The Players It may seem as if the three modes of play (human vs. human, human vs. computer, and computer vs. computer) will have to be implemented separately. However, with Java, we can design a simple implementation that takes care of all three modes. How? **By using polymorphism!** Imagine a **`Player`** interface. A **`Player`** should be able to communicate with the game board and then return the player's move. Doing this would obviously involve calling some other methods – i.e. checking if there are any available moves left to make, checking if a given move is valid, checking if the player has won, etc. This `Player` would also have some properties – for example, **`color`**. Now let's define two classes that implement Player: **`HumanPlayer`** and **`ComputerPlayer`**. These two classes would both define the **`makeMove()`** method of the generic **`Player`**. For the **`HumanPlayer`**, getting the next move involves getting mouse clicks from the user until one corresponds to a valid move. For the **`ComputerPlayer`**, getting the next move involves using the AI algorithm, which will be covered in detail in the supplementary [Othello AI handout](https://hackmd.io/@Fall2024-CS15/SJZV8SCiR).           ### Game Play Having all of these lovely classes is wonderful, but how do the players play the game? An impartial **`Referee`** which tells players to go in order might be a good idea. The **`Referee`** can be thought of as an extension of the **`Game`**. The **`Referee`** tells a player to move. When that player is done moving, it notifies the **`Referee`**, and the **`Referee`** then tells the other player to move. This continues, alternating players, until the game is over. However, the **`Referee`** cannot do this in a simple loop. Why? If there is not a pause between each player’s move you won’t see the move take effect on the screen. (Think about two computer players. They are both capable of calculating and making moves so quickly that two computers could play an entire game in a fraction of a second.) To solve this problem, you need to somehow put a pause between each move. But how? Put the code that tells one player to make a move in a helper method that is called at each **`KeyFrame`** on a **`Timeline`**. Note that we don't want to tell the players to make a move at regular intervals; the time it takes for a player to make a move varies greatly throughout the game. E.g., a **`HumanPlayer`** can take up to 5 minutes to make a move while a **`ComputerPlayer`** can take 2 seconds. So the first line of your helper method should stop the **`Timeline`**. When you want to tell the next player to make a move, call **`play()`**. This will wait for a short amount of time (the **`Duration`** of your **`KeyFrame`**) before calling the player’s move method. Because the program waits before calling the next player’s move method you will have time to see the result of the last move show up on the screen. If you are confused, don't worry. This is not a typical or immediately logical use for a **`javafx.animation.Timeline`**, but it is necessary for you to see the results of a move before the next player makes their move. If you’d like help understanding this please come talk to a TA at conceptual hours!           ### Getting User Input When a human player is taking a turn, the user should be able to click on a particular space on the board and place a piece there, if the move is valid. When a computer player is taking a turn, the user should not be able to affect the board. To do this, you’ll want your pane to handle mouse clicks. You have experience with **`KeyEvents`** from DoodleJump and Tetris, **`MouseEvents`** are very similar! Make sure to take advantage of [JavaFX documentation](https://docs.oracle.com/javase/8/javafx/api/javafx/scene/input/MouseEvent.html) to fully understand how to use them. If it is a human player's turn, we would like the squares that are valid moves to turn into a different color. We would like squares to react to clicks by telling the player which square was clicked. When a computer player starts its turn, however, we would like the squares to not react at all. Does the game really need to keep track of whether the current player is a computer or a human? No! The board should have functionalities that allow it to listen and unlisten to mouse clicks. The human player should activate the board before trying to make a move. Who should be tasked with deactivating the board before the next player's turn?           ### Final Design Note The above design tips are for ***one version*** of an implementation that we found intuitive to code – there are **many** different ways to design this game. You are free to use or not use any of the above design tips as long as you take us through your decision process in your README. **Delegate** but make sure that your use of classes is not excessive. The existence of every class in your program should be justified by its contribution to the way you implement the program. Your classes should have high cohesion – a class’ name and the concept it models should go hand-in-hand. Also, remember to have an intuitive yet strict division of labor among your classes – i.e., there should not be three special cases for the three modes of play, and neither player (human or computer) should need to know whether its opponent is human or computer. In short, your program should be loosely coupled. Association is good but you should not have all or most of your classes knowing about each other. Come to Conceptual Hours to discuss design trade offs with TAs and other students! You got this! --- # Style Refer to the [CS15 Style Guide](https://docs.google.com/document/d/1olSJxbrhuIystA_kVbmKu4V8JfN7HE-eDzM5blkoeFw/edit) for the specific style guidelines along which your code will be graded for the “style” portion. **Note:** This program is probably more complex than anything you’ve written before. You will likely have many lines of code in your classes and methods. We cannot stress the importance of **documentation** *enough* - in your README, in your header comments, and inside your methods! # Handing In ## README In CS15, you’re required to hand in a README file (must be named README) that documents any notable design choices or known bugs in your program. Remember that clear, detailed, and concise READMEs make your TAs happier when it counts (right before grading your project). You are expected to create your own README file. Please refer to the [README guide](https://docs.google.com/document/d/1QJPit-_8ZC3r4l_f5F3ydMK34-NchBYgwtm0c21iwsU/edit) for information on how to create a README, what information your README should contain, and how you must format it. At the bottom of your README, add the approximate number of hours you spent on this project. This will be used only to average how long the projects are taking students this semester, and it is completely anonymous. ## Handin To hand in your assignment, follow these steps: 1. In a terminal, move into the **`othello`** folder 2. Add, commit, and push your code to GitHub 3. Type the command **`rm *.class`** (Mac) or **`del *.class`** (Windows) a. This will remove the **`.class`** files that are created when compiling so that your submission only includes **`.java`** code files. 5. Add your class and interface/inheritance diagrams to your Othello GitHub a. Be sure to upload your diagram as a **.pdf, .jpg/.jpeg, or .png** file to Gradescope. **If you submit a different file format, it may be unsupported by Gradescope so you will receive no credit for the diagram.** 7. Submit your Othello Github repository to Gradescope If you do not submit all the proper files to Gradescope, we will allow you to resubmit with a 5 point penalty, only if you’ve pushed your code to GitHub prior to the deadline. **If your code wasn’t pushed to GitHub by the deadline and you submit incorrectly to Gradescope, we will grade whatever was submitted.** You can submit as many times as you want prior to the deadline, and only your most recent handin will be graded. If you handin before the deadline and again after the deadline, the submission will be counted as late. **Do not include any identifying information on your handin, including file names (name, login, Banner ID) as we grade anonymously. Including identifying information will result in a deduction from your assignment.** Good luck on your journey toward AI mastery, and remember: *Start Early... Start Today... Start Yesterday!*         ~William Shakespeare ![260w](https://hackmd.io/_uploads/rk0ef342C.gif)