Антон Зальцман | Соль шикарного кода

2023-02-14 16:57:42 Как выкладываться на Яндекс Игры?

Я с ребятами подготовил для вас пару документов, которые помогут вам быстро разобраться, как работать с площадкой.
Начало работы с Web разработкой
Начало работы с Yandex Games SDK

Это инсайды прямиком из нашей базы знаний AGAVA.

Заниматься своими проектами и зарабатывать на этом - прекрасно. Я монетизировал свои наработки еще 14 лет назад и даже вышел на какой-никакой пассивный доход.

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

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

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

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

Благо всё можно тщательно протестировать с помощью черновика.

Напишите в комментариях о своем опыте работы с Веб-площадками, интересно узнать ваше мнение. Открыть/Комментировать

2023-02-11 20:56:39 3 главных ошибки тех, кто пишет библиотеки для Unity

⁃ Забить на Package Manager.
⁃ Забить на Тесты.
⁃ Забить на Теги для контроля версий.

Обозначить ошибки неинтересно, а вот как их избежать? Обычно я рекомендую:

1. Использовать Package Manager. Профессионалы всегда предпочтут просто жмакнуть на плюсик в Package Manager и вбить ссылку для установки.

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

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

3. Использовать теги. Допустим, на проект пришёл Вова и качает репозиторий. Вова говорит, что у него ничего не работает, а у остальной команды всё норм. Что произошло? Правильно - вы выкатили обновление с ломающими изменениями. У Вовы скачалась обновлённая версия, а у остальной команды старая. Вам строчат гневные письма в Issues, чтобы вы наконец начали использовать теги.

Собрал несколько примеров хороших библиотек:
https://github.com/forcepusher/com.bananaparty.websocketclient
https://github.com/forcepusher/com.agava.yandexgames
https://github.com/forcepusher/com.agava.webutility
https://github.com/forcepusher/com.agava.yandexmetrica

Но там в основном процедурка, а не ООП, потому что это WebGL плагины - они заставляют работать со статикой.
Если хочется поковыряться в чистом ООП-коде, вам в эту незавершённую библиотеку:
https://github.com/forcepusher/com.bananaparty.behaviortree

P.S. Чтобы удобно ревьюшить код в гитхабе, можно вставить vscode.dev/ после https:// например, вот так:
https://vscode.dev/github.com/forcepusher/com.bananaparty.behaviortree Открыть/Комментировать

2023-02-08 17:18:59 Открыть/Комментировать

2023-02-05 17:45:38 Как я вижу начало разработки в игровых студиях:

1. Начинать надо с Core Loop геймплея (например, с боевой системы, если игра с боёвкой). На этой стадии отваливается 95% "идей". Симуляция игры в своей голове должна отлаженно работать без белых пятен. Поэтому обычно все тырят симуляцию с другой игры, и это печально, потому что симуляция и есть основа игры. По сути, сама игра.
2. Придумать несколько вариантов сеттинга/тематики и Unique Selling Points (USP), название и короткую фразу, которая будет продавать продукт (обычно фраза призывает к действию). Например, в Dungeon Keeper 2 у Питера Молинье была "It's good to be bad". Она не призывает к действию, но этот чел может продать бутылку воды утопающему.
3. Создать варианты рекламных баннеров для каждого USP или тематики. Тот ещё геморрой, тут нужны навыки арт-директора, маркетолога, умение работать с фотошопом и желательно с нейронками.
4. Закупить тестовую рекламу и запустить рекламные баннеры, чтобы проверить кликабельность баннеров относительно друг друга и, тем самым, выбрать лучшую USP и тематику.
5. Дорисовать сову... А это уже наша профессия.

Ой, я не так понял. Вы хотите узнать, как дорисовать сову? xD

P.s. Сейчас приболел, уже три дня с температурой лежу, поэтому с контентом тяжеловато, но стараюсь :3 Открыть/Комментировать

2023-01-31 20:13:06 Идеальные паттерны

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

Decorator - Дополняет/изменяет объект, не трогая оригинал;
Adapter - Враппер для легаси кода и кривых API-шников;
Strategy - Инструмент для DI, даёт заменять куски кода;
Composite - Сбор сложного поведения из нескольких объектов;
Abstract Factory - Позволяет отвязаться от фреймворка/движка.

