CompSci 308
Spring 2024
Advanced Software Design and Implementation

Cell Society: Detailed Change Specifications

Change Functional Requirements

The additional requirements below are intended to emphasize the Cell Society Design Specification by challenging assumptions you may have made in your Basic version.

A program with fewer features, refactored to clearly demonstrate your design supports extension through abstractions, is worth more than a program with more, poorly designed features that expose implementation details, add special case conditionals, hardcode values, or otherwise diminish the rest of your design efforts.

Simulations

Implement at least 2 of the following CA Simulation variations.

ID Name Priority Description

CELL-26A

Simulation: Falling Sand/Water

Variation[2]

A simulation that mimics granular materials like sand or water. Particles fall, interact, and form structures under simulated gravity.
See this assignment for states and state-transition rules (and in video).
You must write at least 2 different configuration files that run successfully to test this simulation.

CELL-26B

Simulation: Foraging Ants

Variation[2]

This simulation models the behavior of ants foraging for food. It involves ants leaving pheromones, finding food, and returning to the nest.
See this paper (rules start at the bottom of page 2) for states and state-transition rules (and in video).
You must write at least 2 different configuration files that run successfully to test this simulation.

CELL-26C

Simulation: Langton’s Loop

Variation[2]

A self-replicating automaton, Langton’s Loop demonstrates patterns that can create copies of themselves.
See this table (try a pre-1994 model and a post-1994 model) or Wikipedia for states and state-transition rules (and in video).
You must write at least 3 different configuration files that run successfully to test this simulation.

CELL-26D

Simulation: SugarScape

Variation[2]

SugarScape involves agents interacting in a virtual landscape, competing for resources like sugar.
See this paper (try at least two of the models described as "Presets") for states and state-transition rules (and in video).
You must write at least 3 different configuration files that run successfully to test this simulation.

NOTE: several of these simulations require that the grid location itself contain a “patch of ground” that can also have state and rules in addition to a cell.

XML Configuration Error Handling

Implement error checking for incorrect file data. This table describes the minimal error handling you must implement (remember DESIGN-13, your program should not crash for any input given):

ID Name Priority Description

CELL-27

Input Missing Parameters

Core

When the user loads a configuration file that has a missing simulation type, name, author, or description, the program should display an error message to the user indicating why the configuration is not valid.
For simulation specific configuration values (i.e., probCatch for catching fire), the simulator should provide a reasonable default value rather than throwing an exception. For grid size, it may be possible to calculate from the initial states, if they are provided.
It must throw an Exception to be caught in the appropriate View method(s).
Include at least 1 simulation configuration file that demonstrate this error.

CELL-28

Invalid Value Check

Core

When the user loads a configuration file that has an invalid value (like a non-existent simulation, edge type, or negative value), the program should display an error message to the user indicating why the configuration is not valid.
It must throw an Exception to be caught in the appropriate View method(s).
Include at least 1 simulation configuration file that demonstrate this error.

CELL-29

Invalid Cell State Check

Core

When the user loads a configuration file that has invalid cell state values, the program should display an error message to the user indicating why the configuration is not valid.
It must throw an Exception to be caught in the appropriate View method(s).
Include at least 1 simulation configuration file that demonstrate this error.

CELL-30

Grid Bounds Check

Core

When the user loads a configuration file that has cell locations specified outside the grid’s bounds, the program should display an error message to the user indicating why the configuration is not valid.
It must throw an Exception to be caught in the appropriate View method(s).
Include at least 1 simulation configuration file that demonstrate this error.

CELL-31

File Format Validation

Core

When the user loads a configuration file that has empty, badly formatted, or non-XML file, the program should display an error message to the user indicating why the configuration is not correctly formatted.
It must throw an Exception to be caught in the appropriate View method(s).
Include at least 1 simulation configuration file that demonstrate this error.

NOTE: provide at least 1 example configuration file for each additional error specifically checked for beyond these and document each in the project README file.

This article provides guidance about “negative” testing, i.e., how to think about what kinds of input errors might occur when coming up with tests.

XML Configuration Initialization

In addition to providing all the initial cell state values, allow the starting configuration of the cell states to be set algorithmically:

ID Name Priority Description

CELL-32A

Random Configuration by Total States

Variation[1]

