(brainstorm apart hoofdstuk) |
(→Idee) |
||
Regel 28: | Regel 28: | ||
== Idee == | == Idee == | ||
− | + | Spelers leveren hun bijdrage als programmacode aan. Programma's die weinig resources gebruiken worden door de scheduler beloond met meer 'kloktikken', zodat slim optimaliseren loont. | |
* Spelers publiceren hun bijdrage als code in een (nog te bedenken/kiezen) taal | * Spelers publiceren hun bijdrage als code in een (nog te bedenken/kiezen) taal | ||
Regel 37: | Regel 37: | ||
* De code wordt door de PixSkillFlut-server periodiek gedownload en constant geinterpreteerd | * De code wordt door de PixSkillFlut-server periodiek gedownload en constant geinterpreteerd | ||
* De scheduler: | * De scheduler: | ||
− | ** | + | ** draait ieder programma voor een aantal 'kloktikken' |
+ | ** kleine programma's (bijv. zonder grote bitmaps) worden beloond met meer kloktikken | ||
== Taal == | == Taal == |
Versie van 21 dec 2017 11:00
Project: PixSkillFlut | |
---|---|
Naam | PixSkillFlut |
Door | Raboof |
Status | Idee |
Madskillz | Networking, Coding |
Doel / Omschrijving | |
pixelflut - maar wees slim, niet sterk. | |
Alle Projecten - Project Toevoegen |
pixelflut is een leuk hackerspelletje: geef een scherm een publieke API om pixels aan te sturen, en zie mensen het scherm bombarderen met hun beeldmateriaal.
Wat jammer is aan de traditionele pixelflut is dat het 'brute force' beloont: wie de server het hardst overlaadt met verbindingen en bandbreedte wint. Het zou aardig zijn als we een variant kunnen bedenken, 'pixskillflut', die behendigheid beloont in plaats van kracht.
Dit project is in de idee-fase: ik heb grof idee dat zou kunnen werken, maar nog weinig implementatiekeuzes gemaakt. Zin om mee te doen? Graag! Let me know!
Brainstorm
Wishlist:
- Gemakkelijk te spelen, moeilijk te winnen. Deel van het leuke van de oorspronkelijke pixelflut is haar eenvoud, je kunt vrij makkelijk een scriptje schrijven om mee te doen. Dat moeten we behouden
- Beloon spaarzaam omgaan met resources. Zo wordt de server ook minder snel overbelast.
Ideeen:
- Het wordt makkelijker wanneer je spelers op de een of andere manier kunt authenticeren. Als mensen samen kunnen werken is dat misschien een feature, geen bug - maar je wil niet dat 1 speler alleen met veel accounts kan spelen. Met die aanname zou je kunnen denken aan:
- Rate limiting: een beperkt aantal operaties per tijdseenheid, waarbij een 'operatie' misschien niet alleen een pixel maar ook 'vector graphics'-achtige constructies zijn
- Een of andere auction, bijvoorbeeld "de speler met het middelste bod wint", en een of andere manier om feedback te krijgen over het gedrag van andere spelers/winnaars.
- Timing: met een bepaalde framerate een constructie zoals 'wie het dichtst bij de deadline zat zonder eroverheen te gaan wint'. Flooden kun je enigszins tegengaan door bijv. TCP te gebruiken en maar 1 instructie per pixel per tijdseenheid toe te staan, maar dan kan iemand alsnog meerdere verbindingen gebruiken
Idee
Spelers leveren hun bijdrage als programmacode aan. Programma's die weinig resources gebruiken worden door de scheduler beloond met meer 'kloktikken', zodat slim optimaliseren loont.
- Spelers publiceren hun bijdrage als code in een (nog te bedenken/kiezen) taal
- Daarvoor leveren ze een URL aan naar een code-sharing site
- Laten we beginnen met github
- Dit promoot het delen van code en leren van elkaar
- En maakt het lastiger met meerdere accounts tegelijk te spelen: 1 programma per github-account tegelijk
- De code wordt door de PixSkillFlut-server periodiek gedownload en constant geinterpreteerd
- De scheduler:
- draait ieder programma voor een aantal 'kloktikken'
- kleine programma's (bijv. zonder grote bitmaps) worden beloond met meer kloktikken
Taal
Wat voor taal dan? Aan de ene kant is het leuk als mensen makkelijk kunnen beginnen, en taalconstructies hebben als variabelen, procedures etc. die ze ook kunnen delen. Een eenvoudige procedurele taal dus.
Aan de andere kant is het leuk als mensen 'rare' code en optimalisaties kunnen gebruiken. Dan zou je kunnen denken aan een assembly-achtige taal met random memory access (self-modifying code) en pipelining.
We zouden ook 2 talen kunnen hebben: een high-level 'procedurele' taal en een low-level 'assembly-achtige' taal, waarbij de high-level taal gewoon naar de low-level assembly wordt gecompiled. Dan heb je best of both worlds, maar geef je mensen die (gedeeltelijk) in assembly werken wel een voordeel. Als meta-game zou je mensen zelfs uit kunnen dagen nieuwe high-level talen te introduceren.
Primitieven
Naast rekenen moeten we denk ik de volgende primitieven bieden om naar het scherm te schrijven:
- lees de resolutie en kleurdiepte van het scherm
- lees een pixel
- schrijf een pixel
- schrijf een lijn
- schrijf een rechthoek
- schrijf een ellips
Misschien:
- schrijf een bitmap (het is leuk als dit makkelijk is, meer eyecandy op het scherm ;) )
- schrijf een letter
- bepaal de grootte van een letter
De 'prijs' van iedere instructie kunnen we zo tweaken zodat 'slim' gebruik van instructies beloond wordt - dus 'schrijf een lijn' moet goedkoper zijn dan het schrijven van alle pixels van de lijn, maar 'schrijf een rechthoek' moet ook weer niet zo goedkoop zijn dat iemand met een klein loopje het scherm 1 kleur kan houden.
Implementatie
Het is misschien wat te ambitieus om dit op een ESP32 te proberen te laten draaien, dus iets wat op een RPi kan draaien lijkt me prima.
In de eerste instantie gewoon output naar het scherm/beamer, 'echte' pixels kan altijd later nog ;).
UI
Het zou leuk zijn als er een web UI is die de 'huidige' spelers/programma's laat zien, en misschien ook per speler hun bijdrage aan het scherm?