Что же с нами стало

вы действительно думаете, что сможете перенести все прелести сски?

вы никогда не сможете перенести в другую игру весь сок игры.

вы никогда не перенесете наслаждение от робаста, наслаждения от набегов на бриг, от ерп, от всего угодно.

это невозможно.

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

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

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

одно удовольствие в одиночку убивать трех и более человек, а они потом пишут на тебя банхим, да, ты получаешь бан, но это было приятно, правда?

одно удовольствие пилить лимитки, а потом убивать с помощью них нюку, делая аллаху акбар (я помню охуенных лимиткоделов, парни, я с вами выносил целый отряд нюки)

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

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

ССка - игра, в которой ты получаешь одно удовольствие.

вот сука, хоть один скажите мне, сможете вы это все перенести? сможете вы создать то, что ни одна студия геймдева не создала за хуеву тучу лет?

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

я буду сметься с каждого ерп, с каждого ньюфага, с каждой неудачной нюки, с каждого трапа с хуевым флавором. Я БУДУ СМЕЯТЬСЯ С НИХ ВЕЧНО.

ДА БЛЯТЬ, ХОТЬ ОДИН ХУЕСОС, СКАЖИ МНЕ, ХОТЬ ЧТО-ТО ТЫ ИЗ ЭТОГО СМОЖЕШЬ ПЕРЕНЕСТИ В СВОЮ НОВУЮ ХУЕВЕНЬКУЮ ИГРУ, КРОМЕ ЕБАНОГО КОСМОСА И АТМОСА?

ССКА ЭТО НЕ ПРОСТО КОСМОС, ССКА ЭТО НЕ ПРОСТО АТМОС, ССКА ЭТО БЛЯТЬ ТО, ЧТО ТЕБЕ ДАЛ БОГ.

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

Тот момент когда движок Х*й пойми какого года лучше новых, которые не могут повторить возомжности Бьонда

Protos-Zerg (26 June 2017 - 10:08) писал:

Тот момент когда движок Х*й пойми какого года лучше новых, которые не могут повторить возомжности Бьонда

Это не бъенд такой классный, это ремейкать его никому не усралось, потому что не окупит вложений НИКОГДА

Сам Бъенд-то жив по таким же удивительным соображениям, что и Анимус.

Переписывать большую часть кода из ДМ в другой язык смысла просто нет. Большая часть кода выполняется редко и не является тяжелой.

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

Вот на этот низкоуровневый API и нужно переписать вещи, где важна производительность.

Бъонд всегда будет лагать в этом плане именно потому, что он не позволяет низкоуровневой работы, самое низкоуровневое, что у него есть - это импорт DLL и оверхед от вызовов функций из DLL никто не знает.

Это также, как и в Питоне: язык, помимо всего прочего, лагает из-за динамической типизации. В ДМ тоже динамическая типизация у вещей. Но в отличие от ДМ на Питоне есть библиотеки, которые позволяют оптимизировать код и сделать его дохуя быстрым, например Numba или компилятор Cython. Помимо этого, даже стандартный интерпретатор CPython позволяет связать код к кодом на C.

Никто не будет спорить, что, например, библиотека Numpy пиздец какая быстрая. В ДМ же вы (практически) целиком ограничены движком, который не предназначен для тяжелых вычислений.

Идеальный подход был бы не переписывать ССку на другой язык, а запинать разрабов Бъонда чтобы они реализовали возможности для работы с другими языками.

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

Вон, лагиус римейк пишет, отлично пишет, и не на чем попало, а на плюсах.

Dean (26 June 2017 - 04:59) писал:

Очень грустный код на бьенде, для модификации нужно сожрать бочку говна.

Даже банально новую станцию собрать очень геморрно.

Пройдите нахуй, бьендокод чрезвычайно простой, проще только петон, если ты умеешь в хоть один язык - осилить бьенд и код станции (не атмос со староТГ, а простые вещи) не составит труда.

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

И вообще, сейчас уже сама мысль о римейке кажется нахуй не нужной.

Нет, серьезно, зачем? Лаги, то, за что всегда пинали бьенд? Очнитесь, лаги победили года полтора-два назад убероптимизацией и фичами бьенда, нету лагов!

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

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

