Битва с соседом без «подписки»: 1 такт игрока1, 5 тактов соперника: пока более умный ИИ игрока1 идет к ресурсу, соперник уже подошел к нему
Такты для всех игроков идут одинаково. Просто за такт один игрок с лучшим тарифом может выполнить более ресурсоемкий скрипт, чем другой. Но при этом более грамотно написанный скрипт может быть менее ресурсоемким сам по себе, поэтому преимущество не очевидно.
1) Подписка на объем серверной мощности (CPU и память). Все честно, подробности — на старте.
2) Тут уже задача сделать такой гейм-дизайн, чтобы подобное было затруднено. Да и универсальной стратегии быть не может, потому что комнаты будут различаться по ландшафту.
И первый вопрос, который возник, был связан с роутингами в клиентской части. Нам была необходима надёжная и простая система, которая поддерживала бы вложенные друг в друга шаблоны и позволяла однозначно сопоставлять определённому URL необходимый шаблон. После недолгих поисков мы выбрали ui-router.
Если вам нужна была надежная и простая система, то, знаете, замороченный и громоздкий ui-router — это не самый очевидный выбор. route-segment спроектирован гораздо проще, и при этом предоставляет все описанные вами функции (disclaimer: я автор).
Если вы покажете своим разработчикам полезность и целесообразность тестирования как основного способа разработки, а не просто как одной из частей процесса разработки, то все вопросы про барское дело отпадут само собой.
Надо быть известной личностью, чтобы утверждать «излишне говорить». Почему излишне? Мы все по какой-то причине уже должны знать, куда автор обычно посылает людей?
И вообще, очень странная тема для поста. Это пост для личного ЖЖ, а не для Хабра.
Не путайте людей. Данный пример (второй из раздела «Структура проекта») — это точно такое же «Плохо», как и предыдущий первый. Подход «структурирование по типу» нельзя использовать даже в проектах с небольшой кодовой базой. Во-первых, маленькие проекты имеют тенденцию вырастать в большие, и вам впоследствии придется делать очень болезненный рефакторинг; во-вторых, это уменьшает пользу от существования единого соглашения по структуризации кода в разных проектах.
«Хорошим» примером является только третий. Причем я бы обязательно добавил, что структура должна быть рекурсивной, а не одноуровневой. Больше чтива по теме из блога разработчиков.
Модули в AngularJS могут быть объявлены различными способами: либо с использованием переменной, либо через getter-синтаксис. Всегда используйте второй способ (более того, он рекомендован разработчиками фреймворка).
А можно конкретно ткнуть в место по указанной ссылке, где разработчики такое рекомендуют?
Только вот extremely как раз и переводится как «чрезвычайно, очень, крайне». «Экстремально» — неверный буквальный перевод, в русском языке это слово не означает степень усиления.
Такты для всех игроков идут одинаково. Просто за такт один игрок с лучшим тарифом может выполнить более ресурсоемкий скрипт, чем другой. Но при этом более грамотно написанный скрипт может быть менее ресурсоемким сам по себе, поэтому преимущество не очевидно.
А если серьезно, то здесь сеттинг практически как в шахматах. Это скорее похоже на соревнование для программистов, какой-либо реализм отсутствует.
2) Тут уже задача сделать такой гейм-дизайн, чтобы подобное было затруднено. Да и универсальной стратегии быть не может, потому что комнаты будут различаться по ландшафту.
Если вам нужна была надежная и простая система, то, знаете, замороченный и громоздкий ui-router — это не самый очевидный выбор. route-segment спроектирован гораздо проще, и при этом предоставляет все описанные вами функции (disclaimer: я автор).
И вообще, очень странная тема для поста. Это пост для личного ЖЖ, а не для Хабра.
А вы, собственно, кто?
Не путайте людей. Данный пример (второй из раздела «Структура проекта») — это точно такое же «Плохо», как и предыдущий первый. Подход «структурирование по типу» нельзя использовать даже в проектах с небольшой кодовой базой. Во-первых, маленькие проекты имеют тенденцию вырастать в большие, и вам впоследствии придется делать очень болезненный рефакторинг; во-вторых, это уменьшает пользу от существования единого соглашения по структуризации кода в разных проектах.
«Хорошим» примером является только третий. Причем я бы обязательно добавил, что структура должна быть рекурсивной, а не одноуровневой. Больше чтива по теме из блога разработчиков.
А можно конкретно ткнуть в место по указанной ссылке, где разработчики такое рекомендуют?
slovari.yandex.ru/extremely/%D0%BF%D0%B5%D1%80%D0%B5%D0%B2%D0%BE%D0%B4/