Koncept

Dentagra blev udviklet som et gymnasialt eksamensprojekt ud fra temaet 'online-multiplayer'. Spillet består principielt af 2 faser: Builder Mode og Player vs. Player Mode. I Builder Mode kan den enkelte spiller uforstyrret designe sin fæstning ud fra de ressourcer de har til rådighed. I PvP Mode dyster 2 spillere mod hinanden om at være den første til at infiltrere modstanderens base, finde deres flag og bringe det til den sikre zone.
Med opgavens mål for øje valgte vi at fokusere på PvP-fasen.

Arkitektur

Projektet består af 3 dele: Client, Matchmaking Server og Game Server. Client er den brugervendte frontend. Matchmaking Serveren agerer gateway, og er ansvarlig for at parre spillere og viderestille dem til en Game Server. De enkelte Game Servere har ansvar for at facilitere de igangværende matches, som den er blevet tildelt af Matchmaking Serveren. Systemet kan skaleres op ved at tilføje flere Game Servere.

Teknologi

Både Client og Game Server er implementeret i Godot Engine - primært i det Python-lignende GDScript. Det gjorde det muligt at udnytte det indbyggede RPC-baserede 'High-level multiplayer' system.
Matchmaking Server er skrevet i Python og kommunikerer igennem WebSocket-Secure protokollen.

skjul

Case

En server, A, leverer vejrdata fra 5 forskellige steder i Anchorage, Alaska med hver sit end-point. Dataene leveres i CSV-format med lokale timestamps. Nyt data udgives hvert minut, men det præcise øjeblik varierer fra gang til gang, samtidig med at den har et ganske konservativt rate-limit. Serveren er tilmed utilregnelig, og der er ingen garanti for at dataene er velformaterede.
Opgaven lyder herpå at udvikle en service, der genformidler disse data ved at sende dem til en server, B, i et givet JSON-format med UTC-timestamps. Dette skal naturligvis ske så konsekvent som muligt, med så lav forsinkelse som overhovedet muligt.

Polling-strategi

Vi valgte at tage den ekstra udfordring at implementere vores løsning i F#-sproget uden tidligere erfaring. Freyr udnytter F#'s async-features til at køre polling'en af hvert end-point på sin egen selvjusterende timer.
Timing-strategien er pragmatisk baseret på en analyse af A's opførsel, hvor udgivelsen af nye data fandtes til at falde indenfor visse trin. På den måde lykkedes det konsekvent at opnå en forsinkelse på under 600ms - ikke udsædvanligt i nærheden af de 200ms tilsvarende netværksforsinkelsen af en enkelt request i sig selv.

skjul

Formål

I forbindelse med SOP (StudioOmrådeProjekt) undersøgte jeg SHA-256, som er en kryptografisk hashfunktion brugt i alt fra SSL-certifikater til Bitcoin-transaktioner.
En god kryptografisk hashfunktion er bl.a. karakteriseret ved at den er svær at forudsige, og selv en lille ændring i inputtet burde resultere i et helt andet output.
χ2-testen kan bruges til at kvantificere dette, ved at opdele outputværdierne i en række intervaller, og praktisk set sammenligne antallet i hver kategori med et forventet antal.

Implementering

• compute_hashes.py står for at beregne SHA-256 hashværdierne for en række nærtliggende inputværdier, inddele dem i en hyppighedstabel bestående af 2¹⁶ = 65.536 forskellige intervaller og skrive den til en fil når scriptet afbrydes. Det er yderligere indrettet til automatisk at fortsætte fra den sidst evaluerede værdi når det startes igen.
• inspector.py bruges eventuelt til overfladisk at inspicere dataene.
• chi_square.py analyserer hyppighedstabellens afvigelser og sammenholder dem med den acceptable værdi.

skjul