Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 65
дфы олваждфыо вадлфо ыав
я в очередной раз в восхищении!
кстати, тебе не кажется, что пора бы завести проект на каком-нибудь codeplex, чтобы все желающие могли глянуть полную версию кода? :)
кстати, тебе не кажется, что пора бы завести проект на каком-нибудь codeplex, чтобы все желающие могли глянуть полную версию кода? :)
присоединяюсь!
кстати, а МТГ не защищена какими-то копирастами?
кстати, а МТГ не защищена какими-то копирастами?
Естественно M:tG защищена законом об авторском праве.
ну если начать делать проект, то ведь не обязательно использовать карты мтг… вполне можно и свои придумать\нарисовать.
такая мегамеханика, как поворот карты на 90 градусов — защищена копирастами, так что придумывать своё можно (в России придумали похожу игру — Берсерк), но вот поворачивать для обозначения состояния — нельзя :)
а на 83 градуса можно? или ставить на спец. подставочку?
«In one embodiment of the invention, tapping a card means turning it approximately horizontally or 90 degrees from vertical.»
я не законник, не знаю как это трактовать — можно или нет :) но на подставочку — точно можно.
я не законник, не знаю как это трактовать — можно или нет :) но на подставочку — точно можно.
, но запатентовать сам поворот… не знаю реально ли. В Берсерке например он есть, называется «закрытие».
VS-System, World of Warcraft: TCG, Yu-gi-oh!, Mapple, Берсерк (да, они тоже умеют поворачивать картонки), Война и ещё с десяток игр об этом, видимо, не знают.
Приведите, пожалуйста, ссылку, подтверждающую, что «такая мегамеханика, как поворот карты на 90 градусов — защищена копирастами», или сознайтесь в своей некомпетентности перед лицом фактов.
Приведите, пожалуйста, ссылку, подтверждающую, что «такая мегамеханика, как поворот карты на 90 градусов — защищена копирастами», или сознайтесь в своей некомпетентности перед лицом фактов.
Видимо тут
Вы не разобрались в вопросе, впрочем, спасибо за минус.
Ещё раз:
Запатентован символ и условное текстовое обозначение «tap».
WoW, VS-System: activate
Cthulhu TCG: exhaust
Yu-gi-oh!: change battle position
Берсерк: закрыть
Ещё раз:
Запатентован символ и условное текстовое обозначение «tap».
WoW, VS-System: activate
Cthulhu TCG: exhaust
Yu-gi-oh!: change battle position
Берсерк: закрыть
да что вы говорите? )
Trading card game method of play
Trading card game method of play
Вы умеете читать?
Там указан термин tap, что он значит и для чего используется.
«Tapping a card means turning it approximately horizontally», да и собственно с 14 страницы, раздел Tapping and Untapping. Символ, слово.
А по-вашему выходит, что кроме Wizards of The Coast никто не может картон на столе поворачивать.
Тем не менее, это используют все настолки, но слово tap и визардовский символ (на который кстати, трейдмарк есть соответствующий) использует только magic.
Там указан термин tap, что он значит и для чего используется.
«Tapping a card means turning it approximately horizontally», да и собственно с 14 страницы, раздел Tapping and Untapping. Символ, слово.
А по-вашему выходит, что кроме Wizards of The Coast никто не может картон на столе поворачивать.
Тем не менее, это используют все настолки, но слово tap и визардовский символ (на который кстати, трейдмарк есть соответствующий) использует только magic.
то что вы умеете читать, мы поняли, а конкретно патенты читать умеете?
запатентовано 6 пунктов:
…
тап:
4. The method of claim 3, wherein said step of designating one or more cards on the playing surface from an original orientation to a second orientation.
5. The method of claim 3, wherein said second orientation is 90 degrees from the first orientation
антап:
6. The method of claim 3, wherein said step of executing a turn comprises the initial step of rotating the player's cards previously designated in a prior turn from the second orientation to original orientation.
успокойтесь уже, тап запатентован как игровая механика этим патентом, а не как конкретное название (все значки на картах и слова «tap», «untap» и др., понятно, тоже зарегистрированы, но это к делу не имеет отношения).
Upperdeck (производитель большинства из приведённых вами игр) абсолютно точно платит лицензионные отчисления компании Wizards. Платит ли что либо Мир Фэнтези, или им положить на этот патент — я не знаю, но в принципе узнать можно.
запатентовано 6 пунктов:
…
тап:
4. The method of claim 3, wherein said step of designating one or more cards on the playing surface from an original orientation to a second orientation.
5. The method of claim 3, wherein said second orientation is 90 degrees from the first orientation
антап:
6. The method of claim 3, wherein said step of executing a turn comprises the initial step of rotating the player's cards previously designated in a prior turn from the second orientation to original orientation.
успокойтесь уже, тап запатентован как игровая механика этим патентом, а не как конкретное название (все значки на картах и слова «tap», «untap» и др., понятно, тоже зарегистрированы, но это к делу не имеет отношения).
Upperdeck (производитель большинства из приведённых вами игр) абсолютно точно платит лицензионные отчисления компании Wizards. Платит ли что либо Мир Фэнтези, или им положить на этот патент — я не знаю, но в принципе узнать можно.
К моему сожалению, вы написали раньше меня.
Всё так, действительно. И это погрузило меня в бездну отчаяния.
Примите мои извинения.
Про Мир Фэнтези, если не трудно, узнайте.
Всё так, действительно. И это погрузило меня в бездну отчаяния.
Примите мои извинения.
Про Мир Фэнтези, если не трудно, узнайте.
И всё-таки, они обладают права на тап как индикатор использования карты.
В югио, например, ориентация карты несёт другой смысл, но они наверняка тоже платят.
В югио, например, ориентация карты несёт другой смысл, но они наверняка тоже платят.
Насколько мне объясняли коллеги, патенты США не работают в Европе, и наоборот. :)
Насчет минуса — это не ко мне. Я такими глупостями не занимаюсь.
За разъяснение спасибо — теперь буду знать.
Не подскажете ли, где вы почерпнули эту информацию, дабы я мог с ней так же ознакомиться?
За разъяснение спасибо — теперь буду знать.
Не подскажете ли, где вы почерпнули эту информацию, дабы я мог с ней так же ознакомиться?
www.google.com/patents?id=ixoMAAAAEBAJ — US Patent 5662332
А что, разве для опенсорсного варианта нужно покупать патенты?
Классно, что Вы разбираете такие примеры, но вот таких карт в бустерах никому не пожелаю!
Укажите, пожалуйста, ссылку на первую часть в начале статьи.
Как и в первой части, твёрдое предположение, что карты выводятся за ману. Но мана — это просто переменная, одна из тех, которыми может оплачиваться способность карты переходить из руки в игру. sales.starcitygames.com/cardscans/MAGALL/force_of_will.jpg
Далее, проверка на легендарность — в принципе можно и так, но логичнее всё же не делать многоуровневую проверку, а списать все прописанные в ней подтипы в отдельные поля. Просто потому, что карта не только легендарной может быть, подтипов дополняющих хватает… Например — sales.starcitygames.com/cardscans/MAGALL/force_of_will.jpg
Веселее всего с заменой типов текстом карты
sales.starcitygames.com/cardscans/MAGALP/underground_sea.jpg
Далее, проверка на легендарность — в принципе можно и так, но логичнее всё же не делать многоуровневую проверку, а списать все прописанные в ней подтипы в отдельные поля. Просто потому, что карта не только легендарной может быть, подтипов дополняющих хватает… Например — sales.starcitygames.com/cardscans/MAGALL/force_of_will.jpg
Веселее всего с заменой типов текстом карты
sales.starcitygames.com/cardscans/MAGALP/underground_sea.jpg
Draw three cards
RequiresTap =false true
Спасибо, интересно. Ждем продолжения. Я правильно понял, что все живет в Game и каждая карта может менять все в этом объекте?
RequiresTap =
Спасибо, интересно. Ждем продолжения. Я правильно понял, что все живет в Game и каждая карта может менять все в этом объекте?
Как вы будете обрабатывать карты, у которых в тексте написано, что они любого типа, например? Не разумнее было бы сделать функцию bool IsType(string Type)? Или вовсе завести отдельный класс Type и переопределить у него Equal? На нем также можно было бы определить операцию композиции типов и т.д. Я считаю, это хорошая музыка. А в вашей реализации, как минимум, карты на русском и на английском языке будут всегда иметь разные типы.
Как вы планируете обрабатывать сложные абилики, которые срабатывают «по событию»? Понятно, что скорее всего при помощи этих самых событый, но события бывают очень сложными, так что заранее предопределенных событый не напасешься.
Кроме того, на карту может быть помещен жетон, карта может быть разным образом связана с другими картами (за-enchanc'ена или как-то еще, я давно не играл), и должна знать об этих связях, чтобы корректно уметь обработать абилку а-ля «remove all coins from the XXX'.
Как вы планируете обрабатывать сложные абилики, которые срабатывают «по событию»? Понятно, что скорее всего при помощи этих самых событый, но события бывают очень сложными, так что заранее предопределенных событый не напасешься.
Кроме того, на карту может быть помещен жетон, карта может быть разным образом связана с другими картами (за-enchanc'ена или как-то еще, я давно не играл), и должна знать об этих связях, чтобы корректно уметь обработать абилку а-ля «remove all coins from the XXX'.
Как вы будете обрабатывать карты, у которых в тексте написано, что они любого типа, например? Не разумнее было бы сделать функцию bool IsType(string Type)? Или вовсе завести отдельный класс Type и переопределить у него Equal? На нем также можно было бы определить операцию композиции типов и т.д. Я считаю, это хорошая музыка. А в вашей реализации, как минимум, карты на русском и на английском языке будут всегда иметь разные типы.
Разберусь когда до этого дойду.
Как вы планируете обрабатывать сложные абилики, которые срабатывают «по событию»? Понятно, что скорее всего при помощи этих самых событый, но события бывают очень сложными, так что заранее предопределенных событый не напасешься.
Ну почему, с метапрограммным подходом можно нагенерировать события чуть ли не на все, что может произойти в игре.
Кроме того, на карту может быть помещен жетон, карта может быть разным образом связана с другими картами (за-enchanc’ена или как-то еще, я давно не играл), и должна знать об этих связях, чтобы корректно уметь обработать абилку а-ля «remove all coins from the XXX.
Опять же, пока я до этого не дошел – реализую простые взаимодействия.
Разберусь когда до этого дойду.
Это плохая музыка. Проектировать объектную модель нужно заранее
Ну почему, с метапрограммным подходом можно нагенерировать события чуть ли не на все, что может произойти в игре.
Конечно, можно, а как карта сможет подписаться на метапрограммно сгенерерированные события?
Ну, насколько я это себе представляю, модель «подписок» тут не работает. Вместо этого есть один большой мультикаст, или messaging queue, как угодно — когда что угодно происходит, любая карта может отреагировать на это. Информация о том, что произошло зашита в сообщении.
Проектировать объектную модель нужно заранее
Подход с проектированием заранее сработает, если проблемная область либо относительно проста и негибка, либо у вас есть коллеги для мозгового штурма, которые будут критиковать ваши идеи.
В случае в реализации M:tG в одиночку я бы тоже предпочёл отдаться на волю потока… Без экспериментов с реальным кодированием карт и механики совсем не очевидно как делать те или иные вещи и как обеспечивать гибкость (и эстетическую красоту кода!).
// Однако, я бы тоже, наверное, завёл класс Type ;-)
ну скажем, если взять текущие comprehensive rules (в них прописана львиная доля доменной логики, есть, конечно, «золотое правило», но с выходом мтго визарда по-моему перестали к нему прибегать :)) и ограниченный набор карт — скажем, только последнее издание, то вот вы получите довольно большое, но замкнутое тз, с намёками на гибкость, но без реальной в ней потребности :)
моё мнение — что тоже лучше сперва спроектировать (вдумчиво почитать правила и порисовать схемы), прежде чем кодировать
моё мнение — что тоже лучше сперва спроектировать (вдумчиво почитать правила и порисовать схемы), прежде чем кодировать
Хм, мне кажется вы немного недооцениваете сложность задачи, которую перед собой поставили. Визарда последние годы достаточно сильно перекраивали правила, чтобы сделать модель более организованной и регламентированной. Например, когда мы говорим о P/T, нужно учитывать все статические модификаторы и слои, в которых они применяются. К типам это тоже относится: что случится с островом, когда в игре Blood Moon и Urborg? Какую он будет давать ману? Зависит ли это от очередности входа в игру перманентов?
То же относится и к картам. Пока она в руке — это карта существа. В стеке это становится спеллом, на в игре это становится перманентом, и т.д.
Тот же «X» в косте оказывает разное влияние на converted mana cost в зависимости от того, в какой момент требуется его посчитать.
Удачи вам, конечно. Будет круто, если вы сможете все учесть.
То же относится и к картам. Пока она в руке — это карта существа. В стеке это становится спеллом, на в игре это становится перманентом, и т.д.
Тот же «X» в косте оказывает разное влияние на converted mana cost в зависимости от того, в какой момент требуется его посчитать.
Удачи вам, конечно. Будет круто, если вы сможете все учесть.
Пост интересный, правда вопрос насколько он близко к НЕТ?
если не очень, то я тоже давно пробую реализовать. Правда попроще — это: www.netrunneronline.com/home/
Плюсы: Проще как карты так и правила, Меньше карт, Киберпанк
Минусы: Малоизвестна
На inform7 и Plolog
Как хобби
если не очень, то я тоже давно пробую реализовать. Правда попроще — это: www.netrunneronline.com/home/
Плюсы: Проще как карты так и правила, Меньше карт, Киберпанк
Минусы: Малоизвестна
На inform7 и Plolog
Как хобби
ледорубы отаке, нетраннер набигаеэ пыщь пыщь
Спорно, проще ли в нетраннере правила.
Спорно, проще ли в нетраннере правила.
Раз у вас Пролог, нет соблазна перенести все на Erlang?
а цель? Я О Erlang знаю не много.
Если правила сложные, мне кажется что системы которые больше ориентированы на программирования агентов соотвественно более полезны для реализации. Это я по своему опыту в MtG сужу.
Для реализации карт (правил) я считаю наиболее удобным является свой псевдо-язык. Или патерн «интерпретатор». ОО это хорошо, но как показывает практика и обсуждение для хорошей реализации требуется хорошая ОО модель. Не думаю что для всех карт возможна такая модель, либо это будет модель исключений. Агент — это тоже своего рода уход от статики.
Потому (псевдо-язык) и пролог.
Потому (псевдо-язык) и пролог.
Давным давно была MtG для PC (что-то там про Shandalar). Сейчас нечто подобное существует?
Опять какая-то для меня мало понятная концепция использовать паттерн декоратов в роли паттерна состояния. :)
То, что вы называете декоратором, на самом-то деле — это паттерн Прототип
Да и паттерн Декоратор немного иначе выглядит и для других задач используется.
А задачи подобные вашей решаются обычно с помощью паттернов Адапер и Синглтон
Или я опять чего-то не поняла?
То, что вы называете декоратором, на самом-то деле — это паттерн Прототип
Да и паттерн Декоратор немного иначе выглядит и для других задач используется.
А задачи подобные вашей решаются обычно с помощью паттернов Адапер и Синглтон
Или я опять чего-то не поняла?
Попробую объяснить.
То, что мы используем прототип объекта для создания инстанса — да, это паттерн Прототип, только обычно он реализуется как deep copy оригинального класса без особой ссылки на оригинал. У нас класс и наследует и аггрегирует другой класс, то есть он — самый настоящий декоратор. То что он еще и прототип — это следствие того, что изначально мы считываем информацию из базы данных, а следовальтельно у нас нет внутриигрового состояния.
Это решение можно было бы обыграть иначе, и я честно пробовал, но пока остановился на том решении что представлено выше. Синглтон к данной задаче отношения не имеет (карт-то много, следовательно вопрос, синглтон чего?). Что касается адаптера, то он служил для приведения одного интерфейса к другому, а у нас еще гора состояний и всяких других прелестей (к пр. те же делегаты), поэтому адаптер тоже непонятно зачем.
Есть много вариантов решения этой задачи. Если интересует, напишите код, выложите, обсудим.
То, что мы используем прототип объекта для создания инстанса — да, это паттерн Прототип, только обычно он реализуется как deep copy оригинального класса без особой ссылки на оригинал. У нас класс и наследует и аггрегирует другой класс, то есть он — самый настоящий декоратор. То что он еще и прототип — это следствие того, что изначально мы считываем информацию из базы данных, а следовальтельно у нас нет внутриигрового состояния.
Это решение можно было бы обыграть иначе, и я честно пробовал, но пока остановился на том решении что представлено выше. Синглтон к данной задаче отношения не имеет (карт-то много, следовательно вопрос, синглтон чего?). Что касается адаптера, то он служил для приведения одного интерфейса к другому, а у нас еще гора состояний и всяких других прелестей (к пр. те же делегаты), поэтому адаптер тоже непонятно зачем.
Есть много вариантов решения этой задачи. Если интересует, напишите код, выложите, обсудим.
Насколько я понимаю в ответственности обектов, то сами карты — это описательные объекты.
Они просто что-то описывают, скажем, стоимость, действие итд.
Т.е. фактически карта должна уметь сама произвести действия над обектами к которым она применяется — это на тему Actions.
Что касается уменьшения её стоимости в зависимости от _внешних_ факторов, к примеру IPlayer, то для расчёта актуальной стоимости обычно используется ICardCostCalculator.GetActualCost(IPlayer, ICard).
Со второй статьи, я уже догадалась, что у вас есть слабо-нормализированое хранилище и вы пытаетесь его типизировать (не меняя при этом нормализации) и привести к некой абстрактной модели объектов. Задача не тривиальная, но и решается обычно слоями, если нет возможности нормализировать базу.
Они просто что-то описывают, скажем, стоимость, действие итд.
Т.е. фактически карта должна уметь сама произвести действия над обектами к которым она применяется — это на тему Actions.
Что касается уменьшения её стоимости в зависимости от _внешних_ факторов, к примеру IPlayer, то для расчёта актуальной стоимости обычно используется ICardCostCalculator.GetActualCost(IPlayer, ICard).
Со второй статьи, я уже догадалась, что у вас есть слабо-нормализированое хранилище и вы пытаетесь его типизировать (не меняя при этом нормализации) и привести к некой абстрактной модели объектов. Задача не тривиальная, но и решается обычно слоями, если нет возможности нормализировать базу.
кстати, обрати внимание на комент выше о слоях и так далее.
Человек оперурует состояниями и расчётами относительно стостояний.
Фактически он и говорит «Используй паттерн адаптер и интерфейс Кальлятор и пару тысяч его реализаций, что бы учесть все нюансы».
Человек оперурует состояниями и расчётами относительно стостояний.
Фактически он и говорит «Используй паттерн адаптер и интерфейс Кальлятор и пару тысяч его реализаций, что бы учесть все нюансы».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Программирование Magic: the Gathering — §2 Карта