Это копия, сохраненная 22 февраля 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Здесь обсуждается только техническая сторона дела: алгоритмы, архитектура, паттерны и реализация всего этого. Вопросы по Unity и прочим движкам, бложеки, охуительные идеи и поиск программистов/художников/инвесторов - в соответствующем разделе. Буду репортить, ибо нехуй.
#gamedev #геймдев #(разработка игр) #игры #unity #godot #ue4 #unreal #lua
как-то в универе писал для курсового игору на directx, 3 дня исправлял баг когда мышью двигаешь камеру, а она продолжает двигаться некоторое время когда перестал мышкой двигать, ну его нахуй такие ебануе баги вылазят
Если пиры выбирают среди себя мастера, кое-как наверное ещё возможно. Иначе же, если топология другая, будет говно, так как очень большие пинги через несколько пиров. В целом, во множестве игор, где вместе с игрой поставляется сервер, позволяют запустить сервер руками, а через агрегатор этот сервер становится видим всему интернету. Сами клиенты уже подключаются непосредственно к серверу, взяв у агрегатора его IP. Примеры: контрстрайк, факторио, майнкрафт, тысячи их. То же своего рода p2p, так как сам агрегатор, издатель игры, сервера не держит.
Насколько мне известно, в первом старкрафте была serverless архитектурка. Но она очень зависима от качества сети, это только для LAN. Там по сути все подключены ко всем одновременно.
Тебе в любом случае нужен какой-то entry point в твою п2п-сеть. Если нет мастер-сервера - все равно придется вместе с программой класть список известных и стабильных нод сети, через которые уже можно находить все остальные ноды. Короче, в контексте этого треда никакого смысла в такой еботне нет, мастер-сервер пишется буквально в две строчки (просто сохраняешь\отдаешь список игровых серверов).
Думаю, начинать надо с модов на те игры, которые тебе нравятся. Потом начинать делать игру с нуля.
Допустим, все вычисления у нас ведутся в кубических координатах. В экранные координаты переводим только на этапе рендеринга. Я так понимаю, у нас есть два варианта:
1) Считаем для каждого видимого гексагона его центр в экранных координатах, применяем трансформацию камеры, после этого рендерим квадратный спрайт в нужном месте. В квадратный спрайт впихнут гексагон, лишние обрубки прозрачные, спрайты перекрываются. При клике по карте можно использовать обычный метод определения кликнутого спрайта (обычно уже реализован в рендер-либе) - тогда клик заденет либо 1 спрайт (ок), либо 2 (тогда считаем, центр которого ближе к месту клика).
2) То же самое, только вместо гексагонов впихиваем в спрайт треугольники. Каждый гексагон состоит из трех треугольников, можно делать плавные переходы между разными типами поверхности без ручной отрисовки кучи гексагональных спрайтов.
Что меня тут напрягает:
- у любых двух рядов спрайтов их центры будут находиться со смещением в половину ширины спрайта друг от друга. Из-за этого вроде как могут быть ошибки при округлении, ну и в итоге между тайлами на карте будут черные просветы. Я так понимаю, что нужно заранее построить целочисленную сетку и отрисовывать все по ней, так? Но как тогда добиться плавной прокрутки карты при движении? Вообще, тут есть какие-то подводные, которых нет при обычных тайлах квадратиками?
- перекрывающиеся тайлы. Из-за этого могут быть проблемы с производительностью или еще какие-то подводные?
- зум\скейл. Опять же, с зумом все целочисленные координаты по пизде пойдут.
Как обычно это делают? Спрайты\тайлы вообще подходящее решение для гексагональной карты?
Я пробовал строить сетки (и не я один) и никаких проблем со смещением в половину гекса не испытывал (щели и т.п.).
Как прокрутка привязана к форме тайла и чем она будет отличаться от прокрутки квадратных тайлов вообще не пойму.
Если у тебя рендер не 3d и без AA, то округление можно проконтролировать. Иначе делай сетку вплотную состыкованных тринглов с текстурами.
При прокрутке будут вылазить нецелочисленные координаты, которые нужно будет округлять, я же вроде писал.
Да не, всё можно в ipv4. Проблема в том что broadcast пакеты не выходят за пределы NAT. Никто не даст тебе зафлудить весь интернет широковещательными анонсами игровых серверов. Так что все кто будет что-то там кудахтать про то как раньше всё работало и какое сегодня всё криворукое, должны вспомнить что раньше только в локалке и играли.
Раз тут обсуждается и "архитектура", вылечите меня, пожалуйста, я уже не могу.
Суть проблемы:
Игра на юньке (но не суть). Есть некие "прожектайлы" (пули, лазеры, хуязеры...) и они используются разными сущностями (игроком и разными врагами). Очевидно, что эти прожектайлы хранятся в пуле (pool) и реюзаются.
И вот тут я уже в 2 заданиях упираюсь рогом в схожие проблемы протягивания зависимостей. Опишу вторую (текущую задачу), с которой борюсь:
Игра типа Space Invaders. Есть некие прожектайлы (типа пули). Для ускорения взял уже готовый простенький синглтон-пул (мне ранее велели зарекаться от синглтонов, но для ускорения...), который извлекает по прототипу (а внутри на самом деле даже проще -- по имени прототипа).
И вот я сделал простой компонент, который производит выстрелы как у игрока, так и у врага, только у игрока по кнопке, у врагов по таймеру, извлекая из пула-синглтона нужный прожектайл. Назовём его Shooter.
Ни класс игрока, ни класс врага не знает о своём Shooter-е. Я инстанциирую врагов, но не их Shooter-ы. Последнего может даже и не быть во враге, например. Прожектайл в свою очередь летит пока не попадет в цель или невидимую стену за экраном и сам себя же возвращает в пул. В этом вроде бы удобство компонентной системы, компонент может быть, а может его и не быть, и он живет своей жизнью.
Но вся эта "красота" разбивается о необходимость ею управлять.
Например: когда игрок потерял жизнь, нам нужно убрать все выпущенные прожектайлы с экрана (вернуть в пул). Но они же живут своей жизнью и ничего не знают о игроке и о его смерти.
Кто всем этим должен управлять?
Спавном врагов я, например, управляю и знаю о "живых" врагах на уровне и их количестве. Но, как я писал выше "Я инстанциирую врагов, но не их Shooter-ы", т.е. когда я запрашиваю из пула врага, я не знаю о том, что вместе с ним может вытянуться и очередной Shooter.
Как быть?
У меня были идеи, но они мне кажутся то уродливыми, то костылями, то излишеством. Вот они:
1) Дописывать какой-то фасад над пулом, который при получении из пула любого объекта проверяет все его компоненты на тип и реализацию разных интерфейсов (уродство).
2) Расширить пул параметром для каждого прототипа указывать в какой трансформ вкладывать его инстансы при извлечении из пула (иерархическая вложенность объектов в сцене, если кто не знаком с Unity, как коробка в коробке). Тогда на конкретный трансформ можно будет повесить дополнительный скрипт, который сможет манипулировать своими чайлдами. Этот метод мне кажется костылём и взять проект побольше, это -- костыль 146% и никогда не знаешь кто и для какой фичи в будущем какой какой трансформ решит сделать родительским для того или иного прожектайла.
3) Dependency Injection. Это тот самый способ, который "излишество" (грузить дополнение по коду бОльшее, чем сама игра) и одновременно "более-менее", т.к. с ним я знаю как более-менее красиво всё порешать. Но как-то же раньше без DI аналогичные вещи решались. Я хочу научиться этому мастерству использования паттернов правильно.
Раз тут обсуждается и "архитектура", вылечите меня, пожалуйста, я уже не могу.
Суть проблемы:
Игра на юньке (но не суть). Есть некие "прожектайлы" (пули, лазеры, хуязеры...) и они используются разными сущностями (игроком и разными врагами). Очевидно, что эти прожектайлы хранятся в пуле (pool) и реюзаются.
И вот тут я уже в 2 заданиях упираюсь рогом в схожие проблемы протягивания зависимостей. Опишу вторую (текущую задачу), с которой борюсь:
Игра типа Space Invaders. Есть некие прожектайлы (типа пули). Для ускорения взял уже готовый простенький синглтон-пул (мне ранее велели зарекаться от синглтонов, но для ускорения...), который извлекает по прототипу (а внутри на самом деле даже проще -- по имени прототипа).
И вот я сделал простой компонент, который производит выстрелы как у игрока, так и у врага, только у игрока по кнопке, у врагов по таймеру, извлекая из пула-синглтона нужный прожектайл. Назовём его Shooter.
Ни класс игрока, ни класс врага не знает о своём Shooter-е. Я инстанциирую врагов, но не их Shooter-ы. Последнего может даже и не быть во враге, например. Прожектайл в свою очередь летит пока не попадет в цель или невидимую стену за экраном и сам себя же возвращает в пул. В этом вроде бы удобство компонентной системы, компонент может быть, а может его и не быть, и он живет своей жизнью.
Но вся эта "красота" разбивается о необходимость ею управлять.
Например: когда игрок потерял жизнь, нам нужно убрать все выпущенные прожектайлы с экрана (вернуть в пул). Но они же живут своей жизнью и ничего не знают о игроке и о его смерти.
Кто всем этим должен управлять?
Спавном врагов я, например, управляю и знаю о "живых" врагах на уровне и их количестве. Но, как я писал выше "Я инстанциирую врагов, но не их Shooter-ы", т.е. когда я запрашиваю из пула врага, я не знаю о том, что вместе с ним может вытянуться и очередной Shooter.
Как быть?
У меня были идеи, но они мне кажутся то уродливыми, то костылями, то излишеством. Вот они:
1) Дописывать какой-то фасад над пулом, который при получении из пула любого объекта проверяет все его компоненты на тип и реализацию разных интерфейсов (уродство).
2) Расширить пул параметром для каждого прототипа указывать в какой трансформ вкладывать его инстансы при извлечении из пула (иерархическая вложенность объектов в сцене, если кто не знаком с Unity, как коробка в коробке). Тогда на конкретный трансформ можно будет повесить дополнительный скрипт, который сможет манипулировать своими чайлдами. Этот метод мне кажется костылём и взять проект побольше, это -- костыль 146% и никогда не знаешь кто и для какой фичи в будущем какой какой трансформ решит сделать родительским для того или иного прожектайла.
3) Dependency Injection. Это тот самый способ, который "излишество" (грузить дополнение по коду бОльшее, чем сама игра) и одновременно "более-менее", т.к. с ним я знаю как более-менее красиво всё порешать. Но как-то же раньше без DI аналогичные вещи решались. Я хочу научиться этому мастерству использования паттернов правильно.
>Например: когда игрок потерял жизнь, нам нужно убрать все выпущенные прожектайлы с экрана (вернуть в пул). Но они же живут своей жизнью и ничего не знают о игроке и о его смерти.
Ээ... https://docs.unity3d.com/ScriptReference/Object.FindObjectsOfType.html
Написано же - с вопросами по движкам пиздуйте в соответствующую парашу.
Есть ли какая-то книга по дизайну и написанию рогаликов?
>говно + моча или моча + говно
ncurses + C
>Есть ли какая-то книга по дизайну и написанию рогаликов?
rlgclub.ru
Анонам с таким внимательным чтением рекомендуется самим пиздовать к параше, потому что вопрос был о том, как бы правильней организовать это всё архитектурно, чтобы всё было управляемо и в идеале поддерживало такую охуенную фичу, как портируемость, потому что хороший код как раз должен быть максимально отвязан от движка. И вот я пытаюсь выяснить каким должен быть этот хороший код. Смею предположить, что подобные задачи управления инстансами решались и за рамками юнити.
Предложенное -- это конечно тоже выход, но это и очередной костыль.
Ты какую-то хуйню несешь, ей-богу. Если выкинуть всю воду из твоего поста, то он сведется к вопросу: "как мне удалить проджектайлы, если в моих объектах ссылка на них нигде не хранится?"
Тебе и отвечают: выбираешь из сцены все объекты с соответствующим компонентом и делаешь с ними что хочешь. Почитай, блин, что такое ecs.
>rlgclub.ru
Мде. http://www.roguebasin.com
>>145109
Второе, конечно, поинтереснее будет. А чо не в браузере?
Спасибо. Там IPX ещё кажется был даже, хех.
>Допустим, все вычисления у нас ведутся в кубических координатах.
Допустим, мы будем срать на потолок. Используй X/Y, тебе будет проще.
>Я так понимаю, у нас есть два варианта:
Абстрагируйся от квадов/треугольников и рисуй просто мэш. Это не та проблема, над которой нужно долго корпеть. Хит-тесты можно сделать просто аналитически.
>Из-за этого вроде как могут быть ошибки при округлении, ну и в итоге между тайлами на карте будут черные просветы.
Значит, не округляй, рисуй не целочисленно.
>Используй X/Y
У гексагональной сетки нет никакого однозначного X/Y, так что непонятно, что ты тут вообще хотел сказать. Зачем ты отвечаешь, если не шаришь?
>рисуй просто мэш
>речь о 2д и спрайтах
>не округляй
Тогда и будут черные просветы. Не шаришь - не лезь, пожалуйста.
>У гексагональной сетки нет никакого однозначного X/Y
Есть, как и у всего, что можно нарисовать на экране.
>речь о 2д и спрайтах
То есть, про тайлы из трёх треугольников я написал, да? Ну тогда определись сначала, что у нас есть.
>Тогда и будут черные просветы.
Нет, не будут. Ну то есть, конечно, это зависит от твоей рендер-либы, возможно, она вообще сама фильтрует твои спрайты вместо того, чтобы отдать это OpenGL/DirectX, и делает это коряво - тогда про зум вообще можно забыть - но 99% рендер-либ такой хернёй не страдают.
С одной стороны, логично сделать KISS (тупо и в лоб): каждый холмик - энтити с соответствующими компонентами. С другой стороны, Капитан Очевидность мне подсказывает, что это будет не очень-то эффективно - плюс нужно делать culling, нужно делать динамическую подгрузку, нужно делать симуляцию в фоне, и в итоге у одного холмика-цветочка все равно куча разных представлений вмест одной энтити.
Стены-холмики - это просто одна сущность из двух компонентов - модель + коллизия. Culling, динамическая подгрузка - это всё забота компонента модели. А зачем ты усложняешь?
>Стены-холмики - это просто одна сущность из двух компонентов - модель + коллизия.
Я этот подход и описал в своем посте с пометкой "KISS".
>Culling, динамическая подгрузка - это всё забота компонента модели.
А теперь представим, что у меня, ну, скажем трехслойная карта 1000х1000. Сильно мне поможет выгрузка одних только моделей? Не думаю, анон. Hence the question.
>Я этот подход и описал в своем посте с пометкой "KISS".
Прости, братиш, мой телепатийный аппарат в ремонте.
>А теперь представим, что у меня, ну, скажем трехслойная карта 1000х1000. Сильно мне поможет выгрузка одних только моделей? Не думаю, анон.
А что ты ещё хочешь выгружать? Можешь создать тестбэд да проверить. А можешь не проверять и просто посмотреть на чуваков, которые пришли к успеху: https://www.youtube.com/watch?v=oup3dSeGAhM Это, правда, не про стриминг, а про дроу-коллы, но подход понятен - они нихуя не выгружают, рисуют всю возможную хуйню во фрустуме почти без отсечения и гребут бабки лопатой.
Добавлю ещё, что коллизии весят мало, и выгружать их смысла, как правило, нет - в GTA, например, коллизия хранится всегда вся для всей карты.
>Прости, братиш, мой телепатийный аппарат в ремонте.
Ээ? Система видения-чтения, видимо, тоже барахлит чутка?
>каждый холмик - энтити с соответствующими компонентами.
>Стены-холмики - это просто одна сущность из двух компонентов
>>151276
>А что ты ещё хочешь выгружать?
Ну я же написал выше: у меня на карте, допустим, 10^9 объектов, их и хочу выгружать.
Алсо, как-то неразумно приводить в пример всякие условно-трипл-эй шутаны. На чем там этот пубг? Там же, во-первых, движок делает все то, о чем я спрашиваю; во-вторых - я, может, для браузера и мобилок 2д-хуйню пишу, а ты мне с пубгом сравнивать предлагаешь. И вообще, анон, в оп-посте же написано, что тред для обсуждения алгоритмов и всего такого - зачем ты начинаешь всякие пространные рассуждения пр бабло, давай в рамках конкретнго технического-архитектурного вопроса останемся.
>>151279
Я таки подозреваю, что коллизии там хранятся не на каждый тайл, а геометрически на каждое здание, разве нет? Это на порядки меньше данных. А все маленькие объекты типа машинок выгружаются буквально сразу после пропадания из поля зрения.
>что коллизии там
элементарные, конвексные
>на каждое здание
которую в свою очередь модулярное, колизия на 4 вершины — охуеть не встать, да анон?
https://vimeo.com/25620314
> using a third-party physics library (PhysX) ... a lot of maths, creativity and approximative hacking. The graphical part was much easier to implement, warping is basically just a vertex shader displacement, requiring objects to be evenly tesselated.
У энтити должен быть вектор компонентов типа IEffect, с каким-нибудь методом DoEffect(). И система просчета бафов, которая будет рассчитывать результаты эффектов.
кстати вертекс шейдер не трогает колизию, по крайней мере в уече по дефолту
а ебать я с SImpleGrassWind спутал, а если там дисплейсмент, то хуле нет, читай ебать что такое теселяция
хотя помню накачал RDTешных текстур и с теселяцией и большим оффсетом кароче нихуя колизия незаработала на моих буграх, но мне тогда пофиг было, наверняка где нибудь лежит жутко дорогущая галка
Почему нельзя просто попросить пул деактивировать свои объекты?
С физикой скорее всего глобально ничего не происходит. Берем карту с обычным евклидовым пространством, размещаем в нем 2 точки, задаемся определенным радиусом, получаем "капсулу". Если физический объект при расчете перемещения оказывается в ней, то нехитрыми умножениями на вектор ускоряем перемещение объекта. Искажения картинки маскируют факт изменения скорости и ускорения, и у зрителя создается иллюзия, что ему необходимо преодолеть меньшее расстояние, а на самом деле он просто перемещается в нем быстрее.
Соответственно можно замедлять игрока, чтобы растянуть пространство.
Если стягивать точки перпендикулярно движению, то уже простым ускорением/замедлением не обойтись.
еще можно с фовом поиграть
https://www.youtube.com/watch?v=joFWr3JzBOI
Кажется здесь объясняется как подогнать под это дело физику, но я нихуя не понял
https://www.youtube.com/watch?v=ztAg643gJBA
ты не тот видос включил, там какое то цифроебство, вот в этом четко показано что это торус ибаный, и демка под видосом, бери и реверси
Пагни, учусь на заочке. Нужно делать курсовик по Компьютерной графии на юнити.
Тема курсовика: Приложение должно формировать трехмерную сцену с генерацией ландшафта из файла. В файле должна содержатся информация о высоте ландшафта к каждой контрольной точке и типе ландшафта в данной точке.
С юнити знаком поверхностно. Поясните за генерацию ландшафта из файла. Есть ли какие гайды или видеоуроки?
Ты не догадался ввести этот запрос на английском, не?
>генерацию ландшафта из файла
шли их нахуй, скажи преподу что юнька распиаренное говно для пидоров и безмозглых детей которые могут только пиздить ассеты со стора, а ты тупо не хочешь шквариться
а вообще любопытно где в рахе тискают юньку и задают по ней курсовые? и почему ты при этом в этом не шаришь лол!?
По посту нихуя не понятно что там у тебя в файле.
А вообще тебе нужно создать кастомный инспектор в папке editor для своего компонента, быдлишь там нужные вещи типа кнопки открытия окна для выбора файла, считывания всей инфы и генерации твоего ландшафта.
Если у тебя в файле обычная карта высот и регулярная сетка то все элементарно
Делаешь сетку по этому гайду
http://catlikecoding.com/unity/tutorials/procedural-grid/
и смещаешь нужные точки.
Вот в играх есть состояние. Например: игровое меню, настройки, игровой процесс, экран проигрыша и тд.
Понятно что писать портянки switch-case не дело и тут дело вступает наследование.
При каких-то условиях мы можем перейти из одного состояние в другое.
Есть базовый класс GameState, от него наследуются другие состояния. По идее они о друг друге ничего знать не должны, но как сделать переход из одного в другое?
На чем пишешь? Потому что этот процесс при использовании либ/фреймворков или движков слишком разный.
Лучше конечно посмотри доки твоей либы, может там уже есть что то готовое.
Если я тебя вообще правильно понял, то допустим есть какой нибудь менеджер стейтов, который имеет активный стейт и вызывает его в геймлупе. Еще менеджер имеет инициализированные поля всех возможных стейтов (логика, настройки, меню и пр.). Стейт хранит ссылку на менеджер. Тогда например в меню по нажатию кнопки старт можно сменить стейт через manager.setState(manager.game). Никаких свичей и ифов.
В либе SFML нет ничего подобного.
Буду думать, короче.
> Тогда например в меню по нажатию кнопки старт можно сменить стейт через manager.setState(manager.game)
Может быть так, за исключением того что у стейтов будет имя строкой.
И переход будет такой: managerState.SwitchTo( "gameplay" );
Ну или как-то так.
1280x720, 0:16
>При каких-то условиях
>игровое меню
onStart
>настройки
ESC_keypressed
>игровой процесс, экран проигрыша
health<0
блять вот элементарно все, но ТЫЖ ПРОГРАММИСТ, тебе надо подрочить сука, аж тресет блять, всем похуй на твои задачки, они делаются за 5 минут в лапше, в игре не это главное
>Понятно что писать портянки switch-case не дело и тут дело вступает наследование.
Проиграл. ООПервокур не палится. Гугли про ECS, анон. Предпочитай композицию наследованию. А лучше вообще забудь, что оно у тебя есть. Это прописные истины, анон.
А по твоему вопросу - внезапно, посмотри на любой фреймворк для клиент-сайда в браузере, или даже на любую standalone-либу для клиент-сайд роутинга. В интернетах эта тема разжевана для нубов тыщу раз, а тебе как раз нужно сделать то же самое.
Спасибо, как раз на компе валялась, планировал почитать ее очень нескоро.
Там в разных номерах разные алгоритмы? У меня gpu pro 7(нашел там в конце про флюиды), есть ли смысл заиметь остальные номера или это типа как старые издания?
Есть. В каждом номере свой набор бест практисов. Помни, что часто алгоритмы придумываются задолго до того, как их начинают активно использовать. С графикой это вдвойне верно, в рилтайм постепенно переезжает всякое добро из fx.
Таж хуйня, столько идей, столько мыслей, до какого нибудь скрипта(
Пиздец! Это же ад какой-то! Реально это кому то нравится? Не проще скриптом делать или такое не предусмотрено?
скоро завезут питон, а пока да, нужно напрячь извилины и узнать что такое локальные переменные макросы и функции
Не понимаю, зачем всё это делают, зачем понижать планку для вкатывальщиков? Если дегенерат не в состоянии освоить основы С++ для скриптинга, то с вероятностью 99% он в любом случае не сможет высрать ничего дельного, дай ему хоть самые продвинутые визуальные инструменты и упрощенные языки. А тот, кто способен сделать что-то годное, его и скриптинг на С++ остановит, хватит усидчивости разобраться, для этого не нужно углубляться в язык слишком далеко и изучать все 1.5к страниц Страуструпа.
Как лучше всего сохранять энтити-компоненты в скуль-базу? Каждый компонент целиком в жсон-поле запихивать?
Как бы правильней реализовать систему items в игре? Планируется много неизменяемых и часть динамически генерируемых.
Я думаю что-то из этого:
- для всего отдельный класс, ножи, камни, пистолеты, применять наследование и интерфейсы...
- декораторы?
- вместо отдельных классов создать конфиг файл, в котором будут описаны все предметы.
Хуйня, потом заебешься править. Коммон практис - сначала определять свойства объектов, а затем контейнером собирать в один объект. Если свойства динамические, то определяй интерфейсы поведения. Хочешь потом легко расширять - скрипты в помощь.
Честно говоря, вообще непонятно, чего ты хочешь и при чем тут та флешовая поделка, которую ты упомянул. У тебя есть конкретные ограничения по памяти? Ты не можешь кутэ (efl? javafx?) использовать?
Qt - нет тех фич, что мне нужны. Код на крестах, или причудливом декларативном недоjs.
JavaFx - я ебал такое на джаве делать, пользовать xml-говноразметку и вообще что-то связанное с jvm пользовать.
EJL - это вообще для встроенного миниатюрного говна, а не пеки.
И как только понадобится (а оно мне понадобится) что-то большее, чем просто раскладывать кнопочки и прикручивать CSS, все эти инструменты обсираются. Вернее, обсирается разработчик их выбравший.
Scaleform интересен тем, что поддерживает swf, значит можно пилить что-то на спижженом Flash/Animate, или их бесплатным аналогам. Единственная (наверное) альтернатива - Adobe Air, который уступает ему по производительности.
Если эта хуйня не взлетит и больше ничего не найду, то придется взять електрон и таки отхлебнуть.
Да нет, я имел в виду Ъ-значение этого слова, в смысле разработчика, который руководствуется категориями типа "нравится - не нравится", "хочется - не хочется" при выборе инструментов, а не рациональными критериями. Просто со стороны это выглядит как "фуу джава)) фуу кресты)) фу для говна)) фуу css))", причем требования так и не были озвучены: в одном посте легковесный тулкит нужен, в другом уже "это вообще для встроенного миниатюрного говна, а не пеки". Завязываться на флеш в 2018 выглядит не очень разумным решением. Эир вообще нужен для кроссплатформы в мобильники, при чем он тут? Короче, получается "посовейтуйте то, не знаю что, и вообще я уже определился, так что идите нахуй". Ээ... ну... ок?
А кто просил советовать что-то для UI? Я только объяснил для чего оно мне (для десктопа, а не игоря, это важно, очевидно) и спросил, пойдет ли вот эта конкретная хуйня с учетом того, что её Autodesk больше не поддерживает.
И да, в сравнении с недохромиумом, это легковесный тулкит для UI.
>руководствуется категориями типа "нравится - не нравится", "хочется - не хочется" при выборе инструментов, а не рациональными критериями
Это и есть рациональные критерии. Почему я должен ебать себе мозг отвратительнейшей джавой, или вообще плюсами, когда я хочу всего лишь запилить красивую морду? Я не хочу. И пытаюсь найти альтернативу получше. Что тут нерационального?
>Завязываться на флеш в 2018 выглядит не очень разумным решением.
Если будет смысл поддерживать поделку, то UI всегда можно перепилить, если вдруг это зачем-то понадобится, потому что он гвоздями как раз не прибит.
Я знаю, что сделал хуйню спросив такое на борде, ведь с этим имели дело разве что только разработчики некоторых движков и относительно старых игрушек. И хуй теперь их найдешь, особенно здесь.
>спросил, пойдет ли вот эта конкретная хуйня
В сотый раз повторяю, что ты никаких требований так и не озвучил, чем тебе не подходят альтернативы не объяснил, так что со стороны это "посовейтуйте то, не знаю что, и вообще я уже определился, так что идите нахуй".
>И да, в сравнении с недохромиумом, это легковесный тулкит для UI.
>флеш поверх юнити\уеча
>легковесный тулкит для UI.
))
>отвратительнейшей джавой
>вообще плюсами
>рациональные критерии
)))
>Если будет смысл поддерживать поделку, то UI всегда можно перепилить
Гениально, лол. Поражаюсь твоему ходу мыслей.
>И хуй теперь их найдешь, особенно здесь.
Кажется он начал что-то подозревать, угу.
Вопросов о требованиях и выборе среди других тулкитов не было, пока ты не начал отвечать. Вопрос был такой
>Тяжело ли его встраивать? Возможно ли это сейчас вообще?
Также я уточнил, что это не игра и встраиваться оно будет как раз не в игровой движок (там в юнитях и анрилах уже давно всё встроили за меня).
По поводу целесообразности пользования крестов и бляцкой джавы для быстрого создания интерфейса со свистелками, анимациями, векторными графенами и прочей хуйней… я просто промолчу.
Только что спиздил их SDK. Посмотрим что из этого получится.
Есть два двухмерных массива, заполненные цифрами. Задача - из второго массива перенести в первый данные, которые попали в красную область. Размеры красной области равны размеру первого массива. Красная область может иметь произвольное расположение во втором массиве, но всегда как минимум пересекает одну ячейку. Делаю камеру.
Нулевые координаты камеры в каком угле?
Гугли либы на твоём языке по работе с массивами, а именно stacking. Например в питоне это делается с помощью numpy
np.vstack((a,b)) к массиву a снизу добавляет строку или несколько b
np.hstack((a,b)) к массиву a сбоку добавляет столбик или несколько b
Ну и отрезать там тоже просто.
Ну да
Ссы на школьников из /gd, анон, насмехайся над ними. Байтоеб хуже пидораса, а /gd-распидорахен хуже байтоеба. /gd - раздел чмырей и унтерменшей, /pr - раздел здорового белого человека. DEVS VULT
Ромера, успокойся.
Потому что важны не фичи движка, а игры.
1. Таблица со всеми предметами, включая дефолтные свойства
2. Все те места, где эти предметы лежат, должны иметь какой-то контейнер, тот же джейсон или хмл. Тоже с параметрами.
3. По данным из (2) создаешь экземпляры классов в рантайме. Структуру классов продумывай сам, очевидное наследование и абстрактные классы.
Если у тебя нету сохранений в игре, то все это дело хранишь в файле-уровне.
Если сохранения есть, то делаешь дефолтный "файл сохранения" в котором по сути прописано состояние игры в начале, он будет иметь ту же структуру, что и все остальные сохраненки, просто значения будут выставлены тобой и ее нельзя будет модифицировать (каким образом защитить ее от переписывания и надо ли тебе это вообще решай сам).
Прогрузка уровня будет выглядеть так:
Лезешь в сохраненку, дергаешь оттуда все контейнеры на уровне, ищешь их экземпляры в "сцене", кладешь в них предметы.
Сам уровень (предметы на полу) и инвентарь гг можно просто представить как отдельные контейнеры.
Если сохраненки нету, то лезешь в "дефотную" сохраненку.
Создание предмета так:
Для создания каждого класса предметов пишешь отдельный метод (или 1 метод с классом-параметром, что по сути одно и то же)
Дергаешь из таблицы (1) его структуру и начальные параметры, даешь игроку менять то, что ты хочешь дать ему поменять.
Создаешь экземпляр выбранного класса с накрученными игроком параметрами и кладешь игроку в инвентарь или в любой другой контейнер.
Тэгай пульки при выпускании, тем же тэгом что висит на трансформе, к которому привязан твой Shooter.
При попадании по игроку, деактивируй все пульки с тэгом игрока.
При попадании по врагу не делай ничего.
Сейчас вайтишников пугает сама надпись "С++". Им всякие жсы и питоны подавай.
А визуальное программирование вообще непонятно для чего существует. Вот реально не пойму, для чего.
Ну боишься ты управления памятью, возьми джаву или додиез, хотя на уровне вкатывания особой разницы нету, как по мне.
Могу ошибаться, потому что 1,5к страниц Страуструпа не читал
Попробуй сделать аналог какой-нибудь игры самому и на готовом движке.
Сравни скорость и простоту разработки.
Тот же кокос2д, корона и тд под 2д хорошо заходят
Потому что это говноязык.
Почитать про NIH-синдром.
Только стандартные игры. Например, у меня обычно программная генерация графики, на это не расчитан ни один движок. Получается удобнее на голом ГЛ делать в конечном счете, чем бороться с архитектурой движка.
Что пишешь? Меня вот интересует тема разработки игр для старых nintendo и sega, но я всего лишь веб девелопер.
Сколько зарабатывает в среднем джун разраб на юнити в ДС? Сам я веб-разработчик, но всякие ноды.жс и реакты-хуякты уже в печёнках сидят. Хочу пилить игры, но вакансий в веб-геймдеве на всяких кокосах2д-жс с гулькин нос, поэтому обратил внимание на юнити. Вакансий джунов на юнити без опыта - куча. Но есть проблема - недавно переехал в Москву, изначальный бюджет достаточно большой, но деньги постепенно проедаются, а значит денежный вопрос стоит на первом месте, хотелось бы не только юнити-джуном стать, но и ещё с голоду не помереть.
ладно придется писать в треде с нерелевантным оппиком сука лучи поноса гадкой моче
насоветуй анон годных книжек по саенсу что скрыт за лапшой движка или может даже лучше справочник с йоба эффектами, как я понял весь геймдев стаф это всего лишь перевод йобы с математического языка на условно крестовый, стало быть может есть какая то годнота по матеши?
какие то базовые вещи понимаю, адд от аппенда отличить могу, но хотелось бы более уверенно в этом плавать что бы моч уверенно задавать вектор движения и читать мат саенс всякий по ходу
(Автор этого поста был забанен. Помянем.)
калькулюс
линейная алгебра
mathematics for 3d game programming and computer graphics (lengyel)
opengl red book
>калькулюс
>calculi ≈ камни в мочевом пузыре
попроще братух, мне тройки по всем предметам рисовали
вот линейная алгебра походу вообще топичк, то что надо ебать, остальное походу тоже в тему, отдуши
Это не матан как таковой во всей его необъятности, а "основы матанализа и интегрального исчисления", по-русски как-то так будет. "Калькулюс" короче и проще.
Я не пишу игры. Хотя в планах попробовать сделать игру для денди и ром на C с помощью компилятора cc65.
как только примешься за работу поймешь что все твои идеи уровня грабежа корованов и реализации не подлежат
Windows forms/ Renpy.
Пальцами по клавиатуре долбить.
Спасибо. А достаточно вежливо будет с моей стороны попросить указать конкретные места? Я просто нуфак совсем в этом деле, а там тонны чужого байтокода.
>>215874
>Тебе желательно иметь два режима: динамическая подгрузка и статическая.
Я про само нутро больше интересовался. Снаружи-то у меня попроще, всего три функции: загрузить, попользовать, освободить. Сейчас там совсем наивно реализованно, через счетчик использования при обнулении которого текстура полностью финализируется.
Потому что за десятки лет навертели стандарт на стандарт так что некоторые стандарты уже как отдельные языки. Но тебе нужно знать все особенности, даже самого древнего как говно мамонта стандарта, потому что именно на этом тебя подловят, и именно с этим ты скорее всего будешь работать.
>Ну боишься ты управления памятью, возьми джаву
нахуй ты такая ограниченная пидорашка?
люди делают для других что бы те ПОЛЬЗОВАЛИСЬ, как нибудь бы пользовались, а не убегали с воплями - ебал вас в рот, я не кодер
геймдев территория творческая, майнкрафт он такой один, остальным же приходится мутить сиджу модели текстуры левелы, и все это не подсилу гадкому зашоренному технарику в бабушкеном свитере и не важно что нормальный кодер выглядит совсем иначе, у креатора есть образ в голове и блоки за сам род деятельности в целом
вот сука когда ты выдрочишь ВЕСЬ пайплайн, на дисент уровне, а тебе потом какое чмо будет говорить
> возьми джаву или додиез, хотя на уровне вкатывания особой разницы нету, как по мне.
ну ты понел, да?
одни люди делают деньги, другие делают деньги на тех кто делает деньги и они заинтерисованы что бы первые делали их как можно больше, с большим комфортом и отдачей, безмозглый ты оторванный от реальности жабёнок максималист
>Ну боишься ты управления памятью, возьми джаву или додиез, хотя на уровне вкатывания особой разницы нету, как по мне.
И самое смешное - услышали слово "кресты", сами себе напридумали, сами испугались.
https://wiki.unrealengine.com/Garbage_Collection_Overview
дело не в ГК, все(кроме упити шкальников) видели парагончик и фортнайт на йосе, фремрейт и графон заибись когда руки не из сраки
просто на злоебучих крестах невозможно быстрое и кайфовое прототипирование
>фортнайт
взял ты такой на собственном движке, который знаешь до дыр, сделал мультяшную игру - и вдруг фпс в небеса! кто бы мог подумать?!
Лол, я как бы юнити-макака сам. И прекрасно понимаю за что платят прокаченным юнити-султанам.
Но это не мешает мне понимать, зачем нужны кресты и почему крестоносцам платят их бабос.
Речь в посте была не о том, что джава лучше чем кресты или додиез.
Я писал о том, что вкатывальщики вообще боятся чего бы то ни было сложнее лего.
мимо >>208272
А, ну и да, если бы ты работал в качестве программиста на проекте чуть более сложно и большом, чем собственная инди-хуйня, то для тебя не было бы секретом, что программирование оно и в геймдеве программирование. Творчество тут представлено исключительно в том виде, как его понимают бородачи в свитерах.
Интересует как в этой игре сделана отрисовка блоков. Готовые 3D-модели? Рисуются ли они полностью или невидимые полигоны отсекаются?
Как хранится информация?
С Майнкрафтом все понятно, алгоритмы уже нагуглил и понял. Там все просто. Тут же сложнее - и детализация намного выше и блоки разнообразнее, и оптимизация хорошая.
Есть несвободные исходы Space Engineers целиком на сисярпе:
https://github.com/KeenSoftwareHouse/SpaceEngineers
Тебе зачем это?
Если сядешь конторе на шею тебя проведут, пояснят за положняк в хате
а если ты дома в носок дрочешь, то и не похуй ли как?
Git?
Совсем не палишься.
Очевидный С++, еблуша. Открой гит майнкрафта и посмотри.
Я не понимаю, зачем насиловать мозги, если можно просто прикрутить фейковую хексакарту, которая на самом деле использует X/Y со смещением по центрам хексагонов фиксированным? Сильно хочется смаковать гемморой?
Java, для моддинга юзай API Minecraft Forge.
Документация на офф. сайте и на ютубе, гайды по установке там же , как и гайды по декомпиляции мойныча.
Если не умеешь кодить вообще - не лезь. Если нервов мало - тоже не лезь, потому что Фордж делали дауны.
Для знающих: Как можно было не сделать проверку НБТ тегов в хэндлере рецептов? Как можно было не сделать дефолтные контейнеры с проверкой мета предмета? Почему я сам должен это писать? Фордж точно делали дауны.
Мертвопостинг инкаминг
>То же своего рода p2p, так как сам агрегатор, издатель игры, сервера не держит.
Но держит агрегатор. Развал агрегатора = развал всей системы. Подобное было при закрытии GameSpy, например (когда разрабам пришлось в срочном порядке перепиливать игры, но т.к. многие из игр были старыми, до них ни у кого руки и не дошли, хотя понятно, что у старых игр на ентом гейспае было полтора сервера в списке)
Я же так понимаю, вопрошающего надёжность интересовала. Можно оставить клиент-сервер в самой игре, а агрегатор выпилить и заменить на DHT, но это теория конечно
>достаточно брать адрес мастер-сервера из конфига
Как вариант.
Но я ж типичный погромизд, которому важно не "чтобы выполняло задачи", а чтобы было похитровыебаннее.
Ты имеешь ввиду OpenGL Programming Guide?
Моя задача состоит в оптимизации сетевой части. Надо собрать игроку данные о его ближайших соседях в заданной области. Перебирать всё - сложность очевидно квадратичная. Есть всякие древа со звёздочками и без звёздочек, есть пространственные хеши, есть кокието кривые. Некоторые из них хорошо работают для редко меняющихся данных. Всякие геохеши и подобное. Они вроде как не особо подходят же.
Why? Какая сложность вставки/удоления/поиска? Как с эффективностью по памяти/кешу? Оно вообще норм в 2D?
Внезапно, у тяна (rimworld который) есть туториал на тему того, как он пилил то самое, что ты спрашиваешь, как раз в 2д, можешь глянуть.
На самом деле я уже начал сам изучать. Запилил пока наивный Spatial Hash Map. 1к поисков из 100к по 500 штук примерно 30 лямов нанопопугаев (с учётом полного пересоздания индекса), но это не точно. Без сравнения с чем либо бенчмарк бесполезен.
Ещё увидел реализацию чего-то похожего на k-d древо и попробую с этим сравнить.
Наивное хеширование против k-d древа. Побеждает k-d древо.
Не нашел ссылку. Там есть что-то стоящее?
>>242260
Таки сам погуглил и уточню. Что лучше?
- Hierarchical Spatial Hash Grid
- Linear/Implicit k-d Tree
- Linear/Implicit Quadtree
Судя по всему HSHG будет эффективнее в мутабельной версии, а джва остальных будет норм пересоздавать каждый фрейм. По идее quadtree быстрее, чем k-d tree и у обоих расход памяти O(n).
У меня уже есть реализация k-d tree и она вроде норм. Строится каждый фрейм в 1.5 раза медленнее, чем наивный Spatial Hash, однако поиск происходит за наносекунды (плюс-минус O(log(n)) же) и совсем не ест память. Там от 12, 16 или 24 байт на элемент (от 2x float + uint32 до 2x double + uint64). Правда я проверяю всё это на рандомных точках и запросах.
Я пока не знаю, есть ли что-то профитное у HSHG. А ещё я видел упоминание Z-order curve в контексте quadtree (по крайней мере об этом есть упоминание в педевикии). Это тоже требует изучения.
Некоторое нагугленное:
https://www.gamedev.net/forums/topic/661021-quad-trees-vs-r-trees-vs-spacial-hashmaps/
https://en.wikipedia.org/wiki/Quadtree
https://medium.com/@agafonkin/a-dive-into-spatial-search-algorithms-ebd0c5e39d2a (я оттуда портанул k-d древо)
https://en.wikipedia.org/wiki/Z-order_curve
https://gist.github.com/kirbysayshi/1760774
Ещё гуглятся всякие исследования™, но я не силён в чтении этого дерьма.
> ...но волею судеб приходится заниматься базами данных.
Ключевой момент - "судеб".
Лан бы що судьбы, то хер с ним
Если для отсечения графики - то в 21 веке не очень, если для абстрактных сущностей как у тебя - то не подойдёт совсем, нужны полигоны, по которым пространство будет рассекаться, а у тебя там абстрактные 2д-сущности.
Quadtree тебе будет в самый раз.
Так ты гугли на геймдевелоперских форумах.
https://gamedev.stackexchange.com/questions/87138/fully-dynamic-kd-tree-vs-quadtree
Вот чел написал что я хотел написать (про хэши я не знал, но не стал бы их советовать все равно).
1. Kd-дерево хорошо для статических целей, для динамических лучше quad-дерево с минимальным порогом.
2. Вообще kd-деревья хороши для сильно многомерных пространств, для 2 и 3 quad и octo деревья симпатичнее, хотя не всегда эффективнее
3. Но если у тебя задача найти не ближайших соседей, а есть ли соседи в радиусе R, то тебе вообще не деревья нужны, а грид из квадратов. При перемещении объекта он делает floor(obj.x/shirina_kvadrata), и записывает себя в соответствующую ячейку, удаля себя из той из которой он ушел. При поиске в радиусе r ты просто проходишь по всем ячейкам и получаешь список объектов.
4. Хэши эффективны только для приблизительных расчетов
Изображение в смысле лого? Заставку первичную.
Я хрен знаю. Код необходимо видеть, иначе наверное никак.
IDA pro попробуй дизассемблер.
Запусти через него свою игру, и наблюдай какие процессы работают в тот или иной момент игры.
Но результат там на сколько я знаю ты в ассемблерном коде получишь
Такие дела.
Нужно написать игру. Клон Героев 3 на пхп.
Так вот.
Прошу тебя дать ссылки на статьи с алгоритмами написания, с планировкой написания различных частей и тд.
У меня опыта в написании никакого нет, даже самых простых программ.
>Прошу тебя дать ссылки на статьи с алгоритмами написания, с планировкой написания различных частей и тд.
https://hh.ru/search/vacancy?text=Дворник&area=1&from=suggest_post
360x356, 0:03
Охуенный подъеб, пиздец, нахуй иди.
Берёшь, пишешь загрузчик для 8286. Переходишь в защищённый режим, настраиваешь все прерывания, пишешь драйверы для мыши и клавиатуры, графику пишешь прямо в VGA. И чтобы на дискете помещалось.
Что системы контроля версий прижились только пару лет назад, что код - все еще каша гениальных мыслей какого-нибудь местного аутиста с файлами по 2000 строк кода?
Что про паттерны и солидопарашу можно даже не заикаться, год обжекты и суперклассы во все поля?
Лучше бы дотнет официально завезли, сразу же бы перекатился со сраного юнити на УЕ4.
Да, именно так все и есть. А еще они до сих пор считают своим долгом заново изобретать редактор и ide для каждого нового фреймворка.
Справедливости ради - те же системы контроля версий (читай гит) плохо для гд приспособлены, так как там обычно в куче и бинарники, и исходники, не очень удобно.
Не, мой препод.
Согласен. Но ощутить, что значит бутстрапить самого себя (даже если это всего 100 строк простого ассемблера), должен каждый.
Мне показалось проще использовать именно что статику. Т.е. я создаю каждый тик древо поиска целиком с нуля. По мимо этого мне надо хранить историю за прошлые полсекунды. Ибо это сервер, а не клиент. В 95% случаев мне нужно узнать, кто тут рядом с игроком стоит, чтоб лишнего не отправлять.
Эти алгоритмы работают для отдельных картинок, но (имхо) в динамике смотрятся как говно. В общем не смотря на то что вроде бы и можно найти информацию в открытом доступе, всё это хуйня какая-то, я хочу нойза, дисторшена, хуй его знает чего. Куда копать?
// Из знакомых примеров знаю лишь то, как изображение проецировалось на экраны телевизоров. Телевизионная сетка значительно визуально улучшала качество изображения. Также, в мс-дос, когда делали видео, часть видосов была для экономии места перекодирована так, что были пропущены строки. И по какой-то причине это визуально воспринималось как более качественная картинка, чем если без этих строк. В старом divx-player был примитивный улучшайзер, он подмешивал случайный шум к картинке: точно также, картинка казалась более качественной, хотя это такое же шакальное изображение. Что у этих решений общего? При всей видимой статичности благодаря этим решениям визуализируют одну и ту же шакальную текстуру совсем иначе, превращая эту текстуру на выходе в, грубо говоря, несколько совсем разных текстур.
waifu2x конечно же
Пишу вот инвентарь на юньке и интересно как сделать инвентарь с ситемой ячеек.
К примеру в стиле 7.62 или Е5.
Если с простым инветарём всё понтно, то как сделать инвентарь где предметы могут занимать не один слот, а скажем 1х2 или 4х4
До этого занимался работой со звуком.
А как их в с# то обьявить.
И как найти скажем элемент по определённому номеру. Нигде не нашёл.
>влиться в какую-то тиму, чтобы чему-то научиться
обучение денег стоит
копи деньги (грузчиком, например, или жопой если ты симпатяга)
находи ментора
Копай себе в очко, сука. Можно более четко мысли выражать?
ИТТ мы можем объяснить базовые и продвинутые концепции языка, и
программирования в целом, поможем вкатывающимся, подскажем что
выбрать для веба, игр или спасибо абу блокчейна.
https://www.rust-lang.org
> Пачиму helloworld весит как моя мамка?!1й
https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.html
Читать
Оф. книга, она же растбук
https://doc.rust-lang.org/book/
https://rustbyexample.com/
Очень хорошая книга, отлично зайдет после растбука:
http://shop.oreilly.com/product/0636920040385.do
Упражнения
https://exercism.io/tracks/rust
https://github.com/crazymykl/rust-koans
Писать
IDE
https://areweideyet.com/
Вебня
http://www.arewewebyet.org/
Игры
http://arewegameyet.com/
Etc
https://wiki.mozilla.org/Areweyet
Список интересных проектов
https://github.com/rust-unofficial/awesome-rust
Новости
Компиляция всего, что произошло за неделю
Иногда постят вакансии
https://this-week-in-rust.org/
Сколько вешать в лайках
https://github.com/trending/rust
Оп рекомендует:
https://www.amethyst.rs/
ИТТ мы можем объяснить базовые и продвинутые концепции языка, и
программирования в целом, поможем вкатывающимся, подскажем что
выбрать для веба, игр или спасибо абу блокчейна.
https://www.rust-lang.org
> Пачиму helloworld весит как моя мамка?!1й
https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.html
Читать
Оф. книга, она же растбук
https://doc.rust-lang.org/book/
https://rustbyexample.com/
Очень хорошая книга, отлично зайдет после растбука:
http://shop.oreilly.com/product/0636920040385.do
Упражнения
https://exercism.io/tracks/rust
https://github.com/crazymykl/rust-koans
Писать
IDE
https://areweideyet.com/
Вебня
http://www.arewewebyet.org/
Игры
http://arewegameyet.com/
Etc
https://wiki.mozilla.org/Areweyet
Список интересных проектов
https://github.com/rust-unofficial/awesome-rust
Новости
Компиляция всего, что произошло за неделю
Иногда постят вакансии
https://this-week-in-rust.org/
Сколько вешать в лайках
https://github.com/trending/rust
Оп рекомендует:
https://www.amethyst.rs/
Бля, сорян. Промахнулся.
> #unity #godot #ue4 #unreal
> Вопросы по Unity и прочим движкам ... Буду репортить, ибо нехуй
Профилирующих, ищи утечки.
По поводу тредов - зачем рендер выносить в отдельный тред, если он завязан на игровой цикл?
Создаю окно:
sf::RenderWindow window(sf::VideoMode::getDesktopMode(), "", sf::Style::Fullscreen);
После чего рисую текст случайного цвета на экране.
Цвет меняется каждый раз перед вызовом window.display();
Так вот, при старте программы, в самом начале, есть две задержки - по 1-2 секунды. Во время задержек на экране есть отрисованный текст, но его цвет не изменяется. После задержекпрограмма ведёт себя как ожидается.
Вопрос: откуда эти задержки и почему их нет, когда окно создаётся в режиме sf::Style::Default ?
Некроответ. Покури catlikecoding, там роскошный туториал по гексагонам есть, поймет даже конченый дебил. Там от самого старта до генерации довольно круто выглядящих ландшафтов, в основе которых лежат гексагоны. Лучше ты точно нигде не найдешь.
Тебе же написали - художникам удобнее мыслить "таак, теперь накреним эту хуевину на 10 градусов", чем ебаться с кватернионами.
>Чо, реально используют углы Эйлера? Есть же божественные кватернионы
Ну так чтобы построить кватернион, тебе и надо будет или углы Эйлера использовать или ось+угол. В какой-нибудь юнити ты делаешь rotation = Quaternion.fromEuler( 10, 0, 0 ).
>надо будет или углы Эйлера использовать
Смысл весь теряется же. Схватишь gimbal lock какой-нибудь, в космическом симуляторе, например.
Есть вопрос про сабпиксельную растеризацию типа msaa. Зачем нужна эта дискретность типа 4x, 8x? Нельзя ли прямо на месте интерполировать цвет отношением площадей пикселя (цвета который в буфере и цвета полигона)?
Считать отношение площадей не заебешься?
>Нельзя ли прямо на месте интерполировать цвет отношением площадей пикселя (цвета который в буфере и цвета полигона)?
Можно, но тогда тебе придется все пиксели сортировать по глубине, потому что альфа-бленд не коммутативный.
Я о том, что сразу кватернион ты из головы не напишешь как константу, он сложный для понимания. Тебе нужен какой-то человекопонимаемый формат (углы Эйлера, ось-угол, матрица ориентации), чтобы из него сконструировать кватернион, который ты потом будешь использовать.
Я слышал, что используют libtcod.
http://www.roguebasin.com/index.php?title=Complete_Roguelike_Tutorial,_using_python+libtcod
На нем же нихуя не делают вне Valve. Скорее всего инфы никакой нормальной не нароешь, если нет прямого выхода на разрабов. А сидеть и самому разбираться в движке который никому ненужен помоему не очень идея.
APEX на сурсе так-то.
Расскажите как делали делают пиратские сервера, в частности к вову. Да, в курсе что есть открытые проекты и всё такое.
Но меня интересует больше в общих чертах всё это.
Как узнавали что что игра передаёт в пакетах? Как такое реверсят? Плюс от версии к версии структура пакета может меняться. Например я слышал что, начиная с Катаклизма аддон такой к вову пакеты шифруются RSA в 4096 бит, но тем не менее есть себе сервера.
Как вообще придумывают проектируют такую сложную систему как сервер? С чего начинают кроме регистрации юзеров?
>Как узнавали что что игра передаёт в пакетах? Как такое реверсят?
Есть софт чтобы перехватывать траффик. Реверсят посылая в клиент такие же пакеты и наблюдая, как он на них реагирует.
>пакеты шифруются RSA в 4096 бит,
Ключи для расшифровки есть у клиента, потому что иначе он не смог бы их расшифровать, лол. Остаётся найти его в дебаггере.
>Как вообще придумывают проектируют такую сложную систему как сервер?
Сервер - это то же самое, что оффлайновая игра, только еще и графический движок писать не нужно. Ну и вместо клавиатуры или геймпада большой вектор сокетов, который ты поллишь.
Исходников сурса же нет, ЕМНИП, только их невнятный SDK.
Если всё так достаточно просто, почему пиратские сервера, часто имеют большое количество багов и отличий в худшую сторону (что-то работает не так, как на официальном сервере)?
мимопроходилинтересующийся
Потому-что одно дело дешифровать и разобрать пакеты с командами, а другое дело с нуля выстроить всю логику игры
Вопрос был про техническую часть, реверс-инжиниринг. ¯\_(ツ)_/¯ Кроме этого есть скрипты, которых тысячи и которые не очень интересны хакерам, которые этим занимаются ради челленжа.
И которые пореверсить в общем случае невозможно.
насчет книги не уверен но статьи есть
http://www.gamasutra.com/view/news/32531/Analysis_The_Eight_Rules_Of_Roguelike_Design.php
http://www.roguebasin.com/index.php?title=Definition
http://www.roguebasin.com/index.php?title=Roguelike_Dev_FAQ
https://gamedevelopment.tutsplus.com/articles/the-key-design-elements-of-roguelikes--cms-23510
http://www.roguebasin.com/index.php?title=How_to_Write_a_Roguelike_in_15_Steps
и т.п.
OpenGL + C++
Из этих двух по первому больше материалов, а на втором конечно писать приятнее и интереснее (плюс можно потом легко портировать в браузер). Думаю если только вкатываешься в кодинг, то лучше первое, в остальных случаях - второе.
Что можете посоветовать вкатальщику, который хочет в дальнейшем работать в геймдеве? В данный момент работаю дизайнером в окологеймдеве вот так вот, да, работал с движками UDK/Unreal/Unity со стороны десигнера, и никак со стороны кодера. Хочется узнать как вообще во все это дело вкатываются программисты, типа поднимают какое-то базовое знание и потом постепенно вкатываются в геймдев или попросту изучают код в рамках какого-то конкретного движка до посинения, и потом устраиваются туда, куда нужны посиневшие в рамках движка люди? Насколько в нынешних реалиях актуальна связка C++ и Unreal 4? Куда не гляну, везде пользуются unity + c#/python даже вот в том месте где работаю я сам., но мне юнити с графисечкой стороны не очень нравится. Либо вообще не смотреть пока ни в какие конкретные области и просто учить плюсы? Хочется узнать у тех, кто занимается этим профессионально, если такие есть.
>Что можете посоветовать вкатальщику, который хочет в дальнейшем работать в геймдеве?
Одуматься.
Ну вообще мне одумываться поздно, я еще и английский учу, и вообще хочу укатываться и вкатываться. Всё совсем плохо. Ну и полный офис геймдев погромистов как бы намекает что не так уж сильно одуматься нужно видимо.
Есть в кодинге области, где работа более тяжелая, а платят меньше, чем в других. Геймдев одна из них. Идти можно только за идею, но при этом сама работа крайне унылая и однообразная, так что энтузиазм быстро испарится. А куча работы и низкая ЗП останутся.
А если с перспективой дальнейшего съеба из россии? Просто хочу на берегу определиться со всеми условиями и дальше уже ебашить не взирая ни на что, понимаю что есть что-то проще плюсов, понимаю что есть области где платят больше и вкатиться легче, вот только уныние от того, что я занимаюсь не интересным мне делом может скатить в говно вообще всё. И я не знаю что мне делать.
С т.з. трактора геймдев тоже не очень привлекателен. Уезжают легче всего крутые спецы с особыми, уникальными, наукоемкими или сильно востребованными скилами. Геймдев же это обычный кодинг, там не нужно рокет саенса, нет ничего особо сложного в массе. Разве что в дебрях графики.
Ну как в итоге люди в геймдеве оказываются-то? Куда не посмотри везде инди, мобайл, кукурузисы, но оно не востребовано и нахуй никому не нужно при этом.
ты не задумывался почему в геймдеве низкие зп? одна из причин та же, по которой по этой линии сложно завести трактор - очень много людей ломится в геймдев, ну вот как ты
Окей, тогда спрошу по другому, если учиться кодингу в unreal на плюсах, знания полученные при этом могут пригодиться в чем-то дальше, в чем-то другом, или только строго для кодинга в unreal?
Общие принципы кодинга пригодятся, конечно. Но на них одних ты далеко не уйдешь. Без какой-то специализации сейчас никак.
Ну чтож пока учусь буду пытаться в геймдев, если совсем ни в какую, уйду в смузи
И за что сейчас платят юнити-султанам?
>Насколько в нынешних реалиях актуальна связка C++ и Unreal 4?
Очень актуальна не только в геймдеве. Есть большой спрос на всякие демки, интерактивные презентации. Особенно пару лет назад, когда был пик популярности ВР, и каждый мамкин бизнесмен делал ВР-аттракционы.
Если нравится то учи конечно, я вот в разработку драйверов пытаюсь вкатиться, понимаю что нахуй никому не нужно + без опыта никуда и не возьмут, ну и похуй! Зато мне интересно.
мимо
> Творчество тут представлено исключительно в том виде, как его понимают бородачи в свитерах.
Блупринты не для погромистов, а для геймдизайнеров.
>// Из знакомых примеров знаю лишь то, как изображение проецировалось на экраны телевизоров. Телевизионная сетка значительно визуально улучшала качество изображения. Также, в мс-дос, когда делали видео, часть видосов была для экономии места перекодирована так, что были пропущены строки. И по какой-то причине это визуально воспринималось как более качественная картинка, чем если без этих строк. В старом divx-player был примитивный улучшайзер, он подмешивал случайный шум к картинке: точно также, картинка казалась более качественной, хотя это такое же шакальное изображение. Что у этих решений общего? При всей видимой статичности благодаря этим решениям визуализируют одну и ту же шакальную текстуру совсем иначе, превращая эту текстуру на выходе в, грубо говоря, несколько совсем разных текстур.
Основной момент который не понимают создатели фильтров под "ящик из 90х":
https://www.youtube.com/watch?v=Ea6tw-gulnQ
Ну есть же CRT Royale вроде, который вроде как физически эмулирует CRT (с различными решётками и всеми делами). Правда я слышал, что для "той самой" картинки лучше около 4К разрешение
Normalize
Это сорт оф барицентрических координат для одномерного случая.
l = b - a; // длина исходного вектора
lt = b - t; // длина второго вектора в системе координат первого вектора
bar = l / lt; // их отношение даст нормализованую координату.
Если выхоход за пределы отрезка недопустим, то ее еще нужно клампнуть в [0-1].
Lerp01
Допустим какая-то сущность должна двигаться по заданной траектории по списку тайлов.
Расстояние между двумя соседними тайлами эта сущность должна преодолевать за 1000 мс.
Как это сделать без каких-то дёрганий и чтобы она плавно двигалась?
Пробовал как точно, не помню, кода по рукой нет и получалась хуйня, типа пикрелейтеда.
Чуть дальше намеченного проходит и в итоге накапливается "погрешность" и сущность двигается не по тайлам, как-то около них.
Ну ставь ее в центр тайла, в чем проблема-то?
Все игры нужно разрабатывать на Расте!
Интерполировать координаты надо, а не считать s = vt как для реалтайма. Тогда погрешность накапливаться не будет.
https://ru.wikipedia.org/wiki/Билинейная_интерполяция
Как это разрушение реализовано? Вроде воксели, а вроде и нет.
Не это блочная разрушаемость. Вангую там у каждого блока коллайдер и некоторая модель энергии, типо если на блок сильно довить, то часть своей энергии он передаст соседям и они тоже сломаются. Наверно есть особый юзкейс для верхних блоков, чтобы имитировать гравитацию.
> Вопросы по Unity и прочим движкам
> - в соответствующем разделе
>#unity
>#godot
>#ue4
>#unreal
Всмысле блочная? В 2003 разве можно было порезать целый ебаный дом в несколько этажей на куски да еще и с коллиженами своими? Это же времена жифорс ФХ и селеронов на пресскоте
Я не улавливают твое смущение.
Дом порезан на блоки заранее еще в 3д редакторе, а какие конкретно блоки разрушать решается уже физическим движком на основе коллизий и энергии(тут я не уверен).
Это не воксели в их изначальном понимании как наименьшай точка в 3д на которую действует вся возможная физика. Например воксельный дом корректно бы считал круглые дыры в стене диаметром меньше болока или например держал угол дома без основания снизу если центр масс дома и вязкость его материала позволяло такое. На виде всего этого нет.
Вот посмотри годный пример вокселей в 2д(это пиксели, лол):
https://habr.com/en/post/345104/
Это просто анимации, а логика по контрольным точкам смотрит, куда попали\где что взорвалось и т.п.
>куда более мелкие и точечные дыры делать.
Это просто анимации, а логика по контрольным точкам смотрит, куда попали\где что взорвалось и т.п.
вот тут эффекты подсказывают разрешение грида для просчета дестракшна. вероятно, все ломаемые стены - это квадраты 1х1 юнит, замапленные на квадрат в uv-спейсе. остальное - просто пропы, которые тупо делают "пуфф!"
в пределах радиуса взрыва удаляешь все "совсем уничтоженные" стены, отбираешь "покоцанные"
для покоцанных сделав пересечение сферы взрыва и всех эджей, можно построить простой ровный срез от точки до точки в uv спейсе
на этом срезу можно сгенерировать несколько точек и чуть рандомизировать их позиции
а можно подумать, как замутить ступенчатый "кирпичный" срез
посчитать уклон, количество рядов, сгенерировать змейку, чуть рандомизировать
результат помножить на матрицу трансформации для этой стены, старый полигон удалить
остается толща среза - но это та же линия среза + оффсет по высоте и полоска полигонов, построенная между ними, замаппленная от балды на равномерную текстуру соответствующего материала, всё это затем опять же умножается на матрицу трансформации стены
что касается мелких дыр от пуль, то берется звёздочка и вычитается из этого квадратика
тут трикс в триангуляции и случаях, когда дырка на краю. поэтому думаю это отдельная большая проблема, другой алгоритм для разрушения
типа: http://www.angusj.com/delphi/clipper.php
мож как-то проще делалось это всё, хз. те же поксели, что и в вормсе, по сути
короче, надеюсь этот высер окажется хоть чем-то полезным
Какой язык и движок лучше взять? Не планирую 3д и прочее.
Мне нужно, чтобы автоматически распознавало юнити3д и открывало с#.
Какой стек технологий для вката в геймдев? Все пишут про C# и C++, но я слышал, что и на Питоне с Джавой что-то делают.
Возьми движок и вкатывайся.
Если навыков программирования достаточно, то с движком проблем не будет
Если рассортировать вещи по сложности, то язык будет где-то глубоко под фасадом api под шконкой.
Блять. Без языка нельзя. Работа программера — это не о языках. Языки это, сука, просто инструменты. То что ты выучишь как на джаве кнопку сделать тебе нихуя не даст. Учить надо программирование блять.
Сипп это исключение, ибо лучше него для очень многих вещей ещё не придумали. Но зависит от того, где ты хочешь работать, если в мобильный сегмент сидеть на подхвате писать пару методов в месяц, то нахуй тебе ничего кроме питона/сижоп не нужно
У меня нет идей я тупой.
Хочу написать простую игру типа не смотри на петуху чтобы убедиться, мое это или нет.
Какие есть годные пособия по написанию игры на Java, например? Те чтобы большой проект был разбит на этапы и я сам мог подумать, как что делается, а не тупо копипастить за "гуру"?
Знание ООП на уровне понимания что гуглить - есть
И тут ты такой рассказываешь как учить именно программирование (и учить правильно), а не языки.
берешь популярный игровой фреймворк, изучаешь доки и примеры, повторяешь с парой фреймворков и движков, профит
Вот этот все правильно написал, не добавить, не отнять.
>И тут ты такой рассказываешь как учить именно программирование (и учить правильно), а не языки.
1) SICP
2) Андре ламот "программирование трехмерных игр для windows" - только после п.1 и при прочтении внимательно сверяйся с прочитанным ранее и понимай где мякотка про графин а где быдлопроцедурное программирование.
3) Nvidia GPU Gems - что бы имет представление о шойдерах и что на них реализуют. Поскорбеть о том, что в мире гпу от процедурного программирования не уйти.
4) Game Engine Architecture от создателя дрейкфейса - подивиться як байтоебы на соснулях без core i5/core i7 страдают. Ну и подчерпнуть для себя низкоуровневую поеботу, которая пригодится разв в столетие.
Есть сервер, есть клиенты и задача их синхронизации.
Правильно ли я понимаю, что на сервере я храню объекты в условной хэшмапе по ключу(uuid, например) и при подключении клиента скидываю ему всё, а дальше просто обновляю то, что изменилось?
Я б поучаствовал.
>конкурса меряния програмерских пиписек
Самый быстрый фруструм каллинг + софтварный растеризатор.
Я имею ввиду типа такого: https://www.youtube.com/watch?v=oSzYliSASKc на 1:57 которые в игрока летят
Та нi, цэ другiй
Откуда инфа? Что то не верится что те кто делают энгрибердсов и прочих жожожамперов сидят на хуяхю
Не тупи, это обычная моделька уровня две перпендикулярные текстурки с картинкой "раскаленная пуля ух бля горячо аж жжотса".
>делаешь дефолтный "файл сохранения" в котором по сути прописано состояние игры в начале, он будет иметь ту же структуру
Интересный метод.
Господа, покритикуйте мой вариант:
Начальное расположение элементов на каждом уровне удобно расставлено в редакторе. Никакой файл сохранения не используется. При этом, каждый элемент при своей загрузке, определяет, существует ли он? И если он не существует, он останавливает дальнейшую подгрузку своих данных и выгружается. Если он существует, то чекает своё состояние, расположение и выстанавливает, так же проверяет есть ли у него незагруженные дочерние объекты и подгружает их.
Существование объектов задаётся файлом сохранения, очевидно.
Какие минусы, кроме лишней загрузки?
> Никакой файл сохранения не используется.
> Существование объектов задаётся файлом сохранения, очевидно.
Ты какой-то всратый. Ещё у тебя ООП головного мозга, но это тема для отдельного разговора.
Ты какой-то школьный. А еще ECS - это паттерн ООП (точнее это подпаттерн паттерна data driven, который - паттерн ООП). Deal with it
Чего бля? Испольовать статистику о уровне в качестве сейва? Ты че ебанутый? А если плейор введит импульс 101 и получит божественную залупу, которой не было в сохранении, что тогда?
Все васяны жсон используют для сохранений в котором пишется "мобж аллах, позиция (нан, нан, нан)б хп 834, жопа "разъебана" и n = 234634" при сохранении и в котором читается эта вся инфа при загрузке.
Т.е. ты увидел слово "объект" и у тебя сразу разорвало жопу от того, что ООП ты так и не осилил, а объекты в твоем жалком мирке бывают только в ООП?
Ну, попроси мамку свою тебя пожалеть.
> А положение вершин 3д модели уже процессор считает
Смотря что, но нет. Вершины обрабатываются вершинными шейдерами (Vertex Shader). Самый примитивный вариант это аффинные трансформации (перевороты, перемещения, изменение размеров), но можно и многое другое делать. Часть вершин возможно придется через CPU просчитывать но тут стараются максимально уменьшить их количество - чем больше вершин на CPU прочсчитывают тем сильнее приозводительность по пизде идет. К примеру скелетная анимация. На CPU просчитывается положение костей, передается в GPU, а там уже на основе костей простчитываются все остальные точки модели. Естественно, если ограничения на анимацию позволяют (если физика не мешает) то и вычисления над скелетом перемещаются в GPU.
Я имею ввиду вот что. Те, кто играл в варкрафт 3 наверняка видели что юниту можно приказать атаковать цель, он начнёт замахиваться и ему можно успеть дать команду "Отставить".
В итоге часть анимации воспроизведётся, но атаки не будет.
Как такое делается?
проигралась анимация замаха, далее проверяем. если всё ещё бьем - проигрываем анимацию удара
сюда же комбы всякие. типа, есть анимация второго удара, она начинается из финальной позы первого. если игрок нажал атаку вовремя - проигрываем второй удар и т.д.
в противном случае возвращаем в пассивное положение
рекомендую освоить азы аним графов в уе4. топик на самом деле огромный, можно легко книгу написать
> искусственному интеллекту
Первым делом тебе нужно чётко понять, что искуственного интеллекта не бывает, потому что люди толком не понимают, как работает естественный. Затем, если не обижен ангельским, можно посмотреть видосики Томми Томпсона: https://www.youtube.com/user/tthompso/videos , особенно рекомендую про наиболее часто используемые в области паттерны - behaviour tree https://www.youtube.com/watch?v=6VBCXvfNlCM и FSM https://www.youtube.com/watch?v=JyF0oyarz4U .
классный дизайн лампы
800x450, 0:47
Решилось добавлением XInitThreads
В современных играх - это не баг, а фича.
но там какой-то модератор сначала хотел просто так закрыть раздачу, утверждая что это не одна серия, а теперь докопался до качества. Такое чувство что там бюрократии больше чем гос. аппарате, два пакета правил и целое иерархическое дерево админов.
Топ)
Прошел по ссылке, не пожалел)
Двойной смайл означает что все таки я дебил? Я все сиденье прожег, он второй день отменяет раздачи да закидывает в тестовый форум. Дожили блять, цензура на рутрекере.
ебать там у вахтёра горит с того, что к нему обращаются не на "Вы" (именно, с большой буквы). ору!
ShaderX4 где?
Ищу кого-нибудь для общения вокруг программирования и матана, обмена ссылками и книгами, а так же для парного программирования.
Мои языки C, Python. Считаю что программист из меня так себе.
Сферы интересов: Теория игр, теория принятия решений, Управление и оптимизация, многокритериальное принятие решений, Марковские модели, конечные автоматы, теория графов, теория вероятностей, статистические методы, имитационное моделирование, ии и коллективное поведение и проч.
Давай общаться. Я тоже искал как-то таких людей.
Но обычно ищут когда хоть какие-то идеи есть в голове, которые хочется реализовать
Клон Квейка 1996
Лучше свой opengl напишите.
Оригинальные предложения будут? Или вы хотите в очередной раз воспроизвести то, что до вас делали десятки (а может и сотни) раз?
Оригинальные предложения конечно будут. Есть идея поэкспериментировать немножко с самой концепцией игровых двигателей. Идея заключается в том, чтобы на стадии разработки игры, меньше кодить, а больше "рисовать"/создавать. Нет речь идёт не о так называемых блюпринтах, а о обычном присвоении имён файлам контента. Ну например. Создал ты локацию, дома, дороги, деревья, воду, траву. И добавляешь во все названия стен префикс (w). T.e упрощенно это выглядит прмерно так:
Object(w).3ds
или
Stena215(w).Mdl
Или что-то в этом роде, хоть Blablabla(w).dff. Поскольку двиг во время трансляции контента и кода, всеравно наткнется на символ W в имени файла(/сетки/меша/аудио/изображения/кода/...) и будет воспринимать эту сетку как нечто статичное и скорее всего не разбивающееся в осколки , несветящееся(поскольку нет B, не звучащее (по скольку нет S, имеющее фиксированный уpовень детализации, поскольку нет L1,2,3... и пр групп сеток Level of detailed.
Но вот к примеру эта стена будет иметь приattachенную (с точки зрения моделирования) картину или тот же ковер. Т.е объект временно наглухо закреплённый за другим главным объектом, и который будет дочерним пока на него не по взаимодействовали физически. Вот и назовем этот ковер как нибудь типо blablabla(P20D,) что в переводе на людской означает упасть от 20 кг нагрузки (удар, выстрел и пр) и перейти в стадию тряпичной куклы P20D, ну или в стадию обычного твердого тела типо box P20B.
Есть у меня короче задумки на этот счёт, и не просто задумки, а некая реализация уже есть в виде небольшого консольного приложеница (около 300 строк кода) , которое загружает находящийся рядом с собой блокнотик, в который я аккуратно записал типо список типо объектов, типо существующей сцены, на самом деле сцены нет, но есть заголовки файлов с инструкциями на моём "языке" сценической разметки. Так вот задача моего движка, разобраться что там к чему ещё на стадии интерпретации кода. Пока я по сути не программировал более высокоуровневую логику типо "этот объект повреждён, заменим его другой четкой с вмятиной и пр.. " , пока я колупвюсь в более низкоуровневых дебрях, отвечающих за синтаксический анализ заголовков файлов. Также попутно учу свой двиг разбирать и делить длинные заголовки на скобки и так называемые токины(логически законченные единицы языка). Ведь бывают и такие файлики -
Tree(Tgrass.jpg, FS, O15, L3000-). Что должно заставить двиг обрабатывать сетку tree с изображением дерева, как некий стационарный НЕ динамический объект, способный гореть, и видимый до 3км но далее исчезающий.
всего в моей системе 17 упр символов
При том при сем, шо я довольно большое ударение ставлю именно на логической составляющей движка, мне совершенно похеру на рендер. У меня его своего вообще не будет. Это возгружу на уже имеющиеся достижения гениев графики, будь то directX, opengl, irrlicht, glscene и пр. Их всеравно не перещеголять в скорости рисования треугольников.
Оригинальные предложения конечно будут. Есть идея поэкспериментировать немножко с самой концепцией игровых двигателей. Идея заключается в том, чтобы на стадии разработки игры, меньше кодить, а больше "рисовать"/создавать. Нет речь идёт не о так называемых блюпринтах, а о обычном присвоении имён файлам контента. Ну например. Создал ты локацию, дома, дороги, деревья, воду, траву. И добавляешь во все названия стен префикс (w). T.e упрощенно это выглядит прмерно так:
Object(w).3ds
или
Stena215(w).Mdl
Или что-то в этом роде, хоть Blablabla(w).dff. Поскольку двиг во время трансляции контента и кода, всеравно наткнется на символ W в имени файла(/сетки/меша/аудио/изображения/кода/...) и будет воспринимать эту сетку как нечто статичное и скорее всего не разбивающееся в осколки , несветящееся(поскольку нет B, не звучащее (по скольку нет S, имеющее фиксированный уpовень детализации, поскольку нет L1,2,3... и пр групп сеток Level of detailed.
Но вот к примеру эта стена будет иметь приattachенную (с точки зрения моделирования) картину или тот же ковер. Т.е объект временно наглухо закреплённый за другим главным объектом, и который будет дочерним пока на него не по взаимодействовали физически. Вот и назовем этот ковер как нибудь типо blablabla(P20D,) что в переводе на людской означает упасть от 20 кг нагрузки (удар, выстрел и пр) и перейти в стадию тряпичной куклы P20D, ну или в стадию обычного твердого тела типо box P20B.
Есть у меня короче задумки на этот счёт, и не просто задумки, а некая реализация уже есть в виде небольшого консольного приложеница (около 300 строк кода) , которое загружает находящийся рядом с собой блокнотик, в который я аккуратно записал типо список типо объектов, типо существующей сцены, на самом деле сцены нет, но есть заголовки файлов с инструкциями на моём "языке" сценической разметки. Так вот задача моего движка, разобраться что там к чему ещё на стадии интерпретации кода. Пока я по сути не программировал более высокоуровневую логику типо "этот объект повреждён, заменим его другой четкой с вмятиной и пр.. " , пока я колупвюсь в более низкоуровневых дебрях, отвечающих за синтаксический анализ заголовков файлов. Также попутно учу свой двиг разбирать и делить длинные заголовки на скобки и так называемые токины(логически законченные единицы языка). Ведь бывают и такие файлики -
Tree(Tgrass.jpg, FS, O15, L3000-). Что должно заставить двиг обрабатывать сетку tree с изображением дерева, как некий стационарный НЕ динамический объект, способный гореть, и видимый до 3км но далее исчезающий.
всего в моей системе 17 упр символов
При том при сем, шо я довольно большое ударение ставлю именно на логической составляющей движка, мне совершенно похеру на рендер. У меня его своего вообще не будет. Это возгружу на уже имеющиеся достижения гениев графики, будь то directX, opengl, irrlicht, glscene и пр. Их всеравно не перещеголять в скорости рисования треугольников.
Да.
Как вообще в мире gamedev с современными подходами к разработке?
Как там с архитектурой?
Про двенадцатифакторные приложения слышали?
Бизнес-логику от системной логики и данных отделяют?
Гит используют?
Мимо-энтерпрайз
А почему конфигурации, зависимости, контроль версий, stateless бизнес-логика, паралеллизм и прочее не относятся к десктопу? Да, они выглядят несколько по-другому, но вообще это всё про хорошую архитектуру и разделение ответственности, беспременительно к вебу (пункт про порты - исключение, его можно было бы переформулировать в "интерфейсы ввода-вывода" к примеру).
> Мимо-энтерпрайз-головного-мозга
Тудали ты лезешь?
В геймдеве ничего общего с тырпрайзом нет и быть не может. Вернее, если туда попадает тухлая струя тырпрайза - всё - земля пухом.
После таких ответов я начинаю понимать, почему всё, вышедшее из gd обладает уровнем качества на уровне https://store.steampowered.com/app/713940/Blaster_Cop/
А ты няшный?
Неправильно начинаешь понимать.
Встал вопрос - как синхронизировать физику?
Я попытался поднять два физических движка: один на стороне клиента, и ещё один - на стороне сервера. Раз в 100мс я отправляю клиенту координаты и линейную/угловую скорости всех физических объектов. По идее всё должно быть чётко, если стейты одинаковые - но нихуя! Физика в браузере как будто считается быстрее, чем физика на сервере, и поэтому физические объекты, например ящики, в браузере падают быстрее, и каждые 100мс дёргаются, возвращаясь к положению, которое у них в данный момент выставлено на сервере. Гравитация одинаковая, maxSubSteps одинаковый, таймстеп фиксированный и тоже одинаковый. Как фиксить?
Если это важно - на клиентах я использую Oimo.js, а на сервере - Bullet 3. Буллет, конечно, есть и для браузера - но он осне медленный в сравнении с Oimo.
Выручайте.
Но ведь настройки у них одинаковые, хули они по-разному себя ведут?
Ладно, убедил
Допустим, я интегрирую Oimo.js в C++(потому что не хочу юзать буллет в браузере) - насколько быстро эта хуйня будет работать через V8?
>Я попытался поднять два физических движка
> Гравитация одинаковая, maxSubSteps одинаковый, таймстеп фиксированный и тоже одинаковый.
>>456349
>интегрирую Oimo.js
У них рандом участвует в прочетах, даже одинаковые движки дадут разные результаты при одних входяших.
В твоем варианте клиент должен только рендерить, все считает только сервер.
или 1 из клиентов наделен физой пацаны я создал , а сервер остальным транслирует месажи от него, типо если сервер у нас и так загружен хуйней ( жопашный вариант для браузерных клиентов, ибо читКады тебе обеспечаны, а к чужому коду ты ватчеров не напишешь нерационально нормальных ).
>Для нетворкинга использую вебсокеты.
которые работают черезжопу tcp, для реалтайм с большим колличеством объектов ты просто невытянешь по пропускной на клиенте ( будет все лагать пиздец ) даже через локал, там upd как воздух нужен, чего на сколько я знаю, на браузере не организуешь, пока что.
>попытался поднять два физических движка
ты типа пытался этим компенсировать пробелы между пакетами?
Лучше закладывай на отрисовку на клиенте большее время, чем условное ожидание между пакетами.
700x392, 0:20
Опенсорц движок.
говно без задач
Так понял там формат dds с измененным заголовком файла. Почти все текстуры удалось корректно прочитать, кроме некоторых, у которых странный dds формат. Вроде формат похож на DXT5, но текстура почему-то пикселизированная с вырвиглазными цветами получается. Нихрена не понятно.
Короче нифига не могу победить этот странный формат. Это какой-то dds, но хрен знает какой. Вроде как первые 32 байта нужно заменить на нормальный заголовок dds-файла и тогда будет работать. Только какой это из форматов dds - нифига не понятно. Разрешение по заголовку вроде 1024x256, но размер файла соответствует DXT5 512x256 c мипмапами.
https://anonfiles.com/7eF4W359nd
Да там есть и карты нормалей и обычные картинки странного формата.
Картинка по ссылке скорее всего пожата DXT1 и имеет разрешение 1024x256, но все равно выдает не правильное изображение.
Почему в РФ нет ААА-геймдева?
Уровня Ассасиснс к Крид, МГС, Файнал Фентези, Кал оф Дьюти, Овервачт, Фортнайт, ГТА?
В каких странах, кроме США, есть ААА-геймдев? Япония?
>делала новый Квейк
тупа бесплатный рескин мультиплеера дума 2016
они вроде же даже музон не сами писали
обычный бодишоп
Как лучше всего вкатываться в домашний геймдев для души? Недавно я поставил Годо, обмазался туторами, решил приступить к своей оригинальной и неповторимой "есть игра суть такова" и тут же въебенился со всего размаху в кирпич под названием "Как я, блять, буду рисовать своими лапками?" То есть у меня есть в голове идея персонажа, его альфа-позы, замахи мечом и охуительные движения тазовыми костями, но как это все перенести в визуальный образ на экране? Кроме паплки-палки-огуречика у меня ничего не выходит, а еще и саму механику игры пилить.
Имеет ли смысл для набрать каких-то стоковых спрайтов и использовать их, имея возможность их в любую минуту поменять какртинки на что-то свое, не ломая при этом игру?
Пиздец, написал хуйню с ошибками, как последний ретард, простите меня.
640x360, 0:35
Просто не придирайся к себе.
Начнешь качать скилл арта - у тебя и всё остальное лучше станет.
Еще немного поломал голову и понял что картинка в DXT1 но зашифрованная, причем шифр скорее всего некая перестановка битов в байте или максимум в двух байтах. Попробовал реверс порядка битов и циклические сдвиги - не подошли. Посмотрел сколько всего вариантов перестановок для 8 битов - 8! факториал блиать! Офигеть. Вроде простой шифр, а столько много брутить. Ну нафиг.
> Как лучше всего вкатываться в домашний геймдев для души?
А что ты хочешь для души в геймдеве получить?
Я сделал пару игр и понял для себя, что мне нравится процесс разработки, а не придумывание персонажей, внешнего их вида, механик, правил и тд (ну может немного совсем).
Правда, я не пользовался никакими движками и пришлось писать самому некоторые вещи.
С одной стороны нужно сформулировать для себя задачу (например, как организовать гуи и работу с ним), искать материал по теме, примеры и тд, а с другой делать некие заметки для себя наперёд. Скажем, в каком-то проекте мне некоторый функционал не нужен и поэтому я не буду тратить на него время, но в будущем оно мне может пригодится.
Постепенно пробуя какие-то варианты\подходы вырабатываю для себя некие идеи\подходы реализации подсистемы (например) и в будущем постараюсь это как-то развить и улучшить.
Вот такое мне очень нравится, но тут встаёт вопрос: а нахера так делать?
Тупо писать "в стол" ради удовольствия? Бесполезная трата времени, я считаю.
Поэтому для души оно только совсем немного. Проекты нужно заканчивать.
Геймдевом неприятно заниматься. На 5% творчества 95% рутиного въеба. Еще если делать все одному, то довольно трудно определисться с концепией игоря и фичами - такая вечная неопределнность когда никто со стороны не выкатит внятное ТЗ, а у тебя самого настолько замылися глаз об "творчество", что ты не можешь его адекватно оценить и ограничить. Если начинаешь - запасайся колесами или железной волей.
Как мне кажется для тврчества сейчас куда лучше подходит возня с нейросетками.
Тут надо несколько условий выдержать, имхо. Во-первых, иметь достаточное кол-во скиллов, чтобы без сильной головной боли решать проблемы. Во-вторых, иметь определенное вдохновение. Иногда заебывает делать рутину и хочется какую-то свою няку чисто для себя запилить, вылить свою душу, кайфануть от результата. Вот тогда в удовольствие получается.
>На 5% творчества 95% рутиного въеба
Да это к любому хобби относится, лол, будь то рисование, лепка из глины, игра на гитаре или даже создание мемасных роликов.
Суть в том, чтобы получать кайф от такой рутины.
1280x720, 5:55
>Иногда заебывает делать рутину и хочется какую-то свою няку чисто для себя запилить, вылить свою душу, кайфануть от результата. Вот тогда в удовольствие получается.
+1
1280x720, 3:05
>Поясните за ecs
Разве это не очередной протухший buzzword?
Типа так же как никто не орёт "мы сделали это с помощью ООП" в наши года, а орут типа "С ПОМОЩЬЮ НЕЙРОСЕТИ".
Ну один хрен мне нужна архитектура. Я упарился при каждом добавлении всяких новых штук переделывать половину кода. Выкручиваются же как-то люди. Вот все говорят, что ecs всех спасет, поэтому и хочу попробовать написать что-нибудь не нем.
Озадачился тут одним вопросом. Как реализован логгинг в современных играх?
Например в дотке есть возможность сохранить игру целиком и затем проматывать реплей с любого места. Есть возможность вообще загрузиться с определенного момента и продолжить игру вживую. Подозреваю, что таймволк войда, таймлапс вивера и глимпс дизраптора тоже обращаются к этому логу. При этом записывается ебаная тонна инфы вплоть до момента падения отдельного дерева. Интересен еще момент, что при перемотке также перематываются и визуальные эффекты, что для меня несколько неожиданно.
Я знаю один паттерн процессов, реализующих что-то подобное, но главная проблема в нем - отсутствие рандомного доступа. Нужно загружать всю цепочку процессов с самого начала и честно выполнять все до нужного места.
Что можно почитать о приемах и паттернах подобного лога событий в современных играх?
Про дотку можешь посмотреть парсер от Вальве, он оперсорс.
Здрасте, игры мирового уровня и проприетарный софт на нём поголовно написаны. Как раз 99% того что делается в айти это какой-то мусор только засоряющий всё вокруг, а не реально серьёзные проекты топовые в своём сегменте по миру.
Капиталы должны перераспределяться, щито поделать.
А в чём проблема? У них вполне информативная и понятная документация. Там простые функции, принимающие аргументы и содержащие константы, которые надо вызвать, передав, к примеру, ID определённого ивента. Окей, есть и лямбы, но разве это проблема? В крайнем случае можно погуглить.
С c# и api проблем нет, тут как раз все хорошо, проблема в том, что для нормального сервера в 2к19 весь client придется писать на js/html/css для cef браузера, встроенного в игру, если хочешь больше 1.5 анона на серве.
Например, https://github.com/GTANetworkDev/platform, здесь, вместое NativeUI поставить MyNeBydloUI.
640x360, 0:40
https://2ch.hk/int/res/62303.html (М)
Потому, что кубические координаты удобнее xy со смещением.
>Из-за этого вроде как могут быть ошибки при округлении, ну и в итоге между тайлами на карте будут черные просветы.
А нахуя тебе спрайты с нечетным (или четным - лень думать) числом пикселей?
А вообще, если в твою деревню завезли антиалиасинг (и судя по всему завезли, если ты о трансформациях камеры рассуждаешь в 2д игрушке), то видюха и дробные координаты проглотит.
Либо ты не можешь в скрипты и гибкое применение различных парадигм в разработке, либо обоснуй свою точку зрения.
Сирешётка - это не скрипты и не новая парадигма в разработке, сирешётка - это visual basic для копроративных оперденей. Мне хватает мозгов, чтобы писать на нормальном ЯП, а не на улучшенном вижул бейсике.
питоношизик опять ты?
>Сирешётка - это не скрипты и не новая парадигма в разработке, сирешётка - это visual basic для копроративных оперденей.
Просто сделал мой день. Во-первых, нагугли парадигмы, чтобы твой манямир перевернулся. Во-вторых, эффективность скриптов на шарпе зависит от рук создающего. Он предоставляет все возможности для гибкой разработки под конкретные задачи, поэтому причин для хейта я не вижу. Хочешь работать с функциональщиной? Пожалуйста, если можешь в неё. Если нет, выбирай ООП или ноды, если неосилятор дизайнер. Всё зависит от глубины знаний. Я говорю только о геймдеве, т.к. им ограничивается использование шарпа мной. В основной деятельности использую другие языки.
>Мне хватает мозгов, чтобы писать на нормальном ЯП
>улучшенном вижул бейсике
Тут всё понятно, собственно. Открою тебе секрет: главный навык, без которого ты останешься мелкокодером - умение формировать фрагментированное представление общей картины.
Это для всех ребят, которые начинают сомневаться, видя подобных дурачков. Не слушайте их.
Найс сирешётка-школьник порвался.
> Открою тебе секрет: главный навык, без которого ты останешься мелкокодером - умение формировать фрагментированное представление общей картины.
Мой маленький друг, открою тебе секрет и я: главный навык, из-за которого ты остаёшься фантастически толстым троллем - привычка скрывать отсутствие мозгов словами, вычитанными в словаре.
Можешь считать, что порвался, но важно то, что твой пустосблёвный высер может реально сбить с толку человека, который только знакомится с инструментами разработки.
>Мой маленький друг, открою тебе секрет и я: главный навык, из-за которого ты остаёшься фантастически толстым троллем - привычка скрывать отсутствие мозгов словами, вычитанными в словаре.
И вновь отсутствует конкретика. Суть же моего тезиса заключается в том, что качество решения задачи напрямую зависит от реализации. Твоих интеллектуальных ресурсов не хватает, чтобы понять это? Мб вылетает эксепшн, когда нечего ответить по факту, хз.
Если ты мима шел, зачем взялся осуждать, не выяснив, кто здесь хороший герой, а кто плохой?
Кстати, этот вопрос еще предстоит решить зрителям срача.
Насколько сложно создать 2d игру самому, например файтинг? Что для этого нужно сделать - какие функции будут возлагаться на мои плечи? Какую программу скачать? Какой язык изучать и литературу? Рисование персонажей и локаций - насколько сложно? Есть время и желание. Вдохновлялся игрой Terrordrome The Game - Rise of the Boogeymen и Terrordrome: Reign of the Legends. Прошу без мата пожалуйста.
Unity, C#. Учатся легко, туториалов полно. Времени надо - чем больше, тем лучше на проработку мелочей. А прототипы 2d игр уже практически с самой Unity идут, только переделать под себя остается.
Во-первых, сложность относительна и зависит от наличия и уровня знаний, либо обучаемости. Во-вторых, если ты хочешь сделать игру самостоятельно, на твои плечи лягут все возможные функции. Вот тебе roadmap:
1) Составь список желаемого функционала.
2) Почитай о различных движках.
3) Посмотри примеры реализации необходимого тебе функционала на разных движках.
4) Нагугли движки игр, на которые хотел бы равняться(кроме высокобюджетных игр - к их рассмотрению стоит вернуться после половины пройденных этапов)
5) По сути, если речь идёт о десктопе, выбирать придется между Unreal Engine 4 и Unity. Ищи инфу, пробуй, выбирай.
6) Не бойся экспериментировать, даже если делаешь примитивнейшие вещи по гайдам, дабы выяснить то, с каким движком тебе комфортнее работать. Это важно.
7) Получив базовое представление о работе с движком, больше практикуйся, обращаясь к документации. Учись читать её, это архиважно.
8) В самом начале ты можешь использовать готовые объекты/текстуры/материалы и пр., но я советую научиться работать с примитивами, пробуй делать самостоятельно как можно больше.
9) Советую прочитать хотя бы одну книгу по выбранному движку, этого будет вполне достаточно. Хорошо ставит мозги на нужное место.
10) Изучай инфу о дополнительных инструментах, которые могут пригодиться в разработке. Научиться можно всему.
11) Ты имеешь достаточное количество знаний для того, чтобы уверенно продолжать развиваться.
Начинай с простого и всё получится.
Информацию принял, буду изучать.
В идеале да. Для анимации придется много рисовать. Поэтому проще сделать пиксельную игру.
Либо можно совместить 2d с 3d. Анимировать 3d персонажей от 2d вида.
Все ясно.
Что нужно для того, чтобы стать гейм дизайнером? В каком возрасте не поздно вкатываться? Какое нужно образование? И как вы считаете, аноны, есть ли будущее у игровой индустрии?
Ты правда хочешь заниматься хуйней уровня "сколько должен стоить бустер на бомбочке в очередной говноигре 3-в-ряд для андроида"?
в РФии другого геймдева нет.
>>519051
Не согласен с вами, господа. Прелесть геймдева в том, что он в меньшей степени зависит от того, в какой стране ты родился. Здесь нет такой сильной локальной привязки, как в энтерпрайзе, например, который сильно подвержен влиянию локальных тенденций и сопутствующей специфики. К тому же, хоть это, без сомнения, перспективная ниша, профессионалов критически не хватает.
Одно дело работать в аутсорс-конторе и пилить код или контент в том числе и для игр. Такого полно. А другое - гейм-дизайн. Это примерно как "что нужно делать, чтобы стать CTO стартапа".
Если не брать случайности, то нужно идти работать в большую контору, учиться там, потом отпочковываться и делать свое. В России это не вариант вообще. Так что либо повезет, либо нет.
Берешь Годот и делаешь.
> По сути, если речь идёт о десктопе, выбирать придется между Unreal Engine 4 и Unity.
Святая толстота.
Отчасти согласен, так как сама постановка вопроса отсылает к работе над созданием собственного продукта. Тогда и речь должна идти о том, как "вкатиться" в сей бизнес в целом. Гейм-дизайн слишком специфичен для примитивного обсуждения на уровне инструкций. Тем не менее, можно продать себя проекту, который нуждается в профессиональном геймдизайнере со множеством регалий, например, ведь такое тоже бывает. Вопрос лишь в уровне профессионализма. Короче говоря, это не то, ради чего стоит целенаправленно развиваться. Не самоцель, но вектор развития.
Гейм дизайн это как раз просто логика и баланс компонентов, о чему можно научиться хоть дома за компом. Уйма модов отбалансеных в разы лучше оригинальных ааа и просто инди проекты которые на клык по геймдизайну любой коммерческой высокобюджетной параше дадут как бы намекают.
Стань гей-шлюхой
> ATS (Applied Type System) — язык программирования, чьим основным предназначением являлось обеспечение поддержки доказательства теорем
Тред борщехлёбов с пруверами двумя тредами ниже.
ATS это игра, American Truck Simulator
не знаю, вообще не разбираюсь в этом. игра принимает в качестве мода один запакованный файл в формате .scs внутри него лежат и звуки и 3d модель и всё прочее. где модель находится не знаю, при всём желании не смогу тебе сказать к сожалению. могу разве что скинуть его тебе. он распаковывается обычным winrar за 45 секунд. разумеется если ты будешь готов пофиксить этот мод, я тебе заплачу деньги сколько мы договоримся.
Не. Безрезультатно.
Там грузовик разбит на десятки кусочков по ходу дела. Текстуры в dds хранятся, тут всё понятно. А саму модель не могу пофиксить. Скрипты какие-то ещё лежат. Может углы дверей, подвески или разворота колёс и пр. физика
спасибо большое хотя бы за то что посмотрел, понял.
Помс
Пикрелейтед
Да.
В обычных тайлах/паках.
Есть игры в которых такое создается динамически из отдельных иконок, суть в оптимизации для разные видеокарты, типа одна видюха хорошо держит 4096х4096, а другая 10к на 20к и это позволяет за счет более долгого запуска игры улучшить ее производительность.
А еще есть, правда это не для иконок
https://ru.wikipedia.org/wiki/Мегатекстура
> В обычных тайлах/паках.
Скорее всего так. Строится типа тайлмапы, но для иконок.
https://www.youtube.com/watch?v=_quACGPzHi8
В первый раз обращаюсь за вашей помощью, ибо уже в полном смятение, где можно почерпнуть знаний о этой теме, и по наставлению своего друга решил обратится к вам!
У меня возник вопрос по поводу изменения материалов объекта в Unity.
Задача: Необходимо с помощью скрипта(С#) изменить, допустим, Емиссион(или любой другой параметр материала) Материала_1 (вкл/выкл) по нажатию кнопки_1 (или любому другому событию) Материала_2 по кнопка_2, Матер_3 по кноп_3 и т.д. При этом, что бы материал менялся на конкретном объекте, а не в целом.
Заранее благодарю!
Поссал на юнитидебила.
ибо такая работа
на хлеб будет хоть что намазывать
1. Описание движения корабля по прямой в заданную точку за минимальное время/с минимальными затратами топлива.
2. Выбор оптимальной траектории до точки для обхода препятствий.
3. Описание движения корабля по траектории за минимальное время/с минимальными затратами топлива.
На выходе некоего алгоритма нужно на каждом тике получать значения для силы тяги по каждому направлению.
Посоветуйте, пожалуйста, что почитать по этой теме (можно на английском).
Скажем, когда игрок пересекает координаты какого-нибудь помещения нпц должен что-то ему пропиздеть, потом игроку надо нажать кнопку и решить физический паззл что запустит катсцену и затем нужно сгенерировать и наспавнить десяток врагов различных типов после перемалывания которых откроется следующая локация.
Крестовики-двиглописатели же наверное гнушаются таким и вообще ебанутая идея писать это на плюсах, какие-нибудь скриптовые языки больше подходят для таких задач. Знаю что в одной конторе для этих целей навелосипедили свой язык.
А как в целом в индустрии? Как вообще называется эта каста разработчиков в ААА и что знаете о такой работе?
Короче, хочу написать свой супер движок на шарпике(да, блядь, на шарпике, потому что ебал я си и СиПлюсПлюс). И вот собственно в чем загвоздка, я хочу чтобы мой движок был модульным, расширяемым, простым в использовании и под разные задачи, при этом быстрым.
До этого уже пилил мелкие игрушки и понял, что именно игрушки мне пилить менее интересно чем продумывать как это со стороны движка работать будет, именно потому и хочу свой движок.
Что есть почитать, по архитектурам и лучшим практикам в этом направлении, без привязки к конкретной задаче с созданием конкретной игрушки?
>да, блядь, на шарпике, потому что ебал я си и СиПлюсПлюс
Почему ты так предвзято к ним относишься? Можешь конечно и на шарпике, но если движком предполагается пользоваться другим людям, то рано или позно придется заниматься бесмысленным бусидо с гарбадж коллектором, если тебе действительно нужен быстрый движок.
Вот пример лайтвейт движка на сишке можешь глянуть сорc
https://github.com/raysan5/raylib
> Почему ты так предвзято к ним относишься?
Всего пара причин.
1. Это то что нужно разбивать объявление и реализацию в 2 разных файла.
2. То что объявление обязательно должно идти по тексту раньше чем использование.
Эти 2 вещи меня просто выводят из душевного равновесия.
ЗЫ: Сама игра - лютый вин, советую.
Я не играл в игру, потому тонкостей механики не знаю и исхожу из следующего представления:
Есть блоки is, есть блоки с правилами(you, push, stop, win и т.д), есть блоки с именами объектов мира к которым применяется правило, есть соответственно, сами блоки мира которым соответствует имя. Когда слева/сверху от блока is находится имя, а с противоположной стороны правило, это правило применяется к объектам с именем.
Вот тебе самое простое решение в лоб:
У тебя словарик в котором ключ - имя объекта, значение - список свойств,
проверяешь при очередном апдейте, появилось ли новое правило относительно какого-то типа объектов, если появилось - ищешь в словарике по ключу объект к которому добавилось правило и добавляешь в список свойство, если правило исчезло, соответственно это правило удаляешь, а затем просчитываешь дальнейшее поведение объектов на карте в соответствии с правилами которые есть в списке, т.е как-то так:
while(GameRuning)
{
ReadPlayreInput();
Update();// тут проверяешь в словарике какие правила применяются к какому объекту и в соответствии с этим апдейтишь каждый тайл
CheckRulesUpdated();//Тут проверяешь изменились ли правила, если изменились - добавляешь в словарик новое правило чтобы при следующей итерации логика апдейта была другой
Render();
}
Про передачу управления игроку, т.к. you - свойство, то ты должен был бы просто при очередном апдейте просто проверить был ли ввод и изменить положение всех объектов мира, которые you в соответствии с инпутом, ну и центрировать камеру на объекте, т.к. если я правильно понял объектов с you может быть много, центрируешь на какой-то средней координате, как найти середину думаю ты сам сможешь нагуглить.
Как-то так.
Но опять же, это мое решение в лоб, а в игру я не играл, потому каких-то особенностей могу не знать. Просто так ты сможешь потестить и разобраться, потом уже придумать как сделать более изящно и элегантно.
>>565182
Я уверен таких как ты с клонами БАБЫ уже сотни.
Тайлики и перемещение – хуйня, весь смак в правилах, их взаимодействии, очерёдности применения и краевых случаях, обработка каких-нибудь SWAP, SHIFT и PULL вместе наверное занимает половину исходников.
Пиши лучше Сокобан и успокойся.
Потом можешь попробовать первую версии игры, которой автор выиграл какой-то там хакатон, там правил меньше.
Да, забыл сказать, игра полна по Тьюрингу: https://twitter.com/mattar0d/status/1109987662608384000
>волею судеб
Чё у тебя, пророчество что-ль как в морровинде согласно которому тебе уготовано заниматься базами данных?
Допустим нужно использовать фрагмент текстуры для прямоугольника, но не просто натянуть текстуру на квад, а сделать так чтобы она заполнила его повторением. Если бы это была обычная текстура, то достаточно было указать текстурные координаты в несколько раз больше обычного.
Но с атласом такое не пройдёт, будут браться соседние текстуры.
Есть ли варианты решения такой задачи?
>как в Pac-Man
Читаешь в вики как работают враги.
Вот красный должен идти к переду пакмана. Как сделать? Каждый раз когда красный подходит к краю хода, например, он смотрит где пакман, смотрит его направление, выбирает точку сразу впереди него как цель, самого его воспринимает как препятствие (чтобы сзади не заходить), далее просчитывает варианты траектории с учётом условий и идёт по кратчайшей. Если что, я не знаю подкапотную реализацию поведения этих ребят, просто объясняю как делал бы я.
>Battle City
Проще. В вики лезть не буду, лично мне по ощущениям показалось что враги там ТУПО РАНДОМНО двигаются и стреляют. Значит что?
while(isAlive) {
move(рандомная сторона)
sleep(рандомное время)
}
Ой прошу прощения, красный идёт к жопе пакмана, а не к ебалу.
1. Формально необязательно, используется для устранения пункта 2
2. Вот чтобы этого не было и выносят объявления в другой файл, просто чтобы глаза не мозолили (на самом деле не только поэтому, но не хочу лезть в дебри)
Это всё глупости ничего не значащие и на работу не влияющие.
А вот, как анон выше сказал, сборщик мусора может уже вполне по-настоящему из равновесия выводить, и хуй что с этим сделаешь что самое главное, я не искушённый гуру решетки и джавы и не припоминаю в них возможности самому работать с памятью где и когда тебе нужно.
Проще разобрать на одномерном случае. Пускай твоя текстура - отрезок 0.5-0.6 (длина 0.1). Тебе нужна функция, которая отображает точку 0.55 в 0.55, 0.64 в 0.54, -0.11 в 0.59 и так далее.
Сначала преобразуем отрезок к координатам 0 - 0.1, вычтя 0.5. Отсюда сразу видно, что тебе нужен остаток от деления от 0.1 - он отобразит все точки как надо. Осталось лишь вернуться к исходной системе координат (обратно прибавить 0.5). Таким образом, xWrapped = 0.5 + mod(x - 0.5, 0.1).
Вообще афинные и линейные преобразования - очень полезная вещь даже вне компьютерной графики.
Мимопроходил негеймдев но когда-то давно пинал OpenGL-кун
Создать менеджер Shooteroв, который хранит их в формате Dict<IShooterOwner, list<Shooters>>, далее при каждом добавлении нового IShooterOwner, создавать подписку на его событие OnLiveObjectClear(), брать из словаря его list<>shooters и очищать мб?
Могу пояснить, если всё ещё нужно.
Это копия, сохраненная 22 февраля 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.