Pull to refresh
161
0
Артём @artch

User

Send message
Да, игроку доступен один большой JSON-объект для сохранения любых данных.
Битва с соседом без «подписки»: 1 такт игрока1, 5 тактов соперника: пока более умный ИИ игрока1 идет к ресурсу, соперник уже подошел к нему

Такты для всех игроков идут одинаково. Просто за такт один игрок с лучшим тарифом может выполнить более ресурсоемкий скрипт, чем другой. Но при этом более грамотно написанный скрипт может быть менее ресурсоемким сам по себе, поэтому преимущество не очевидно.
Сложность скрипта мы и не пытаемся определять. Ограничение идет по физическому времени исполнения скрипта в миллисекундах.
Попробуйте сейчас — заработало?
В Transport Tycoon нужно было уничтожать конкурентов похлеще, чем в каком-нибудь Старкрафте :)

А если серьезно, то здесь сеттинг практически как в шахматах. Это скорее похоже на соревнование для программистов, какой-либо реализм отсутствует.
1) Подписка на объем серверной мощности (CPU и память). Все честно, подробности — на старте.
2) Тут уже задача сделать такой гейм-дизайн, чтобы подобное было затруднено. Да и универсальной стратегии быть не может, потому что комнаты будут различаться по ландшафту.
Все верно, Травиан — наиболее близкий пример. Надеюсь, мы вас не разочаруем :)
Да, смысл слова «первая» не в том, что это первая «игра для программистов», а в том, что первая «стратегическая MMO-песочница для программистов».
Опять же — это не MMO в реальном времени, в которой юниты живут всегда, а сессионная игра, матчи в которой запускаются и завершаются. Разница огромна.
В оригинале было бы аутентичнее.
И первый вопрос, который возник, был связан с роутингами в клиентской части. Нам была необходима надёжная и простая система, которая поддерживала бы вложенные друг в друга шаблоны и позволяла однозначно сопоставлять определённому URL необходимый шаблон. После недолгих поисков мы выбрали ui-router.

Если вам нужна была надежная и простая система, то, знаете, замороченный и громоздкий ui-router — это не самый очевидный выбор. route-segment спроектирован гораздо проще, и при этом предоставляет все описанные вами функции (disclaimer: я автор).
Если вы покажете своим разработчикам полезность и целесообразность тестирования как основного способа разработки, а не просто как одной из частей процесса разработки, то все вопросы про барское дело отпадут само собой.
Надо быть известной личностью, чтобы утверждать «излишне говорить». Почему излишне? Мы все по какой-то причине уже должны знать, куда автор обычно посылает людей?

И вообще, очень странная тема для поста. Это пост для личного ЖЖ, а не для Хабра.
Недавно меня вызвали на Ice Bucket Challenge. Думаю, излишне говорить, куда я по-дружески послал автора этого вызова.

А вы, собственно, кто?
Нет, элементом рекурсии является кусок функциональности проекта (feature), а не тип сущности. Подробнее об этом по ссылке, что я привел выше.
Скрытый текст
|-- app.js
|-- controllers/
|   |-- MainCtrl.js
|   |-- AnotherCtrl.js
|-- filters/
|   |-- MainFilter.js
|   |-- AnotherFilter.js
|-- services/
|   |-- MainService.js
|   |-- AnotherService.js
|-- directives/
|   |-- MainDirective.js
|   |-- AnotherDirective.js


Не путайте людей. Данный пример (второй из раздела «Структура проекта») — это точно такое же «Плохо», как и предыдущий первый. Подход «структурирование по типу» нельзя использовать даже в проектах с небольшой кодовой базой. Во-первых, маленькие проекты имеют тенденцию вырастать в большие, и вам впоследствии придется делать очень болезненный рефакторинг; во-вторых, это уменьшает пользу от существования единого соглашения по структуризации кода в разных проектах.

«Хорошим» примером является только третий. Причем я бы обязательно добавил, что структура должна быть рекурсивной, а не одноуровневой. Больше чтива по теме из блога разработчиков.
Модули в AngularJS могут быть объявлены различными способами: либо с использованием переменной, либо через getter-синтаксис. Всегда используйте второй способ (более того, он рекомендован разработчиками фреймворка).

А можно конкретно ткнуть в место по указанной ссылке, где разработчики такое рекомендуют?
Только вот extremely как раз и переводится как «чрезвычайно, очень, крайне». «Экстремально» — неверный буквальный перевод, в русском языке это слово не означает степень усиления.

slovari.yandex.ru/extremely/%D0%BF%D0%B5%D1%80%D0%B5%D0%B2%D0%BE%D0%B4/
Graphic designer и UX designer — две разные профессии. Дрибл с его красивостями для первых, а вторым часто бывает достаточно одноцветных вайрфреймов.

Information

Rating
Does not participate
Location
Кировская обл., Россия
Registered
Activity