Довольно много плохих вопросов, которые я вижу на StackOverflow, можно описать следующей формулой:

Вот моё решение домашнего задания. Оно не работает.
[20 строк кода]

И… всё.

Прим. пер.: это перевод статьи "How to debug small programs", на которую ссылаются в справочном разделе английского StackOverflow, посвящённом созданию минимальных, самодостаточных и воспроизводимых примеров. Мне кажется, она прекрасно описывает то, что должен знать каждый программист — основы отладки нерабочего кода.

Если вы читаете эту заметку, то, скорее всего, вы перешли по ссылке, которую либо я, либо кто-то ещё оставил под вашим вопросом на StackOverflow незадолго до того, как этот вопрос был закрыт и удалён. (Если вы читаете эту заметку по другому поводу, оставляйте свои любимые советы по отладке маленьких программ в комментариях).

Часть 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 элементов, вот такой:



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

Объем российского рынка онлайн-игр по итогам 2016 года составил 56,7 млрд руб. (по данным Mail.Ru Group), общемировой объем рынка онлайн-игр в 2016 году — $99,6 млрд (по данным Newzoo), но только 6% пользователей умеют зарабатывать на внутриигровых предметах. Игровые пространства предлагают активно покупать амуницию, камуфляж, прогресс персонажа, но легально продать кому-то свою коллекцию ты не можешь, как не можешь и вывести деньги из игры, инвестировав время, скилы и удачу.

Имея большой опыт в игровой индустрии (Suntechsoft, Esforce, Na’Vi’ и др.), мы придумали, как объединить все игры и платформы и дать геймерам возможность в один клик продавать, обменивать или оценивать виртуальные предметы. Сервис DMarket будет работать на базе блокчейн, а все операции внутри маркетплейса можно будет осуществлять с помощью встроенных токенов и умных контрактов.

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

В Apache Ignite, начиная с версии 2.1 появилась собственная реализация Persistence.

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

Всё началось с фундаментальных проблем предыдущего механизма, который позволял интегрировать In-Memory Data Grid с внешними постоянными хранилищами, например, Cassandra или Postgres.

Такой подход накладывал определенные ограничения — например, было невозможно выполнять SQL или распределенные вычисления поверх данных, которые находятся не в памяти, а в таком внешнем хранилище, был невозможен холодный запуск и низкий RTO (Recovery Time Objective) без существенных дополнительных усложнений.

Если вы используете Apache Ignite Persistence, то оставляете себе все обычные возможности Apache Ignite — ACID, распределенные транзакции, распределенный SQL99, доступ через Java/.NET API или интерфейсы JDBC/ODBC, распределенные вычисления и так далее. Но теперь то, что вы используете, может работать как поверх памяти, так и поверх диска, который расширяет память, на инсталляциях от одного узла до нескольких тысяч узлов.

Давайте посмотрим, как устроен Apache Ignite Persistence внутри. Сегодня я рассмотрю его основу — Durable Memory, а в следующей публикации — сам дисковый компонент.

SPF (Sender Policy Framework), полное название можно перевести как «Основы политики отправителя для авторизации использования домена в Email» — протокол, посредством которого домен электронной почты может указать, какие хосты Интернет авторизованы использовать этот домен в командах SMTP HELO и MAIL FROM. Публикация политики SPF не требует никакого дополнительного софта и поэтому чрезвычайно проста: достаточно добавить в зону DNS запись типа TXT, содержащую политику, пример записи есть в конце статьи. Для работы с SPF есть многочисленные мануалы и даже онлайн-конструкторы.

Первая версия стандарта SPF принята более 10 лет назад. За это время были созданы многочисленные реализации, выработаны практики применения и появилась свежая версия стандарта. Но самое удивительное, что почему-то именно SPF, более чем любой другой стандарт, оброс за 10 лет невероятным количеством мифов и заблуждений, которые кочуют из статьи в статью и с завидной регулярностью выскакивают в обсуждениях и ответах на вопросы на форумах. А протокол, казалось бы, такой простой: внедрение занимает всего пару минут. Давайте попробуем вспомнить и разобрать наиболее частые заблуждения.

