ECS

Veloren იყენებს Entity Component System (ECS). ეს არის შედარებით ახალი პარადიგმა თამაშის ძრავის განვითარებაში კონკურენციას უწევს ტრადიციულ ობიექტზე ორიენტირებულ დიზაინის მოდელებს, რომლებიც ინტენსიურად იყენებენ იერარქიას, მემკვიდრეობას და პოლიმორფიზმი. ის მოუწოდებს თამაშის დეველოპერებს შეიმუშაონ მონაცემთა სტრუქტურები ისე, რომ შესაძლებელი იყოს ეფექტური პარტია მონაცემთა დამუშავება თანამედროვე პროცესორის არქიტექტურებზე ღრმა ქეშით, მეხსიერებაში შენახული მონაცემების შენახვით.

ტრადიციულად, თამაშში ერთეულების წარმოდგენა ასე ხდება:

#![allow(unused)]
fn main() {
struct Entity {
    position: Vec3<f32>,
    velocity: Vec3<f32>,
}
}

მრავალი ერთეულის წარმოდგენისას, ჩვეულებრივია მონაცემთა მასივის მსგავსი სტრუქტურის გამოყენება.

#![allow(unused)]
fn main() {
struct World {
    entities: Vec<Entity>,
}
}

თუმცა, ამას პრობლემები მოჰყვება. თანამედროვე პროცესორებს აქვთ ღრმა ქეში, რაც იმას ნიშნავს, რომ ისინი მნიშვნელოვნად უფრო სწრაფად წვდებიან მეხსიერება, რომელიც მისამართთა სივრცეში უფრო ახლოს არის მეხსიერებასთან, რომელიც უკვე მიუწვდომელია. შენახვის ყველაზე ეფექტური ფორმატების პაკეტი მონაცემთა დამუშავება მეხსიერებაში ძალიან ახლოს. ჩვენი ამჟამინდელი წარმომადგენლობა ასე გამოიყურება:

| Entity 0            | Entity 1            | Entity 2            |
|---------------------|---------------------|---------------------|
| position | velocity | position | velocity | position | velocity |

წარმოვიდგინოთ „ტიპიური“ ოპერაცია, რომლის შესრულებაც გვსურს: გრავიტაციის გამოყენება ერთეულებზე. ეს გულისხმობს დამატებას 9.81 ვერტიკალური სიჩქარით თითოეული ერთეულისთვის. სამწუხაროდ, ამ ოპერაციის წვდომის ნიმუში მოიცავს თითოეულ velocity ველზე შეხება, მაგრამ თითოეული position ველის გამოტოვება. ჩვენს მონაცემებში არსებული ეს ხარვეზები ანელებს ოპერაციას. In ტექნიკური ჟარგონი, ჩვენ ამას ვუწოდებთ “ქეში თანმიმდევრულობის” ნაკლებობას.

ყველაფერი არ არის დაკარგული.

დიზაინის ნიმუში, რომლის შესახებაც შეიძლება გსმენიათ, ეწოდება Struct Of Arrays, ან SOA. ის ვარაუდობს, რომ შეფუთვის ნაცვლად თითოეულ ობიექტთან დაკავშირებული მონაცემები ერთ ადგილზე ერთად, ჩვენ უნდა დავაჯგუფოთ მონაცემები მისი მიზნის მიხედვით.

#![allow(unused)]
fn main() {
struct World {
    positions: Vec<Vec3<f32>>,
    velocities: Vec<Vec3<f32>>,
}
}

ახლა ჩვენი წარმოდგენა ბევრად უფრო მჭიდროდ არის შეფუთული და ჩვენი გრავიტაციის გამოყენება ერთეულებზე უფრო ეფექტურია, რადგან ჩვენ აღარ გვჭირდება პოზიციის მონაცემების გამოტოვება ერთეულის სიჩქარის გამეორებისას.

| Entity 0 | Entity 1 | Entity 2 |     | Entity 0 | Entity 1 | Entity 2 |
|----------|----------|----------| ... |----------|----------|----------|
| position | position | position |     | velocity | velocity | velocity |

ECS არის ეს იდეა მის ლოგიკურ დასკვნამდე: ერთეულები, როგორც კომპონენტების ასოცირებული, მაგრამ ცალკეული კოლექციები თითოეული ტიპის კომპონენტი ინახება თავის ცალკეულ შესანახ ბუფერში. ამ მიდგომას აქვს მეტი უპირატესობაც: იმიტომ კომპონენტები ინახება ცალ-ცალკე, მარტივი და სწრაფია კომპონენტების დამატება ან ამოღება ერთეულიდან თამაშის გაშვებისას, რითაც ცვლის სუბიექტის ქცევას და მის შესაძლებლობებს. ეს საოცრად ძლიერი ტექნიკაა და საშუალებას იძლევა რამხელა უნარი რადიკალურად შეცვალოს თამაშის ქცევა და მასში შემავალი ერთეულები თამაშის დროს გაშვებული და შესრულების შეწირვის გარეშე.

სპეციფიკური ECS ყუთი, რომელსაც Veloren იყენებს არის SPECS. შეგიძლიათ მეტი წაიკითხოთ ECS და სპეციფიკა, თუ როგორ მუშაობს SPECS აქ. თუ თქვენ ეძებთ მუშაობას ძალიან, მე დაჟინებით გირჩევთ წაიკითხოთ ეს რესურსი თავიდან ბოლომდე (ეს საკმაოდ მოკლეა).