HLFX.Ru Forum - XashNT: блог разработчика

Страницы (32): « Первая ... « 3 4 5 6 [7] 8 9 10 11 » ... Последняя »
Показать все 479 сообщений этой темы на одной странице

HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- Наши проекты (https://hlfx.ru/forum/forumdisplay.php?forumid=1)
-- XashNT: блог разработчика (https://hlfx.ru/forum/showthread.php?threadid=6097)

Отправлено Crystallize 10-08-2024 в 09:22:

Цитата:

FiEctro писал:
Сделай ещё поддержку атрибутов текста
Debug.Log("<color=red>Error: </color>AssetBundle not found");

Ох уж эти проклятые треугольные скобки. У тебя не было ощущения что старый добрый BBcode с квадратными скобками намного читабельнее?

Отправлено nemyax 10-08-2024 в 10:55:

Да уж, не по-жсоновски как-то =)

Отправлено Дядя Миша 10-08-2024 в 11:54:

Цитата:

FiEctro писал:
Ещё здорово бы было если бы был простой доступ к движковым классам и их методам. Без развёртывания кучи композиций и объявления в разных частях своего кода. Ну как в шарпах: объект.класс.значение

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

Цитата:

FiEctro писал:
Debug.Log("<color=red>Error: </color>AssetBundle not found");

Это тоже есть, но в более простом варианте ^<number>
где ^ означает начало атрибута, а за ним следует число от нуля до семи.
0 - черный цвет, 1 - красный, итогдалие. На практике набора из пяти-шести цветов хватает всегда. Это же просто отладочные сообщения.

Добавлено 10-08-2024 в 14:54:

Собственно схема цветовых префиксов досталась в наследство от Xash3D, а туда она попала из Quake3. Ни разу у меня не было случая, чтобы представленных семи цветов не хватило. К тому же, благодаря ограниченному набору я могу с лёгкостью воспроизвести эти же цвета в системной консоли, где изначально действует ограничение примерно такого же плана. Там по сути три бита RGB и один бит интенсивности.

Цитата:

Crystallize писал:
Ох уж эти проклятые треугольные скобки

Треугольные - это для шаблонов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 10-08-2024 в 18:28:

Цитата:

Дядя Миша писал:
Треугольные - это для шаблонов.

Ну эта сишная профдеформация тоже так себе, обычный моддер эти треугольные скобки видел максимум в HTML и вообще не ассоциирует треугольность с обращением к некоему множеству объектов. У него эта ассоциативная связка скорее пустует ну или занята двойным процентом который он в мемах в 00 видел: %%USERNAME%%. Мне лично хочется в таких случаях писать квадратные скобки просто потому что они визуально легче читаются и выглядят более солидно чем круглые или треугольные.

Отправлено FiEctro 10-08-2024 в 18:33:

Crystallize
Квадратные больше с массивами ассоциируются. А это атрибуты. Там может быть не только цвет. Но и размер текста, и тип (моноширинный например), и курсив, жирный, зачеркнутый и т.д. и т.п.

Цитата:

Дядя Миша писал:
Собственно схема цветовых префиксов досталась в наследство от Xash3D, а туда она попала из Quake3. Ни разу у меня не было случая, чтобы представленных семи цветов не хватило. К тому же, благодаря ограниченному набору я могу с лёгкостью воспроизвести эти же цвета в системной консоли, где изначально действует ограничение примерно такого же плана. Там по сути три бита RGB и один бит интенсивности.

Добавь ещё HEX код для игрового текста. Вот этих "хватит всем" никогда не хватает. Ладно для консоли ещё понимаю, но в игре ограничивать этим - бред.

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!

Отправлено Crystallize 10-08-2024 в 18:58:

Цитата:

FiEctro писал:
Квадратные больше с массивами ассоциируются.

Это у тех кто за кодингом провёл больше времени чем печатая посты на форумах 00х. У меня пока не так. Да и я думаю что синтаксис вывода в консоль можно сделать каким-то особенным, с ним чаще сталкиваешься.

Отправлено Дядя Миша 10-08-2024 в 19:43:

Цитата:

FiEctro писал:
Ладно для консоли ещё понимаю, но в игре ограничивать этим - бред.

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

Добавлено 10-08-2024 в 22:43:

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

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 10-08-2024 в 20:40:

Цитата:

Дядя Миша писал:
FiEctro вообще у тебя какой-то перманентный страх, что я всячески ограничиваю пользователя в будущем движке, я не понимаю откуда это у тебя берётся. Такое ощущение что в Юнити ничего нельзя и ты боишься, что в Ксаше оно так же будет.

Я по твоему совету ковырял кваку. Я ковырял ХЛСДК. Ковырял твой новый СДК. И ты говоришь что ориентируешься на эти проекты. Вот оттуда этот страх.

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

Я считаю что когда пользователь первый раз включает движок он должен видеть что то очень простое, типа паинта, и уже когда в нём сможет потыкаться, тогда уже начинать его изучать более углублённо и серьёзно.
А когда тебе первым делом дают кучу утилит с командами которые непонятно как и куда вводить. То 99% народу сразу отсеится. И это я не про то чтобы про Ксаш, а вообще, навидался я такого.

Отправлено Дядя Миша 10-08-2024 в 20:49:

Цитата:

FiEctro писал:
И ты говоришь что ориентируешься на эти проекты

Дух старой школы я хочу сохранить, да.

Цитата:

FiEctro писал:
Я тебя понимаю что ты привык уже чисто на блокнотике и крестах всё делать

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

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 11-08-2024 в 07:29:

Можно сказать что XashNT будет чем-то средним между первым Квейком (именно первым!) и Юнити. Но навряд ли вы вот так сходу поймете, что именно он унаследовал. Речь идёт скорее о передании общей атмосферы, нежели о прямом заимствовании.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 11-08-2024 в 08:51:

Цитата:

FiEctro писал:
А когда тебе первым делом дают кучу утилит с командами которые непонятно как и куда вводить.

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

Отправлено FiEctro 11-08-2024 в 09:49:

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

Отправлено a1batross 11-08-2024 в 11:17:

Цитата:

Дядя Миша писал:
К тому же, благодаря ограниченному набору я могу с лёгкостью воспроизвести эти же цвета в системной консоли, где изначально действует ограничение примерно такого же плана. Там по сути три бита RGB и один бит интенсивности.

А этот набор из Quake 3 в свою очередь попал из ANSI последовательностей терминалов. В Windows то наверное можно сделать напрямую SetConsoleTextColor какой-нибудь, а вот в юниксах и в Windows 10 и выше их можно преобразовать табличкой:

code:
static void Sys_WriteEscapeSequenceForColorcode( int fd, int c )
{
	static const char *q3ToAnsi[ 8 ] =
	{
		"\033[1;30m", // COLOR_BLACK
		"\033[1;31m", // COLOR_RED
		"\033[1;32m", // COLOR_GREEN
		"\033[1;33m", // COLOR_YELLOW
		"\033[1;34m", // COLOR_BLUE
		"\033[1;36m", // COLOR_CYAN
		"\033[1;35m", // COLOR_MAGENTA
		"\033[0m", // COLOR_WHITE
	};
	const char *esc = q3ToAnsi[c];

	if( c == 7 )
		write( fd, esc, 4 );
	else write( fd, esc, 7 );
}

__________________
Xash3D FWGS форк

Отправлено Дядя Миша 12-08-2024 в 07:25:

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

Цитата:

Антон, [11.08.24 18:14]
[В ответ на XashNT Chat]
Расскажу про свой опыт взаимодействия с игровыми движками. Я буду выделять основные плюсы и минусы. Обращу внимание, что всё ниже перечисленное - это мое субъективное мнение и оно отражает лишь то, что я подмечал при работе с тем или иным движком.

1. Unity

Плюсы:

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

Минусы:

* Приходится практически все писать с нуля. Конечно в Ассет Сторе есть всякие шаблоны и модули, но нюанс в том, что они написаны обычно под конкретную версию Unity. Если версии редактора и какого либо ассета различаются — то фиг установишь.

* Visual Studio в качестве редактора кода. Раньше в со старыми версиями Unity в комплекте был редактор MonoDevelop. Легкий, удобный, сразу настроенный. А в новых версиях увы — будь добр установи внешний редактор, который еще не факт, что правильно интегрируется с движком

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

* Работа с GUI - это какой-то треш. Добавляешь Canvas какой нибудь, а он появляется в 3D сцене в виде огромного квадрата, который растянут на всю сцену. Нужно переключается на 2D режим, чтобы хоть как то с этим работать.

* Графика. Приходится попотеть, чтобы Unity выдавал красивую и целостную картинку.

2. Unreal Engine

Плюсы:

* Работает «из коробки». Множество функций уже предварительно настроены, что экономит время при создании проектов.
* Красивая графика. Дорого бохато и всё такое.

Минусы:

* Требователен к ресурсам ПК
* Занимает много места на жестком диске. Если вес Unity обычно не превышает 5 ГБ, то Unreal занимает 40-70 ГБ.
* Блюпринты. Кто-то может возразить — так это же хорошо. Визуальное программирование самое то для новичков. Так то да, блюпринты хороши на начальных этапах разработки (для прототипирования например), но по мере масштабирования проекта он может запросто превратится в лапшу из кучи нодов, где хрен потом разберёшься. Лично мне писать код привычнее.
* Процесс сборки и компиляции проекта может занимать много времени.
* Как по мне, у движка немного перегруженный интерфейс.

3. GoldSrc/Xash3D/Source

Плюсы:

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

Минусы:

Антон, [11.08.24 18:14]
[В ответ на XashNT Chat]
* Размерность игрового мира. При создании карт меня всегда смущали внутриигровые юниты. Например, хочется воссоздать место из реальной жизни, а тут возникает проблема - как не промахнуться с размерностью, чтобы какой-то объект правильно вписался в игровой мир. Конечно, существуют всякие шпаргалки по размерам дверных проёмов, высоты лесниц и т.д, но блин..это такая запара конечно. Мне очень не хватало возможности сделать карту в Блендере каком нибудь просто в метрах обычных и потом импортировать её в движок и не беспокоится о том, что где-то я налажал с размерами.
* Кодинг. Он тут сложный. Дело даже не в самом языке С++, а в..ммм я даже не знаю как правильно сказать, в архитектуре игрового кода наверное. Конечно, существуют множество туторов по созданию оружия, монстров, и т. д, Обычно они сводятся к следующему: На клиенте в каком то файле пишем то то, на сервере в другом файле то то, не забываем про прекеш и т. д. и т. д. Когда делаешь строго по туториалу, вроде бы все понятно, но как только начинаешь кодить что-то отличное от стандартных монстров или оружия - тут то и возникают вопросы. Как это всё работает? Почему писать надо именно так? Разделение на клиент и сервер просто путает и возникает каша в голове. Некоторые вещи вообще намертво «приколочены» к движку, если по какой-то причине они не нужны и хочется их убрать, а нельзя — иначе есть риск поломать что-то важное.
* Скриптинг. Скрипты в виде квадратиков в редакторе карт сбивают с толку и запутывает. Тут как в случае с с Блюпринтами в UE — получается визуальная лапша, в которой потом трудно ориентироваться.
* Отсутствие возможности запустить сцену прямо в редакторе. Обязательно нужно сначала скомпилировать карту, зайти в игру и только потом тестировать карту. Неудобно.
* Нет единой экосистемы — куча разных редакторов, которые приходится ставить отдельно самостоятельно.
* Сложность в освоении. Туториалов и видеоуроков не так много.

Добавлено 12-08-2024 в 10:10:

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

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

По поводу размерности игрового мира в юнитах. Переделывать движок на сантиметры или метры навряд ли будет оптимальным решением.
Лучше всего на мой взгляд вычистить из конвейера все константы, которые так или иначе завязаны на реальных привязках к юниту. Тем более что их не особенно много. Тот же OpenGL оперирует абстрактными единицами, ему всё равно что у вас - юнити ли метры. Значит надо, чтобы и движку тоже было всё равно.

Цитата:

Когда делаешь строго по туториалу, вроде бы все понятно, но как только начинаешь кодить что-то отличное от стандартных монстров или оружия - тут то и возникают вопросы. Как это всё работает? Почему писать надо именно так? Разделение на клиент и сервер просто путает и возникает каша в голове. Некоторые вещи вообще намертво «приколочены» к движку, если по какой-то причине они не нужны и хочется их убрать, а нельзя — иначе есть риск поломать что-то важное.

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

Добавлено 12-08-2024 в 10:21:

Собственно, подводя итоги, можно отметить что набор для разработки в игровых движках, существует только в двух состояниях.
Первое состояние - это когда движок исторически делался для какой-то конкретной игры, поэтому там присутствует набор объектов под эту игру.
Даже если впоследствии его попытались расширить и абстрагировать.
Таков например Унреал, КрайЭнджин, Сорс. Кодобаза там большая, она на С++, как это всё работает понять очень сложно, что можно удалять, а что нельзя - тем более. К тому же ни в одной из документаций вы никогда не найдет никакой информации по этому поводу. Предполагается, что ни у кого просто не возникнет желания полностью удалить весь старый игровой код и написать полностью свой. Хотя на практике зачастую именно это и требуется.
Второе состояние - это когда в движке вообще нет никакого игрового кода, а всё что есть - это примеры разной степени похабности. Например знаменитый игровой контроллер игрока реализующий интересный эффект физики "мешок с гавном на пенсии", ну да я про него уже упоминал.
Таков например Юнити. И всё равно, многие считают, что лучше создавать кодобазу с нуля, пусть плохонькую, зато свою, чем разбираться в чужой.

Как я вижу выход из этой ситуации? XashNT, точнее его скриптовая часть, устроен таким образом что не навязывает единственно правильный способ организиации игровых объектов. Этих способов может быть несколько и все они будут законными. Например под разные типы игр. Разумеется к этому должны прилагаться сэмплы, на базе которых можно начинать делать свою будущую игру в определённом жанре.
То есть сэмпл для 2д бродилки, сэмпл для тетриса-змейки, сэмпл для 3д шутера, сэмпл для стратегии. Пока что такого плана.
То есть разработчик берёт сэмпл за основу и начинает добавлять туда уже собственный код. Я пока что не учитываю какую роль во всём этом будет занимать визуальное программирование, но не считаю, что оно должно доминировать. Просто исходя из тех соображений, что те, кто в своё время сделали ставку на визуальное программирование, проделали длинный путь, наступили на все возможные грабли и мне совершенно не хочется бежать вслед за ними. К тому же, как мы уже успели убедиться - это далеко не панацея. Должны быть и другие способы.

Добавлено 12-08-2024 в 10:25:

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

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-08-2024 в 08:06:

Цитата:

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

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

Цитата:

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

Я считаю что на данном этапе, ноды не нужны. У них ещё не достаточно сформировалась общая концепция, и если посмотреть на реализацию в популярных программах - там дикий запад. У 3д макса свои ноды, у блендера свои, у Анрила свои, у Юнити свои. Т.е. какого то общего стандарта нет.

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

Цитата:

Дядя Миша писал:
По поводу размерности игрового мира в юнитах. Переделывать движок на сантиметры или метры навряд ли будет оптимальным решением.
Лучше всего на мой взгляд вычистить из конвейера все константы, которые так или иначе завязаны на реальных привязках к юниту. Тем более что их не особенно много. Тот же OpenGL оперирует абстрактными единицами, ему всё равно что у вас - юнити ли метры. Значит надо, чтобы и движку тоже было всё равно.

Можно оставить и юниты, но в самом движке должны быть методы и инструменты для конвертации в другие единицы. Это вопрос автоматизации твоего редактора и библиотек для скриптинга.

Цитата:

Дядя Миша писал:
Надеюсь, что в NT мне удалось избавиться от большинства перечисленных недостатков. Хотя разделение на клиент и сервер всё равно остается, да и кэшировать ресурсы тоже надо.
Но благодаря виртуальной машине, сломать что-либо полностью удалив старый код будет довольно-таки проблематично.
Но опять же - хотите гибкости, которая возможно не понадобится вам в текущем проекте - значит у вас будет присутствовать код на Шоте, который вам совсем не нужен и заглядывать в него необязательно, но без него невозможна правильная работа движка. Зато впоследствии, когда вам захочется там что-нибудь изменить, вы сможете это сделать безо всяких проблем.

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

Цитата:

Дядя Миша писал:
Даже если впоследствии его попытались расширить и абстрагировать.
Таков например Унреал, КрайЭнджин, Сорс. Кодобаза там большая, она на С++, как это всё работает понять очень сложно, что можно удалять, а что нельзя - тем более. К тому же ни в одной из документаций вы никогда не найдет никакой информации по этому поводу. Предполагается, что ни у кого просто не возникнет желания полностью удалить весь старый игровой код и написать полностью свой. Хотя на практике зачастую именно это и требуется.

Ну да, ты привязан к чужой архитектуре, и никуда не денешься.

Цитата:

Дядя Миша писал:
Второе состояние - это когда в движке вообще нет никакого игрового кода, а всё что есть - это примеры разной степени похабности. Например знаменитый игровой контроллер игрока реализующий интересный эффект физики "мешок с гавном на пенсии", ну да я про него уже упоминал.
Таков например Юнити. И всё равно, многие считают, что лучше создавать кодобазу с нуля, пусть плохонькую, зато свою, чем разбираться в чужой.

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

Цитата:

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

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

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

Я не просто так показывал тебе S&Box это вот именно та халфа - песочница с закосом под Юнити. О которой ты говорил.

Это вот как работа с памятью в С++, и работа с памятью в той же Джаве или Шарпах.

Временная зона GMT. Текущее время 07:46.

Страницы (32): « Первая ... « 3 4 5 6 [7] 8 9 10 11 » ... Последняя »
Показать все 479 сообщений этой темы на одной странице

На основе vBulletin версии 2.3.0
Авторское право © Jelsoft Enterprises Limited 2000 - 2002.
Дизайн и программирование: Crystice Softworks © 2005 - 2024