cicatrix

Обычно аутентификация происходит при установлении сеанса, состояние устанавливается как свойство этого сеанса. Естественно, после перезапуска приложения, сеансы новые и надо производить проверку authentication cookie заново.

В своё время делал довольно прямолинейно. На лабиринте генерил сначала путь из точки А в точку Б случайным образом и помечал эти клетки как проходные. А уж потом вокруг генерировал случайным образом весь остальной лабиринт.

Ну, а ошибку загуглить?
Startup.cs покажи

Самое главное: Должны быть очень ясные и недвусмысленные доказательства того, что код действительно твой.

Если твой работодатель использует код сейчас бесплатно, должно быть хоть какое-нибудь EULA или договор-оферта, которую работодатель акцептовал бы самим фактом использования. При увольнении надо уведомить работодателя об изменении EULA и зафиксировать акцепт новой оферты. Идеально было бы, если бы вообще был какой-никакой договор (пусть за 3 копейки), в котором работодатель приобретал бы срочное право использования. Думаю, протащить под шумок такой договор (особенно, если сумма смешная) будет просто. Твоим представителем может быть какой-нибудь родственник или юр. лицо, если не хочешь палиться сам.

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

Справедливости ради стоит отметить, что много современных игр состоят из 2 основных частей.
Первая - это т. н. "движок", он отвечает за визуализацию моделей, обработку ввода, сеть, просчёт физики и пр. Он действительно обычно скомпилирован в машинный код и его дизассемблирование очень затруднено.
Вторая часть - это игровая логика, она уже отвечает за сценарий, определяет, что произойдёт в игре на определённые действия игрока, открывает уровни, изменяет параметры самой игры, и пр.
Очень часто, игровая логика описывается скриптами, которые доступны для чтения.
Разумеется, это не всегда так, но очень часто игровые студии не имеют ресурсов или желания для разработки собственного движка, а сосредотачиваются на самой игре.
Огромное количнство игр, даже ААА сделаны именно так. Думаю, движки Unity и UnrealEngine в совокупности отжирают более половины мирового рынка игр.

Управление пространствами имён в XML-документе

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

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

Зайди в метод InitializeComponent(), который вызывается из конструктора формы, и там увидишь привязку несуществующего обработчика событий.

А по какому протоколу работает связь клиент-сервер?
Если TCP, то ведь можно просто опрашивать состояние соединения и держать его всё время ESTABLISHED. Правда, такой подход годится для относительно малого числа клиентов. Если их счёт пошёл на тысячи, то да, нужно опрашивать периодически.

Любой "чит" представляет собой программу, которая находит в адресном пространстве памяти, выделенной под игровой процесс, необходимые данные и видоизменяет их.
Собственно, сам по себе чит соорудить дело нехитрое. Найти работающий процесс, прошерстить его память, найти нужные данные и записать на их место другие (кол-во жизней, патронов и пр).
Просто - да, но дьявол в деталях. Поиск необходимой вам информации - процесс долгий и муторный. Распространённые "универсальные" читы вроде CheatEngine работают путём сравнения состояний до и после изменения, тем самым, сужая круг поиска. Но это неоптимально. Нормальный чит - продукт реверс-инжиниринга игровой программы, где ты уже точно знаешь, как игра распределяет в памяти свои ресурсы и как их искать.
Наличие исходного кода игры сильно помогает, но только отчасти.
Разумеется, разработчики игр знают обо всех этих приёмчиках и стараются максимально затруднить подобные действия. Одним из самых эффективных методов защиты является сохранение состояния игры за пределами машины игрока (на сервере разработчика). Нормальный разработчик просто не учитывает или игнорирует некорректное состояние клиентской машины. Внедрить чит игру с такой архитектурой нереально. Но часто разработчики идут на компромиссы, чтобы не хранить вообще всё на сервере, часть данных размещается на машине клиента. С этим уже можно работать, но алгоритмы на сервере направлены на поиск несоответствий в состоянии клиента и последующие санкции, если игрок будет уличён в использовании читов.
Ну и есть конченные разработчики, позволяющие изменять состояние клиента как угодно. Но обычно такие игры просто теряют своих клиентов потому что из-за обилия читеров становится невозможно играть.