From a0c3cd2533cb429b039d9e078d6ccabb7b822348 Mon Sep 17 00:00:00 2001
From: Andrea Bianchi <andrea@kaist.ac.kr>
Date: Thu, 9 Apr 2026 15:47:45 +0900
Subject: [PATCH] Init

---
 .DS_Store | Bin 0 -> 6148 bytes
 README.md |  95 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 95 insertions(+)
 create mode 100644 .DS_Store
 create mode 100644 README.md

diff --git a/.DS_Store b/.DS_Store
new file mode 100644
index 0000000000000000000000000000000000000000..5008ddfcf53c02e82d7eee2e57c38e5672ef89f6
GIT binary patch
literal 6148
zcmeH~Jr2S!425mzP>H1@V-^m;4Wg<&0T*E43hX&L&p$$qDprKhvt+--jT7}7np#A3
zem<@ulZcFPQ@L2!n>{z**<q8>++&mCkOWA81W14cNZ<zv;LbK1Poaz?KmsK2CSc!(
z0ynLxE!0092;Krf2c+FF_Fe*7ECH>lEfg7;MkzE(HCqgga^y>{tEnwC%0;vJ&^%eQ
zLs35+`xjp>T0<F0fCPF1$Cyrb|F7^5{eNG?83~ZUUlGt@xh*qZDeu<Z%US-OSsOPv
j)R!Z4KLME7ReXlK;d!wEw5GODWMKRea10D2@KpjYNUI8I

literal 0
HcmV?d00001

diff --git a/README.md b/README.md
new file mode 100644
index 0000000..53c12b7
--- /dev/null
+++ b/README.md
@@ -0,0 +1,95 @@
+# Individual Project - Video Game in Javascript
+
+## General Description
+
+You will implement a **video game** of your choice (already existing or an original design). You have _three weeks_ to implement your code and document your project with a README file. This first project is an _individual_ project. Any help received should be acknowledged in the `README`.
+
+## Requirments and Templates
+
+You must use `p5.js`. Optionally, you can use any library or framework.
+
+Feel free to use either the [p5js vite template](http://git.prototyping.id/andrea/p5js-vite) or the [simple p5js starter templates](http://git.prototyping.id/andrea/p5js-starter-template), or any other starter code.
+
+If you use [p5play](https://p5play.org/index.html), [this](http://git.prototyping.id/andrea/svelteP5Play) is also a template you could consider.
+
+For this project, you are encouraged to use libraries (e.g., [p5.js](https://p5js.org/libraries) or other libraries), online tutorials, or any material you can find (make sure to properly credit your sources in the documentation), but it is **not** required to explore material beyond those seen in class. Do not simply copy and paste code from the Internet - in such case, you will receive a score of 0 if we find out. If you want to use the p5js Play library, [here an example]().
+
+## AI Policy
+
+It is assumed that all projects will make use of generative AI to write part of the code. The evaluation will take that into account. However, if you choose to **NOT** use any AI for your project, _please specifically state it in your README file (very visible, at the top)_. In such a case, when I evaluate your project, I will take this into account, reducing my expectations on the expected features, quality, and amount of code generated.
+
+## Evaluation method and criteria
+
+The evaluation will be a combination of a `peer-reviewed score` (50%) and a `heuristic evaluation` of the code and documentation (50%).
+
+For the peer review part, all students, the TA, and the professor will individually grade via an online form each of the projects. The students' average and the professor+TA average will be weighted in this way: student average (40%) + TA and professor average (60%).
+
+The overall score will be computed as this:
+
+`score = (student_peer_score * 40% + prof_TA_peer_score * 60%) * 50% + heuristic_evaluation * 50% + optional_bonus * 5%`
+
+### Peer review score
+
+Peer reviewing follows these criteria:
+
+1. **Overall quality of the demo (20%)**: How good is the game interaction? How polished and complete is the game? What is the overall value of this game?
+2. **Challenge (15%)**: How ambitious is the project? How much effort did you invest in the design and implementation of the project?
+3. **Quality of presentation (15%)**: how well is the video showing the demo and details of the project? How clearly does the video convey the game dynamics and features? Are images clear, visible, stable, and in focus? Are the editing, the voiceover/sound, or any visual aid helping to understand?
+
+### Heuristic evaluation
+
+The code and documentation quality will be done by the professor and the TA with the heuristics described below.
+
+1. **Code quality (20%)**
+2. **Documentation quality (30%)**
+
+Finally, the professor can arbitrarily and optionally allocate **a +/-5% bonus or deduction** if he sees fit (this includes submitting the wrong files or with the wrong method)
+
+#### Code quality (20%)
+
+Your code will be evaluated with the following heuristics (each equally considered):
+
+1. **Code organization**: How well organized is the code? Is there a good usage of files, modules, functions, or classes? Do you also make good use of git, make regular commits, etc.?
+2. **Code readability**: Are there globals all over the place, poor naming conventions, and functions scattered all around? Or is the code readable, commented where needed, and clear for anyone to read? If your code is generated using AI, I will look wheather the code is well organized in conceptual blocks, rather than a monolitic codebase.
+3. **Code features + effort**: Does your code make use of any of the topics we covered in class? Are you using features/knowledge from this class? How challenging was your implementation? How feature rich is your application? If your code is generated through AI, there is an implicit expectation that the final game will be more feature-complete and polished than if it is purely coded by hand.
+
+#### Documentation (30%)
+
+How well and complete is your documentation? Your documentation should contain the following information:
+
+Write a `README.md` file that contains the following information.
+
+1. Your **name, ID, email**
+2. **URL of the git repository** with the source code. This can be on gitea or a public repository in Github, or equivalent.
+3. **URL of your video on YouTube**. This should be a public or unlisted video (not private!) on YouTube (no other platforms)
+4. A **description of the game** - how it works and what the user has to do
+5. A description of the **organization of your code**. Feel free to use diagrams, UML, or others. What are the main functions/classes? If you used patterns, what did you use them for, and how do different parts of your code speak to each other?
+6. **Highlight** any issue you want us to know about or whether the code has any known bug. If there are special features you want us to know about, write them here
+7. **Acknowledge any help** or resource you used
+
+- Writing style might be considered in grading (not the grammar, but rather the clarity of your writing)
+- Be visual so use images and tables
+- Try to be complete in your explanation - you do not need to write a lot, but the professor and the TA should be able to understand your documentation and your code by reading this file.
+
+## About the video demo
+
+The video should show a demonstration of your Game (e.g., gameplay). You can edit your video, but it should not be _fake_. It should be clear that your application is actually working, as shown in the video.
+
+The video should be no longer than 3 minutes. It can contain a voiceover. It can also contain a tutorial or an explanation of specific features, though try to focus on the actual gameplay. For example, you can even say technical details about the implementation (e.g., I used 3D transformation to do this and that...). Text and voice should be in English.
+
+**The video should be on YouTube** and not on other platforms. Make sure it is `public` or `unlisted` and NOT private.
+
+## How to submit the material
+
+1. **Zip** the folder of your repository containing your proposal (`README.md` file) and any source files (e.g., code, images, or others). Do **not** include `node_modules` in your submission.
+2. **Submit** the homework using the class [submission system](https://homework.designware.xyz). Choose `Individual project`.
+3. For any problem, feel free to contact the professor or TA via Discord.
+
+**NOTES**
+
+- Any submission after the deadline or without video will receive a flat penalty of 30% of the score (a score of 0 for peer evaluation). Submissions submitted after 24 hours from the deadline will be ignored (the score will be 0).
+- Only submissions made with the system will be considered (e.g., no direct emails to TA or Prof).
+- You can re-submit as many times as you want: the last submission only will be considered.
+- Keep a screenshot that proves your completed submission.
+- Other subjective metrics by prof may apply.
+- Reach out in case of problems or questions.