🥇24 ಗಂಟೆಗಳಲ್ಲಿ ರಸ್ಟ್‌ನಲ್ಲಿ ಆಟ: ವೈಯಕ್ತಿಕ ಅಭಿವೃದ್ಧಿ ಅನುಭವ

ಈ ಲೇಖನದಲ್ಲಿ ನಾನು ರಸ್ಟ್ನಲ್ಲಿ ಸಣ್ಣ ಆಟವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ನನ್ನ ವೈಯಕ್ತಿಕ ಅನುಭವದ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇನೆ. ಕೆಲಸದ ಆವೃತ್ತಿಯನ್ನು ರಚಿಸಲು ಇದು ಸುಮಾರು 24 ಗಂಟೆಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು (ನಾನು ಹೆಚ್ಚಾಗಿ ಸಂಜೆ ಅಥವಾ ವಾರಾಂತ್ಯದಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದ್ದೇನೆ). ಆಟವು ಮುಗಿದಿಲ್ಲ, ಆದರೆ ಅನುಭವವು ಲಾಭದಾಯಕವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ನಾನು ಕಲಿತದ್ದನ್ನು ಮತ್ತು ಮೊದಲಿನಿಂದ ಆಟವನ್ನು ನಿರ್ಮಿಸುವಾಗ ನಾನು ಮಾಡಿದ ಕೆಲವು ಅವಲೋಕನಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತೇನೆ.

ಸ್ಕಿಲ್‌ಬಾಕ್ಸ್ ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ: ಎರಡು ವರ್ಷಗಳ ಪ್ರಾಯೋಗಿಕ ಕೋರ್ಸ್ "ನಾನು PRO ವೆಬ್ ಡೆವಲಪರ್".

ನಾವು ನೆನಪಿಸುತ್ತೇವೆ: ಎಲ್ಲಾ Habr ಓದುಗರಿಗೆ - Habr ಪ್ರೊಮೊ ಕೋಡ್ ಬಳಸಿಕೊಂಡು ಯಾವುದೇ ಸ್ಕಿಲ್‌ಬಾಕ್ಸ್ ಕೋರ್ಸ್‌ಗೆ ದಾಖಲಾಗುವಾಗ 10 ರೂಬಲ್ ರಿಯಾಯಿತಿ.

ಏಕೆ ತುಕ್ಕು?

ನಾನು ಈ ಭಾಷೆಯನ್ನು ಆರಿಸಿಕೊಂಡಿದ್ದೇನೆ ಏಕೆಂದರೆ ನಾನು ಅದರ ಬಗ್ಗೆ ಸಾಕಷ್ಟು ಒಳ್ಳೆಯ ವಿಷಯಗಳನ್ನು ಕೇಳಿದ್ದೇನೆ ಮತ್ತು ಆಟದ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಇದು ಹೆಚ್ಚು ಹೆಚ್ಚು ಜನಪ್ರಿಯವಾಗುತ್ತಿರುವುದನ್ನು ನಾನು ನೋಡುತ್ತೇನೆ. ಆಟವನ್ನು ಬರೆಯುವ ಮೊದಲು, ರಸ್ಟ್‌ನಲ್ಲಿ ಸರಳವಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವಲ್ಲಿ ನನಗೆ ಸ್ವಲ್ಪ ಅನುಭವವಿತ್ತು. ಆಟವನ್ನು ಬರೆಯುವಾಗ ನನಗೆ ಸ್ವಾತಂತ್ರ್ಯದ ಭಾವವನ್ನು ನೀಡಲು ಇದು ಸಾಕಾಗಿತ್ತು.

ಏಕೆ ಆಟ ಮತ್ತು ಯಾವ ರೀತಿಯ ಆಟ?

