Форумы
Вселенная аллодов
22.07.2014, 02:03
Пока в данный момент работаю с полной базой данных на ЗВА, потом перейду на ПЗ. Предстоит очень много работы.
Буду пробовать различные игровые движки для полного переноса Аллодов 1-2, ПЗ и ЗВА, а также создания Аллодов 5. Пока сингл. Поскольку с сетевыми протоколами не дружу.
Базу впоследствии выложу в BMP в архиве, а также в PDF.
База помощи - Здесь будут скрины обучения из ЗВА.
База квестов - Здесь будут скрины прохождения ПЗ и ЗВА, и возможно добавлю много позднее прохождение Аллодов 1-2.
База оружия - Обработанные скрины всех видов оружия, прототипное оружие, прототипные приспособления, прототипные щиты (атака-защита).
База брони - Обработанные скрины лёгких и тяжёлых доспехов по отдельности.
База зелий - Обработанные скрины зелий (жезлы не войдут в этот раздел).
База жезлов, и прочего - Обработанные скрины ученических жезлов, прототипные короткие посохи подмастерьев, прототипные посохи магов.
База плащей и регалий - Здесь будут представленны прототипные плащи для воинов и магов, прототипные накидки на броню типа фамильных регалий, прототипная реликтовая броня и оружие именного типа.
База монстров - Скринная вырезка оформленная в информационный лист.
База классов - Прототипное деление на классы игрового персонажа, с дополнительными бонусами.
База материалов - Обработанные скрины материалов обычных и прототипных.
Как будут выглядеть базы оружия и брони пока не решенно, но возможно я их тоже подвергну обработке.
Также планируется создать настольный проект, который по сути станет прообразом скелета игры (графика в виде статичных изображений, игровая механика в виде текстов и просчитанных таблиц, квестовая составляющая).
Возможно не один игровой движок для моего проекта не подойдёт, поскольку он весьма сложен для реализации современными движками.
Точнее: мне не нравится структура базы данных - она отстойна как и все мировые базы данных - планируется создать блок вмещающий другие блоки, а те в свою очередь сеть блоков - каждый блок должен будет иметь уникальный идентификатор, который будет считываться блоком определителя индексов и далее отдавать потоки в блок маршрутизации, который в свою очередь прогонит потоки сквозь блоки предварительной синхронизации, и далее погонит потоки в ЦП, ГП, АП, ОЗУ, на Хард, на Монитор, и другие устройства. В этом случае база данных в современном понимании вообще ненужна. Сам блок уже есть унифицированная база данных типа Матрёшка. Или коробка в коробке, для лучшего понимания идеи. Например: Блок загрузки программы - всего лишь цифровая кнопка Пуск, Блок определителя железа и ПО - формирует план загрузки программы в соответствии с мощностью и возможностями оборудования на котором запускается программа включая инструкцию загрузки приложения в зависимости от ОС, Блок загрузки меню - без комментариев, в зависимости от выбора Другие Блоки, естественно включающие полный набор всего необходимого. Пример 2: Блок Мира - Блок Континента - Блок Зоны - Блок Локации (Блок Музыки) - Блок Заданий - Блок Динамических и Статических Объектов - Блок Объекта - (Блок Текстур - Блок Модели - Блок Морфинга - Блок Механики - Блок Звука). Блок Фильтра игрового движка, а также редактора и готового приложения - работает по заданным скриптом фильтрам. Например: загружен редактор - разработчик открывает звук - редактор не грузит всё остальное, а только показывает список звуков считывая блоки с звуковыми индексами в соответствии с установками фильтра, чтобы не искать немерянно долго необходимый звук - разработчик выбирает локацию и объект, но загружается только привязанный к локации или объекту звук - неважно это звук анимации, фона или интерфейса. Меняя установки фильтра можно добиваться вывода любой информации для отладки. Например: музыкант пишет музыку для локации и одновременно созерцает её в виде готового рендеринга, художник слушает музыку и вдохновлённый музыкой отрисовывает локацию или иное, программист пишет скрипт или код и одновременно видит к чему приводят вносимые им изменения, чтобы кто не менял - эти изменения в виде изменённых блоков разносятся на все машины разработчиков, что позволяет более эффективно заниматься разработкой приложений, плюс чат и видеоконференция, общая или приватная. Все блоки должны иметь режим горячей замены, а также буфер для сохранения старых образцов, и режим песочницы для отладки некорректно работающего блока. Вообщем ничего нового - идея на моя, я лишь чуточку развил её и довёл до ума. Синклар предлагал подобное, но IBM нужны были маленькие быстрые коды, а не большие и медленные. Потому идея умерла не успев родиться. Хотя ряд устройств всё же делается по этому принципу, в основном в военной технике.
Подробнее об проекте Движок Нового Поколения раскажу как-нибудь позжее.
Прилаживаю пробные скрины! Поддержки не прошу, поскольку ещё много предстоит работы Вокруг да Около! А отнимать свободное время подло...
Буду пробовать различные игровые движки для полного переноса Аллодов 1-2, ПЗ и ЗВА, а также создания Аллодов 5. Пока сингл. Поскольку с сетевыми протоколами не дружу.
Базу впоследствии выложу в BMP в архиве, а также в PDF.
База помощи - Здесь будут скрины обучения из ЗВА.
База квестов - Здесь будут скрины прохождения ПЗ и ЗВА, и возможно добавлю много позднее прохождение Аллодов 1-2.
База оружия - Обработанные скрины всех видов оружия, прототипное оружие, прототипные приспособления, прототипные щиты (атака-защита).
База брони - Обработанные скрины лёгких и тяжёлых доспехов по отдельности.
База зелий - Обработанные скрины зелий (жезлы не войдут в этот раздел).
База жезлов, и прочего - Обработанные скрины ученических жезлов, прототипные короткие посохи подмастерьев, прототипные посохи магов.
База плащей и регалий - Здесь будут представленны прототипные плащи для воинов и магов, прототипные накидки на броню типа фамильных регалий, прототипная реликтовая броня и оружие именного типа.
База монстров - Скринная вырезка оформленная в информационный лист.
База классов - Прототипное деление на классы игрового персонажа, с дополнительными бонусами.
База материалов - Обработанные скрины материалов обычных и прототипных.
Как будут выглядеть базы оружия и брони пока не решенно, но возможно я их тоже подвергну обработке.
Также планируется создать настольный проект, который по сути станет прообразом скелета игры (графика в виде статичных изображений, игровая механика в виде текстов и просчитанных таблиц, квестовая составляющая).
Возможно не один игровой движок для моего проекта не подойдёт, поскольку он весьма сложен для реализации современными движками.
Точнее: мне не нравится структура базы данных - она отстойна как и все мировые базы данных - планируется создать блок вмещающий другие блоки, а те в свою очередь сеть блоков - каждый блок должен будет иметь уникальный идентификатор, который будет считываться блоком определителя индексов и далее отдавать потоки в блок маршрутизации, который в свою очередь прогонит потоки сквозь блоки предварительной синхронизации, и далее погонит потоки в ЦП, ГП, АП, ОЗУ, на Хард, на Монитор, и другие устройства. В этом случае база данных в современном понимании вообще ненужна. Сам блок уже есть унифицированная база данных типа Матрёшка. Или коробка в коробке, для лучшего понимания идеи. Например: Блок загрузки программы - всего лишь цифровая кнопка Пуск, Блок определителя железа и ПО - формирует план загрузки программы в соответствии с мощностью и возможностями оборудования на котором запускается программа включая инструкцию загрузки приложения в зависимости от ОС, Блок загрузки меню - без комментариев, в зависимости от выбора Другие Блоки, естественно включающие полный набор всего необходимого. Пример 2: Блок Мира - Блок Континента - Блок Зоны - Блок Локации (Блок Музыки) - Блок Заданий - Блок Динамических и Статических Объектов - Блок Объекта - (Блок Текстур - Блок Модели - Блок Морфинга - Блок Механики - Блок Звука). Блок Фильтра игрового движка, а также редактора и готового приложения - работает по заданным скриптом фильтрам. Например: загружен редактор - разработчик открывает звук - редактор не грузит всё остальное, а только показывает список звуков считывая блоки с звуковыми индексами в соответствии с установками фильтра, чтобы не искать немерянно долго необходимый звук - разработчик выбирает локацию и объект, но загружается только привязанный к локации или объекту звук - неважно это звук анимации, фона или интерфейса. Меняя установки фильтра можно добиваться вывода любой информации для отладки. Например: музыкант пишет музыку для локации и одновременно созерцает её в виде готового рендеринга, художник слушает музыку и вдохновлённый музыкой отрисовывает локацию или иное, программист пишет скрипт или код и одновременно видит к чему приводят вносимые им изменения, чтобы кто не менял - эти изменения в виде изменённых блоков разносятся на все машины разработчиков, что позволяет более эффективно заниматься разработкой приложений, плюс чат и видеоконференция, общая или приватная. Все блоки должны иметь режим горячей замены, а также буфер для сохранения старых образцов, и режим песочницы для отладки некорректно работающего блока. Вообщем ничего нового - идея на моя, я лишь чуточку развил её и довёл до ума. Синклар предлагал подобное, но IBM нужны были маленькие быстрые коды, а не большие и медленные. Потому идея умерла не успев родиться. Хотя ряд устройств всё же делается по этому принципу, в основном в военной технике.
Подробнее об проекте Движок Нового Поколения раскажу как-нибудь позжее.
Прилаживаю пробные скрины! Поддержки не прошу, поскольку ещё много предстоит работы Вокруг да Около! А отнимать свободное время подло...