CompSci 308 : Spring 2025

Cell Society: Functional Change Specifications

The additional requirements below are intended to emphasize the Cell Society Design Specification by challenging assumptions you may have made so far. Note the new Design Requirements as well.

Below is a table of the project’s expected functionality, following the format in the Functional Requirements Glossary (which describes the difference between Core, Variation, and Extension requirements). You are expected to implement all Core requirements, but only enough Variation and Extension requirements of your choice to validate you are making good choices to meet the current and new Design Specifications.

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

Simulation

ID	Name	Priority	Description
`CELL-46`	Darwin	Core	A simulation that models a world populated by a different species of creatures, determined by the program it executes on each step, to observe how they interact together (and perhaps what causes a species to dominate). See this description of the program language syntax. You must write at least *2 new species programs* and *5 configuration files* that run successfully to test this simulation.

Configuration

ID	Name	Priority	Description
`CELL-47`	Simulation Styles	Core	Allow at least three different ways for simulations to be "styled": name of colors or image files for cell states (as many as needed to cover any simulation implemented) grid properties (edge policy, cell shape, or neighbor arrangement) another one of your choice (such as whether or not grid locations should be outlined (i.e., to "see" the grid or not), language used, color style mode, etc.) NOTE: these values can be added to the existing configuration file but are more appropriate in a separate "style" file since they can be applied to many simulations

NOTE: You will also need to update your error checking and support the new options provided with the new features below.

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.

ID	Name	Priority	Description
`CELL-48A`	Grid Edge Type: Toroidal	Variation[2]	Support wrapping (toroidal) edges, in which the edges wrap around both horizontally and vertically, creating a continuous surface with no fixed boundaries. Include at least 1 configuration file that utilizes this option.
`CELL-48B`	Grid Edge Type: Mirror	Variation[2]	Support mirrored edges, in which the edges act as mirrors, reflecting as many of the cells adjacent to the edge as needed to make a full neighborhood. Include at least 1 configuration file that utilizes this option.
`CELL-48C`	Grid Edge Type: Infinite	Variation[2]	Support infinite edges that expand to include new cells as needed. Include at least 1 configuration file that utilizes this option.
`CELL-48X`	Grid Edge Type: Custom	Variation[2]	Design and implement an Edge Type of your choice that is different than or a generalization of the others. Include at least 1 configuration file that utilizes this option.

NOTE: The Edges supported by your program should be given as an option in your configuration files.

Cell Neighborhoods

Allow different arrangements of neighbors instead of assuming it will always be the complete "Moore" neighborhood.

ID	Name	Priority	Description
`CELL-49A`	Neighbor Arrangement: Von Neumann	Variation[2]	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. Include at least 1 configuration file that utilizes this option.
`CELL-49B`	Neighbor Arrangement: Extended Moore Neighborhood	Variation[2]	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. Include at least 1 configuration file that utilizes this option.
`CELL-49C`	Neighbor Arrangement: Multiple Neighborhoods	Variation[2]	Support multiple neighborhoods at once such that the neighborhood may not even be directly adjacent to the cell. Include at least 1 configuration file that utilizes this option.
`CELL-49X`	Neighbor Arrangement: Custom	Variation[2]	Design and implement a Neighborhood arrangement of your choice that is different than or a generalization of the others. Include at least 1 configuration file that utilizes this option.

NOTE: The Neighborhoods supported by your program should be given as an option in your configuration files.

Cell Shape

