Mäng Rustis 24 tunni jooksul: isiklik arenduskogemus

Selles artiklis räägin ma oma isiklikust kogemusest väikese mängu arendamisel Rustis. Töötava versiooni loomine võttis aega umbes 24 tundi (peamiselt töötasin õhtuti või nädalavahetustel). Mäng on endiselt kaugel valmimisest, kuid arvan, et kogemus tuleb kasuks. Räägin, mida õppisin, ja mõningatest tähelepanekutest, mis tegin mängu nullist ehitamise käigus.

Skillbox soovitab: Kaks aastat praktilist kursust „Mina – PRO veebiarendaja“.

Tuletame meelde: kõigile «Habr» lugejatele – 10 000 rubla allahindlus igale Skillboxi kursusele, kasutades sooduskoodi «Habr».

Miks Rust?

Valisin selle keele, kuna olin sellest palju head kuulnud ja näen, et see muutub mängude arenduse alal üha populaarsemaks. Enne mängu kirjutamist oli mul natuke kogemust lihtsate rakenduste arendamisel Rustis. Seda oli just parajalt, et tunda teatud vabadust mängu kirjutamisel.

Miks just mäng ja mis mäng?

Mängude loomine on lõbus! Sooviksin, et põhjus oleks rohkem, kuid „kodu“ projektide jaoks valin teemasid, mis ei ole liiga tihedalt seotud minu tavalise tööga. Mis mäng see on? Soovisin teha midagi sarnast tennisemängimise simulaatorile, kus on ühendatud Cities Skylines, Zoo Tycoon, Prison Architect ja tenis ise. Lühidalt, tekkis tennisekadeemia mäng, kuhu inimesed tulevad mängima.

Tehniline ettevalmistus

Soovisin kasutada Rusti, aga ei teadnud täpselt, kui palju tuleb alustada „nullist“. Ma ei tahtnud kirjutada pikselšeedreid ja kasutada lohista-ja-droppa, seetõttu otsisin kõige paindlikumaid lahendusi.

Leidsin kasulikke ressursse, millega jagan teiega:

• Are we game yet — nimekiri vajalikest mängu arendamise elementidest Rustis;
• Rusti mängu arendamise subreddiit;
• Tasuta pikselkunst.

Uurisin mitmeid Rusti mängumootoreid, valides lõpuks Piston ja ggez. Olen nende kahel varasemate projektide käigus kokku puutunud. Otsustasin ggez'i kasuks, kuna see tundus sobivam väikese 2D-mängu realiseerimiseks. Pistoni modulaarne struktuur on liiga keeruline algavale arendajale (või kellelegi, kes töötab Rustiga esmakordselt).

Mängu struktuur

Käisin veidi aega projekti arhitektuuri üle mõtlema. Esimene samm on luua „maa“, inimesed ja tennisekorterid. Inimesed peavad liikuma korterite vahel ja ootama. Mängijatel peaks olema oskused, mis ajas paranevad. Lisaks peab olema redigeerija, mis võimaldab uusi inimesi ja kortereid lisada, kuid see ei ole enam tasuta.

Pärast kõike läbimõtlemist asusin tööle.

Mängu loomine

Algus: ringid ja abstraktsioonid

Võtsin eeskuju ggez'ist ja sain ringi ekraanile. Üllatav! Nüüd mõned abstraktsioonid. Tundus, et oleks hea abstraktida mänguobjekti ideest. Iga objekt peab olema joonistatud ja uuendatud, nagu siin näidatud:

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

See koodilõik võimaldas mul saada suurepärase objektiloendi, mida ma saan uuendada ja joonistada sama hästi toimivas tsüklis.

mpl event::EventHandler for MainState {
    fn update(&mut self, context: &mut Context) -> GameResult {
        // Uuenda kõik objektid
        for object in self.objects.iter_mut() {
            object.update(context)?;
        }
 
        Ok(())
    }
 
    fn draw(&mut self, context: &mut Context) -> GameResult {
        graphics::clear(context);
 
        // Joonista kõik objektid
        for object in self.objects.iter_mut() {
            object.draw(context)?;
        }
 
        graphics::present(context);
 
        Ok(())
    }
}

main.rs on vajalik, kuna seal on kõik koodiread. Kulutasin natuke aega, et jagada failid ja optimeerida kaustastruktuuri. Nii see kõik pärast seda välja näeb:
resources -> siia kogunevad kõik varad (pildid)
src
— entities
— game_object.rs
— circle.rs
— main.rs -> peatsükkel

Inimesed, platsid ja pildid

Järgmine etapp on mänguobjekti Person loomine ja piltide laadimine. Kõik peab olema ehitatud 32*32 plaadi alusel.

Tennis platsid

Uurides, millised tennisplatsid välja näevad, otsustasin need valmistada 4*2 plaatidest. Alguses võis teha sellise suurusega pildi või kokku panna 8 eraldi plaati. Kuid hiljem sain aru, et on vajalikud vaid kaks ainulaadset plaati ja siin on miks.

Kokku on meil kaks sellist plaati: 1 ja 2.

Iga platsiosa koosneb plaatidest 1 või 2. Need võivad olla paigutatud tavaliselt või pööratud 180 kraadi.

Põhirakenduse (kokkupaneku) režiim

