В первой части я рассуждал для чего прототипирование и в целом с чего начать
— Часть 1

В второй части немножко пробежались по ключевым классам
и архитектуре — Часть 2

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

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

Итак видосик, смотреть надо на тексты расставленные по уровню, а не на геймплей ):

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

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

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

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

Об авторе. Энди Томасон — ведущий программист Genomics PLC. Он с 70-х годов занимается графическими системами, играми и компиляторами; специализация — производительность кода.

Гены: краткое введение

Геном человека состоит из двух копий примерно по 3 миллиарда пар оснований ДНК, для кодирования которых используются буквы A, C, G и T. Это около двух бит на каждую пару оснований:

3 000 000 000 × 2 × 2 / 8 = 1 500 000 000 или около 1,5 ГБ данных.

На самом деле эти копии очень похожи, и ДНК всех людей практически одинаков: от торговцев с Уолл-Стрит до австралийских аборигенов.

Существует ряд «референсных геномов», таких как файлы Ensembl Fasta. Эталонные геномы помогают построить карту с конкретными характеристикам, которые присутствуют в ДНК человека, но не уникальны для конкретных людей.

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

— Эдсгер Вибе Дейкстра

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

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

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

Введение

История началась с хакатона по разработке игр на блокчейне. На старте мероприятия я встретил человека, который в качестве хобби создает настольные деловые игры (я был на плейтесте одной такой игры), мы объединились, вместе нашли команду, с которой за выходные “слепили” простую стратегическую игру. Хакатон прошел, а задор остался. И у нас родилась идея многопользовательской карточной игры о счастье, мировом сообществе и выборах.

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

• Краткая информация об игре
• Как принималось решение на чем делать backend. Где это будет “жить” так, чтобы за это не платить на этапе разработки
• Первые шаги в разработке — аутентификация игроков и организация поиска игры (matchmaking)
• Дальнейшие планы

На часах 7:15 утра. Наша техподдержка завалена работой. О нас только что рассказали в передаче «Good Morning America» и множество тех, кто впервые посещает наш сайт, столкнулось с ошибками.

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

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



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

Скорее всего, из названия статьи вы уже догадались, что в центре внимания ошибки в исходном коде. Но это вовсе не единственное, о чем пойдет речь в этой статье. Если кроме С++ и ошибок в чужом коде вас привлекают необычные игры и вам интересно узнать, что это такие за «рогалики» и с чем их едят, добро пожаловать под кат!

<< До этого: Электронная революция

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

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

Дано: 12 монет, одна из них фальшивая, отличается только весом. Неизвестно легче или тяжелее. Даны рычажные весы, которые показывают, что груз с одной из сторон тяжелее. За 3 взвешивания необходимо найти фальшивую монетку.

Из опыта советую не спешить, решать письменно. Головоломка «12 монет, 3 взвешивания» несколько раз возникала в моей жизни. Первый раз ее задал мне мой товарищ-олимпиадник, решил я ее после олимпиады и пришлось пару часиков поломать голову. И через несколько лет она далось мне не сразу. Если желаете решить самим — делайте на листочке.

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

Буквально на днях компания FireEye презентовала систему Commando VM, предназначенную для пентестеров и Red Team, работающую под управлением операционных систем семейства Microsoft Windows.

FireEye позиционирует Commando VM как «первый в своем роде» дистрибутив для пентестеров под Windows, однако они явно лукавят, т.к. на ум сразу приходит как минимум проект Pentest Box, который также заточен под Windows.

В тоже время, сама система Commando VM довольно интересна и заслуживает внимания…

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

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

Материал, перевод которого мы публикуем сегодня, предназначен для тех, кто хочет освоить командную строку Linux. Умение эффективно пользоваться этим инструментом позволяет экономить немало времени. В частности, речь здесь пойдёт о командной оболочке Bash и о 21 полезной команде. Также мы поговорим о том, как пользоваться флагами команд и псевдонимами Bash, которые позволяют ускорить ввод длинных инструкций.



