Use this GitHub Classroom link to create a repo for this project.
!!! Important !!! This is an individual assignment. You may not work in teams.
For this assignment you will implement the game Connect 4 using JavaScript.
You will be adding two additional features:
- The size of the board will be configurable.
- The run length needed to win will be configurable. (So, I guess the game is really "Connect X").
I placed a sample solution on EOS at /home/kurmasz/public/CIS343/c4demo. Your board and workflow need not be identical to mine. However, I will be using automated "system tests", so your input and output needs to formatted carefully. In addition, your implementation must follow a handful of rules, so Be sure to read the Details section below!
This assignment has two main objectives
- Provide experience writing asynchronous code (i.e., "callbacks").
- Provide experience combining both imperative and functional programming aspects.
In particular, think about the following as you write your code:
- What aspects of this program are easier to write in an functional style?
- What aspects of this program are easier to write in an imperative style?
This project uses the same interface rules as the C version. Review them if necessary.
-
You must use an asynchronous I/O library for reading user input. The starter code is set up to use the node:readline library. If you prefer, you may use
readline's Promises interface; but, you may not useawaitfor the I/O. You must use a callback. -
Your implementation must contain both imperative and functional aspects.
Your code must follow standard design principles. For example, be sure to
- Use comments
- Divide your code into appropriately-sized functions and files
- Make sure your code is neat, well-organized, and well-organized
You must use a Test Driven Development (TDD) workflow. If done well, your system tests from the C version of Connect 4 should also work for this project.
When your project is complete (has a complete set of tests, has a working game, passes my automated tests, and is well-formatted and well-documented), check in your code with "[Grade Me]" in the commit message.
Important: Just because your code passes the GitHub tests, does not mean it meets all the requirements. The GitHub tests do not, for example, check the user interface. They also don't check the completeness of your unit tests or the quality of your code.
One key purpose of the GitHub classroom setup is to automatically verify that submitted code is bug-free. Attempting to subvert this system and generate a "false positive" (for example, by modifying files such as the Makefile) is a serious violation of Academic Honesty and could result in a failing grade in the course.
Attempting to reverse engineer the sample solution through de-compiling or other means is a serious violation of Academic Honesty and could result in a failing grade in the course. Similarly, writing tests is an important part of the software development process. The automated tests are a part of this project's "solution". Attempting to access the specific test cases through means included, but not limited to, de-compiling and print statements is a serious violation of Academic Honesty and could result in a failing grade in the course.
Hiding and/or obfuscating GitHub activity through means such as rebasing, squashing, or outright deleting test runs is a serious violation of Academic Honesty and could result in a failing grade in the course.