Красивые, но тормозные "ручные" 3d Api, создание Moto 3D API для FPS,QUEST,RPG Поделиться Опции

[Nick-85]

Красивые, но тормозные "ручные" 3D API, написанные полностью на Java можно использовать, например, для создания очень красивых квестов, RPG, стратегий и любых др. типов приложений, в которых допустимо длительное время первоначальной загрузки картинки, а также для полноценного играбильного real-time отображения трёхмерных объектов в небольшой области экрана.
Если вы желаете принять участие в разработке, то просто оставьте своё сообщение в данном топике.

Ниже OFFTOP:
А если вас переполняют негативные эмоции, то вам целесообразно обратиться к психиатру... или к эзотерикам на какой-нибудь bodhi.ru.

[Nick-85]

To 4ep:
- Я бы хотел клёвые гоночки со стрельбой и динамичным игровым процессом.
- Если чего - то рисунки машин, героев, трасс, характеры героев, и сюжет с меня.
"Концепт-артная" идея №1.

hobbit19:
- первое гонки с офигенной графикой типа асфальта но чтобы игра не надоедала предлагаю
- сделать в ней возможность апгрейдов машин трасс ( апгрейды сделать онлайн т.е человек прошедший трассу мог скачать новую с сети и тд) - тагже что то типа рейтинга играков
Где взять отдельный сервер?
Я думал только над вариантом - купить хостинг с поддержкой средств платформы J2EE и исп. их.

To pro123:
- Извените, если я чего-то не понимаю, но суда по fps при вращении обычного текстурированного кубика на e398, которое равно 1 - игру на - таком движке сделать невозможно! Если один кубик - 1 fps, то 100 кубиков - 0.01 fps! А в нормальных играх, хотя бы даже в DOOM 1 - полигонов оооооочень много, гораздо больше, чем 100!!!! Так зачеи обсуждать, какую игру делать, если её сделать невозможно!?!?!?!?!?
Производительность падает до 1 fps когда кубик максимально приближен к ближней плоскости отсечения и занимает практически всю площадь экрана, => другие объекты могут нах. только за кубиком, но за ним они видны не будут => производительность с учётом ресурсоёмкости отрисовки куба в указанном случае практически не изменится даже при перекрытии им 100 др. любых объектов.
Если всё же ты запихаешь 100 кубиков в кадр, то производительность упадёт на величину в среднем в 10 - 30 раз меньшую от указанной тобой, т.е. до 0.1 - 0.3 fps... :)


To pro123:
- Я думаю, что пока не стоит обсуждать, какую игру делать. Сначала нужно ПОЛНОСТЬЮ дописать движок, полностью его оптимизировать, - написать небольшую демку, чтобы увидеть его МАКСИМАЛЬНЫЕ возможности. А потом исходя из этих возможностей думать, что писать.
Код движка с учётом небольших модификаций легко преобразуется к виду пригодному для использования в MVS .NET под DirectX + небольшой ассемблерный кусочек кода и мы уже можем обработывать на AXP2800+ до 140 млн. трансформированных вершин / сек в пике ( для сравнения ATI Radeon 9800 Pro до 106 млн. трансформированных вершин / сек в пике ). Можно также с лёгкостью разбить код трансформации массива вершин на пару потоков и получить на новых двуядерных Атлонах величины порядка 300 - 500 млн. трансформированных вершин / сек в пике.
Но, оптимизировать, можно вечно, тогда как сменить платформу при исп. рациональных подходов к программированию можно достаточно просто.

To 4ep:
- hobbit19, чтобы не надоедали гоночки - надо их особенными сделать. Разьве ты не согласен насчёт стрельбы?
- А насчёт РПГ - почему сразу средневековье? Лучше будет создать свой собственный мир. А насчёт артефактов, лекарств и т.д. ты попал в - точку. Если чего, у меня друг есть фанат РПГ, и он дома всё время сидит. Он может сюжет и героев продумать.
"Концепт-артная" идея №2.


