Даю 3% вероятности, что из всего этого может что-то выйти. Но идейка очень приятная.


Если действительно браться за создание нового движка, то самое главное, чего не хватало в старом - универсальности. Предлагаю лечить это так: сделать ВСЁ в игре (включая даже вылет отдельной пули из ствола) завязанном на "событиях", легко доступных при написании квестовых и геймплейных скриптов.
Реализация мне видится такая: когда что-то случается (механоид прыгает/влетает в здание/поворачивается/врубает форсаж; товар падает на землю, пуля вылетает из ствола, ракета взрывается - перечислять можно долго... словом, когда что угодно происходит), "движок" посылает название события и все соответствующие характеристики, с ним связанные (событие:"выстрел";урон:"100";наименование:"ЛучЛазТ1";координаты:"736/433";атаковавший: "SINIGR01"; и т.д.), в особую функцию. Особая она тем, что содержит "ссылки" на скрипты, "привязанные" к каждому виду события. Так что когда что-то случается, функция просматривает условия всех "зарегистрированных" на это событие скриптов, и если условия запуска скрипта выполняются (урон:">99";наименование:"";координаты->x:"<985>100";координаты->y:"<500>250"; атаковавший: "SINIGR01"; и т.д.), он идёт на исполнение. Так можно сделать равноправными ВСЕ скрипты, от квестовых до кода ИИ или даже управления патроном (ну, это уже, возможно, лишнее, но принцип понятен, я думаю).
Разумеется, это все не я придумал - так, судя по всему, работает Warcraft III, на стратежном движке которого я без проблем даже ролики делал (полноценные мультики просто лень было ). И я бы не осмелился сказать, что ресурсов этот принцип много жрёт... Но вот функциональность необъятная.

_________________
Сообщество креативных механоидов:
aim-fans.ru

2 Шаман
А проц-то не треснет, на каждое событие реакцию проверять? А если сразу 5-6 глайдеров из трехствольных атомок начнут палить, не будет ли жуткого лага? Плюс координаты.
Есть в С++ удобный механизм реализации этого - исключения. Есть еще сигналы, но они ресурсоемки...

Это ты о каком языке?

Это скорее всего скрипт какой-то. Интерпретатор только нужно правильно подобрать.

_________________
_=S.A.L.K.E.R.=_
"Кто кого еще порвет" - сказала Тузику грелка, надутая до 10 атмосфер
"У нас большие леса. Они способны без остатка поглотить любое воинское формирование" (с)

пусть если на то уж пошло хоть форум то оставьте, ИБО ПРИДУТ НА ЭТОТ ФОРУМ ДРУГИЕ ИЗДАТЕЛИ, В ЧЬИХ ФИРМАХ РАБОТАЮТ СОЗДАТЕЛИ МЕХОНОИДОВ, И ДА ПОСМОТРЯТ СКОЛЬКО ЛЮДЕЙ ГОТОВЫ ТРАТИТЬ НА НИХ СВОИ ДЕНЬГИ, И СОЗДАДУТ 3ИХ МЕХОНОИДОВ, И ДА ВОЗРАДУЮТСЯ ЛЮДИ ТОГДА!!!!!!

_________________
Я вам не гринпис, твари!
№ ICQ 491-966-131

2 --GAZ-- Сразу две плюхи. За дублирование сообщений и залипший капслок.
За невнимательность уж не буду, ибо - не в тему, да и никто форум закрывать не собирается.

_________________
-=S.A.L.K.E.R.=-
Хорошо ухоженный бобёр отталкивает воду.

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

_________________
Я вам не гринпис, твари!
№ ICQ 491-966-131

2 Славон, красавчик...так редко кто огребается..=)
2 Шаман, Razum лучше собрать толковый народ и помогать разработчикам, если будут М3.

_________________
file:

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

Есть только одно "НО"...
Если ты - разработчик определенной игры, то ты уже не геймер этой игры.
(а зачастую разработчик - не геймер вобще )
А я хочу поиграть в М3... (может это и эгоистично, зато правда)

_________________
"IСQ - ЗЛО" полностью поддерживаю...

Имхо, это значит, что ты хреновый разработчик.

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

_________________
Сообщество креативных механоидов:
aim-fans.ru

Сомневаюсь что много людей читают эти сборники.

_________________
https://sites.google.com/site/intelligencecells
http://www.youtube.com/user/IntelligenceCells

Он разработчикам делает. А остальные уже давно прибор положили. Да и разработчики, похоже, тоже.