ಆಟಗಳನ್ನು ಮಾಡುವುದು ಮೋಜು! ಹೆಚ್ಚಿನ ಕಾರಣಗಳಿವೆ ಎಂದು ನಾನು ಬಯಸುತ್ತೇನೆ, ಆದರೆ "ಮನೆ" ಯೋಜನೆಗಳಿಗಾಗಿ ನಾನು ನನ್ನ ನಿಯಮಿತ ಕೆಲಸಕ್ಕೆ ಹೆಚ್ಚು ಸಂಬಂಧವಿಲ್ಲದ ವಿಷಯಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತೇನೆ. ಇದು ಯಾವ ಆಟ? ನಾನು ಸಿಟೀಸ್ ಸ್ಕೈಲೈನ್ಸ್, ಝೂ ಟೈಕೂನ್, ಪ್ರಿಸನ್ ಆರ್ಕಿಟೆಕ್ಟ್ ಮತ್ತು ಟೆನ್ನಿಸ್ ಅನ್ನು ಸಂಯೋಜಿಸುವ ಟೆನಿಸ್ ಸಿಮ್ಯುಲೇಟರ್‌ನಂತಹದನ್ನು ಮಾಡಲು ಬಯಸುತ್ತೇನೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಇದು ಜನರು ಆಡಲು ಬರುವ ಟೆನಿಸ್ ಅಕಾಡೆಮಿಯ ಆಟವಾಗಿ ಹೊರಹೊಮ್ಮಿತು.

ತಾಂತ್ರಿಕ ತರಬೇತಿ

ನಾನು ರಸ್ಟ್ ಅನ್ನು ಬಳಸಲು ಬಯಸಿದ್ದೆ, ಆದರೆ ಪ್ರಾರಂಭಿಸಲು ಎಷ್ಟು ಗ್ರೌಂಡ್‌ವರ್ಕ್ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ನನಗೆ ನಿಖರವಾಗಿ ತಿಳಿದಿರಲಿಲ್ಲ. ನಾನು ಪಿಕ್ಸೆಲ್ ಶೇಡರ್‌ಗಳನ್ನು ಬರೆಯಲು ಮತ್ತು ಡ್ರ್ಯಾಗ್-ಎನ್-ಡ್ರಾಪ್ ಅನ್ನು ಬಳಸಲು ಬಯಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾನು ಹೆಚ್ಚು ಹೊಂದಿಕೊಳ್ಳುವ ಪರಿಹಾರಗಳನ್ನು ಹುಡುಕುತ್ತಿದ್ದೇನೆ.

ನಾನು ನಿಮ್ಮೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳುವ ಉಪಯುಕ್ತ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನಾನು ಕಂಡುಕೊಂಡಿದ್ದೇನೆ:

ನಾವು ಇನ್ನೂ ಆಡುತ್ತಿದ್ದೇವೆಯೇ - ಆಟದ ಅಭಿವೃದ್ಧಿಗೆ ಅಗತ್ಯವಾದ ರಸ್ಟ್ ಅಂಶಗಳ ಪಟ್ಟಿ;
ರಸ್ಟ್ ಗೇಮ್ ದೇವ್ ಸಬ್‌ರೆಡಿಟ್;
ಉಚಿತ ಪಿಕ್ಸೆಲ್ ಕಲೆ.

ನಾನು ಹಲವಾರು ರಸ್ಟ್ ಗೇಮ್ ಎಂಜಿನ್‌ಗಳನ್ನು ಅನ್ವೇಷಿಸಿದ್ದೇನೆ, ಅಂತಿಮವಾಗಿ ಪಿಸ್ಟನ್ ಮತ್ತು ಗ್ಜೆಜ್ ಅನ್ನು ಆರಿಸಿದೆ. ಹಿಂದಿನ ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಾಗ ನಾನು ಅವರನ್ನು ಕಂಡೆ. ಕೊನೆಯಲ್ಲಿ, ನಾನು ggez ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇನೆ ಏಕೆಂದರೆ ಇದು ಸಣ್ಣ 2D ಆಟವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಹೆಚ್ಚು ಸೂಕ್ತವೆಂದು ತೋರುತ್ತಿದೆ. ಪಿಸ್ಟನ್‌ನ ಮಾಡ್ಯುಲರ್ ರಚನೆಯು ಅನನುಭವಿ ಡೆವಲಪರ್‌ಗೆ (ಅಥವಾ ಮೊದಲ ಬಾರಿಗೆ ರಸ್ಟ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿರುವವರಿಗೆ) ತುಂಬಾ ಸಂಕೀರ್ಣವಾಗಿದೆ.

