Как стать автором
Обновить

Комментарии 57

Вот бы ещё отдел баланса свою тяжкую работу здесь описал, а мы бы с радостью обсуждали в комментариях.
[irony] И отдел по эффективному повышению «надоев» (доната)[/irony]
По этой теме уже кто только не выступал. Извините, увидел комменты про баланс и надои, и не удержался :)
Заголовок спойлера

Просмотрел видео, половину не понял о.О Нет, суть угадать можно — сделали платную модель, поломали баланс, и потом с ней тоже что-то случилось (неясно — то ли урезали, то ли выпустили новую модель, снова сломавшую баланс, то ли и то и другое…). Но фразы… Вот как можно угадать слово «нерфить»? Я даже не имею представления, производная от чего это — есть только компания игрушек NERF → НЕРФ, так может они плохой пластик производят, и «нерфить», это как делать бракованную партию?

Больше всего понравилось «начинают вайнить на форуме». Это, наверное, как «начинают бухать на форуме», и мозг живо представляет горестные заголовки «Вздрогнем за почившего Т1000», печальные комментарии «мне будет его не хватать», серый фон, и все ЧЕРНЫМИ БУКВАМИ!
поиграйте в вот и посмотрите видосы на ютубе. Сразу всё поймёте
Да не, трудно потом вылезти. Я не знаю, может другим легче, но меня затягивает даже в намного менее кооперативный Xonotic, где и матч то один длится, казалось бы, лишь 5…10 минут в среднем.

Наверное у меня модель мышления поломана. Потому что сажусь, к примеру, за диплом, и понимаю, что он очень скучен, неинтересен, и очень хочется поиграть в Xon. Или, к примеру, прихожу домой, и думаю «Сейчас что-нибудь крутое сделаю — вон, Фабрис Беллар и QEMU, и ffmpeg написал, и формулу офигенную открыл, и еще много чего, ну чем я хуже??». И вот, смотрю я на свои идеи, и не испытываю ни малейшей симпатии, они размываются в серую и нудную муть, зато Xonotic — это море веселья прямо сейчас!

Я сейчас вспомнил Ричарда Фейнмана — он рассказывал, как алкоголь бросил. Позволю себе его процитировать.
Однажды днем, около половины четвертого, я шел мимо пляжа Копакабаны и
наткнулся на бар. И тут же, совершенно внезапно, у меня возникло огРОМное и
сильное желание: «Именно это мне сейчас и нужно; это будет как раз кстати. Я
с удовольствием выпью что-нибудь прямо сейчас!»

Я уже почти вошел в бар, и тут мне подумалось: «Стоп! Еще только
середина дня. Здесь никого нет. Нет никакой причины пить, ведь сейчас не
может быть никакого общения. Почему же у тебя возникла такая сильная
потребность выпить?» Тут я испугался.
Тут я испугался.
в целом, всё правильно поняли, но есть нюансы.
NERF — это название фирмы производителя оружия, которое стреляет мягкими безопасными снарядами или мячиками. Ну, т.е. оружие, которое не может нанести вреда даже ребенку. Качество пластика там отличное, так что тут не угадали
whine — ныть, скулить. опять немного мимо))
Если не секрет, что требуется от идеального балансера? И чем плох текущий? Играю как «казуал» с племянником, и особых проблем вроде бы нет.
Описываю свой личный опыт.

Часто бывают ситуации, когда одна команда выигрывает бой минуты за 4, просто потому, что в команды закинулось примерно одинаковое количество типов техники, но не учитывалась их боевая роль. В итоге неорганизованная толпа слабых игроков идёт сквозь вражеский строй словно раскалённый нож сквозь масло. Вариант решения — баланс по боевой роли единицы, а не по её номинальному классу.

Некоторые танки просто ничего не могут сделать с танками на два уровня выше. И это не зависит ни от мастерства, ни от боевой ситуации. Разработчики оправдывают баланс +2 желанием разнообразить количество техники в боях, но это оправдание уже несущественно, количество танков достаточно возросло. А с отменой уровня боёв 12 жизнь восьмёрок вообще в АДъ превратилась. Соответственно, баланс +1 был бы идеален, под него проще и танки балансить.