Implement a new XML element in the configuration file to allow random assignment of cells to a specified number of states. When these values are set, the program should randomly assign cell states so that the number of cells of each state match the provided values (if empty or dead cells are not included, they will fill out the remaining cells). For instance, a 4x4 Game of Life set to 6 alive cells would have 6 alive cells and 10 dead cells.
Exact initial states should not be given in the XML in this case.
Include at least 2 simulation configuration files to demonstrate this option.

CELL-32B

Random Configuration by Probability Distribution

Variation[1]

Implement a new XML element in the configuration file to allow random assignment of cells to a specified proportion of states. When these values are set, the program should randomly assign cell states so that the ratios between the states matches the provided values (if empty or dead cells are not included, they will fill out the remaining cells). For example, a 3x3 Game of Life with 66% alive cells would have 6 alive cells and 3 dead cells.
Exact initial states should not be given in the XML in this case.
Include at least 2 simulation configuration files to demonstrate this option.

NOTE: document the expected XML tag and/or attribute name(s) and formats in your README file.

Grid Topology

The changes below do not need to affect how a Simulation's rules are applied (i.e., the number of neighbors needed to activate a state change can remain the same); however, if you are curious, here are several rule variations for different neighborhoods and a discussion of how these variations might affect the simulation for the well studied Game of Life.

NOTE: any simulation should work with any kind of edge, neighborhood, or shape options.

Grid Edges

Allow different kind of grid edge types, instead of assuming it will always be bounded to the initial size (including even infinite size that expands to include new cells as needed).

ID Name Priority Description

CELL-33A

Grid Edge Type: Toroidal

Variation[1]

Support wrapping (toroidal) edges, in which the edges wrap around both horizontally and vertically, creating a continuous surface with no fixed boundaries.
This should be an option provided in the XML configuration file.
Include at least 1 configuration file that utilizes this option.

CELL-33B

Grid Edge Type: Mirror

Variation[1]

Support mirrored edges, in which the edges act as mirrors, reflecting the state of the cell adjacent to the edge.
This should be an option provided in the XML configuration file.
Include at least 1 configuration file that utilizes this option.

CELL-33X

Grid Edge Type: Custom

Variation[1]

Design and implement an Edge Type of your choice that is different than or a generalization of the others.
This should be an option provided in the XML configuration file.
Include at least 1 configuration file that utilizes this option.
Cell Neighbors

Allow different arrangements of neighbors instead of assuming it will always be the complete "Moore" neighborhood (including even multiple neighborhoods at once).

ID Name Priority Description

CELL-34A

Neighbor Arrangement: Von Neumann

Variation[1]

Support the “Von Neumann” neighborhood arrangement, in which a cell’s neighbors are only those that are directly adjacent to it vertically and horizontally (up, down, left, right), excluding diagonal neighbors.
This should be an option provided in the XML configuration file.
Include at least 1 configuration file that utilizes this option.

CELL-34B

Neighbor Arrangement: Extended Moore Neighborhood

Variation[1]

Extend the Moore Neighborhood to 2 cells away, in which a cell’s neighbors are all the adjacent cells and all the cells adjacent to those cells.
This should be an option provided in the XML configuration file.
Include at least 1 configuration file that utilizes this option.

CELL-34X

Neighbor Arrangement: Custom

Variation[1]

Design and implement a Neighbor Arrangement of your choice that is different than or a generalization of the others.
This should be an option in the XML configuration file.
Include at least 1 configuration file that utilizes this option.
Cell Shape

Allow any different kind of grid cell shapes, instead of assuming it will always be rectangular (including even planar tilings such as pentagonal and general tilings). This change should not affect the model's data structure, just how neighborhoods are determined and how the grid is displayed in the View.

ID Name Priority Description

CELL-35A

Cell Shape: Hexagonal

Variation[1]

Support hexagonal cells, which follow hexagonal tiling such that there are 2 Von Neumann neighbors or 6 Moore neighbors.
This should be an option provided in the XML configuration file.
Include at least 1 configuration file that utilizes this option.

CELL-35B

Cell Shape: Triangular

Variation[1]

Support triangular cells, which are tiled so that they alternate facing, such that there are 4 Von Neumann neighbors or 12 Moore neighbors.
This should be an option provided in the XML configuration file.
Include at least 1 configuration file that utilizes this option.

