Дядя Миша писал: пишут, что он дико тормозной из-за сишарпа
Игры на Юнити по моим наблюдениям действительно имеют свойство тормозить, но я честно говоря сомневаюсь, что это из-за шарпа. Скорее из-за кривых рук разработчиков игр и закрытого движка, который не дает его нормально дебажить и оптимизировать.
Ну то есть я сомневаюсь, что шарп тормознее того же Унреал-скрипта на котором вполне себе делались игры.
Цитата:
Дядя Миша писал: вы любите сишарп?
Люблю, пишу на нем всякие тулзы и другие нетребовательные к производительности проги.
Вообщем на данный момент идеология следующая: ядро движка не должно содержать внутри себя никаких константных путей. Вообще. В идеале конечно. На практике что-то обязательно придётся прописать, например gameinfo.txt будет читаться из движка, но это некритично, т.к. его можно бесконечно расширять, прозрачно для самого движка, он хранит его параметры как набор кей-валуев.
Всё что потенциально пользователь захочет поменять - выносится в пользовательские библиотеки и\или скрипты. На данный момент я планирую две пользовательских библиотеки со следующим наполнением:
GameUI.dll - основное меню, внутри-игровой худ, клиентская консоль, чат, менеджер кнопок. Вообщем 2Д-стафф.
progs.dll - интеракция с объектами, эдикты-энтить, механизм приёма и передачи дельта-состояний (прозрачен для движка, он просто отправляет и принимает пакеты), формирование вида от каждой энтити (возможность задать ref_viewpass) актуально, когда мы смотрим от лица той или иной энтити\мониторов\зеркал\камер (ну ладно, зеркала в движке это делают).
Единственное что при таком подходе повисает в воздухе - это usercmd. С одной стороны его бы неплохо было иметь в progs.dll, с другой - это нарушает тиеричность, да и кнопки, я напоминаю - в GameUI.dll. Физически кнопки конечно разделены на игровые состояния и обычные, вообщем там дальше уже по факту будет видно.
По идее этих двух пользовательских библиотек будет достаточно чтобы сделать абсолютно любую игру, хоть однопользовательскую, хоть многопользовательскую, хоть 2д, хоть 3д. Вообщем всё что угодно.
Если какие-то элементы нам не нужны - например сеть, мы просто их не используем. Точно так же и с сейврестором и чейнджлевелом, он может быть абсолютно любым, он находится полностью в пользовательской части. Поверх этого можно прикрутить скрипт-машину, шарп куси, да хоть яву, кому што нравится. Соответственно то, к чему пользователь не будет иметь доступа (закрыто в ядре).
1. сеть (только на уровне доставки и отправки пакетов)
2. системные средства - окошки, системная консоль, ввод\вывод, подключение графических библиотек, прочий бакэнд
3. файловая (на уровне пользователя только основные функции для работы внутри папки игры).
4. система консольных комманд и переменных (можно создавать свои, логику работы этих скриптов менять нельзя).
5. форматы трёхмерные - жестко определены, самостоятельно новых нельзя добавить
6. форматы двухмерные - жестко определены (текстуры)
7. форматы видео, звука - аналогично.
8. звуковой движок - можно отправлять звуки и музыку на воспроизведение, фундаментально вмешаться в его работу нельзя.
9. некоторые отладочные средства, жестко зашитые в самом движке (напримеры атласы текстур, лайтмап, дебаг-экраны)
10. менеджер шрифтов.
11. рендерер, но с оговоркой, что конвейер полностью программируемый и прозрачный, с возможностью создания собственного языка описания материалов, равно как и возможностью выбора типа рендеринга на пользовательском скриптовом уровне - можно будет сочетать динамику и статику в любых комбинациях, делать отложку и форвард по желанию, добавлять любые пост-процессы.
Код для предиктинга не собирается в двух вариантах как GoldSrc/Source, а один в progs.datprogs.dll? Это очень здорово. Впрочем, вспоминаю, что ты про это уже писал...
В предиктинге самое главное что? Инкапсулировать тайм-машину, чтобы можно было откатывать стейты индиффирентно.
Оно не столько сложное, сколько жручее в плане памяти, да.
С меню я управился, можно и приступать к рендереру, но сперва имплементирую лайтмапы, раз обещал. Они могут пригодится для разных вариантов, например тени - лайтмапой, свет деномический или Dual Lightmapping этот про который я рассказывал в своём обзоре, как резкие зубцы теней взяли и чуть-чуть сгладили Ну и лайтмаппер визлайт-матрицу мне построит для фуллдинамики. Вообщем лишним не будет.
Но под кутришный формат считать лайтмапы уже нет смысла, под эти страницы 128х128. Лайтмапы должны быть внешними в нормальных текстурах. Следовательно пришло время разработать и новый формат BSP.
Он не будет фундаментально отличаться от кутришного, но лишь в том аспекте, что кутришный формат почти генеричный, вертексы-индексы, дерево. Надо только выкинуть это идиотское разделение на брашы-патчи-флаеры, оно вообще не нужно. Я лучше туда сохраню варианты STRIP-режима. TRILIST, TRISTRIP вот это всё. А брашы остануться для коллизии.
Как вы помните, я нагенерил колоизационных брашей и для патчей и вообще для всякого. Так что план работ следующий:
1. имплементация нового формата уровней
2. лайтмаппер (лайтбейкер?)
3. новый рендерер с поддержкой динамического освещения
Ну тут сложно сказать - новый, он же кастомный, на скриптах. Надо вынести наружу возможности манипуляции с FBO, MRT и подключением нужных шейдеров в определённых точках. Т.е. возможность скриптования конвейера. Правда этому мешает тот факт, что мне бы неплохо иметь униформные модели с унифицированными VBO-мешами. Так что вероятно будут еще разработаны форматы для моделей, травки-муравки, импосторов, спрайтов (ну это понятно на базе шрифтов).
Вообщем самая такая визуально-наглядная часть работы. Вероятно будут скриншоты.
Добавлено 03-05-2020 в 14:53:
Когда всё вышеперечисленное будет сделано, работы останется относительно немного - сеть и игровые объекты (скриптование?).
Всё остальное уже готово. Но и занять оно может порядочно времени - может до конца года, я не знаю. Очень уж велик объем работы.
Всё-таки товарищи, какая же пропасть лежит между пониманием и осознанием. Для программиста понять, что какая-то ерунда, которая лично для него вообще не заслуживает даже секунды внимания, для его пользователей может явиться непреодолимым препятствием, ставящим под угрозу выход всего проекта - может не хватить даже всей жизни. На этом уже погорел Крайтек, кстати.
Я сейчас попробую сделать очень громкое и весьма пафосное заявление, которое конечно не соответствует моему положению и уровню, прямо как тогда в 2004-м, ведь мало кто верил, что Xash3D будет действительно написан. Но это всё баловство по сути. Хотя бы потому, что никому никому ничем не обязан. А NT как изначально проект с упором на коммерческий сегмент, это другой расклад абсолютно. И вот знаете, по прочтении той темы, у меня окончательно сформировалось то, что зрело подспудно все эти годы и я наконец-то смог его окончательно сформулировать. Что же самое главное для игрового движка?
1. Несмотря ни на что, любой пользователь работавший со святой троицей назовёт вам массу недостатков любого из них. Т.е. возможность оттягать маленький кусочек рынка по прежнему сохраняется даже в 2020-м году.
2. Самое главное, ну впрочем как и много где - это работа с людьми, отношение. Пусть там чего-то нехватает или недоделато. Важно, понимание оперативной поддержки и личного участия в пользовательских проблемах. Пусть даже физически это и не всегда возможно. И вот за отношение люди готовы простить техническое несовершеноство отдельных подсистем и выдать проекту
3. Кредит доверия. По умолчанию он есть у любой новой вещи, но так же быстро убывает или наоборот растёт. Но в любом случае в момент входа на рынок он не должен быть нулевым, иначе со входа всё и в помойку.
4. Техническое. Даже в 2020-м году, даже при наличии рейтрейсинга, вменяемых алгоритмов реалтайм радиосити, удобных для разработчика так толком и не появилось. Возможно это именна та точка приложения, которая позволит мне приобрести изначальный кредит доверия аудитории. Тем более что мне и самому эта тема весьма интересна.
Ну а теперь, то самое пафосное заявление: если моему будущему проекты и суждено стать коммерчески успешным, то я вам обещаю и торжественно клянусь, никогда не забивать на проблемы реальных пользователей, хотя соблазн порой весьма велик.
| IP: 
30-04-2020 21:22
Ну и лайтмаппер визлайт-матрицу мне построит для фуллдинамики. Вообщем лишним не будет.
