For our second project you’ll be implementing Conway’s Game of Life. Despite the name, this is really a simulation. It is interesting to see the patterns and “life” that appears from such simple rules.

As in the first project, we will continue to challenge your programming skills while building on your ability to work in a team, use version control effectively, and apply an Agile development methodology.

Learning Goals

  • Basic web development using JavaScript, HTML, and a little CSS
  • Independent learning and problem-solving skills
    • We will cover some basic ideas in class, but just as in the last project, it’s up to you to pick up all the details. I’m here to guide you if things are taking too long, but it’s up to you to research and experiment!
  • Team-based software development and project management:
    • Agile methodology to plan, execute, and track progress, including the use of sprints, user stories, and retrospectives.
    • Git and GitHub for version control and collaboration
    • Git feature branch workflow
  • Presentation skills
  • Software design patterns and architecture, specifically MVC (Model-View-Controller)

The “Game”

The essence of the simulation is a grid of cells, each of which is either alive or dead. Generally, living cells are colored (e.g., red, green, black), while dead cells are white. But you can choose colors as you please.

The game is turn-based: for each turn, each cell decides whether it will be alive or dead in the next turn. It does this by considering the cells around it (cells adjacent horizontally, vertically, or diagonally). People have come up with different rule variants, but Conway’s initial rules were (taken from Wikipedia):

  1. Any live cell with fewer than two live neighbors dies (underpopulation).
  2. Any live cell with two or three live neighbors lives on to the next generation.
  3. Any live cell with more than three live neighbors dies (overpopulation).
  4. Any dead cell with exactly three live neighbors becomes a live cell (reproduction).

The behavior of the simulation depends on the initial state (AKA “seed”) of the system.

At a minimum, our users should be able to:

  1. Before a simulation has started, click various cells to toggle them alive or dead.
  2. Start a simulation.
  3. Pause a simulation.
  4. Stop a simulation.

However, many more features are possible and should be considered. Here are some example stretch goals:

  • All the users to select different rulesets.
  • Let the user adjust the simulation speed.
  • Ability to save the current state and load it later.
  • Ability to use a library of predefined patterns.
  • Advanced visualization, e.g., color-coding cells based on their age, visual effects when a cell is born/dies, etc.
  • Make the app responsive and usable on a mobile device

You may come up with your own stretch goals, keeping in mind the fact that this is only a one-month project. It is recommended that you come to me with your stretch goal ideas for advice on how to implement them.

The Implementation Medium — A Web App

Your implementation will be a web application using HTML, CSS, and JavaScript. We will review the basics in class, but you are encouraged to explore additional resources and tutorials.

The Development Environment — VSCode

The whole team should work with the same IDE (integrated development environment). I highly recommend VSCode — it’s popular (so there’s lots of online support), easy to use, and works on all major operating systems. However, your team is free to have a discussion and choose a different IDE.

As before, use Git for version control. However, I also want you to do a few new techniques:

  • Use GitHub issues to track your progress on features and any bugs you find.
  • Use Git feature branch workflow to develop your features. The basic idea is to make a new branch for a new feature and implement your feature. When you’re done, commit, push, and make a pull request on GitHub. Ask your teammates to review the pull request, possibly walking them through the code. After making any changes they’d like, merge your pull request!

Initial Planning

Start by envisioning your final product and creating user stories. You don’t necessarily need to implement ALL of these user stories, just come up with a bunch. Estimate how long each story will take in “points”.

I will act as a partial “product owner”, helping to define and clarify your user stories. The user stories are key, BUT please realize that the plans here are not fixed. Your initial plan will evolve based on feedback and your sprint reviews.

Your goal is to end up with a final “release” that is a usable product. It may not have all the user stories or features you wanted, but it should run and do some things.

After you get your feet wet, I’m going to introduce extra requirements in weeks 2 and 3 (see below). Keep this in mind when doing your planning.

Details about User Stories

User stories describe a feature or function of your application from the perspective of your end user. They’re a way to capture user needs and ensure your project aligns with those needs. A typical user story follows this format:

As a [type of user], I want [some goal] so that [some reason].

