Комментарии 44
уважаю дерзких безумцев, но прежде чем писать 3д игру на яве, я бы написал 2д игру :)
С одной стороны - make sense, приобрести опыт и попробовать идеи.
С другой стороны - а зачем? Если целевым вариантом является 3D с процедурным миром и попытка воссоздать Gothic/Oblivion. В процессе всё равно приходится делать standalone мини-приложения для проверки гипотез. То есть создание 2D игры в данном случае кажется потерей времени на не-релевантные задачи.
Полностью Вас поддерживаю 2D это первично в любой игре..
поверьте вы это сделаете очень быстро, где в 3д - 2д это просто матрица Ortho тоесть скорость добавления 2д в 3д близка к скорости света )
https://www.songho.ca/opengl/gl_projectionmatrix.html
https://www.songho.ca/opengl/gl_transform.html
Matrix4 ModelGL::setOrthoFrustum
Тут видно, что человек пишет игру для процесса, а не для результата, как почти все индюшатники. Значит удовольствие в процессе познания - как организовать архитектуру игры, как сделать освещение, как сделать мир безшовным, а стримминг - незаметным и прочие прелести познания того - как любимые игры устроены под капотом. Создавая 3D игру ты получишь больше выхлопа в количестве и глубине этих открытий в единицу времени, чем создавая 2D.
Так Minecraft написан на Java, а это чуть ли не самая популярная игра в мире вообще...
"был"
есть отдельная Java версия, но основная давно переехала на плюсы
Насколько знаю, многие сидят на Java версии, в том числе из-за модов.
Нет никакой основной версии и никто никуда не переезжал.
Есть кроссплатформенная Java Edition и есть Bedrock Edition для винды и консолей.
Это две параллельно развивающиеся реализации.
Интересно, какая такая основная, если она Bedrock? На ней ней поддержки модов, до сих пор немало критичных багов, да и не переходит на нее никто, на ПК по крайней мере.
Нет. На ПК никто на бедрок точно не переходит, ибо там нет всех этих миллиардов разработанных и до сих пор поддерживаемых модов. И Java-версия до сих пор активно развивается.
кстати майнкрафт без greedy meshing можно написать, там очень интересная идея, математика интересная, в конечном итоге можно и фигуры строить аля вокселями - для этого правда надо подумать как это делать, а чанки рисовать не так то и сложно, да и коллизия простенькая, после такого можно даже в себя поверить немного ) (рисовать чанк, строить блок/убрать блок, обновить чанк)
Кстати, да, а куда пропал lwjgl?
Тоже джава игровой движок для 3д
классно очень, а сколько у вас память отьедает при запущенной игре? мне порой история с с/с++ надоедает порой реально подумываю переехать в java
траву вроде можно отправить в геометрический шейдер, траву можно не шевелить и либо кидать в геометрический шейдер, либо кидать траву в 1 буффер, второй буффер, селектор идете рисуется селектор из буффера травы (там еще посмотреть как лучше)
Постепенно количество объектов в кадре увеличивается и требования начинают подрастать. Также это зависит от размеров текстур и используемых моделей (low poly/high poly).
Требуется система имеющая от 4Gb RAM (бывают скачки выделения в пике до 6Gb) и от 2Gb до 4Gb Video RAM.
Траву можно через шейдер рисовать, это правда, но шейдер пишется не на Java а уже на другом языке - GLSL OpenGL Shading Language, он кажется довольно сложным, надо отдельно изучать. И в шейдере для травы придется учитывать неровности ландшафта, место посадки (не сажать на скалах и под водой) и тогда уж надо бы сделать эффект ветра - колышащуюся траву. С шейдерами я планирую как-нибудь попозже поразбираться.
ява всё таки дорога у меня сейчас такой расклад
посмотрите тутс ниже он должен придать вам уверенности, я когда его увидел многое стало реально сделать
у вас трава одинаковая, это классно, и момент что она одинаковая тоже двоякий (трава может быть и частичкой тогда возможно будет доступ к координате по высоте)
весь тутс ниже я оттестировал, перенял его опыт, и щас на С пытаюсь понять как хейтмапу делать, но в тутсе скейл и высота 1 в 1
вот советую тутсы
https://www.mbsoftworks.sk/tutorials/opengl4/
и DSA местами может улучшить
по траве получается либо бить на части и трансформ фидбек в доках пишут он работает со стадией геометрического, либо как кубики у синМатрикса на геометрическом шейдере
Генерация травы осуществляется следующим образом. На высоте 150 местных единиц от нулевой точки (земли) я беру плоскость, на ней генератором случайных чисел выбираю точки. Из каждой такой точки вниз направляю луч — это техника называется ray cast. (вот это нагрузно) дело в том что у вас проекция террейна находится в плоскости 2д (x,0,z); поэтому проще генерить по террейну без рейкаста, подправляя высоту из карты высот = (random,height,random) далее не знаю как вы ходите, но если есть карта высот проще ходить по нормалям(террейна), так вы половину формул на площадь/обьём скипните просто и будете всё равно там где надо. (потратьте время на карту высот и получение тайловых карт высот это вам очень поможет), далее изза того что мы на 2д плоскости можно пойти дальше и генерить области УГО где дом/дерево - получится поидее +- как должно быть, если ходить по дому, просто ставим материал на лесницу/пол если есть материал(по имени) ходим по нему, соотв на террейне где нет УГО у вас материал(по имени), так будет вся инфа статичная и высота известная, по матеше - советуют использовать кватернионы на камере и обьектах, пишут там скипается некоторое число умножений матриц
по запуску лучей и физикe(дело в том что реал тайм мы до сих пор не тянем поэтому лучше посмотреть практики как можно симулировать) есть нетривиальные наблюдения, недавно случайно набрёл на обзор https://gamedev.ru/code/articles/PositionBasedPhysics
В играх дождь и снег никогда не просчитываются для всей карты – от такой задачи любое современное железо просто умрет. (простите) - осадки лучше делать через трансформ фидбек или через геометрический шейдер или частицами(инстаседами). полусферу можете не рисовать, важно само положение эмитера - эмитер виртуальная точка участвующая в расчете
Скажите, как вы решали проблему с ограничением симуляции дождя - чтобы в помещениях не было капель?
у дома есть баундинг бокс(центроид и по геометрии ограничивающие плоскости куб типо) его можно посчитать оффлайн по факту когда вы его создаете, если у вас частицы и вы управляете в коде частицами просто по высоте работайте баундинг бокса(виртуальный расчет только в коде - баундинг бокс имею ввиду и его точка виртуальная они участвуют в расчетах. для дебага можно отрисовывать)
https://ru.wikipedia.org/wiki/Иерархия_ограничивающих_объёмов
http://ray-tracing.ru/articles184.html небольшие вводные
вроде дорого выходит, вопрос интересный ниразу не думал о таком, если зашли в дом то дом рисовать первым(спрятать за дом партиклы по очередности отрисовки), но это только внутри, а снаружи? мы же же можем быть одновременно только в одном месте
какието хитрости наверняка есть)
еще вариант верх дома делать по материалу террейна, и учесть как-то высоту - подставлять ее
допустим есть УГО дома и карта высот, надо как-то сделать карту высот и вырезать площадь дома и выбирать максимум это наверно дешевле
а тоннели/пещеры у вас есть?
у меня нету, я просто задался вопросом как удешевить эти операции, в сторону облегчения ради анимаций/интерактива, у пещер тоже есть топология и точка входа, в разных играх сделано по разному но если удасться всё вживить в террейн, и отключать отрисовку когда когда вы внутри каких-то областей и ходить по высоте террейна которая в текущий момент подвела вас к вросшему в террейн обьекту и увела внутрь - вроде получается дешевле чем пускать лучи
поидее в пещере после предбанника поворота можно отключить то что снаружи
сегодня еще прибавилось - пещеры можно стартово генерить в своём софте аля как первый слепок - образно должно выглядить как туннель переходящий в амбар или куб, сохраняем такой туннель в модель, открываем в блендере - редактируем амбары, модифицируем туннели, вытягиваем подступы к высоте террейна подхода в пещеру, делаем вход, вот чтото такое еще можно, почему из своего софта или движка, потомучто террейн и пещеры по скейлам и этим моментам одной руки, а ну и с нормалями надо подумать, там нормали надо в масштаб кидать чтото такое пишу не професиональными словами(шаг туннеля и как генерить посмотрите на тор или куб, ну и шаг еще зависит от скейла и желаемого еффекта)
Я пока никак не решал, ибо у меня пока нет зданий со входом с улицы. Вообще зданий пока нет. Но, кажется это можно решить именно с использованием BoundingBox - проверяются координаты частиц и попавшие в него убираются. Этот метод кажется самым точным но и самым тяжелым.
Внутри здания совершенно точно можно управлять этим через бакет (очередности) отрисовки RenderQueue.Bucket.Transparent. Снаружи использовать такой подход не выйдет, так как будет нарушена очередность отрисовки травы, неба и удалённых гор.
Ещё можно проверять положение ноды игрока - если он внутри дома отключать отображение полусферы с частицами через particleGeom.setCullHint(Spatial.CullHint.Always);
Но это должно визуально полностью отключить дождь. То есть в дверной проём будет видно что снаружи дождя нет.
да но представье теперь на сколько дорого ради частицы проверять все ну пускай в ноде квадрата баундинг боксы, варик с вживлением или подменой новой высоты набирает обороты потомучто тогда у вас все коллизии с тереном будут статичны
вы за 1 иф находите под частицу в этом случае высоту, под игрока 1 иф и остается производительность на анимации(тоесть булыжники допустим кидать в загрузку карт дома деревья и будет высота уникальная) (тоесть дом стоит на подступах, деревья и камни с водой имеют тоже уникальные моменты, если всё кроме воды по чему можно ходить вживить в террейн то там поидее будет задача только разбиения и гео рассадки квадрантов)
Судя по пересвеченным и недосвеченным картинкам вам могут помочь гамма-коррекция, hdr и tone mapping.
Я пробовал на libgdx свой пайплайн рендеринга сделать - было прикольно, очень красиво, но времени много заняло.
Ещё из интересного для godot есть экспериментальное расширение для того чтобы писать на kotlin, но пока что остаётся ждать и наблюдать за развитием.
Программировать игры это хобби. Я у меня тоже есть такая страсть. В магазине продаются кубики Рубика и пирамиды Мефферта любого размера. Программы Популярный размер 3. Вот взял и написал программу на трех языках программирования. Java. Pascal Abc. Python. Для любого размера кубика и пирамиды. Использовал 2D модель для 3D объекта. Применил макрос ( повторяющиеся последовательности вращений). Получилось удобно играть и изучать кубики больших размеров. При недописанной программе обнаружил, что можно определить и игру - НеРубик. Но играть в неё не получается. При вращения боковой плоскости боковая грань не вращается. Приглашаю к поиску алгоритма решения кубика НеРубика. Реального кубика такого нет. А виртуальный есть.
В тегах ошибка
Стоит тег "игра на javascript"
Хотя проект полностью на обычной java....
На Java довольно много коммерческих игр, из успешных можно вспомнить, например, Minecraft или Slay the spire. В опенсорс крыле есть легендарная Pixel Dungeon https://github.com/watabou/pixel-dungeon. Помимо Jmonkey есть движок LibGDX https://libgdx.com/, на котором мне довелось писать игры еще 14 лет назад и который силами энтузиастов жив до сих пор, игру на нём можно будет собрать под любую платформу включая Ios(используя Robovm https://github.com/MobiVM/robovm). На LibGDX написан очень известный редактор для 2D анимаций Spine https://esotericsoftware.com/, который мои коллеги много лет использовали в коммерческих играх на Unity. В геймдеве очень популярен подход к архитектуре, который называется ECS - entity, component, system, для Java и под него есть готовая либа - Artemis https://github.com/junkdog/artemis-odb.
К чему это я всё? А к тому же, о чем пишет автор статьи - если вам нравится Java, вы хотите заняться разработкой игр и любите code-only подход, то есть множество инструментов, которые вам в этом помогут.
Привет коллеге! Пишу свой проект на Java но без использования сторонних движков.
https://vk.com/thegreattribes
Рад Вашему прогрессу. Я сам пишу игры на Java, сперва использовал Processing как основную библиотеку для моей 2D игры (есть статья тут: https://dtf.ru/gamedev/2022593-razrabotka-igry-na-processing-ot-dvizhka-do-reliza). После релиза стал делать новую на LibGDX - тоже 2D, но уже Action Adventure с RPG-элементами, но уже жду, когда наконец зарелизю и хочу портировать её же в 3D и спользовать для этого JME3. Мне он тоже нравиться, хотя меня пугает перспектива работы с встроенным редактором частиц в JME3. Как у Вас с этим? В LibGDX как то это было - прям как с молоком матери и очень гибко. От себя:
1) По поводу перформанса - плюньте на замечания коллег. Поднять FPS можно практически всегда, но лучше все таки оставлять это на предрелизное время. Я сам поднимал с 14 до 55 на целевой плафторме и знаю, что это было не конец и можно поднять еще.
2) Рад, что Вам удается сохранять мотивацию, хотя я Вас понимаю. Я вот откладываю в максимально дальний ящик весь игровой контент и пытаюсь подольше поработать с кодом, добавляя в него новые фичи и оптимизируя архитектуру. Старайтесь получать удовольствия именно от процесса, а не от мысли, что когда то это будет готово и вот тогда вот ...
3) Вы тоже испытываете это неописуемое удовольствие, когда задумываете очередную фичу, садитесь за её реализацию, и понимаете в процессе - "как же чертовски хорошо она ложиться на архитектуру игрового движка"?
Привет!
Я работаю с движком jme3 используя только code-only подход. Имеющимся SDK не пользовался. Так как исходный код самого движка открыт, если Вас что-то не устраивает, теоретически можно это переделать под себя)
Либо посмотреть на другие OSS проекты, как там реализовано, может даже [пере]использовать. Написано уже множество всяких редакторов и библиотек. Около года назад, даже FSR1 пытались реализовать, правда в движок это пока не попало.
После пары глобальных очень долгих рефакторингов (которые по классике бизнес-ценности не имели, но без них было не обойтись) я теперь сразу стараюсь делать компоненты игры расширяемыми, чтобы в дальнейшем можно было легко наращивать функциональность.
Как я пишу open source игру на Java