Allow any different kind of grid cell shapes, instead of assuming it will always be rectangular. 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-50A`	Cell Shape: Hexagonal	Variation[2]	Support hexagonal cells, which follow hexagonal tiling such that there are 2 Von Neumann neighbors or 6 Moore neighbors. Include at least 1 configuration file that utilizes this option.
`CELL-50B`	Cell Shape: Triangular	Variation[2]	Support triangular cells, which are tiled so that they alternate facing, such that there are 4 Von Neumann neighbors or 12 Moore neighbors. Include at least 1 configuration file that utilizes this option.
`CELL-50C`	Cell Shape: Tiling	Variation[2]	Support planar tilings such as pentagonal and general tilings, whose neighbors include any cell that intersects with the cell's border (even by just a point). Include at least 1 configuration file that utilizes this option.
`CELL-50X`	Cell Shape: Custom	Variation[2]	Design and implement a Cell Shape of your choice that is different than or a generalization of the others. Include at least 1 configuration file that utilizes this option.

NOTE: The Shapes supported by your program should be given as an option in your configuration files.

Graphical User Interface

Dynamic Updates

Allow users to interactively change simulation values, even while it is running, such that each change takes immediate effect on how the simulation rules are applied:

ID	Name	Priority	Description
`CELL-51A`	Dynamic Updates: Grid Edges	Variation[3]	Allow users to change the grid's edge policy of a currently loaded simulation (i.e., a drop-down selection or radio buttons). This depends on `CELL-48` and should support each Edge your program supports.
`CELL-51B`	Dynamic Updates: Cell Neighborhoods	Variation[3]	Allow users to change the cell's neighborhood policy of a currently loaded simulation (i.e., a drop-down selection or radio buttons). This depends on `CELL-49` and should support each Neighborhood your program supports.
`CELL-51C`	Dynamic Updates: Cell Shape	Variation[3]	Allow users to change the cell's shape of a currently loaded simulation (i.e., a drop-down selection or radio buttons). This depends on `CELL-50` and should be implemented for each Shape you program supports. NOTE: This should just require changing the Nodes used in the Scenegraph, allowing OpenJFX to display the effect when it draws them. Thus when the shape changes from rectangular to hexagonal, the grid's view should change to match the layout, but the total number of cells and rows should remain unchanged and each cell should retain its state.
`CELL-51D`	Dynamic Updates: Undo	Variation[3]	Allow users to undo/redo the last action(s) done (e.g., a dynamic change, setting a parameter value, updating a description, going back or forward a step in the simulation, etc.)
`CELL-51X`	Dynamic Updates: Custom	Variation[3]	Allow users to dynamically change something of your choice that is different than or a generalization of the others.

Different Views

Allow users to see any combination of different views of a simulation model at the same time (including being opened or closed dynamically while other views are active), 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-52`	View: Number of Iterations	Core	Display a just a number that is a count of the number of iterations that have been run so far. For example, it should increase by one each time the simulation steps forward and stay the same when the simulation is paused.
`CELL-53A`	View: Cell Information	Variation[3]	Display information about an individual cell when the user hovers over or clicks on it (such as its state name, how long it has been in that state, its patch data, etc.).
`CELL-53B`	View: Histogram of Cell States	Variation[3]	Display a histogram graph showing the populations of all cell states over time, independent of their locations on the grid. For example, see the WaTor assignment.
`CELL-53C`	View: Graph of Cell Population Changes	Variation[3]	Display a graph of changes in cell population totals since the last step. For example, see this SugarScape discussion.
`CELL-53D`	View: Mini-Grid	Variation[3]	Display the grid at a small scale so the user can always see the entire grid. If the Zoom View is implemented, its bounds should be displayed as a light outline within this view so the user knows what part of the simulation they are zoomed into.
`CELL-53E`	View: Zoom	Variation[3]	Allow the user to zoom in or out within the display (this should not change the dimensions of the world, just the user's view of it)
`CELL-53X`	View: Custom	Variation[3]	Design and implement a View of your choice that is different than or a generalization of the others.

NOTE: ideally, all of these Views should update automatically when simulation values are changed dynamically by users, but it is okay if the simulation needs to be paused and restarted to see the change.

Design Requirements

These design requirements are an extension of those given previously for you to practice before they are used in the Final Project. Below is a table of the project's expected design goals, following the format in the Design Requirements Glossary.

ID	Name	Adherence	Description
`DESIGN-18`	APIs	Forthcoming	Provide well-defined Application Programming Interfaces (APIs) for logical parts of your project. The View should only interact with APIs. Each public API class and method should have complete Javadoc comments, especially interfaces and abstract classes to show their intended use. Each API package must include a file called `package-info.java` that includes comments to describe the API's Design Goals and Contracts.
`DESIGN-19`	Apply Design Patterns	Forthcoming	Define and describe your system design using Design Patterns. Your classes should follow the naming conventions of the design pattern you are applying (i.e., a factory class from the Factory pattern should be named with the suffix `Factory`). Document your Design Patterns where appropriate, such as Javadoc comments and the project `DESIGN` document.
`DESIGN-20`	Reflection for Instantiation from Strings	Forthcoming	Use reflection whenever you need to create objects or call methods from `String`s rather than hardcoding conditionals or a mapping between the `String` literal and your object.
`DESIGN-21`	Logging	Forthcoming	Use Log4j2, instead of `println()` statements to output messages. A message must be generated *any time an Exception is thrown* that is saved to one or more files within the folder `log`. Messages labeled as `DEBUG` or `INFO` can go to the console (standard out) or a file.