Выработка концепции для учебного игрового проекта
 

Итак, можно сказать, что с жанром мы определились. Это будут гонки

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

Есть несколько предложений:

1. Несколько видов гонок: круг и дрэг, можно еще чего-нибудь.

2. Смена раскраски автомобиля, хотя бы только основной цвет. Можно реализовать через шейдры.

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

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

И вопросов:

1. В чем будут создаваться трассы? В 3dmax целиком с последующей загрузкой, или в спец редакторе из отдельных объектов и поверхности с картой высот? + если все в 3dmax, то все равно где-то надо описывать триггеры на финиш etc.

2. Кто будет моделировать машины? И сколько их будет? В принципе можно связаться с авторами машин для GTA и попросить разрешения использовать их творения в нашем проекте.

3. Насколько сложной будет физическая модель машин?

4. Какова реалистичность? Разбиваются машины или нет?

5. Какие это гонки? Ралли, формула1, стрит-рейс?

А чему именно должна обучать игра?

[CCCP] Monster, всё-таки сейчас мы проектируем ядро игры - это не помешает отметить. Нам нужны глубины реализации, а не её поверхностная часть. Если глубины потребуют конкретного определения поверхности - уточним, если нет - тем лучше и универсальнее будет ядро проекта.
Посему в рамках "учебности" проекта внесу ясность:
К базовой концепции отношения не имеет. Виды гонок - это правила, в соответствии с которыми рассчитывается победа/поражения игрока. В ядро игры их зашивать бессмысленно и откровенно вредно. Скорее, они потом будут добавлены как расширение ядра.

Простите, но это вообще имеет отношение только к движку, причём ещё не ясно, какой он будет.

Достаточно интересная физика; вот это - действительно идея для диздока. Но я предлагаю ограничиваться стандартным управлением с клавы. Не представляю себе "микромашинки" с рулём. :sml:

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

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

Этот вопрос вообще к диздоку не относится.

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

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

Имеет отношения к базовой концепции ещё меньше, чем вопрос №1. Однако точно не формула - там слишком высокие скорости.

AXEL SONIC
Своему созданию.

мм..м..а можно пример, как именно выражается, так сказать, концепция?

С чего именно начинать и как мы будем работать, каждый одинаково как и все пишет у себя (на форуме предложения толкать будем) или соединять потом будем.:confused:

Так что же мы здесь обсуждаем? Концепт игры (задача геймдизайнерская) или проектируем ядро (для программистов)? Игровой концепт должен давать общее представление об игре с упором на основные фичи таким образом, чтобы у любого (ну или почти любого...), кто прочитает это документ, создалось некое представление об игре, а не знание некого набора уравнений. Чтобы читатель мог мысленно поиграть в эту игру. Вопрос 1 и предложение 5 на это и направлены. Ну а вопрос 2 все же не в тему :wnk:

Согласен. Я не говорю про вшивание в ядро игры. Лично я сторонник того, что в ядре должны быть зашиты только некие правила, использование точных значений надо свести к минимуму, их можно грузить из файлов. Антипример: HoMM5, где все прошито в коде.

Лично я за то, чтобы каждый работал над определенным кусочком, а потом все это соеденить. Это позволит давать участникам задания в соответствии с их знаниями.

,В первом варианте я предлагал на форуме писать то, что у тебя, и все будут списывать, потом придумывать или додумывать, как по лучше это сделать и опять же выносить на форум.
Хотя второй тоже мене больше нравиться.

1. Это правила игры, решается триггерами. Желательно более полно все это продумать, дабы мы могли решит, какая реализация триггеров и областей нам понадобится.

2. Делается текстурами. Несложно.

В Operation Flashpoint реализовано аналогичное управление техникой. Идея хорошая, такой режим можно прикрутить. Однако его реализация, скажем, в двумерной версии сомнительна. В любом случае, будущее покажет.


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


Моделировать или рисовать большое количество машин нам не нужно, поскольку проект обучающий. Однако, думаю, что здесь на форуме найдутся люди, готове предоставить свои модели или создать новые. В том числе я, как 3Д Максер с 8-летним стажем:)

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

