Saboteur

Нельзя рассчитать просто "стабильную экономику".

1. Критически влияет онлайн - от количества игроков может зависеть и покупательная способность, и востребованность отдельных профессий и количество конкуренции.
2. Экономика не может быть идеальной поскольку не может быть идеальным баланс игры. Вам нужно будет иметь возможность не сильно нарушая геймплей влиять на баланс игры, подталкивая игроков к тому направлению, которое вы хотите сейчас развить.
3. В дополнение к пункту 2, реализовать игру, в которой все аспекты геймплея интересны всем игрокам - также невозможно. Кому-то нравится больше одно, кому-то другое. В зависимости от вашего онлайна и аудитории игры, уже по факту можно будет видеть какое направление у вас используется больше и как его менять.

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

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

Нет никаких вариантов. Надо иметь понятие, как это делать.
Подключать "стандартную" библиотеку языка C напрямую к Скриптовому языку - невозможно.

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

Подключать библиотеки из другого языка нельзя.

На питоне можно писать бэкенд и для игр.
Просто у вас вопрос не правильный.

На самом деле у вас вопрос типа "если я пишу на питоне, сложно ли мне будет освоить unity".

По существу, игры являются такими же программами как сайты или бизнес-приложения.

1. Издание видеоигр появилось в цифровой век. Те, кто непосредственно этим занимается, вряд ли будут писать что-то в твердом виде.
2. Непосредственным продуктом является не текст в видеоиграх, а сама видеоигра, которая выходит в электронном виде, а не напечетанном.

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

Очень сложно.

Много специалистов. Количество зависит от подробного ТЗ и времени на разработку. Мало специалистов - дольше, много - быстрее, но не все можно распарралелить.

Разработчики, тестировщики, архитекторы, менеджеры, обслуживающий персонал.

Если исходники - проприетарны, их попытаться купить можно только у автора-владельца. Но не факт, что владелец согласится.

Если исходники open-source - они уже доступны где-нибудь в интернете, например github, sourceforge, лично на портале проекта, в общем по-разному.

Первый необходимый навык - умение пользоваться поиском.

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

План такой:

* Ищете вакансии в gamedev
* Смотрите требования, выбираете какое направление интересно вам - андроид/web/C++/QA
* Учите то, что указывают в вакансиях
* как выучите - пишете резюме и бомбардируете эти вакансии.

5-10 (или если все плохо 50-100) собеседований и профит.

P.S. Ну и еще, геймдев гораздо меньше, чем разработка вообще, поэтому вполне можно начать не с геймдев, а с любой разработки.

Хочу начать с чего-то простого (например. сделать 2D игру) и хочу сделать что-то интересное и чтобы приносоло прибыль на следующие разработки, начинаю с 2D, так как невозможно одному сделать

Вы вообще не с той стороны подходите к вопросу.
Если вы хотите заработать и получить прибыль - УСТРОЙТЕСЬ НА РАБОТУ, ГДЕ ПЛАТЯТ ЗАРПЛАТУ.

Если вы хотите написать что-то технически крутое, то 99% что вы не сможете это продать.

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

Программисты слишком часто думают, что они умнее всех, и знают как заработать.. Но это далеко не всегда так.

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

Движок от minecraft написан на java, можете видеть в чем разница с точки зрения возможностей.
Основная проблема - работа с памятью, которая в более низкоуровневых языках типа с/c++ под контролем программиста, следовательно производительность предсказуема.

Непонятно что такое "самостоятельная игровая среда".

Суть большинства игровых сред - либо удобная дистрибьюция, либо удобная стандартизированная среда разработки/API/фреймворки, которые позволяют большому количеству разработчиков создавать продукты и таким образом наполнять список приложений.

А такие вещи как Raspberry PI и др, лучше использовать не как самостоятельную среду, а как платформу для создания продуктов, типа игровых автоматов, различных активных компонентов (например квест-комнаты, в которых необходимо создавать подвижный и программируемый антураж) - то есть это готовая среда для embedded.

Зависит от правообладателя франшизы.

Например Роулинг разрешает писать фанфики на вселенную Гарри Поттера, если вы не преследуете коммерческую выгоду.
А Дисней за изображение Микки Мауса может в суд подать.

P.S. Автор и правообладатель - не одно и тоже. Например Джон Кармак - активный последователь опенсорса. Но вот права на IDSoft сейчас принадлежат не ему, и такой прикол, что исходный код некоторых продуктов, которые он сам опубликовывал - подпадает под авторское право.

Просто почитайте документацию и все.
https://twinery.org/wiki/twine1:reference

Например:
https://twinery.org/wiki/twine1:syntax

Более сложные вещи - нужно писать на javascript. Twine и другие штуки обычно работают не так гибко, как хочется, поэтому сперва читаешь документацию, понимаешь что умеет этот движок и принимаешь решение подходит он тебе или нет.
В Twine если чего-то нет, можно допилить javascript, который вы не знаете, поэтому придется обходиться без хотелок, либо учиться.

Вы не знаете программирование но рассчитывать на поддержку в виде "почитайте за меня документацию" нет смысла. Хотите ничего не делать, только писать сюжет - напишите и наймите на фрилансе программистов. Тут несложная задача.

Какую-нить простенькую веб-браузерку написать на перле можно легко и быстро.
Но Perl не был рассчитан на разработку игр, в основном на парсинг текстовых данных - в этом он до сих пор очень крут.
Писать на перле игру - не стоит.