Алексей Елецкий

>Я думаю, а можно ли продать уже готовые наработки, идею и все вещи что с ней связаны, чтобы более опытные люди за него взялись и развивали этот "бизнес"?

В нашем мире продать можно всё, но не все могут это сделать :-)

В большинстве случае продать наработки одиночки (а тем более идею) нереально. Есть шанс только, если это уникальная технология (допустим, новая архитектура нейронной сети).

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

А втюхать всё можно, но лучше так не делать.

Full Stack - это абстракция, за ним может скрываться очень много чего. И бывает он не только в вебе :-)

Как минимум, для веба:

- HTML5 + CSS
- JavaScript + любой популярный фреймворк.
- Любой язык для бэкенда: Python, JavaScript, Go, etc. Вообще, бэкенд сейчас на всём пишут.
- Любая технология автоматизации деплоя (опционально, но лучше иметь представление).
- Любая база данных + её язык запросов.
- Любой веб-сервер (его конфигурация, опционально)

Но лично я не рекомендую учиться именно сразу на Full Stack. В итоге знания будут очень неполные из-за большого фронта обучения. Лучше выучить одну чать, но хорошо. Это позволит начать немного понимать и вторую часть, после чего её можно будет целенаправленно выучить.

Кроме того. Frontend довольно стандартен по технологиям, бэкенд очень различается. Можно стать Full Stack разработчиком со знанием бэкенда, который никому не нужен.

Простой путь: учить фронтэнд (глубоко) и потом догоняться бэкендом под нужды текущей работы.

Хардкорнее: учить бэкенд и постепенно перенимать функции фронтенда на текущей работе.

Тут две задачи стоит:

- обезопасить общение между клиентом и фронтендом
- обезопасить общение между фронтендом и бэкендом

Первое делается известными методами, я думаю их перечислять не надо.

Второе можно делать по-разному:

- можно организовать закрытую сеть между всеми серверами (варианты разные: от vpn, до физически отдельной сетки).
- можно делать https соединения, проверяя сертификаты друг друга
- можно подписывать сообщения, например с помощью https://en.wikipedia.org/wiki/HMAC

Можно даже всё вместе сделать - зависит от уровня паранойи.

Передавать креды пользователя в открытом виде, само собой, нельзя. Нужно обезопасить само соединение (например, https использовать) или сами креды (шифровать ключом, известным только фронтенду и бекенду).

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

А так можешь C# пробовать, он и в геймдеве пригодиться, и вне геймдева используется.

Если ушёл по ссылке с Вашего сайта, то можно. Простейшее решение — подмена всех ссылок на промежуточную (можно даже с предупреждением «осторожно, вы покидаете сайт»).

Любой другой переход со страницы отследить нельзя.

Теоретически, за этим может следить расширение браузера, но оно должно ещё и что-то полезное делать, иначе не поставят :-)

предевременная оптимизация — ЗЛО
KISS

Вы хорошо описали, что хотите сделать, но ни словом не обмолвились о том зачем Вы это хотите:

- какого типа планируется взаимодействие игрока с сервером?
- какие предполагаются нагрузки? Средняя, пики…

Без знания ответов на эти вопросы, ответ на Ваш вопрос один: делайте как Вам приятно. Потому что критериев выбора архитектуры не приведено.

Вот универсальное правило принятие решений: «Х решает какую-то проблему? Если решает, делаем Х, если не решает — не делаем.»