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



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

Картинка для привлечения внимания

Успокоившись после шока из-за того, что моя первая игра не взорвала интернет, я решил сделать еще одну. Первая мысль, с которой началась разработка второй игры, возникла в голове и без обдумывания стала краеугольным камнем в фундаменте игры: «если игра с бесконечным геймплеем не стала популярной, то нужно делать контенто-зависимую игру с уровнями».

Так как небольшой опыт создания игры у меня уже был, я вооружился не клавиатурой, как в прошлый раз, а карандашом и бумагой, и принялся «придумывать» игру. На разных листах А4 я записывал свои мысли по разным направлениям: игровые механики, сеттинг, интерфейс, правила, интересные мысли, запомнившиеся игры из детства и т. п.; при этом я параллельно шерстил Google Play Market в поисках вдохновения. В итоге, спустя несколько дней, было принято решение, что игра станет головоломкой, а именно — пазлом. За это время мой мозг и пальцы заскучали по программированию, в результате чего захотелось сделать хоть какой-нибудь прототип игры. Это сподвигло меня на более интенсивную проработку идеи пазла, и в итоге в качестве рабочего был принят вариант со следующими правилами: игровое поле состоит из квадратных кусочков пазла (далее они будут называться тайлами), на которых располагаются разноцветные линии; тайлы можно менять местами; цель игры: собрать пазл единственным образом, в котором линии одного цвета замкнуты в некий узор.

Хотелось бы поделиться своим первым опытом создания такой штуки, как Arduino аквариум. Ранее я вообще не работал с электроникой, и, тем более, не знал как программируются микроконтроллеры. Но все-же решил попробовать свои силы и хотел бы поделиться результатами.

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

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

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

Главный враг раздолбайства — план.

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

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

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

Может показаться, что прототипировать — это вроде как не очень нужно. Херак-херак — и в продакшн. На самом деле, это чертовски важно в любом процессе; например, по заветам юзабелистов — это 70% работы. Вопрос только в том, как это можно делать.

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

Сегодняшний пост подготовил молодой коптеровод-конструктор по имени Денис. Он собирает компактный коптер с онлайн-трансляцией (FPV). Передаем слово ему:

Честно признаюсь, я с детства мечтал делать фотографии «с высоты птичьего полета». И когда DJI начали пиарить первый фантом, понял, что время пришло. Запускать планировал беззеркалку, поэтому и коптер искал соответствующий. В то время готовые решения с необходимой грузоподъемностью стоили от 3000$. Более того, они не складывались. А компактность была для меня основным параметром, так как наивно хотелось носить коптер в рюкзаке. Поэтому я решил собрать дрон самостоятельно.

Во второй лекции Мессенджеровских чтений профессор Ричард Фейнман расскажет о том, как математика используется для формулировки физических законов и задач. Он продемонстрирует, как разные математические утверждения могут описывать один и тот же физический закон, и чем всё-таки отличается математика от физики.


Источник: research.microsoft.com

P.S.: Как всегда, в комментариях вы можете предложить интересные видео на перевод.

Привет Хабравчане!

Сегодня я хочу рассказать вам о том, как можно сделать игру без навыков программирования. И да, это не просто красивое и заманивающее название, в созданную игру можно будет играть на Windows, Mac OS, Linux, Android и может быть даже на… iOS? Но об этом позже. Перед началом чтения статьи, я хочу дать вам мое понимание того, что создание игры без навыков программирования – это действительно не круто. Но знаете что еще больше не круто? Тот факт, что вы, владея языками программирования, сутками работаете над кодом, путая ваше рабочее место с постелью, нанимаете дизайнеров, договариваетесь со знакомыми музыкантами, платите рекламщикам, выпускаете свой продукт, а он не окупается! Ну, то есть игру, вашу, в любом случае будут скачивать, и какой-то доход будет капать. Но, будете ли вы довольны тем, какой в итоге получилась ваша игра, и как она продается? К чему я это все говорю? Если у вас в голове живет яркая идея, и вы давно хотите попробовать себя в создании игр, но единственный ваш тормозной элемент, это незнание компьютерных языков, смело пробуйте себя в этом деле. Если же вы владеете языками программирования, и может быть наплодили уже пару не плохих проектов, которые приносят прибыль, данная статья так же будет вам полезна. Я не советую никому здесь бросать все свои знания программирования, и начинать лепить игры в программе, о которой пойдет речь. Мое мнение на этот счет, достаточно простое. С помощью данного приложения, вы сможете создать презентацию вашей игры, затратив намного меньше времени, или как минимум ролик геймплея, который можно будет бросить на YouTube, создать шумиху, получить обратную связь, и работать над игрой, грея себя приятной мыслью, что ваша идея работает, люди ее оценили и ждут. Это не значит, что создание игр, в этой программе, ограничится лишь демо-версиями. Если вы действительно вложитесь душой в это дело, то спокойно сможете создавать полноценные проекты.

^{© Антон Кокарев}

Выхода Fallout 4 осталось ждать недолго. Множество фанатов по всему миру уже до дыр засмотрели тизеры игры, на форумах обсуждаются детали увиденного, и с новой силой разгорелся спор между адептами олдскульных «правильных» Fallout’ов 1/2 и теми, кому пришлись по душе скитания по пустоши в третьей части игры. Но оба лагеря геймеров, как и множество людей, никогда не игравших ни в какой Fallout, объединяет тяга к прекрасному — к постапокалипсису, к миру, лежащему в руинах. Вероятно, у психологов найдется в загашниках пара теорий, объясняющих, почему широким народным массам так интересна тема разрушенного мира, в котором выживают остатки человечества. Но не будем заниматься самодеятельным психоанализом, а лучше в преддверии выхода нового Fallout'a почитаем книги и посмотрим фильмы, в которых действие разворачивается во времена постапокалипсиса.