В первой версии они не будут деформироваться. В крайнем случае деформации будут чисто текстурными (скин будет на побитый меняться). Дальше посмотрим, в процессе "наворачивания" графики и физики, когда основа проекта будет закончена полностью и он будет играбельным.

Именно это было бы замечательно выяснить в рамках концепции.

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

Верно, но отчасти. Дело в том, что зависит это от реализации в первую очередь графической составляющей, т.е. рисуемой карты. Например, АТИ и НВидиа предлагают технологию записи в вершинный буфер, который можно использовать как для расчетов физики, так и для вывода геометрии. Можно также использовать массив высот, представленных точками типа float, или использовать карты высот с двухбатовыми значениями высоты. Так или иначе, но нам нужно определиться с размерами игрвого мира и тем, как именно будут реализованы поверхности. Если весь уровень сделать в 3ДМаксе, то совершенно ясно, что карты высот отпадают.

КОНЦЕПЦИЯ ж. лат. понятие, образ понятия, способ пониманья, соображения и выводы. (слогласно словарю Даля)

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

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

[CCCP] Monster
Полагаю основу будете делать вы с pokibor'ом, но её написание то вы дадите? Тоесть с помощью чего и как вы это сделали?

GSUR

Да, разумеется:) Мы выложим полное описание архитектуры, дадим рекомендации, скажем, почему использовали именно такой вариант, а не другой. Ведь в этом и есть цель учебного проекта:)

Ну что, все закисли?

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

Нужно определить, как все это будет выглядеть. Кроме того, мы должны будем написать редактор трасс и редактор автомобилей.

Я за обсуждение в первую очередь ядра, и, собственно, физики. Скрипты, трассы и т.п. - это хорошо, но это находится над физикой. Мы же сейчас не обсудив фундамент пытаемся обсудить крышу. Итак, вопросы следующие:
1) Как будут задаваться машины? Я вижу такие варианты:
- простой - прямоугольник и только он
- также простой, возможно, даже проще предыдущего - набор сфер
- система отрезков; многоугольник
2) Как будут задаваться препятствия:
- система отрезков, многоугольник
- аналогично предыдущему пункту, но при приближении автомобиля вдоль отрезков будут выстраиваться сферы, что облегчит рассчёт пересечений
- Довольно изощрёный способ - как уравнение. Тут можно задать что угодно, но как определять пересечения? Хотя методы решения системы из двух уравнений есть.
3) Как будет вообще рассчитываться физика?

pokibor
ИМХО: я считаю, что и автомобили и препятствия нужно представлять в виде наборов сфер. Это мое предложение.

pokibor

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

Насчет физики - не совсем ясно, 2Д или 3Д, но поскольку упомянуты сферы, пусть будет 3Д.

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

По физике вообще. Любой объект, с которым возможно взаимодействие в игрвом мире должен обладать несколькими основными параметрами. Во-первых - скорость. Думаю, представить ее в виде вектора. Длина вектора будет у нас величиной скорости. Второй параметр линейного движения - ускорение, представим аналогично скорости. Теперь движение вращательное. Моменты инерции, моменты сил, действующих на тело. Результат их действия можно задавать как скорсоть вращения. Задаваться будет плоскость вращения и угловая скорость враения в рад/с.

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

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

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

Важное дополнение:

Также есть параметр "дельта времени" - время, которое занял обсчет игрового цикла (время между сменой кадров, величина, обратная FPS). Это время будет использоваться для расчетов физики и изменений в сцене. К примеру, для того, чтобы вычислить, на сколько нужно переместить объект, обладающий скоростью v=1м/с, если известно, что время между сменой кадров t=0.037 сек. Нужно просто умножить v*t, и в итоге получится 0.037 метров. Вычислять думаю с помощью функции получения значения системного счетчика времени. Такой метод позволяет на компах с разной производительностью моделировать течение времени игрвого мира без проблем с задержкой (или ускорением времени). Однако время между кадрами иногда меняется, из-за совпадения перидоа чтения из видеобуфера ЦАП и записи туда нового кадра, что приводит к рывками дерганию ФПС. Для предотвращения такого эффекта считаю необходимым расчитывать среднее значение дельты времени за последние 5 кадров.

