Реализация поведения юнитов в RTS играх может стать серьезной проблемой. Компьютер, зачастую, контролирует огромное количество юнитов, в том числе и принадлежащих игроку, которые должны передвигаться в большом динамическом мире, попутно избегая столкновения друг с другом, выискивая врагов, защищая собственные базы и координируя атаки для истребления противника. Стратегии реального времени работают в реальном времени, что делает довольно сложным слежение за планированием действий и навигацией.

Этот урок описывает метод планирования течения игры и навигации юнитов, который использует многоагентные потенциальные поля. Он основан на работах под номерами [1, 2, 3]. (Смотри в конце статьи ссылки на используемые материалы)

Вот уже как неделю английская версия the art of command line висит в секции trending на Github. Для себя я нашел этот материал невероятно полезным и решил помочь сообществу его переводом на русский язык. В переводе наверняка есть несколько недоработок, поэтому милости прошу слать пулл-реквесты мне сюда или автору оригинальной работы Joshua Levy вот сюда. (Если PR отправите мне, то я после того, как пересмотрю изменения отправлю их в мастер-бранч Джоша). Отдельное спасибо jtraub за помощь и исправление опечаток.

Всем привет!

Две недели назад в Москве прошла очередная встреча CodeFreeze. Нашим гостем стал Евгений Кривошеев, признанный российский эксперт в области архитектуры программных систем, консультант из Scrumtrek/Skilltrek. Евгений прочитал офигеннейшую лекцию по архитектуре, как он любит и умеет.



В рамках этой встречи Евгений предложил обсудить последовательность решений, критичных для архитектуры любой системы. Выстраданная последовательность действий такова:

• Точки зрения на систему, или Почему мы слепнем при проектировании
• Адресация ключевых рисков, или Гордыня убивает
• Учитываем контекст, или Как не долбиться в закрытую дверь

• Реализация AI: как сделать максимально просто?
• RPC клиент-сервер: json или бинарная «самопальщина»?
• Асинхронные сокеты или многопоточная архитектура?
• Кеширование объектов на уровне приложения или больше памяти для СУБД?
• Работа с БД без Reflection API: действительно ли это так сложно?

        Сегодня мы продолжим рассматривать архитектуру и особенности реализации игрового backend'а на С++ для онлайн игры на примере ММО РПГ «Звездные Призраки». Это вторая часть статьи про сервер, начало можно прочитать здесь.

Перевод статьи Seven Deadly Sins of a Software Project автора Yegor Bugayenko.

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

Каждый программист неоднократно сталкивался с необходимостью проверки пользовательского ввода. Занимаясь веб-разработкой уже более 10 лет, я перепробовал массу библиотек, но так и не нашел той единственной, которая решала бы поставленные мною задачи.

Основные проблемы, которые встречаются в библиотеках валидации данных

Проблема №1. Многие валидаторы проверяют только те данные, для которых описаны правила проверки. Для меня важно, чтобы любой пользовательский ввод, который явно не разрешен, был проигнорирован. То есть, валидатор должен вырезать все данные для которых не описаны правила валидации. Это просто фундаментально требование.

Проблема №2. Процедурное описание правил валидации. Я не хочу каждый раз думать про алгоритм валидации, я просто хочу описать декларативно, как должны выглядеть правильные данные. По сути, я хочу задать схему данных (почему не «JSON Schema» — в конце поста).

Проблема №3. Описание правил валидации в виде кода. Казалось бы, это не так страшно, но это сразу сводит на нет все попытки сериализации правил валидации и использования одних и тех же правил валидации на бекенде и фронтенде.

Проблема №4. Валидация останавливается на первом же поле с ошибкой. Такой подход не дает возможности подсветить сразу все ошибочные/обязательные поля в форме.

Проблема №5. Нестандартизированные сообщения об ошибках. Например, «Field name is required». Такую ошибку я не могу показать пользователю по ряду причин:

• поле в интерфейсе может называться совсем по другому
• интерфейс может быть не на английском
• нужно различать тип ошибки. Например, ошибки на пустое значение показывать специальным образом

То есть, нужно возвращать не сообщение об ошибках, а стандартизированные коды ошибок.

Проблема №6. Числовые коды ошибок. Это просто неудобно в использовании. Я хочу, чтобы коды ошибок были интуитивно понятны. Согласитесь, что код ошибки «REQUIRED» понятней, чем код «27». Логика аналогична работе с классами исключений.

Проблема №7. Нет возможности проверять иерархические структуры данных. Сегодня, во времена разных JSON API, без этого просто не обойтись. Кроме самой валидации иерархических данных, нужно предусмотреть и возврат кодов ошибок для каждого поля.

