Vi fortsätter att berätta hur vårt laseruppdrag med förstörelsen av servern arrangerades. Börja i föregående .
Totalt hade spelets backend 6 arkitektoniska enheter, som vi kommer att analysera i den här artikeln:
- Backend av spelenheter som var ansvariga för spelmekanismer
- Backend och platsdatautbytesbuss på VPS
- Översättare från backend-förfrågningar (spelelement) till Arduino och hårdvara på plats
- Arduino, som ansvarade för att styra reläerna, fick kommandon från översättaren och gjorde själva arbetet
- Faktiska enheter: fläkt, girlanger, golvlampor, etc.
- Frontend - själva Falcon-webbplatsen, från vilken spelare kontrollerade enheter
Låt oss gå igenom var och en av dem.
Backend av spelenheter
Backenden implementerades som en fjäderstartapplikation: den hade flera vilokontroller, en websocket-slutpunkt och tjänster med spellogik.
Det fanns bara tre kontroller:
- Megatron. Den aktuella Megatron-sidan skickades via GET-förfrågningar: före och efter att strömmen slogs på. Lasern avfyrades genom POST-begäran.
- Mappning av tilde-sidor så att de betjänas av sidnamn. Tilde producerar sidor för export inte med originalnamn, utan med internt ID och efterlevnadsinformation.
- Captcha-kontroller för att tjäna pseudo-högbelastningsserver-captcha.
Websocket endpoint användes för att styra prylar: lampor, girlander och bokstäver. Det valdes att synkront visa enhetens aktuella status för alla spelare: om den är på eller av, aktiv eller inte, vilken färg på bokstaven som för närvarande lyser på väggen. För att göra uppgiften att slå på lasern lite svårare lade vi till auktorisering till kransen och lasern med samma login och lösenord admin/admin.
Spelare kunde testa det genom att slå på kransen och upprepa samma sak med lasern.
Vi valde ett så trivialt inloggning-lösenordspar för att inte plåga spelare med onödiga val.
För att göra uppgiften lite mer intressant användes objekt-ID från mongodb som enhetsidentifierare i rummet.
ObjectId innehåller en tidsstämpel: två slumpmässiga värden, varav ett tas baserat på enhetsidentifieraren och det andra baserat på pid för processen som genererar det och räknarvärdet. Jag ville göra identifierarna som genererades med jämna mellanrum och med olika pid-processer, men med en gemensam räknare, så att valet av en laserenhetsidentifierare skulle bli mer intressant. Men i slutändan började alla med identifierare som bara skilde sig i räknarvärdet. Detta kan ha gjort steget för enkelt och inte kräver analys av objectId-strukturen.
Översättare från backend-förfrågningar
, som arbetade med timers och översatte dem från spelabstraktioner till en fysisk modell. Till exempel, "slå på golvlampan" → "slå på relä N2."
Skriptet kopplade till RabbitMQ-kön och överförde förfrågningar från kön till Arduino. Den implementerade också logiken med parallell ljusväxling: tillsammans med vissa enheter tändes ljuset på dem, till exempel när ström först tillfördes Megatron, var den upplyst med scenljus. Ljusdesign för kinematografin av hela scenen är en separat berättelse om det stora arbetet av vår projektmedproducent och produktionsdesigner Ilya Serov, och vi kommer att berätta om det i ett separat inlägg.
Översättaren var också ansvarig för logiken i att starta dokumentförstöraren med en timer och överföra bilden till TV:n: timern för att starta dokumentförstöraren, en skrikande kapybara, en reklamfilm i slutet av spelet.
Hur logiken för att generera Megatron-token var uppbyggd
Provskott
Var 25:e sekund genererades en ny token som kunde användas för att slå på lasern i 10 sekunder med 10/255 effekt. Anknyta till .
Lasern svalnade sedan i 1 minut - under denna tid var den inte tillgänglig och accepterade inte nya skottförfrågningar.
Denna kraft räckte inte för att bränna igenom repet, men vilken spelare som helst kunde avfyra Megatron och se laserstrålen i aktion.
MD5-hashningsalgoritmen användes för att generera token. Och upplägget fungerade MD5 från MD5 + räknare + hemlighet för en stridsbricka och utan hemlighet för en testbricka.
MD5 är en referens till ett kommersiellt projekt som Pavel, vår backender, gjorde. För bara ett par år sedan använde detta projekt MD5, och när han berättade för projektarkitekten att det var en föråldrad krypteringsalgoritm började de använda MD5 från MD5. Eftersom vi bestämde oss för att göra ett så noob projekt som möjligt kom han ihåg allt och bestämde sig för att göra en liten referens.
Stridsskott
Megatrons stridsläge är 100 % laserkraft på 3 watt. Detta räcker i 2 minuter för att bränna igenom repet som höll vikten, för att bryta akvariet och översvämma servern med vatten.
Vi lämnade några tips om projektets Github: nämligen tokengenereringskoden, från vilken man kunde förstå att test- och stridstokenen genereras baserat på samma räknarindikator. När det gäller en stridstoken används förutom motvärdet också ett salt, som nästan helt finns kvar i historien om att ändra denna kärna, med undantag för de två sista tecknen.
Genom att känna till dessa data var det möjligt att sortera igenom de två sista symbolerna i saltet och faktiskt ta reda på att siffrorna från Lost, omvandlade till det hexadecimala systemet, användes för det.
Sedan var spelarna tvungna att fånga räknarvärdet (genom att analysera testtoken) och generera en stridstoken med hjälp av nästa räknarvärde och saltet som valdes i föregående steg.
Räknaren steg helt enkelt med varje testskott och var 25:e sekund. Vi skrev inte om det här någonstans, det var tänkt att vara en liten spelöverraskning.
Captcha-interaktionstjänst
I spelvärlden var detta samma captcha som måste laddas för att kunna slå på fläkten och öppna blädderblocket med en hint. Bredvid kameran stod en bärbar dator med belastningsövervakning.
Jag beräknade vad som skulle visas i övervakningen som aktuell belastning: temperatur och CPU-fläkt. Mätvärden överfördes till tidsbasdatabasen och ritades med grafana.
Om det under de senaste 5 sekunderna fanns mer än 50 förfrågningar om att visa captcha, ökade belastningen med ett fast + slumpmässigt antal steg. Beräkningen var att 100 % belastning kunde uppnås på två minuter.
Faktum är att det fanns mer logik i tjänsten än vad som visades i det sista spelet: vi placerade bildskärmen på ett sådant sätt att endast rotationen av CPU-fläkten var synlig.
I början av uppdraget ville de lämna Grafan tillgänglig från Falcons webbplats. Men den innehöll också springboot-mått från backend-applikationsrapporten, som vi inte hade tid att rensa, så vi bestämde oss för att blockera åtkomst till den. Och med rätta - även i början av uppdraget gissade vissa spelare att applikationen var skriven i springboot-ramverket och till och med grävde fram namnen på vissa tjänster.
Hosting och databuss
Ett verktyg för att överföra information från backend till webbplatsen, VPS-servern som RabbitMQ kördes på.
Backend och databussen hölls på . Dess kraft var jämförbar med datorn du såg på skärmen: en 2-kärnig VPS med två gigabyte RAM. Tariffen debiterades för resurser, eftersom toppbelastningen var planerad för bara några dagar - det är vad våra kunder gör som planerar att ladda VPS under en kort period. Då visade det sig att belastningen var högre än vi räknat med, och en fast taxa skulle vara mer lönsam. Om du gör ett uppdrag, välj linjetariffer .
För att skydda servern från DDoSa använde vi Cloudflare.
Det är värt att säga att VPS stod emot allt med ära.
Arduino, som ansvarade för att styra reläerna, fick kommandon från översättaren och gjorde själva arbetet
Detta är mer ämnet för nästa artikel om hårdvarudelen av projektet: backend skickade helt enkelt förfrågningar om att slå på ett specifikt relä. Det hände så att backend kände till nästan alla enheter och förfrågningar från den såg ut som "slå på den här enheten." Vi gjorde detta för tidig testning av sajten (vi hade ännu inte satt ihop alla Arduino och reläer), till slut lämnade vi allt så.
Frontend
Vi skapade snabbt sajten på tilde, det tog en arbetsdag och sparade oss 30 tusen på vår budget.
Från början tänkte vi helt enkelt exportera webbplatsen och lägga till logiken vi saknade, men vi stötte på användarvillkor som förbjöd oss att göra detta.
Vi var inte redo att bryta mot licensen, så det fanns två alternativ: att implementera allt själva eller att kontakta Tilda direkt, prata om projektet och be om lov att ändra koden.
Vi valde det andra alternativet och de mötte oss inte bara halvvägs, utan gav oss till och med ett års gratis affärskonto, vilket vi är mycket tacksamma mot dem. Det var väldigt besvärligt att visa dem Sokols webbdesign.
Som ett resultat kopplade vi js-logik till frontend för att skicka förfrågningar till elementära enheter, och ändrade lite stilen på knapparna för att slå på och av spelelement.
Webbplatsdesign
Sökningarnas historia, som är värd ett separat kapitel.
Vi ville skapa inte bara en gammaldags sida, utan en helt äcklig sådan som bryter mot alla grundläggande regler för design. Samtidigt var det viktigt att upprätthålla trovärdigheten: den behövde inte bryta ENT-historien, visa upphovsmannens pretentiöshet, och spelarna skulle behöva tro att en sådan sida kunde existera och till och med ge kunder. Och han kom med den! Medan spelet pågick blev vi kontaktade två gånger för att skapa webbplatser.
Först gjorde jag designen själv och försökte inkludera fler gifs och glänsande element. Men min designerman under 10 år tittade sig över axeln och avfärdade det som "för bra". För att bryta designregler måste du känna till dem.
Det finns flera färgkombinationer som framkallar en bestående känsla av avsky: grönt och rött av lika rikedom, grått och rosa, blått plus brunt. Till slut bestämde vi oss för en kombination av rött och grönt som basfärger, la till gifs med en katt och valde ut 3-4 bilder på Sokolov själv från en bild. Jag hade bara några krav: en medelålders man, klädd i en illasittande kostym ett par storlekar för stor och i en "professionell studiofotografering". För testet visade de det för vänner och frågade "hur gillar du det?"
Under designutvecklingsprocessen var min man tvungen att lägga sig ner varje halvtimme, helikoptern började flyga. Pasha försökte öppna utvecklarkonsolen till större delen av skärmen medan han avslutade frontend - för att skydda ögonen.
Faktiska enheter
Fläktarna och lamporna monterades genom halvledarreläer så att de inte skulle slå på med full effekt direkt – så att effekten skulle öka parallellt med övervakningen.
Men vi kommer att prata om detta i nästa inlägg, om hårdvarudelen av spelet och själva konstruktionen av sajten.
Håll dig igång!
Andra artiklar om strävan att förstöra servern
Källa: will.com