Spelande i Rust på 24 timmar: personlig erfarenhet av utveckling

I den här artikeln kommer jag att berätta om min personliga erfarenhet av att utveckla ett litet spel i Rust. Det tog ungefär 24 timmar att skapa en fungerande version (för det mesta arbetade jag på kvällar eller helger). Spelet är fortfarande långt ifrån klart, men jag tror att erfarenheten kommer att vara användbar. Jag kommer att dela med mig av vad jag har lärt mig och några observationer som jag har gjort under byggandet av spelet från grunden.

Skillbox rekommenderar: Tvåårig praktisk kurs „Jag är en PRO webbutvecklare“.

Påminnelse: för alla läsare av "Habr" — 10 000 rubel rabatt vid registrering för vilken kurs som helst på Skillbox med rabattkoden "Habr".

Varför Rust?

Jag valde detta språk eftersom jag har hört mycket bra om det och ser att det blir alltmer populärt inom spelutveckling. Innan jag skrev spelet hade jag lite erfarenhet av att utveckla enkla program i Rust. Det var precis tillräckligt för att känna en viss frihet när jag skrev spelet.

Varför just spel och vilket spel?

Att skapa spel är roligt! Jag skulle vilja ha fler skäl, men för „hemma“ projekt väljer jag ämnen som inte är för nära kopplade till mitt vanliga arbete. Vilket spel? Jag ville göra något som en tennissimulator där Cities Skylines, Zoo Tycoon, Prison Architect och egen tennis blandas. I allmänhet blev det ett spel om en tennisklubb där människor kommer för att spela.

Teknisk förberedelse

Jag ville använda Rust, men jag visste inte exakt hur mycket jag behövde börja från „grunden“. Jag ville inte skriva pixel-shaders eller använda drag-n-drop, så jag letade efter de mest flexibla lösningarna.

Jag har hittat användbara resurser som jag delar med er:

• Are we game yet — en lista över nödvändiga Rust-element för spelutveckling;
• Rust game dev subreddit;
• Gratis pixelkonst.

Jag studerade flera Rust-spelmotorer och valde till slut Piston och ggez. Jag hade stött på dem när jag arbetade med mitt tidigare projekt. I slutändan valde jag ggez eftersom det verkade mer lämpligt för att skapa ett litet 2D-spel. Den modulära strukturen i Piston är för komplicerad för en nybörjare (eller någon som arbetar med Rust för första gången).

Spelstruktur

Jag spenderade lite tid på att tänka på projektets arkitektur. Det första steget är att göra "jorden", människor och tennisbanor. Människor ska kunna röra sig på banorna och vänta. Spelarna ska ha färdigheter som förbättras över tid. Dessutom måste det finnas en redaktör som gör det möjligt att lägga till nya människor och banor, men det är inte gratis.

Efter att ha övervägt allt började jag arbeta.

Skapande av spel

Inledning: cirklar och abstraktioner

Jag tog ett exempel från ggez och fick en cirkel på skärmen. Fantastiskt! Nu lite abstraktioner. Jag kände att det var bra att abstrahera från idén om ett spelobjekt. Varje objekt måste renderas och uppdateras som anges här:

// 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(())
    }
}

Denna kodsnutt gjorde att jag fick en fantastisk lista över objekt som jag kan uppdatera och rendera i en lika fantastisk loop.

mpl event::EventHandler för MainState {
    fn update(&mut self, context: &mut Context) -> GameResult {
        // Uppdatera alla objekt
        for object in self.objects.iter_mut() {
            object.update(context)?;
        }
 
        Ok(())
    }
 
    fn draw(&mut self, context: &mut Context) -> GameResult {
        graphics::clear(context);
 
        // Rita alla objekt
        for object in self.objects.iter_mut() {
            object.draw(context)?;
        }
 
        graphics::present(context);
 
        Ok(())
    }
}

main.rs är nödvändig eftersom den innehåller alla kodrader. Jag la ner lite tid på att dela upp filerna och optimera mappstrukturen. Så här ser allt ut efter detta:
resources -> här finns alla tillgångar (bilder)
src
— entities
— game_object.rs
— circle.rs
— main.rs -> huvudloop

Människor, banor och bilder

Nästa steg är att skapa spelobjektet Person och ladda bilder. Allt ska byggas på grundval av brickor som är 32*32.

Tennisbanor

Efter att ha studerat hur tennisbanor ser ut bestämde jag mig för att göra dem av 4*2-brickor. Inledningsvis kunde jag antingen skapa en bild av denna storlek eller sammanfoga 8 separata brickor. Men senare insåg jag att det bara behövdes två unika brickor, och här är varför.

Vi har totalt två sådana brickor: 1 och 2.

Varje sektion av banan består av antingen bricka 1 eller bricka 2. De kan placeras som vanligt eller vändas 180 grader.

Huvudbyggnadsläget (sammanställning)

