Посмотрите статью, может, пригодится их 80lvl экселевый шаманизм.
Ещё вот есть от Milfgard, какие способы баланса существуют.
Ещё есть статья с интересным примером балансирования TowerDefence, довольно полезно.

В современных версиях Unity не работают поля типа rigidbody2D (поле rigidbody2D есть, но имеет тип Component, а не Rigidbody2D). Их нужно присваивать в методе Start в отдельную переменную:

public class CharacterControllerScript : MonoBehaviour
{
    //переменная для установки макс. скорости персонажа
    public float maxSpeed = 10f; 

    //переменная для определения направления персонажа вправо/влево
    private bool isFacingRight = true;

    //ссылка на компонент анимаций
    private Animator anim;

    private Rigidbody2D rb;

    /// <summary>
    /// Начальная инициализация
    /// </summary>
    private void Start()
    {
        anim = GetComponent<Animator>();
        rb = GetComponent<Rigidbody2D>();
    }

И дальше в коде использовать поле rb вместо rigidbody2D.

В принципе, можно переопределить новое поле со старым именем rigidbody2D:

private new Rigidbody2D rigidbody2D;

Разработчик — это не только программист, это все те, кто участвует в процессе разработки. Геймдизайнер — тоже разработчик.

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

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

Книга «Варлорд. Темный пакт» (Angel Delacruz). Одежду печатают в прет-а-порте-принтерах, бесплатно, но вот список разрешённых вариантов одежды — у каждого свой, красивые модели надо оплачивать.

Отменили в 2016-м году, теперь можно две копии. См. вики.

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

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

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

Был монолит со сложностью 10. Делим на 10 микросервисов, получается не 10 по 1, а 10 по 2-3. Но проектом со сложностью 2-3 управлять гораздо проще, чем сложностью 10. И плюс добавляем сложность в взаимодействии, если декомпозиция проведена хороша, то взаимодействий от 9, иначе до 90, сложностью 1.
Получается, вместо сложности 10 выходит 30=20(сервисы)+10(взаимодействия), как и написано в статье («разработка может обойтись вам примерно в 3 раза дороже, чем на монолите», в последнем абзаце). Но управлять 10 монолита уже нереально (невозможно добавить ещё одну, чтобы стало 11), тогда и делают микросервисы.

И Проклятые земли! Трепещите, матёрые кабаны! (трепещите, когда прокачаюсь получше)

Эта история — крайность, безусловно. Хотя и в реальности появляются крайние вещи. Бывают и менеджеры — эффективные, которые сильно помогают программистам.
Просто другую крайность мы тоже читаем — в книгах про «эффективных менеджеров». Там одна крайность, в этой статье — обратная крайность. Истории и той, и этой крайности — важны и поучительны.
nmivan, а сможете написать про подобную историю, но с точки зрения менеджера? Или когда менеджер научит программисту быть лучше. Я не все ваши посты читал, может, уже есть?..

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

Автор уже писал про это, в повести «Проще, чем кажется» — начало тут. Годная история.

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

Руки, крылья… Главное — хвост! (с)

Ну, это pro-уровень :) в первом уроке использовать это не нужно (хотя, упомянуть в тексте можно). Автору пришлось указывать на новую сущность в обзорном уроке — объяснять «код позади» xaml. По опыту обучения новичков, чем меньше различных сущностей в одном уроке — тем лучше.

Статья хорошая, хорошо рассказана основа биндинга.

Есть несколько замечаний/предложений:
1) лучше не загромождать xaml необязательными атрибутами. Например, StackPanel легко обойдётся без Orientation=«Vertical», а оба биндинга справятся без указания Mode. К тому же, режим биндингов и так будет разный — у TextBox режим по умолчанию TwoWay, а у TextBlock — OneWay (как указано в настройках свойств зависимости Text этих классов).

2) Всё-таки лучше указывать датаконтекст в xaml-е, а не в конструкторе:

<Window ...
        xmlns:vm="clr-namespace:Ex1.ViewModels">
    <Window.DataContext>
        <vm:MainWindowViewModel/>
    </Window.DataContext>
    <StackPanel>
        ...
    </StackPanel>
</Window>

Как указали выше, суть не изменится, зато будет два плюса — показать, что в замле можно указывать всё что угодно, а также в редакторе заработает подсказка свойств в биндинге (лучше отметить, что при изменениях во вьюмодели нужно сбилдить проект). А во втором уроке можно будет рассказать про d:DataContext, опять же — для подсказок.

3) Базовый класс BaseViewModel лучше делать не сразу, а потом. В начале показать, что во вьюмодели должен быть INotifyPropertyChanged, а потом (во второй части) сделать рефакторинг и вынести в отдельный класс. Предполагаю, что эту статью будут читать новички, им будет полезно показывать по шагам, объясняя по ходу изменения в коде и показывая необходимость проводить рефакторинг.

Тогда напишите не «Копия текста», а «Пример: Копирование текста».
И вообще, текст от ссылки до места якоря можно поместить в спойлер, раз вы считаете, что эта ссылка вообще нужна. А так, выглядит, что это ссылка на другую статью, или на репозиторий с текстом примера (который был бы полезен многим). Мне пришлось приглядываться к ссылке, чтобы понять, что вы не отправляете меня куда-то.