в League of Legends каждый месяц играет около 70 млн уникальных пользователей, вдобавок в загрузочном клиенте, у них встроен маленький браузер, отображающий медиаинформацию о последних изменениях, новых скинах и так далее.
Можно сказать, что их браузер более популярный, чем опера?
Можно еще раз уточнить что такое эти 55 миллионов и уникальных пользователей? Как вы их считаете?
Можно уточнить, что в данной оптимизации является нестандартным?
Профайлинг mysql запросов — вполне себе best practics,
рефакторинг кода, особенно после адекватного анализа — тоже вполне разумный и популярный шаг,
То есть я бы сказал, что вы все сделали верно, даже профессионально, но где же изюминка?
А еще это часто происходит, потому что всякие замы — частенько родственники, которые строят из себя невесть что, и когда админ банка им поясняет политику безопасности, они плюют на это свысока, а потом считают, что админ виноват.
Вместо японского DDR можете поискать ITG, которая практически полностью ее копирует, и когда-то их засудили, после чего они пошли к Андамиро делать пятикнопочный Pump-Pro.
Но пока они работали с четырехкнопочным, они сделали официальный InTheGroove для PC и PS/2, то есть на этих платформах можно запустить полностью официальную эмуляцию аркадного автомата.
Где-то на на торренте я вроде до сих пор раздаю PC вариант, если не найдете, напишите в личку.
Интересные перцы. С ними пытаешься связаться — постоянно в отпуске, а с вами так сами связались.
P.S. у нас два набора падов — один полноценный аркадный, второй — степмания через usb. Но под виндой.
Разницу в общем-то видно ). Удачи с тренировками.
Эта игра пользуется большой популярностью в нескольких странах, и основной рынок кроме самих автоматов — запчасти.
Кроме того, могу заверить, что увлеченные игроки вполне способны купить такой автомат в личное пользование, несмотря на то, что танцевальный автомат гораздо дороже чем вообще среднестатистический аркадный автомат — в основном из-за лицензий на треки.
Бесплатная степмания, даже самая последняя, не соответствует в точности официальному автомату, а для профессионалов это имеет значение (сам участвовал в чемпионатах, и знаю о чем говорю).
Ну и USB не может повторить идеально тайминги Jamma, счет идет на милисекунды срабатывания.
1. Класс — специальная синтаксическая конструкция представленная множеством обобщённых логически связанных сущностей.
2. Если давать более точно определение, то класс в CoffeeScript это абстрактный тип данных, который определяет альтернативный способ работы с объектами.
Странная размытая статья. Если второе определение более точное, почему бы именно его не указать первым?
Недавно пытался понять, почему один знакомый не понимает как использовать классы (он только учит ООП), и понял, что большинство людей пытается заучить шаблонные определения, без попыток пояснить своими словами.
Когда он сказал, что класс это набор связанных функций и данных, я понял в чем проблема.
Потому что на самом деле — наоборот.
Класс — это в первую очередь данные, а потом уже функции, которые работают именно с этими данными.
Если рассматривать именно в таком ключе, иерархия становится на свои места. Проще проектировать что где должно быть.
Мстители наглядно продемонстрировали, что работа в виртуальном мире крайне удобна всяким научникам, которые работают с моделями чего-либо (физика, генетика).
А еще точнее дизайн.
Я вот сразу представляю себе какого-нить дизайнера, который меняет внешний вид чего-либо, размахивая руками. Комнату себе так планировать — шикарно.
>Не известно почему, но исторически человек пришел к тому, что считать десятками (не пятерками, дюжинами или двоично) удобнее.
Известно почему — запись чисел идет в десятичной системе, и разделить сложные вычисления на отдельные операции можно поцифрово.
Майя вот пользовались двадцатиричной системой, вероятно им было удобнее считать двадцатками.
есть 10 юнитов, убиты 4,5,6,7,8.
Сравните вероятность попадания в 3 юнит и в 9-й, учитывая что попадания в мертвые 4,5,6,7,8 также приведут к попаданию в 9-й.
Более красивый подход, который не злоупотребляет ресурсами, как дефрагментацию после окончания каждого раунда, пока не нашли…
1) То, что это уже сделано на ассемблере.
2) видимо на ассемблере разработчик шарил больше, чем на яве.
Меня не радует, что многие комментаторы рассуждают об экономии времени программиста, но если что-то уже написано и работает, предлагают это все переделать просто потому, что это можно сделать иначе.
Много ли хороших и грамотных программистов действительно все переделывают в уже работающих проектах так, как они рекомендуют?
И я уже писал выше, что всего на это было затрачено несколько неполных дней. Я думаю на любом языке это заняло бы ненамного меньше — так что даже с коммерческой точки зрения нет особой выгоды, а вот интересный опыт поимелся.
P.S. Если у вас есть свободное время, я могу кинуть детальный алгоритм боевки, напишете его на java, сравним скорость. Не то, чтобы сейчас было важно что оно будет считаться считается 5 секунд или 6, но все же я не думаю, что ява сможет обогнать ассемблер в конкретно этой задаче.
Их тело и контрольная сумма меняются в основном только на диске за счет обсфукация и шифрования, а не за счет реального полиморфизма.
Ядро вируса и отдельные его функции, остаются практически неизменными, ну то есть их логическая составляющая, ибо можно накидать случайных nop-ов и других бесполезных команд, уменьшая или увеличивая их количество. НО основные функции будут неизменны. Вирус не станет другим вирусом.
Основная суть — на ассемблере вместо работы с типами данных, просто выделяется область памяти и с юнитами работали просто по смещению адреса. Это действительно быстрее, чем работа с хэшами и массивами.
После окончания одного раунда, делаем дефрагментацию, оставляя только живых юнитов для более адекватного рандомайза — если рандомайзер выпадает на уже убитого в раунде юнита, вместо вычисления еще одного рандома (который опять может попасть на убитого), просто выбирается следующий юнит. Если убито 10 юнитов, следующих подряд, вероятность попадения в 11 юнит значительно увеличивается, но дефрагментировать чаще — большой расход времени.
В результате — в цикле у нас остались однотипные операции, которые можно оптимизировать буквально потактово, увеличив эффективность общего цикла.
Вот поискал по нашему форуму… Официальный лог боя — расчет длился около 20 секунд на сервере (двухпроцессорный intel)
Имеющийся симулятор1 на Си, написанным игроком, (домашний целерон) считает от 10 до 20 минут (много рандома).
Имеющийся симулятор2 на яве, написанный игроком, (домашний целерон) завис.
В бою участвовало примерно 2.5 миллиона юнитов.
P.S. Еще раз хочу сказать, что совершенно не хочу сказать что у нас какое-то уникальное достижение, просто удачно повезло с самой задачей. При открытии проекта существование подобного размера армий вообще не предполагалось, но не рассчитали с экономикой…
Я же явно указал, что основная проблема — объем данных, то есть память, а операции простейшие, зачем цепляться к другим словам?
По сути, основная доля времени уходит на:
1. В бою может участвовать несколько миллионов юнитов по обе стороны баррикады, у каждого юнита есть несколько параметров, которые меняются в процессе боя (щиты, броня, статус мертв/жив), на это нужно выделить память и быстро к ней обращаться.
3. Случайный выбор очередной жертвы при каждом выстреле, включая грамотный выбор очередной жертвы, если текущая уже мертва, и сортировка оставшихся живых.
В нашем конкретном случае это помогло избежать не только проблемы нагрузки на сервере, но так же и то, что игроки, среди которых есть программисты (ну ладно, может не профессиональные), даже после полного описания алгоритма, пытались и пытаются его воспроизвести на привычных им языках программирования, но на текущий момент, я не знаю ни одной попытки сделать это на ассемблере.
Текущие эмуляторы просчитывают бои гораздо дольше нашего (несколько минут то, что у нас секунды), в результате, учитывая случайную составляющую — для прогноза результата боя, было бы хорошо его прогнать раз 10-100 и затем взять уже среднее, на что уходят часы (прогнозируют обычно для самых крупных сражений).
P.S. Еще раз хочу сказать, что я просот привел пример удачного взаимодействия ассемблерной вставки для веб-проекта на практике. Спорить о том, что круче — компилятор или ассемблер я не хочу.
Можно сказать, что их браузер более популярный, чем опера?
Можно еще раз уточнить что такое эти 55 миллионов и уникальных пользователей? Как вы их считаете?
Профайлинг mysql запросов — вполне себе best practics,
рефакторинг кода, особенно после адекватного анализа — тоже вполне разумный и популярный шаг,
То есть я бы сказал, что вы все сделали верно, даже профессионально, но где же изюминка?
Сори, наболело.
Но пока они работали с четырехкнопочным, они сделали официальный InTheGroove для PC и PS/2, то есть на этих платформах можно запустить полностью официальную эмуляцию аркадного автомата.
Где-то на на торренте я вроде до сих пор раздаю PC вариант, если не найдете, напишите в личку.
P.S. у нас два набора падов — один полноценный аркадный, второй — степмания через usb. Но под виндой.
Разницу в общем-то видно ). Удачи с тренировками.
Некоторые музыканты махают смычками 8/5
И те и другие не особо прокачиваются.
Кроме того, могу заверить, что увлеченные игроки вполне способны купить такой автомат в личное пользование, несмотря на то, что танцевальный автомат гораздо дороже чем вообще среднестатистический аркадный автомат — в основном из-за лицензий на треки.
Бесплатная степмания, даже самая последняя, не соответствует в точности официальному автомату, а для профессионалов это имеет значение (сам участвовал в чемпионатах, и знаю о чем говорю).
Ну и USB не может повторить идеально тайминги Jamma, счет идет на милисекунды срабатывания.
2. Если давать более точно определение, то класс в CoffeeScript это абстрактный тип данных, который определяет альтернативный способ работы с объектами.
Странная размытая статья. Если второе определение более точное, почему бы именно его не указать первым?
Недавно пытался понять, почему один знакомый не понимает как использовать классы (он только учит ООП), и понял, что большинство людей пытается заучить шаблонные определения, без попыток пояснить своими словами.
Когда он сказал, что класс это набор связанных функций и данных, я понял в чем проблема.
Потому что на самом деле — наоборот.
Класс — это в первую очередь данные, а потом уже функции, которые работают именно с этими данными.
Если рассматривать именно в таком ключе, иерархия становится на свои места. Проще проектировать что где должно быть.
А еще точнее дизайн.
Я вот сразу представляю себе какого-нить дизайнера, который меняет внешний вид чего-либо, размахивая руками. Комнату себе так планировать — шикарно.
Не с каждым устаревшим плагином такое дефолтное поведение.
p.s. gmail, googledocs, адсенс, аналитикс…
Известно почему — запись чисел идет в десятичной системе, и разделить сложные вычисления на отдельные операции можно поцифрово.
Майя вот пользовались двадцатиричной системой, вероятно им было удобнее считать двадцатками.
Сравните вероятность попадания в 3 юнит и в 9-й, учитывая что попадания в мертвые 4,5,6,7,8 также приведут к попаданию в 9-й.
Более красивый подход, который не злоупотребляет ресурсами, как дефрагментацию после окончания каждого раунда, пока не нашли…
Но всегда готовы прислушаться :)
2) видимо на ассемблере разработчик шарил больше, чем на яве.
Меня не радует, что многие комментаторы рассуждают об экономии времени программиста, но если что-то уже написано и работает, предлагают это все переделать просто потому, что это можно сделать иначе.
Много ли хороших и грамотных программистов действительно все переделывают в уже работающих проектах так, как они рекомендуют?
И я уже писал выше, что всего на это было затрачено несколько неполных дней. Я думаю на любом языке это заняло бы ненамного меньше — так что даже с коммерческой точки зрения нет особой выгоды, а вот интересный опыт поимелся.
P.S. Если у вас есть свободное время, я могу кинуть детальный алгоритм боевки, напишете его на java, сравним скорость. Не то, чтобы сейчас было важно что оно будет считаться считается 5 секунд или 6, но все же я не думаю, что ява сможет обогнать ассемблер в конкретно этой задаче.
Ядро вируса и отдельные его функции, остаются практически неизменными, ну то есть их логическая составляющая, ибо можно накидать случайных nop-ов и других бесполезных команд, уменьшая или увеличивая их количество. НО основные функции будут неизменны. Вирус не станет другим вирусом.
После окончания одного раунда, делаем дефрагментацию, оставляя только живых юнитов для более адекватного рандомайза — если рандомайзер выпадает на уже убитого в раунде юнита, вместо вычисления еще одного рандома (который опять может попасть на убитого), просто выбирается следующий юнит. Если убито 10 юнитов, следующих подряд, вероятность попадения в 11 юнит значительно увеличивается, но дефрагментировать чаще — большой расход времени.
В результате — в цикле у нас остались однотипные операции, которые можно оптимизировать буквально потактово, увеличив эффективность общего цикла.
Вот поискал по нашему форуму… Официальный лог боя — расчет длился около 20 секунд на сервере (двухпроцессорный intel)
Имеющийся симулятор1 на Си, написанным игроком, (домашний целерон) считает от 10 до 20 минут (много рандома).
Имеющийся симулятор2 на яве, написанный игроком, (домашний целерон) завис.
В бою участвовало примерно 2.5 миллиона юнитов.
P.S. Еще раз хочу сказать, что совершенно не хочу сказать что у нас какое-то уникальное достижение, просто удачно повезло с самой задачей. При открытии проекта существование подобного размера армий вообще не предполагалось, но не рассчитали с экономикой…
По сути, основная доля времени уходит на:
1. В бою может участвовать несколько миллионов юнитов по обе стороны баррикады, у каждого юнита есть несколько параметров, которые меняются в процессе боя (щиты, броня, статус мертв/жив), на это нужно выделить память и быстро к ней обращаться.
3. Случайный выбор очередной жертвы при каждом выстреле, включая грамотный выбор очередной жертвы, если текущая уже мертва, и сортировка оставшихся живых.
В нашем конкретном случае это помогло избежать не только проблемы нагрузки на сервере, но так же и то, что игроки, среди которых есть программисты (ну ладно, может не профессиональные), даже после полного описания алгоритма, пытались и пытаются его воспроизвести на привычных им языках программирования, но на текущий момент, я не знаю ни одной попытки сделать это на ассемблере.
Текущие эмуляторы просчитывают бои гораздо дольше нашего (несколько минут то, что у нас секунды), в результате, учитывая случайную составляющую — для прогноза результата боя, было бы хорошо его прогнать раз 10-100 и затем взять уже среднее, на что уходят часы (прогнозируют обычно для самых крупных сражений).
P.S. Еще раз хочу сказать, что я просот привел пример удачного взаимодействия ассемблерной вставки для веб-проекта на практике. Спорить о том, что круче — компилятор или ассемблер я не хочу.