Англійська мова для розробників Bevy Game

Розмови Bevy зазвичай включають пояснення шаблону сущість-компонент-система (ECS) для розробників, що походять з об’єктно-орієнтованих ігрових рушіїв, тому словник включає сущості, компоненти, системи і модель планування, яка регулює те, як вони взаємодіють.

Ключовий словник

** Entity- component- system (ECS) ** — архітектурний шаблон Bevy, де об’ єкти гри (суб’ єкти) є лише ідентифікаторами, дані, що визначають поведінку, приєднані як компоненти, а логіка живе в окремих системах, які працюють на суб’ єктах, що відповідають заданому набору компонентів. “Не існує класу Player тут — в моделі сутність-компонент-система, гравець є просто сутністю з Health, Position, і PlayerControlled компонентом приєднаним.”

** Компонент ** — простий об’ єкт даних, приєднаний до сутності, що утримує стан, але не поведінку, за якою системи запиту будуть стежити під час прийняття рішення щодо того, які сутності слід використовувати. “Додати компонент Stunned до сутності замість булівського поля на якійсь монолітній структурі — тоді будь-яка система, яка повинна пропускати оглушені сутності, може просто запитати про її відсутність.”

** System ** — функція, яка запитує сутності з певними компонентами і діє на них у кожному кадрі, представляючи одну частину логіки гри, відокремлену від будь- якого конкретного типу сутності. “Напишіть це як власну систему, яка запитує Velocity і Position — не закопуйте логіку руху всередині системи, яка повинна обробляти бій.”

** Запит ** — механізм, за допомогою якого системи надають запит на набір об’ єктів, які відповідають підпису компонента, за бажанням далі фільтрують, надаючи безпечний з точки зору типів, ефективний доступ до даних, які потрібні системі. “Цей запит повинен фільтрувати With<Enemy> і виключити With<Dead> — зараз він також ітерує над мертвими ворогами, тому вони продовжують атакувати після смерті.”

** Розклад / впорядкування систем ** — Механізм Bevy для керування тим, коли системи виконуються відносно одна до одної у рамках, включаючи явні обмеження впорядкування, щоб уникнути перегонів між системами, які читають і записують ті ж дані. “Ці дві системи мутують Position — додають явне обмеження порядку в розкладі, тому ми не покладаємося на порядок реєстрації, щоб уникнути гонки.”

Звичайні фрази

• Чи має це бути його власною складовою, чи це просто поле, що належить до існуючого?»
• Чи є ця логіка в правильній системі, чи це кровотеча відповідальності, яка належить десь іншому?»
• «Чи потребує цей запит додаткового фільтра, чи це тому, що мертві об’єкти все ще обробляються?»
• «Чи є порядок між цими двома системами явно в розкладі, або ми покладаємося на порядок реєстрації?»

Приклади висловлювань

Пояснення архітектури комусь, хто має досвід роботи з OOP: “Не існує ієрархії успадкування тут — поведінка виникає з того, які компоненти має суб’єкт, і системи просто запитують компоненти, які їх цікавлять, незалежно від того, що суб’єкт ‘є’.”

Неочікуване поводження під час зневадження: “Перевірте фільтри цього запиту — якщо він не виключає сутності з компонентом Dead, це пояснює, чому переможені вороги все ще беруть свій хід.”

Перегляд умов гонки: “Ці дві системи записують до одного і того ж компонента без явного обмеження порядку — додайте одне до розкладу, щоб ми не залежали від порядку реєстрації для коректності.”

Професійні поради

• Ввести систему суспільств-компонентів, контрастуючи її безпосередньо з ієрархією класів — це найшвидший спосіб переорієнтувати розробників, що прийшли з традиційних рушіїв ООП.
• Заохочуйте малі, зосереджені ** компоненти ** на великих структурах з багатьма додатковими полями — це зберігає точність запитів і уникнення обробки системою незначних даних.
• Утримувати кожну ** систему ** виконуючи одну річ — система, що обробляє рух, пошкодження і анімацію разом є спільною метою рефакторингу, позначеним у перегляді.
• Прапорець відсутності явного впорядкування у ** розкладі **, коли дві системи мутують один і той же компонент — неявне впорядкування є поширеним джерелом вади, яку важко відтворити.