ಆಟದ ರಚನೆ

ನಾನು ಯೋಜನೆಯ ವಾಸ್ತುಶಿಲ್ಪದ ಬಗ್ಗೆ ಸ್ವಲ್ಪ ಸಮಯ ಯೋಚಿಸಿದೆ. "ಭೂಮಿ", ಜನರು ಮತ್ತು ಟೆನ್ನಿಸ್ ಅಂಕಣಗಳನ್ನು ಮಾಡುವುದು ಮೊದಲ ಹಂತವಾಗಿದೆ. ಜನರು ನ್ಯಾಯಾಲಯದ ಸುತ್ತ ತಿರುಗಿ ಕಾಯಬೇಕಾಗಿದೆ. ಆಟಗಾರರು ಕಾಲಾನಂತರದಲ್ಲಿ ಸುಧಾರಿಸುವ ಕೌಶಲ್ಯಗಳನ್ನು ಹೊಂದಿರಬೇಕು. ಜೊತೆಗೆ, ಹೊಸ ಜನರು ಮತ್ತು ನ್ಯಾಯಾಲಯಗಳನ್ನು ಸೇರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಸಂಪಾದಕರಿರಬೇಕು, ಆದರೆ ಇದು ಇನ್ನು ಮುಂದೆ ಉಚಿತವಲ್ಲ.

ಎಲ್ಲವನ್ನೂ ಯೋಚಿಸಿದ ನಂತರ, ನಾನು ಕೆಲಸ ಮಾಡಿದೆ.

ಆಟದ ಸೃಷ್ಟಿ

ಪ್ರಾರಂಭ: ವಲಯಗಳು ಮತ್ತು ಅಮೂರ್ತತೆಗಳು

ನಾನು ggez ನಿಂದ ಒಂದು ಉದಾಹರಣೆಯನ್ನು ತೆಗೆದುಕೊಂಡೆ ಮತ್ತು ಪರದೆಯ ಮೇಲೆ ವೃತ್ತವನ್ನು ಪಡೆದುಕೊಂಡೆ. ಅದ್ಭುತ! ಈಗ ಕೆಲವು ಅಮೂರ್ತತೆಗಳು. ಆಟದ ವಸ್ತುವಿನ ಕಲ್ಪನೆಯಿಂದ ದೂರವಿರುವುದು ಒಳ್ಳೆಯದು ಎಂದು ನಾನು ಭಾವಿಸಿದೆ. ಇಲ್ಲಿ ಹೇಳಿರುವಂತೆ ಪ್ರತಿ ವಸ್ತುವನ್ನು ನಿರೂಪಿಸಬೇಕು ಮತ್ತು ನವೀಕರಿಸಬೇಕು:

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

ಈ ಕೋಡ್ ತುಣುಕು ನನಗೆ ಅಪ್‌ಡೇಟ್ ಮಾಡಬಹುದಾದ ಮತ್ತು ಅಷ್ಟೇ ಉತ್ತಮವಾದ ಲೂಪ್‌ನಲ್ಲಿ ಸಲ್ಲಿಸಬಹುದಾದ ವಸ್ತುಗಳ ಉತ್ತಮ ಪಟ್ಟಿಯನ್ನು ನೀಡಿದೆ.

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 ಅಗತ್ಯವಾಗಿದೆ ಏಕೆಂದರೆ ಇದು ಕೋಡ್‌ನ ಎಲ್ಲಾ ಸಾಲುಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ನಾನು ಫೈಲ್‌ಗಳನ್ನು ಬೇರ್ಪಡಿಸಲು ಮತ್ತು ಡೈರೆಕ್ಟರಿ ರಚನೆಯನ್ನು ಉತ್ತಮಗೊಳಿಸಲು ಸ್ವಲ್ಪ ಸಮಯವನ್ನು ಕಳೆದಿದ್ದೇನೆ. ಅದರ ನಂತರ ಅದು ಹೇಗಿತ್ತು:
ಸಂಪನ್ಮೂಲಗಳು -> ಇಲ್ಲಿಯೇ ಎಲ್ಲಾ ಸ್ವತ್ತುಗಳು (ಚಿತ್ರಗಳು)
Src
- ಘಟಕಗಳು
— game_object.rs
- circle.rs
— main.rs -> ಮುಖ್ಯ ಲೂಪ್

