Если и есть что-то неизменное с того дня, когда я начал писать код и по сегодняшний день (а я пишу уже дней 500). Так это то, что незнание с чего начать — невероятно пугает. Я остро помню панику изучения HTML, когда я понятия не имел, как заставить мои div-ы располагаться там, где я хотел. Я понимал концепцию сетки, но реализация никак мне не давалась в течение нескольких дней.

Облегчение, в конце концов, наступило, после величайшего прозрения моей кодерской жизни: Бог мой, так рабочий код везде! В интернете он повсюду. Просто найди, скопируй, посмотри, как он работает — и ты в шоколаде. Я стал использовать Google, «просмотреть исходный код страницы» и «исследовать элемент», ночами изучая структуру и логику работающего чужого кода. И на определенное время этого было достаточно. Мне требовалось изучить настолько элементарные вещи, что просто видеть, как другие люди кодируют, а потом немножко изменять этот код под свои нужны — это все что мне требовалось. Однако, когда мои навыки повысились, я обнаружил, что мне не хватает умения писать код с нуля так элегантно, как бы я этого хотел. И я стал делать по другому: вместо того, чтобы копировать чужой код, я стал набирать его полностью сам.

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

Для моей постапокалиптической игры Frameshift мне нужно было заполнить очень большой открытый мир разнообразными городами. В нашей команде всего 3 человека, поэтому я, разумеется, воспользовался процедурной мощью Houdini!

Раньше, когда не знал о Houdini, я писал на C# собственные инструменты процедурной генерации мешей для Unity. Добавление новых функций было очень долгим процессом, и когда я однажды услышал, что Houdini предназначен для подобных задач, то сразу перешёл на него. Я поэкспериментировал с разными способами генерации городов и улиц, и в этой статье я вкратце расскажу о методике, которая в конечном итоге была использовала для игры.

Сначала я создал инструмент для генерации сети улиц, которые можно было бы использовать в городе. Моё решение основано на изложенных здесь концепциях, а также на использованной по ссылке статье. Там много говорится о тензорных полях и собственных векторах, и всё написано очень технически, но вкратце это можно объяснить так: для моего случая (генерации дорожной сети на рельефе) мне нужно было сгенерировать контурные линии рельефа, а также линии, перпендикулярные им.

Существует множество отличных статей и туториалов о производительности в Unity. Этой статьёй мы не пытаемся заменить или улучшить их, это всего лишь краткое изложение шагов, сделанных нами после прочтения этих статей, а также шагов, позволивших решить наши проблемы. Настоятельно рекомендую вам как минимум изучить материалы на https://learn.unity.com/.

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

• Неоптимизированные шейдеры
• Неоптимизированные скрипты на C#

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

Поиск слабых мест

Цель этой статьи — не написать туториал по использованию профилировщика; я хотел просто рассказать о том, что нас в основном интересовало в процессе профилирования.

Unity Profiler — всегда самый лучший способ поиска причин задержек в скриптах. Настоятельно рекомендую профилировать игру непосредственно в устройстве, а не в редакторе. Поскольку наша игра создавалась для iOS, мне нужно было подключить устройство и использовать показанные на изображении Build Settings, после чего профилировщик подключался автоматически.


Build Settings (параметры сборки) для профилирования

Если вы попробуете загуглить «Random lag in Unity» или другой похожий запрос, то обнаружите, что большинство людей рекомендует сосредоточиться на сборке мусора, поэтому именно так я и поступил. Мусор генерируется каждый раз, когда вы прекращаете использовать какой-то объект (экземпляр класса), после чего время от времени запускается сборщик мусора Unity для уборки беспорядка и освобождения памяти, что требует безумного количества времени и приводит к падению частоты кадров.

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

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



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

Основная часть

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

Никого не волнует, что ты работаешь

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

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

Для всех, кто хотел разобраться с Lua (скриптовый язык для разработки игр и не только, список), но никак не находил времени, Tyler Neylon приготовил небольшой подарок:

http://tylerneylon.com/a/learn-lua/