То Всем:
Предложения по поводу отображения картинки на "100% PURE JAVA":
1) Предложения по поводу отображения картинки для RPG / Strategy и т.п.
Основной режим 1 - Wire Mode
Основной режим 2 - Fill Color Mode + Flat Shading
Доп. режим 1 - Perspective Correct Textured + Gouraud Shading + Mip-mapping
Доп. режим 2 - Perspective Correct Textured + Gouraud Shading + Mip-mapping + Antialiasing 4X [ + Bilinear or Trilinear Filtering ]
Доп. режим 3 - Perspective Correct Textured + Pixel Shading + Mip-mapping + Antialiasing 4X [ + Anisotropic Filtering ]
Пока картинка на всём экране непрерывно изменяется используется только один из основных режимов. Как только картинка перестаёт непрерывно изменяться запускается один из доп., либо последовательно несколько. Вся анимация для соотв. картинки буферизуется на сколько хватает памяти. В результ. сохр. динамику игры и доб. красотищи столько, сколько хватит терпения ожидать её отображения... :)
2) Есть один экзотический вариант - сервер рендерит и передаёт через GPRS картинку на ваш mobile. Через EDGE возможен real-time изображения и звука.
3) Есть ещё один достаточно быстрый вариант, наиболее подходящий для игр типа DOOMI-II - это исп. "тексур", составленных из различных графических примитивов. Смещения элементов в таких "тексурах" можно подсчитать достаточно быстро, а выглядеть могут достаточно качественно. Натолкнули на эту мысль одноцветные стены в DOOM RPG с нижней полоской, как у отжатой клавиши "древнего" меню.
4) В зависимости от размеров объекта и расстояния между ним и позицией камеры исп. различные его приближения, в т.ч. и относительно количества составляющих объект вершин,

Мои предложения в рамках уже сделанных:
1) Mobile GTAIII DEMO на 1 - 3 миссии ( Wire Mode и Fill Color Mode + Flat Shading ).
2) Evil Islands DEMO ( 1 карта, пара - тройка заданий ).
Привлекает, особенно в последнем случае, возможность конвертирования данных из ресурсов игры.

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

Итак, открываем два проекта:
1) Проект №1 ( "Концепт-артная" идея №1 ). Ответственный за создание, ведение и дополнение концепт-арта игры - 4ep.
2) Проект №2 ( "Концепт-артная" идея №2 ). Ответственный за создание, ведение и дополнение концепт-арта игры - 4ep ( min до тех пор, пока не отпишется здесь его друг ).

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

1. Сюжетную линию предлагаю прорабатывать только до уровня играбильной демо - версии.
2. Все данные по концепт-арту заносятся в соответствующий *.doc файл. Предлагаю Ответственным по концепт-артам завести также отдельный *.doc для рассматриваемых ими к вкл. в концепт-арт деталей.
3. После составления основных описаний, выносите их на обсуждение.

Все желающие принимать участие в создании какой - либо игры пишите, чем бы вы хотели заняться.
Для проекта №1:
1) написание квестов;
2) художественное оформление составляющих мира ( напр., дизайнеры персонажей, машин, зданий и т.д. );
3) 3D - моделлинг с исп. соотв. художественных составляющих, либо без их исп. ( напр., 3D - моделлеры персонажей, растений, ландшафтов и т.д. );
4) программирование логических составляющих игры;
-
Для проекта №2:
1) написание квестов ( в т.ч. числе доп. типа нахожд. артефактов и т.п. );
2) художественное оформление составляющих мира ( напр., дизайнеры персонажей, растений, ландшафтов и т.д. );
3) 3D - моделлинг с исп. соотв. художественных составляющих, либо без их исп. ( напр., 3D - моделлеры персонажей, растений, ландшафтов и т.д. );
4) художественное оформление текстур;
5) программирование логических составляющих игры;
-
пока что так :)