Несколько лет назад меня пригласили консультантом по одному проекту ПО для крупной французской технологической компании. Увиденное выходит за рамки всего, что я мог представить в разработке. Простое отсутствие профессиональной компетентности оказалось не самым худшим. Гораздо хуже было крайнее презрение к человеческому достоинству, что показалось мне сравнимо с тюрьмой в том виде, как я её представляю. Вот список, проверьте сами.

Масштаб

• Разработка программного обеспечения для государственного агентства.
• Сложность низкая, с несколькими вывертами.

Правительство платит авансом несколько миллионов евро. План разработки на два-три года. Для начала компания нанимает несколько разработчиков и продолжает удваивать размер команды каждые три месяца или около того, осваивая бюджет по мере поступления средств.

7 лет спустя проект ещё не оформился. Набегают штрафы по несколько тысяч евро в сутки. Руководство решает сократить расходы и производит увольнения опытных сотрудников, нанимая людей с небольшим или нулевым опытом работы.

10 лет спустя, учитывая катастрофическое состояние проекта, менеджмент среднего звена решает нанять некоторых людей с опытом разработки, чтобы вернуться в график. Средняя текучка среди новичков: три месяца. Это минимальный срок, чтобы иметь право уволиться во Франции.

В предыдущей статье про 2048 мы использовали цепи Маркова, чтобы выяснить, что в среднем для победы нужно не менее 938,8 ходов, а также исследовали с помощью комбинаторики и полного перебора количество возможных конфигураций поля игры.

В этом посте мы используем математический аппарат под названием «марковский процесс принятия решений» для нахождения доказуемо оптимальных стратегий игры 2048 для полей размером 2x2 и 3x3, а также на доске 4x4 вплоть до тайла 64. Например, вот оптимальный игрок в игру 2x2 до тайла 32:


Случайное начальное число (random seed) определяет случайную последовательность тайлов, добавляемых игрой на поле. «Стратегия» игрока задаётся таблицей, называемой алгоритмом (policy). Она сообщает нам, в каком направлении нужно сдвигать тайлы в любой возможной конфигурации поля. В этом посте мы рассмотрим способ создания алгоритма, оптимального в том смысле, что он максимизирует шансы игрока на получение тайла 32.

Оказывается, что в игре 2x2 до тайла 32 очень сложно выиграть — даже если играть оптимально, игрок выигрывает только примерно в 8% случаев, то есть игра оказывается не особо интересной. Качественно игры 2x2 сильно отличаются от игр 4x4, но они всё равно полезны для знакомства с основными принципами.

В идеале мы хотим найти оптимальный алгоритм для полной игры на поле 4x4 до тайла 2048, но как мы убедились из предыдущего поста, количество возможных конфигураций поля очень велико. Поэтому невозможно создать оптимальный алгоритм для полной игры, по крайней мере, с помощью используемых здесь методов.

Однако мы можем найти оптимальный алгоритм для укороченной игры 4x4 до тайла 64, и, к счастью, мы увидим, что оптимальная игра на полях 3x3 качественно выглядит похожей на некоторые успешные стратегии полной игры.

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

Все мы еще с уроков информатики знаем, что информация внутри компьютера передаётся при помощи нулей и единиц, но оказалось, что большинство айтишников, с которыми я общаюсь (и довольно хороших!) слабо представляют, как же, все-таки, устроен компьютер.

Как заставить песок делать то, чего мы от него хотим?

Для большинства людей познания устройства компьютера оканчиваются на уровне его составных элементов — процессор, видеокарта, оперативная память… Но что именно происходит внутри этих чёрных прямоугольничков после подачи питания — магия. В этой статье (скорей всего, даже серии статей) я постараюсь простым языком объяснить, как же устроены эти таинственные прямоугольнички.

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

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

Тогда как это удаётся играм?

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

Часть 1. Линейные структуры

Массив

Когда вам нужен один объект, вы создаёте один объект. Когда нужно несколько объектов, тогда есть несколько вариантов на выбор. Я видел, как многие новички в коде пишут что-то типа такого:

// Таблица рекордов
int score1 = 0;
int score2 = 0;
int score3 = 0;
int score4 = 0;
int score5 = 0;

Это даёт нам значение пяти рекордов. Этот способ неплохо работает, пока вам не потребуется пятьдесят или сто объектов. Вместо создания отдельных объектов можно использовать массив.

// Таблица рекордов
const int NUM_HIGH_SCORES = 5;
int highScore[NUM_HIGH_SCORES] = {0};