ಜನರು, ಮಹಡಿಗಳು ಮತ್ತು ಚಿತ್ರಗಳು

ಮುಂದಿನ ಹಂತವು ವ್ಯಕ್ತಿ ಆಟದ ವಸ್ತುವನ್ನು ರಚಿಸುವುದು ಮತ್ತು ಚಿತ್ರಗಳನ್ನು ಲೋಡ್ ಮಾಡುವುದು. ಎಲ್ಲವನ್ನೂ 32 * 32 ಅಂಚುಗಳ ಆಧಾರದ ಮೇಲೆ ನಿರ್ಮಿಸಬೇಕು.

ಟೆನಿಸ್ ಕೋರ್ಟ್‌ಗಳು

ಟೆನಿಸ್ ಕೋರ್ಟ್‌ಗಳು ಹೇಗಿವೆ ಎಂಬುದನ್ನು ಅಧ್ಯಯನ ಮಾಡಿದ ನಂತರ, ನಾನು ಅವುಗಳನ್ನು 4 * 2 ಅಂಚುಗಳಿಂದ ಮಾಡಲು ನಿರ್ಧರಿಸಿದೆ. ಆರಂಭದಲ್ಲಿ, ಈ ಗಾತ್ರದ ಚಿತ್ರವನ್ನು ಮಾಡಲು ಅಥವಾ 8 ಪ್ರತ್ಯೇಕ ಅಂಚುಗಳನ್ನು ಜೋಡಿಸಲು ಸಾಧ್ಯವಾಯಿತು. ಆದರೆ ಕೇವಲ ಎರಡು ವಿಶಿಷ್ಟ ಅಂಚುಗಳು ಮಾತ್ರ ಅಗತ್ಯವಿದೆ ಎಂದು ನಾನು ಅರಿತುಕೊಂಡೆ ಮತ್ತು ಏಕೆ ಎಂಬುದು ಇಲ್ಲಿದೆ.

ಒಟ್ಟಾರೆಯಾಗಿ ನಾವು ಅಂತಹ ಎರಡು ಅಂಚುಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ: 1 ಮತ್ತು 2.

ನ್ಯಾಯಾಲಯದ ಪ್ರತಿಯೊಂದು ವಿಭಾಗವು ಟೈಲ್ 1 ಅಥವಾ ಟೈಲ್ 2 ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಅವುಗಳನ್ನು ಸಾಮಾನ್ಯ ಅಥವಾ 180 ಡಿಗ್ರಿಗಳಷ್ಟು ತಿರುಗಿಸಬಹುದು.

ಮೂಲ ನಿರ್ಮಾಣ (ಅಸೆಂಬ್ಲಿ) ಮೋಡ್

ಸೈಟ್‌ಗಳು, ಜನರು ಮತ್ತು ನಕ್ಷೆಗಳ ರೆಂಡರಿಂಗ್ ಅನ್ನು ಸಾಧಿಸಲು ನಾನು ನಿರ್ವಹಿಸಿದ ನಂತರ, ಮೂಲಭೂತ ಅಸೆಂಬ್ಲಿ ಮೋಡ್ ಸಹ ಅಗತ್ಯವಿದೆ ಎಂದು ನಾನು ಅರಿತುಕೊಂಡೆ. ನಾನು ಇದನ್ನು ಈ ರೀತಿ ಕಾರ್ಯಗತಗೊಳಿಸಿದೆ: ಗುಂಡಿಯನ್ನು ಒತ್ತಿದಾಗ, ವಸ್ತುವನ್ನು ಆಯ್ಕೆಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಕ್ಲಿಕ್ ಅದನ್ನು ಬಯಸಿದ ಸ್ಥಳದಲ್ಲಿ ಇರಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ, ಬಟನ್ 1 ನಿಮಗೆ ನ್ಯಾಯಾಲಯವನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಬಟನ್ 2 ನಿಮಗೆ ಆಟಗಾರನನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ.