А в остальном бьенд совсем неплох.

Писать код легко и не требует умений.

Инфраструктура есть.

А самое главное - есть уже вся станция, а это очень, очень, очень много кода. Это так много аспектов, фич, мелкофич и хитростей, что представить сложно.

Много кода, слишком много.

Самый активный ремейк на юнити из тех, что я знаю это https://github.com/u...on/unitystation

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

Dean (26 June 2017 - 06:04) писал:

Но ведь я не спрашивал, почему нет ремейка.

Я спросил, почему никто не делает ничего нормального на юнити.

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

UPD

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

MR_R (28 June 2017 - 03:17) писал:

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

UPD

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

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

Странно что не появилось нормального ремейка в виде рогалика на спрайтах, до уровня Byond это работа 60 человекочасов до альфы +100-200 до беты. Особо сложного ничего нет. И серверный специалист не нужен, можно в начальной стадии вообще по UDP принимать текстовые команды, также как это делает Byond и по UDP отправлять на клиент WorldState в пределах отрисовки пользователя + 1,  пишется 15 минут, при частоте обновления в 10Гц, в пике будет жрать 1Мбит/с.  Когда прижмет можно и нормальный, но простой код написать, но тут надо знать детали реализации уже, думаю в пике до 1-2Мбит/с на 30 пользователей. Отрисовывать на стороне клиента - SDL за глаза. Самая большая большая проблема - это атмос, надо придумывать алгоритм с малым количеством промахов по кешу.

Час, два вечером в качестве хобби одному человеку и за месяца 3-4 можно написать вполне играбельный экземпляр. Но тут таких людей нет. [Тут барабаны и другие спецэффекты]

RecursiveRoar (01 May 2018 - 06:04) писал:

Странно что не появилось нормального ремейка в виде рогалика на спрайтах, до уровня Byond это работа 60 человекочасов до альфы +100-200 до беты. Особо сложного ничего нет. И серверный специалист не нужен, можно в начальной стадии вообще по UDP принимать текстовые команды, также как это делает Byond и по UDP отправлять на клиент WorldState в пределах отрисовки пользователя + 1,  пишется 15 минут, при частоте обновления в 10Гц, в пике будет жрать 1Мбит/с.  Когда прижмет можно и нормальный, но простой код написать, но тут надо знать детали реализации уже, думаю в пике до 1-2Мбит/с на 30 пользователей. Отрисовывать на стороне клиента - SDL за глаза. Самая большая большая проблема - это атмос, надо придумывать алгоритм с малым количеством промахов по кешу.

Час, два вечером в качестве хобби одному человеку и за месяца 3-4 можно написать вполне играбельный экземпляр. Но тут таких людей нет. [Тут барабаны и другие спецэффекты]

Может таких ремейков не появилось, потому что все не так просто, как тебе кажется?

WorldState по UDP

Просто гениально. Может напишешь, раз так все просто? Всего лишь 15 минут. Впрочем не спеши, давай посчитаем вместе:

Значит говоришь 1 Мбит/с на игрока? Это 131072 байт/с. При частоте обновления в 10 кадров получается, что один кадр у тебя занимает 13107 байт. Обзор игрока - 15 тайлов. Если взять +1 (в обе стороны), получается 17 тайлов. Делим, получаем что у тебя выходит 45 байт на один тайл, в среднем. И сколько объектов ты сможешь описать с помощью 45 байтов? А сколько их реально на станции?

А что такое объект? Каждый объект - это спрайт (бывает не один, человечек - это 30 спрайтов), куча свойств, которые важны для отрисовки (цвет, сдвиг по пикселям, состояния анимации и прочий треш) плюс название, различные действия которые можно с ним делать и т.д. Как это все уместить в 45 байт на тайл? А это уже 1 мбит/с на игрока! То есть если у тебя 50 игроков, то тебе нужен стабильный коннект на отдачу 50 мбит/c минимум.

