Skadekortet

Skadekortet

> Programmering

Med evalueringen af bevægelser og styringen af angrebskombinationer er skadeskortet en stor vigtighed i LeekWars. Hovedformålet er at kunne vurdere, afhængigt af modstanderen, et fareniveau for hver boks for at kunne trække sig tilbage til en boks med mindre fare ved slutningen af svinget. Den nemmeste måde er at oprette et associativt array: dangerMap=[ celle1:danger1 , cell2:danger2 , ... ], muligvis begrænset til dine tilgængelige celler. Til dette formål er flere algoritmer mulige

Den "naive" algoritme

Dette er normalt den første idé, der kommer til at tænke på, når du opretter en farevurderingsalgoritme. Ideen er følgende:

/* -for hver af mine tilgængelige celler

• for hver modstander

-for hver tilgængelig celle hos modstanderen -for hver modstanders våben -hvis han kan skyde min celle fra sin celle tilføje en "danger score" til min celle */

Valget af score er en integreret del af din algoritme: du kan sætte "+1" i den, eller beregne skaden, der potentielt er påført, ... Der er lige så mange måder at forfine denne evaluering, som der er spillere 😉

Det store problem med denne algoritme er, at den er ekstremt grådig i driften! Det er derfor generelt nødvendigt at optimere det meget hurtigt.

Optimeringsspor

Det første du skal gøre er at forhindre din porre i at "crash"... Så du skal et sted i koden lave en test på getOperations() og afslutte loops, hvis antallet af operationer kommer for tæt på grænsen: du vil kun have en delvis vurdering af faren, men din porre vil stadig kunne bevæge sig et minimum 😉

For selve optimeringen er et af de første principper, der bør styre din tilgang, frem for alt at undgå at gentage de samme operationer flere gange i løkkerne: det er bedre i dette tilfælde at forberede tingene i tabeller, så husk. Så, for eksempel, i den inderste løkke, der beregner "danger score", hvis du sætter et kald til getStrength(Enemy) i den, vil du kalde den funktion tilbage tusindvis af gange. Ideen er så kun at beregne fjendens styrke én gang og gemme den i en variabel før de interne loops udføres. Du vil allerede begynde at tjene et par hundrede tusinde handler! Så jagt efter elementer af "interne" loops, der ikke afhænger af loop-variablen, men kun på en "ekstern" loop: du kan derefter spore disse elementer tilbage til deres loop.

Hvis din algoritme forbliver dyr, er en anden ret æstetisk mulighed for optimering at nedgradere opløsningen af denne evaluering. Du kan for eksempel ikke teste alle de tilgængelige felter (dine og/eller modstanderens), men for eksempel kun dem, der kræver et lige antal bevægelsespoint. Det "er tilstrækkeligt" så at udfylde hullerne opnået ved interpolation af værdierne på nabokvadraterne (middelværdi af naboer, maksimum af naboer, maksimum af middelværdi mellem to linjer osv.). Denne tilgang er mindre nøjagtig, men med eksemplet med selv PM'er bruger den omkring 4x mindre end den første algoritme.

For at fortsætte optimeringerne bliver du nødt til at tænke på at forudberegne ting, normalt i første runde, at lagre visse ting i store (eller mange) arrays, som du skal genberegne, og som aldrig ændres, eller endda opdatere visse værdier hver tur (i vores eksempel styrken af fjendens porrer).

"én gang for alle"-algoritmen

Denne algoritme forudberegner et farekort én gang i starten af kampen. Billig, det er meget mindre præcist, men giver dig mulighed for hurtigt at få listen over områder på kampkortet, der generelt er farlige. Det består i at evaluere, ved starten af vendingen, for hver celle på kampkortet, alle de celler, der giver dig mulighed for at skyde på den med de våben, som fjenden/fjenderne har: en firkant, der kun kan nås fra 5. andre felter vil så have en score meget lavere end en firkant, der kan nås af 200 andre felter! Det kan være klogt at forsøge at trække sig tilbage til områder med lav fare, og få fjenden til at blive i områder med høj fare.