GmDvlpr

create trigger <trigger_name> before insert on <table_name>
for each row
begin
if new.val = '' then
signal sqlstate '45000';
end if;
end;$$

и аналогичные триггеры для before delete/before update

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

Меньше места в UI занимает)

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

Ещё в интернете есть коллекции готовых бесплатных хорошо нарисованных ассетов. Пусть они, может быть, не вполне подходят вам по стилистике или задумке, но не придирайтесь. Главное - сделать что-то работающее, более-менее играбельное. Если вы на это способны и не тонете в бесконечных метаниях перфекциониста, которому не дают приступить к делу раздумья о том, как сделать все "правильно", то все у вас получится. Найдутся соратники, которые захотят вам нарисовать персонажей, найдутся программисты, которые захотят к вам в команду, чтобы кастомизировать ваших персов...

Главное - это умение выделить главное и сконцентрироваться на нем.

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

Простите, а что у нас с математикой уровня 4-5 классов (простое умножение целых чисел)?

например, максимум в стаке будет тип переменной byte, т.е. 255 штук определенного прдемета(пусть, этот предмет называется палкой).

1 байт

А теперь, вот в чем вопрос, сколько максимум может быть этих палок если игроков свыше 100к в онлайне каждый день и у каждого будет 255 палок в инвентаре

100к * 1 байт = 100.000 байт = 100 килобайт.

а ведь еще можно выкидывать их на землю и они не будут удаляться, а будут лежать, пока их не возьмут.

ну на каждый предмет вне инвенторя можно выделить пару байт на координаты. Ну давайте каждый выкинет по 100 предметов, умножаем на 100.000 онлайн, получим 10 000 0000 - 10 мегабайт.

Ну давайте предположи, что на хранение одного предмета будет уходить не 1 байт, а 5 байт или 10 байт, умножаем 10 мегаюбйт на 10, получаем 100 мегабайт. Сколько у вас на домашнем компе оперативки? Фаерфокс может больше выжрать.

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

Каждая точка в зависимости от точности, занимает разное кол-во памяти:
float это 4 байта, для double 8 байт

Возьмем к примеру меньшую точность float, чтобы сэкономить память, тогда координаты одной палки займут:
XYZ *4 байта = 12 байт

У палки есть id, пусть он будет integer 2 байта от 0 до 65536 (256 byte * 256 byte) т.е. разновидностей предметов в игре у вас будет максимум 65536, это не мало.

Дано 100000 игроков
Размер рюкзака 0-255 (максимум 256 предметов)
Рюкзак это список предметов с их id, к примеру:
id 1 = палка
id 390 = лопата
id 27 = яблоко
будет выглядеть как: [1, 390, 27]

Если все палки лежат у игроков:
100000 * 256 * 2 байта (id палки) = чуть более 50 мегабайт

Если все палки лежат на земле:
100000 * 256 * 2 байта (id палки) * 12 байт (XYZ) = чуть более 600 мегабайт

Можно сделать хак и описать координаты палок как квадраты на местности, к примеру у вас есть карта:
16 * 16 километров = 256 км² (1000000 м²) каждый квадрат = 1 км²
1000000 / 256 = каждый квадрат 62.5 x 62.5 метров
/ 256 = каждый квадрат 3.9 x 3.9 метра, как туалет в макдоналдс
/ 256 = 20 x 20 см

В итоге чтобы запомнить в каком квадрате лежит палка мы уложились в 4 байта [255,255,255,255].
id первого квадрата = [0,0,0,0]
id последнего квадрата [255,255,255,255]
Расположить ее на оси Z, чтобы не хранить высоту уже дело техники.

Теперь если все игроки выкинут свои палки на землю, то это займет:
100000 * 256 * 2 байта (id палки) * 4 байта (квадрат) ~ 205 мегабайт, если все держать в памяти, то с этим справится любой сервер за $5.

Любые вопросы в комменты.

Во-первых, ознакомьтесь с моделью памяти C#, как работает сборщик мусора, какие есть кучи, как они заполняются и опустошаются, как работать с IDisposable, using, и оборачивать unmanaged ресурсы.

Потому что на самом деле есть выбор: делать сервер на .Net либо на LLVM. В принципе, на LLVM garbage collector свой, и напридумать модно много чего интересного.

Во-вторых вам нужно разобраться в архитектуре ОС. Дело в том, сервер не может "рухнуть" из-за каких-то абстракций, он может начать захватывать слишком много памяти, и в зависимости от настроек ядра и окружения вашего Linux, в котором запущен процесс сервера, могут происходить разные вещи, которые ограничены лишь с вашими желаниями.

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

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

1 инстанс сервера может держать 100к соединений, но ваш игровой room может обслуживаться и многими нодами, не обязательно одной. Более того, у вас может быть не одна nosql база данных, а целый кластер.

Другими словами, вам стоит ознакомится с концепциями ACID, кластеризацией и микросервисной архитектурой. В завершение можете почитать про Kubernetes.

Когда вы проработаете эти темы, вы сможете уточнить свой вопрос до конкретных технических требований и сами сможете на него ответить.

PS: Касательно максимума соединений к абстрактным коням в вакууме, считается, что один демон, держащий 10к соединений - это граница highload. В конкретных цифрах обычно все сводится к доле процессорного времени за интервал допустимой задержки ответа сервера на конкретной платформе включая конкретное железо и конкретную сетевую карту + тесты доступа из точек по всей планете.

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

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

теперь к мелочам.

• найдите документацию или примеры на форуме про RaycastHit hit;
  там внутри hit - куча информации во что вы лучом попали и по хороше добавить бы проверку что попали именно в нужный объект, мало ли что там еще слоем или тегом будет помечено случайно.
  
• саму проверку "скастовать луч" - вам бы делать только по клику/Down/Up мышкой (смотрите в сторону Input)
  
• для работы с 2D колайдерами есть отдельные реикасты Physics2D. чтоб избавится от костылей с 3d коллайдерами))
  
  

На враге должен быть коллайдер с флагом триггер.

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

В том и дело что ты новичок, новичкам Всегда трудно.

Можно вспомнить как любой из нас начинал учить таблицу умножение в школе, сначала сложно очень, учим и не можем выучить, путаемся забываем, но это сначала, а сейчас спроси у себя 5 на 9 и ты сразу скажешь 45.

Так что дело в опите и практике, чем больше практикуешься тем лучше запоминается, главное не останавливаться со временем все получится!

"Сначала всем сложно"

Можно, но в 90% будут вопросы и будете возвращаться к учебнику.

Если вы просто сидите и просто знаете - то это бесполезно. Практикуйтесь. Забейте на юнити, создайте консольный проект и реализуйте что вам будет интересно. Да хоть игру в виселицу, хоть текстовый квест.

Я бы сказал вообще так. Без уверенного знания языка лезть в юнити не стоит. А уверенное знание языка - это когда на 90% ваших задач вы не думаете "а как это написать на сишарпе".