Событию может быть присвоен null - оно от этого не кидается эксепшнами. А вот проверить webBrowser1 и Document на null стоит. Отладчик и try-catch в зубы и вперед.
Внезапно - любой функционал делается написанием кода.
По вашему вопросу сказать прям больше нечего. Ну можно добавить что обычно делается дерево квестов (прям как структура данных) с ветвлением в зависимости от результатов. Т.е. делаете сущность "квест", она умеет проверять свой статус, и делаете контейнер, который знает о всех ветках и умеет переключать текущий квест.
Кладете все объекты как дочерние в один rootObject. Этот rootObject делаете DontDestroyOnLoad. НА него же вешаете скрипт, в массив которого загоняете все нужные объекты.
После загрузки сцены и массив цел, и объекты.
Для изучения именно шарпа юнити плохо подходит - там старая версия языка (вроде с 2018 обещают новую).
Прикол еще в том, что при создании игры в юнити вы будете намного чаще использовать особенности именно юнити, а не шарпа. Особенно с ее компонентной системой.
Ну так раз у вас C# - то и юзайте ASP.NET/ASP.Core, и бд соответствующую этому стеку.
Пойдет легко и просто, в целом. Поищите примеры какого нить REST на ASP
В цикле for - три блока, каждый из которых не является обязательным. Может отсутствовать и инициализация, и условие (тогда оно всегда true считается), и пост-действия.
У меня, как, наверное, и у многих, очень часто встречается такая проблема, что я представляю себе, как я написал бы код на человеческом языке, а на C# - нет
Нет, такой проблемы у программистов нет. Учитесь алгоритмизировать.
Что вы мне посоветуете?
Посоветую начинать с более простых задач. Ну и заодно пройти десяток-другой уроков как по юнити, так и по шарпу. Но строго - с отдельной кучей практики.
1) Решение - это набор проектов. Так удобнее решать зависимости и одновременно делить на модули. Крайне актуально для больших проектов.
2) Можно. В двух экземплярах VS. В рамках одного экземпляра по моему можно только 1 решение держать.
3) Вкладки называются так же, как называются файлы (внезапно!) Почему именно Program - ну потому что так решил разработчик.
Давным давно, в эпоху диалапа, некоторые браузерные игры делали так.
Юзер качает архив, распаковывает его у себя на винте, а в свойствах профиля указывает свой локальный путь к этой папке. И сайт потом урлы картинок строил с учетом этого пути.
Это чисто так, в копилку методов.
Например сравнить его с null, причем и напрямую, и через ReferenceEquals.
Но, стоит помнить, что объект уничтожается в конце фрейма, поэтому лучший метод - это в OnDestroy объекта уведомлять какой то контейнер, что объект уничтожается, и потом чекать уже по контейнеру.
Если GetDamage - это часть MonoBehaviour (а судя по всему это так), то немного непонятно, где вы ожидаете увидеть увеличение переменной. Вы же весь GO уничтожаете, вместе с инстансом скрипта.
