Tja, vad jag just har förklarat hittills så är det vad vi slutade med att göra i projektet, grafikmässigt. För att komma till den punkten var processen, som alltid, full av iterationer och förändringar, försök och framför allt misstag. När vi startade projektet så baserades idén på rörelsespårning som ingångskontroll. Vi började utforska det som primär kontroll plus en sekundär kontroll med mus eller tangentbord.
Vi fick rörelsespårningen att fungera ok, men inte tillräckligt bra. Och allt eftersom spelet fortskred så handlade det mer och mer om hastighet och noggrannhet, vilket inte riktigt fungerade så bra med bristen på precision med rörelsespårning i allmänhet. Problem relaterade till kamerabehandling, ljusförhållanden och buller var för allvarliga och inte så stabila som den breda allmänheten med rätta kunde förvänta sig.
Det kändes inte heller intuitivt och enkelt nog att välja en spårningsfärg eller lära sig gränserna för rörelseområdet. Med ett mer förlåtande spel, eller en bättre funktion/färgspårning och rätt visuell feedback, kan det fortfarande vara genomförbart. Men det finns ett annat problem som vi skulle ha tagit itu med om vi tagit den vägen.
Logiken för att hålla spelet synkroniserat i läget för två spelare beror på delta-rörelser, som att säga ”Jag flyttade musen i den här riktningen med den här hastigheten”, vilket fungerar bra med touch och tangentbord, men mindre valfritt med direkta kontroller som mus eller en position för ett objekt i din webbkamera.
För det senare måste du skicka den exakta positionen för varje bildruta som orsakar uppsvälld datatrafik. Och det gör det svårare att interpolera/extrapolera spelet för att dölja latens. Så jag är glad att vi tog beslutet att undvika rörelsespårning, även om jag tillbringar nästan en månad med att vifta i luften med slumpmässiga färgglada föremål.