Легко будет запомнить акроним "DASCA", и по итогу у нас фундаментом будет "твёрдая доска".
Поняли фишку? xD Пишите в комментариях. Открыть/Комментировать

2023-01-28 20:31:10 Хочу вам признаться: я специализируюсь на веб-играх

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

1. Для того, чтобы поиграть в любимую игру, достаточно всего лишь кликнуть по ссылке.

Это значит, что нам больше не нужен никакой паблишер или площадка вроде Google Play, App Store, Steam и т.п. Они больше не смогут диктовать нам, что можно и чего нельзя, что хорошо и что плохо, а сверху ещё и забирать 30%. Но при этом нет ничего зазорного, чтобы опубликоваться на площадке вроде Яндекс.Игр. Только теперь это опциональный бонус, а не необходимость, как было раньше.

2. Настоящая мультиплатформенность.

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

3. На подходе WebGPU и новые спеки WebAssembly.

Скоро в веб можно будет пихать полноценный RTX и мультипоток. Ведьмак, киберпанк, WoWчик - пилите что угодно, это всё в скором времени можно будет полноценно сделать в вебе. Сейчас нас ограничивает только производительность, но этот лимит снимется с дальнейшим развитием WebAssembly и WebGPU. "Но это же будет лагать на мобилках?" Да, но настройки графики никто не отменял, снимаем галочку и вперёд.

Сейчас WEB выглядит как странное ответвление мобильных игр, но скоро это изменится. Напишите в комментариях, сталкивались ли вы с вебом в работе? И хороших всем выходных Открыть/Комментировать

2023-01-28 15:06:23 Ого, вас уже 1000!

Я тут ещё ютубом балуюсь немного, там пока только пара фановых шортсов вроде этого, но хочу сделать большое видео об ООП.

Кому интересно, вот ссылка https://www.youtube.com/@SalzmanAnton Открыть/Комментировать

2023-01-26 20:52:48 Почему я хочу, чтобы все программисты в нашей студии разбирались в ООП

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

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

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

Эту же цель преследуют и другие направления программирования, но у объектов это получается гораздо лучше - БЕЗ единого компромисса. Один объект всегда содержит в себе (инкапсулирует) небольшую целую программу со стадией исполнения и интерфейсом для коммуникации с другими программами (объектами).

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

Это если очень коротко, говорить о плюсах ООП я могу очень долго. Ну и подписывайтесь на канал, здесь я помогаю писать шикарный код. Открыть/Комментировать

2023-01-24 17:41:03 Я Антон Зальцман, мне 32 и я технический директор игровой студии.

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

1. Я 14 лет работаю в геймдеве. За это время успел поработать над всеми аспектами разработки игр от программирования до арта и паблишинга.

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

3. Работал в США. Обычно я работаю только с зарубежными заказчиками. Один из самых ярких (во всех смыслах) проектов, над которыми я успел поработать, был в 2018-2020, и это Frostfall. Над ним я работал в команде с ребятами из США в Денвере. Это был онлайновый батл-рояль. Я написал весь мультиплеер и ботов для игры.

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

5. Сейчас работаю с WebGL-разработкой для мобилок. Это самая капризная официально не поддерживаемая платформа на Unity. Помимо своей глючности, ужасной производительности, тяжеловесности и проблем с совместимостью, это накладывает жестокие ограничения на код для онлайнового мультиплеера.

В свободное от работы время развиваю симуляционный движок для реал-таймового онлайн-мультиплеера с deterministic prediction-rollback неткодом. Я в целом кайфую от разбора сложных и плохо изученных тем.

Зачем этот канал?

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

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

А, и ещё - я женат, мы вместе уже 10 лет и оба работаем в геймдеве. Она работает Lead-аниматором.

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

Ну как-то так, вобщем, как там говорится? Лайк-подписка и погнали :3 Открыть/Комментировать

2023-01-23 21:44:08 Всем привет!
Завтра выпущу большой пост о том кто я вообще такой и почему фурри на аве Открыть/Комментировать