Это что касается балансера. А ещё САУ. Тут и говорить нечего. Класс нуждается в перебалансировке, это признают и сами разработчики.
Хм. А что плохого в подобного рода боях? Ведь в половине случаев победа принадлежит союзной команде. Опять-таки, баланс по роли — сложная вещь, очень. Тот же Т-34 можно использовать как в роли флангового дырокола, так и в роли светляка. Роль сильно зависит от экипажа, модулей, используемого вооружения. Балансировать по множеству параметров — долго, и результат не гарантирован.

Насчет +2 — вопрос тоже спорный, ибо есть исключения. Luchs, ELC и иже с ними демонстрируют, что вражеский танк +3 можно отлично засветить.

САУ, возможно, дисбалансна, но она дисбалансна в обеих командах.

P.S. Предлагаю на этом завершить. Оказывается, тема весьма холиварна, и не раз поднималась на танковых ресурсах.
Это не твой акк случайно?
> Luchs, ELC и иже с ними демонстрируют, что вражеский танк +3 можно отлично засветить.

Ага, ну засветил, и что? Толпа оленей стреляет куда угодно, но только не по твоему засвету — как жить?

Роль танка, кстати, меняется в зависимости от его вооружения. ELC с топовой пушкой должен использоваться как быстрая, малозаметная и мощная ПТ, а вовсе не как ЛТ.
Я как человек играющий часто без према на 7-8 уровнях могу сказать что меня это не особо напрягает.
Те с моими 54% я могу играть на 10ках в ноль, но смысла нет, новые танки не купишь. Идеальный уровень без према именно до 8го.
Я, кстати, играл еще до введения ±2 и тогда на моем Т-34 (который 5й) видел в бою ИС-7. Приходилось думать, читать и выживать.

Просто поменялся подход что-ли… раньше гораздо больше времени уделялось обучению в кланах и на форумах. Вон на стримах Десертода некоторые после стольких лет до сих пор танк сменить не могут не выходя из компании.

Сейчас же в моде БТР (бодрое танковое рубилово). А бтр на 8ках против 10к быстро заканчивается. А стоять на прием пуша люди не умеют (это не только кэмпить из кустов, но еще и понимать когда надо отойти и контр-пушить). Играть как саппорт тоже.

С артой тоже все не так просто. Контингент танков кажется 30+. Это люди с работой, детьми и внимание! деньгами. Им бы поиграть и расслабиться после дня и совершенно не хочется каждый день врываться на средних танках. Эти люди никуда не уйдут, у них не бомбит. Если арту понерфят они сядут на ТД типа бабахи или босса. Там альфа не хуже. И будет в боях по 7-8 бабах или маусов. Будет снова визг что нужно понерфить и их.
Но скажем так… точность у арты нерфить не будут. И так хуже некуда. А от всего остального будут страдать бумажные танки на которых играет очень много статистов, типа батчата или новых чехов. Там даже прямого не надо и так криты идут.
Для примера возьмем fv304 (6я арта). Теперь когда попадает к 8м просто от большинства рикошетит или выбивает по 80 урона. При полете снаряда в 2,5с, бешеной перезарядке, дальности стрельбы 600 метров. И обзоре 8к в 430м. Первым огребет статист на бате. Он первый засветился (остальные еще едут), а Т-62 я могу просто не пробить.