→ Также читайте в нашем блоге цикл публикаций про bash-скрипты

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

На проводимой в этом году Game Developers Conference выступили два разработчика игр, способные написать новую главу романа-антиутопии о будущем: они рассказали историю о том, как заработали деньги, позволив делать всю работу роботам. В их случае этой работой была процедурная генерация игр для смартфонов.

Участие в обычном гейм-джеме привело к созданию машины обработки данных, которой в результате удалось заработать приличную сумму: 50 тысяч долларов за два с лишним года. Спустя годы, имея на руках данные (и деньги), разработчики этой машины по изготовлению игр, которая создавала только «мусорные» слот-автоматы с моделью free-to-play, использовали GDC как трибуну, чтобы подать тревожный сигнал индустрии, в которой «правильное» поведение часто ограничивается вниманием к игрокам, заискиванием перед издателями и сбором положительных обзоров критиков. В случае этих разработчиков нарушение всех этих правил привёл к слишком успешным результатам, вызвав у них сильный дискомфорт.

Побеждаем в «гонке ко дну»

Вернёмся в 2013 год: в то время два разработчика видеоигр уже несколько лет пытались добиться успеха на растущем рынке мобильных игр. Один из них, Алекс Шварц, помогал в создании качественной мобильной игры Jack Lumber. (В прошлой жизни я даже написал о ней хороший отзыв в уже несуществующем журнале The Daily, работавшем только на планшетах.) Второй, Зиба Скотт, разработал приятную мобильную головоломку Girls Like Robots.

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

Несколько лет назад довелось мне попробовать свои силы в заманивании пытливых отроков в разработку микроэлектроники. А дальше было, как в известной пословице: «Коготок увяз — птичке пропасть!» Остановиться уже не смог. Хочу поделиться с общественностью этим опытом, возможно, другие инженеры-электронщики тоже захотят устроить что-то подобное. Грамотнее народ – лучше жизнь.

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

При первом знакомстве Termux, а я далеко не линуксоид, вызвал в моей голове две мысли: «Круть несусветная!» и «Как им пользоваться?». Порывшись в инетах, я не нашел ни одной статьи в полной мере позволяющей начать пользоваться Termux'ом так чтобы это приносило больше удовольствия чем гемора. Будем это исправлять.

• First of all, you can read this article in russian here.

One evening, I was reading Mastering regular expressions by Jeffrey Friedl , I realized that even if you have all the documentation and a lot of experience, there could be a lot of tricks developed by different people and imprisoned for themselves. All people are different. And techniques that are obvious for certain people may not be obvious to others and look like some kind of weird magic to third person. By the way, I already described several such moments here (in russian) .

For the administrator or the user the command line is not only a tool that can do everything, but also a highly customized tool that could be develops forever. Recently there was a translated article about some useful tricks in CLI. But I feel that the translator do not have enough experience with CLI and didn't follow the tricks described, so many important things could be missed or misunderstood.

Under the cut — a dozen tricks in Linux shell from my personal experience.

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

Эта статья — своеобразное сопровождение к видео. В ней я даю комментарии ко всем показанным решениям плюс собственную версию решения на JavaScript. Также обсуждаются нюансы каждого алгоритма.

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

Часть I
Часть II

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

---

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

Рассмотрим метод оценок при решении неравенств.
Дать оценку сверху означает определить максимальное значение, которое может принимать искомая величина.

Предположим, что цена за одну единицу товара может колебаться в пределах от 5 до 10 RUB. Для двух единиц товара оценка сверху составляет 10+10=20 RUB, оценка снизу 5+5=10 RUB.

Рассмотрим задачу из задачника профильной направленности М.И. Башмакова
37. Известны оценки для переменных $$ и $$

Дайте оценки сверху для следующих выражений:
1. $$
2. $$

5. $$
6. $$

8. $$
9. $$

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

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

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