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

[[CCCP] Monster]

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

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

[thsGeo]

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

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

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

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

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

И вопросов:

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

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

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

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

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

[AXEL SONIC]

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

[pokibor]

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

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


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


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

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


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

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


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


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


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

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


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

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


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

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

[Fey]

Monster;2819694]Теперь нам необходимо определиться с концепцией игры, а именно, правилами игры и ее воплощением
мм..м..а можно пример, как именно выражается, так сказать, концепция?

[GSUR]

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

[thsGeo]

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

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

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

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

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

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

[GSUR]

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

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

[[CCCP] Monster]

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

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


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

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

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


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


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


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


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


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

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


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

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

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

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

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

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


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

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


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

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


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

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

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

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

[GSUR]

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

[[CCCP] Monster]

GSUR

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

[[CCCP] Monster]

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

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

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

[pokibor]

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

[razor21]

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

[[CCCP] Monster]

pokibor

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

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

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

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

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

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

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

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

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

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

[pokibor]

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

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

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

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

Monster;2849146']
Теперь движение вращательное. Моменты инерции, моменты сил, действующих на тело. Результат их действия можно задавать как скорсоть вращения. Задаваться будет плоскость вращения и угловая скорость враения в рад/с.
Момент инерции будет один, и он - константа относительно центра масс (2D-случай же). Момент силы, соответственно, тоже один.

Monster;2849146']
Не менее важным параметром является точка - центр масс. Центр масс, думаю, нужно считать в локальных координатах объекта (т.е. на его пространственное положение действует вышеописанная матрица положения объекта).
Мне кажется, наоборот - объект сводится к поступательному движению центра масс и вращательному - точек объекта вокруг центра масс. Так что центр масс - это будет 0 в локальных координатах. А уже все остальные точки ведут отсчёт относительно этого нуля.

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

[[CCCP] Monster]

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


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

Нет, 3D физика для нас слишком. Время + пересечение трёхмерных плоскостей... нет, не потянем, как мне кажется.

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

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

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

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

[CMogilko]

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

[pokibor]

Monster;2849757']
А теперь главный твой вопрос - как считать коллижн. Берем BoundingBox вокруг машинки. Берем вектор скорости. Считаем расстояние, на которое надо подвинуть машинку до следующего кадра. Параллельно получившемуся отрезку "расстояния" откладываем пару точно таких же отрезков, так, чтобы получился прямоугольник. В конце и в начале отрезка впиливаем копию Bounding Box'а. После чего считаем пересечения с точно таким же набором отрезков, представляющих вторую машину. Там, где пересекаются, смотрим координату и соответствующее время. Ежели время не совпадает, то столкновения небыло.
Ага, щаз!
Не учтено вращательное движение (я что, просто так про синусы-косинусы говорил? или мы ими пренебрегаем?), плюс не учтено ускорение (ибо оно даёт t^2, и там уже так просто время пересечения не посчитаешь).
Иначе говоря, ты абсолютно прав, но несколько упростил исходную задачу.
В остальном согласен. Эх, сам говорю, что нужно правильно писать диздок, но самому так лениво!
Ладно, завтра будет на работе совещание важное, если в сознании останусь - попытаюсь что-нибудь набросать. ;)

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

[CMogilko]

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

[pokibor]

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

а разве в современных играх это не так? если так, то помоему, как раз это полезно.
В современных играх по-разному...

[CMogilko]

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

[[CCCP] Monster]

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


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

КРоме того про разные потоки физики и графики. Дело в том, что и физика и графика работают с одной важно штукой - матрицей преобразования объекта. Ты представляешь себе все эти критические секции (индивидуально для каждого объекта), которые надо будет нагородить для того, чтобы данные небыли разрушены в процессе взаимодействия. КРоме того, это соверщенно нецелесообразно с точки зрения производительности - игровая логика работает на коллиженах и все равно будет их считать. Засунешь в разные потоки и получишь два вызова одной и той же функции вместо одного - один для проверки столкновений с объектами и расчета скорости, а второй для расчета взаимодействия в игровой логике.

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

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

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

В современных играх используется переменная дельта времени с подтяжкой за счет нескольких последних кадров, как я говорил. Иначе Халф Лайф, разрабатывавшийся из расчета на вторые пни на современных машинах бы неверно работал. При 30 кадрах в секунду на Пне2 и фиксированной дельте ты прошел бы одно расстояние а на Пне4 при 90 кадрах в секунду - в 3 раза большее за то же время. Этого не наблюдается.

