Если вы пишете не казуалку под веб и не беспощадный суровый рогалик, без сохранения данных на диск не обойтись.
Как это делается в Unity? Вариантов тут достаточно — есть класс PlayerPrefs в библиотеке, можно сериализовать объекты в XML или бинарники, сохранить в *SQL*, можно, в конце-концов, разработать собственный парсер и формат сохранения.
Рассмотрим поподробнее с первые два варианта, и заодно попробуем сделать меню загрузки-сохранения со скриншотами.

Будем считать, что читающий дальше базовыми навыками обращения с этим движком владеет. Но при этом можно не подозревать о сущестовании в его библиотеке PlayerPrefs, GUI, и ещё в принципе не знать о сериализации. С этим всем и разберёмся.
А чтобы эта заметка не стала слишком уж увлекательной и полезной, ориентирована она самый неактуальный в мобильно/планшетно/онлайновый век вариант — сборку под винду (хотя, конечно, более общих моментов достаточно).

• Кстати, пару недель назад на Хабре была статья, где автор упомянул, что Unity3D проходят в курсе компьютерной графики на кафедре информатики питерского матмеха. Занятный факт, немало говорящий о популярности движка.
  Хотя насколько это в целом хорошая идея — на мой взгляд, тема для дискуссии. Может быть, обсудить это было бы даже интереснее вопросов сериализации =)

Строительство более широких дорог может ухудшить ситуацию с дорожным движением. Обычно этот контринтуитивный и контрпродуктивный результат объясняют следующим образом: чем больше дороги, тем более крупные торговые центры они привлекают, что в свою очередь привлекает больше автомобилей. Но это ещё не вся история. В 1960-х Дитрих Браес обнаружил теоретическую конфигурацию дорог, в которой строительство новой соединительной дороги может замедлить движение каждого, даже если количество машин остаётся постоянным. И наоборот, закрытие одной дороги в сети Браеса позволит всем добираться домой быстрее. Такое явление настолько странно, что заслуживает собственного определения — «Парадокс Браеса».

Несколько лет назад Джоел Коэн сказал мне, что парадокс Браеса может стать хорошей темой для моей колонки в «Computing Science». Я засомневался. Опубликовано уже немало обсуждений этого парадокса, в том числе потрясающие статьи самого Коэна, а также книга Тима Рафгардена (обзор которой я написал для American Scientist). Я не считал, что смогу добавить что-то новое к дискуссии.

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

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

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


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

Дорогие разработчики, вы чувствуете себя неуютно, потому что вы быстро пишете только на восьми языках для трех семейств устройств? Вздрагиваете ли вы, едва заслышав о переходе на очередной фреймворк? Откладывали ли вы любимый проект из-за того, что не могли определить, какая облачная платформа подойдет лучше всего?
Возможно, у вас тоже паралич разработчика. Бойтесь! Это не лечится.

Богатство доступных программистам опций сегодня просто чудовищно. Мы задохнулись под тем, что извергает рог изобилия. Последние несколько лет я зарабатывал на том, что писал на Java, Objective-C, C, C++, Python, Ruby, JavaScript, PHP (прошу прощения) с разными вариантами SQL/баз данных (MySQL, PostgreSQL, MongoDB, BigTable, Redis, Memcached и другими). Нравится ли это мне? Черт побери, нет. По большей части я просто чувствую вину за то, что не делал ничего на Erlang, Clojure, Rust, Go, C#, Scala, Haskell, Julia, Scheme, Swift или OCaml.


Я — жертва паралича разработчика: чувства ущербности из-за того, что индустрия софта развивается быстрее, чем может успеть один человек.

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

Перевод статьи Джеффа Прешинга (Jeff Preshing) How to Write Your Own C++ Game Engine.

Как написать собственный игровой движок на C++

В последнее время я занят тем, что пишу игровой движок на C++. Я пользуюсь им для создания небольшой мобильной игры Hop Out. Вот ролик, записанный с моего iPhone 6. (Можете включить звук!)

Hop Out — та игра, в которую мне хочется играть самому: ретро-аркада с мультяшной 3D-графикой. Цель игры — перекрасить каждую из платформ, как в Q*Bert.

Hop Out всё ещё в разработке, но движок, который приводит её в действие, начинает принимать зрелые очертания, так что я решил поделиться здесь несколькими советами о разработке движка.

С чего бы кому-то хотеть написать игровой движок? Возможных причин много:

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

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

Книга, что попалась не так давно на глаза, объединяет в себе оба мира: в ней, с одной стороны, описаны интересные в совокупности алгоритмические приемы; результат же работы — настольная игра «Yavalath» на приложенной картинке — был издан и пользовался достаточно широкой для абстрактной игры популярностью.

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