CELL-35X

Cell Shape: Custom

Variation[1]

Design and implement a Cell Shape of your choice that is different than or a generalization of the others.
This should be an option provided in the XML configuration file.
Include at least 1 configuration file that utilizes this option.

Graphical User Interface

Allow users to customize how they display simulations.

ID Name Priority Description

CELL-36

Multiple Simultaneous Simulations

Core

Allow users to run multiple simulations concurrently.
Document UI decisions such as window arrangement and the independence of each simulation in the README

CELL-37

Simulation Language Customization

Core

Allow customization of the language used for the UI text (e.g., English, Spanish, Emoji).
This should be an option provided in the XML configuration file.
Include at least 2 languages in addition to English.

CELL-38

Cell State Colors Customization

Core

Allow customization of the colors of cell states (e.g., empty cells as blue to represent a water world or black to represent a space world).
These should be an option provided in the XML configuration file.

CELL-39

Cell Shape Customization

Extension

Allow customization of the shape and appearance of cells based on their state (e.g., circles, rectangles, or images like sharks or fire).
These do not affect the structure of the grid, only the graphical presentation.
These should be an option provided in the XML configuration file.
Different Views

Allow users to see any combination of different views of a simulation model at the same time, such that if one view is opened after another was started, it should start at the shared model's current time.

ID Name Priority Description

CELL-40A

View: Histogram of Cell States

Variation[1]

When the user opens the histogram view, the simulation displays a histogram graph showing the populations of all cell states over time, independent of their locations on the grid.
This view should have the same underlying model state as other views, such that each is in sync at every step of the simulation, and able to function independently or alongside other views (including being opened or closed dynamically while other views are active).
For example, see the WaTor assignment.

CELL-40B

View: Graph of Cell Population Changes

Variation[1]

When the user opens the graph view, the simulation displays a graph of changes in cell population totals since the last step.
This view should have the same underlying model state as other views, such that each is in sync at every step of the simulation, and able to function independently or alongside other views (including being opened or closed dynamically while other views are active).
For example, see this SugarScape discussion.
Dynamic Updates

Allow users to interactively change simulation values while it is running such that each change takes immediate effect:

ID Name Priority Description

CELL-41A

Dynamic Updates: Simulation Parameters

Variation[3]

Provide a mechanism for a user to change the configuration parameters of a currently loaded simulation (i.e., sliders or text fields organized in a separate panel). Simulation parameters include things like probCatch from Spreading Fire. When a user changes a value, the simulation should immediately apply this change in computing the next generation.
This requires a number of GUI components constructed based on the parameters required by the current simulation.

CELL-41B

Dynamic Updates: Grid States

Variation[3]

Provide a mechanism for a user to manually alter a cell state of a currently loaded simulation (i.e., by clicking on the cell). When a user changes the state of a specific cell in the grid, the simulation should update in real-time to reflect this new state.

CELL-41C

Dynamic Updates: Grid Outline

Variation[3]

Provide a mechanism for the user to toggle on/off cell outlines in the grid of a currently loaded simulation (i.e., a button or checkbox). When a user chooses to toggle the grid outline, the simulation should immediately apply this change, either displaying or hiding the grid lines.

CELL-41D

Dynamic Updates: Edge Policy

Variation[3]

Provide a mechanism for a user to change the edge policy of a currently loaded simulation (i.e., a dropdown selection or radio buttons). When a user selects a different edge policy (e.g., wrapped edges, fixed boundaries), the simulation should dynamically adjust to the new policy, affecting how cells interact at the grid’s edges.
This depends on CELL-33 and should support each Edge Type your simulation supports.

CELL-41E

Dynamic Updates: Cell Shape

Variation[3]

Provide a mechanism for the user to change the cell shape of a currently loaded simulation (i.e., a dropdown selection or radio buttons). When a user chooses to change the shape of the cells (e.g., from rectangular to hexagonal), the simulation should update the grid to match the layout, but the number of cells should remain unchanged and each cell should retain its previous state.
This should just require changing the Nodes used in the Scenegraph, allowing OpenJFX to display the effect when it draws them.
This depends on CELL-35 and should be implemented for each Cell Shape you simulator supports.