In hierdie artikel sal ek praat oor my persoonlike ervaring van die ontwikkeling van 'n klein speletjie in Rust. Dit het ongeveer 24 uur geneem om 'n werkende weergawe te skep (ek het meestal in die aande of oor naweke gewerk). Die speletjie is nog lank nie klaar nie, maar ek dink die ervaring sal lonend wees. Ek sal deel wat ek geleer het en 'n paar waarnemings wat ek gemaak het terwyl ek die speletjie van nuuts af gebou het.
Skillbox beveel aan: Twee-jaar praktiese kursus .
Ons herinner: vir alle lesers van "Habr" - 'n afslag van 10 000 roebels wanneer u inskryf vir enige Skillbox-kursus met behulp van die "Habr"-promosiekode.
Hoekom Roes?
Ek het hierdie taal gekies omdat ek baie goeie dinge daaroor gehoor het en ek sien dit word al hoe meer gewild in speletjie-ontwikkeling. Voordat ek die speletjie geskryf het, het ek min ondervinding gehad om eenvoudige toepassings in Rust te ontwikkel. Dit was net genoeg om my 'n gevoel van vryheid te gee terwyl ek die speletjie skryf.
Hoekom die speletjie en watter soort speletjie?
Om speletjies te maak is pret! Ek wens daar was meer redes, maar vir “tuis” projekte kies ek onderwerpe wat nie te nou verband hou met my gewone werk nie. Watter speletjie is hierdie? Ek wou iets soos 'n tennissimulator maak wat Cities Skylines, Zoo Tycoon, Prison Architect en tennis self kombineer. Oor die algemeen het dit geblyk 'n speletjie te wees oor 'n tennisakademie waar mense kom speel.
Tegniese opleiding
Ek wou Rust gebruik, maar ek het nie geweet presies hoeveel grondwerk dit sou neem om te begin nie. Ek wou nie pixel shaders skryf en sleep-en-drop gebruik nie, so ek was op soek na die mees buigsame oplossings.
Ek het nuttige hulpbronne gevind wat ek met jou deel:
- — 'n lys van Roes-elemente wat nodig is vir spelontwikkeling;
Ek het verskeie Rust-speletjieenjins verken, en uiteindelik Piston en ggez gekies. Ek het op hulle afgekom terwyl ek aan 'n vorige projek gewerk het. Op die ou end het ek ggez gekies omdat dit meer geskik gelyk het vir die implementering van 'n klein 2D-speletjie. Piston se modulêre struktuur is te kompleks vir 'n beginner ontwikkelaar (of iemand wat vir die eerste keer met Rust werk).
Spelstruktuur
Ek het 'n bietjie tyd spandeer om oor die argitektuur van die projek te dink. Die eerste stap is om die "grond", mense en tennisbane te maak. Mense moet in die howe rondbeweeg en wag. Spelers moet vaardighede hê wat mettertyd verbeter. Boonop moet daar 'n redigeerder wees wat jou toelaat om nuwe mense en howe by te voeg, maar dit is nie meer gratis nie.
Nadat ek alles deurdink het, het ek begin werk.
Speletjie skepping
Begin: Kringe en Abstraksies
Ek het 'n voorbeeld van ggez geneem en 'n sirkel op die skerm gekry. Wonderlike! Nou 'n paar abstraksies. Ek het gedink dit sou lekker wees om weg te abstraheer van die idee van 'n spelvoorwerp. Elke voorwerp moet weergegee en opgedateer word soos hier vermeld:
// 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(())
}
}Hierdie stukkie kode het vir my 'n mooi lys van voorwerpe gegee wat ek in 'n ewe mooi lus kon opdateer en weergee.
mpl event::EventHandler for MainState {
fn update(&mut self, context: &mut Context) -> GameResult<()> {
// Update all objects
for object in self.objects.iter_mut() {
object.update(context)?;
}
Ok(())
}
fn draw(&mut self, context: &mut Context) -> GameResult<()> {
graphics::clear(context);
// Draw all objects
for object in self.objects.iter_mut() {
object.draw(context)?;
}
graphics::present(context);
Ok(())
}
}
main.rs is nodig omdat dit al die reëls kode bevat. Ek het 'n bietjie tyd spandeer om die lêers te skei en die gidsstruktuur te optimaliseer. Dit is hoe dit daarna gelyk het:
hulpbronne -> dit is waar al die bates is (prente)
src
- entiteite
— game_object.rs
— sirkel.rs
— hoof.rs -> hooflus
Mense, vloere en beelde
Die volgende stap is om 'n Persoon-speletjie-objek te skep en beelde te laai. Alles moet op die basis van 32*32 teëls gebou word.
Tennisbane
Nadat ek bestudeer het hoe tennisbane lyk, het ek besluit om dit van 4*2 teëls te maak. Aanvanklik was dit moontlik om 'n beeld van hierdie grootte te maak, of om 8 aparte teëls saam te stel. Maar toe besef ek dat net twee unieke teëls nodig is, en hier is hoekom.
In totaal het ons twee sulke teëls: 1 en 2.
Elke gedeelte van die baan bestaan uit teël 1 of teël 2. Hulle kan soos normaal uitgelê word of 180 grade omgedraai word.
Basiese konstruksie (samestelling) modus
Nadat ek daarin geslaag het om die weergawe van werwe, mense en kaarte te bereik, het ek besef dat 'n basiese samestellingmodus ook nodig was. Ek het dit so geïmplementeer: wanneer die knoppie gedruk word, word die voorwerp gekies, en die klik plaas dit op die gewenste plek. So, knoppie 1 laat jou toe om 'n baan te kies, en knoppie 2 laat jou toe om 'n speler te kies.
Maar ons moet nog onthou wat 1 en 2 beteken, so ek het 'n draadraam bygevoeg om dit duidelik te maak watter voorwerp gekies is. Dit is hoe dit lyk.
Argitektuur en herfaktoreringsvrae
Nou het ek verskeie spelvoorwerpe: mense, bane en vloere. Maar om draadrame te laat werk, moet elke voorwerp-entiteit vertel word of die voorwerpe self in demonstrasiemodus is, en of 'n raam bloot geteken is. Dit is nie baie gerieflik nie.
Dit het vir my gelyk of die argitektuur herbedink moes word op 'n manier wat 'n paar beperkings aan die lig gebring het:
- Om 'n entiteit te hê wat homself weergee en bywerk, is 'n probleem, want daardie entiteit sal nie in staat wees om te "weet" wat dit veronderstel is om weer te gee nie - 'n beeld en 'n draadraam;
- gebrek aan 'n instrument vir die uitruil van eienskappe en gedrag tussen individuele entiteite (byvoorbeeld die is_build_mode-eienskap of gedragsweergawe). Dit sou moontlik wees om oorerwing te gebruik, alhoewel daar geen behoorlike manier is om dit in Rust te implementeer nie. Wat ek regtig nodig gehad het, was die uitleg;
- 'n instrument vir interaksie tussen entiteite was nodig om mense aan howe toe te wys;
- die entiteite self was 'n mengsel van data en logika wat vinnig buite beheer geraak het.
Ek het nog navorsing gedoen en die argitektuur ontdek , wat algemeen in speletjies gebruik word. Hier is die voordele van ECS:
- data word van logika geskei;
- samestelling in plaas van oorerwing;
- data-sentriese argitektuur.
ECS word gekenmerk deur drie basiese konsepte:
- entiteite - die tipe voorwerp waarna die identifiseerder verwys (dit kan 'n speler, 'n bal of iets anders wees);
- komponente - entiteite word daaruit saamgestel. Voorbeeld - lewering van komponent, liggings en ander. Dit is datapakhuise;
- stelsels - hulle gebruik beide voorwerpe en komponente, plus bevat gedrag en logika wat op hierdie data gebaseer is. 'n Voorbeeld is 'n leweringstelsel wat deur alle entiteite met leweringskomponente herhaal en die lewering doen.
Nadat u dit bestudeer het, het dit duidelik geword dat ECS die volgende probleme oplos:
- die gebruik van uitleg in plaas van oorerwing om entiteite sistemies te organiseer;
- ontslae te raak van kode warboel deur beheerstelsels;
- met behulp van metodes soos is_build_mode om die draadraamlogika op dieselfde plek te hou - in die leweringstelsel.
Dit is wat gebeur het na die implementering van ECS.
hulpbronne -> dit is waar al die bates is (prente)
src
- komponente
—posisie.rs
— persoon.rs
— tennisbaan.rs
— vloer.rs
- draadraam.rs
— mouse_tracked.rs
- hulpbronne
—muis.rs
- stelsels
— lewering.rs
— konstantes.rs
— utils.rs
— world_factory.rs -> wêreldfabrieksfunksies
— hoof.rs -> hooflus
Ons wys mense by die howe toe
ECS het die lewe makliker gemaak. Nou het ek 'n sistematiese manier gehad om data by entiteite te voeg en logika op grond van daardie data by te voeg. En dit het dit op sy beurt moontlik gemaak om die verspreiding van mense onder die howe te organiseer.
Wat het ek gedoen:
- data oor toegewysde howe aan Persoon bygevoeg;
- data oor verspreide mense by TennisCourt gevoeg;
- bygevoeg CourtChoosingSystem, wat jou toelaat om mense en howe te ontleed, beskikbare howe op te spoor en spelers na hulle te versprei;
- het 'n PersonMovementSystem bygevoeg, wat soek na mense wat aan die howe toegewys is, en as hulle nie daar is nie, dan mense stuur waar hulle moet wees.
Opsomming
Ek het dit baie geniet om aan hierdie eenvoudige speletjie te werk. Boonop is ek bly dat ek Rust gebruik het om dit te skryf, want:
- Roes gee jou wat jy nodig het;
- dit het uitstekende dokumentasie, Roes is redelik elegant;
- konsekwentheid is koel;
- jy hoef nie te wend tot kloning, kopieer of ander soortgelyke aksies, wat ek dikwels in C++ gedoen het nie;
- Opsies is baie maklik om te gebruik en hanteer foute baie goed;
- as die projek saamgestel kon word, dan werk dit 99% van die tyd, en presies soos dit moet. Ek dink die samesteller foutboodskappe is die beste wat ek nog gesien het.
Speletjieontwikkeling in Rust begin net. Maar daar is reeds 'n stabiele en redelike groot gemeenskap wat werk om Rust vir almal oop te maak. Daarom kyk ek met optimisme na die toekoms van die taal, sien uit na die resultate van ons gemeenskaplike werk.
Skillbox beveel aan:
- Aanlyn kursus .
- Praktiese kursus .
- Praktiese jaarkursus .
Bron: will.com