Рубрика «архитектура» - 10

Тайлер Анлауф подготовил подробный анализ модульного окружения ROME: Church of Sant’Ivo созданного им в UE4 и 3ds Max. В статье он рассказывает о предварительном черновом плане (blockout), модульной сборке, освещении, постобработке и многом другом.

Сложное модульное архитектурное окружение в UE4 - 1

ROME: Church of Sant’Ivo

В данном анализе я поделюсь с вами своим процессом работы над ROME: Church of Sant’Ivo, хитростями, которым научился, трудностями, с которыми столкнулся во время работы, а также планами под дальнейшему усовершенствованию сцены, потому что она пока ещё не завершена.

Сложное модульное архитектурное окружение в UE4 - 2

Цели проекта

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

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

Композиция против наследования, паттерн Команда и разработка игр в целом - 1

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

— Слушай, я тут придумал отличную идею игры! — гейм-дизайнер Вася был взъерошен, а глаза — красные. Я ещё попивал кофе и холиварил на Хабре, чтобы убить время перед стенд-апом. Он выжидательно посмотрел на меня, пока я закончу писать в комментариях человеку, в чем он не прав. Он знал, что пока справедливость не восторжествует, а правда не будет защищена — смысла продолжать со мной разговор нету. Я дописал последнее предложение и перевел на него взгляд.

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

Он убежал по своим гейм-дизайнерским делам, а я открыл IDE.

Читать полностью »

Как у нас не получилось переделать архитектуру компании - 1

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

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

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

Но давайте начну с методологии. Читать полностью »

Так случилось, что ваша программа написана на скриптовом языке — например, на Ruby — и встала необходимость переписать ее на Golang.

Резонный вопрос: зачем вообще может понадобится переписывать программу, которая уже написана и нормально работает?

Как победить дракона: переписываем вашу программу на Golang - 1Читать полностью »

Всегда ли нужны Docker, микросервисы и реактивное программирование? - 1

Автор: Денис Цыплаков, Solution Architect, DataArt

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

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

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

Ускользает понимание своего или чужого кода?

Не можете вникнуть в алгоритм?

Проводите кучу время в отладке, но найти место неверной инициализации не получается, а хочется получать удовольствие от кодирования?

Вспомните о приведенных ниже правилах и примените их!

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

Рассмотрим процесс восприятия данных, чтобы соотнести описанные правила с процессом восприятия и определить критерии простого кода.

Упрощенный процесс восприятия состоит из следующих этапов:

  1. Поступающая через рецепторы данные соотносятся с предыдущим опытом.
  2. Если соотнесения нет – это шум. Шум быстро забывается. Если есть с чем соотнести, происходит опознавание фактов.
  3. Если факт важен — запоминаем, либо обобщаем, либо действуем, например говорим или набираем код.
  4. Для сокращения объема запоминаемой и анализируемой информации используется обобщение.
  5. После обобщения, информация вновь соотносится и анализируется (этап 1).

Читать полностью »

Архитектурные решения для мобильной игры. Часть 2: Command и их очереди - 1

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

Архитектурные решения для мобильной игры. Часть 1: Model
Внимание, в первой части статьи мной был допущен ляп в форматировании, из-за которого в некоторых браузерах пол статьи не показывалось. Если вы читали предыдущую статью, и вам показалось, что она как-то странно обрывалась — сходите по ссылке и дочитайте вторую половину.
Читать полностью »

Эпиграф:
— Как я тебе оценю, если неизвестно что делать?
— Ну там будут экранчики и кнопочки.
— Дима, ты сейчас всю мою жизнь описал в трёх словах!
(с) Реальный диалог на митинге в игровой компании

Архитектурные решения для мобильной игры. Часть 1: Model - 1

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

В нашей суровой реальности каждый, кто хоть раз архитектурил крупный проект хотя бы в своих мыслях, имеет свои представления о том, как надо делать, и часто готов отстаивать свои идеи до последней капли крови. У окружающих это вызывает улыбку, а менеджмент часто смотрит на всё на это как на огромный чёрный ящик, который никому углом не упёрся. Но что если я скажу вам, что правильные решения помогут сократить создание нового функционала в 2-3 раза, поиск ошибок в старом в 5-10 раз, и позволят делать многие новые и важные вещи, которые раньше были вообще недоступны? Достаточно лишь впустить архитектуру в сердце своё!
Читать полностью »

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

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

Как поделить архитектуру и реализацию и не поругаться - 1

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

Читать полностью »

Как правило статьи, рассказывающие о проектировании типами, содержат примеры на функциональных языках — Haskell, F# и других. Может показаться, что эта концепция неприменима к объектно-ориентированным языкам, но это не так.

В этой статье я переведу примеры из статьи Скотта Власчина Проектирование типами: Как сделать некорректные состояния невыразимыми на идеоматичесий C#. Также я постараюсь показать, что этот подход применим не только в качестве эксперимента, но и в рабочем коде.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js