TL;DR — рекомендации в конце.

Когда я пишу статьи об обучении в видеоиграх, вокруг них всегда начинаются яростные обсуждения. Люди неизбежно начинают перечисляют все неудачные фрагменты обучения, неуклюжие техники и провалившиеся эксперименты как примеры того, что «обучение — это плохо, лучше бы его вообще не было!».

Если поискать на сайте tvtropes.org (это база данных клише поп-культуры) слово «tutorial», то найдётся больше десяти разных тропов, связанных с тем, что люди ненавидят в процессе обучения видеоигр. Для сравнения: я нашёл всего два обсуждения того, как сильно пользователи ненавидят скачиваемый контент.

Самое печальное в этом то, что когда я пишу об обучении, я имею в виду не такое обучение.

Из-за этого заблуждения я не могу сообщить об обучении то, что хочу.

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

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

35 килобайт минифицированного кода на обычном JavaScript, семь городов, пустоши, радиоактивные гекконы, съедобные кактусы, встречные караваны и бандиты. Что это? Это небольшая игра, которая запускается в браузере. Ее принципы довольно просты для повторения и в самой примитивной версии ее можно воссоздать, наверное, на любом устройстве, если там есть устройство вывода и генератор случайных чисел. Но сегодня я хочу рассказать, как я реализовал ее для современных браузеров.

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

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

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

Что такое инкрементная игра?

Игрок нажимает на кнопку, число увеличивается. Нажимает снова, число снова увеличивается. Игрок продолжает нажимать, и постепенно разблокирует функцию, увеличивающую число за игрока. Числа растут, даже когда вы не играете. И этот процесс повторяется вечно.

В сущности, такова общая структура «инкрементной» игры. Она кажется простой, даже примитивной, но в игровом процессе есть неожиданная глубина и привлекательность. Стили игры могут быть разными — от коммерчески успешных и казуальных Clicker Heroes и AdVenture Capitalist до более экспериментальных или хардкорных примеров, таких как Candy Box, Cookie Clicker и Sandcastle Builder.


Cookie Clicker, самое начало.

Что же самое важное в инкрементной игре? Хотя в этом жанре есть множество вариаций и экспериментов, фундаментальными аспектами дизайна являются:

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

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

Для вычисления урона от атаки в таких настольных ролевых играх, как Dungeons & Dragons, используются броски урона. Это логично для игры, чей процесс основан на бросках кубиков. Во многих компьютерных RPG урон и другие атрибуты (сила, очки магии, ловкость и т.д.) вычисляются по похожей системе.

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

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

Приветствую всех! Прошло почти полгода с момента публикации первой части (а также релиза в Google Play), в которой я описал историю возникновения идеи Neo Angle и ее реинкарнацию из портальной флэшки в мобильную игру на Unity. За это время многое изменилось, вследствие чего хотел бы рассказать о следующих моментах:

• Результаты релиза в Google Play (статистика, цифры)
• Поиск паблишера и работа с ним
• Устранение ошибок
• Presskit (будет много графики)
• Релиз в Appstore

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

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

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

Партнеры и друзья Appodeal, Corona Labs совместно с Defold и DevGAMM Минск, объявляют о старте геймджема #CoronaDefoldJam на базе Lua. Джем пройдет с 28 июля по 30 сентября 2017 на платформе itch.io. Требование к участникам только одно — игры в рамках джема должны быть созданы на Corona или Defold. Если вы никогда не использовали эти движки, не страшно: обе платформы просты для изучения и обладают очень дружелюбными сообществами, которые всегда помогут разобраться. В общем, #CoronaDefoldJam — идеальный повод освоить новые инструменты для создания игр; тем более, что джем поддерживает легендарный Джон Ромеро.

