Mäng Rustis 24 tunni jooksul: isiklik arenduskogemus

Selles artiklis jagan oma isiklikku kogemust väikese mängu arendamisel Rustis. Töötava versiooni loomiseks kulus umbes 24 tundi (peamiselt töötasin õhtuti või nädalavahetustel). Mäng on veel kaugel valmimisest, kuid arvan, et see kogemus on kasulik. Räägin, mida õppisin, ja mõnest tähelepanekust, mida tegin mängu nullist ehitamisel.

Skillbox soovitab: Kaheaastane praktiline kursus „Mina olen PRO veebiarendaja“.

Tuletame meelde: kõigile «Habra» lugejatele — 10 000 rubla soodustus, kui registreerite end Skillboxi mis tahes kursusele promokoodi «Habr» abil.

Miks Rust?

Valisin selle keele, kuna olin kuulnud sellest palju head ja näen, et see muutub mänguarenduse valdkonnas üha populaarsemaks. Enne mängu kirjutamist oli mul vähene kogemus lihtsate rakenduste arendamisel Rustis. Seda oli just piisavalt, et tunda kindlat vabadust mängu kirjutamisel.

Miks just mäng ja milline mäng?

Mängude loomine on lõbus! Sooviksin, et põhjus oleks rohkem, kuid koduste projektide puhul valin teeman, mis ei ole liiga closely seotud minu tavapärase tööga. Mis mäng see on? Soovis teha midagi nagu tennis sims, kus segunevad Cities Skylines, Zoo Tycoon, Prison Architect ja tennis ise. Kokkuvõttes kujunes välja mäng tennisekadeemiast, kuhu inimesed tulevad mängima.

Tehniline ettevalmistus

Soovisin kasutada Rust'i, kuid ma ei teadnud täpselt, kui palju tuleb alustada nullist. Ma ei soovinud kirjutada pikslite varjutusi ja kasutada drag-n-drop'i, seega otsisin paindlikumaid lahendusi.

Leidsin kasulikke ressursse, mida jagan teiega:

• Are we game yet — nimekiri vajalikest elementidest mängude arendamiseks Rust'is;
• Rust mängude arenduse subreddiit;
• Tasuta pikselkunst.

