Войти
ПроектыФорумОцените

Space Station 13 Remake (2 стр)

Страницы: 1 2 3 410 Следующая »
#15
10:40, 15 янв. 2016

AIIIBAP

Отлично! Продолжай в том же духе.
Стильный генератор, сам нарисовал или из сборки какой взял?


#16
13:21, 15 янв. 2016

Smeler
Я его собрал из скриншота с Soviet Station и из вентиляторов с GoonStation. Немного думаю переделать, мне не нравится как трубы выходят и на центральной части хочется видеть экран со всякими разными картинками (на Goon Stattion там для разных событий вроде перегрева и прочего были разные анимации, но тут экрана для них нету), ещё шкала с генерируемой энергией сейчас просто дублируется в двух местах - это тупо конечно, надо оригинальнее делать.

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

В ближайших планах первый компьютер!
Он будет регулировать состав воздуха отсеке или в нескольких отсеках, также с его помощью можно будет управлять в процессами в камере сгорания, регулируя подачу форона и кислорода. Ещё будет общий фикс интерфейсов, и фикс физики (сейчас у меня 50 обновлений в секунду, думаю делать 10, а возможно даже меньше).

#17
10:40, 17 янв. 2016

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

Изображение

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

P.S. Ещё я узловые части труб переделал, как вам новые трубы?

#18
12:13, 17 янв. 2016

работа стала идти намного быстрее и интереснее для автора, как только создал тему ;)

#19
17:00, 17 янв. 2016

Фантазёр
Ну я бы не сказал - быстрее всего работа шла в отпуске)
Кроме того у меня же ещё полнофункциональный редактор + интерфейс для каждого объекта, а их я пока не показываю.
Да и на скриншоте из нового только комп, весь объем работ то в коде!

#20
17:05, 18 янв. 2016

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

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

#21
20:04, 18 янв. 2016

Velant

Почему не суперматерию/сингулярность, коли термогенераторы уже показывал.

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

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

Всё не так просто, объект подтягивает значения из компа (при этом смотрит, что он включен и не сломан), объект можно подключить к компу с объекта или с самого компа (для игрока удобно - для меня куча кода), в случае с объектом - это легко (мы меняем управляющий комп), для компа тяжелее (мы смотрим разрешено ли для объекта подключение управляющего компа, для вентиляций смотрим газ, который контролирует вентиляция, смотрим нет ли уже подключенного компа, ещё смотрим не подключен ли уже текущий комп к управлению). В общем - много тут всего.
Да и это не все проблемы, скажем - разобрали мы вентиляцию или комп, вентиляции должны узнать об этом, как и комп, проверка игрового объекта на null в Unity "долгая", для оптимизации придётся делать так, что объект будет отправлять всем заинтересованным объектам информацию о прекращении своего существования, при этом какие-то изменения произойдут в заинтересованном объекте. И это я ещё перечислил не все трудности (ведь при подключении объектов они примерно так же должны будут и "знакомиться").
#22
20:18, 18 янв. 2016
ещё есть идея создания ядерного реактора на фороне

В оригинале пакман на нем работает. Его продвинутая версия из РнД как раз твой ядерный реактор, работает на уране.
я подаю в отсеки кислород и азот по отдельности, каждая вентиляция мониторит давление "своего" газа и при необходимости подаёт ещё, скраблеры высасывают весь воздух (все газы) из отсека до определённого общего давления

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

А зачем так делать? Пускай машинерия у себя и хранит текущие настройки, а комп участвует только когда с компа что-то пытаются поменять. Куча лишних проверок долой. При создании компа можно как и в оригинале подключать его к расположенной рядом соответствующей машине и дело с концом. И никаких сложностей.
проверка игрового объекта на null в Unity "долгая", для оптимизации придётся делать так, что объект будет отправлять всем заинтересованным объектам информацию о прекращении своего существования, при этом какие-то изменения произойдут в заинтересованном объекте.

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

Надеюсь проводка-то у тебя не норовит постоянно запросить не подключили ли к ней чего?

#23
20:40, 18 янв. 2016

Velant

Это же адская мешанина труб будет. Лишнее переусложнение планировки, резкое усиление тормозов.

В полтора раза больше труб для газа. Было две - станет три. Тормозов с этого особо больше не станет (во всяком случае не из-за этого они будут).
Плюс теряется любимая фича ИИ и триторов-атмостехов с пусканием в вентиляцию плазмы или углекислого газа...

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

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

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

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

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

