Евгений Иванов

Но есть "проблема". При добавлении новой фразы для героя, она всегда будет в конце таблицы т.к. это новая запись.
Т.е. при дополнении таблицы фразами - для 1 героя, для второго, придумали новую фразу для 1 героя, они будут идти в разнобой. Это визуально не удобно для отслеживания, понимания, не красиво.

Это не проблема. При выборке фраз ты можешь спокойно указать нужный порядок.

База данных - это не эксель, и даже в экселе это не было бы проблемой благодаря сортировкам.

Первое что приходит на ум - Одна таблица для всех героев с 3 полями
id - автоинкремент
имя героя
фраза героя

Лучше для героев завести отдельную таблицу, а в этой таблице держать только id героя.

Вариант 2. Для каждого героя своя таблица. Таблица Hero1 Hero2 и т.д.
id - автоинкремент
фраза героя
И далее, делать выборку всех записей из таблицы т.к. в ней фразы для нужного героя.
Просто, интуитивно понятно, все фразы идут "друг за другом", но много таблиц.

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

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

С точки зрения адекватного проектирования баз данных — однозначно первый вариант (и, желательно, с индексом по имени героя). А если очень хочется просматривать отдельные выборки по героям без дополнительных действий — использовать для этого такую штуку как Views, если база их поддерживает и позволяет редактировать. Но вообще, во всех нормальных менеджерах баз данных есть возможность выборки с фильтрацией по содержимому поля, и лучше использовать их.

Разделить мир на ячейки, обновлять и отрисовывать только те сущности, которые находятся от игрока на определенном радиусе. Не знаю что там тебе и откуда нужно подгружать, 100 на 100 юнитов это небольшая сцена, все ее содержимое спокойно будет помещаться в оперативной памяти, с диска там ничего подгружать не нужно. Гугли spatial hashing, выбирай алгоритм, который тебе лучше подходит

Когда объекты крупные в сцене то пользователь видит их скорость кадров. Можно ставить 60 fps.
Когда пользователь смотрит на объекты размером с пиксель - то и не нужно их обновлять часто.
Сделай хоть 10-15 fps и будет норм.

Ну тоесть я как-бы взял level of detalization но применительно не к пространству а ко времени.

Если простым языком, опция Render Mode используется следующим образом:
1) Overlay - стандартный вариант, когда у вас одна камера на все задачи;
2) Camera - показать специфический интерфейс для определённой камеры;
3) World - вообще отвязать от камер, сделав объектом сцены.

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

Далее размер зоны Canvas-а на сцене. В режиме Overlay он огромен неспроста - он имеет размер экрана. Например, если эран 2960:1440, то и канвас будет иметь такой размер, почти 3к в ширину и 1.5к в высоту. Но на камеру он будет накладываться так, чтобы вложиться в её границы. Единственное неудобство в том, что чисто визуально сложно представить, как это дело будет выглядеть в игре. Чтобы каждый раз не прыгать в плеймод, можно просто вкладку Game расположить где-нибудь рядом. Ну или делать как мои знакомые. Заметил среди знакомых тренд, что они в простых гиперказуалках просто ставят режим Render Mode - Camera и сразу так работают. Сценический размер и положение канваса подстраиваются под камеру и им удобно.

Касательно масштабирования, обычно разработчики выбирают эталонное разрешение экрана, которое указывают в Canvas Scaler (рядом с Canvas на одном объекте). Там опция - UI Scale Mode, режим Scale With Screen Size. А ползунком ниже указывают как именно интерфейс будет зависеть от ширины и высоты. Затем нужно перейти во вкладку Game и там слева вверху есть выпадающий список с размерами экрана. Нужно выбрать или создать и выбрать то же самое разрешение.

Если вы хотите, чтобы определённый объект был привязан, например, к левому верхнему краю экрана, этот объект обязательно должен иметь RectTransform. В компоненте вы можете заметить вот такую фичу:

Открываем, согласно подсказке жмём Shift+Alt и нажимаем на левый верхний квадрат:

Осталось только в самой компоненте задать такие Pos X / Pos Y, чтобы вам нравились отступы от левого и верхнего краёв экрана.

Делать основной канвас дочерним игроку - плохая практика. Максимум на уровне префаба и сразу вытащить из игрока при спавне, но и это хз зачем, если её можно сразу поставить на сцену и не мучаться. Если у вас много сцен с таким канвасом, то просто сделайте сам канвас префабом и меняйте его содержимое не для конкретной сцены, а на уровне префаба. Собственно, так обычно и делают, разве что у вас всего 1 сцена игры, на которой вы спавните префаб нужного уровня.

Осталось лишь придумать как привязать этот интерфейс к игроку на уровне скрипта. Много кто использует для этого синглтон, кто-то при спавне игрока просто ищет специфический скрипт на сцене и сохраняет на него ссылку. Это реально неплохие варианты.

