Що я можу зробити, щоб уникнути одноразових прапорців та перевірок у всьому коді?

Розгляньте карткову гру, наприклад, Hearthstone .

Є сотні карток, які роблять найрізноманітніші речі, деякі з яких унікальні навіть для однієї карти! Наприклад, є картка (звана Nozdormu), яка зменшує кількість поворотів гравця до лише 15 секунд!

Якщо у вас є така велика кількість потенційних ефектів, як уникнути магічних чисел та одноразових перевірок у всьому коді? Як уникнути методу "Check_Nozdormu_In_Play" у класі PlayerTurnTime? І як можна організувати код таким чином, що коли ви додаєте ще більше ефектів, вам не потрібно переробляти основні системи, щоб підтримувати речі, які їм ніколи не доводилося підтримувати?

Ви вивчали компоненти компонентних систем та стратегії обміну подіями?

Ефекти статусу повинні бути деякими компонентами, які можуть застосовувати свої стійкі ефекти в методі OnCreate (), закінчувати свої ефекти в OnRemoved () і підписуватись на повідомлення про події гри, щоб застосовувати ефекти, які виникають як реакція на щось, що відбувається.

Якщо ефект стійкий до умовного (триває Х витків, але застосовується лише за певних обставин), можливо, вам доведеться перевірити ці умови на різних фазах.

Тоді ви просто переконайтеся, що у вашій грі також немає магічних чисел за замовчуванням. Переконайтеся, що все, що можна змінити, - це змінна, керована даними, а не жорсткі коди за замовчуванням зі змінними, що використовуються для будь-яких винятків.

Таким чином, ви ніколи не припускаєте, якою буде довжина повороту. Це завжди постійно перевіряється змінна, яку можна змінити будь-яким ефектом і, можливо, відмінити пізніше ефект, коли він закінчується. Ви ніколи не перевіряєте винятки, перш ніж дефолтуватимете свій магічний номер.

RobStone на вірному шляху, але я хотів доопрацювати, оскільки це саме те, що я робив, коли писав Dungeon Ho !, розбійник, який мав дуже складну систему ефектів для зброї та заклинань.

Кожна карта повинна мати доданий до неї набір ефектів, визначений таким чином, щоб він міг вказувати, що таке ефект, на що націлений, як і на який термін. Наприклад, ефект "пошкодження противника" може виглядати приблизно так;

Effect type: deal damage (enumeration, string, what-have-you)
Effect amount: 20
Source: my weapon
Target: opponent
Effect Cost: 20
Cost Type: Mana

Тоді, коли ефект спрацьовує, потрібно загальну рутину обробляти обробкою ефекту. Як ідіот, я використав величезний випадок case / switch:

switch (effect_type)
{
     case DAMAGE:

     break;
}

Але набагато кращий і більш модульний спосіб зробити це через поліморфізм. Створіть клас Effect, який охоплює всі ці дані, створіть підклас для кожного типу ефектів, а потім перекладіть цей клас на метод onExecute (), характерний для класу.

class Effect
{
    Object source;
    int amount;

    public void onExecute(Object target)
    {
          // Do nothing
    }
}

class DamageEffect extends Effect
{
    public void onExecute(Object target)
    {
          target.health -= amount;
    }
}

Отже, у нас був би базовий клас Effect, потім клас DamageEffect методом onExecute (), тому в нашому коді обробки ми просто переходимо;

Effect effect = card.getActiveEffect();

effect.onExecute();

Спосіб вирішити питання про те, що грає, це створити вектор / масив / пов'язаний список / тощо. активних ефектів (типу Effect, базовий клас), прикріплених до будь-якого об'єкта (включаючи ігрове поле / "гру"), тому замість того, щоб перевіряти, чи є певний ефект у грі, ви просто перегляньте всі ефекти, що додаються до об'єкт (-ів) і нехай вони виконують. Якщо ефект не додається до об'єкта, він не відтворюється.

Effect effect;

for (int o = 0; o < objects.length; o++)
{
    for (int e = 0; e < objects[o].effects.length; e++)
    {
         effect = objects[o].effects[e];

         effect.onExecute();
    }
}

Я запропоную кілька пропозицій. Деякі з них суперечать один одному. Але, можливо, деякі корисні.

Розгляньте списки проти прапорів

Ви можете переглядати по всьому світу та перевіряти прапор на кожному елементі, щоб вирішити, чи робити прапор. Або ви можете зберегти список лише тих предметів, які повинні робити прапор.

Розгляньте списки та перерахування

Ви можете продовжувати додавати булеві поля до класу позицій, це ТАК і це. Або у вас може бути список рядків або елементів перерахунків, наприклад {"isAThis", "isAThat"} або {IS_A_THIS, IS_A_THAT}. Таким чином ви можете додавати нові в перерахунку (або рядкові строки) без додавання полів. Не те, що насправді щось не так з додаванням полів ...

Розглянемо функціональні покажчики

Замість списку прапорів або перерахунків може бути список дій, які потрібно виконати для цього елемента в різних контекстах. (Entity-ish…)

Розгляньте об’єкти

Деякі люди вважають за краще підходи, керовані даними, або сценарії, або компоненти компонентів. Але також варто врахувати старомодні ієрархії об'єктів. Базовий клас повинен прийняти такі дії, як "грати в цю карту для покрокової фази B" або будь-що інше. Тоді кожен тип карт може переосмислити та відповісти, якщо це доречно. Напевно, є також об’єкт гравця та ігровий об’єкт, тому гра може робити такі речі, як, якщо (player-> isAllowedToPlay ()) {do play ...}.

Розглянемо можливість налагодження

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

Зрештою, рефакторинг: Розгляньте одиничні тести

Скільки б ви не узагальнили свою архітектуру, ви зможете уявити речі, які вона не охоплює. Тоді вам доведеться зробити рефактор. Може, небагато, може, багато.

Спосіб зробити це безпечнішим - це тест одиничних тестів. Таким чином, ви можете бути впевнені, що навіть якщо ви переставляли речі під ними (можливо, багато!), Існуюча функціональність все ще працює. Кожен блок тесту виглядає, як правило, так:

void test1()
{
   Game game;
   game.addThis();
   game.setupThat(); // use primary or backdoor API to get game to known state

   game.playCard(something something).

   int x = game.getSomeInternalState;
   assertEquals(“did it do what we wanted?”, x, 23); // fail if x isn’t 23
}

Як бачимо, для забезпечення стабільності цих викликів API вищого рівня щодо гри (або гравця, картки та ін.) Є ключовим у стратегії тестування одиниць.

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

Це, по суті, міні-складова система, де кожен об’єкт «картки» є просто контейнером для групи компонентів ефекту.