Проблема №8. Ограниченный набор правил. Стандартных правил всегда не хватает. Валидатор должен быть расширяемый и позволять добавлять в него правила любой сложности.

Проблема №9. Слишком широкая сфера ответственности. Валидатор не должен генерировать формы, не должен генерировать код, не должен делать ничего, кроме валидации.

Проблема №10. Невозможность провести дополнительную обработку данных. Практически всегда, где есть валидация, есть необходимость в какой-то дополнительной (часто предварительной) обработке данных: вырезать запрещенные символы, привести в нижний регистр, удалить лишние пробелы. Особенно актуально — это удаление пробелов в начале и в конце строки. В 99% случаев они там не нужны. Я знаю, что я до этого говорил, что валидатор не должен делать ничего кроме валидации.

3 года назад, было решено написать валидатор, который не будет иметь всех вышеописанных проблем. Так появился LIVR (Language Independent Validation Rules). Есть реализации на Perl, PHP, JavaScript, Python (мы на python не пишем — фидбек по ней дать не могу). Валидатор используется в продакшене уже несколько лет практически в каждом проекте компании. Валидатор работает, как на сервере, так и на клиенте.

TZ_database, ключевой источник информации о часовых поясах в мире ПО, закрыта в следствии обвинения в нарушении авторских прав.

Закрытие было инициировано в связи с иском от Astrolabe Inc (производитель ПО для астрологов) против 2 физ. лиц, Артура Девида Олсона и Пауля Р. Эггерта, ментейнеров БД с середины 80х, 30 сентября в Бостоне — www.scribd.com/doc/67760407/ASTROLABE-INC-Vs-ARTHUR-DAVID-OLSON-and-PAUL-EGGERT-Complaint.

free heroes2 — свободная версия движка Heroes of Might and Magic II. Написан с использованием SDL русским (вроде бы) программистом. Существуют порты на Windows, Linux, WM, WinCE, Dingoo a320, Cowon V5… ну почти везде. Все кто хочет узнать больше — под кат

Если вы читаете эти строки, то будет вполне естественно предположить, что вы проводите за компьютером по крайней мере несколько часов в день, а то и больше. Такой режим работы привносит с собой достаточно сильную нагрузку на наши руки, которая может вызвать боли в кистях, запястьях и пальцах. Такие боли вызваны так называемым «туннельным синдромом» (синдромом карпального канала, кистевым туннельный синдром, carpal tunnel syndrome) — хроническим заболеванием.

В этой статье мы постараемся понять причины туннельного синдрома, возможные пути лечения и способы предупреждения этого нежелательного явления. Данная статья будет содержать достаточно много субъективных отступлений от формальных определений и формулировок, которые доступны на тех или иных медицинский сайтах, поскольку проводя за клавиатурой значительное количество времени за последние восемь лет, я вкусил последствия туннельного синдрома во всех его проявлениях.

Как развивается туннельный синдром и что мы при этом чувствуем

Итак, что же порождает это неприятное явление? Карпальный (туннельный) синдром вызывается сдавливанием нерва кисти (срединного нерва), который проходит в специальных каналах, образованных костями и связками. Естественно, при сдавливании нерва мы ощущаем боль, которая может чувствоваться в суставе кисти, но не только в нём. Сейчас мы пройдёмся по всем этапам обсуждаемого синдрома и постараемся связять физиологические процессы с тем, что мы можем ощущать при работе за компьютером.

В статье описаны основные трудности создания приложений под Android.
Рассматриваются базовые понятия программирования Android.
Для примера описано создание игры Sudoku из книги Hello, Android – Ed Burnette.
Осторожно много скриншотов.

Пошаговое руководство по созданию RSS-клиента на Android. Статья для начинающих разработчиков.
Android – операционная система для мобильных устройств от Google.
Система очень перспективная и динамично развивается. Базовые навыки разработки будут совсем не лишними.
Осторожно много скриншотов!

Эта статья — перепечатка статьи от 16 ноября 2007 г. с моего блога, ссылку на который можно найти в моем же профайле — но, поскольку так уж вышло, что тема эта, кажется, до сих пор многим интересна, к тому же не так давно я читал на эту тему доклад на конференции PHPConf… в общем — судите сами.

Вступление

В последнее время все большее распространение получает технология трансляции видео через веб – без необходимости скачивать медиа-контент на машину пользователя, с просмотром прямо из браузера. Таким образом можно просматривать довольно большое количество различных форматов видео, однако, это требует наличия определенных плагинов на стороне пользователя. Очевидно, самым распространенным подобным плагином является flash-player (ну хорошо, хорошо: если быть точным, то он, конечно же, не может сам по себе проигрывать видео – но позволяет легко создать приложение, способное воспроизводить видео-контент). Яркий пример такого подхода – youtube.com. Попытаюсь рассказать о том, как самостоятельно организовать трансляции флэш-видео на своей веб-странице и какие существуют подходы к этой проблеме.

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