Против них мы имеем статистов и стримеров. Первые будут ныть если сделать ММ по скиллу, ведь кто-то окажется менее статистом, статка будет падать. И тех, кто забил на рандом и катает ГК и укрепы, где арты нет или можно договориться чтобы не брали.
И стримеров, которым НУЖЕН бтр иначе стрим будет скучным и народ уйдет.
На инсте гейта минусовый хуррик, в бубле, в агре.
Вот круто :) Вроде бы всё по-русски, но половину не понял :)))
Пусть сделают так, что бы не забрасывало в бои, где на 8 восьмерок в одной команде приходится 3 восьмерки другой команды. Остальные естественно 9 и 10.
А зачем? Танки одного уровня сильно различаются по полезности. Сравните AMX 40 и БТ-7: первый выше уровнем, но в большинстве случаев бесполезен. Второй картонный, без урона, но шустрый и зело полезный.
Интуитивно кажется, что бои с выровненными по уровню составами будет лучше, но знатоки наверняка приведут немало контрпримеров.
Погуглил, каждый танк в балансере имеет свой коэффициент полезности. В вашем пример количество компенсируется качеством.
Вот когда вы в составе команды, в которой 8 танков восьмого уровня выкатитесть на команду, где таких танков три, а в топе у них тройка ТТ. Тогда имеет смысл говорить. Особо доставляет, когда выезжаешь в такой бой на каком-нибудь Т-44.
Если что, на уровнях ниже 8 с этим параметром баланса всё еще куда ни шло.
Пусть сделают так, что бы не забрасывало в бои, где на 8 восьмерок в одной команде приходится 3 восьмерки другой команды. Остальные естественно 9 и 10.

Почти идеальный вариант для выполнения:
1. СТ-15 на Т-55А, играя на ст 8 уровня, надеясь на наличие в красной команде трех ПТ (убить надо двух ПТ, одна ПТ — запасная)
2. ЛТ-15 на Т-55А, играя на ЛТ-8, надеясь на полевую карту.
«Возможно все, но зачем?» (с)
Насколько Я вижу, у вас схема данных фиксирована и хранится как на отправляющей стороне, так и на принимающей. В UDP пакетах передаются только значения (без имён полей и структу). Вы не пробовали в качестве эксперимента использовать google.protobuf вместо cpickle? По-моему, protobuf как раз придуман как формат передачи данных фиксированной структуры. Я тут набросал небольшой пример:
Описание структуры данных:
gamedata.ptoro
package protobuf;

message MatrixRow {
	repeated int32 cell = 1 [packed=true];
}

message InnerDict {
	required int32 innerVal = 1;
	required int32 innerVal2 = 2;
	repeated int32 listOfVals = 3 [packed=true];
}

message GameData {
	required int32 someIntegerValue =1;
	required bool someBoolValue = 2;
	repeated int32 someListOfIntsValue = 3;
	required float someFloatValue = 4;
	required InnerDict someDictionaryValue = 5;

	repeated MatrixRow _2dArray = 6;
}


Серриализация одного объекта:
test.py
import gamedata_pb2

obj = gamedata_pb2.GameData()
obj.someIntegerValue = 1
obj.someBoolValue = True
obj.someListOfIntsValue.append(1)
obj.someListOfIntsValue.append(2)
obj.someListOfIntsValue.append(3)
obj.someFloatValue = 0.5

dictValue = obj.someDictionaryValue
dictValue.innerVal = 1
dictValue.innerVal2 = 2
dictValue.listOfVals.append(1)
dictValue.listOfVals.append(2)
dictValue.listOfVals.append(3)
dictValue.listOfVals.append(4)

#Create 2D matrix. Looks ugly but works!
row1 = obj._2dArray.add()
row1.cell.append(1)
row1.cell.append(2)
row1.cell.append(3)
row1.cell.append(4)
row1.cell.append(5)
row1.cell.append(6)

row2 = obj._2dArray.add()
row2.cell.append(7)
row2.cell.append(8)
row2.cell.append(9)
row2.cell.append(10)
row2.cell.append(11)
row2.cell.append(12)

row3 = obj._2dArray.add()
row3.cell.append(13)
row3.cell.append(14)
row3.cell.append(15)
row3.cell.append(16)
row3.cell.append(17)
row3.cell.append(18)

row4 = obj._2dArray.add()
row4.cell.append(19)
row4.cell.append(20)
row4.cell.append(21)
row4.cell.append(22)
row4.cell.append(23)
row4.cell.append(24)

data = obj.SerializeToString()
print(len(data))