ಆದರೆ 1 ಮತ್ತು 2 ಅರ್ಥವೇನು ಎಂಬುದನ್ನು ನಾವು ಇನ್ನೂ ನೆನಪಿಟ್ಟುಕೊಳ್ಳಬೇಕು, ಆದ್ದರಿಂದ ಯಾವ ವಸ್ತುವನ್ನು ಆಯ್ಕೆ ಮಾಡಲಾಗಿದೆ ಎಂಬುದನ್ನು ಸ್ಪಷ್ಟಪಡಿಸಲು ನಾನು ವೈರ್‌ಫ್ರೇಮ್ ಅನ್ನು ಸೇರಿಸಿದೆ. ಈ ರೀತಿ ಕಾಣುತ್ತದೆ.

ಆರ್ಕಿಟೆಕ್ಚರ್ ಮತ್ತು ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಪ್ರಶ್ನೆಗಳು

ಈಗ ನಾನು ಹಲವಾರು ಆಟದ ವಸ್ತುಗಳನ್ನು ಹೊಂದಿದ್ದೇನೆ: ಜನರು, ನ್ಯಾಯಾಲಯಗಳು ಮತ್ತು ಮಹಡಿಗಳು. ಆದರೆ ವೈರ್‌ಫ್ರೇಮ್‌ಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸಲು, ಪ್ರತಿಯೊಂದು ವಸ್ತು ಘಟಕವು ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ಸ್ವತಃ ಪ್ರದರ್ಶನ ಕ್ರಮದಲ್ಲಿದೆಯೇ ಅಥವಾ ಫ್ರೇಮ್ ಅನ್ನು ಸರಳವಾಗಿ ಚಿತ್ರಿಸಲಾಗಿದೆಯೇ ಎಂದು ಹೇಳಬೇಕು. ಇದು ತುಂಬಾ ಅನುಕೂಲಕರವಲ್ಲ.

ಕೆಲವು ಮಿತಿಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸುವ ರೀತಿಯಲ್ಲಿ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಮರುಚಿಂತನೆ ಮಾಡಬೇಕಾಗಿದೆ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ:

ನಿರೂಪಿಸುವ ಮತ್ತು ನವೀಕರಿಸುವ ಘಟಕವನ್ನು ಹೊಂದಿರುವುದು ಒಂದು ಸಮಸ್ಯೆಯಾಗಿದೆ ಏಕೆಂದರೆ ಆ ಘಟಕವು ಏನನ್ನು ನಿರೂಪಿಸಬೇಕೆಂದು "ತಿಳಿಯಲು" ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ - ಚಿತ್ರ ಮತ್ತು ವೈರ್‌ಫ್ರೇಮ್;
ವೈಯಕ್ತಿಕ ಘಟಕಗಳ ನಡುವೆ ಗುಣಲಕ್ಷಣಗಳು ಮತ್ತು ನಡವಳಿಕೆಯನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುವ ಸಾಧನದ ಕೊರತೆ (ಉದಾಹರಣೆಗೆ, is_build_mode ಆಸ್ತಿ ಅಥವಾ ನಡವಳಿಕೆ ರೆಂಡರಿಂಗ್). ರಸ್ಟ್‌ನಲ್ಲಿ ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸರಿಯಾದ ಮಾರ್ಗವಿಲ್ಲದಿದ್ದರೂ, ಆನುವಂಶಿಕತೆಯನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ನನಗೆ ನಿಜವಾಗಿಯೂ ಬೇಕಾಗಿರುವುದು ಲೇಔಟ್;
ಜನರನ್ನು ನ್ಯಾಯಾಲಯಗಳಿಗೆ ನಿಯೋಜಿಸಲು ಘಟಕಗಳ ನಡುವಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಗೆ ಒಂದು ಸಾಧನದ ಅಗತ್ಯವಿದೆ;
ಘಟಕಗಳು ಸ್ವತಃ ಡೇಟಾ ಮತ್ತು ತರ್ಕದ ಮಿಶ್ರಣವಾಗಿದ್ದು ಅದು ತ್ವರಿತವಾಗಿ ನಿಯಂತ್ರಣದಿಂದ ಹೊರಬಂದಿತು.

