improves the getting started instructions and integrations

Author: fredx30

.idea/runConfigurations/GameOfLife__build_.xml

@@ -2,17 +2,56 @@
 
 Inspired by a challenge issued earlier in the week.
 
+## Getting started
+
+To get started clone this repo. The project is made to integrate with [IntelliJ idea](https://www.jetbrains.com/idea/).
+There are several gradle integrated run configurations that will aid in a quick start (see `GameOfLife [run]`).
+Running `gradlew.bat run`(windows) or `gradlew run`(linux)
+will start the application via cli.
+
+### Run Configurations
+
+For now these are all set via inline code.
+
+Further development is set up to enable features such as
+
+- Setting the location of the viewport.
+- Setting the scale of the viewport.
+- Progression speed of the simulation age / tick-speed
+- Pausing the simulation
+- Loading start configurations (active/inactive status on the grid) from files
+
 ## Implementation
 
-After an initial lookover the linked wikipage [Conways Game of Life](http://en.wikipedia.org/wiki/Conway's_Game_of_Life). An implementation
-seems to require logic to keep track of the entities, and a canvas to render a limited space out of the total of the
-abstract 2d plane on which the game logic occurs across.
+After an initial look over the linked
+wikipage [Conways Game of Life.](http://en.wikipedia.org/wiki/Conway's_Game_of_Life)
+An implementation seems to require logic to keep track of the entities, and a canvas to render a limited space out of
+the total of the abstract 2d plane on which the game logic occurs across.
+
+### Limitations on current implementation
+
+The current implementation uses a `boolean[][]` type 2d array to store the abstract 2d plane.
+
+The good: Primitive types when in arrays allow for very fast memory access. There is a great talk
+here [Youtube - Scott Meyers Nokia talk](https://www.youtube.com/watch?v=WDIkqP4JbkE) that describes why a large data
+set capable of being described by a and array of primitives should never be represented as an array of complex typed
+objects. This could however likely be rewritten in some combination of logic to handle chunks
+and arrays of 64bit integers for the best result.
+
+The bad: This does however add a limitation where the size of the simulation space is neither infinite nor flexible.
+Adding simulation space into rows lower than 0 or columns lower than requires a full copy of the array into a larger
+array this is unideal.
 
 ### Ideas for further development
 
-Move the implementation of the abstract grid containing an array of entities in series of classes into an spring powered mvc app.
+Move the implementation of the abstract grid containing an array of entities (see the class `EntityGrid`) into a spring
+powered mvc app. This would allow multiple observers to simultaneously observe.
+
+Change the method of simulation progression such that it relies on a queue of changes. This could also allow different
+singular clients to stream/download and load the simulation asynchronously.
 
-Extend the implementation of the rendering engine in java fx, to also cover a web app- perhaps angular with a 2d rendering library.
+~~Extend the implementation of the rendering engine in java fx, to also cover a web app- perhaps angular with a 2d
+rendering library.~~
 
 ## Dependencies
 

.idea/runConfigurations/GameOfLife__clean_.xml

@@ -22,22 +22,12 @@ javafx {
     modules = [ 'javafx.controls', 'javafx.fxml' ]
 }
 
-sourceSets {
-    main {
-        resources {
-            srcDirs = ["src/main/java"]
-            includes = ["**/*.fxml"]
-        }
-    }
-}
-
 dependencies {
     // Use JUnit test framework.
     testImplementation 'junit:junit:4.13'
 
     // This dependency is used by the application.
     implementation 'com.google.guava:guava:29.0-jre'
-
 }
 
 application {