В результате объект серриализуется в строку размером 67 байт.
Подумал о том же самом, protobuf здесь просто-таки напрашивается
Статья оставляет отчетливое впечатление очередного изобретения велосипеда
На момент выхода протокола версии 0, биндингов protobuf для питона не существовало.
Протокол версии 1 был скорее «пожарной мерой», которую было достаточно легко ввести в эксплуатацию.
Возможно, стоило вместо версии 2, использовать protobuf, но на данный момент у нас порядка 20 промежуточных шаблонов, из которых в различных комбинациях склеивается 7 финальных шаблонов. Я могу быть не прав, но мне кажется, что в данном случае перенести подобную схему на protobuf будет достаточно проблематично.
И да, сейчас protobuf рассматривается как одна из альтернатив 2-ой версии.
Посмотрите ещё на cap'n'proto — он рвёт google protobuf просто на кусочки.
Делюсь свои испытанным решением. В бинарном протоколе реализованы простые типы: int8, int16, int32, int64, float, double, string и список любых типов и любой вложенности. Места занимает минимум. Естественно каждый пакет приходится формировать и парсить вручную (с помощью индивидуального кода для каждого пакета), но от этого больше плюсов нежели минусов, так как есть гибкая возможность в случае изменения формата пакета внести версионные изменения.
Отвечу здесь. bson и даже msgpack не достаточно компактны. И первый и второй вместе с собственно данными содержат структуру пакета. При пересылке множества пакетов эта информация остается долгое время (если не на протяжении всей жизни приложения) неизменной и вносит существенный оверхед. Вот пример из MessagePack — {«compact»:true,«schema»:0} — 18 байт, и это сообщение еще надо как-то передать по сети, то-есть обернуть хотя бы заголовком с длиной сообщения и типом сообщения. В моем варианте заголовок занимает 4 байта и сами данные — 2 байта. Итог 6 байт пригодных для отправки по сети вместо пускай даже 18+(4)
Protobuf упакует подобный месседж в 4 байта при более изящной реализации которую легче поддерживать :)
Зачем передавать в _каждом_ пакете его структуру, если 1) эта структура уже известна обеим сторонам (и серверу, и клиенту) 2) даже если неизвестна, то особым сообщением передать структуру, а данные гонять без описания структуры
а почему было не взять гугловый protocol buffers?
И мы конечно же увидим тут аргументированные примеры треша и ада?
лично я треша и ада с протобуфом не наблюдал (очевидно не такие сложные структуры данных), но мои знакомые сильно намучилась с протобуфом
>но мои знакомые сильно намучилась с протобафом
Не факт, что их мучения связаны именно с реализацией протобафа.
Использую его уже несколько лет. Никаких проблем не испытывал.
Все проблемы которые встречал у коллег, были от незнания как его использовать.
радуют такие знакомые
Пастернака читали?
> протокол с гарантированной доставкой, реализованный поверх UDP.

Для чего такая конструкция нужна? (Почему не TCP ?)
Различия в скорости и способе обработки пакетов.

TCP:
-требует установки соединения(на это тратим время)
-запись/чтение из буфера
-задержка ожидания заполнения буфера(можно пофиксить флагом NO_DELAY)
-если какой-то пакет потерялся, то вся очередь стоит пока не доставят потерянный покет/таймаут

UDP:
-нет соединения, просто шлем пакет
-пакет либо пришел весь, либо вообще не пришел(в случае с TCP могут быть фрагменты)
-длина заголовка меньше

RUDP:
-добавляет флаг доставки, очередность и тд.

С RUDP мы можем организовать сразу несколько очередей(каналов) передачи данных с разными настройками(гарантировать доставку, соблюдать порядок, приоритет) в пределах одного «соединения».
Все верно, мы не можем себе позволить дополнительную задержку на установление TCP-cоединения.
Хотелось бы отметить то, что реально раздражает.

1) блокировка интерфейса пользователя в стандартном клиенте игры при сетевых проблемах.

2) арта 9-10 уровней

Вопросы:

1. Где Ольга Сергеевна? Она в декрете? ;)
2. За оптимизацию последних патчей спасибо. Ноут стал норм тянуть.
3. Приходите на конференции, Барышников очень интересно рассказывал тогда 2 часа. Жалко до 45 минут теперь урезали.
У вас зоопарк технологий и решений просто потрясающий. Про использование того же RabbitMQ и логгера интересно было бы послушать. Многие такое за всю жизнь не видят.
4. Что нужно знать чтобы устроиться программистом-юниором к вам в Питере? ;)
5. Реально у вас получить статку по игрокам для Data Science Capstone? Можно конечно и самому, но с ограничениями api получится сдвиг по времени.
1. Не знаю, честно. Я простой разработчик и кто такая Ольга Сергеевна не имею ни малейшего понятия.
2. Спасибо за доброе слово, и хоть моего кода на клиенте практически нет, приятно слышать что кому-то нравится.
3. Так вроде бы WG присутствует на конференциях.
4. Не знаю, я работаю в Минске. Попробуйте порыться на официальном сайте, может быть найдете подходящую вакансию, я попал именно так.
5. Не знаю, попробую выяснить в понедельник.
Ольга Сергеевна это девушка на тизере, слева )
https://www.youtube.com/user/wotTV4players
> 4. Что нужно знать чтобы устроиться программистом-юниором к вам в Питере? ;)

Набор приостановлен, насколько мне известно.
Какую реализацию Python используете? GIL не мешает? Какую версию языка?
CPython 2.7, с небольшими изменениями. GIL не мешает — Python-код обрабатывается в одном потоке.
все ваши оптимизации… год назад на ноуте был фпс40 сейчас к 20 со всякими твикерами еле еле дотягивает
Я так понимаю, что статью вы не читали, т.к. описанная в ней оптимизация не имеет никакого отношению к отрисовке сцены боя на клиенте.
Интересная статья. Хотелось бы больше статей на тему архитектуры серверных решений для гейм дева.

Интересно было бы узнать про коммуникацию узлов между собой: как узнают друг о друге, как происходит балансировка нагрузки. Вообще хотелось бы побольше узнать про изнанку BigWorld.

Есть мнение, что реалтаймовые игры будут трендом нескольких ближайших лет. Т.е. топ гроссинг будут покорять игры, требовательные к хорошей модели синхронизации клиент-сервера (Шутеры, RTS, ...). Причем стоит ожидать их не только от крупных компаний, но и от небольших компаний-разработчиков игр, от инди разработчиков в том числе. Сейчас самое дешевое решение — использовать синхронизацию типа мастер-клиент в связке с каким-нибудь облачным решением вроде Unity Photon. Что собственно и делают маленькие студии. У такого решения есть недостатки, учитывая, что часто реал-тайм игры — соревновательные игры, требовательные к наличию авторитарной стороны.

По сути для студии, которая решит выпускать подобные игры будет несколько путей: покупка лицензии на готовый движок (например BigWorld), либо разработка своего решения. Вот тут самое интересное, ведь для того, чтобы начать работать с большим закрытым движком требуется время, да и куча денег, которых часто у студий нет. В итоге они начинают делать свои решения.

Я как раз работаю в одной из таких студий. Правда у них в свое время получилось наработать неплохую кодовую серверную базу, которая покрывает пока что все потребности, но это ненадолго. Понятно, что в процессе жизни студии принимались решения, позволяющие дешево добиваться цели, в итоге получился монолитный C++ сервер, работающий на мощных железках. Из плюсов: весь онлайн (относительно WoT мизерный) можно обслуживать в одном сервере, все работает шустро и оптимизировано. Из минусов: никакого масштабирования, вся бизнес-логика на C++ (с трудом можно найти толковых спецов, а даже если найдешь, то они будут долго пилить свои задачи).

Мне кажется можно сформировать какой то пул best practice, или может даже доступных для многих решений, которыми смогут пользоваться разработчики.
Ну так есть же доклад об архитектуре WoT
https://www.youtube.com/watch?v=5y23xezgQKE
Благодарю, не видел этого доклада.
А CellApp это физический хост или некая виртуальная машина? Сколько ресурсов необходимо для расчета одного боя?
CellApp — это отдельный процесс. К сожалению, ответить сколько именно ресурсов необходимо, не представляется возможным. Т.к. нагрузка постоянно меняется и бой может обсчитываться сразу на нескольких машинах внутри кластера.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий