За время существования индустрии разработки игр формул разных механик, способных развлечь нас, придумали не одну сотню. Что-то умерло засветившись в паре игр, что-то ушло со временем, какие-то существуют до сих пор. Есть и такие, которые не просто выжили, но стали мейнстримом, хотя только портят нервы игрокам. Игровой дизайн большинства старых игр, от второго фолыча до первого FarCry и пятью активными перками, пусть и не был вершиной искусства - затягивал не хуже современных песочниц с миллионом активностей. Редкую игру захочется пройти второй раз, а как вспомню, что на прохождение можно потратить под сотню и больше часов - думаю, а оно мне действительно было надо? Можно же было заняться чем-то более интересным. Я знаю, чем закончился второй фолыч, знаю это уже четвертый раз, но каждый раз игра удивляет меня чем-то новым. А вот нового "Аватара" бросил на половине, слишком много всего и все недоделанное, и прозрачные стены... просто бич игры. И тут вопрос, чего-то не хватает в этой раздутой, перекачанной сотней механик игре? Только задумайтесь - в аватаре больше сотни основных механик, которые влияют на окружение. Может в играх что-то потерялось? Хотя "потерялось" - звучит странно - за столько лет индустрия только создала просто море всего нового. Статья ориентирована на "побурчать", так что не ждите каких-то великих секретов и тонкостей мастерства.

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

Привет, Хабр! В 2020 году компания решила вывести на рынок линейку продуктов Platform V. Для них нужна была документация, которая на тот момент велась в Confluence. Нам предстояло проделать сложную и дорогую работу: собрать документы на нужные версии, привести тексты к единому стилю и терминологии, оформить как комплект документации от поставщика ПО. Расскажу, какие инструменты мы в СберТехе использовали, почему перешли от документирования в Confluence нa Docs-as-a-Code и создали инструмент Platform V GetDocs, который помогает эффективно писать документацию.

Зачем еще один калькулятор? Да незачем, просто как тестовый проект для рассмотрения GUI-библиотеки.

Изначально я хотел попробовать такие крейты, как GPUI, Floem и Xilem, но первая, кажется, пока работает только под MacOS и Linux, вторая не позволяет установить иконку окну и кушает оперативы побольше Webview в Tauri, а до третьей я так и не добрался, узнав об Slint.

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

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

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

Эта статья строится на двух простых идеях:

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

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

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

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

Вы, наверняка, помните отличный цикл статей на Хабре в прошлом году от пользователя MiraclePtr, который рассказывал о разных методах блокировок, о разных методах обхода блокировок, о разных клиентах и серверах для обходов блокировок, и о разных способах их настройки (раз, два, три, четыре, пять, шесть, семь, восемь, десять, десять, и вроде были еще другие), и можете спросить, а зачем еще одна? Есть две основные причины для этого.

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

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

Поэтому сегодня мы поговорим об установке и использовании графической панели 3X-UI для сервера X-Ray с поддержкой всего того, что умеет X-Ray: Shadowsocks-2022, VLESS с XTLS и т.д.

Написать этот материал меня побудило... отсутствие хороших статей по корутинам в C++ в русскоязычном интернете, как бы странно это не звучало. Ну серьезно, C++20 существует уже несколько лет как, но до сих пор почти все статьи про корутины, что встречаются в рунете, относятся к одному из двух типов. Или обзор начинается с самых глубин и мелочей, пересказывая cppreference, а потом автор выдыхается и все сводится к "ну а дальше все понятно, возьмите и примените это в своем коде", что напоминает известную картинку с совой. Либо иногда в статьях рассматривается применение корутин на примере генераторов, и этим все и ограничивается. Но, давайте будем честны, генераторы — это замечательно, но за все время моей многолетней карьеры разработчика я, вероятно, делал что‑то подобное генераторам разве что разок, в то время как асинхронный ввод‑вывод приходится использовать почти в каждом проекте. И поэтому меня гораздо больше интересует реализация асинхронного ввода‑вывода с использованием корутин, а не генераторы. Поэтому пришлось разбираться во всем самому.

Всем привет! Для того, чтобы усилить безопасность серверов Linux привожу ниже советы, основой которых является публикация 40 Linux Server Hardening Security Tips [2023 edition] Вивека Гите. В приведенных инструкциях предполагается использование дистрибутив Linux на базе Ubuntu/Debian. Часть материала от автора я опускаю, так как публикация ориентированна на безопасность хостов Linux в инфраструктуре.

!!! Приведенные ниже рекомендации необходимо тестировать на совместимость с используемыми сервисами. Веред внедрением рекомендую провести тестирование на каждом отдельном типе сервера/приложения. !!!

Продолжаем серию «C++, копаем вглубь». Цель этой серии — рассказать максимально подробно о разных особенностях языка, возможно довольно специальных. Это седьмая статья из серии, список предыдущих статей приведен в конце в разделе 10. Серия ориентирована на программистов, имеющих определенный опыт работы на C++. Данная статья посвящена концепции константности в C++.

Переменные являются основой любого языка программирования. Если значение переменной нельзя изменить после инициализации, то такие переменные называются неизменяемыми (immutable) переменными или константными переменными или просто константами. Константные переменные в том или ином виде поддерживаются во всех языках программирования и играют в них важную роль. Такие переменные помогают компилятору оптимизировать код, улучшают читаемость и надежность кода, позволяют выявлять бОльшее количество ошибок на стадии компиляции. Константы помогают решать проблемы, связанные с многопоточным доступом к переменным. Использование константных переменных влияет на проектные решения в объектно-ориентированном программировании, а функциональное программирование изначально исходит из неизменяемости используемых переменных.

В C++ концепции константности уделяется значительное место. Для переменных используется два вида константности, имеются ссылки и указатели на константу, константные функции-члены, константные итераторы. Попробуем разобраться во всех этих понятиях.

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

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

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

Объём специфичных знаний, которые требуются рядовому программисту игр, даже если он только начал свою карьеру, вызывает у меня «лёгкую» тоску. Это одна из причин, почему большая часть людей, которые «горят делать игры», отсеивается на этапе технических собеседований (обычно их больше одного). Это нормально и грустно. Добавьте сюда, что нефундаментальные знания, вроде инструментов, библиотек и движков, приходится обновлять где‑то раз в 5–7 лет. Не вижу тут, что игрострой сильно отличается от других областей разработки. Если бы лет 15 назад «добрый я» скинул на почту список книг, которые придется прочитать и осмыслить, армия собранных граблей не была бы столь большой и разнообразной, и без ручек половинной длины. Осторожно, в конце статьи будет супердлинная картинка (взята с github отсюда, с разрешения автора).

Недавно на Хабре была опубликована статья Разбираем самый маленький PNG в мире. Интересно, а какой самый маленький файл JPEG? В ответах на StackOverflow и Reddit можно встретить размеры 107, 119, 125, 134, 141, 160 байтов. Все они представляют серый прямоугольник 1 на 1. И кто прав? Все правы, просто такая разница объясняется различными режимами кодирования и степенью строгости соответствия стандарту. Описание всех нюансов разрослось до целой статьи cо всеми необходимыми подробностями для более-менее хорошего знакомства с самыми маленькими jpeg-ами. После краткой теории разберем 159-байтный файл на КДПВ, а затем рассмотрим способы его уменьшения.

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

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

На Хабре было опубликовано уже достаточно статей, посвященных «spaceship operator» operator<=> ([1], [2], [3], [4]) И этой статьи бы не было, если бы все они были идеальны и описывали его во всей полноте. Но ни одна из них в деталях не рассказывает: а какой тип, собственно, должен возвращать наш operator<=>, если мы реализуем его своими руками: std::strong_ordering, std::weak_ordering или std::partial_ordering? И какая вообще между ними разница?