Внезапно решили залететь на конкурс. Расскажу об этом в нескольких постах.
Идея пришла за пару дней до начала. Возможно, меня заинтересовало то, что организаторы ранее не устраивали игровые задания, а занимались конкурсами для решений из сферы бизнеса. Называется “Лидеры цифровой трансформации”. Там 21о задание, где 21ое - это игра (в прошлом году игр среди задач не было). Организаторы: Агентство инноваций Москвы и Департамент предпринимательства. На сколько же это ни как обычно, очень серьёзный подход. На столько серьёзный, что по ощущениям на одну наполовину - это хакатон, на другую - подача документов в МФЦ.
В жюри присутствуют как персоны из гейм-индустрии, так и представители указанных департаментов, что на мой взгляд только добавляет интересности. Тут проекты будут оценивать не только профессионалы, но и специалисты из сферы культуры и бизнеса, которые быть может вообще в игры не играют.
Задание, тоже, нестандартное для разработчиков игр. Обычно это что? Какая-то 1 из условных 20 рандомных прикольных тем, выбранных в момент старта. Но не в этот раз. Тут главная тема - Москва. С массой пожеланий и оговорок. Позитивная коннотация образа города, никакой чернухи, запрещена разная нехорошая деструктивная пропаганда, а также город должен однозначно читаться и узнаваться.
Далее - есть датасет. Внезапно, но выдали пак из тысяч 3D-моделей различных зданий и сооружений Москвы. Все в текстурах, в реальных пропорциях и очень неоптимизированное, а главное все файлы подписаны условными номерами, которые не сообщают ничего о модели внутри файла.
Кроме сданного проекта, нужно предоставить репозиторий с кодом, презентацию, оформленную по общему шаблону, техническую и сопроводительную документацию. И оцениваться это будет все вместе.
Вот такие вводные мы получили и начали пилить. Срок - 7 дней.
Покажу несколько моделей из дата сета. Такое ощущение, что часть из них делали сканерами. Мы в начале были в небольшом ступоре, когда решали, чтобы с ними такого придумать.
#события
Идея пришла за пару дней до начала. Возможно, меня заинтересовало то, что организаторы ранее не устраивали игровые задания, а занимались конкурсами для решений из сферы бизнеса. Называется “Лидеры цифровой трансформации”. Там 21о задание, где 21ое - это игра (в прошлом году игр среди задач не было). Организаторы: Агентство инноваций Москвы и Департамент предпринимательства. На сколько же это ни как обычно, очень серьёзный подход. На столько серьёзный, что по ощущениям на одну наполовину - это хакатон, на другую - подача документов в МФЦ.
В жюри присутствуют как персоны из гейм-индустрии, так и представители указанных департаментов, что на мой взгляд только добавляет интересности. Тут проекты будут оценивать не только профессионалы, но и специалисты из сферы культуры и бизнеса, которые быть может вообще в игры не играют.
Задание, тоже, нестандартное для разработчиков игр. Обычно это что? Какая-то 1 из условных 20 рандомных прикольных тем, выбранных в момент старта. Но не в этот раз. Тут главная тема - Москва. С массой пожеланий и оговорок. Позитивная коннотация образа города, никакой чернухи, запрещена разная нехорошая деструктивная пропаганда, а также город должен однозначно читаться и узнаваться.
Далее - есть датасет. Внезапно, но выдали пак из тысяч 3D-моделей различных зданий и сооружений Москвы. Все в текстурах, в реальных пропорциях и очень неоптимизированное, а главное все файлы подписаны условными номерами, которые не сообщают ничего о модели внутри файла.
Кроме сданного проекта, нужно предоставить репозиторий с кодом, презентацию, оформленную по общему шаблону, техническую и сопроводительную документацию. И оцениваться это будет все вместе.
Вот такие вводные мы получили и начали пилить. Срок - 7 дней.
Покажу несколько моделей из дата сета. Такое ощущение, что часть из них делали сканерами. Мы в начале были в небольшом ступоре, когда решали, чтобы с ними такого придумать.
#события
🫡5❤1🔥1
Хакатон - это маленький проект и нельзя удалять важные роли или убирать процессы. Нужно держать баланс, помнить про важные аспекты. У нас команда из 4х человек, где роли распределились вот так:
- Программист - немного менеджер проекта
- 3D художник - технический художник
- Художник - геймдизайнер - композитор
- Сценарист
Мы собрались проверенной командой, где уже понимали чего ожидать друг от друга, но к завершению периода разработки, мы ощутили просадку по геймдизайну. Где-то не понятно игроку, что происходит, где-то очки начисляются непонятно как, из 7и концовок реально получить можно 3-4.
Цель этой мысли не критика, а рефлексия для выводов на будущее. У нас отличный ГД, вывез тонну задач, настоящий атлант, но в данном предприятии, он закрывает еще две важнейшие области - визуальный стиль и аудио сопровождение. Дело тут в распределении времени, доля на геймдизайн оказалась слишком мала, 33% от общего времени конкретного тиммейта. Физический было не вывезти столько нагрузки чтобы успеть всё. Таким образом наш проект имеет больший вес в контенте, чем в играбельности. Опасное смещение, которое может стоить нам баллов. Ощущение от геймплея важнее контента.
В процессе нарастает количество задач, фиксов и эмоций. И сильно мог бы помочь человек, который бы рулил 2 вещами: задачами на доске иварил бы обеды финальным виденьем проекта. То есть бы мониторил, что ещё нужно сделать, в каком порядке, что важно, а что нет. Таким образом снизил бы уровень эмоций, разрядил чувство аврала, разгрузил исполнителей и не давал бы финальному результату съехать не в ту степь.
Пока не буду представлять наш высоковибрационный проект) О нем позже. Покажу несколько игровых экранов.
#события #девлог
- Программист - немного менеджер проекта
- 3D художник - технический художник
- Художник - геймдизайнер - композитор
- Сценарист
Мы собрались проверенной командой, где уже понимали чего ожидать друг от друга, но к завершению периода разработки, мы ощутили просадку по геймдизайну. Где-то не понятно игроку, что происходит, где-то очки начисляются непонятно как, из 7и концовок реально получить можно 3-4.
Цель этой мысли не критика, а рефлексия для выводов на будущее. У нас отличный ГД, вывез тонну задач, настоящий атлант, но в данном предприятии, он закрывает еще две важнейшие области - визуальный стиль и аудио сопровождение. Дело тут в распределении времени, доля на геймдизайн оказалась слишком мала, 33% от общего времени конкретного тиммейта. Физический было не вывезти столько нагрузки чтобы успеть всё. Таким образом наш проект имеет больший вес в контенте, чем в играбельности. Опасное смещение, которое может стоить нам баллов. Ощущение от геймплея важнее контента.
В процессе нарастает количество задач, фиксов и эмоций. И сильно мог бы помочь человек, который бы рулил 2 вещами: задачами на доске и
Пока не буду представлять наш высоковибрационный проект) О нем позже. Покажу несколько игровых экранов.
#события #девлог
❤3👍2
Мы вышли в финал. Из всех команд выбрали 10 лучших и пригласили на финал в формате трёхдневного фестиваля, который пройдёт в кластере «Ломоносов», ИНТЦ МГУ «Воробьёвы горы». Никогда я не приближался к МГУ так близко)
В течение пары дней мы собрались и прибыли сегодня всем составом в столицу. Будет 3 полных дня лекций, питчей, докладов, коворкинг, кейтеринг, диджей сеты и разных других активностей. Масштабы поражают.
Но нас интересуют питчи - это ещё один раунд отбора. Теперь команды должны “продать” свой проект членам жюри так, как будто это заказчик. Это нам сложно по двум причинам:
1. Мы не профессиональные ведущие, а вот эти самые айтишники, которые любят свой спокойный уголок с приглушенным освещением.
2. При постановке задачи было обозначено отдельным пунктом, что коммерческая составляющая не учитывается в оценках жюри. И упор на нее мы не делали. Как питчить то, что не имеет коммерческого потенциала?
Завтра мы будем работать над этими вопросами и готовиться выступить перед жюри и другими участниками. Неизвестно сможем ли мы занять какие-то места в финале, но сама эта движуха - уже награда за труды. Как говориться, делай что должен и будь, что будет.
#события
В течение пары дней мы собрались и прибыли сегодня всем составом в столицу. Будет 3 полных дня лекций, питчей, докладов, коворкинг, кейтеринг, диджей сеты и разных других активностей. Масштабы поражают.
Но нас интересуют питчи - это ещё один раунд отбора. Теперь команды должны “продать” свой проект членам жюри так, как будто это заказчик. Это нам сложно по двум причинам:
1. Мы не профессиональные ведущие, а вот эти самые айтишники, которые любят свой спокойный уголок с приглушенным освещением.
2. При постановке задачи было обозначено отдельным пунктом, что коммерческая составляющая не учитывается в оценках жюри. И упор на нее мы не делали. Как питчить то, что не имеет коммерческого потенциала?
Завтра мы будем работать над этими вопросами и готовиться выступить перед жюри и другими участниками. Неизвестно сможем ли мы занять какие-то места в финале, но сама эта движуха - уже награда за труды. Как говориться, делай что должен и будь, что будет.
#события
🌚4👍3
Мы провели питч своего проекта и наконец достигли точки, где от нас уже ничего не зависит и можно расслабиться. Напряжение за эти дни было запредельным.
Что я для себя отметил:
- Умение вести презентацию. Надо делать это не только правильно по шаблонам питчинга, но и ярко, харизматично. Потому, что это вишенка на торте, которая создаёт целостность команды, идеи и проекта. На это смотрят и оценивают. Здесь нам надо прокачиваться. Мне кажется, на фото наши лица и слайд идеальные)
- Наконец увидели проекты других команд. Наш проект в техническом смысле простой. Мы в финале с ребятами, которые мутят мета-вселенные и аля АА-шутеры с анриал-графикой. По моим замечаниям, это впечатляет не всех членов жюри, потому что они ищут идеи и рациональное зерно, а контент и графику можно создать любую. Я не приуменьшаю количества труда вложенные командами в проекты, но отсутствие единого мнения у жюри заметно. Мы думаем, что в тройку не попадём, но до сих пор не понятны фавориты.
- Хакатон запредельно крутой, а также общий вайб. За пару дней тут, мы прочувствовали общий подход к организации и общению. Собянин по-настоящему ищет таланты и проекты, здесь происходит мощнейший акселератор для IT. Масса программ финансирования и нужных людей для стартапов.
- Большая концентрация ума на квадратный метр. У меня включился синдром самозванца потому, что рядом с нами-игроделами другие команды, которые решают задачи по выгрузке данных со спутников, создании ИИ для анализа медицинских данных и снижения врачебных ошибок, темы связанные с «железом», дронами, кибер-протезами, робототехникой и др. Всем нужно тянуться к такой же глубине хардов в своих сферах.
- Отсутствует нетворкинг. Организатор не продумал какого-то формата для общения и обсуждений команд внутри специальностей. Впрочем мы сами сделали свой чат игроделов-финалистов.
UPD: Наш модератор 21 задачи подхватила эту идею и разослала всем командам приглашение в общий чат. Молодец)
#события
Что я для себя отметил:
- Умение вести презентацию. Надо делать это не только правильно по шаблонам питчинга, но и ярко, харизматично. Потому, что это вишенка на торте, которая создаёт целостность команды, идеи и проекта. На это смотрят и оценивают. Здесь нам надо прокачиваться. Мне кажется, на фото наши лица и слайд идеальные)
- Наконец увидели проекты других команд. Наш проект в техническом смысле простой. Мы в финале с ребятами, которые мутят мета-вселенные и аля АА-шутеры с анриал-графикой. По моим замечаниям, это впечатляет не всех членов жюри, потому что они ищут идеи и рациональное зерно, а контент и графику можно создать любую. Я не приуменьшаю количества труда вложенные командами в проекты, но отсутствие единого мнения у жюри заметно. Мы думаем, что в тройку не попадём, но до сих пор не понятны фавориты.
- Хакатон запредельно крутой, а также общий вайб. За пару дней тут, мы прочувствовали общий подход к организации и общению. Собянин по-настоящему ищет таланты и проекты, здесь происходит мощнейший акселератор для IT. Масса программ финансирования и нужных людей для стартапов.
- Большая концентрация ума на квадратный метр. У меня включился синдром самозванца потому, что рядом с нами-игроделами другие команды, которые решают задачи по выгрузке данных со спутников, создании ИИ для анализа медицинских данных и снижения врачебных ошибок, темы связанные с «железом», дронами, кибер-протезами, робототехникой и др. Всем нужно тянуться к такой же глубине хардов в своих сферах.
- Отсутствует нетворкинг. Организатор не продумал какого-то формата для общения и обсуждений команд внутри специальностей. Впрочем мы сами сделали свой чат игроделов-финалистов.
UPD: Наш модератор 21 задачи подхватила эту идею и разослала всем командам приглашение в общий чат. Молодец)
#события
🔥4🍌4👍3
Финальный пост про хакатон хочу сделать красивым, поэтому он позже, а пока давайте на технические темы.
Попался пост от умного чела, который точно знает, что делает с приемом хранения двух переменных, например переменных типа int в типе long. Вот пример метода извлечения из его поста:
Наглядным это не назвать, 2 подписанных поля типа int в структуре — это удобно читать глазами, а парсить long глазами — нет.
Пожалуй, это вариант оптимизации. Потому как такая структура, будет занимать не 8 байт, хотя казалось бы.
Остаётся поинт про быстрее работает, но снова скорее всего, эффект будет заметен только на больших объемах данных.
Если фантазировать, то пожалуй, подобную штуку в купе с другими приемами оптимизации можно вкручивать в фичи, где есть тоны данных, например, какое-то гигантское игровое поле с клетками, где нужно хранить данные для каждой клетки.
#техничка
Попался пост от умного чела, который точно знает, что делает с приемом хранения двух переменных, например переменных типа int в типе long. Вот пример метода извлечения из его поста:
void ToInts(long a, out int a1, out int a2)
{
a1 = (int)(a & uint.MaxValue);
a2 = (int)(a >> 32);
}
Выглядит классно, но не могу представить хорошего валидного применения, потому что:Наглядным это не назвать, 2 подписанных поля типа int в структуре — это удобно читать глазами, а парсить long глазами — нет.
Пожалуй, это вариант оптимизации. Потому как такая структура, будет занимать не 8 байт, хотя казалось бы.
struct Test
{
int a;
int b;
}
Потому, что каждый процессор производит выравнивание по адресным границам, до значений, с которыми именно он лучше работает. Тот случай, когда «на моей машине» может работать по-другому, проц может сделать выравнивание, например, до 12 или 16 байт. Итого размер может плясать. Но если мы работаем на таком низком уровне оптимизации, то надо следить за всей картиной кода. Одно неосторожное движение где-то в стеке вызов и эта оптимизация станет ничтожна. И конечно, вопрос к объёму данных на которых это станет «интересно». Остаётся поинт про быстрее работает, но снова скорее всего, эффект будет заметен только на больших объемах данных.
Если фантазировать, то пожалуй, подобную штуку в купе с другими приемами оптимизации можно вкручивать в фичи, где есть тоны данных, например, какое-то гигантское игровое поле с клетками, где нужно хранить данные для каждой клетки.
#техничка
👍4🤯2🌚2❤1
Еще немного про джемы. Зачем вообще участвовать в конкурсах? Один мой коллега, который часто участвует в подобного рода событиях, недавно поделился своим мнением. Хочу пересказать некоторые его поинты и дополнить своими:
1. На джеме сталкиваешься с задачами уровня приложения - жизненный цикл, загрузка статических данных, менеджмент окон итд. Тот самый “скелет”, который уже решён на рабочем проекте и очень редко можно столкнуться с задачами такого уровня.
2. Джем хорошо показывает код, который невозможно настроить. Позволяет на короткой дистанции сделать выводы, что не так. Подсвечивает разницу между фичей и игрой. Становятся понятны требования к инструментам, которые важны на следующих этапах разработки - сетап и тесты.
3. Ограничение по времени учит "срезать углы". Есть идея, на работе ее оценил бы в 5 дней. Но как сделать тоже самое за 5 часов? Оказывается это возможно. Чтобы понимать масштаб проблемы, можно посмотреть на победителей прошлого джема - часто, это делают любители за короткий срок. А ты, профессионал, способен повторить такое? Без лукавства "мне надо х10 времени, потому что оно будет по SOLID, расширяемо и там архитектура".
4. В ваш проект поиграют и дадут фидбек. Похвалят и укажут проблемы. Это позволит оценить верность принятых вами решений.
5. Делая фичи на работе, можно забыть как делать игру. Класть кирпичики друг на друга - это не тоже самое, что строить дом.
6. Нетворкинг. Я участвовал всего несколько раз в джемах и каждый раз это выливалась в массу знакомств, новых контактов, проектов, историй.
7. Если вы джун без опыта или в поиске работы, то такие события создают вам проекты в портфолио, строчки в резюме и возможность попасть на собес через новые знакомства.
8. Ещё один обширный поинт я хочу подробнее раскрыть в отдельном посте и закрыть тему с джемами на время.
#события
1. На джеме сталкиваешься с задачами уровня приложения - жизненный цикл, загрузка статических данных, менеджмент окон итд. Тот самый “скелет”, который уже решён на рабочем проекте и очень редко можно столкнуться с задачами такого уровня.
2. Джем хорошо показывает код, который невозможно настроить. Позволяет на короткой дистанции сделать выводы, что не так. Подсвечивает разницу между фичей и игрой. Становятся понятны требования к инструментам, которые важны на следующих этапах разработки - сетап и тесты.
3. Ограничение по времени учит "срезать углы". Есть идея, на работе ее оценил бы в 5 дней. Но как сделать тоже самое за 5 часов? Оказывается это возможно. Чтобы понимать масштаб проблемы, можно посмотреть на победителей прошлого джема - часто, это делают любители за короткий срок. А ты, профессионал, способен повторить такое? Без лукавства "мне надо х10 времени, потому что оно будет по SOLID, расширяемо и там архитектура".
4. В ваш проект поиграют и дадут фидбек. Похвалят и укажут проблемы. Это позволит оценить верность принятых вами решений.
5. Делая фичи на работе, можно забыть как делать игру. Класть кирпичики друг на друга - это не тоже самое, что строить дом.
6. Нетворкинг. Я участвовал всего несколько раз в джемах и каждый раз это выливалась в массу знакомств, новых контактов, проектов, историй.
7. Если вы джун без опыта или в поиске работы, то такие события создают вам проекты в портфолио, строчки в резюме и возможность попасть на собес через новые знакомства.
8. Ещё один обширный поинт я хочу подробнее раскрыть в отдельном посте и закрыть тему с джемами на время.
#события
👍5⚡3🐳1
Марево. Так называется наша игра-финалист с конкурса “Лидеры цифровой трансформаций 2023”. Теперь я готов сказать пару слов о смысле участия в конкурсе и выложить ссылку для желающих поиграть.
В продолжение предыдущего поста про дежмы, я говорил о практической пользе, но психологический для программиста это обычные серые будни - развиваться, разбираться, искать лучшее решение, делать новое итд. Все мы ещё люди и поэтому на одних “нужных\полезных\правильных” вещах далеко не уедешь. Ещё нужна энергия и способность сохранять простой интерес к профессии годами. Поэтому пара философских мыслей в дополнение к ответу на вопрос. Здесь уже конкретно по нашему опыту на ЛЦТ 2023.
Мы вписались в конкурс под закрытие заявок и времени было мало. Проект наш заведомо небольшой и технический не сложный. Но у нас была цель - довести идею до ума и сдать его вовремя. Мы справились и потом неожиданно для себя попали в финал. Далее началось наше приключение, нас пригласили в Москву в инновационный кластер МГУ, там нас ждали новые испытания, дедлайны, лидеры отрасли, команды, лекции, выставки, диджеи, робо-собака и много другое. А также то, что мы сами себе организовали, когда преодолели все дедлайны - прогулка по летней Москве по локациям нашей игры всей командойи с винишком. Затем в финале мы вместе со всеми трепещали в ожидании результатов, чтобы узнать, что мы заняли 9ое место… и получили ещё шквал эмоций.
Я это все рассказываю, чтобы проиллюстрировать суть, к которой подвёл. Именно так создаются эмоции, дружба, совместные моменты, общие истории и именно так заряжается батарейка на новые свершения.
Мы с самого начала не рассчитывали на денежные призы или первые места из-за миниатюрности и “странности” своего проекта, но получили гораздо больше, чем рассчитывали изначально. Поэтому в шапке этого поста не трейлер игры.
Скачать проект можно по ссылке: https://rayonist.itch.io/marevo
А во втором нашем канале более высоковибрационное описание проекта
@cat_and_code
#события #девлог
В продолжение предыдущего поста про дежмы, я говорил о практической пользе, но психологический для программиста это обычные серые будни - развиваться, разбираться, искать лучшее решение, делать новое итд. Все мы ещё люди и поэтому на одних “нужных\полезных\правильных” вещах далеко не уедешь. Ещё нужна энергия и способность сохранять простой интерес к профессии годами. Поэтому пара философских мыслей в дополнение к ответу на вопрос. Здесь уже конкретно по нашему опыту на ЛЦТ 2023.
Мы вписались в конкурс под закрытие заявок и времени было мало. Проект наш заведомо небольшой и технический не сложный. Но у нас была цель - довести идею до ума и сдать его вовремя. Мы справились и потом неожиданно для себя попали в финал. Далее началось наше приключение, нас пригласили в Москву в инновационный кластер МГУ, там нас ждали новые испытания, дедлайны, лидеры отрасли, команды, лекции, выставки, диджеи, робо-собака и много другое. А также то, что мы сами себе организовали, когда преодолели все дедлайны - прогулка по летней Москве по локациям нашей игры всей командой
Я это все рассказываю, чтобы проиллюстрировать суть, к которой подвёл. Именно так создаются эмоции, дружба, совместные моменты, общие истории и именно так заряжается батарейка на новые свершения.
Мы с самого начала не рассчитывали на денежные призы или первые места из-за миниатюрности и “странности” своего проекта, но получили гораздо больше, чем рассчитывали изначально. Поэтому в шапке этого поста не трейлер игры.
Скачать проект можно по ссылке: https://rayonist.itch.io/marevo
А во втором нашем канале более высоковибрационное описание проекта
@cat_and_code
#события #девлог
🔥7❤4
Люблю встречать что-то эдакое в коде, обычно не свойственное для С#. Указатели как раз такой зверь, который встречается не часто. Их применение на мой взгляд не оправдано, потому что можно обойтись без них. Что характерно для их использования? Они работают в блоках unsafe кода. Это такие участки кода, где среда CLR не может отследить использование памяти и собрать мусор. Эта задача ложится на программиста. Потенциально опасное место для утечек и ошибок, особенно когда код пишется руками разных программистов.
Что можно сделать с помощью указателей? Например, грубо выражаясь, можно заставить value-объект вести себя как ссылочный.
На самом деле мы работаем с указателями в шарпах чаще всего другими способами:
- Когда создаём объект через операцию new, которая возвращает указатель на объект после выделения памяти и вызова всех конструкторов
- Когда используем оператор
- При упаковке значимых типов, они записываются в кучу и получают свою ссылку, то есть указатель
- При передачи параметров в методы мы можем использовать ключевые слова
- Когда назначаем делегат - фактический назначаем указатель на функцию.
- Ну про ссылочные типы и говорить нечего…
Если у вас есть примеры из практики, где вы используете указатели в unsafe коде - поделитесь, интересно.
#техничка
Что можно сделать с помощью указателей? Например, грубо выражаясь, можно заставить value-объект вести себя как ссылочный.
int* pointer;
int anyValue = 100;
point = &pointer; // теперь указатель pointer ссылается на ту же область памяти, где записано значение anyValue
anyValue += 100;
Debug.Log($”{*pointer}”); // 200
*pointer = 500;
Debug.Log($”{anyValue}”); // 500
Ещё с помощью указателей можно получить адрес памяти, куда ссылается указатель, но это очень специфично. И конечно можно ссылать один указатель на другой, но здесь я ещё больше радуюсь данной возможности, но совсем не могу придумать применение в нашей сфере.На самом деле мы работаем с указателями в шарпах чаще всего другими способами:
- Когда создаём объект через операцию new, которая возвращает указатель на объект после выделения памяти и вызова всех конструкторов
- Когда используем оператор
as, среда проверяет совместимость типов и возвращает либо указатель, либо null. Warrior unit = wizard as Warrior;
- Когда пишем ключевое слово this мы обращаемся к указателю- При упаковке значимых типов, они записываются в кучу и получают свою ссылку, то есть указатель
- При передачи параметров в методы мы можем использовать ключевые слова
ref и out для значимых типов, где компилятор будет генерировать метаданные, описывающие параметр как передаваемый по ссылке- Когда назначаем делегат - фактический назначаем указатель на функцию.
- Ну про ссылочные типы и говорить нечего…
Если у вас есть примеры из практики, где вы используете указатели в unsafe коде - поделитесь, интересно.
#техничка
🐳4👍2
У меня есть подборка мемов про разработку, но они лежат где попало и поэтому неудобно искать нужный к ситуации, хочется простой систематизации. Во-вторых прекрасным хочется делиться, а как мне кажется, здесь у нас вполне себе небольшое общество ценителей айтишных шутеек. И наконец, их наличие не испортит никакие другие посты и темы. Поэтому буду теперь иногда вкидывать с тегом для поиска.
Если у вас есть пара любимых мемов - киньте в коменты.
Если у вас есть пара любимых мемов - киньте в коменты.
👍2
Какую мысль можно вынести из скандала с Unity? На данный момент они начирикали в Твиттере X, что извиняются, но не понятно за что. Толи за весь сыр-бор, толи за то, что не смогли нормально "продать" свою новую систему сборов и вернутся к нам, когда подготовят презентацию получше.
При этом сейчас разные слухи ходят о будущем Unity, в том числе, что его готовят к сливу. Но предлагаю абстрагироваться от подробностей и просто принять факт, что если будет какой-то негативный сценарий (не важно какой конкретно) и движок начнёт накрываться медным тазом, что это значит для нас?
Тогда технология будет терять свою популярность, и это напрямую отразится на количестве вакансий для Unity Developers. Не в один день, потому что старые-большие проекты будут поддерживаться, но новых будет все меньше.
Если сейчас все откатят, все равно мы теперь знаем, что история может повториться в любой момент, и уверенность в завтрашнем дне все равно не такая сильная, как до этого скандала.
Как действовать в таких условиях? Можно отнестись к этому, как к толчку, который мы давно ждали. Кому-то его не хватало, чтобы начать изучать Unreal и C++, Godot, серверный стек или что-то ещё. Не потому что корабль тонет и сейчас надо паниковать, а потому, что всегда стоит держать в голове, что рынок может поменяться, и нужно иметь план Б. Сейчас просто яркое напоминание об этом.
Какие-то технологии уходят, и на их место приходят новые. Можно вспомнить взлёт и падение популярности Xamarin. А также знания разных инструментов помогают подбирать эти инструменты под задачи, а не делать все одним и тем же молотком. Такие перемены всегда некомфортны, но для нас, как для специалистов, это возможность для развития.
#новость
При этом сейчас разные слухи ходят о будущем Unity, в том числе, что его готовят к сливу. Но предлагаю абстрагироваться от подробностей и просто принять факт, что если будет какой-то негативный сценарий (не важно какой конкретно) и движок начнёт накрываться медным тазом, что это значит для нас?
Тогда технология будет терять свою популярность, и это напрямую отразится на количестве вакансий для Unity Developers. Не в один день, потому что старые-большие проекты будут поддерживаться, но новых будет все меньше.
Если сейчас все откатят, все равно мы теперь знаем, что история может повториться в любой момент, и уверенность в завтрашнем дне все равно не такая сильная, как до этого скандала.
Как действовать в таких условиях? Можно отнестись к этому, как к толчку, который мы давно ждали. Кому-то его не хватало, чтобы начать изучать Unreal и C++, Godot, серверный стек или что-то ещё. Не потому что корабль тонет и сейчас надо паниковать, а потому, что всегда стоит держать в голове, что рынок может поменяться, и нужно иметь план Б. Сейчас просто яркое напоминание об этом.
Какие-то технологии уходят, и на их место приходят новые. Можно вспомнить взлёт и падение популярности Xamarin. А также знания разных инструментов помогают подбирать эти инструменты под задачи, а не делать все одним и тем же молотком. Такие перемены всегда некомфортны, но для нас, как для специалистов, это возможность для развития.
#новость
⚡6🫡5
На этом канале обсуждаем техническую сторону разработки игр, говорим про особенности Unity и C#, общаемся на профессиональные темы программистов и про геймдев в целом.
@KotikovD — автор канала, программист
А Горюшко вслед собакою… - наша игра в Steam, атмосферное и эмоциональное приключение о юной почтальонке
Основные теги:
#девлог@cat_and_code - про разные проекты, которыми занимаюсь
#техничка@cat_and_code - про программирование, код и Unity
#мем@cat_and_code - развивающаяся коллекция IT-мемов на разные ситуации
#игры@cat_and_code - мои небольшие обзоры про специфические игры в которые играю
#события@cat_and_code - про митапы, лекции и хакатоны
Буст канала:
https://news.1rj.ru/str/boost/cat_and_code
@KotikovD — автор канала, программист
А Горюшко вслед собакою… - наша игра в Steam, атмосферное и эмоциональное приключение о юной почтальонке
Основные теги:
#девлог@cat_and_code - про разные проекты, которыми занимаюсь
#техничка@cat_and_code - про программирование, код и Unity
#мем@cat_and_code - развивающаяся коллекция IT-мемов на разные ситуации
#игры@cat_and_code - мои небольшие обзоры про специфические игры в которые играю
#события@cat_and_code - про митапы, лекции и хакатоны
Буст канала:
https://news.1rj.ru/str/boost/cat_and_code
Telegram
Кот и код
Проголосуйте за канал, чтобы он получил больше возможностей.