Посвящается всем, кто предпочитает один большой список из говорящих самих за себя сниппетов кода (с небольшими комментариями к 95% case'ов) длинным мануалам с огромной иерархией. Очень удобно для тех, кто уже умеет программировать и просто хотел бы разобраться с новым для себя языком. Весь «мега-сниппет» на английском, но примеры несложно читаются.

P.S. А для всего остального есть Hyperpolyglot.

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

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

Компаниям, как правило, нужны программисты двух типов. Одни — «рабочие руки», т.е. те, кто умеет хорошо выполнять порученное им задание, и вторые — «рабочие мозги», т.е. те, кто может генерировать новые идеи, предлагать новые подходы, разрабатывать новые направления.
Что касается первой категории, то для того, чтобы в ней работать действительно может хватить пары курсов института и книжек перед сном. Со второй категорией все сложнее… Дело в том, что специалисты этого уровня должны иметь знания шире, чем это требуется для их непосредственной работы.
Вот о том, как готовить специалистов второй категории и хочется поговорить сегодня. И начать с азов — с бакалавриата.

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

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

О поступлении

В далеком 2010 году поступила я в ВУЗ. Моих несчастных 166 баллов (по 3 предметам) хватило только на МГУПИ. Такое количество баллов из-за того, что в ВУЗ пошла после 2-х курсов колледжа и вечерней школы, и так вышло, что на подготовку к ЕГЭ по всем 3 предметам у меня было что-то около 2 недель в перемешку с сессией колледжа.

Мама хотела, чтобы я училась в МГТУ СТАНКИН, и поэтому туда сразу отдали оригинал аттестата. Но моих баллов в первую волну на бюджет не хватало. Было несколько попыток забрать аттестат, но приемка морозилась, убеждая подождать 2-й волны. В итоге, почти с боем, аттестат отдали.

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

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


На картинке изображён логотип российского ромхакинг-сообщества по версии проекта Russian Romhacking.

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

1 Введение

Настоящий документ содержит рекомендации по написанию программ на языке C++.

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

Но для появления ещё одного списка рекомендаций, помимо указанных источников, есть несколько причин. Основная причина — их излишняя обобщённость, поскольку зачастую требуется задать частные правила (в особенности правила именования). Данный документ содержит комментарии, что делает его более удобным в использовании при проведении ревизий кода, чем другие уже существующие документы. К тому же, рекомендации по программированию обычно вперемешку содержат описания проблем стиля и технических проблем, что не совсем удобно. Этот документ не содержит каких-либо технических рекомендаций по C++, делая упор на вопросах стиля.

Цель данной статьи:

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

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

Часто ли вы задумываетесь – почему что-то сделано так или иначе? Почему у вас микросервисы или монолит, двухзвенка или трехзвенка? Зачем вам многослойная архитектура и сколько у вас вообще слоев? Что такое бизнес-логика, логика приложения, презентационная логика и почему все так разделено? Посмотрите на свое приложение – как оно вообще спроектировано? Что в нем и где находится, почему это сделано именно так?
Потому что так написано в книжках или так говорят авторитетные личности? Какие ВАШИ проблемы решает тот или иной подход/паттерн?
Даже то, что на первый взгляд кажется очевидным, порой бывает очень сложно объяснить. А иногда, в попытке объяснения, приходит понимание того, что очевидные мысли были и вовсе ошибочны.
Давайте попробуем взять какой-нибудь пример и изучить на нем эти вопросы со всех сторон.

Источники вдохновения

Этот пост возник благодаря недавней публикации Араса Пранцкевичуса о докладе, предназначенном для программистов-джуниоров. В нём рассказывается о том, как адаптироваться к новым ECS-архитектурам. Арас следует привычной схеме (объяснения ниже): показывает примеры ужасного ООП-кода, а затем демонстрирует, что отличным альтернативным решением является реляционная модель (но называет её «ECS», а не реляционной). Я ни в коем случае не критикую Араса — я большой фанат его работ и хвалю его за отличную презентацию! Я выбрал именно его презентацию вместо сотен других постов про ECS из Интернета потому, что он приложил дополнительные усилия и опубликовал git-репозиторий для изучения параллельно с презентацией. В нём содержится небольшая простая «игра», используемая в качестве примера выбора разных архитектурных решений. Этот небольшой проект позволил мне на конкретном материале продемонстрировать свои замечания, так что спасибо, Арас!

Слайды Араса выложены здесь: http://aras-p.info/texts/files/2018Academy — ECS-DoD.pdf, а код находится на github: https://github.com/aras-p/dod-playground.

Я не буду (пока?) анализировать получившуюся ECS-архитектуру из этого доклада, но сосредоточусь на коде «плохого ООП» (похожего на уловку «чучело») из его начала. Я покажу, как бы он выглядел на самом деле, если бы правильно исправили все нарушения принципов OOD (object-oriented design, объектно-ориентированного проектирования).

Спойлер: устранение всех нарушений OOD приводит к улучшениям производительности, аналогичным преобразованиям Араса в ECS, к тому же использует меньше ОЗУ и требует меньше строк кода, чем ECS-версия!

TL;DR: Прежде чем прийти к выводу, что ООП отстой, а ECS рулит, сделайте паузу и изучите OOD (чтобы знать, как правильно использовать ООП), а также разберитесь в реляционной модели (чтобы знать, как правильно применять ECS).

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

Сегодня в программе:

• auto
• nullptr
• range-based циклы
• override и final
• строго-типизированный enum
• интеллектуальные указатели
• лямбды
• non-member begin() и end()
• static_assert и классы свойств
• семантика перемещения