När jag lyckades få till rendering av banor, människor och kartor insåg jag att jag också behövde ett grundläggande bygglägen. Jag implementerade det så här: när en knapp trycks ned väljs ett objekt, och ett klick placerar det på önskad plats. Så, knapp 1 låter mig välja en bana, medan knapp 2 låter mig välja en spelare.

Men vi måste också komma ihåg vad 1 och 2 betyder, så jag lade till en wireframe för att göra det tydligt vilket objekt som var valt. Så här ser det ut.

Frågor om arkitektur och refaktorering

Nu har jag några spelobjekt: människor, tennisplaner och våningar. Men för att wireframes ska fungera måste varje objekts enhet informeras om huruvida själva objekten är i demonstrationsläge eller bara har en ritad ram. Det är inte särskilt praktiskt.

Jag tyckte att det var nödvändigt att ompröva arkitekturen så att vissa begränsningar framträdde:

• Närvaron av en enhet som visar och uppdaterar sig själv är ett problem, eftersom den enheten inte kan "veta" vad den ska rendera – bild och wireframe;
• Det finns en brist på ett verktyg för att utbyta egenskaper och beteenden mellan separata enheter (exempel - egenskapen is_build_mode eller renderingbeteenden). Man skulle kunna använda arv, men i Rust finns det inget bra sätt att implementera detta. Vad jag verkligen behövde var komposition;
• Ett verktyg för att interagera mellan enheterna var nödvändigt för att tilldela människor till tennisplaner;
• Själva enheterna var en blandning av data och logik, vilket snabbt blev oöverskådligt.

Jag genomförde en ytterligare studie och upptäckte arkitekturen ECS – Entity Component System, som vanligtvis används i spel. Här är fördelarna med ECS:

• Data är separerade från logik;
• Komposition istället för arv;
• Dataorienterad arkitektur.

ECS kännetecknas av tre grundläggande koncept:

• Enheter – en typ av objekt som refereras av en identifierare (det kan vara en spelare, en boll eller något annat);
• Komponenter – dessa utgör enheterna. Exempel - renderingkomponent, positionskomponent och andra. Dessa är datalagringsutrymmen;
• System – de använder både objekt och komponenter, samt innehåller beteende och logik baserat på dessa data. Exempel - rendering system som går igenom alla enheter med komponenter för rendering och hanterar ritningen.

Efter studien blev det klart att ECS löser sådana problem:

• Användning av komposition istället för arv för systematisk organisering av enheter;
• Bli av med kodpackningen genom system för hantering;
• Användning av metoder som is_build_mode för att lagra wireframe-logiken på samma ställe - i rendering systemet.

Här är vad som kom ut efter implementeringen av ECS.

resources -> här finns alla tillgångar (bilder)
src
— komponenter
— position.rs
— person.rs
— tennis_court.rs
— floor.rs
— wireframe.rs
— mouse_tracked.rs
— resurser
— mouse.rs
— system
— rendering.rs
— constants.rs
— utils.rs
— world_factory.rs -> världsfabriksfunktioner
— main.rs -> huvudloop

Vi tilldelar personer till tennisbanor

ECS har gjort livet enklare. Nu har jag ett systematiskt sätt att lägga till data till entiteter och lägga till logik baserad på dessa data. Detta har i sin tur möjliggjort att organisera fördelningen av människor på tennisbanorna.

Vad jag gjorde:

• lade till data om tilldelade banor i Person;
• lade till data om de fördelade personerna i TennisCourt;
• lade till CourtChoosingSystem, som gör det möjligt att analysera människor och anläggningar, upptäcka tillgängliga banor och fördela spelare på dem;
• lade till PersonMovementSystem, som letar efter personer som är tilldelade banorna, och om de inte är där, skickar folk dit de behövs.

Sammanfattning

Jag gillade verkligen att arbeta med detta enkla spel. Dessutom är jag nöjd med att jag använde Rust för att skriva det, eftersom:

• Rust ger dig det du behöver;
• det har utmärkt dokumentation, Rust är mycket elegant;
• konstans är coolt;
• jag behöver inte förlita mig på kloning, kopiering eller liknande åtgärder, vilket jag ofta gjorde i C++;
• Options är väldigt användarvänliga, de hanterar också fel bra;
• om projektet lyckas kompilera, fungerar det i 99% av fallen precis som det ska. Jag tycker att kompilatorns felmeddelanden är de bästa jag sett.

Spelutveckling med Rust är i sitt begynnelsefas. Men det finns redan ett stabilt och ganska stort community som arbetar för att göra Rust tillgängligt för alla. Därför ser jag med optimism på språkets framtid, ivrigt väntande på resultaten av vårt gemensamma arbete.

Skillbox rekommenderar:

• Onlinekurs «Yrket frontendutvecklare».
• Praktisk kurs «Mobilutvecklare PRO».
• Praktisk årskurs PHP-utvecklare från grunden till PRO.

Källa: habr.com