Фрэймворки переоценены

В последнее время меня часто спрашивают, пользуюсь ли я какими-то фреймворкими, и меня возникает вопрос, почему вокруг них такой хайп?

Лично я не пользуюсь практически ничем. Единственное, сейчас делаем мультиплеер, следовательно изучил Photon. Но в остальном, я считаю, что они практически бесполезны…

Не торопитесь кидаться тапками, есть пару но!

В каких случаях сторонние ресурсы бесполезны:

1. Вы новичок!

Если у вас нет базы, вы не понимаете как составляется архитектура базовых приложений и не уверены в языке, на котором пишете: фреймворки вам не помогут

2. Вы делаете типичный проект:

Фреймворки, как правило, решают специфические проблемы, которые вы не встретите в 50% проектов.

В каких случаях они нужны:

1. Если вам нужно решить специфическую задачу (мультиплеер, сторонный сервер, нейронка и тд)

2. Вы много лет работаете, на 100% уверены в том, что пишете и вам хочется развиваться.

В остальных случаях я не советую из использовать. Почему?

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

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

#Мнение

🎮Чистый код в Unity для начинающих

Привет! Сегодня поговорим об основах архитектуры кода в Unity. Это то, что отличает начинающего разработчика от профессионала.

📝 Основные принципы чистого кода:

1. Правильное именование

// ❌ Плохо
public class plController : MonoBehaviour
{
    private float spd = 5f;
    public void mv() { }
}

// ✅ Хорошо
public class PlayerController : MonoBehaviour
{
    private float _moveSpeed = 5f;

    public void Move() { }
}

2. Один скрипт - одна задача

// ❌ Плохо
public class Player : MonoBehaviour
{
    public void Move() { }
    public void Attack() { }
    public void UpdateUI() { }
    public void SaveGame() { }
}

// ✅ Хорошо
public class PlayerMovement : MonoBehaviour
{
    [SerializeField] private float _moveSpeed = 5f;

    private Rigidbody2D _rb;

    private void Awake()
    {
        _rb = GetComponent<Rigidbody2D>();
    }

    public void Move(Vector2 direction)
    {
        _rb.velocity = direction * _moveSpeed;
    }
}

3. Кэширование компонентов

// ❌ Плохо
private void Update()
{
    GetComponent<Rigidbody2D>().velocity = Vector2.right;
}

// ✅ Хорошо
private Rigidbody2D _rb;

private void Awake()
{
    _rb = GetComponent<Rigidbody2D>();
}

private void FixedUpdate()
{
    _rb.velocity = Vector2.right;
}

💡 Полезные советы:

- Используйте [SerializeField] вместо public для инспектора
- Группируйте похожие переменные
- Добавляйте XML-комментарии к публичным методам

/// <summary>
/// Наносит урон игроку.
/// </summary>
/// <param name="damage">Количество урона.</param>
/// <returns>Оставшееся здоровье.</returns>
public float TakeDamage(float damage)
{
    _currentHealth -= damage;
    return _currentHealth;
}

🎯 Простой пример правильной структуры:

public class PlayerHealth : MonoBehaviour
{
    [SerializeField] private float _maxHealth = 100f;

    private float _currentHealth;

    public event System.Action<float> OnHealthChanged;

    private void Awake()
    {
        _currentHealth = _maxHealth;
    }

    public void TakeDamage(float damage)
    {
        _currentHealth = Mathf.Max(0f, _currentHealth - damage);
        OnHealthChanged?.Invoke(_currentHealth);
    }

    public void Heal(float amount)
    {
        _currentHealth = Mathf.Min(_maxHealth, _currentHealth + amount);
        OnHealthChanged?.Invoke(_currentHealth);
    }
}

📚 Что изучать дальше:
- SOLID принципы
- Паттерны проектирования
- Dependency Injection
- Событийно-ориентированная архитектура

⚡️ Совет: Начните применять эти принципы в маленьких проектах. Со временем чистый код войдет в привычку.

#Фишки

Странная ситуация получается, вроде и опыта у меня много и над проектами крупными работал, а ни одной игры в сторе нет…

Надо бы исправлять это)

Как вы относитесь к ритм играм?)

За пару дней сделал вот такой вот детектор битов. Работает не идеально, нужно настраивать чувствительность и другие параметры. Но все же, меня устраивает)

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

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

На слова не обращайте внимания)

Мы потратили неделю на настройку освещения нашей локации

2-3 дня я потратил на то, чтобы понять, как можно сохранить запеченый свет в префаб)

В итоге нашел решение, которое работает:)

Что мы делаем в час ночи?

Едим пасту-бургер (необычный рецепт:)

Приветствую всех новеньких в канале)

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

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

Естественно, финальное решение за мной и опираться я буду впервую очередь на свои желания, но узнать ваше мнение мне тоже важно)

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

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

Но в конечном счете, идея никогда не менялась. Я хочу создавать и делиться этим, а обучающая часть забирает немало времени, а результата особо не приносит (того, которого хочу я)

Рад что мы сошлись во мнениях)

Периодически буду писать про личное и о моих проектах.

Что нибудь полезное - как появится идея

Процесс разработки игры + Git

Я, как и все в начале, всегда разрабатывал проекты по схеме: пришла в голову идея - сделал, захотел исправить баг, исправил. Все хаотично, а когда дело доходит до коммита на гит, не знаешь как его назвать и что вообще туда написать.

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

Все достаточно просто: прежде чем делать, запишите все идеи в блокнот, назначте одну и сделайте ее до конца. Затем коммит и возвращаемся к выбору идеи.
Максимально тривиально, но очень эффективно:)

Возможно кто-то уже говорил про такой подход) но я для себя его открыл сам

#Фишки

Как думаете, сколько проектов одновременно стоит делать разработчику?

Казалось бы очевидно: один. Быстрее и качественнее.

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

Поэтому для себя я определил такую стратегию:

Рабочее время я разделяю на 3 части.

Основная: для самого крупного проекта. Он должен идти долго, скорее всего это будет работа.

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

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

Подъехали новые концепты персов для авточесса)

Copilot спасает от выгорания.

Понимаю, что многие не могут оплатить его или просто достаточно дорого. Но в моем случае это просто спасение.

Мне его оплачивает отдельно руководитель и благодаря этому я могу работать практически без перерывов


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

Копилот решает 100% монотонных задач, во время которых я могу спокойно отвлечься просто проверяя его в конце и давая ему правки. Такой своеобразный личный джун, который может сделать что угодно. Еще и моментально:)

Кто не понял, тот поймет

Приколы уровня болеем с девушкой

Сработало:)

Весь геймдев держится на инди разработчиках!

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

В таких условиях очень сложно развиваться дальше. Ты не развиваешь новые навыки, а просто выполняешь рутинные задачи.

В отличии от инди разработчиков! Они - мультиинструменталы! Могут и анимации настроить и апи интегрировать и геймдизайн уровня проработать. В общем, все аскпекты игры от идеи до релиза. И я искренне восхищаюсь ими.

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

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

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

Хочется все и сразу, но так не бывает)


К чему я это все? Сам не знаю:) Но захотелось поделиться. Возможно, кому-нибудь станет немного спокойнее, что он не один такой:)

ПОВ: Первый день после болезни