Методы монетизации аудитории

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

По предоставляемых пользователям услуг можно выделить три основных категории сайтов:

• Специализированные интернет-магазины и сервисы (магазины программного обеспечения, музыки, видео, рефератов, темплейтов веб-дизайнов, документации, специализированных статей для профессионалов, сервисы доставки сообщений пользователям, розыгрыши и викторины, ответы на вопросы), основной задачей которых является предоставление посетителям специфических услуг или продажа контента (с оплатой за единицу контента). Такие ресурсы считают получение дохода от рекламы второстепенным заработком.
• Сайты, доступ к которым можно получить только на платной основе (нишевые и узкотематические профессиональные ресурсы с ценной информацией для определенной аудитории, ресурсы для взрослых) – обычно пользователям демонстрируют только общую информацию о ресурсе, а для того, чтобы получить к нему доступ, требуется сначала внести оплату. Рекламы на таких ресурсах практически не бывает.
• Ресурсы, предлагающие своим пользователям дополнительные сервисы и услуги – так, например, на сайте знакомств пользователи могут выделить свою анкету в результатах поиска, а в социальных сетях подарить другу какой-нибудь подарок.

Спустя некоторое время публикую 2 версию схемы. Если вам есть что добавить — с удовольствием жду от вас комментариев!

Оригинал по ссылке: extrastat.ru/scheme2.gif

Я работаю в одной компании, занимающейся написанием программного обеспечения в основном в области логистики. Работаю я уже 3 год, прошел через несколько проектов и узнал о тех, которые были до меня. И так уж повелось, что для каждого проекта заводилась своя внутренняя вики, которая по окончании проекта архивировалась и складировалась в таком виде на сервере. Проходило время, люди уходили и приходили, и опыт, накопленный по данному проекту постепенно забывался. Начинался новые проект и конвейер по производству велосипедов запускался вновь.

Введение в PHP 5.3 замыканий — одно из главных его новшеств и хотя после релиза прошло уже несколько лет, до сих пор не сложилось стандартной практики использования этой возможности языка. В этой статье я попробовал собрать все наиболее интересные возможности по применению замыканий в PHP.

Как только проект перестает быть завязан на ограниченное количество потребителей и растет география его применения, встает вопрос о применении временных зон. Когда я работал в одной известной интернет компании внедрение в работу временных зон (как в интерфейс отображения статистики, так и в программу анализа) было достаточно серьезным шагом.

Далее перевод :-)

В вашей системе время играет важную роль? Ваши пользователи/компоненты распределены по территории всего земного шара, или хотя бы нашей необъятной родины? Значит, вам нужны часовые пояса. Что ж, это просто. Самое сложное, что вам придется сделать — не запутаться. Об этом мы с вами и поговорим. Для начала вам нужно научиться правильно думать. Думая правильно, все остальное будет для вас либо самоочевидным, либо достаточно простым.

Начнем с часов. Все мы привыкли определять время, глядя на часы на стене. При работе с часовыми поясами такое время называется Wall clock time. В принципе, ничего плохого в нем нет, только в разных местах земного шара в один и тот же момент времени часы показывают разное время. Если задаться целью, можно придумать алгоритм перевода wall clock time одного часового пояса в wall clock time другого. Обычно надо прибавить/отнять разницу в часах между часовыми поясами, кроме (внимание) моментов перехода на летнее/зимнее время. Вот когда начинается переход, вычисления становятся по-настоящему сложными.

Нам же нужно что-то простое и пуленепробиваемое, как… целое число.

В последнее время на Хабре появляется множество статей, посвящённых Гугловским системам идентификации по лицам. Если честно, то от многих из них так и несёт журналистикой и мягко говоря некомпетентностью. И захотелось мне написать хорошую статью по биометрии, оно же мне не в первой! Пара неплохих статей по биометрии на Хабре есть — но они достаточно короткие и неполные. Тут я попробую вкратце обрисовать общие принципы биометрической идентификации и современные достижения человечества в этом вопросе. В том числе и в идентификации по лицам.

У статьи есть продолжение, которое, по-сути, является её приквэлом.

Интервью с Джоном Резигом, опубликованное 25 июля на usesthis.com

Кто вы и чем занимаетесь?

Я JavaScript программист. Я работаю в Khan Academy, разрабатываю обучающую систему следующего поколения. Я создатель и главный разработчик JavaScript библиотеки jQuery и автор двух книг о JavaScript – «Pro JavaScript Techniques» и «Secrets of the JavaScript Ninja».