Spil på Rust på 24 timer: personlig erfaring med udvikling

I denne artikel vil jeg dele min personlige erfaring med at udvikle et lille spil på Rust. Det tog cirka 24 timer at skabe en fungerende version (primært arbejdede jeg om aftenen eller i weekenden). Spillet er stadig langt fra færdigt, men jeg tror, at erfaringen vil være nyttig. Jeg vil fortælle, hvad jeg har lært, og nogle observationer, jeg har gjort under opbygningen af spillet fra bunden.

Skillbox anbefaler: Toårigt praktisk kursus «Jeg er webudvikler PRO».

Vi minder om: til alle læsere af 'Habr' — rabat på 10.000 rubler ved tilmelding til et hvilket som helst Skillbox-kursus med rabatkoden 'Habr'.

Hvorfor Rust?

Jeg valgte dette sprog, fordi jeg havde hørt meget godt om det, og jeg kan se, at det bliver mere og mere populært inden for spiludvikling. Før jeg begyndte at skrive spillet, havde jeg en smule erfaring med at udvikle simple applikationer på Rust. Det var lige nok til at føle en vis frihed under udviklingen af spillet.

Hvorfor netop et spil, og hvad for et spil?

At skabe spil er sjovt! Jeg ville ønske, at der var flere grunde, men til «hjemmeprojekter» vælger jeg emner, der ikke er for tæt forbundet med mit sædvanlige arbejde. Hvad for et spil? Jeg ville gerne lave noget i stil med en tennissimulator, hvor der kombineres Cities Skylines, Zoo Tycoon, Prison Architect og selvfølgelig tennis. Samlet set blev det et spil om en tennisklub, hvor folk kommer for at spille.

Teknisk forberedelse

Jeg ville gerne bruge Rust, men jeg vidste ikke præcis, hvor meget jeg skulle starte ‘fra bunden’. Jeg ønskede ikke at skrive pixel-shaders og bruge drag-n-drop, så jeg søgte efter de mest fleksible løsninger.

Jeg fandt nyttige ressourcer, som jeg vil dele med dig:

• Are we game yet — en liste over nødvendige elementer til spiludvikling i Rust;
• Rust game dev subreddit;
• Gratis pixel-art.

Jeg har undersøgt flere Rust spillemotorer og valgte til sidst Piston og ggez. Jeg stødte på dem, da jeg arbejdede på et tidligere projekt. Til sidst valgte jeg ggez, da det syntes mere passende til implementeringen af et lille 2D-spil. Den modulære struktur af Piston er for kompleks til en ny udvikler (eller en, der arbejder med Rust for første gang).

Spilstruktur

Jeg brugte lidt tid på at overveje projektets arkitektur. Første skridt er at lave ‘jorden’, menneskerne og tennisbanerne. Folk skal bevæge sig rundt på banerne og vente. Spillerne skal have færdigheder, der forbedres over tid. Desuden skal der være en editor, der tillader tilføjelse af nye mennesker og baner, men det er ikke gratis.

Efter at have gennemtænkt alt, gik jeg i gang med arbejdet.

Oprettelse af spil

Begyndelse: cirkler og abstraktioner

Jeg tog et eksempel fra ggez og fik en cirkel på skærmen. Fantastisk! Nu lidt abstraktioner. Jeg syntes, det ville være godt at abstrahere fra ideen om et spilleobjekt. Hvert objekt skal rendres og opdateres som beskrevet 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 kode gjorde det muligt for mig at få en fantastisk liste over objekter, som jeg kan opdatere og rendere i en lige så fantastisk loop.