[CMogilko]

Monster;2851022]получишь два вызова одной и той же функции вместо одного - один для проверки столкновений с объектами и расчета скорости, а второй для расчета взаимодействия в игровой логике.
а зачем нам при отрисовке вообще проверять столкновения? просто берём координаты объектов и рисуем. Из-за того, что мы только берём координаты и ниразу их не изменяем при отрисовке, никаких разрушений данных быть не должно. При отрисовке для нас они константы.
Monster;2851022]При 30 кадрах в секунду на Пне2 и фиксированной дельте ты прошел бы одно расстояние а на Пне4 при 90 кадрах в секунду - в 3 раза большее за то же время. Этого не наблюдается.
вы меня, наверное, не поняли. при фиксированной дельте, FPS не зависит от этой самой дельты. Расчёт физики происходит в таймере, с периодом равном дельте, например 100 мс. Тело сделало за 100 мс какое-то перемещение, а второй поток параллельно отрисовал N раз, в зависимости от нагруженности процессора. На пне2 он не будет успевать за таймером и игра будет тормозить, на пне4 всё будет плавно.

[[CCCP] Monster]

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


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

вы меня, наверное, не поняли. при фиксированной дельте, FPS не зависит от этой самой дельты. Расчёт физики происходит в таймере, с периодом равном дельте, например 100 мс. Тело сделало за 100 мс какое-то перемещение, а второй поток параллельно отрисовал N раз, в зависимости от нагруженности процессора. На пне2 он не будет успевать за таймером и игра будет тормозить, на пне4 всё будет плавно.


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

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

[SCrat.ORS]

Гдето в начале декабря начал разработку Гонок на Delphi 2006, под DirectX и WinAPI, пока не густо, поскольку поворачивать БМП не прикольно написал на Lineto в Canvas'e с поворотом на абсолютно любой градус, немного запарился с физикой тачки, решил написать с меню, PNG, MP3, получилось неплоха. Пишу модульно, если я нужен в помощь пиште.

[WideWhale]

Может вообще сделаем так чтобы мы ездили по чистому полю и все. Ну еще рельеф сделать или город. И еще с помощью чего мы будем делать это игру. Мне надо знать заранее чтобы начать качать а то инет не очень быстрый.
ЗЫ чот все забыли что мы игру собирались делать.

[pokibor]

Vaider
Новый год, сессия, отчёты на работах, жаркие споры в теме про C#, модераторство... Продолжать? :)

[WideWhale]

pokibor
Я знаю что щас всякие экзамены. Просто около месяца прошло. Мог хоть бы один написать:sml:

[[CCCP] Monster]

Vaider

Заранее тебе говорю, что нам понадобится Visual Studio с его Visual C++, релизом 2006 года или старше, в комплектации Enterprise или Professional, желательно с интеловским компилятором, а также необходимо раздобыть SDK DirectX 9. Он находится в свободном доступе на Майкрософтовском домене (microsoft.com, если кто не понял:) ), но правда доступен только юзерам лицензионной винды. Остальные могут нагуглить.

В остальном постараюсь подготовить свой концепт игры к выходным.

[pokibor]

[CCCP] Monster
Ну не знаю, что там доступно только пользователям лицензии, но я его вроде качал без особых проблем. Впрочем, всегда есть BitTorrent и др. пиринговые сети.

Кстати, я сейчас закачал NVidia'вский NVSG и вообще-то они там неплохо постарались. Вполне возможно, что разумнее использовать его, а не DirectX, тем более что в нём точно никаких проблем с лицензиями нет. Зато есть отдельные библиотеки (!!!) для Атлона 64, уж не говоря про различные версии VS. Так что с оптимизацией всё более чем нормально.

И кстати, что это за "Visual Studio с его Visual C++, релизом 2006 года"? Я знаю VS 2005, знаю новый VS 2008 (который вроде Codename Orcas), но о 2006 не слышал. Может, ошибочка вышла?

[WideWhale]

[CCCP] Monster
У меня есть Microsoft Visual C++ 2008 но тока он Expess edition токой тож подойдет? Выше перечисленные Enterprise и Professional если я не ошибаюсь платные и соответсвенно не смогу их достать:frown: SDK DirectX 9 я как раз собирался скачать вот тока вопрос от какого месяца? Если последние выпуски то они большие но ни чего страшного.

