Clamp,
Ок, давай на примере, если абстрактно не получается.
Есть две игровых механики, мгновенное лечение и поглощающий урон щит, фактически временно увеличивающий максимальный запас здоровья, числовые значения использующих эти механики способностей подобраны таким образом чтобы обеспечивать одинаковый прирост реального запаса здоровья сферического коня в вакууме за единицу ресурса. Кроме того, их нельзя применять одновременно - цель под щитом нельзя лечить, а наложение нового щита на цель невозможно до истечения предыдущего.
Обе механики линейно масштабируются от кол-ва кастеров - чем их больше, тем больше целей может получить прирост к выживаемости одновременно. Обе использующие эти механики способности имеют автокаст. Для чистоты эксперимента, кастер не имеет автоатаки и других способностей кроме использующих эти две механики, а щит нельзя снять другими способами кроме нанесения урона и истечения срока его действия.
А теперь, внимание, вопрос, какая из этих двух механик получает больший прирост выживаемости армии в реальном бою от увеличения кол-ва задействованных юнитов?
Clamp, ты забыл самое важное слово в этой фразе - слишком. А так, речь об эффективности использования механики игроком в сравнении с другими доступными игроку механиками, которая возникает из масштабируемости от контролируемого игроком параметра, а не из природы самой механики или скила игрока.
Clamp, я не просто так написал "в условиях проекта" - в каком-нибудь дуэльном пвп проекте, например, о масштабируемости по кол-ву игроков в сессии и юнитов на карте речи не идет вовсе, зато могут быть свои критерии масштабируемости, неприменимые к RTS.
Слишком эффективная для игрока масштабируемость чего бы то ни было это тоже паршивая масштабируемость, если что.
Ок, поясняю на пальцах: механики должны быть элементарными (unless it's a shooter), но в комбинации с другими элементарными механиками давать бесконечную вариативность.
А еще есть такая штука, как масштабируемость - элементарная механика или не очень, если она паршиво масштабируется в условиях проекта с кол-вом игроков, кол-вом юнитов или длительностью матча, то обычно такой механике не место в проекте.
Все это лечение симптомов - для начала необходимо избавиться от причин массовой преступности, а остатки будет уже намного проще отработать любым из способов, хоть гуманным, хоть не очень.
Я всегда думала, что это полностью 3д движки с кучей непонятного для меня кода. Хммм...
И там и там есть 2д составляющая, нужно только откопать как заставить её работать. Более того, в UnrealEngine4 есть визуальное программирование - блюпринты, но не уверен применимо ли оно с 2д. Но, имхо, для 2д лучше все-же 2д движки, особенно для первых проектов.
Cinos, мир воксельный в своей основе, что накладывает ряд ограничений на рендер и форму блоков, если хочется чтобы это работало быстро. А модели всего остального какраз не велика проблема запихнуть какие угодно, можно даже выковырять из JME3 готовые алгоритмы для костной анимации и немного их причесав заставить все это работать (делал так когда-то давно, результат того не стоит).
drako3y, заменить модели какраз таки проблематичней контроля юнитов - воксельный движок он не очень любит что-то кроме кубиков по форме. Заменить модели персонажей не сложно, но они будут бледно смотреться на фоне кубиков и местного света - правильнее запилить свои, стилизованные под кубики, поменять текстуры блоков на свои и добавить треугольный блок чтобы мир не выглядел таким квадратным там где нет отвесных обрывов.
А контроль юнитов нужно просто написать с нуля и это хоть и не самая простая, но и далеко не самая сложная задача - по факту надо будет добавить возможность отдавать AI мобов команды переопределяющие стандартный механизм принятия решений и реализовать интерфейс для этого. Стратегическая камера что тут что в WoW не получится, если не делать рельеф совсем уж плоским - придется довольствоваться свободной камерой, полетом и телепортацией, но не считая этого, реализовать управление юнитами почти как в варе вполне реально.
Могут возникнуть проблемы если юнитов будет слишком много и у них будет слишком сложный AI, но это решаемо. В худшем случае надо будет запилить кастомную систему навигации для мобов по навмешу и генерацию этого самого навмеша, но для начала должно хватить и дефолтной реализации.
что на мой взгляд надо сделать с майнкрафтом для достижения поставленой цели
это далеко не полный список, и далеко не все в этом списке обязательно - я просто выписал что пришло в голову за ограниченный отрезок времени, но все или почти все из этого списка вполне реализуемо в разумные сроки
запилить возможность добавлять именованных NPC
добавить систему админского ручного контроля мобов и NPC
добавить возможность назначать мобам и NPC патрули и маршруты
переделать мобов и условия их спавна - врядли автоматический спавн мобов в темноте будет уместен, да и ассортимент будет нужен по больше
реализовать базовую систему "союзов", не требующую лезть в код чтобы поменять кто кого хочет атаковать или не хочет
переделать боевую систему, текущая хоть и стала немного лучше чем была раньше, но аркадное решение делать цель неуязвимой на короткое время после получения урона это ад
там нет системы способностей и статов персонажа как таковой, все вертится вокруг предметов - в зависимости от постановки задачи это возможно надо будет исправить
переделать инвентарь и систему подбирания предметов с пола - стандартно предметы к которым игрок подошел близко просто втягиваются в него, нужно это заменить чем-то вроде списка ближайших предметов на полу, как в некоторых играх или подбиранием по наведению мышки, наверно лучше первым.
переделать набор доступных блоков под свои задачи и поменять их текстуры, в том числе добавив треугольную вариацию блоков чтобы можно было более естественные пейзажи создавать
выдрать из популярного мода и адаптировать систему аксессуаров, позволяющую добавить игроку больше слотов "брони", чем дефолтные "шлем", "тело", "ноги" и "сапоги", в первую очередь для декоративных целей, но и игровые механики туда прикрутить можно какие-то
создать и добавить в игру свои стилизованные модели игроков и NPC. Возможно, по началу для игроков и человекообразных NPC можно будет обойтись скинами-текстурами более высокого разрешения и кастомными моделями брони и аксессуаров, не трогая базовую модель игрока.
выдрать из популярного мода и адаптировать систему расширенного движения, позволяющую ползать, запрыгивать на препятствия с зацепом руками и тому подобные, обычные и граничащие с паркуром действия, чего дико не хватает в обычном майнкрафте.
отвязать скины игроков от веб-серверов mojang и перенести их для начала в мод, что просто, но неудобно т.к. придется при появлении каждого нового игрока мод обновлять, а потом или на свой веб-сервер или лучше прямо на игровой сервер
отключить за ненадобностью большую часть активных механик блоков - рост кактусов и тросника, редстоун-логику, падение песка и гравия, распространение травы на блоки земли и тому подобное
запилить более вменяемую замену редстоун-логике, не такую накладную для сервера и с более приличным внешним видом
отключить или починить встроенный античит, который сейчас только мешает во вполне легальных ситуациях, а читера давно научились его обходить
выбрать правильные настройки игровых правил - например, запретить игрокам и мобам ломать блоки и отключить выпадение всех предметов при смерти
переделать правила респавна после смерти на соответствующие требованиям
переделать базовые статы игрока (здоровье, броня, еда) и при необходимости добавить недостающие
добавить возможность отключения автоматического деспавна предметов для ситуаций когда предмет действительно должен оставаться в мире навсегда пока его не подберут - для всех предметов не стоит этого делать из соображений производительности
выдрать из популярных модов ряд декоративных блоков и адаптировать их под свои требования и свой уровень графония - всякие стеллажи для книг и инструментов, демонстрационные стенды для предметов, стойки для брони и тому подобное, требующее дополнительного функционала, а не просто мертвые модели декора
скачать более-менее подходящую карту из интернета и немного доработать - для тестовых целей
создать свою собственную карту мира (в несколько этапов - сперва идет генерация высот и рельефа, потом заполнение его зданиями и деталями)
подобрать инструментарий для редактирования карт и дополнить его своим функционалом в моде, например возможностью ставить прямо в игре а не сторонних редакторах заранее собранные из блоков здания в пару кликов мышки вместо выкладывания их по блочно
Zahanc:
Вариант с md5 хешем каждой записи или всего лога позволит остановить часть хомячков с той-же надежностью, что и "шифрование" xor-ом - оба способа одинаково обходятся заглянув в код Lua.
Обеспечить одинаковую работу рандома достаточно просто - там же на самом деле псевдорандом и seed видоизменяется после каждой операции заранее заданым способом - достаточно обеспечить одинаковость этой операции и рандом будет выдавать одинаковые значения хоть на джаве, хоть на брейнфаке. Другое дело что это так-же бесполезно, как и хеш данных - обходится идентично за счет доступа к Lua-имплементации в открытом виде.
обфускатор штука хорошая и задержит небольшое кол-во хомяков, но во-первых все обращения к WoW API придется оставить не обфусцированными, а во вторых обфускация имееет смысл только на больших объемах кода - иначе найти нужное место в коде не составит большого труда.
Zahanc, есть простое решение, которое остановит часть хомяков - запилить свой алгоритм рассчета хеша на основе данных и писать этот хеш тоже в лог, тогда тупые изменения файла данных уже ничего не дадут т.к. надо будет пересчитывать хеш как-то, а клиент сможет на основе данных проверять валидность хеша
но это не спасет от возможности подсмотреть алгоритм генерации хеша и/или шифрования и воспользоваться этими знаниями в своих целях, вплоть до использования скопированного оттуда кода хеширования/шифрования для автоматической генерации данных в том формате в каком их ожидает клиент
и я даже не говорю о возможности декомпиляции клиента - это не уровень хомячков
А разве Lua-аддоны нынче уже можно компилировать или они по прежнему в текстовом виде? Если второе - любая система шифрования бесполезна т.к. отредактировать код аддона не сложнее, чем подменить содержимое лога, а значит данные будут скомпрометированы еще до шифрования.
Обновление главной страницы проекта пока нет определенного уровня проекта требует подтверждения от модераторов. Не знаю как сейчас, а раньше где-то была кнопка переключающая между последней утвержденной модераторами версией страницы и последней неутвержденной версией, доступная только автору проекта.
А решать "проблему" очень просто - дождаться пока кто-то из модераторов доберется до вашего проекта или написать в обратную связь чтобы немного повысить шансы что раньше заменят необходимость утвердить обновления.
Нееее, лучший вариант под поставленную задачу - майнкрафт - единственный серьезный его недостаток это графоний, который вполне можно исправить со временем, не до уровня WoW, конечно, но до вполне терпимого.
А из основных плюсов:
возможность работы напрямую с кодом, а не через мемхаки и сильно ограниченные скрипты - очень сильно упрощает жизнь и расширяет возможности
возможность при необходимости привлечь игроков к строительству локаций, что особенно ценно на раннем этапе, когда нужно не отдельные локации доделывать или переделывать, а всю карту сразу создать
наличие разнообразного готового инструментария для генерации и редактирования карты
возможность надергать кусков из существующих модов, которые на данный момент почти все с открытым кодом
теоретически неограниченный размер бесшовной карты (конечно, для твоих целей карту лучше будет ограничить и заранее заполнить, не полагаясь на автоматический генератор, но в любой момент её можно расширить в любую сторону или подключить еще один мир)
сравнительно небольшая нагрузка и малый вес (учитывая что карта будет запрещена к редактированию игроками в обычных условиях, а игровые механики требующие частых обновлений карты будут отключены за ненадобностью)
минимальный вес обновлений за счет примитивной графики и за счет отдачи карты в реальном времени, без необходимости её заранее скачивать
Doc, именно поэтому я пытаюсь обратить внимание автора на альтернативы разработке с нуля - тот-же майнкрафт вполне реально приспособить под его нужды за месяц-два фулл-тайма силами одного мидла, если контент сгрузить на самого автора и добровольцев из числа игроков и время кодера тратить только на код.
drako3y, ну да, по извращаться придется чтобы дать возможность комфортно контролировать группы NPC с ГМ-персонажа. Но это в любом случае придется делать с нуля, если в основе не стратегия используется.
В моровинде будет та-же проблема, что и в ВоВ - будет нужен дикий изврат чтобы добиться стратегического режима управления NPC, вне рамок записаных заранее сценариев. Имхо, в этом плане проще всего будет работать с майнкрафтом из всех упомянутых тут вариантов т.к. можно работать напрямую с кодом игры, а не с мем-хаками и ограниченными по функционалу скриптами.
drako3y, 100-200 человек ты ни на одном готовом бесплатном решении не потянеш, придется или платное брать или с нуля разрабатывать, если речь идет о работе с движком, а не о переделывании игры, которая уже тянет такой онлайн.
ИМХО, с такими требованиями лучше всего смотреть в сторону майнкрафта или сервера ВоВ с модами. Не представляю себе как в режиме ролевой игры один ГМ управится с сотней игроков одновременно, но это уже другой вопрос.
Существует клон Minecraft с открытыми исходниками, забыл название. Можно пробовать его расширять.
Глупости, зачем трогать руками клон, если можно спокойно пилить моды на оригинал.
Но сама идея перехода на майнкарафт в качестве "движка" для этого проекта хороша - если уровень графики устраивает, то это одно из самых простых решений поставленой задачи. Придется допилить некоторые вещи, вроде управления толпой мобов и отключения ряда стандартных механик, но в целом сложность намного ниже, чем делать с нуля на полноценном движке. Плюс многое можно стащить из готовых модов.
drako3y, технически задача выглядит не особо сложно, но есть нюансы, которые могут все сильно усложнить.
кол-во игроков одновременно находящихся на сервере (чем больше верхний предел, тем сложнее будет заставить это стабильно работать)
предельное кол-во NPC, предметов и прочих динамических объектов на карте (чем их больше, тем больше нагрузка на сервер, вплоть до необходимости вводить срок жизни валяющимся на земле предметам и выгрузки предметов и NPC из зон где нет игрков)
доступные серверные мощности
требуемый уровень графики и эффектов (создание моделей, анимаций, текстур, звуков, спецэффектов и прочих ассетов это дело не быстрое и не дешевое)
геометрический размер карты в метрах (больше карта - больше нагрузка на сервер, вплоть до необходимости разбивать карту на несколько участков и полностью выгружать с сервера части, в которых нет игроков)
необходима ли защита от читеров (если нет. то это очень сильно упрощает разработку)
необходимость редактирования карты в реальном времени, а не заранее в редакторе (если большая часть объектов на карте не прикручена намертво болтами к земле, то это дополнительная нагрузка и на клиент и на сервер и значительно усложняет разработку)
механизм обновления для клиента и частота этих обновлений (большие детализированные карты на современных движках могут легко достигать веса в несколько гигабайт, кроме того все ассеты обычно пакуются в один или несколько больших архивов, которые приходится перекачивать целиком при внесении малейших правок в ассеты в архиве)
В общем, уложиться в предложеный бюджет реально, но вопрос в том, чем придется пожертвовать ради этого.
Запил моделей для элементов - задача 3д-артиста, а не программиста.
Разработка независимых сферических коней в вакууме, без центральной системы управления - дохлое дело, а разработка центральной системы управления всем этим цирком стоит немного других денег, чем реализация игровой логики для отдельных элементов.
Ну а размещение вакансий в разделе вопросов так и вовсе на нарушение правил тянет.
» Чердак / Стратегическая глубина (часть I)
Ок, давай на примере, если абстрактно не получается.
Обе механики линейно масштабируются от кол-ва кастеров - чем их больше, тем больше целей может получить прирост к выживаемости одновременно. Обе использующие эти механики способности имеют автокаст. Для чистоты эксперимента, кастер не имеет автоатаки и других способностей кроме использующих эти две механики, а щит нельзя снять другими способами кроме нанесения урона и истечения срока его действия.
Ред. prog
» Чердак / Стратегическая глубина (часть I)
» Чердак / Стратегическая глубина (часть I)
» Чердак / Стратегическая глубина (часть I)
» Game Dev / Многопольз. онлайн сервер. Плачу за разработку.
» AzaZzell / Смертная казнь
» Монстрофилию в массы / я тоже хочу сделать игру #0
» Монстрофилию в массы / я тоже хочу сделать игру #0
Ред. prog
» Game Dev / Многопольз. онлайн сервер. Плачу за разработку.
» Game Dev / Многопольз. онлайн сервер. Плачу за разработку.
» Программирование / Аутентификация с нуля. Предотвратить подмену записей.
Вариант с md5 хешем каждой записи или всего лога позволит остановить часть хомячков с той-же надежностью, что и "шифрование" xor-ом - оба способа одинаково обходятся заглянув в код Lua.
Ред. prog
» Программирование / Аутентификация с нуля. Предотвратить подмену записей.
» Программирование / Аутентификация с нуля. Предотвратить подмену записей.
» Администрация XGM / Почему не обновляется информация о проекте?
Ред. prog
» Администрация XGM / Почему не обновляется информация о проекте?
А решать "проблему" очень просто - дождаться пока кто-то из модераторов доберется до вашего проекта или написать в обратную связь чтобы немного повысить шансы что раньше заменят необходимость утвердить обновления.
» Game Dev / Многопольз. онлайн сервер. Плачу за разработку.
» Game Dev / Многопольз. онлайн сервер. Плачу за разработку.
» Game Dev / Многопольз. онлайн сервер. Плачу за разработку.
В моровинде будет та-же проблема, что и в ВоВ - будет нужен дикий изврат чтобы добиться стратегического режима управления NPC, вне рамок записаных заранее сценариев. Имхо, в этом плане проще всего будет работать с майнкрафтом из всех упомянутых тут вариантов т.к. можно работать напрямую с кодом игры, а не с мем-хаками и ограниченными по функционалу скриптами.
» Game Dev / Многопольз. онлайн сервер. Плачу за разработку.
Не представляю себе как в режиме ролевой игры один ГМ управится с сотней игроков одновременно, но это уже другой вопрос.
» Game Dev / Многопольз. онлайн сервер. Плачу за разработку.
Ред. prog
» Game Dev / Многопольз. онлайн сервер. Плачу за разработку.
» Маленький блог пользователя Alexander18 / Слад идей,фантазий и пРочИх.....
» Мир безумного / В тесте PUBG обнаружили прозрачные трусики
» Game Dev / Необходим программист Unity или Unreal
Разработка независимых сферических коней в вакууме, без центральной системы управления - дохлое дело, а разработка центральной системы управления всем этим цирком стоит немного других денег, чем реализация игровой логики для отдельных элементов.
Ну а размещение вакансий в разделе вопросов так и вовсе на нарушение правил тянет.
Ред. prog
» StarCraft 2 / Вопросики по Editor'у.