Skadekartet

> Programmering

Med evaluering av bevegelser og håndtering av angrepskombinasjoner, er skadekartet en viktig del av LeekWars. Hovedmålet er å kunne vurdere, avhengig av motstanderen, et farenivå for hver boks for å kunne trekke seg tilbake til en boks med mindre fare ved slutten av svingen. Den enkleste måten er å lage en assosiativ matrise: dangerMap=[ celle1:danger1 , cell2:danger2 , ... ], muligens begrenset til dine tilgjengelige celler. For dette formålet er flere algoritmer mulige

Den "naive" algoritmen

Dette er vanligvis den første ideen du tenker på når du lager en farevurderingsalgoritme. Tanken er følgende:

/* -for hver av mine tilgjengelige celler

for hver motstander

-for hver tilgjengelig celle til motstanderen -for hver motstanders våpen -hvis han kan skyte cellen min fra cellen sin legge til en "danger score" til cellen min */

Valget av poengsum er en integrert del av algoritmen din: du kan sette "+1" i den, eller beregne skaden som potensielt er påført, ... Det er like mange måter å avgrense denne evalueringen på som det er spillere 😉

Det store problemet med denne algoritmen er at den er ekstremt grådig i operasjoner! Det er derfor generelt nødvendig å optimalisere den veldig raskt.

Optimaliseringsspor

Det første du må gjøre er å forhindre purren din fra å "krasj"... Så du må, et sted i koden, gjøre en test på getOperations() og avslutte looper hvis antall operasjoner kommer for nærme grensen: du vil bare ha en delvis vurdering av faren, men purren din vil fortsatt kunne bevege seg et minimum 😉

For selve optimaliseringen er et av de første prinsippene som bør lede tilnærmingen din fremfor alt å unngå å gjenta de samme operasjonene flere ganger i løkkene: det er bedre i dette tilfellet å forberede ting i tabeller og deretter huske. Så, for eksempel, i den innerste løkken som beregner "farepoengsummen", hvis du setter et kall til getStrength(Enemy) i den, vil du kalle den funksjonen tilbake tusenvis av ganger. Tanken er da å beregne fiendens styrke bare én gang og lagre den i en variabel før de interne løkkene utføres. Du vil allerede begynne å tjene noen hundre tusen handler! Så jakt på elementer av "interne" looper som ikke er avhengige av loop-variabelen, men bare på en "ekstern" loop: du kan deretter spore disse elementene tilbake til deres loop.

Hvis algoritmen din forblir dyr, er en annen ganske estetisk mulighet for optimalisering å nedgradere oppløsningen til denne evalueringen. Du kan for eksempel ikke teste alle de tilgjengelige rutene (dine og/eller motstanderens), men for eksempel bare de som krever et jevnt antall bevegelsespoeng. Det "strekker" da å fylle ut hullene oppnådd ved interpolering av verdiene på naborutene (gjennomsnitt av naboene, maksimum av naboene, maksimum av gjennomsnittet mellom to linjer, etc.). Denne tilnærmingen er mindre nøyaktig, men, med eksemplet med jevne PM-er, bruker den omtrent 4 ganger mindre enn den første algoritmen.

For å fortsette optimaliseringene, må du tenke på å forhåndsberegne ting, vanligvis i første runde, lagre i store (eller mange) arrays visse ting som du må beregne på nytt og som aldri endres, eller til og med oppdatere visse verdier hver sving (i vårt eksempel styrken til fiendtlige purre).

"en gang for alle"-algoritmen

Denne algoritmen forhåndsberegner et farekart én gang ved starten av kampen. Billig, det er mye mindre presist, men lar deg raskt ha listen over områder på kampkartet som generelt er farlige. Den består i å evaluere, ved starten av svingen, for hver celle på kampkartet, alle cellene som lar deg skyte på den med våpnene som fienden(e) har: en firkant som kun kan nås fra 5 andre ruter vil da ha en poengsum som er mye lavere enn en rute som kan nås av 200 andre ruter! Det kan være lurt å prøve å trekke seg tilbake til områder med lav fare, og få fienden til å holde seg i områder med høy fare.