Хм, мне кажется, топик задумывался как некое аккультное место для тех, кто имеет желание склепать М3, написать код в домашних условиях, такскать. Попытаюсь продолжить идею в этом русле. Не С++шников прошу меня не слушать.
Приснилось мне такое устройство движка:
1) Движок умеет генерить некоторый набор типов событий. К примеру, загрузка карты, нажатие клавиши, изменение положения объекта в пространстве и т.д. Ну, собсно, в первом посту так примерно и изложено.
2) Движок обладает набором утилит и данных, определяющих все игровые фичи, и эта феня упакована в известную всем и вся структуру.
3) На каждый тип события есть свой EventHandler, прогоняемый движком каждый раз, как сгенерится событие. Суть EventHandler'а - при каждом своём запуске выполнять по-порядку все функции, прописанные в данное событие (бинарные скомпилленные скрипты), передавая каждой из них:
а. указатель на структуру, содержащую информацию о событии (для каждого типа события своя определённая структура данных)
б. указатель на структуру, где находятся все фичи движка.
Таким образом, скрипты могут управлять всем и вся, и ничто не будет жёстко прописано в коде движка.
Но основная идея - компиллировать скрипты отдельно в независимые функции и сохранять сий бинарный код тела функции в файл, откуда при запуске игры они будут считаны, загружены в память, и прилинкованы каждая к своему EventHandler'у.
На домохозяйственном уровне, это мне представилось так: EventHandler - это DynamicArray, содержащий указатели на все исполняемые скриптофункции и алгоритм, запускающий по очереди каждую из этого "списка", пиная проц по соответствующему адресу.
А вопросы "простые": как писнуть функцию, чтобы после компилляции она была такой самостоятельной, чтобы её бинарное тело можно было сохранить в файл, а потом загрузить в память и прилинковать? Насколько я понимаю, в ассемблере никаких проблем всё это проделать не возникло бы (знаю, хотя и ни разу на сиим не программил ). Но как в С++?
Если кто-то понял идею, и может на домохозяйском левеле дать указания...

_________________
Сообщество креативных механоидов:
aim-fans.ru

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

Подкопились небольшие наработки по программульканью, возможно, пригодится всем, кто с 3D борется. Я тут написал структурку "Камера" - вспомогательный объект для перемещения в 3-хмерной сцене. Полную подробную документацию, коды, пример использования (ехе-шник) выкладываю тут (архив, 238 Кб):
http://www.mediafire.com/?qzn02zm2dvf
Особо допытливые могут выдрать оттуда кучу полезностей по инициализации и начальным настройкам OpenGL, а в хеадере Grid.h описаны функции по рисованию сетки и системы координат - не в тему, но если.

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

_________________
Сообщество креативных механоидов:
aim-fans.ru

Классно.
Мышкой бы еще.

...Ландшафтик бы вместо сетки... ...Плавно-переходящие одна в одну текстурки...

_________________
Сообщество креативных механоидов:
aim-fans.ru

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

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

Добавлено спустя 47 минут 24 секунды:

Аха! Знач, во как оно делается...
Сперва, нужно включить подходящий способ теста глубины и функцию смешивания:
glEnable(GL_DEPTH_TEST); glDepthFunc(GL_LEQUAL);
glEnable(GL_BLEND); glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
В принципе, это есть наиболее употребимые настройки, так что можно задать их такими изначально.
Теперь саму фишку талдычить буду.
Если в некотором объекте нужно смешать по-ровну N текстур,
то нужно отрисовать этот объект N раз, причём каждый раз прозрачность объекта должна уменьшаться по следующей схеме:
Alpha = (N-n)/N,
где n - номер цикла отрисовки (в первом цикле n=0, в последнем - n=N-1). Т.е. в первом цикле отрисовки прозрачность объекта должна быть 1 (непрозрачный), а в последнем - 1/N.
Практический пример
[Будем считать, вы знаете, как в OpenGL текстура накладывается. ]
Нужно смешать на кубе 3 текстуры.
Функция рисующая куб Alpha-непрозрачости и накладывающая на него текстуру с цифровым именем TextureID:
void DrawCube(float Alpha, unsigned long int TextureID);
Переменные, содержащие номера текстур:
unsigned long int Ta = ... ;
unsigned long int Tb = ... ;
unsigned long int Tc = ... ;
Тогда цикл отрисовки куба, в результате которого поверхность будет представлена смесью трёх текстур будет выглядеть так:
DrawCube(3/3, Ta);
DrawCube(2/3, Tb);
DrawCube(1/3, Tc);
Проверено на работоспособность - вклад каждой текстуры равноценен [штампующий смайляро].

Добавлено спустя 2 минуты 16 секунд:

Осталось только к рельефу применить.

_________________
Сообщество креативных механоидов:
aim-fans.ru

А тебе не кажется, что при данном способе у тебя на ребре между треугольником с одной текстурой и треугольником с несколькими текстурами будет резкий переход. Поясню на простом примере.
Есть три квадрата в виде полосочки, примыкающие друг к другу, слева на право.(будем считать их неделимой единицей отрисовки, хотя это и не принципиально). Левый квадрат черный, а правый - белый, а средний между ними должен обеспечить плавный переход от черного к белому. Используем способ Шамана.
что получаем? Рисуем, как я понял, заместо среднего два квадрата - один черный, со значением прозрачности 1, один белый, со значением прозрачности 0,5. получим, если я не ошибаюсь, по всей грани некий серый однородный цвет. А плавного перехода не будет.

Добавлено спустя 5 минут 22 секунды:

