**to slow down or speed up pause the simulation then adjust speed**
+
+
+
+
+
+
Shapes
+
+
+
+
+
+
+
Width: 50
+
+
+
+
+
Height: 50
+
+
+
+
+
+
+
+
Rules:
+
If the cell is alive and has 2 or 3 neighbors, then it remains
+ alive. Else it dies.
+
If the cell is dead and has exactly 3 neighbors, then it comes to
+ life. Else if remains dead.
+
+
+
\ No newline at end of file
diff --git a/objectives/double-buffer/README.md b/objectives/double-buffer/README.md
deleted file mode 100644
index 8fb1b9072..000000000
--- a/objectives/double-buffer/README.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# Cellular Automata and The Game of Life
-
-
-## Double Buffering
-
-There's a technique that's commonly used in graphics programming called
-*double buffering*. This is when we display one buffer to the user, but
-do work on one that's hidden from sight. In this way, the user doesn't
-see the buffer being generated, they only see the one that was
-previously completed.
-
-When we're done doing work on the hidden buffer, we *page flip* and show
-the hidden buffer to the user. Then the previously-displayed buffer
-becomes the new hidden buffer, and work begins again.
-
-There are multiple benefits to this approach.
-
-One is that the user doesn't see the work being progressively completed. From
-their perspective, the work is suddenly done as soon as the page flips.
-
-Another is that the program can use the previous buffer (i.e. the one that is
-currently being displayed) as a source for material to perform calculations to
-produce the next buffer. This is particularly beneficial where you need to
-produce a completely new output based on the complete previous output. If you
-were to only use a single buffer, you'd have to overwrite the pixels as you
-went, and this might affect the outcome of the subsequent pixels in an
-undesirable way.
-
-And this is very useful when implementing a cellular automaton.
-
-There will be two arrays of data for the automaton. One of them holds the data
-that the user currently sees on the canvas. The other one is where the _next_
-frame to be shown is being actively constructed.
-
-After the new frame is constructed, the next from becomes the current frame, and
-the current frame becomes the next frame. And the process repeats.
-
-Also note that this approach is vaguely reminiscent of the Model and View in the
-MVC pattern where the Model is manipulated then displayed by the View.
diff --git a/objectives/double-buffer/img/life.png b/objectives/double-buffer/img/life.png
deleted file mode 100644
index 617755676..000000000
Binary files a/objectives/double-buffer/img/life.png and /dev/null differ
diff --git a/objectives/explain-describe-ca/README.md b/objectives/explain-describe-ca/README.md
deleted file mode 100644
index 0e25438e2..000000000
--- a/objectives/explain-describe-ca/README.md
+++ /dev/null
@@ -1,29 +0,0 @@
-# Cellular Automata and The Game of Life
-
-
-## Cellular Automata
-
-A _cellular automaton_ (plural: cellular automata, abbreviated _CA_) is a
-program that operates on data typically stored in a 2D grid. (1D, 3D and _n_-D
-cellular automata run on lines, cubes, etc.)
-
-A simple set of rules describes how the value in a cell on the grid changes over
-time, often as the result of the states of that cell's neighbors.
-
-> Sometimes neighbors includes the 4 orthogonally adjacent cells; sometimes it
-> includes all 8 surrounding cells including diagonals.
-
-Each round of the simulation examines the current state of the grid, and then
-produces an entirely new grid consisting of the old state. (Remember the
-discussion about double buffers earlier--we don't want to modify the same grid
-we're examining, lest we munge future results.)
-
-This new grid becomes the "current" state of the simulation, and the process
-repeats. Each new grid is referred to as a _generation_.
-
-The beautiful thing about cellular automata is that sometimes very complex
-behavior can emerge from very simple rules.
-
-Practically speaking, CAs have been used in biological and chemical simulations
-and other areas of research, such as CA-based computer processors, and other
-numeric techniques.
diff --git a/objectives/explain-describe-ca/img/life.png b/objectives/explain-describe-ca/img/life.png
deleted file mode 100644
index 617755676..000000000
Binary files a/objectives/explain-describe-ca/img/life.png and /dev/null differ
diff --git a/objectives/rules-game-life/README.md b/objectives/rules-game-life/README.md
deleted file mode 100644
index a90debd4d..000000000
--- a/objectives/rules-game-life/README.md
+++ /dev/null
@@ -1,50 +0,0 @@
-# Cellular Automata and The Game of Life
-
-
-## The Game of Life
-
-A very famous cellular automaton is John Conway's [Game of
-Life](https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life).
-app. This game is a class of discrete model known as a *[Cellular
-Automaton](https://en.wikipedia.org/wiki/Cellular_automaton)*, abbreviated *CA*.
-
-It's made up of a grid of cells (usually 2D, but can be any dimension)
-that follow a simple set of rules from which complex behaviors can
-emerge.
-
-
-
-In the Game of Life, these rules examine each cell of the grid. For each
-cell, it counts that cell's eight neighbors (up, down, left, right, and
-diagonals), and then act on that result.
-
-* If the cell is alive **and** has 2 or 3 neighbors, then it remains
- alive. Else it dies.
-* If the cell is dead **and** has exactly 3 neighbors, then it comes to
- life. Else if remains dead.
-
-From those two rules, many types of "creatures" can be created that
-[move around the
-"landscape"](https://www.youtube.com/watch?v=28vxPvTDh4E).
-
-Note: cells that are off the edge of the grid are typically assumed to
-be dead. (In other cases, people sometimes code it up to wrap around to
-the far side.)
-
-
-### Explore The Game of Life
-
-* [Edwin Martin's Implementation](https://bitstorm.org/gameoflife/): run the
- simulation to see what the Game looks like.
-* [Patterns that can be used for testing](https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life#Examples_of_patterns)
-* [Glider pattern](https://en.wikipedia.org/wiki/Glider_(Conway%27s_Life)) to
- the grid at a random location.
-* [Gosper Glider Gun pattern](https://en.wikipedia.org/wiki/Gun_(cellular_automaton)) to the
- grid at a random location.
-
-
-### References
-
-* [John Conway's Game of
-Life](https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life)
-* [`requestAnimationFrame()`](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame)
diff --git a/objectives/rules-game-life/img/life.png b/objectives/rules-game-life/img/life.png
deleted file mode 100644
index 617755676..000000000
Binary files a/objectives/rules-game-life/img/life.png and /dev/null differ
diff --git a/objectives/turing-complete/README.md b/objectives/turing-complete/README.md
deleted file mode 100644
index acb73f34d..000000000
--- a/objectives/turing-complete/README.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# Cellular Automata and The Game of Life
-
-
-## Turing Completeness
-
-We say a computing system is [_Turing
-Complete_](https://en.wikipedia.org/wiki/Turing_completeness) if it is capable
-of performing arbitrary, general purpose computation.
-
-Using a construct in The Game of Life called a [glider
-gun](https://en.wikipedia.org/wiki/Gun_(cellular_automaton)), it's possible to
-build a rudimentary [NAND gate](https://en.wikipedia.org/wiki/NAND_gate) in the
-Game of Life. While a NAND gate by itself isn't enough to be Turing Complete,
-the "infinite" grid of The Game of Life allows you to use them (or any other
-[functionally complete](https://en.wikipedia.org/wiki/Functional_completeness)
-operator) to build any other type of logical "circuitry" and
-[memory](https://en.wikipedia.org/wiki/Flip-flop_(electronics)), as well.
-
-Anything computable can be computed in The Game of Life given a large enough
-grid and enough time. Most people, however, find JavaScript to be a far easier
-development medium.
diff --git a/objectives/turing-complete/img/life.png b/objectives/turing-complete/img/life.png
deleted file mode 100644
index 617755676..000000000
Binary files a/objectives/turing-complete/img/life.png and /dev/null differ
diff --git a/resources/README.md b/resources/README.md
deleted file mode 100644
index 1edfdaa94..000000000
--- a/resources/README.md
+++ /dev/null
@@ -1,5 +0,0 @@
-# Additional Resources
-
-* [Web](web/)
-* [iOS](ios/)
-* [Python](python/)--not recommended
diff --git a/resources/ios/README.md b/resources/ios/README.md
deleted file mode 100644
index e6b752bbd..000000000
--- a/resources/ios/README.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# iOS Hints and Resources
-
-Please refer to [this Training Kit module](https://learn.lambdaschool.com/ios2/module/recEEqjQwd10wS6Wl/) for references to custom drawing.
-
-To create your grid for drawing, use a UIView subclass and the `draw` method.
-
-Hint: Open the Color Picker Xcode guided project for this module to get hints about how to create a grid of squares (these will be white or black). Ask an iOS instructor for the completed guided project if you don't have it.
-
-The app needs to be comprised of 2 screens:
-
-* A main screen with the custom view for the simulation, buttons to play/pause the simulation, run the simulation 1 generation at a time, and a stop button that resets the simulation to a new random field of alive/dead squares.
- * The preset buttons are part of a stretch goal and may be omitted.
-
-* An about screen, triggered however you wish, that lists the rules of the game, and a textview containing information about what learned from researching and implementing the game.
-
-
-
\ No newline at end of file
diff --git a/resources/ios/game-of-life-iOS-mock-1.png b/resources/ios/game-of-life-iOS-mock-1.png
deleted file mode 100644
index 80b72d14d..000000000
Binary files a/resources/ios/game-of-life-iOS-mock-1.png and /dev/null differ
diff --git a/resources/ios/game-of-life-iOS-mock-2.png b/resources/ios/game-of-life-iOS-mock-2.png
deleted file mode 100644
index 400288c65..000000000
Binary files a/resources/ios/game-of-life-iOS-mock-2.png and /dev/null differ
diff --git a/resources/python/README.md b/resources/python/README.md
deleted file mode 100644
index 68665256c..000000000
--- a/resources/python/README.md
+++ /dev/null
@@ -1,19 +0,0 @@
-# Python Hints
-
-We highly recommend you do this in your core track language and framework.
-
-* It will help shake the rust off.
-* You'll likely have better-looking and speedier results.
-* It will be far easier to demo as part of a portfolio.
-* It will take you less time to shake the rust off than it will for you to
- learn a Python graphics framework.
-
-But if you insist, you might check out:
-
-* [tkinter](https://docs.python.org/3/library/tkinter.html)
-* [Pillow](https://github.com/python-pillow/Pillow)
-* [PySDL2](https://pypi.org/project/PySDL2/)
-* [PyGame](https://www.pygame.org/)
-
-Out of all those, tkinter with Pillow will be the easiest to do a GUI in, but
-it's going to not look so hot.
diff --git a/resources/web/README.md b/resources/web/README.md
deleted file mode 100644
index aeaef7c57..000000000
--- a/resources/web/README.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# Resources for Web
-
-These are some resources that _might_ be useful. There's no requirement
-that you use HTML canvas for this project. You could use DOM elements,
-or a game engine, or whatever you choose.
-
-Instead of doing the pixel manipulation, below, you could use drawing
-primitives to draw rectanges on the canvas, for example.
-
-Be creative. Anything is allowed, as long as it meets MVP. If in doubt,
-ask!
-
-* [Manipulating pixels on a canvas](canvas-buffer/)
-* [Animating a canvas with React](canvas/)
-* [Deploying to GitHub Pages](deployment/)
\ No newline at end of file
diff --git a/resources/web/canvas-buffer/Readme.md b/resources/web/canvas-buffer/Readme.md
deleted file mode 100644
index ff41a085a..000000000
--- a/resources/web/canvas-buffer/Readme.md
+++ /dev/null
@@ -1,156 +0,0 @@
-# Screen Buffers, Canvas, and RGB
-
-
-## The Screen Buffer
-
-The *Screen Buffer* is a fancy way of saying "big array that holds pixel
-information". Screen buffers hold their data in a variety of different
-formats, but JavaScript's `