Як реалізувати «картки спеціальних ефектів» у торговій картці?

Я намагаюся написати тут якусь гру торгових карт, якимось чином це схожа на Magic The Gathering , або на Yu-Gi-Oh! карткова гра.

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

Щоб дати вам уявлення про те, які ефекти можуть мати ці картки, ось декілька прикладів ефектів карт орфографії, які присутні у Yu-Gi-Oh! карткова гра:

• Відроджуй істоту, яку знищили
• Візьміть під контроль істоту супротивника
• Змініть статистику істоти на основі деяких умов (наприклад, кількість істоти з певними іменами, які були знищені)
• Спеціально викликайте певних істот, якщо деякі умови виконуються.
• Сплавте дві чи більше істот у більш сильну істоту.
• Імунітет до дії спеціальних карт.

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

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

Існує декілька проектів з відкритим кодом такого типу, з різними підходами до реалізації правил. Ось запис у блозі від творця однієї з найбільш відомих реалізацій MtG, CardForge. Це може бути не повний список, але він містить кілька проектів з відкритим кодом, де ви можете просто переглянути код або відвідати форуми для конкретних питань.

Як реальна відповідь: Ваша найкраща ставка для надійної основи - суворо використовувати об'єктно-орієнтоване програмування. Кожна дія, кожен тригер, кожна здатність є об'єктом. Зони, як "Рука", "Бібліотека" - теж об'єкти, зайве говорити. У механізмі Правил ніколи не обмінюйте тупі об’єкти, як рядки чи цілі числа, щоб описувати ігрові об’єкти, а лише ваші об’єкти.

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

Потім ви опрацьовуєте ці стеки відповідно до правил гри, поки стек не порожній, і в цей момент можна вжити нових дій і т.д.

В ідеалі, якщо ви досконало виконуєте правила гри, код ваших правил не містить жодної картки з твердим кодом. Карти жорсткого кодування можуть створювати зручні ярлики, але з часом це розмиє ваш код і створить потенційні підводні камені, наприклад, коли випускаються нові картки, які взаємодіють із цими картками по-новому. У такій грі, як MtG з більш ніж 12 000 унікальних карт і не видно кінця, є багато таких взаємодій.

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

Я також планую карткові ігри з використанням веб-мов з mysql db. В даний час я збираюся зробити дуже загальну настройку, тому вона дуже гнучка до нових унікальних карт. Наприклад, замість:

reduceHitPoints() { } 
reduceMana() { }
reduceSpeed() { }

це легко може бути:

reduce($attacker, $target, $reduceWhat, $amount) { }
massReduce($attacker, Array $targets, $reduceWhat, $amount) { }

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

Усі параметри та здібності будуть визначені в db в цьому одному рядку.