Будет создан буфер из 5 элементов, вот такой:



Заметьте, что индекс массива начинается с нуля. Если в массиве пять элементов, то они будут иметь индексы от нуля до четырёх.

Вдохновение на написание данной статьи было получено после прочтения похожей публикации для архитектуры x86 [1].

Данный материал поможет тем, кто хочет понять, как устроены программы изнутри, что происходит до входа в main и для чего всё это делается. Также я покажу как можно использовать некоторые особенности библиотеки glibc. И в конце, как и в оригинальной статье [1] будет визуально представлен пройденный путь. В большинстве своём статья представляет собой разбор библиотеки glibc.

Итак, начнём наш поход. Будем использовать Linux x86-64, а в качестве инструмента отладки — lldb. Также иногда будем дизассемблировать программу при помощи objdump.

Исходным текстом будет обычный Hello, world (hello.cpp):

#include <iostream>
int main()
{
        std::cout << "Hello, world!" << std::endl;
}

Здравствуй, Хабр! Данная статья предназначена для тех, кто приблизительно шарит в математических принципах работы нейронных сетей и в их сути вообще, поэтому советую ознакомиться с этим перед прочтением. Хоть как-то понять, что происходит можно сначала здесь, потом тут.

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

Вряд ли пользователь домашнего ПК заинтересуется тем, чтобы блокировать устройства на своем ПК. Но если дело касается корпоративной среды, то все становится иначе. Есть пользователи, которым можно доверять абсолютно во всем, есть такие, которым можно что-то делегировать, и есть те, кому доверять совсем нельзя. Например, вы заблокировали доступ к Интернету одному из пользователей, но не заблокировали устройства этого ПК. В таком случае пользователю достаточно просто принести USB-модем, и Интернет у него будет. Т.е. простым блокированием доступа к Интернету дело не ограничивается.

Однажды примерно такая задача и стояла передо мной. Времени на поиск каких-либо решений в Интернете не было, да и они, как правило, небесплатные. Поэтому мне было проще написать такой драйвер, и его реализация отняла у меня один день.

В этой статье я расскажу немного теоретическую часть, на основе которой все строится, и расскажу принцип самого решения.

Девять лет назад я имел неосторожность приобрести приставку PSP, чему был очень рад. Омрачало радость только отсутствие пасьянса. Не то, чтобы я был любителем пасьянса, но как-то привык я раскладывать один из вариантов — “Косынку”. Пришлось такой пасьянс написать самому. В дальнейшем этот написанный для PSP пасьянс я портировал под Windows и под QNX. В этой вот статье я и расскажу, как написать такую игру.

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

В связи с тем, что мне не удалось связаться со Сбербанком, точнее — с кем-то вменяемым с той стороны, хочу поделиться, чтобы если не исправить утечку данных, то хотя бы предупредить о ней.


Совсем недавно случайно обнаружил, что Сбербанк Онлайн густо утыкан счетчиками. Это Google, Doubleclick, Rutarget, ЯМетрика. Еще раз подчеркну, в личном кабинете, где люди переводят деньги, вводят очень персональную информацию и т.п., в этом личном кабинете натыканы скрипты, которые Сбербанку совсем не принадлежат, а принадлежат совсем не нашим компаниям, например. Давайте посмотрим, что из этого выходит (слайды и видео ниже).

Привет, Хабр! Меня зовут Александр, и сегодня мы сравним Unity и Unreal Engine 4.

Думаю, многие разработчики пробовали движок Unity и видели сделанные на нём игры, проекты, какие-то демки. Его главный конкурент — движок Unreal Engine. Он берёт своё начало в проектах компании Epic Games, таких как шутер Unreal Tournament. Давайте рассмотрим, как начать работу с движком Unreal после Unity и какие препятствия могут подстерегать нас на пути.

Эта статья и прилагаемое к ней приложение-пример поможет вам начать создавать полноценные приложения для Windows Phone 7. Вы узнаете об общих вопросах разработки на примере создания простого приложения для отслеживания количества топлива, потребляемого вашим автомобилем. В этой статье описываются вещи, которые вы должны знать, прежде чем приступить к созданию приложений для Windows Phone.

Вы также узнаете, как выполнять следующие задачи (ниже указаны ссылки на другие части):

