Ксения

На С++ будет работать быстрее(если правильно написать).
На C# будет проще написать и быстрее написать.
Я бы для такой задачи выбрал бы связку на C#:
1)sqllite или mssql express в качестве бд. Sqllite если все данные хранятся локально.
2) Для работы с бд в c# есть entity framework
3) В качестве библиотеки компьютерного зрения я бы выбрал EmguCv. (Почти тоже самое, что и OpenCVSharp, но документация лучше, поддерживается лучше и в общем информации больше)
4) Ну и в качестве интерфейса можно использовать winforms, хотя я бы написал на wpf

Обосновать такой выбор можно сокращением времени разработки.

По вопросу 1: Если бы это был реальный проект, то скорее всего часть для обработки изображений была бы написана на c++, а интерфейс на c#+wpf или с помощью какого нибудь фрейм ворка типа react.

У вас есть целых три варианта: переехать, найти подходящую работу удаленно, или поменять направление деятельности под более востребованное в вашем городе. Главное что-то поменять, потому что при таком раскладе, ка у вас сейчас, ИМХО, вы бесповоротно закисните...
А еще можно сходить побеседовать в компанию, где вы видели вакансию сеньора, и пообщаться на тему вашего проф.роста. Может выйти очень полезная беседа.

а вы не забыли случаем где нибудь инициализировать массив??
если уж другие переменные и поля из sv доступны..

sv.achieveStatus = new int[,]
или не int. но суть уловили.

а то так и получите NUllRef))нельзя брать длину у НИЧЕГО))

Это противоречит LSP.

Вот представьте, вам дали такую возможность и вы переопределили метод с новыми параметрами. Теперь у нас есть метод, который принимает Layer или даже ICreatable. Допустим так:

void DoSomething (ICreatable layer) {
  layer.Create();
}

Но мы ведь можем передать потомка в этот метод! Делаем следующее и ломаем наш код:
DoSomething(new PerlinNoiseLayer())

Потому именно в таком виде - нет, нельзя.

Для генерации каждого слоя нужен разный набор параметров и генерируются они, соответственно, по-разному

Ну вот у вас есть разница - вот и отобразите её в своем коде.

Это слой? - Да. - Ок, тогда посмотрим его высоты.

Если есть такая необходимость - почему бы не ввести отдельный интерфейс для высот?

void DoSomething (IHasHeights layer) {
  layer.Heights; // <== тут есть высоты
}

Почему бы не воспользоваться фабрикой или билдером? Или даже заставить передавать все эти параметры в конструктор?

public abstract class Layer: ICreatable
{
    float[,] Heights { get; set; }
    public abstract void Create();
}

public class PerlinNoiseLayer : Layer
{
    private float[,] _heights;
    readonly int _resolution ;

    public PerlinNoiseLayer (int resolution) {
        _resolution = resolution;
    }

    public override void Create()
    {
        // тут расширение уже есть
    }
}

Никак не сделать, мало того, что все инструменты для террейна работают только в редакторе, дак ещё и сам террейн был написан много лет назад и с тех пор не обновлялся. Если хотите менять террейн в рантайме, то надо писать свои инструменты, берёте Terrain.terrainData и вперёд. Либо поищите плагин в магазине.

Это вряд ли возможно формализовать. Один из подходов: KISS — keep it simple. Выбираю самое простое решение, потому что, пока оно дойдет до production, требования 10 раз поменяются (и еще 10 раз поменяются уже после внедрения), а простое решение и проще реализовать и проще переделать. Но это только одна из эвристик.

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

Иногда по мере того, как делаешь задачу, понимаешь, что ее можно сделать совсем иначе, при этом получится проще и эффективнее. Ничего страшного нет: с самого начала продумать идеальное решение не может никто.

В жизни нет готовых рецептов на все случаи. Жизнь вообще не поддается формализации.

Разбивать нужно с дублированием вершин внутри шва. Возьмём примитивный случай с террейном четыре на четыре клеточки, размер массива вершин в данном случае будет пять на пять. Разобьём его на четыре части, каждая сторона будет разделена пополам. Чтобы посчитать размер нужных массивов, нужно вычесть единичку из стороны, поделить на два и прибавить единичку. Таким образом, получаем четыре массива три на три, каждый содержит в себе два на два клеточек.
Для вашего случая аналогично, вычитаете единицу из 513, делите на восемь, получается 64, прибавляете единицу, получается 65. Вот и размер нужного вам массива. На стыке вершины будут дублироваться, но каждый кусочек будет независимый.

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

Что касается реализации, то это можно сделать либо с помощью вычислительных шейдеров, либо с помощью обычных шейдеров, всё зависит от возможностей целевой платформы. На компе, если очень хочется, можно и CUDA прикрутить. Если с шейдерами раньше не работали, то могу посоветовать The Book of Shaders, там не про Unity, но достаточно толково.

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

Должно быть:
1. Ссылка на префаб GameObject enemyPrefab
2. Любого Enemy мы создаём из префаба, даже первого. Enemy enemy = Instantiate(enemyPrefab)