Намного лучше дисциплинарные ограничения убирать инструментарным расширением
Автор статьи

Введение

При разработке информационной системы, то есть программы, нацеленной на хранение, работу с данными, обработку, анализ и визуализацию какой-то базы данных, одним из краеугольных камней стоит задача разработки БД. Когда я только начинал задаваться этим вопросом, казалось – что ни сделай, все равно будет криво.

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

Для многих из нас зеленый свет для собственной игры в Steam GreenLight является целью, к которой люди готовы идти месяцами, а то и годами. Настает тот день, когда игра готова и пришло время выложить её на всеобщее обозрение. С чего же начать и как не ошибиться? Об этом и пойдёт речь в данной статье



P.S. Через все описанное ниже автор прошел лично, с целью набить как можно больше шишек.

Flutter — новый инструмент от Google, позволяющий разработчикам писать кроссплатформенные приложения, которые можно запускать на различных системах (например, на Android или iOS) с общей кодовой базой.

Сам инструмент написан на C и C++. Предоставляет движок для 2D рендеринга, React-подобный FRP фреймворк и набор виджетов в стиле Material Design. На данный момент распространяется версия alpha:0.0.20, но несмотря на довольно "сырую" версию, уже можно создавать продвинутый интерфейс, работать с сетью и даже с файловой системой.

Задержка в сети (лаг) — это реальность, которую нужно учитывать в многопользовательских играх. Сообщениям, передаваемым через Интернет, требуется время, чтобы достичь точки назначения. В зависимости от маршрута и его длины передача этих сообщений может занять довольно долгое время. Это может негативно влиять на процесс игры, особенно в динамичных клиент-серверных играх, таких как FPS. То, что кажется очень простой задачей (стреляй, пытаясь попасть в цель), внезапно становится очень сложным в создании плавного игрового процесса для всех игроков. Думаю, не нужно говорить, что создавать многопользовательские игры сложно, при этом возникает множество проблем, которые разработчики должны решить. В этой статье я расскажу, как система вооружения MechWarrior Online справляется с лагом.

    Добрый день, Хабр. В эфире снова я, Илья Кудинов, QA-инженер компании Badoo. В свободное от основной работы время я занимаюсь разработкой игрушек на Unity 3D и решил в качестве эксперимента написать статью об одной из проблем, с которой столкнулась наша команда. Я являюсь основным разработчиком, и наш гейм-дизайнер в «гробу видал» копание в моем коде с какой бы то ни было целью (разделение труда — одно из величайших достижений цивилизации), значит, моя обязанность — предоставить ему все необходимые рычаги управления и настройки геймплея в виде удобных визуальных интерфейсов. Благо Unity сам по себе имеет достаточно удобные (кхе-кхе) готовые интерфейсы и ряд методов их расширения. И сегодня я расскажу вам о некоторых приемах, которые делают жизнь нашего гейм-дизайнера проще и удобнее, а мне позволяют не биться головой о клавиатуру после каждого его запроса. Надеюсь, они смогут помочь каким-нибудь начинающим командам или тем, кто просто упустил эти моменты при изучении Unity.

    Сразу скажу, что наша команда все еще активно учится и развивается, хоть мы уже и выпустили дебютную игру. И если «дедлайны не горят», то я предпочитаю разбираться в каких-то вещах сам, а не обращаться к экспертам и различным best practices. Поэтому что-то из рассказанного мною может оказаться не оптимальным или банальным. Буду очень рад, если в таких случаях вы подскажете мне более удобные решения в комментариях и личных сообщениях. Ну и в целом информация здесь скорее базового уровня.

Эта статья не для тех, кто уже пишет на go.
Она для программистов на других языках, которым инетересно, стоит ли тратить время на go.
Чем отличается go, например, от java и чем может быть полезен.

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

Под катом описан полный процесс от создания проекта до его развертывания.