Uurisin mitmeid mängumootoreid Rust'is, valides lõpuks Piston ja ggez. Kohtusin nendega, töötades varasema projekti kallal. Lõpuks valisin ggez, kuna see tundus sobivam väikese 2D-mängu elluviimiseks. Piston'i modulaarne struktuur on algajale arendajale (või sellele, kes esmakordselt Rust'iga töötab) liiga keeruline.

Mängu struktuur

Kulutasin veidi aega projekti arhitektuuri mõtlemiseks. Esimene samm on luua „maa“, inimesed ja tenniseväljakud. Inimesed peavad väljakutel liikuma ja ootama. Mängijatel peavad olema oskused, mis ajas arenevad. Lisaks peab olema redaktor, mis võimaldab lisada uusi inimesi ja väljakuid, kuid see ei ole enam tasuta.

Kui kõik läbi mõeldud, asusin tööle.

Mängu loomine

Algus: ringid ja abstraktsioonid

Võtsin eeskujuks ggez'i ja sain ringi ekraanile. Imeline! Nüüd natuke abstraktsioone. Tundus, et oleks hea, kui abstrakteeruda mängu objekti ideest. Iga objekt peab olema renderdatud 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 objekti nimekirja, mida saan uuendada ja renderdada vähemalt sama suurepärases 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. Mäletan, et kulutasin natuke aega failide jagamisele ja kaustastruktuuri optimeerimisele. Nii see kõik pärast muutus:
resources -> siia kogunevad kõik varad (pildid)
src
— entities
— game_object.rs
— circle.rs
— main.rs -> põhitsükkel

Inimesed, tasanded ja pildid

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

Tenniseväljakud

Uurides, kuidas tenniseväljakud välja näevad, otsustasin teha need 4*2 plaatidest. Alguses oleks võinud sellise suuruse jaoks teha kas ühe pildi või kokku panna 8 eraldi plaati. Kuid hiljem sain aru, et on vajalikud vaid kaks ainulaadset plaati, ja siit tulenebki põhjus.

Kokku on meil ainult kaks sellist plaati: 1 ja 2.

Iga väljakusektsioon koosneb plaadist 1 või plaadist 2. Need võivad paikneda nagu tavaliselt või olla pööratud 180 kraadi.

Peamine ehitamisrežiim (kokkupanek)

Pärast seda, kui sain renderdamisega hakkama, märkasin, et on vajalik ka põhikoosolekurežiim. Selle lahendasin nii: kui nuppu vajutatakse — objekt on valitud ja klikk paigutab selle soovitud kohta. Nii annab nupp 1 võimaluse valida koht, samas kui nupp 2 võimaldab valida mängijat.

Kuid peame veel meeles pidama, mida 1 ja 2 tähendavad, seetõttu lisasin juhtplaani, et selge oleks, 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 selleks, et juhtplaanid töötaksid, peab iga objekti ühik olema kursis, kas objektid on esitluse režiimis või on lihtsalt joonistatud raam. See ei ole kuigi mugav.

Mulle tundus, et arhitektuuri tuleks ümber mõelda, et leida mõned piirangud:

• üksuse olemasolu, mis kuvab ja uuendab ennast, on probleem, kuna see ühik ei suuda 'teada', mida ta peab renderdama — pilti ja juhtplaani;
• puuduvad vahendid omaduste ja käitumise vahetamiseks üksikute objektide vahel (näide — omadus is_build_mode või käitumise joonistamine). Oleks võinud kasutada pärandamist, kuigi Rustis pole selle rakendamiseks korralikku viisi. Mind tõeliselt huvitas kompositsioon;
• vahend objektide omavaheliseks suhtlemiseks oli vajalik, et määrata inimesi väljakutele;
• need objektid olid andmete ja loogika segu, mis kiiresti hukka läks.

Tehnisin veel ja avastasin arhitehtuuri ECS — Entity Component System, mida kasutatakse sageli mängudes. Siin on ECS eelised:

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

ECS-i iseloomustavad kolm põhikontseptsiooni:

• objektid — objekti tüüp, millele viitab identifikaator (see võib olla mängija, pall või midagi muud);
• komponendid — need moodustavad objektid. Näide — renderdamise komponent, asukoht ja teised. Need on andmete hoidlad;
• süsteemid — nad kasutavad nii objekte kui komponente ning sisaldavad käitumist ja loogikat, mis põhinevad nende andmetel. Näide — renderdamisseade, mis läbib kõik olemused koos komponentidega renderdamiseks ja tegeleb joonistamisega.

Uurimise järel selgus, et ECS lahendab järgmised probleemid:

• komponendi kasutamine asemel pärimise süsteemseks korraldamiseks;
• koodi segadusest vabastamine süsteemide haldamise kaudu;
• meetodite nagu is_build_mode kasutamine, et hoida traate loogikat samas kohas — renderdamisseadmes.

Siin on, mis sündis 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
— resources
— mouse.rs
— süsteemid
— rendering.rs
— constants.rs
— utils.rs
— world_factory.rs -> maailmade tehasetooted
— main.rs -> põhitsükkel

Määrame inimesed kohtadele

ECS on elu lihtsamaks teinud. Nüüd oli mul süsteemne tee andmete lisamiseks olemustele ja nende andmete põhjal loogika lisamiseks. See, omakorda, võimaldas korraldada inimeste jaotamist kohtadele.

Mida ma tegin:

• lisati Person-i määratud kohtade andmed;
• lisati TennisCourt-i jaotatud inimeste andmed;
• lisatud CourtChoosingSystem, mis võimaldab analüüsida inimesi ja platsse, avastada saadaolevaid väljakuid ja jaotada mängijaid neile;
• lisatud PersonMovementSystem, mis otsib inimesi, kes on määratud väljakutele, ja kui neid seal pole, suunab inimesi sinna, kus nad peavad olema.

Teeme kokkuvõtteid

Mulle meeldis väga töötada selle lihtsa mänguga. Veelgi enam, olen rahul, et kasutasin selle kirjutamiseks Rust'i, kuna:

• Rust annab teile kõik, mis vajalik;
• sellel on suurepärane dokumentatsioon, Rust on väga elegantne;
• püsivus on suurepärane;
• ei pea kasutama kloonimist, kopeerimist või muid sarnaseid toiminguid, mida ma sageli tegin C++-s;
• Options on väga mugavad kasutada ja nad käsitlevad vigu suurepäraselt;
• kui projekt õnnestub kompileerida, siis 99% tõenäosusega töötab see just nii, nagu peab. Arvutiviga teated on minu arvates parimad, mida ma olen näinud.

Mängude arendamine Rust'i keeles on alles alguses. 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 kannatamatult.

Skillbox soovitab:

• Veebikursus „Frontend-arendaja amet“.
• Praktiline kursus «Mobiilne arendaja PRO».
• Praktiline aastakursus „PHP arendaja algusest PRO-ni“.

Allikas: habr.com