Игровой процесс может быть очень сложной задачей. Некоторые игры, например, «Змеи и лестницы», достаточно прямолинейны, однако такие игры, как SpaceChem и Factorio могут быть невероятно сложной проверкой работы мозга.

Каждой игре, от простой до сложной, очень важно объяснить игроку, как в неё играть. Неважно, бросает ли он кубики или решает сложные математические уравнения — главное, чтобы игрок понимал, как работает игра.

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

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

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

Об уничтожении сословий и гражданских чинов
Декрет ВЦИК и СОВНАРКОМа от 10.11.1917 года, ст. 2

---

Как-то же я обходился без этого раньше...

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

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

Статья посвящена языку ассемблер с учетом актуальных реалий. Представлены преимущества и отличия от ЯВУ, произведено небольшое сравнение компиляторов, скрупулёзно собрано значительное количество лучшей тематической литературы.

Постановка задачи

Это вторая, итоговая статья. Напоминаю цель: есть двигатель постоянного тока. Задача — разработать, собрать и протестировать устройство, позволяющиее реализовать контур управления с заданием тока применительно к этому двигателю. Желаемое время переходного процесса на застопоренном двигателе (без противо-ЭДС) — не более 10мс.

Текст разбит на две статьи:

• 1. Измерение сопротивления и индуктивности двигателя
• 2. Разработка управляющего контура

Напоминаю, как выглядит макет управляющего железа:

Цель поста — в максимально простой форме описать основные этапы разработки с помощью фреймворка LÖVE, на примере классической игры atari-автоматов Asteroids.

Здравствуйте!

До настоящего времени в арсенале средств высокоуровневого языка программирования Python отсутствовали модули для численного преобразования передаточных функций элементов САУ из частотной области во временную.

Поскольку функции обратного преобразования Лапласа широко используются при анализе динамических систем контроля измерения и управления, использование Python для указанных целей было весьма затруднительно, поскольку приходилось использовать менее точное обратное Фурье преобразование [1].

Указанную проблему решает модуль mpmath библиотеки Python свободного распространения (под лицензией BSD), предназначенный для решения задач вещественной и комплексной арифметики с плавающей точкой и заданной точностью.

Работу над модулем ещё в 2007 году начал Fredrik Johansson [2], и, благодаря помощи многих участников проекта, в настоящее время mpmath приобрёл возможности серьёзного математического пакета.

Что такое робастный контроллер и зачем нам усложнять себе жизнь? Чем нас не устраивает стандартный, всеми узнаваемый, ПИД-регулятор?

Ответ кроется в самом названии, с англ. «robustness» — The quality of being strong and not easy to break (Свойство быть сильным и сложно сломать). В случае с контролером это означает, что он должен быть «жестким», неподатливым к изменениям объекта управления. Например: в мат. модели DC мотора есть 3 основных параметра: сопротивление и индуктивность обмотки, и постоянные Кт Ке, которые равны между собой. Для расчета классического ПИД регулятора, смотрят в даташит, берут те 3 параметра и рассчитывают коэффициенты ПИД, вроде все просто, что еще нужно. Но мотор — это реальная система, в которой эти 3 коэффициента не постоянные, например в следствии высокочастотной динамики, которую сложно описать или потребуется высокий порядок системы. Например: Rдаташит=1 Ом, а на самом деле R находиться в интервале [0.9,1.1] Ом. Так во показатели качества в случае с ПИД регулятором могут выходить за заданные, а робастный контроллер учитывает неопределенности и способен удержать показатели качества замкнутой системы в нужном интервале.

Еще один игровой бот для «Космических рейнджеров HD» (издатель 1С) наводит на интересные мысли о путях развития искусственного интеллекта (ИИ).

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


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

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

Это продолжение предыдущей статьи. Мы шаг за шагом создаем движок, на котором будет работать игровая логика нашей экономической стратегии. Если вы видите это впервые — настоятельно рекомендую начать с Части 1, так как это зависимое продолжение и требует ее контекста.

Как и раньше — внизу статьи вы можете найти полный код на ГитХаб и ссылку на бесплатное скачивание.

---

Всем привет. В связи с выходом моей игры SpaceLab на GreenLight я решил начать серию статей о разработке игры на C#/Unity. Она будет основываться на реальном опыте её разработки и немного отличаться от стандартных гайдов для новичков:

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

---

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

Зато я шаг за шагом расскажу о создании движка, на котором будет работать игровая логика нашей экономической стратегии.

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

Кого заинтересовало узнать, что за игра — внизу есть видео и ссылка на бесплатное скачивание.