Arkitektur ========== - Nettleserklienter, antageligvis Windows, hva nå folk har - Linux-server - Apache - PostgreSQL (overkill? galt verktøy?) - C++ med OpenGL, mot projektor - Perl (CGI.pm, Template.pom) - Lavhastighets Ethernet, evt. WLAN Use case ======== 1. Snute får 9983 på Max 300. 2. draconia dytter inn i webinterfacet (i Snutes gruppe, som han har oppe) at Snute har valgt Max 300 som selvvalgt sang, og fikk 9983 på den. 3. Webinterfacet oppdaterer PostgreSQL, og HUPer projektordæmonen. (Dette er ikke et bokstavelig SIGHUP, vi fikser det antageligvis med en socket der bare en får snakke av gangen, e.l..) 4. Projektordæmonen kaller refresh_data() på alle subscreens. 5. Subscreens som merker endret data, legger til et element på sin aktivitetsliste (hvis ting skal gjøres fancy), eller invaliderer seg selv totalt (hvis supersystemet skal gjøre evt. overganger). Eksempler: 5.1. Subscreenen for Snutes gruppe lager en fancy effekt (evt. bare skriver ett og ett siffer :-) ) der scoren hans detter på plass, og evt. neste spiller highlightes. (Dette kan være to helt separate aktiviteter...) Hvorvidt denne aktiviteten skal hardkodes på noe vis eller om man skal ha et scenegraphsystem og f.eks. lua er ikke bestemt ennå, evt. kan vi bare gå for ren invalidering (se neste punkt). 5.2. Subscreenen for "dagens beste scores" invaliderer seg selv, da den ser at top5-lista har endret seg. Supersystemet spawner den på nytt, pusher prioriteten på den nye opp (fordi den inneholder ny info) og drar den med inn i rotasjonen neste gang. (Rationale: Vi har ikke kapasitet til å lage fancy endringsfunksjoner for alskens rare situasjoner, like greit bare å lage litt fades her og der og ha et enhetlig system for å ordne det.) I begge tilfelle kan vi legge en rød ramme rundt (blinkende?) for å signalisere ny informasjon, f.eks. første gang en skjerm vises. 6. refresh_data() returnerer en liste over alle nylig spawnede skjermer. 7. draconia gis feedback ved at "nylig spawnede screens" (fra refresh_data) kommer opp på skjermen slik at han kan se hva som er skjedd. 8. Tilbake til punkt 1, antageligvis. Typer screens i projektordæmonen ================================ Terminalscreens: Alle terminalscreens rendrer til en tekstur (640x480? 1024x768? Trenger den overhodet å vite noe om det? Noe power-of-2?) slik at grenscreens kan fade mellom dem o.l. etter behov. (Det er ikke "terminal" som i "xterm", det er terminal som i "avsluttende", da en terminalskjerm ikke kan ha noen barn.) 1. Gruppescreen - Viser spillere i gruppa, med scores og selvvalgte sanger (plassproblem?) - Viser hvem som er neste, og evt. hvor mye som skal til for å gå videre/vinne gruppa. (Nederst er kanskje best her, vi har ikke så mye å gå på i bredden.) 2. Dagens fem beste scores. (Ren score, standardavvik.) 3. Tidligere spilte grupper. 4. Video-input? 5. PG-reklame e.l. 6. Sjekk innspill fra draconia her. Grenscreens: 1. Splitscreen (rommultipleksing). - Alle logiske splittkonfigurasjoner (mao. MxN). - Statisk oppdeling, må invalideres om man skal endre konfigurasjonen? 2. Rotasjon (tidsmultipleksing). - Har flere skjermer, organisert etter prioritet. Nye skjermer har mer prioritet, utover det går det på round-robin. Vi må passe på her så det blir en logisk rekkefølge av ting med lik prioritet (tidligere grupper burde f.eks. sorteres etter gruppenummer, dette kan vi løse helt OK med bare en "global prioritet" vi reverter til når vi er på slutten av lista og ikke har ny info som skal vises). - Fader mellom skjermene i et gitt tidsintervall. - Viser "n/N" nederst (tekst-TV følgesider). - Også nyttig for bare én terminalskjerm, som sørger for å fade til en ny skjerm når den gamle invalideres. 3. Overlays. - Alle terminalscreens burde sette destination alpha riktig, ergo er det bare å tegne teksturene oppå hverandre i rekkefølge. Typisk tilfelle: rotation(inf,0.5) // ytterste hovedvindu, kan ikke fjernes split(2,2) // hovedvindu, 2x2 rotation(inf,0.5) // gruppe 3 group(3) rotation(inf,0.5) // gruppe 4 group(4) rotation(inf,0.5) // gruppe 5 group(5) rotation(10,1.0) // diverse nederst til høyre topscores() // dagens beste group(1) // tidligere grupper group(2) image(pglogo.png) Grafen her ordnes antageligvis også av webinterfacet på noe vis, som sørger for å splitte og ordne etter behov. Trikset her er å få i stand best mulige primitiver mellom Perl og C++ over socketen; her må man nok tenke mer. Beste alternativ så langt er å la en manuell operatør ta seg av rendergraphen i et språk lignende det over. Tanker: - Det at en node invaliderer seg selv og det spawnes en kopi (ikke veldig vanskelig å gjøre, antageligvis) er et spesialtilfelle. Det er omtrent den eneste operasjonen man trenger å gjøre automatisk som respons på input av scores utenfra, og det er alltid én node som fjernes og én (lik) node som legges til på samme sted. - Vi får ganske mye gratis om vi navngir alle nodene våre. Da kan vi håndtere endringer o.l. ganske greit; hvis en node har samme navn og samme innhold beholdes objektet, hvis ikke destrueres det og et evt. nytt lages. Type: group3: group(3) group3_rot: rotation(inf,0.5) group3 mainsplit: split(2,2) group3,group4,group5,misc - Et system ala det over er lett å bygge ut til noe som automatisk lager graftreet. - Vi trenger ikke å løse alle verdens problemer på en gang. Det er sikkert veldig fancy å ha splitscreens som ekspanderer og trekker seg sammen o.l., men når du får for mange parameterendringer på en gang blir det fort knot. Det er et reellt alternativ å lage en funksjon som sier "her har du nye parametre, oppdatér deg selv hvis du kan, ellers returner false og jeg lager en ny". rotation() kan håndtere denne situasjonen rimelig lett (oppdater parametre, hent inn alle nye noder, fade til neste (hva er neste?), kast ut alle gamle), split() vil nok ha mye mer problemer, men det er funksjonalitet man evt. kan legge til seinere. Dersom man faktisk lager en ny, må kanskje foreldrenoden få beskjed slik at den kan fade e.l. :-)