• Следование рекомендациям по проектированию интерфейса
• Определение вашего приложения, начиная с идеи
• Создание нового проекта Windows Phone
• Создание страниц
• Навигация между страницами
• Разметка страницы
• Использование элементов управления для создания пользовательского интерфейса
• Добавление изображений и иконок
• Создание согласованного внешнего вида
• Отображение данных
• Создание классов данных
• Использование классов доступа к данным
• Сохранение и загрузка данных
• Восстановление приложения после дезактивации
• Валидация вводимых данных
• Доступ к фотографиям на Windows Phone

Всем привет!



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

Для тех кто не в курсе яйцебот — это машина, которая обычным фломастером умеет рисовать на любых сферических объектах: яйцах, теннисных шариках, ёлочных игрушках. Концепт механизма придумал дизайнер Bruce Shapiro в далеком 1990-м году, а не так давно знаменитая компания Evil Mad Scientist Laboratories выпустила в свободную продажу свою версию под названием The EggBot. Надо отдать должное Evil Mad Scientist Laboratories свой проект сделала открытым и разрешает пользоваться программным обеспечением для других яйцеботов даже в коммерческих проектах.

Введение

Почему псевдо-3d?

Зачем кому-то захочется создавать дороги в олдскульном стиле сегодня, когда каждый компьютер может на лету отрисовывать графику, состоящую из миллионов полигонов? Разве полигоны — не то же самое, только лучше? На самом деле нет. Полигоны действительно создают меньше искажений, но именно деформации в старых игровых движках дают такое сюрреалистическое, головокружительное чувство скорости, ощущаемое во многих дополигональных играх. Представьте, что область видимости управляется камерой. При движении по кривой в игре, использующей один из таких движков, похоже, что она заглядывает на кривую. Затем, когда дорога становится прямой, вид тоже выпрямляется. При движении в повороте с плохим обзором камера как будто заглядывает за выступ. И поскольку в таких играх не используется традиционный формат трасс с точными пространственными соотношениями, то можно без проблем создавать трассы, на которых игрок будет ездить с захватывающей дух скоростью. При этом не нужно беспокоиться о том, что объекты появляются на трассе быстрее, чем может среагировать игрок, потому что физическую реальность игры можно легко изменять в соответствии со стилем геймплея.

Но в такой системе есть и множество недостатков. Глубина физики, используемой в играх-симуляторах, будет утеряна, поэтому такие движки не приспособлены для этих игр. Однако они просты в реализации, быстро работают, а игры на их основе обычно очень интересны!

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

Как я создал первую функцию

Все началось с того что я захотел программировать на C# (до создания этой программы у меня было почти что никаких знаний о C#), и была одна программа которая не работала так как я хотел (Punto Switcher) долго-долго я искал к ней альтернативы и ненадолго остановился на dotSwitcher нравилась она мне… Но через некоторое время я решил что ей не хватает функционала и решил посмотреть исходный код, кое-где кое-как я разобрался как все работает, но больше всего не понимал одну вещь — WinAPI, и начал я искать информацию по функциям используемых в dotSwitcher и понемногу я начинал запоминать и понимать смысл всего этого волшебства (так мне тогда казалось).

На первый взгляд нижеприведённый материал может показаться ещё одним банальным «хэллоууорлдом», «туториалом от Капитана Очевидность», коих уже предостаточно на просторах Сети, но это впечатление обманчиво. На деле чтобы добиться того же результата с нуля у WinForms-программиста, не работавшего ранее с Entity Framework Core (не путать с классической Entity Framework) и вооружённого только уже валяющимися в изобилии на просторах Сети туториалами по EF Core и документацией может уйти куда больше времени, чем он наивно ожидал до того, как взялся за дело. Так случилось и со мной. Посему хочу поделиться опытом.

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

Концепция игры заключается в том что вам нужно взять на себя управление звездолетом и уничтожить как можно большее количество метеоритов. На вашем пути будут появляться вражеские звездолеты, которые будут мешать вам и после их уничтожения будут появляться «капсулы» после подбора которых будет доступен новый тип оружия. Игра будет называться Galaxy Desteroid.

Я люблю две вещи: Intellij IDEA и чистый код (Clean Code).
IDEA создана для чистого кода. Многие настройки по умолчанию уже стимулируют вас писать как надо.


Но она всё ещё не идеальна.
Когда я устанавливаю новую копию IDEA, я пробегаю по настройкам и выставляю свои любимые галочки.
Хочу ими с вами поделиться в надежде, что когда-нибудь и они станут стандартом.

Всем привет! Это вторая часть урока для новичков о том, как создать маленькую игру жанра Tower Defence на движке Unity. Мы остановились на создании скрипта для спауна крипов. Если интересно, прошу под кат.