multiplayer distinction

.cursor/rules/architecture.mdc

@@ -1,12 +1,11 @@
 ---
-description: General structure of the app
-globs: 
+alwaysApply: true
 ---
-
 # Structure
 
 - Read, but don't edit @README.md to get an idea of how the app should work.
 - Where possible, the app should be separated into an API and frontend components.
 - Tests should be written as the app is developed.
 - Use package.json to ensure you're using the correct packages to implement features and not installing redundant packages or reinventing the wheel.
-- User superforms for all forms
+- User superforms for all forms
+- For now, we will keep multiplayer and single player experiment serving, queuing, and session logic completely separate, even if it means overlapping and redundant code. We will optimise later.

.cursor/rules/multiplayer.mdc

@@ -0,0 +1,8 @@
+---
+description: Multiplayer experiment implementation
+globs:
+alwaysApply: false
+---
+
+- Multiplayer experiments should be 'run' by the app, not on the participant's computers like singleplayer experiments. This enables participants to drop connection and rejoin the session where they left off
+- All participants should see the same thing at the same time, but *later* I want to give the experimenter the ability to occasionally show participants different things based on a URL variable that this app will inject based on some . So participants will be on the same 'screen' but with different images, for example. The ability for experimenters to show different things should not be implemented unless directly requested, but any solutions to the basic multiplayer implementation consider that this needs to be possible in the future.