Spill på Rust på 24 timer: personlig utviklingserfaring

I denne artikkelen vil jeg dele min personlige erfaring med utviklingen av et lite spill i Rust. Det tok omtrent 24 timer å lage en fungerende versjon (jeg jobbet hovedsakelig om kveldene eller i helgene). Spillet er fortsatt langt fra ferdig, men jeg mener erfaringen vil være nyttig. Jeg vil fortelle hva jeg har lært og om noen observasjoner jeg har gjort mens jeg bygde spillet fra bunnen av.

Skillbox anbefaler: Toårig praktisk kurs «Jeg er PRO webutvikler».

Vi minner om: for alle lesere av «Habr» — 10 000 rubler rabatt ved påmelding til hvilket som helst Skillbox-kurs med kampanjekoden «Habr».

Hvorfor Rust?

Jeg valgte dette språket fordi jeg har hørt mye positivt om det og ser at det blir stadig mer populært innen spillutvikling. Før jeg begynte med spillet, hadde jeg noe erfaring med å utvikle enkle applikasjoner i Rust. Dette var akkurat nok til å føle en viss frihet mens jeg skrev spillet.

Hvorfor spill og hvilket spill?

Å lage spill er gøy! Jeg skulle ønske det var flere grunner, men for «hjemme» prosjekter velger jeg temaer som ikke er alltför nært knyttet til min vanlige jobb. Hvilket spill? Jeg ønsket å lage noe som lignet på en tennissimulator, hvor Cities Skylines, Zoo Tycoon, Prison Architect og selve tennis blandes. Totalt sett ble det et spill om en tennisskole der folk kommer for å spille.

Teknisk forberedelse

Jeg ønsket å bruke Rust, men jeg visste ikke nøyaktig hvor mye jeg måtte begynne fra «bunnen» av. Jeg ville ikke skrive pikselshadere eller bruke dra-og-slipp, så jeg lette etter de mest fleksible løsningene.

Jeg fant nyttige ressurser som jeg deler med deg:

• Are we game yet — en liste over nødvendige elementer for spillutvikling i Rust;
• Rust game dev subreddit;
• Gratis pikselkunst.

Jeg utforsket flere spillmotorer i Rust og endte til slutt opp med Piston og ggez. Jeg hadde støtt på dem da jeg jobbet med et tidligere prosjekt. Til slutt valgte jeg ggez fordi det virket mer passende for å lage et lite 2D-spill. Den modulære strukturen i Piston er for komplisert for en nybegynner (eller for de som jobber med Rust for første gang).

Spillstrukturen

Jeg brukte litt tid på å tenke over prosjektets arkitektur. Det første steget er å lage «jorden», folk og tennisbaner. Folk skal bevege seg rundt på banene og vente. Spillerne skal ha ferdigheter som forbedres over tid. I tillegg bør det være en redaktør som lar deg legge til nye folk og baner, men det er ikke gratis.

Etter å ha tenkt over alt, begynte jeg arbeidet.

Spilling av spillet

Start: sirkler og abstraksjoner

Jeg tok et eksempel fra ggez og fikk en sirkel på skjermen. Fantastisk! Nå litt abstraksjoner. Jeg mente det var en god idé å abstrahere fra tanken om et spillobjekt. Hvert objekt må bli gjengitt og oppdatert, som angitt her:

// the game object trait
trait GameObject {
    fn update(&mut self, _ctx: &mut Context) -> GameResult<()>;
    fn draw(&mut self, ctx: &mut Context) -> GameResult<()>;
}
 
// a specific game object - Circle
struct Circle {
    position: Point2,
}
 
 impl Circle {
    fn new(position: Point2) -> Circle {
        Circle { position }
    }
}
impl GameObject for Circle {
    fn update(&mut self, _ctx: &mut Context) -> GameResult<()> {
        Ok(())
    }
    fn draw(&mut self, ctx: &mut Context) -> GameResult<()> {
        let circle =
            graphics::Mesh::new_circle(ctx, graphics::DrawMode::Fill, self.position, 100.0, 2.0)?;
 
         graphics::draw(ctx, &circle, na::Point2::new(0.0, 0.0), 0.0)?;
        Ok(())
    }
}

Denne koden ga meg en flott liste over objekter jeg kan oppdatere og gjengi i en minst like flott løkke.

mpl event::EventHandler for MainState {
    fn update(&mut self, context: &mut Context) -> GameResult {
        // Oppdater alle objekter
        for object in self.objects.iter_mut() {
            object.update(context)?;
        }
 
        Ok(())
    }
 
    fn draw(&mut self, context: &mut Context) -> GameResult {
        graphics::clear(context);
 
        // Tegn alle objekter
        for object in self.objects.iter_mut() {
            object.draw(context)?;
        }
 
        graphics::present(context);
 
        Ok(())
    }
}

main.rs er nødvendig fordi det inneholder alle kodebitene. Jeg brukte litt tid på å dele opp filene og optimalisere mappestrukturen. Her er hvordan alt så ut etter dette:
resources -> dette er hvor alle ressursene er (bilder)
src
— enheter
— game_object.rs
— circle.rs
— main.rs -> hovedløkken

Mennesker, baner og bilder

Neste steg er å lage spillobjektet Person og laste opp bilder. Alt må bygges på 32*32 fliser.

Tennisbaner