Окей, можно придумать какие-то системы кэширования, нумеровать объекты IDшниками и отправлять сами объекты не каждый раз, а только в первый, но тут мы плавно переходим от UDP к TCP + огромному вороху проблем, которые нужно будет предусмотреть. Впрочем, если у тебя еще осталось желание, ты можешь написать это за 15 минут и скинуть Лагиусу вот сюда: https://github.com/griefly/griefly . А то он бедный сидит уже, несколько лет развлекается. Просто никто ему не сказал, что все так просто.

Ладно, если WorldState по UDP не зашло, давай "нормальный, но простой код" напишем? Так, с чего бы начать? Значит WorldState отправлять не можем - давай отправлять начальное состояние и диффы?

Значит берем мир вокруг персонажа, отправляем ему начальное состояние тайликов, а дальше изменения? Звучит как план. Вот только дальше начинаются проблемы с тем, что тебе нужно, как минимум, как-то фиксировать эти изменения и определять игроков, которым они будут актуальны, чтобы отправлять их только им. Начинаются проблемы с синхронизацией всего этого добра на сервере, начинаются проблемы с "теорией относительности", о которой Valve целые статьи пишет, начинаются проблемы с предсказаниями на клиенте. Решение всех этих проблем - уже на целый магистерский диплом потянет в каком-нибудь ITшном вузе, а если завернуть все это в либу, то можно и продать ее за кучу денег, между прочим.

Короче много вас таких, у которых все просто, только вы либо ничего не делаете, либо появляются ПАБГи. Собрали кучу готовых кусков, склепали вместе, получилось говно - продали, а как оно там внутри работает, а хер его знает.

Epicus (01 May 2018 - 17:37) писал:

Может таких ремейков не появилось, потому что все не так просто, как тебе кажется?

WorldState по UDP

Просто гениально. Может напишешь, раз так все просто? Всего лишь 15 минут. Впрочем не спеши, давай посчитаем вместе:

А в чем проблема, на стороне сервера открываешь асинхронный сокет и читаешь с него команды пользователей. Обновляешь мир. Отправляешь участки мира пользователям. Код для сокета даже писать не надо, он просто гуглится. Это реально 15 минут.

Epicus (01 May 2018 - 17:37) писал:

Значит говоришь 1 Мбит/с на игрока? Это 131072 байт/с. При частоте обновления в 10 кадров получается, что один кадр у тебя занимает 13107 байт. Обзор игрока - 15 тайлов. Если взять +1 (в обе стороны), получается 17 тайлов. Делим, получаем что у тебя выходит 45 байт на один тайл, в среднем. И сколько объектов ты сможешь описать с помощью 45 байтов? А сколько их реально на станции?

А что такое объект? Каждый объект - это спрайт (бывает не один, человечек - это 30 спрайтов), куча свойств, которые важны для отрисовки (цвет, сдвиг по пикселям, состояния анимации и прочий треш) плюс название, различные действия которые можно с ним делать и т.д. Как это все уместить в 45 байт на тайл?

Обзор я считал равным 13х13, так как он такой по дефолту в Byond. Для передачи исчерпывающей инфы нужно 1,5 байта на World_Id, 1,5 байта на TypeObj_Id, 2 байта на координаты, ну и допустим 3 байта на флаги и доп инфу. Итого 8 байт. Умножаем на частоту обновления и количество тайлов. 8*225*10=18000 байт/c. Теперь остальные объекты. Допустим те же 8 байт + 4 байта ссылок на структуры + 20 байт на доп инфу нужную для отрисовки. 32 байта. Допустим 70% пространства занято различными предметами которые видит пользователь и в среднем на тайле по 3 доступных для отрисовки предмета 225*0.7*3*10Гц*32байта = 151200 байт/c, итого 169200 байт/с или ~1.3 Мбит/c + ~0.2 Мбит/с(UDP) на пользователя. И естественно серверу не нужно отправлять ни спрайтов ни функций действий.

Epicus (01 May 2018 - 17:37) писал:

То есть если у тебя 50 игроков, то тебе нужен стабильный коннект на отдачу 50 мбит/c минимум.

Зачем на начальном этапе разработки 50 клиентов? На начальном этапе она должно хотя бы просто работать, чтобы было что показать. Это же инди, не надо торопиться получить релизную версию.

Epicus (01 May 2018 - 17:37) писал:

