Project: A JavaScript Chip8 System

Chip8 is a low-level programming language designed to run on 8-bit computers. It is still of interest to many programmers because, compared to similar languages and hardware, it’s relatively easy to emulate. You can find lots of information about Chip8 online, including tutorials for creating an emulator and programs that you can run on your own Chip8 once you get it working.

Your project for this semester is to design, create, and test the Chip8 software described below. All your code should run in any modern web browser that supports JavaScript, and so the implementation language must be JavaScript, or some language that compiles to it (like TypeScript).

Here are the major components of your project that your team should design, create, and test:

• A Chip8 emulator (i.e. virtual machine) that can run any Chip8 program (e.g. from the web, or that you write). This includes input and output.

• A Chip8 visualizer that lets you see a Chip8 program in action. It should show the memory, registers, instruction being executed, etc. Also, it should allow the program to be paused, be stepped-forward one instruction at a time, or be stepped backwards one instruction at a time.

• Create at least one other Chip8 tool that would be useful for a software developer. Your team needs to decide what this tool will be. It could, for example, be a graphics editor for creating Chip8 sprites, or a text editor plug-in to make writing programs easier. Try to pick something useful that your team actually uses, and that other Chip8 developers might want to use as well.

• Create at least two, original and polished (and hopefully fun) Chip8 games. The code for the games should be written by your team, and be specific to this project. The games could be ideas of your own original creation, or you could clone other games (perhaps Tetris, or Breakout, or Minesweeper, etc.). Whatever you choose to do, the majority of the source code should be written by your team.

  When your Chip8 emulator is done, it should be able to run these games (as well as any other Chip8 programs, of course). Note that you could begin development of these games before your emulator is ready by using some other Chip8 emulator.

You can, of course, do more then this if you like. But the above requirements are how your project will be judged, so spend your time and effort wisely.

These requirements are straightforward but informal, and an important part of your team’s job will be to make them more precise. Your team can interpret them in any reasonable way (although, ultimately, what is reasonable will be decided by the marker).

General Requirements

• Everyone on your team is expected to do the same amount of work, although, of course, they won’t all do the same work. Different team members can have different roles.

• Your team must schedule at least one face-to-face in-person meeting every week. In addition to this, you should also keep in close communication on-line (e.g. using Slack, or Discord, or Skype, etc.).

• Your team must use the Git version-control system to manage its source code. You can, if you wish, use something like Github, or just a private Git repository that you share among teammates.

• Your team should not spend any significant amount of money, and should not use software or tools that aren’t freely available to other students.

• Your team must do the majority of the creative and implementation work. You can (with proper citation!) use ideas and some libraries from elsewhere, but don’t treat this as just a modding project of existing software.

• Testing is a significant part of this project, and thus your team is required to do automated testing. Make it easy to automatically re-test your program after any change to the source code.

• Your software must run in a modern web browser, which means you must implement it with JavaScript, or some language that compiles to JavaScript (such as TypeScript). You do not need to create a big, complicated multi-page website: a single-page JavaScript application is fine. You also don’t need to save anything in a database or to files on disk.

  There is no need to use any major web framework tools (such as React, or Vue.js). You won’t get any marks for using such a framework. The time it takes for everyone in your group to get up to speed on a modern web framework may not be worth the effort for this project. But, if you your group decides it is worthwhile, you certainly could use such a framework.

• Non-technical issues can arise in team project like this. For example, some team members may feel they are doing more work than others, and thus that they deserve more credit. Or some team members might get frustrated that their ideas are not used. It is important that your team take these issues seriously, and try resolve problems in a friendly and professional way.

Release 0: Getting Started

Create a Product Document that contains all the project planning info for our team. It needs at least the following information:

• your group’s semester meeting schedule
• communication tools/techniques your team plans to use
• software repository your team plans to use
• details of the software methodology your team plans to use (e.g. what roles do team members have?)
• testing and quality assurance tools and methods your plans to use (remember, you must do automated testing for your source code!)
• main implementation language your team plans to use (and any major libraries/tools you plan to use with it)
• detailed use cases for all major features planned for the next release
• detailed work breakdown, divide your project into small parts, estimate how much work they will take, etc.
• detailed schedule showing when you plan to finish every part of the project

Part of the mark for this assignment is for the completeness and clarity of this Product Document, and its overall quality.

The exact format of this document is up to you, but we strongly recommend that you use Markdown. Markdown is a popular mark-up language that can be converted to HTML, but it is much easier for humans to wrote. Markdown is used in websites like Github, and Git can easily track changes made to it.

Release 1

• updates to your Product Document (clearly point out differences from previous version)
  • this means any and all changes or updates to any part of your team’s work
• features planned for the next release (i.e. use cases and other helpful info for all new features)
• product release
  • usable version of the software (and all source code), including instructions for how to use it, etc.
  • automated testing for the release, including instructions for how to run the testing
  • discussion of which planned features were not implemented (why not?), and which unplanned features were implemented (why?)
• your product (including automated testing code) will be judged on the following criteria
  • source code readability
  • correctness (i.e. lack of bugs!)
  • performance
  • usability
  • quality of output (i.e. user interface)

Release 2

• updates to your Product Document (clearly point out differences from previous version)
  • this means any and all changes or updates to any part of your team’s work
• features planned for the next release (i.e. use cases and other helpful info for all new features)
• product release
  • usable version of the software (and all source code), including instructions for how to use it, etc.
  • automated testing for the release, including instructions for how to run the testing
  • discussion of which planned features were not implemented (why not?), and which unplanned features were implemented (why?)
• your product (including automated testing code) will be judged on the following criteria
  • source code readability
  • correctness (i.e. lack of bugs!)
  • performance
  • usability
  • quality of output (i.e. user interface)

Release 3

• updates to your Product Document (clearly point out differences from previous version)
  • this means any and all changes or updates to any part of your team’s work
• features planned for the next release (i.e. use cases and other helpful info for all new features)
• product release
  • usable version of the software (and all source code), including instructions for how to use it, etc.
  • automated testing for the release, including instructions for how to run the testing
  • discussion of which planned features were not implemented (why not?), and which unplanned features were implemented (why?)
• your product (including automated testing code) will be judged on the following criteria
  • source code readability
  • correctness (i.e. lack of bugs!)
  • performance
  • usability
  • quality of output (i.e. user interface)

Release 4: The Final Product

• updates to Product Document (clearly point out differences from previous version)
• product release
  • usable version of the software (and all source code), including instructions for how to use it, etc.
  • automated testing for the release, including instructions for how to run the testing
  • discussion of which planned features were not implemented (why not?), and which unplanned features were implemented (why?)
• features planned for the next release (if there is one — this is the final release for the course)
• your product (including automated testing code) will be judged on the following criteria
  • source code readability
  • correctness (i.e. lack of bugs!)
  • performance
  • usability
  • quality of output (i.e. user interface)
• final presentation and demo
• project post mortem discussion: What worked well in this project, and what didn’t? What would you have done differently knowing what you know now? What was the biggest unexpected challenge? Was all the testing worth it? What advice would you give to the next students who take 276?