Gebruiker:Raboof/PixSkillFlut

Project: PixSkillFlut
PixSkillFlut
Naam	PixSkillFlut
Door	Raboof
Status	Idee
Madskillz	Networking, Coding
Doel / Omschrijving
pixelflut - maar wees slim, niet sterk.
Alle Projecten - Project Toevoegen

noez

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

Isolatie

Om de programma's van spelers te scheiden van de runtime kunnen we ze op een aantal manieren isoleren:

• Een eigen taal defineren en die zelf interpreteren. Leuk, maar waarschijnlijk niet triviaal om snel genoeg te maken om een fatsoenlijke framerate te halen
• Een bestaande taal gebruiken, communiceren over STDIN (met backpressure) en het proces met linux-tools isoleren. Isolatie wordt hier misschien lastig.
• Een bestaande taal gebruiken en deze met een scripting engine embedden. Misschien makkelijker te isoleren maar wellicht moeilijker backpressure toe te passen?

Performance

De TkkrLab Pixelflut op SHA draaide op een server en stuurde 12 blokken van 80x80 pixels aan (dus totaal 320x240). Voor een full-screen animatie op 20fps zou je in deze setup dus 1536000 pixels per seconde moeten kunnen verwerken. Zij gebruikten een server in C, vermoedelijk https://github.com/ands/pixel.

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 self-modifying code en misschien zelfs 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. Wellicht wat te ambitieus ;).

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?

Hardware

Als het een beetje werkt misschien leuk voor de Thomson_Displaymuur?