ನಾನು ಇನ್ನೂ ಕೆಲವು ಸಂಶೋಧನೆಗಳನ್ನು ಮಾಡಿದ್ದೇನೆ ಮತ್ತು ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಕಂಡುಹಿಡಿದಿದ್ದೇನೆ ಇಸಿಎಸ್ - ಎಂಟಿಟಿ ಕಾಂಪೊನೆಂಟ್ ಸಿಸ್ಟಮ್, ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಆಟಗಳಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ. ECS ನ ಪ್ರಯೋಜನಗಳು ಇಲ್ಲಿವೆ:

ಡೇಟಾವನ್ನು ತರ್ಕದಿಂದ ಪ್ರತ್ಯೇಕಿಸಲಾಗಿದೆ;

ಪರಂಪರೆಯ ಬದಲಿಗೆ ಸಂಯೋಜನೆ;

ಡೇಟಾ ಕೇಂದ್ರಿತ ವಾಸ್ತುಶಿಲ್ಪ.

ECS ಅನ್ನು ಮೂರು ಮೂಲಭೂತ ಪರಿಕಲ್ಪನೆಗಳಿಂದ ನಿರೂಪಿಸಲಾಗಿದೆ:

ಘಟಕಗಳು - ಗುರುತಿಸುವಿಕೆ ಸೂಚಿಸುವ ವಸ್ತುವಿನ ಪ್ರಕಾರ (ಅದು ಆಟಗಾರ, ಚೆಂಡು ಅಥವಾ ಇನ್ನೇನಾದರೂ ಆಗಿರಬಹುದು);
ಘಟಕಗಳು - ಘಟಕಗಳು ಅವುಗಳಿಂದ ಮಾಡಲ್ಪಟ್ಟಿದೆ. ಉದಾಹರಣೆ - ರೆಂಡರಿಂಗ್ ಘಟಕ, ಸ್ಥಳಗಳು ಮತ್ತು ಇತರರು. ಇವು ಡೇಟಾ ಗೋದಾಮುಗಳು;
ವ್ಯವಸ್ಥೆಗಳು - ಅವು ವಸ್ತುಗಳು ಮತ್ತು ಘಟಕಗಳನ್ನು ಬಳಸುತ್ತವೆ, ಜೊತೆಗೆ ಈ ಡೇಟಾವನ್ನು ಆಧರಿಸಿದ ನಡವಳಿಕೆ ಮತ್ತು ತರ್ಕವನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ. ರೆಂಡರಿಂಗ್ ಘಟಕಗಳೊಂದಿಗೆ ಎಲ್ಲಾ ಘಟಕಗಳ ಮೂಲಕ ಪುನರಾವರ್ತಿಸುವ ಮತ್ತು ರೆಂಡರಿಂಗ್ ಮಾಡುವ ರೆಂಡರಿಂಗ್ ಸಿಸ್ಟಮ್ ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ.

ಅದನ್ನು ಅಧ್ಯಯನ ಮಾಡಿದ ನಂತರ, ಇಸಿಎಸ್ ಈ ಕೆಳಗಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಯಿತು:

ಘಟಕಗಳನ್ನು ವ್ಯವಸ್ಥಿತವಾಗಿ ಸಂಘಟಿಸಲು ಆನುವಂಶಿಕತೆಯ ಬದಲಿಗೆ ಲೇಔಟ್ ಅನ್ನು ಬಳಸುವುದು;
ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆಗಳ ಮೂಲಕ ಕೋಡ್ ಜಂಬಲ್ ಅನ್ನು ತೊಡೆದುಹಾಕುವುದು;
ವೈರ್‌ಫ್ರೇಮ್ ತರ್ಕವನ್ನು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಇರಿಸಲು is_build_mode ನಂತಹ ವಿಧಾನಗಳನ್ನು ಬಳಸುವುದು - ರೆಂಡರಿಂಗ್ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ.