Да и вообще, рисовать объект n раз?.. А если у нас очень сложный объект с большим количеством треугольников и штук пять текстур? У компа ниче не треснет столько отрисовывать? Должен быть, имхо, более удобный и производительный способ.

Вообще-то, я привёл пример, как вообще ХОТЬ КАК-ТО замесить текстуры. Этот способ объясняет лишь принцип мультитекстурирования (МОЁ логическое умоизлияние на тему) - перерисовку столько раз, сколько текстур надо наложить. ИМХО, иначе никак, бо за раз можно наложить лишь одну тестуру, т.к. функцию её привязки (glBindTexture) можно вызывать лишь вне цикла glBegin-glEnd. А реальное мультитекстурирование с использованием какого-то ARB-расширения имеет лимит на количество текстур и не всеми картами поддерживается (я рыл вопрос 2 дня... ). Так что, во всяком случае в OpenGL, иного способа нет, кроме как перерисовка не менее стольких раз, сколько текстур надо наложить.
Но! В случае рельефа не вся карта будет несколько раз перерисована - лишь те её малые части, что лежат на границе областей, которые заполнены одинаковыми текстурами.
Моя генеральная идея такова: отрисовывать каждую монотекстурную область отдельно.

_________________
Сообщество креативных механоидов:
aim-fans.ru

Да ну не надо. Если ты не знаешь, как, то это не значит, что нельзя. В ОGL можно сделать очень сложные текстурные эффекты, и я сильно сомневаюсь, что это сделано путем перерисовки объектов по нескольку раз. Во-первых, можно использовать т.н. render to texture, который позволит наложить на объект вообще как угодно замиксованные текстуры.
Шаман, ты знаешь, как сделать, чтобы окружающая среда отражалось на предмете? Хотя бы для случая, когда поверхность предмета идеально зеркальная.

Не, пока что работу с материалами не осваивал - только наложение текстур профильтровал.
2 Razum: вот, где я пасусь:
http://pyopengl.sourceforge.net/documentation/manual/
http://www.opengl.org/sdk/docs/man/
[ Отсюда начинал - http://pmg.org.ru/nehe/index.html ]
Не видел я ничё подобного "gl[u][t]RenderToTexture".

_________________
Сообщество креативных механоидов:
aim-fans.ru

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

И вот, знач, к чему я пришёл в плане рисовки ландшафта:

1) Нарисовать "подложку" - лишь с целью заполнить буфер глубины и обнулить ВСЕ цветовые составляющие пикселов, попавших под рисовку рельефа. Для этого отключаем всё, что только можно:
glDisable(GL_TEXTURE_2D);
glDisable(GL_COLOR_MATERIAL);
glShadeModel(GL_FLAT);
glDisable(GL_LIGHTING);
glDisable(GL_ALPHA_TEST);
glDisable(GL_BLEND);
glColor4f(0,0,0,0);
Теперь рисуем "ландшафт" - кормим OGL ЛИШЬ ВЕРШИНАМИ. Раз всё отключено, цвет отрисованного ландшафта будет чёрным, альфа-компонента - равна нулю. Сие действо очистит цветовой буфер в области рисовки поверхности ландшафта и заполнит буфер глубины. Эта на первый взгляд бессмысленная операция по рисованию "ничего" нужна вот для чего: когда отдельные монотекстурные области карты будут отрисовываться, "подложка" предотвратит образование полупрозрачных дырок на границах этих областей.
Ну и не забудем вернуть всё обратно после рисования подложки:
glEnable(GL_BLEND);
glEnable(GL_ALPHA_TEST);
glEnable(GL_LIGHTING);
glShadeModel(GL_SMOOTH);
glEnable(GL_COLOR_MATERIAL);
glEnable(GL_TEXTURE_2D);

Далее принципиальный нюанс. Я тщательно копнул момент рисования текстур в реде Мехов. Каждой вершине присваивается "главная текстура". Если две соседние (слева-справа-сверху-сбоку - не по диагонали!) вершины имеют разные текстуры, они плавно переходят друг в друга.
Т.е. если рядом две вершины V1 и V2, на первой текстура T1, на второй T2, то при рисовке областей с текстурой T1 непрозрачность вершины V1 будет 1, а V2 - 0. Аналогично и с текстурой T2. Таким образом они плавно равноценно перейдут друг в друга. Плавность не нарушится и в случае, когда рядом контачит 5 текстурных областей (по принципу крестика это максимум).
Так что второй этап рисования рельефа такой:

2) Отрисовать каждую монотекстурную область отдельно, причём расширить границу на 1 и сводить там непрозрачность к 0. Таким образом получится, что граничные области будут перерисованы несколько раз.

Вроде бы так...

_________________
Сообщество креативных механоидов:
aim-fans.ru

Раз пошла такая пьянка, то не разумнее бы было заделать М3 как мод к какой-то игре с подходящим и гибким движком. Тот же Unreal Tournament во что только не переделывался. А жить уже все легче - движок не нужен, основа есть, документация кой-какая.

Я о Spring думал, но разработчики модели вряд ли дадут.

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