This is a group project. You must work in a group of 4-5.
In this lab you will use your:
This assignment requires that you work with the ESPNOW communication protocol to build a multiplayer game.
You will be assigned a team of four to five (depending on the class size) group members. Please contact the instructor and/or preceptor ahead of time if you have requests for group formation in the negative (i.e. we will honor preferences for people you do not want to work with, but will not accommodate preferences for who you do want to work with).
Your assignment will be to build some meaningful addition to the code here: https://github.com/santolucito/ESP32aceTeam
As always, the standard deliverables. If working in a group, you may all submit the same code repository, but each need to submit your own blog. The post should detail, in your own words, the creative vision of the device you have created. You should detail the technical challenges you specifically (as opposed to other group members) faced during the implementation of the device.
(10 pts total - see below for breakdown)
In addition to the project specific deliverables lists above, you must also meet the following “standard documentation deliverables”. Throughout this course, we will ask you to document your work in order to slowly build a portfolio of your projects. Going forward, these types of standard documentation deliverables can be assumed to be required for all assignments unless specified otherwise.
(5 pts) A blog post
Using a blog site of your choice (github pages, hackaday, medium, notion, etc) make a blog post describing your art. The post should give an overview of your artistic vision. In particular for this assignment, you should address how you have specialized your generative art to the space. What creative decisions did you work lead you to, and which decisions did you take? How were your decisions motivated by your larger creative vision for this project. In the same vein, also address any technical issues you encountered in your work. Particularly focus on issues that other artists may encounter when developing with your hardware setup.
(3 pts) A README
On your github repo add a readme that contains a short description and key information on reproducibility/installation/usage. This key information should be sufficient for a knowledge third party, outside the class, to replicate your design. This readme can be a subset of the material used in your blog post.
(2 pts) Visual documentation of your art (and in this case, the installation as a whole)
Both your blog post and the README should have some amount of visual documentation. Typically the blog post will have a video. The README can have some lighter weight visuals (e.g. a still image). The video can be a simple video shot on your phone - assuming you use basic best practices as discussed in class. You can host the video wherever you like as long as the hosting platform supports in-browser playback (e.g. YouTube, Vimeo). You may also choose to embed a gif in your README in place of a video link.