Сегодня мы представляем вашему вниманию адаптированную подборку инструментов (в том числе облачных) для разработчиков, которые позволяют создавать по-настоящему качественные проекты. Здесь представлены исключительно SaaS, PaaS и IaaS сервисы, предоставляющие бесплатные пакеты для разработчиков инфраструктурного ПО.

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

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

Немного истории. Квадрокоптер типа f450 у меня уже около 3х лет. За все это время на нем поменялись 3 комплекта двигателей, 2 комплекта регуляторов и пропеллеров: от дешевых turnigyдо t-motor. Но в итоге, после выхода комплекта E300 от DJI, я остановился именно на них. Этот набор* вместе с рамой я заказал с ebay.

Игра гениальная. Она ещё год назад взорвала кучу изданий тем, как быстро и эффективно доносит до игрока ужасы войны. Поэтому предлагаю забраться немного «под капот». Сразу говорю — игра не наша, и отношения к нам не имеет.

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

Итак, напомню: основная задача игры — погрузить человека в состояние «быть гражданским на войне и попробовать выжить», чтобы даже до самых отмороженных дошло, как это плохо. Соответственно, всё остальное строится именно вокруг этого. При этом сама по себе игра должна быть:

• Интересной.
• С простым порогом входа.
• Реалистичной для задач погружения.

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

Внимание, ниже немного спойлеров и много скриншотов (трафик).

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

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

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

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

Работая над своей игрой в Unity я подумал, зачем мне создавать множество однотипных скриптов описывающих поведение игровых объектов, но имеющих небольшие отличая друг от друга, если я мог бы создать один, а добавляя его как компонент объекту просто выбирал бы тип того самого объекта, а в редакторе (он же Inspector) видел бы только те свойства и поля, что имеют прямое отношение к выбранному типу. Так же это позволило бы в зависимости от выбора внутри скрипта использовать те или иные методы. В этом мне помогло пространство имён UnityEditor и её класс Editor.

Давным-давно я имел радость играть в замечательнейшую RTS под названием «Периметр: Геометрия Воины» от отечественного разработчика K-D Labs. Это игра о том, как огромные летающие города под названием «Фреймы» бороздят просторы «Спанджа» — цепи соединенных между собой миров. Сюжет достаточно странный и абстрактный, но гораздо более интересной и инновационной составляющей игры была одна из ее технических особенностей, а не сюжет. В отличие от большинства RTS, где сражения происходят на статической местности, в «Периметре», одной из ключевых игровых механик был терраформинг. У игрока были средства манипулировать ландшафтом с целью возведения на нем своих сооружений а также целый арсенал боевых единиц, способных этот ландшафт превратить в потрескавшийся, поплывший и изрыгающий раскаленные камни/противных насекомых ужас.

Как известно, мир RTS нынче переживает некоторый упадок. Инди-разработчики слишком заняты тем, что клепают ретро-платформеры и rouge-like игры зубодробительной сложности, и поэтому, переиграв в «Периметр» некоторое время назад я решил, что должен и сам попробовать реализовать что-то подобное — идея была интересной и с технической и с геймплейной точек зрения. Обладая некоторым практическим опытом в разработке игр (ранее я совершал попытки сделать кое-что на XNA), я подумал, что чтобы добиться хоть какого-то успеха в одиночку мне придется воспользоваться чем нибудь более высокоуровневым и простым. Выбор мой пал на Unity 3D, чья пятая версия только-только вышла из под пресса.

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

Сказ о том, как написать плагин для Unity Asset Store, поломать голову над решением известных проблем изометрии в играх, да еще и немного денег на кофе с этого поиметь, а так же понять на сколько Unity имеет расширяемый редактор. Картинки, реализации, графики и мысли под катом.

Речь пойдёт о простой структуре данных — системе непересекающихся множеств. Вкратце: даны непересекающиеся множества (например, компоненты связности графа) и по двум элементам x и y можно: 1) узнать, находятся ли x и y в одном множестве; 2) объединить множества, содержащие x и y. Сама структура очень проста в реализации и описывалась много раз в различных местах (например, есть хорошая статья на хабре и ещё кое-где). Но это один из тех удивительных алгоритмов, написать который ничего не стоит, а вот разобраться, почему он работает эффективно совсем нелегко. Я постараюсь изложить относительно простое доказательство точной оценки на время работы этой структуры данных, придуманное Зейделем и Шариром в 2005 (оно отличается от того ужаса, который многие могли видеть в других местах). Конечно, сама структура тоже будет описана, а попутно разберёмся причём здесь обратная функция Аккермана, о которой многие знают только, что она оооочень медленно растёт.

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

И всё бы ничего, да вот светодиодные не нравятся. Нет, они современны, просты, симпатичны… И ужасно скучны. А хотелось чего то тёплого, лампового ионного. Всегда имел слабость к ионным лампам…
А посему, на даче был отрыт блок на лампе ИЛТ6-30М. Но радовался я не долго — оказалось кто-то успел спалить его до меня…
И вот, думая чем заменить блок управления, случайно наткнулся на лампу ИН-33.



И всё завертелось…