Pärast seda, kui suudasin joonistada platsid, inimesed ja kaardid, mõistsin, et on vajalik ka põhikokkupaneku režiim. Selle rakendasin järgmiselt: kui nuppu vajutada - objekt valitakse ja klikk asetab selle soovitud kohta. Nii võimaldab nupp 1 valida plats, ja nupp 2 valida mängija.

Kuid peame ka meeles pidama, mida 1 ja 2 tähendavad, seega lisasin wireframe'i, et oleks selge, milline objekt on valitud. Nii see välja näeb.

Küsimused arhitektuuri ja refaktoreerimise kohta

Nüüd on mul mitu mänguobjekti: inimesed, väljakud ja korrused. Kuid et wireframe'id töötaksid, tuleb iga objekti olemasolu kohta teada anda, kas objektid on demonstreerimisrežiimis või on lihtsalt raami joonistatud. See ei ole eriti mugav.

Mul tundus, et on vaja arhitektuuri ümber mõelda, et tuvastada teatud piirangud:

• olemasolu objekt, mis kuvab ja uuendab ennast, on probleem, kuna see objekt ei saa «teada», mida ta peaks renderdama — pilti ja wireframe'i;
• puudub tööriist omaduste ja käitumise jagamiseks eraldi objektide vahel (näide — omadus is_build_mode või käitumise joonistamine). Saaks kasutada pärandit, kuigi Rustis ei ole selle rakendamiseks normaalseid viise. Mis mul tõeliselt vajalik oli — see oli kompositsioon;
• tööriist objektidevaheliseks suhtlemiseks oli vajalik, et määrata inimesed väljakutele;
• iseendid olid andmete ja loogika segu, mis läks väga kiiresti kontrolli alt välja.

Tegin lisauuringu ja avastasin arhitektuuri ECS — Entity Component System, mida kasutatakse tavaliselt mängudes. Siin on ECS-i eelised:

• andmed on eraldatud loogikast;
• kompositsioon pärandi asemel;
• andmepõhine arhitektuur.

ECS-il on kolm põhikontseptsiooni:

• olendid — objekti tüüp, millele viitab identifikaator (see võib olla mängija, pall või miski muu);
• komponendid — neist koosnevad olendid. Näide — renderdamise, asukoha ja muud komponendid. Need on andmete hoidlad;
• süsteemid — need kasutavad nii objekte kui ka komponente, pluss sisaldavad käitumist ja loogikat, mis põhineb nende andmete põhjal. Näide — renderdamise süsteem, mis läbib kõik olendid koos renderdamise komponentidega ja tegeleb renderdamisega.

Pärast uurimist selgus, et ECS lahendab järgmised probleemid:

• kompositsiooni rakendamine pärandi asemel objektide süsteemse korraldamise jaoks;
• koodi segadusest vabanemine juhtimissüsteemide abil;
• meetodite kasutamine nagu is_build_mode, et hoida wireframe'i loogikat samas kohas — renderdamise süsteemis.

Nii nägi välja pärast ECS-i rakendamist.

resources -> siia kogunevad kõik varad (pildid)
src
— komponendid
— position.rs
— person.rs
— tennis_court.rs
— floor.rs
— wireframe.rs
— mouse_tracked.rs
— ressursid
— mouse.rs
— süsteemid
— rendering.rs
— constants.rs
— utils.rs
— world_factory.rs -> maailmadehitusfunktsioonid
— main.rs -> peatsükkel

Määrasime inimesed väljakutele

ECS tegi elu lihtsamaks. Nüüd oli mul süsteemne viis andmete lisamiseks olenditesse ja nendele andmetele põhineva loogika lisamiseks. See võimaldas omakorda korraldada inimeste jaotust väljakutele.

Mida ma tegin:

• lisasin määratud väljakute andmed Isikule;
• lisasin jaotatud inimeste andmed Tenniservile;
• lisasin CourtChoosingSystem, mis analüüsib inimesi ja väljakuid, tuvastab saadavalolevad väljakud ja jagab mängijad nende vahel;
• lisasin süsteemi PersonMovementSystem, mis otsib inimesi, kes on määratud väljakutele, ning kui neid seal pole, suunab inimesi vajalikku kohta.

Teeme kokkuvõtte

Mulle väga meeldis töötada selle lihtsa mängu kallal. Veelgi enam, olen rahul, et kasutasin selle kirjutamiseks Rusti, kuna:

• Rust annab sulle selle, mida vajad;
• tal on suurepärane dokumentatsioon, Rust on äärmiselt elegantne;
• püsivus on äge;
• ei ole vaja kasutada tükeldamist, kopeerimist või muid sarnaseid tegevusi, mida ma sageli C++-s tegin;
• Options on väga mugavad, nad käsitlevad vigu suurepäraselt;
• kui projekt õnnestub kompileerida, töötab see 99% ajast just nii, nagu peab. Compileri veateated on minu arvates parimad, mida olen näinud.

Mängude arendamine Rustis on hetkel alles algusjärgus. Kuid juba on olemas stabiilne ja üsna suur kogukond, mis töötab selle nimel, et avada Rust kõigile. Seetõttu vaatan keele tulevikku optimistlikult, oodates meie ühise töö tulemusi.

Skillbox soovitab:

• Veebikursus «Frontend-arendaja amet».
• Praktiline kursus «Mobiilne arendaja PRO».
• Praktiline aastakursus «PHP-arendaja 0-st PRO-ni».

Allikas: habr.com