The most significant design decisions made in this assignment revolve around three main areas: internal structure of the game board, functions on the internal and external representations of the game, and design of presets.
We decided to structure our internal game board using a 2D Array. This solution allowed us to readily mutate our board when cells needed to be changed, and also allowed us to index into the internal board with the implicit assumption that what the user is seeing is the same as what our internal board is seeing. One key tradeoff that this design required was figuring out how to successfully update the board. We couldn't assume one board would work the whole time, because we needed to account for previous as well as future time steps. To overcome this issue, we created a new 2D array when updating the board, and reassigned the board variable accordingly when we would update the game at each step. While this may have been a poor decision from a performance perspective, it kept our code understandable and safe from confusing alias logic of handling placeholder/temp boards in the global scope. All in all, this design choice took a slight hit in terms of performance for the sake of cleaner code and sounder localization.
The primary functions we utilized were created in the init stage, thanks to the provided functions which were later used as closures. Every funciton we created involved completely iterating over the board, whether to reset, design a preset, or simulate the next step. We also used a localized neighbor counting function to count the number of neighbors for a given cell, which fit nicely into our functionals we used for step().
Preset design was certainly an area of friction for managing repitition. At first, we were defining each preset by a unique function that would build the preset, and that function was called to set the board to the correct preset. While this was useful from a partitioned code/testing perspective, we were taking a hit in terms of repeating what could have been highly generalizable code. To combat this, we represented every preset as a simple set of points inside an anonymous function, and when the preset is to be built, the points can be directly added to the board through the general function attached to all presets.
Functionals were critical in almost every feature we implemented. While a few (init, getNumAliveNeighbors) didn't leverage functionals, other functions were able to leverage the existing board object to make easy iterations over the entire game board. What was especially powerful about the functionals we used was our choice to further nest functions withing the functionals. This made the step() feature especially simple and modular, because the logic for computing neighbors and making the decision on a given cell could all be packaged neatly into the functional that was used to iterate across the whole game board.
One of the main alternatives we made a decision on was the representation of the board during the step method. While we settled with creating a new board every time, one plan we had was to create two boards from the start, and switch ownership/representation of one as the "board" and one as the "previous board" this would have saved significantly on performance by saving us the trouble of having to build a new array every time, but repeatedly drawing over the same boards over and over again could lead to some entanglements with aliasing that could've caused some extremely confusing bugs, especially with what errors we'd be expecting to get back from javascript. For the sake of simplicity and clear code, we took the hit on performance and created a new template board to write on at every step.
One of the main limitations of this implementation is that it only handles boards of a finite size, and kills any cells that would be placed outside of the bounds of the board. It would be pretty interesting to see about implementing it such that the game is unbounded, which could potentially be achieved by using a set structure to keep track of all living cells. Another limitation is that the current implementation only supports one rule set. This is fine for this particular assignment, but might need to be generalized if there were any modifications that we wanted to make to the rules of the game. This could probably be easily fixed with callbacks passed into the step function.
One ethical implication of this project is the way that it broadcasts ideas about how populations manage themselves. Conway's game of life introduces a very simplistic and determinsitic set of rules, and attempts to use these to make a model for population fluctuations. The only challenge to this is that these mechanics are not even close to this simple, and even have some randomization. This means that Conway's model is really not a viable model, but we are perpetuating it by recreating the game.