Ты будешь наверное смеяться, но таки запрашивает) Правда не по отдельным тайлам, а целиком. Проводка объединена в систему с общей энергией (раздельных систем может быть сколько угодно), если мы как-то меняем систему, то система пробегает по всем своим тайлам-проводам и актуализирует данные. Если объект подключается к проводу, то он взаимодействует с системой, а не с отдельным проводом. Провод свои проверки и обновления проводит при изменении объектов на своём тайле, а так он вообще не имеет своего цикла обновления.
#24
21:28, 18 янв. 2016
Больше возможностей, есть задумки различных устройств атмосферного отсека для разных станций.

А что мешает просто подключить разные трубы к разным помпам без изменений их обработки консолью вентиляции? Какая ей разница кислородная труба или азотная, она просто задает отдельные настройки для каждой помпы, не определяя какая труба к ней подсоединена.
Это в общем случае отвяжет систему от наличия конкретного числа труб и не потребует вообще никаких изменений в интерфейсе по сравнению с оригиналом.
Вот к примеру у вентиляции указан управляющий комп, она проверяет жив ли комп, включен ли, не сломан ли, считывает свою настройку.
Комп идёт по своим вентиляциям, проверяет только существование и газ, который контролирует вентиляция.
Для полноценного объекта - это не так уж то и много проверок.

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

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

Так-то нормально, я опасался что как с компами спам идет.

А как у тебя реализованы газы? Реалистично как в Baystation или потайлово как в TG? (в первом случае при разгерме 2д-космонавтиков весело швыряет в другой конец коридора потоком воздуха, ломая кости об углы и стены, во втором лениво сдвигаются на один тайл, если встанут в открытом шлюзе).

#25
22:38, 18 янв. 2016

Velant

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

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

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

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

Ну компов-то будет не так много, да и подключить любой объект можно только один раз - то есть тут проблемы нет, а вот проводов много, их надо грузить по минимуму.
А как у тебя реализованы газы? Реалистично как в Baystation или потайлово как в TG? (в первом случае при разгерме 2д-космонавтиков весело швыряет в другой конец коридора потоком воздуха, ломая кости об углы и стены, во втором лениво сдвигаются на один тайл, если встанут в открытом шлюзе).

Ну, вообще и там и там сделано потайлово, реалистично - это же не учёт всех молекул)
У меня сейчас этот момент только запланирован, я думаю считать перенос общего количества газа из тайла в тайл и вешать в соответствии с этим определённую силу на все динамические объекты в тайле. Выйдет примерно так: от вентиляции ветерок вполне сможет утащить лист бумаги, а при сильной разгерме всех потащит в дыру, при том тащить будет не по тайлам, а прямо к дыре (главное чтобы пробок не было, а то тупо будет).
#26
23:03, 21 янв. 2016

Доброго вечера! Небольшой апдейт.

Изображение

Газовый сенсор - прогоняет газ из отсека через себя и определяет температуру, давление и состав. Незаменимая вещь для контроля за составом воздуха. Также компьютер по управлению атмосферой получает актуальные данные именно от этого устройства.
В данном случае я показываю как устроен интерфейс, интерфейсы у меня уже есть для 20 статических игровых объектов (в основном всё по атмосфере). Параметры Main SMES, Secondary Smes я уберу - пересмотрел одну концепцию, так что их скоро не будет.

#27
1:21, 22 янв. 2016

Подписался.
Почему не 3D?

#28
9:06, 22 янв. 2016

Gexon

Почему не 3D?

Вот честно говоря уже и не знаю, возможно и правда стоило использовать 3D сцену для тайловой игры. Изначально я думал, что spriteRenderer будет работать быстрее, чем вывод плоскости с набором текстур (аля Майнкрафт, но вид только сверху), но оказалось, что это совсем не так. Ещё думаю попробую сделать через шейдер, который будет на spriteRenderer, если в него кидать кучу спрайтов. Ну, в целом ещё предстоит поломать голову. Может всё таки в Unity дадут в spriteRenderer кидать трёхмерный массив спрайтов). Двумерный для распределения на плоскости и третье измерение будет отвечать за высоту слоя. Ну в крайнем случае надо будет это писать самому))
#29
9:10, 22 янв. 2016

На скринах Гнум?

Страницы: 1 2 3 410 Следующая »
ПроектыФорумОцените

Тема в архиве.