ಇಸಿಎಸ್ ಅಳವಡಿಸಿದ ನಂತರ ಹೀಗಾಯಿತು.

ಸಂಪನ್ಮೂಲಗಳು -> ಇಲ್ಲಿಯೇ ಎಲ್ಲಾ ಸ್ವತ್ತುಗಳು (ಚಿತ್ರಗಳು)
Src
- ಘಟಕಗಳು
-position.rs
- person.rs
— tennis_court.rs
- floor.rs
- wireframe.rs
— mouse_tracked.rs
- ಸಂಪನ್ಮೂಲಗಳು
-mouse.rs
- ವ್ಯವಸ್ಥೆಗಳು
- rendering.rs
- ನಿರಂತರ.ಆರ್ಎಸ್
- utils.rs
— world_factory.rs -> ವರ್ಲ್ಡ್ ಫ್ಯಾಕ್ಟರಿ ಕಾರ್ಯಗಳು
— main.rs -> ಮುಖ್ಯ ಲೂಪ್

ನಾವು ಜನರನ್ನು ನ್ಯಾಯಾಲಯಗಳಿಗೆ ನಿಯೋಜಿಸುತ್ತೇವೆ

ಇಸಿಎಸ್ ಜೀವನವನ್ನು ಸುಲಭಗೊಳಿಸಿದೆ. ಈಗ ನಾನು ಘಟಕಗಳಿಗೆ ಡೇಟಾವನ್ನು ಸೇರಿಸಲು ಮತ್ತು ಆ ಡೇಟಾದ ಆಧಾರದ ಮೇಲೆ ತರ್ಕವನ್ನು ಸೇರಿಸಲು ವ್ಯವಸ್ಥಿತ ಮಾರ್ಗವನ್ನು ಹೊಂದಿದ್ದೇನೆ. ಮತ್ತು ಇದು ಪ್ರತಿಯಾಗಿ, ನ್ಯಾಯಾಲಯಗಳ ನಡುವೆ ಜನರ ವಿತರಣೆಯನ್ನು ಸಂಘಟಿಸಲು ಸಾಧ್ಯವಾಗಿಸಿತು.

ನಾನು ಏನು ಮಾಡಿದೆ:

ವ್ಯಕ್ತಿಗೆ ನಿಯೋಜಿಸಲಾದ ನ್ಯಾಯಾಲಯಗಳ ಬಗ್ಗೆ ಡೇಟಾವನ್ನು ಸೇರಿಸಲಾಗಿದೆ;
ಟೆನ್ನಿಸ್‌ಕೋರ್ಟ್‌ಗೆ ವಿತರಿಸಿದ ಜನರ ಬಗ್ಗೆ ಡೇಟಾವನ್ನು ಸೇರಿಸಲಾಗಿದೆ;
ಜನರು ಮತ್ತು ನ್ಯಾಯಾಲಯಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಲು, ಲಭ್ಯವಿರುವ ನ್ಯಾಯಾಲಯಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಮತ್ತು ಅವರಿಗೆ ಆಟಗಾರರನ್ನು ವಿತರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ CourtChoosingSystem ಅನ್ನು ಸೇರಿಸಲಾಗಿದೆ;
PersonMovementSystem ಅನ್ನು ಸೇರಿಸಲಾಗಿದೆ, ಇದು ನ್ಯಾಯಾಲಯಗಳಿಗೆ ನಿಯೋಜಿಸಲಾದ ಜನರನ್ನು ಹುಡುಕುತ್ತದೆ ಮತ್ತು ಅವರು ಅಲ್ಲಿ ಇಲ್ಲದಿದ್ದರೆ, ಜನರನ್ನು ಅವರು ಇರಬೇಕಾದ ಸ್ಥಳಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ.

ಸಂಕ್ಷಿಪ್ತವಾಗಿ