Кроме того, умножив дельту времени на коэффициент времени можно увеличить или замедлить ход времени в игровом мире.

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

Нет, 3D физика для нас слишком. Время + пересечение трёхмерных плоскостей... нет, не потянем, как мне кажется. Насчёт сфер - не обращайте внимания, я когда говорю о сферах, имею в виду окружности ;)
Я понимаю физику как 2,5-мерную, скажем так. Т.е. силы будут чётко разделяться на действующие по вертикали (тяжесть) и горизонтали (сила тяги, сила реакции опоры и соударении и т.д.). То есть гонка по сути будет всё же 2-мерной.

Пересечение двух отрезков (в нашем случае) считается довольно просто, да. А вот многоугольник в пространстве... по моему, сложновато для первого проекта. Хотя пересечение полигонов двух, конечно, можно сделать...
И, кстати, мы так до сих пор и не определились, что будем ли двигаться на дискретное время каждый раз или всё-таки будем рассчитывать момент времени, когда происходит касание. Второй алгоритм куда сложнее, поверь мне. Там нелинейное уравнение со временем под синусами-косинусами от вращательной компоненты выходит...

Момент инерции будет один, и он - константа относительно центра масс (2D-случай же). Момент силы, соответственно, тоже один.

Мне кажется, наоборот - объект сводится к поступательному движению центра масс и вращательному - точек объекта вокруг центра масс. Так что центр масс - это будет 0 в локальных координатах. А уже все остальные точки ведут отсчёт относительно этого нуля.

Насколько будет легко эту физическую модель сделать, да ещё так, чтобы она не тормозила... :confused:

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

Мы-то с тобой потянем, но вот наши падаваны будут вынуждены курить план Путина, чтобы понять о чем речь вообще.

Тогда определяемся. 2Д микромашинки с видом сверху, реализованные в "условно трехмерной" среде. Т.е. координата Z будет нам предоставлена самим графическим API (Директ3Д или OpenGL), но мы ее не будем использовать при выводе графики (пока что), кроме как для подвещшивания камеры на заданном расстоянии от "земли".

Соответственно ландшафт у нас будет плоским. Объекты будут представлены как второй слой над ландшафтом. У объектов будут ограничивающие многоугольники. Чтобы узнать о столкновении, достаточно узнать о пересечении пары отрезков.

А теперь главный твой вопрос - как считать коллижн. Берем BoundingBox вокруг машинки. Берем вектор скорости. Считаем расстояние, на которое надо подвинуть машинку до следующего кадра. Параллельно получившемуся отрезку "расстояния" откладываем пару точно таких же отрезков, так, чтобы получился прямоугольник. В конце и в начале отрезка впиливаем копию Bounding Box'а. После чего считаем пересечения с точно таким же набором отрезков, представляющих вторую машину. Там, где пересекаются, смотрим координату и соответствующее время. Ежели время не совпадает, то столкновения небыло.

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

Ага, щаз!
Не учтено вращательное движение (я что, просто так про синусы-косинусы говорил? или мы ими пренебрегаем?), плюс не учтено ускорение (ибо оно даёт t^2, и там уже так просто время пересечения не посчитаешь).
Иначе говоря, ты абсолютно прав, но несколько упростил исходную задачу.
В остальном согласен. Эх, сам говорю, что нужно правильно писать диздок, но самому так лениво!
Ладно, завтра будет на работе совещание важное, если в сознании останусь - попытаюсь что-нибудь набросать. ;)

CMogilko
Верно предложение, но тогда придётся каким-то образом подстраиваться под возможности конкретного процессора компьютера. Хотя в нашем простеньком проекте при возможностях современных процессоров такой вопрос не стоит, но всё же с учебной точки зрения это ни есть хорошо, как говорит [CCCP] Monster.

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