Вот только дальше начинаются проблемы с тем, что тебе нужно, как минимум, как-то фиксировать эти изменения и определять игроков, которым они будут актуальны, чтобы отправлять их только им. Начинаются проблемы с синхронизацией всего этого добра на сервере, начинаются проблемы с "теорией относительности", о которой Valve целые статьи пишет, начинаются проблемы с предсказаниями на клиенте. Решение всех этих проблем - уже на целый магистерский диплом потянет в каком-нибудь ITшном вузе, а если завернуть все это в либу, то можно и продать ее за кучу денег, между прочим.

Фиксируешь изменения если они в пределах видимости игрока, потом отправляешь на клиент. Если игрок передвигался, отправляешь инфу на 15 тайлов. И ты серьёзно сравниваешь синхронизацию шутера(UDP) и 10 фпс рогалика(TCP)? Тут заметные проблемы с рассинхроном могут возникнуть лишь в боевке, и в Byond эта проблема не особо решена. Нет никакой надобности писать в инди проекте идеальный код. Небольшой рассинхрон, ну и ладно, его никто не заметит, а умение использовать его в боевке будут называть робустом.

RecursiveRoar (01 May 2018 - 21:30) писал:

А в чем проблема, на стороне сервера открываешь асинхронный сокет и читаешь с него команды пользователей. Обновляешь мир. Отправляешь участки мира пользователям. Код для сокета даже писать не надо, он просто гуглится. Это реально 15 минут.

отправляешь участки мира пользователям

Вот в этом проблема же. Конечно, открыть сокет - много ума не надо. А вот продумать архитектуру, как твой мир будет складываться в пакеты, и как потом эти пакеты на клиенте будут превращаться в картинку - это целая история. Так то тут у тебя целая эмуляция мира на клиенте должна быть, с учетом огромного количества мелочей. За 15 минут ты этого не напишешь.

RecursiveRoar (01 May 2018 - 21:30) писал:

Обзор я считал равным 13х13, так как он такой по дефолту в Byond. Для передачи исчерпывающей инфы нужно 1,5 байта на World_Id, 1,5 байта на TypeObj_Id, 2 байта на координаты, ну и допустим 3 байта на флаги и доп инфу. Итого 8 байт. Умножаем на частоту обновления и количество тайлов. 822510=18000 байт/c. Теперь остальные объекты. Допустим те же 8 байт + 4 байта ссылок на структуры + 20 байт на доп инфу нужную для отрисовки. 32 байта. Допустим 70% пространства занято различными предметами которые видит пользователь и в среднем на тайле по 3 доступных для отрисовки предмета 2250.7310Гц32байта = 151200 байт/c, итого 169200 байт/с или ~1.3 Мбит/c + ~0.2 Мбит/с(UDP) на пользователя. И естественно серверу не нужно отправлять ни спрайтов ни функций действий.

Обзор в Space Station 13 - 15х15. С учетом того, что тебе нужны еще как минимум спрайты, которые находятся за экраном, но чуть-чуть выглядывают (сингулярность какая-нибудь), то это будет минимум 17х17.

TypeObj_Id

И чо ты собираешься делать с этим TypeObj_id? Наверное, сначала надо инфу переслать по этому объекту, а уже потом работать с TypeObj_id? А как ты пересылать собираешься их, по UDP? Так у тебя все потеряется - приехали к TCP уже. То есть уже даже по твоему замечательному плану тебе на каждого пользователя надо будет отдельно работать и с TCP, и с UDP.

Допустим 70% пространства занято различными предметами которые видит пользователь и в среднем на тайле по 3 доступных для отрисовки предмета

Очень оптимистичное приближение.

Ну в любом случае, ты насчитал столько же, сколько и я, 1 Мбит/с на игрока минимум, даже больше, аж 1,5 Мбит/с.

RecursiveRoar (01 May 2018 - 21:30) писал:

Зачем на начальном этапе разработки 50 клиентов? На начальном этапе она должно хотя бы просто работать, чтобы было что показать. Это же инди, не надо торопиться получить релизную версию.

Угу, с такими планами тебе на КикСтартеры и Гринлайты - там таких вагоны. Пилят говно, продают людям и сваливают, потому что все с нуля переписывать надо.

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