Когда камера вложена в объект игрока, она меняет свои позиции относительно игрока, а не мира. Соответственно, когда игрок не в 0, то камера будет отдаляться от игрока и показывать что-то совсем другое.

Так как ваша сетка не движется, то единственное, чем она ваш комп грузит - это добавляет свои данные в Draw call Batching. А учитывая специфику этого процесса, выгоднее сделать меньше больших, чем больше маленьких. Но речь идёт о каких-то безумных числах, вроде 10 тыс клеток при условии, что они будут ВСЕ у вас на экране в границах активной камеры. Но даже так, пока изменение тайлмапа (большими порциями за раз) не происходит в рантайме вы не словите каких-то ощутимых лагов.
Если же говорить про оптимизацию процесса, то выгоднее сделать более мелкую сетку по одной простой причине - вы можете рисовать как одной клеткой за раз, так и их энным количеством (как буд-то вы рисуете более большой сеткой), а вот уменьшить исходно большую если и возможно, то я хз как.

Есть несколько рекомендаций:
1. Используйте асинхронный код. Что-то типа такого:

public static async void SetXMLValue(string pathToXMLFile, string nodeName1, string nodeName2, string nodeName2Value) {  
    TextAsset textAsset = Resources.Load<TextAsset>(pathToXMLFile);
    XmlDocument xmlDoc = new XmlDocument();
    xmlDoc.LoadXml(textAsset.text);
    XmlNode node = xmlDoc.SelectSingleNode("/" + nodeName1 + "/" + nodeName2);
    node.InnerText = nodeName2Value;
    await File.WriteAllTextAsync(Application.dataPath + "/Resources/" + pathToXMLFile + ".xml", xmlDoc.OuterXml);
}

2. Используйте более быстрые методы чтения и записи XML. Вместо стандартных методов XmlDocument.LoadXml() и XmlDocument.OuterXml вы можете использовать XmlReader и XmlWriter. XmlReader позволяет читать XML файлы по мере их поступления и не хранить их в памяти целиком, что позволяет сократить время чтения. XmlWriter позволяет записывать XML файлы по мере их создания, что позволяет сократить время записи.
3. Используйте кэширование данных в памяти. Вместо того, чтобы каждый раз читать настройки из XML файла, вы можете загрузить их в память при запуске программы и хранить в памяти. При изменении настроек вы можете обновить их как в памяти, так и в XML файле. Это позволит избежать чтения XML файла каждый раз при обращении к настройкам.
4. Используйте более быстрый способ доступа к файлам. Вместо использования метода File.WriteAllText() вы можете использовать методы доступа к файлам, которые более быстры и оптимальны для Unity, например, System.IO.MemoryMappedFiles.
5. Если вам и правда так припекло использовать XML, вы можете немного ускорить процесс, оптимизировав его структуру. Например, выделить для каждой локали по отдельному файлу. Но лично я вам советую познакомиться с форматом JSON, тем более в юнити есть хороший нативный инструмент JsonUtility, а в шарпе newtonsoft.json.

Но если ваша цель не решить интересную задачу, а просто иметь под рукой хороший инструмент, советую вам не мучать себя, а просто воспользоваться пакетом Unity.Localization. Ну или если у вас есть лишних $45, то пакетом i2 в ассет сторе.

1. Зная размерность сетки, можно руками поправить координаты в Transform
2. Можно перетащить префаб во вкладку Hierarchy, а затем перетащить на нужное место через Move Tool с зажатой Ctrl
3. Можно поместить сразу как надо, и, держа открытой вкладку "Edit >> Grid and Snap Settings...", нажать кнопку "All Axes", и если оно неправильно округлило, то используя способ 2, дотянуть немного.
4. Можно самому написать скрипт, типа такого:

1. Убираете Capsule Collider 2D, вешаете Box Collider 2D
2. Делаете коллайдеру скругление (да, там есть такая опция), чисто чтобы за углы не цеплялся
3. Делаете не одну большую точку, а маленьких штуки две (по краям) или три (одна в центре, если у вас есть узкие платформы)
4. Ищете землю условием ИЛИ. Profit

Важно, чтобы края поиска земли не доставали до левого и правого краёв коллайдера и при этом был включен режим Rigidbody2D collision detection = continuous. Тогда всё будет работать отлично.

Если это планируется как клиент серверное приложение(mmo)то это в корне неправильно, если это просто однопользовательская игра то не важно

Классы надо называть так, как завещано патриархами программирования - с использованием существительного. Ваше String - скорее прилагательное, вы забыли указать, что именно делает этот класс со строками. StringParser? StringContainer?
StringTester, наконец, по тому огрызку кода, что тут приведен :)

Писать пространство имен полностью, что не очень красиво AnotherPHPProject\Strings()

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