For example:

As a user, I want to pause the simulation so that I can inspect the current state of the grid in detail.

(We will probably only have one type of user.)

Some user stories will be essential, others are just nice to have. Work together to prioritize these stories, focusing first on those that are critical to a successful “release.”

Agile “Sprints”

In real-world Agile implementations, “sprints” are 1–4 weeks. Due to the duration of our project, your sprints will be one week long.

Each week, decide which user stories (or parts of user stories) are most important, break them down into small tasks, and assign them to team members. Use GitHub issues to track these tasks — both new tasks and old ones not yet completed (the “backlog”). Estimate how long each task will take and keep track of the velocity, just like in previous projects.

Every time you meet as a group, start with a 5-15 minute “stand-up meeting”. The point of standing is to keep the meeting short. (It’s okay if some members are unable to stand.) Each member should address three questions:

  1. What have I done recently that helped us meet our spring goal?
  2. What will I do today?
  3. What obstacles are preventing progress?

After this, you can do code reviews, re-assign tasks as necessary, and begin coding. Code in pairs or triples whenever possible.

When Things Don’t Go As Planned

It’s normal for plans to change. Use your meets and especially the checkpoints to adjust tasks based on completed work and team velocity.

Sometimes you may need to slow down and make sure you understand JavaScript. If you use web sources, make sure you understand the code you’re using, or else it will actually slow you down when things don’t work the way you expect.

Checkpoint Presentations

Begin by showing me a demo of the current state of your project, focusing on newly implemented features or user stories. Spend some time telling me what your tasks were, who worked on them, how long they took versus expected time, and velocity. Include a small code review. Reflect on your user stories themselves — how well they were understood, whether they effectively captured user needs, and how they might need to be changed.

Then review your teamwork and Agile project management — what you did well versus what could be improved. This is an opportunity for feedback and reflections. Lastly, tell me your plans for the next sprint, including what is in the “backlog” and what changes might be needed to keep the “release” on track.

Final Presentation

Your final presentation should target first-year computer science students. This is a longer presentation: 15–20 minutes. It should include the following components, not necessarily in this order:

  • Explain the motivation behind the project — why are you doing it and what are you learning?
  • Explain your development process and Agile methodologies — act like you are teaching it to them!
  • Show a demo of your final result.
  • Highlight key piece(s) of code. Pick only the most important/interesting bit(s). Slow down and explain it well.
  • Discuss your success and mistakes, both in terms of coding but also project management.
  • What would you do differently if you could restart the project from the beginning?
  • If you had time for another “release”, what users stories would you focus on, and what would the next sprint look like?

Presentation tips:

  • Number slides
  • Use an outline slide. Possible flash it up between sections
  • Don’t add too much text to slides. Don’t just read directly off the slide.
  • Aim for one diagram/picture/code block per slide.
  • Don’t cover too much!

Testing (Week 2+ only)

Starting in week 2, we’re going to add explicit testing as a requirement for your project. We’ll use QUnit to do this. We’ll talk more about this in class.

MVC Architecture (Week 3+ only)

Starting in week 3, we’re going to refactor your app to use a specific software architecture called MVC (Modal-View-Controller).

The idea is to split your app into three components. This separation helps in managing complex applications, making it easier to maintain and add features.

  • Model: the central component, managing the data, logic, and rules of the application. For us, this would manage the grid state and the rules for determining which cells are born or die.
  • View: Any representation of the state. For us, it’s the visual representation of the grid on the HTML canvas.
  • Controller: Accepts input and converts it to commends for the model or view. For us, including the acts of starting, pausing, or resetting the grid.

The previous week’s tests should make it easier to refactor, since you can be more confident that you didn’t break anything. Although your tests might need some changes. You should focus on testing the model, and perhaps the controller. Testing the UI is beyond the scope of this project.

Test-Driven Development (Week 4+) only

In your final week, experiment with test-driven development. This style of development means you will write tests BEFORE writing any code. Yes, this means you will write tests that will immediately fail! The hope is that writing the tests first makes the goal and eventual code clearer, while also enforcing comprehensive tests for your app.