[[CCCP] Monster]

Кстати, я сейчас закачал NVidia'вский NVSG и вообще-то они там неплохо постарались. Вполне возможно, что разумнее использовать его, а не DirectX, тем более что в нём точно никаких проблем с лицензиями нет. Зато есть отдельные библиотеки (!!!) для Атлона 64, уж не говоря про различные версии VS. Так что с оптимизацией всё более чем нормально.


Да, я читал про эту вещь, но его было бы неплохо отбенчмаркать на Радеонах еще. В зависимости от архитектуры и уровня абстракции к оборудованию у этого API, возможны различные варианты. Я не знаю, как именно организуется работа этой системы с дровами видеокарт, поэтому заранее ничего сказать о производительности не могу. Но я за то, чтобы его попробовать и тоже уже скачал СДК:)

Тем более, что по ДХ в нете полно описух. Хотя... Учить былоб неплохо и на ДХ.

И кстати, что это за "Visual Studio с его Visual C++, релизом 2006 года"? Я знаю VS 2005, знаю новый VS 2008 (который вроде Codename Orcas), но о 2006 не слышал. Может, ошибочка вышла?


Ой, да, ошибся. 2005 года релиз. Мысли в этот момент были о BDS 2006 :)


Vaider

Думаю, что ничего страшного.

[SCrat.ORS]

Всем привет,.. на мой взгляд, - вы слишком далеко лезите в дебри!
И не могу понять зачем использовать Си?,.. но дело ваше, попробуйте начать непосредственно разработку, и тогда многое на место встанет сразу, а эти слова "ни о чём" - программу не напишут...

[razor21]

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

[GameProgX]

SCrat.ORS - без плана, писать игрушку сложно, особенно если командой!
Я даже, если сам пишу игрушку, перед этим составляю план ее создание по вашему Диз-Док, что бы избежать запинок, уверенно идешь по плану и доходишь к цели. Исключения бываю, если ты не заешь, что ты хочешь создать (либо автор). Я встречал совсем другое мнение на счет ВизуалС++ и Делфи. И заметил, какждый свое хвалит.

razor21 - Си, как Си, да хоть и асамблер. Но Делфи я обожаю еще с детства и она на много удобнее чем Visual C++, особенно розцветка кода.
На которой я в С++ медленее ориентируюсь. И зачем, каждый хочет написать свой Граф-Движ, достаточно взять открытый и немного подделать для себя как пример GLScene. Ни как я вас не пойму, че-то, обьясните смысл, заново каждому изобретать велосипед, это гордсть, подвиг, самоутверджение?!?...
Кончаем оффтоп, а то головы у всех полетят вне зависимости от языка. Есть такая штука, как факты. И факты о применении в профессиональном/любительском геймдве того или иного вполне способны вас рассудить.

[Markwell]

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

[Keloraen]

Извиняюсь если пишу не туда, но обсуждение же перенесли в эту тему.

Задача выбора жанра на мой взгляд не должна быть первичной. Я бы определялся так.
Хотим сделать с нуля новый продукт (1) или модификацию(2)?
1 - Хотим писать движок сами(3) или взять один из готовых(4)?
2 - Хотим получить мод (5) или total conversion(6)?
3 - Выбираем язык, разбираемся с ним.
4 - Выбираем движок, а вместе с ним и язык программирования. Можем видеть примеры других проектов, исходные коды в достатке.
5 - Достаем инструментарий. Обычно официальный SDK, но возможно дополнительно и сторонние программы.
6 - То же что и 5, но возможно дополнительно будет необходимо разбираться в чужом коде, на разных языках программирования.

[[CCCP] Monster]

Keloraen

Ну, вообще желательно было почитать тему с начала. Создается учебный проект, с простым 2Д движком, который вообще должен показать, как работают системы моделирования процессов реального времени. При должном уровне алгоритмизации любой участник проекта в принципе сможет понять, как из такой 2Д системы сотворить 3д, и в принципе далее уже нет ограничений.

Собственно, с твоим предложением-то уже разобрались, как видишь:) Поэтому теперь жанр и определяем. Вернее, определили уже. Осталось реализовать.

[_†DAMIAN†_]

Monster;3645253']
Собственно, с твоим предложением-то уже разобрались, как видишь:) Поэтому теперь жанр и определяем. Вернее, определили уже. Осталось реализовать.
Как там дела с реализацией?