Etter å ha sett hvordan tennisbaner ser ut, bestemte jeg meg for å lage dem med 4*2 fliser. Jeg kunne opprinnelig lage et bilde av den størrelsen eller sette sammen 8 separate fliser. Men så innså jeg at bare to unike fliser er nødvendige, og her er hvorfor.

Vi har totalt to slike fliser: 1 og 2.

Hver seksjon av banen består av flis 1 eller flis 2. De kan plasseres vanlig eller være snudd 180 grader.

Grunnleggende bygge-modus

Etter å ha fått til gjengivelsen av baner, mennesker og kart, forstod jeg at vi også trenger en grunnleggende byggemodus. Jeg implementerte det slik: når knappen trykkes, blir objektet valgt, og et klikk plasserer det på riktig sted. Dermed lar knapp 1 oss velge banen, mens knapp 2 lar oss velge spilleren.

Men vi må også huske hva 1 og 2 betyr, så jeg la til et wireframe for å vise hvilket objekt som er valgt. Slik ser det ut.

Spørsmål om arkitektur og refaktorering

Nå har jeg flere spillobjekter: mennesker, baner og etasjer. Men for at rammeverkene skal fungere, må hver objekt enhet informere om de selv er i demonstrasjonsmodus eller om det bare er et rammeverk tegnet. Det er ikke veldig praktisk.

Jeg følte at det var nødvendig å revurdere arkitekturen slik at noen begrensninger ble avslørt:

• tilstedeværelsen av en enhet som viser og oppdaterer seg selv er et problem, siden denne enheten ikke vil kunne «vite» hva den skal rendere — bilde og rammeverk;
• mangel på et verktøy for utveksling av egenskaper og atferd mellom separate enheter (for eksempel egenskapen is_build_mode eller rendering av atferd). Man kunne ha brukt arv, selv om Rust ikke har en ordentlig måte å implementere det på. Det jeg virkelig trengte var komposisjon;
• et verktøy for interaksjon mellom enheter var nødvendig for å tilordne mennesker til baner;
• selve enhetene bestod av en blanding av data og logikk, noe som raskt kom ut av kontroll.

Jeg gjorde en ekstra studie og oppdaget arkitekturen ECS — Entity Component System, som vanligvis brukes i spill. Her er fordelene med ECS:

• data er adskilt fra logikk;
• komposisjon i stedet for arv;
• dataorientert arkitektur.

For ECS er tre grunnleggende konsepter karakteristiske:

• enheter — en type objekt som henvises til av en identifikator (dette kan være en spiller, en ball, eller noe annet);
• komponenter — de som enhetene består av. For eksempel — renderingskomponent, plassering og andre. Dette er datalagre;
• systemer — de bruker både objektene og komponentene, og inneholder atferd og logikk som er basert på disse dataene. For eksempel — et renderingssystem som går gjennom alle enheter med komponenter for rendering og håndterer tegning.

Etter studien ble det klart at ECS løser slike problemer:

• bruk av komposisjon i stedet for arv for systematisk organisering av enheter;
• fjerning av kodehermetikk gjennom styringssystemer;
• bruk av metoder som is_build_mode for å lagre rammeverkatferd på ett og samme sted - i renderingssystemet.

Slik ble det etter implementeringen av ECS.

resources -> dette er hvor alle ressursene er (bilder)
src
— komponenter
— position.rs
— person.rs
— tennis_court.rs
— floor.rs
— wireframe.rs
— mouse_tracked.rs
— ressurser
— mouse.rs
— systemer
— rendering.rs
— constants.rs
— utils.rs
— world_factory.rs -> world factory functions
— main.rs -> hovedløkken

Vi har tildelt folk til banene

ECS har gjort livet enklere. Nå hadde jeg en systemisk måte å legge til data til enheter og legge til logikk basert på disse dataene. Dette har igjen gjort det mulig å organisere tildelingen av folk til banene.

Hva jeg gjorde:

• la til data om tildelte baner i Person;
• la til data om fordelte personer i TennisCourt;
• la til CourtChoosingSystem som lar analysere folk og fasiliteter, oppdage tilgjengelige baner og fordele spillere til dem;
• la til PersonMovementSystem som finner personer tildelt til banene, og hvis de ikke er der, sender dem dit de trenger å være.

Oppsummering

Jeg likte veldig godt å jobbe med dette enkle spillet. Dessuten er jeg fornøyd med at jeg brukte Rust til å skrive det, fordi:

• Rust gir deg det du trenger;
• det har utmerket dokumentasjon, Rust er ganske elegant;
• konstans er kult;
• jeg trenger ikke å ty til kloning, kopiering eller andre lignende handlinger, som jeg ofte gjorde i C++;
• Options er veldig praktiske å jobbe med, de håndterer også feil på en utmerket måte;
• hvis prosjektet klarte å kompilere, så fungerer det i 99% av tilfellene, nøyaktig slik det skal. Kompilatork feilmeldinger er, etter min mening, de beste jeg har sett.

Spillutvikling på Rust er bare i gang. Men det finnes allerede et stabilt og ganske stort fellesskap som jobber med å åpne Rust for alle. Derfor ser jeg optimistisk på framtiden for språket, og ser frem til resultatene av vårt felles arbeid.

Skillbox anbefaler:

• Nettkurs «Frontend-utvikler».
• Praktisk kursus «Mobiludvikler PRO».
• Praktisk ettårig kurs «PHP-utvikler fra 0 til PRO».

Kilde: habr.com