Все это хорошо, если не принимать во внимание нагрузку на сервер
что? Да для одного снаряда понадобится информации передать больше, чем для описанного выше.
А про IPv6 вообще не понял к чему.
Это про предстоящее по пингу, учитывая как провайдеры любят применять новые технологии, если вводить расчет кучи факторов бездумно.
Для реализации того, что описано выше не нужно передавать ни одного байта.
Эти бы слова, да серверу в уши, к сожалению клиентская часть и серверная разные вселенные, в коде реализации предложения слишком много если, кинетический, электромагнитный, термический, воздействие регенерации щита, брони, индивидуальные хилы, заливка, и так для каждого корабля, в добавок, у каждого корабля свои резисты, одни игроки на броню другие на щит и можно продолжать до бесконечности, и вся это обсчитывает сервер, до 5 тыс. игроков, нет проблем, а свыше 5 тыс. самое интересное, там уже вылезают особенности провайдеров, их региональное расположение и вой игроков, почему пинг упал. К сожалению возможности сервера и велики, но не безграничны. Наглядный пример Android, многие модули банально не оптимизированы, как следствие WP по ресурсам на аппаратном уровне требует в два раза меньше при почти одинаковой реакции, а местами и быстрее. Поэтому надо смотреть картину в общем а не контекстами к сожалению.
EVE уже тоже вынуждена оптимизировать затраты на вычисления, по той же причине, упрощая механику, а не в силу адаптации под казуальщиков. А у них мощности, думаю и Google позавидует)))
>2. Всем кораблям сделать модули самовосстановления.
Используют свой слот активных модулей или занимают один из общих слотов?
Изменить принцип действия аур восстановления
Модулями направленного восстановления может оснащаться инженерный фрегат, они тоже бывают трех типов:
В наших условиях подобные штрафы отменят весь ремонт. Плюс, лишние проверки на тип урона для сервера.
На модули самовосстановления такие штрафы не действуют, модули бывают трех типов:
а) модули мгновенного действия, восстанавливают щиты либо корпус сразу, но мало,
б) универсальные модули действуют дольше, но эффект лучше,
в) модули регенерации действуют долго (20-40с), но значимо восстанавливают корабль.
Реализовано. Пункт в - регенерирующее покрытие, а щит и сам восстанавливается.
Именно выделить отдельный слот под системы саморемонта. Инженер же по словам разрабов именно что и должен сидеть в тылу. К тому же он сможет заниматься направленной накачкой, и другими инженерными делами (установкой барьеров, ворот, постреливать) и не будет ему необходимости летать в гуще боя. К нему будут прилетать игроки для хила, как и задумывали разрабы.
Эти бы слова, да серверу в уши, к сожалению клиентская часть и серверная разные вселенные, в коде реализации предложения слишком много если, кинетический, электромагнитный, термический, воздействие регенерации щита, брони, индивидуальные хилы, заливка, и так для каждого корабля, в добавок, у каждого корабля свои резисты, одни игроки на броню другие на щит и можно продолжать до бесконечности, и вся это обсчитывает сервер, до 5 тыс. игроков, нет проблем, а свыше 5 тыс. самое интересное, там уже вылезают особенности провайдеров, их региональное расположение и вой игроков, почему пинг упал. К сожалению возможности сервера и велики, но не безграничны. Наглядный пример Android, многие модули банально не оптимизированы, как следствие WP по ресурсам на аппаратном уровне требует в два раза меньше при почти одинаковой реакции, а местами и быстрее. Поэтому надо смотреть картину в общем а не контекстами к сожалению.
EVE уже тоже вынуждена оптимизировать затраты на вычисления, по той же причине, упрощая механику, а не в силу адаптации под казуальщиков. А у них мощности, думаю и Google позавидует)))
И сервер, и клиент уже получают инфу о повреждениях, для каждого игрока нужно лишь хранить когда был нанесен последний урон из каждого типа оружия. Для сервера чтобы определять возможность хила, для клиента - отображать иконки дебаффа. Какую инфу нужно передавать серверу или клиенту дополнительно? Затраты на вычисления тоже вряд ли критичны… менее десятка случаев и столько же обращений к памяти.
Именно выделить отдельный слот под системы саморемонта. Инженер же по словам разрабов именно что и должен сидеть в тылу. К тому же он сможет заниматься направленной накачкой, и другими инженерными делами (установкой барьеров, ворот, постреливать) и не будет ему необходимости летать в гуще боя. К нему будут прилетать игроки для хила, как и задумывали разрабы.
Зачем барьеры на респе? Как стрелять на сверхдальние расстояния (до фронта только более 5 км должно быть)? И правильно ли я понимаю что вы предлагаете дополнительные модули, которые надо будет отдельно активировать?
Эти бы слова, да серверу в уши, к сожалению клиентская часть и серверная разные вселенные, в коде реализации предложения слишком много если, кинетический, электромагнитный, термический, воздействие регенерации щита, брони, индивидуальные хилы, заливка, и так для каждого корабля, в добавок, у каждого корабля свои резисты, одни игроки на броню другие на щит и можно продолжать до бесконечности, и вся это обсчитывает сервер, до 5 тыс. игроков, нет проблем, а свыше 5 тыс. самое интересное, там уже вылезают особенности провайдеров, их региональное расположение и вой игроков, почему пинг упал. К сожалению возможности сервера и велики, но не безграничны. Наглядный пример Android, многие модули банально не оптимизированы, как следствие WP по ресурсам на аппаратном уровне требует в два раза меньше при почти одинаковой реакции, а местами и быстрее. Поэтому надо смотреть картину в общем а не контекстами к сожалению.
EVE уже тоже вынуждена оптимизировать затраты на вычисления, по той же причине, упрощая механику, а не в силу адаптации под казуальщиков. А у них мощности, думаю и Google позавидует)))
И сервер, и клиент уже получают инфу о повреждениях, для каждого игрока нужно лишь хранить когда был нанесен последний урон из каждого типа оружия. Для сервера чтобы определять возможность хила, для клиента - отображать иконки дебаффа. Какую инфу нужно передавать серверу или клиенту дополнительно? Затраты на вычисления тоже вряд ли критичны… менее десятка случаев и столько же обращений к памяти.
Мда по ходу недостатки возможности редактирования)))
Один тип выстрела один таймер, другой еще один, итого по типам уронов поток в три раза возрастает и так далее, еще надо вести лог стрельбы, и там и там, для работы с бот программами и копейка за копейкой, там можно доползти до потока в 5 мегабит на клиента, при аудитории в 5 000 мы получаем поток в 25 гигабит, поправка на нестабильность оборудования провайдеров думаю процентов 30 уже 32,5 гигабита (переходный период) запас прочности еще 10 процентов итого 35,75 гигабит на 5 тысяч человек в секунду. В добавок плавающая скорость соединения, от нее никуда, а если больше людей, там и до завала сервера с возросшим пингом недалеко. Нельзя смотреть только по одному предолжению, нужно смотреть на картину в целом, если можно избежать дублирование таймеров отката, то надо экономить прежде всего на этом.
5км не расстояние, а прикрыться от стабов и налетающих перехватов надо, если это открытый космос.Модули самолечения - отдельно. А инженерные лечилки - боевые.
>
Эти бы слова, да серверу в уши, к сожалению клиентская часть и серверная разные вселенные, в коде реализации предложения слишком много если, кинетический, электромагнитный, термический, воздействие регенерации щита, брони, индивидуальные хилы, заливка, и так для каждого корабля, в добавок, у каждого корабля свои резисты, одни игроки на броню другие на щит и можно продолжать до бесконечности, и вся это обсчитывает сервер, до 5 тыс. игроков, нет проблем, а свыше 5 тыс. самое интересное, там уже вылезают особенности провайдеров, их региональное расположение и вой игроков, почему пинг упал. К сожалению возможности сервера и велики, но не безграничны. Наглядный пример Android, многие модули банально не оптимизированы, как следствие WP по ресурсам на аппаратном уровне требует в два раза меньше при почти одинаковой реакции, а местами и быстрее. Поэтому надо смотреть картину в общем а не контекстами к сожалению.EVE уже тоже вынуждена оптимизировать затраты на вычисления, по той же причине, упрощая механику, а не в силу адаптации под казуальщиков. А у них мощности, думаю и Google позавидует)))
И сервер, и клиент уже получают инфу о повреждениях, для каждого игрока нужно лишь хранить когда был нанесен последний урон из каждого типа оружия. Для сервера чтобы определять возможность хила, для клиента - отображать иконки дебаффа. Какую инфу нужно передавать серверу или клиенту дополнительно? Затраты на вычисления тоже вряд ли критичны… менее десятка случаев и столько же обращений к памяти.
Мда по ходу недостатки возможности редактирования)))Один тип выстрела один таймер, другой еще один, итого по типам уронов поток в три раза возрастает и так далее, еще надо вести лог стрельбы, и там и там, для работы с бот программами и копейка за копейкой, там можно доползти до потока в 5 мегабит на клиента, при аудитории в 5 000 мы получаем поток в 25 гигабит, поправка на нестабильность оборудования провайдеров думаю процентов 30 уже 32,5 гигабита (переходный период) запас прочности еще 10 процентов итого 35,75 гигабит на 5 тысяч человек в секунду. В добавок плавающая скорость соединения, от нее никуда, а если больше людей, там и до завала сервера с возросшим пингом недалеко. Нельзя смотреть только по одному предолжению, нужно смотреть на картину в целом, если можно избежать дублирование таймеров отката, то надо экономить прежде всего на этом.Бедный вартандер… там после одного нажатия на гашетку штук 20-30 снарядов вылетает, причем 4-8 различных типов каждый по своей траектории…а если они в противника попадают, то каждый отдельно просчитывается.В общем, не пишите о том, в чем не разбираетесь.
ребят, ну что вы городите? Уапервых, ничего из вышеописаных нагрузок это нововведение не принесет, максимум полтора - два процента на одно ядрышко (сранимо с фоновыми перепадами от обслуживающих деймонов). Уафтарых, клиент ничего не расчитывает, кроме мультимедийной составляющей, о которой сервер ни слухом ни духом, откуду повышение трафика? Прально, с потолка. Такое впечатление, что вы говорите о сервере на основе ЕНИАКа.
По теме. Что-то в этом предложении есть, но нужно детально проработать. Проблема нынешней игры в полнейшем отсутствии логики. С одной стороны простота (относительная) расчета урона/резиста, с другой стороны полная муть с ролями и их модулями. Яркий пример дальнобои и инженеры всякие, заграды тоже не блещут живучестью, добавим полную перемену ролей и полное отсутствие смены характеристик боев, как пве так и пвп под новые роли. Реальную нагрузку на сервер могут дать только вариативные вычисления с циклами и применением генератора случайных чисел. Здесь же человек предлагает стандартные прямые вычисления с короткими формулами. И если сервер СК основан хотябы на машине мощнее моей домашней, то при вычислительной мощности более 240 млрд операций в секунду он должен справиться с вышеописанными задачами с легкостью.
Просто сделать порезку регена от массхилок при получении дамага игроком на 50% и в запрет ещё на 7-15 секунд. В бою массхилки будут незаметны, переработать слегка дистанционные хилы для отхиливания именно в бою.
тогда не будет смысла в типе урона. В основном народ пытается сровнять цифры резистов (кроме прикрытия, там 100 халявного резиста плюс собственный резист, плюс импланты, такой резист тяжело уравнять). И получится чем не стреляй все будет одинаково. Так что идея ТСа гуд.