RecursiveRoar (01 May 2018 - 21:30) писал:

Фиксируешь изменения если они в пределах видимости игрока, потом отправляешь на клиент. Если игрок передвигался, отправляешь инфу на 15 тайлов. И ты серьёзно сравниваешь синхронизацию шутера(UDP) и 10 фпс рогалика(TCP)? Тут заметные проблемы с рассинхроном могут возникнуть лишь в боевке, и в Byond эта проблема не особо решена. Нет никакой надобности писать в инди проекте идеальный код. Небольшой рассинхрон, ну и ладно, его никто не заметит, а умение использовать его в боевке будут называть робустом.

Что-что, а сеть в Byond написана очень даже не плохо, не знаю о каком рассинхроне ты говоришь. Фиксируешь-отправляешь - звучит очень легко, пока за код не сядешь, а я это писал и знаю о чем говорю.

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

Спасибо, уже насмотрелись на кучу говноигр, которые строились по такому принципу. Если делать ремейк SS13, то он должен быть лучше оригинала, а твои костыли тут никому не уперлись.

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

Как авторитетный эксперт по сетевому дерьму, серверам/клиентам и прочим выебонам - это нихуя не просто, слушай эпикуса, умникблять.

1.5 байта на ид - ну успехов хуле, у тебя на экране объектов больше может быть, чем влезет в 1.5 байта, а на сервере дохуя их по факту, а ид должен быть уникальным.

А еще удп в 2018 году - некроеб костыльный, у тебя не шутан, хотя и там он не упал.

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

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

Ну да кстати, в 1,5 байта ид не влезет, но это не особо важно.

Я не знаю насколько ты "авторитет", но ты в курсе что на UDP висят DNS, видео-потоки и прочие потоковые данные, и в том числе онлайн игры, где UDP вообще-то основной транспортный протокол.

Изначально сделать минимум, чтобы был рабочий прототип, а не чтобы было, и неожиданно, написав код для UDP тебе не надо будет ничего переделывать особо(этим и определяется возможность использовать его на промежуточном этапе), потому что TCP будет использовать те же структуры и функции, нужно лишь добавить кучу недостающего кода.

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

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

На сервере принимаешь ввод, считаешь логику, формируешь пакеты для пользователей, отправляешь, все. Остается только добавлять контент со своей логикой. В 250 часов это все вполне пишется. Тут самое главное геймдизайн иметь до того как писать будешь, иначе реально может возникнуть надобность в переписывании.

В курсе. Как и в курсе клевых атак на этот протокол, где любой школьник может устроить дудос в гигабиты. Нет, не основной, по моим зоонаблюдениям вообще только в шутанах.

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

Уже бульйонд есть, делать еще 1 - зачем, если будет тоже самое говно?

Do it, hule.

Ну UDP основной в шутано-подобных и RTS-подобных играх, ну то есть в большинстве онлайн игр.

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

Естественно UDP имеет кучу недостатков, но TCP писать заметно дольше, писать его желательно параллельно игровой логике, иначе просто есть риск скопытить энтузиазм на написании сетевого стека, обычно на написании таких относительно сложных и скучных модулей и заканчивается большинство инди проектов от непрофессионалов в области. Плюс у сс13 довольно крупное комьюнити в котором есть люди умеющие писать код, нежелающие писать ремейк, но вполне способные писать отдельные модули, и написав рабочий прототип на UDP, вполне может найтись человек который перепишет сетевой стек на TCP. Я считаю что выбор между: скопытить проект на написание отдельного модуля; и написать немного неполный и неидеальный прототип - очевиден.

Ну BYOND с чистым и полностью открытым исходным кодом заранее лучше, чем то что есть сейчас. А еще если в этом новом BYONDе доступ к элементам массива будет стоить не так как будто это каждый раз промах по кешу + O(n^2) дополнительных ненужных расходов, то на нем даже можно будет написать неплохой атмос.

И всеже я был неправ, в одиночку писать прям до беты если ты уделяешь этому менее 2-3 часов в день может растянутся даже до 300-400 часов, тут в принципе у любого кто не получает за это деньги угаснет энтузиазм.

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