Практичні вправи

1. Пояснити модель сутність- компонент- система комусь, хто звик до успадкування за класами в ігрових рушіях.
2. Опишемо, чому запит може потребувати додаткового фільтра, використовуючи приклад мертвої сутності.
3. Напишіть речення, у якому поясните співробітнику команди, чому дві системи потребують явного обмеження порядку у розкладі.

На практиці: Навігація Nuance в командному спілкуванні

Багато розробників, які вивчають професійну англійську, вважають, що просто перекладати слова недостатньо. * Спосіб *, у який ви спілкуєтеся — формулювання, рівень деталізації, навіть тонкі підказки — може значно вплинути на те, як ваші ідеї приймаються і розуміються командою розробників. Розглянемо деякі типові сценарії, де точність має величезне значення при використанні словника, пов’ язаного з архітектурою ECS Bevy і системним плануванням.

Одна з найчастіших ситуацій виникає під час перегляду коду. Уявіть, що ви переглядаєте публікацію колеги, яка вводить новий компонент для керування здоров’ ям гравця. Замість того, щоб сказати: «Це добре, але може додати час охолодження?», - що може здатися неясним - це набагато ефективніше надати конструктивний зворотній зв’язок, використовуючи конкретну термінологію. Ви можете сказати: «Реалізація CooldownSystem виглядає здорово, проте, я рекомендую додати залежність введення для TimeService, щоб забезпечити послідовне час у різних контекстах планування. Зокрема, розгляньте можливість використання Ticker замість прямого запиту системного годинника в логіці вашої системи; це краще відповідає принципам від’єднання Bevy і уникнення потенційних умов гонки. Крім того, документування логіки, яка стоїть за вибором підходу — пояснення * чому * Ticker є кращим за прямий доступ до годинника — значно поліпшить підтримку. » Це показує, що ви розумієте основні концепції і пропонуєте цілеспрямовані рекомендації.

Іншою областю, де нюансована фраза стає критичною, є розмови Slack при обговоренні пріоритетів системного планування. Просте « Ця система має бути запущена спочатку » не зможе цього зробити. Вам потрібно пояснити * чому * певна система має мати вищий пріоритет. Наприклад, «Ураховуючи, що RenderingSystem залежить від даних, оброблених MovementSystem, пріоритет MovementSystem забезпечує плавні оновлення анімації і запобігає візуальному зависання. Ми можемо дослідити налаштування алгоритму планування, щоб відобразити цю залежність — можливо, підвищити його пріоритет на один рівень.» Цей підхід показує, що ви розглянули потенційні наслідки і активно пропонуєте рішення.

Нарешті, створення чітких описів PR є надзвичайно важливим для співпраці. Замість короткого резюме типу « Виправлено помилку », постарайтеся вказати детальніше: « Виправлено проблему, коли об’ єкти гравця періодично зникали після виконання дії стрибка через умову перегонів у системі виявлення зіткнень. Впроваджено блокування mutex навколо оновлення списку об’ єктів, щоб забезпечити безпечний доступ потоків і запобігти пошкодженню даних. Додано тести на окремі елементи, що охоплюють цей сценарій, зокрема, крапкові випадки, що включають високу швидкість руху гравця. Цей рівень деталізації дозволяє рецензентам швидко зрозуміти проблему, розв’ язати її і оцінити її вплив.

Ось приклад використання інструменту командного рядка Bevy ( bevy_generate ) для створення простої системи, яка обробляє базовий рух:

bevy_generate --name MovementSystem --description "A system for moving entities based on input" --output_path src/movement.rs

Це створює файл src/movement.rs з базовим реалізацією руху, що забезпечує матеріальний приклад для подальшого обговорення.