ಈ ಸರಳ ಆಟದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಾನು ನಿಜವಾಗಿಯೂ ಆನಂದಿಸಿದೆ. ಇದಲ್ಲದೆ, ನಾನು ಅದನ್ನು ಬರೆಯಲು ರಸ್ಟ್ ಅನ್ನು ಬಳಸಿದ್ದೇನೆ ಎಂದು ನನಗೆ ಖುಷಿಯಾಗಿದೆ, ಏಕೆಂದರೆ:

ತುಕ್ಕು ನಿಮಗೆ ಬೇಕಾದುದನ್ನು ನೀಡುತ್ತದೆ;
ಇದು ಅತ್ಯುತ್ತಮ ದಸ್ತಾವೇಜನ್ನು ಹೊಂದಿದೆ, ರಸ್ಟ್ ಸಾಕಷ್ಟು ಸೊಗಸಾದ;
ಸ್ಥಿರತೆ ತಂಪಾಗಿದೆ;
ನೀವು ಅಬೀಜ ಸಂತಾನೋತ್ಪತ್ತಿ, ನಕಲು ಅಥವಾ ಇತರ ರೀತಿಯ ಕ್ರಿಯೆಗಳನ್ನು ಆಶ್ರಯಿಸಬೇಕಾಗಿಲ್ಲ, ನಾನು ಆಗಾಗ್ಗೆ C++ ನಲ್ಲಿ ಮಾಡಿದ್ದೇನೆ;
ಆಯ್ಕೆಗಳು ಬಳಸಲು ತುಂಬಾ ಸುಲಭ ಮತ್ತು ದೋಷಗಳನ್ನು ಚೆನ್ನಾಗಿ ನಿಭಾಯಿಸುತ್ತವೆ;
ಯೋಜನೆಯನ್ನು ಕಂಪೈಲ್ ಮಾಡಲು ಸಾಧ್ಯವಾದರೆ, 99% ಸಮಯ ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ನಿಖರವಾಗಿ ಅದು ಮಾಡಬೇಕು. ಕಂಪೈಲರ್ ದೋಷ ಸಂದೇಶಗಳು ನಾನು ನೋಡಿದ ಅತ್ಯುತ್ತಮವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

ರಸ್ಟ್‌ನಲ್ಲಿ ಆಟದ ಅಭಿವೃದ್ಧಿಯು ಕೇವಲ ಪ್ರಾರಂಭವಾಗಿದೆ. ಆದರೆ ಎಲ್ಲರಿಗೂ ರಸ್ಟ್ ಅನ್ನು ತೆರೆಯಲು ಈಗಾಗಲೇ ಸ್ಥಿರ ಮತ್ತು ಸಾಕಷ್ಟು ದೊಡ್ಡ ಸಮುದಾಯವು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ. ಆದ್ದರಿಂದ, ನಾನು ಭಾಷೆಯ ಭವಿಷ್ಯವನ್ನು ಆಶಾವಾದದಿಂದ ನೋಡುತ್ತೇನೆ, ನಮ್ಮ ಸಾಮಾನ್ಯ ಕೆಲಸದ ಫಲಿತಾಂಶಗಳನ್ನು ಎದುರು ನೋಡುತ್ತಿದ್ದೇನೆ.

ಸ್ಕಿಲ್‌ಬಾಕ್ಸ್ ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ:

ಆನ್‌ಲೈನ್ ಕೋರ್ಸ್ "ವೃತ್ತಿ ಮುಂಭಾಗದ ಡೆವಲಪರ್".

ಪ್ರಾಯೋಗಿಕ ಕೋರ್ಸ್ "ಮೊಬೈಲ್ ಡೆವಲಪರ್ ಪ್ರೊ".

ಪ್ರಾಯೋಗಿಕ ಒಂದು ವರ್ಷದ ಕೋರ್ಸ್ "0 ರಿಂದ PRO ವರೆಗೆ PHP ಡೆವಲಪರ್".

ಮೂಲ: www.habr.com

24 ಗಂಟೆಗಳಲ್ಲಿ ರಸ್ಟ್ ನುಡಿಸುವಿಕೆ: ವೈಯಕ್ತಿಕ ಅಭಿವೃದ್ಧಿ ಅನುಭವ