Следовательно игра сделанная на конструкторе, сделана на движке
А вот про это и говорил ilya7834
У движков и конструкторов разные задачи, все-таки.
arthur33 поправь предложения, "Работаем на движке GM" соответствующе, названию продукта как заявлено разработчиком GM, т.е. так как позиционирует его сам создатель.
Сообщение отредактировал serg-kkz - Воскресенье, 31 Июля 2011, 11:46
Kafkianskiy, скажи мне как злементы управления движком, могут называться движком.
пояснения: игра, это не движок. конструктор, это не движок. и ещё автомобиль, это не движок.
Это продукты основаные на движке. И по моему глупо кричать что автомобиль это движок, ловишь суть? Так же не обязательно кострукторам основаваться на движках. Яркий пример самописные программы для модостроения, ловишь суть? или они тоже движок?
Вывод: конструктор это программа для работы с движком. Сколько можно уже.
Сообщение отредактировал serg-kkz - Воскресенье, 31 Июля 2011, 11:48
allxumuk, подскажи пожалуста временной промежуток для этого форума, когда считается некропостинг. Чтоб знать создавать новою тему или нет. Можно в правилах прописать конкретно.
Сообщение отредактировал serg-kkz - Суббота, 30 Июля 2011, 00:43
skandver я тебе ещё раз говорю чтоб рендерить большое количество объектов, нужно чтоб это было реализовано в двиге, в панде 100% реализовано, а остальные проверяй или задавай вопросы в спец разделах по двигам. Так же погляди примеры игр на них.
Quote (Stas96)
Тоже советую Panda3D, но для него нету нормального редактора карт.Можно прикрутить плагин к Blender. Но мне кажется лучше написать свой...(Может займусь этим в ближайшее время(хотя не знаю что из этого получиться...))
Ogre4j - по идеи должен. 3DzzD - особо о нём нечего сказать.
Проверь их, не знаю есть ли они в базе здесь. А я все таки рекомендую взглянуть на панду. Т.к. в тех движках возможно прийдется допиливать, звук, физику, и. д.
И почему все так плохо думают про этот язык программирования?
У википедии спроси, ответ найдешь где сравнивается скорость, вывод: выбирай двиг у которого ядро на C++, а возможность программировать на яве.
Quote (skandver)
А если реализовать такой метод: Мир разделяется на отдельные области, динамически подгружающиеся в память при приближении пользователя, и выгружаются при удалении пользователя от этих областей. Делается это на дальности, которая установлена пользователем в зависимости от мощности его компьютера. Подземные области реализуются также, за исключением того, что пока игрок не приблизился к порогу подземных областей, они не генерируются. При перемещении пользователя в подземные области, наземные сохраняются и "консервируются". Аналогичное происходит при переходе из подземных областей в наземные. По идее, такие моменты, как глюки и тормоза, должны исчезнуть. Или такое в Java нереально сделать?
Дело в том что на эти действия тоже нужно время, но по сути можно и не выгружать, просто не рендерить, т. е. скрывать-отображать. Но хочу привести один факт при наличии множества объектов в сцене, видеокарте проще обрабатывать один меш, нежели каждый по отдельности. Так вот если скажем 100 тыс. кубиков в сцене являются отдельными объектами, то ресурсов видеокарты будет потребляется больше. А если 100 тыс. будут одним мешом, то скорость рендеринга увеличится в разы. Но одним мешом можно только экспортировать из 3D редактора, если конечно нет возможности их объединить программно в двиге. Здесь важный момент, который двиг ты выбериш должен иметь такую возможность, на яве он или еще на чем то, главное возможности для этого в API двига. А то что написал про загрузку и выгрузку ресурсов, это называется менеджер сцены, как правило в конструкторах он уже реализован, а вот в движках тебе нужно будет написать свой. Это необходимо, и должнен имеется на любам двиге, не только написанном на яве.
Quote (skandver)
Модель для всех объектов - куб, но с разными текстурами и свойствами(т.е. каждый тип куба - это отдельный объект, вроде камня или гранита), в том числе с разными размерами(элементы, создаваемые игроком), и в некоторых случаях - с разными свойствами(вроде шипов).
Модель можно копировать и текстуры назначать нужные программно и свойства, так же размеры путем масштабирования. Думаю любой двиг имеет такую возможность.
Сообщение отредактировал serg-kkz - Вторник, 02 Августа 2011, 15:27
Если сделать текстуры 64 пикселя на каждую сторону куба, это долго будет обрабатываться, при учёте, что работает оно на Java и количество таких кубов - за сотни тысяч на начальную карту?
Все зависит есть ли оптимизация для таких случаев в двиге или нет. Если говорить про панду там есть, у нас кстати есть пример карты Minecraft, на питоне(я из сообщества Panda3D). Зайди глянь в разделе "wip", тема "производительность" 160 тыс кубиков - fps норм. Про яву думаю не потянет если сам движок написан на яве как в случае JMonkeyEngine 3.
Quote (skandver)
Что лучше, огромный, заранее созданный мир, или создающийся на ходу? Мне больше по нарву первый вариант. Можно расположить всё так, что все привыкнут и иногда выпускать обновления в виде новых карт.
На ходу как правило быстрей, но тут опять зависит от того как движок грузит одинаковые модели, панда просто копирует модель если она есть в памяти. Так вот если модель одна(куб), то остаётся позаботиться о списке координат и имени текстуры для кубика.
А для второго варианта надо еще писать алгоритм для создания мира.
Сообщение отредактировал serg-kkz - Пятница, 29 Июля 2011, 17:52
Есть ещё gmax, урезаный 3D max. Правда не поддерживается разработчиком, но свободен. Рендер отсуствует, а возможность работать с анимацией есть. Так же попробуй 3DCanvas, насколько я помню есть ограничения для свободного использования.
Сообщение отредактировал serg-kkz - Пятница, 29 Июля 2011, 16:34
TrueIfrit, однозначно у него есть будущее, я в этом уверен. Слава как универсального конструктора у него ещё впереди. Ну а про код, это везде так, он тут не причем, главное руки прямые.
05142, Blender Game Engine - для казуалок, либо для слайдшоу, со временем возникнет нехватка производительности. И насколько я знаю разрабы работают над ним в последнею очередь. А это значит он мало приспособлен на что то серьёзное. Да еще, переменчив API. Хорошо создавать игру из кирпичей, да только вот кирпич бы нужный был всегда . Не рекомендую его, впрочем, тебе выбирать.
ezhickovich, это не компилятор кода, эта вещь всего лишь упаковывает его в exe, и связывает с dll'ой питона. Есть, cx_Freeze, принцип такой же.
Novus, на питоне вполне можно делать игры, есть движок Panda3D, на нем Disney's Pirates of the Caribbean Online, создавались. И проблем с производительностью нет. Дело в том что в этом двиге реализована автоматическая генерация обертки для кода питона в C++. Да и сам он написан на С++.
Сообщение отредактировал serg-kkz - Пятница, 29 Июля 2011, 00:22
zhenOK, не забывай чтоб научится программировать нужно программировать. Мне кстати учебники не помогли, лучше учиться по статьям сайтов по питону. На конкретных примерах: чтение/запись файлов, списки, функции, и. д. Так же на примерах кода с комментариями. Поверь, чайником перестанешь быть быстрее, чем читая заумные книги. И больше практиковаться, конечно на создании игр))), а остальное скучно.
Сообщение отредактировал serg-kkz - Четверг, 28 Июля 2011, 23:34
Critical, не пойму движок или конструктор? Если движок, то Panda3D. Открытые пространства в нем не проблема. Но насчет действий выбирать и всего остального, надо программировать, а написать можно, что душе угодно. А если все-таки нужен конструктор, ну тогда я не знаю. Проще освоить любой двиг и на нем написать нужный конструктор, быстрее будет и надежней, нежели на середине разработки игры в конструкторе не обнаружить банальной функции.
-------------
Блин на старый старт-пост ответил, смотрел на дату предыдущего поста.
Сообщение отредактировал serg-kkz - Четверг, 28 Июля 2011, 20:50
. Не рекомендую его, впрочем, тебе выбирать.