mpl event::EventHandler for MainState {
    fn update(&mut self, context: &mut Context) -> GameResult {
        // Opdater 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 den indeholder alle kodelinjer. Jeg brugte lidt tid på at opdele filer og optimere mappestrukturen. Sådan så alt ud efterfølgende:
resources -> her er alle aktiverne (billeder)
src
— entities
— game_object.rs
— circle.rs
— main.rs -> hovedløkke

Personer, etager og billeder

Næste skridt er at oprette spilleobjektet Person og indlæse billeder. Alt skal bygges på fliser, der er 32*32.

Tennisbaner

Efter at have studeret, hvordan tennisbaner ser ud, besluttede jeg at lave dem af fliser 4*2. Oprindeligt kunne man lave et billede af denne størrelse eller samle 8 separate fliser. Men senere indså jeg, at der kun var brug for to unikke fliser, og her er hvorfor.

Vi har i alt to sådanne fliser: 1 og 2.

Hver sektion af banen består af flise 1 eller flise 2. De kan være normalt placeret eller væltet 180 grader.

Hovedbygningsmodellen (samlingen)

Efter at have opnået rendering af banerne, folkene og kortene, indså jeg, at jeg også havde brug for en grundlæggende samlingsmode. Jeg implementerede det således: når knappen er trykket på - objektet er valgt, og klikker placerer det på det ønskede sted. Så knap 1 giver mulighed for at vælge banen, mens knap 2 tillader at vælge spilleren.

Men man skal også huske, hvad 1 og 2 betyder, derfor tilføjede jeg et wireframe for at gøre det klart, hvilket objekt der er valgt. Sådan ser det ud.

Spørgsmål om arkitektur og refactoring

Nu har jeg flere spilelementer: mennesker, baner og etager. Men for at wireframes skal fungere, skal hver objekts entitet informeres om, hvorvidt selve objekterne er i demonstrationsmodus, eller om der blot er tegnet en ramme. Det er ikke særlig praktisk.

Jeg syntes, det var nødvendigt at gentænke arkitekturen, så nogle begrænsninger kunne fremhæves:

• tilstedeværelsen af en entitet, der viser og opdaterer sig selv, er et problem, da denne entitet ikke kan 'vide', hvad den skal gengive - billede og wireframe;
• manglen på et værktøj til at udveksle egenskaber og adfærd mellem individuelle entiteter (f.eks. egenskaben is_build_mode eller gengivelse af adfærd). Man kunne have brugt inheritance, selvom der ikke er nogen ordentlig måde at implementere det på i Rust. Hvad jeg virkelig havde brug for, var sammensætning;
• et værktøj til at interagere mellem entiteter var nødvendigt for at tildele mennesker til banerne;
• selve entiteterne var en blanding af data og logik, hvilket hurtigt kom ud af kontrol.

Jeg foretog en yderligere undersøgelse og opdagede arkitekturen ECS - Entity Component System, som normalt anvendes i spil. Her er fordelene ved ECS:

• data er adskilt fra logik;
• komposition i stedet for arv;
• dataorienteret arkitektur.

ECS er kendetegnet ved tre grundlæggende koncepter:

• entiteter - en type objekt, som en identifikator refererer til (det kan være en spiller, en bold eller noget andet);
• komponenter - som entiteterne består af. Eksempel - en rendering komponent, placering, og andre. Dette er datalagre;
• systemer - de bruger både objekter og komponenter, plus indeholder adfærd og logik baseret på disse data. Eksempel - et renderingssystem, der itererer over alle entiteter med komponenter til rendering og håndterer gengivelsen.

Efter undersøgelsen blev det klart, at ECS løser sådanne problemer:

• anvendelsen af komposition i stedet for arv til systematisk organisering af entiteter;
• fjernelse af kodekaos ved hjælp af kontrolsystemer;
• brug af metoder som is_build_mode til at opbevare logikken for wireframe på ét sted - i renderingssystemet.

Her er, hvad der kom ud af implementeringen af ECS.

resources -> her er alle aktiverne (billeder)
src
— components
— position.rs
— person.rs
— tennis_court.rs
— floor.rs
— wireframe.rs
— mouse_tracked.rs
— resources
— mouse.rs
— systems
— rendering.rs
— constants.rs
— utils.rs
— world_factory.rs -> verdens fabriksfunktioner
— main.rs -> hovedløkke

Tildeler folk til banerne

ECS har gjort livet nemmere. Nu havde jeg en systematisk måde at tilføje data til enhederne og tilføje logik baseret på disse data. Dette gjorde det muligt at organisere fordelingen af folk til banerne.

Hvad jeg har gjort:

• tilføjet data om tildelte baner til Person;
• tilføjet data om fordelte personer til TennisCourt;
• tilføjet CourtChoosingSystem, der analyserer folk og steder, opdager ledige baner og fordeler spillere til dem;
• tilføjet PersonMovementSystem, der leder efter personer, der er tildelt til banerne, og hvis de ikke er der, sender folk derhen, hvor de skal være.

Sammenfatning

Jeg nød virkelig at arbejde på dette enkle spil. Desuden er jeg glad for, at jeg brugte Rust til at skrive det, fordi:

• Rust giver dig det, du har brug for;
• den har fremragende dokumentation, Rust er meget elegant;
• konstanten er fantastisk;
• jeg behøver ikke at ty til kloning, kopiering eller lignende handlinger, som jeg ofte gjorde i C++;
• Options er meget praktiske at arbejde med, de håndterer også fejl fremragende;
• hvis projektet kunne kompilere, så fungerer det i 99%, og præcis som det skal. Kompilationsfejlmeddelelserne er efter min mening de bedste, jeg har set.

Spiludvikling på Rust er kun lige begyndt. Men der er allerede et stabilt og ret stort fællesskab, der arbejder på at gøre Rust tilgængelig for alle. Derfor ser jeg optimistisk på fremtiden for sproget og ser frem til resultaterne af vores fælles arbejde.

Skillbox anbefaler:

• Online kursus «Frontend Developer Profession».
• Praktisk kursus «Mobil udvikler PRO».
• Praktisk års kursus "PHP-udvikler fra 0 til PRO".

Kilde: habr.com