Вы видите копию треда, сохраненную 14 июня 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Предыдущий тред http://arhivach.net/thread/347971/
без хейта
Почему в бриташке школьники могли выпустить на коленке годные игры, а в совке не могли?
Могли. Самая популярная игра в истории была создана в Чичичипи.
Кто вообще в совке мог что-то выпустить? Много советских геймдев-студий знаешь?
Кто угодно, детские игрушки и всякие игровые автоматы делали же, почему бы игр не ебануть для автоматов опять же?
Да и речь про времена, когда это ещё не было развитой индустрией.
Го не будем устраивать этот днище срачь?
В 80-е большинство игр были отупляющими (как и сейчас, лул). Тот же "Братья Марио" - это тупая убивалка времени, бестолковое задрачивание бестолковых действий. В СССР же думали о будущем и думали о развитии подрастающего поколения. Дикий форс кубика рубика, всякие шахматные секции, центры научно-технического творчества молодёжи, разные радиокружки, кружки авиамоделирования, юный техник. Вот это вот все. Какие нахуй марио? Ты что пиздонулся? Никому они нахуй не нужны были в СССР.
Ну и в СССР таки делали игры, да. Был завод ПО "Электронмаш", который вполне выпускал игры для БП ЭВМ "Поиск". Шахматы, Реверси, Калах, вот тот же Тетрис в разных вариантах. Опять же, преимущественно развивающие игры, а не дегродные.
Жаль нет компа давно, скинул бы скриншотов.
Чел, вот ты противопоставляешь игры технике, а на самом деле наоборот. Эти самые "техники" занимались всем чем ты говоришь, а когда появились компы, занялись программированием и играми. А вот тупое быдло не интересовалось и компьютерами и играми, они приперлись только позже, когда рекламщики вырастили "тренд", вот тогда быдло и приперлось в игры. А настоящие игроки это именно самые умные из людей, те самые "юные техники". И програмимирование игр самое вменяемое программирование, а отличие от параши вроде чатиков и вкудахтиков и прочих магазинов дерьма и документооборота.
Картинку не могу сбросить(, редактор юнити
>Почему в бриташке школьники могли выпустить на коленке годные игры, а в совке не могли?
Потому что полноценно компы в совке появились только к концу перстройки и развалу совка.
И ты видимо проебал спектрум-сцену начала девяностых когда писали кучу этого твоего хуинди и модов к уже имеющимся играм и продавали его на рынках на аудиокассетах.
Имеется в виду, естественно, личный компутаптор который ты хоть как то мог достать и поставить у себя дома что бы кодить игорь.
А не пользоваться по часу в день в шкилке или шараге.
Так то ДВК и производных еще с начала 80х было хоть жопой жуй.
>В 80-е большинство игр были отупляющими (как и сейчас, лул). Тот же "Братья Марио" - это тупая убивалка времени, бестолковое задрачивание бестолковых действий. В СССР же думали о будущем и думали о развитии подрастающего поколения. Дикий форс кубика рубика, всякие шахматные секции, центры научно-технического творчества молодёжи, разные радиокружки, кружки авиамоделирования, юный техник. Вот это вот все. Какие нахуй марио? Ты что пиздонулся? Никому они нахуй не нужны были в СССР.
Представляешь себе, в США все было то же самое, только вдобавок никто не заставлял с серьезным ебалом серьезно тащить комуняцкую лямку серьезного ебала.
И по факту всю историю этим самым серьезным ебалом по факту нюхали пердежные газы убегающего все дальше и дальше по прогрессу США, который на изичах переиграл и уничтожил, нагнул совок торговыми санкциями и Афганом.
По сути поставив раком совок в необходимость тащить ту самую пресловутую газовую иглу-трубу прямо к основному форпосту НАТО где стояли першинги. И дальше вопрос капитуляции уже был вопросом времени.
> И ты видимо проебал спектрум-сцену начала девяностых когда писали кучу этого твоего хуинди и модов к уже имеющимся играм и продавали его на рынках на аудиокассетах.
Это была уже ответка на те самые британские игры, десять лет спустя.
>разные радиокружки, кружки авиамоделирования, юный техник.
Доступность всяких деталей и инструментов для хобби в США была на порядки выше.
>Какие нахуй марио?
Ну вот дети играли в марио, потом садились за компьютер и учились делать свои игры. В результате США - мировой центр айти.
>спектрум-сцену начала девяностых когда писали кучу этого твоего хуинди и модов к уже имеющимся играм и продавали его на рынках на аудиокассетах.
А одновременно с этим Кармак и компания делали Дум на некстстепах.
Зато лямку нацианальных интересов заставляли тащить и ничё.
Ток чому-то сама марио японщина
Хочу написать простую 2д игру с видом сверху без использования движка, на голом SDL. Подскажите, пожалуйста, что почитать типичной вебмакаке чтобы такое осилить? Про паттерны, камеры и всё такое.
Тогда и весь раздел (за исключением 1с) не имеет смысла, т.к. большая часть проектов забугорные
>[Бред сумасшедшего]
На самом деле, вакансий например JS огромное кол-во. Поэтому JS имеет смысл, а вот Гей дев нет.
>всякие шахматные секции, центры научно-технического творчества молодёжи, разные радиокружки, кружки авиамоделирования
Это все лютый треш, никогда не встречал ребенка, который серьезно бы такими вещами интересовался и ходил бы туда без понукания родителей. А вот как раз какая-то часть интересующихся компуктерными игрульками имеют мотивацию к занятиям по программированию.
640x360, 2:24
>А вот как раз какая-то часть интересующихся компуктерными игрульками имеют мотивацию к занятиям по программированию.
Ебать не должно.
>Поэтому JS имеет для меня смысл, ведь у меня нет денег. Мне нужны деньги, без денег нельзя даже пукнуть. Давайте обсудим деньги, в треде не про деньги, а то у меня детство было голодное и всегда было мало денег, поэтому сейчас я гиперкомпенсирую детство.
Таких в нашем клубе было может пару человек. Остальные по фану всякие жучки, мигалки, пищалки делали. Взрывали конденсаторы, делали дымовухи.
Это может быть очень интересно. Просто ты потреблядь с детства, как тебе понять что такое интерес. Интерес бывает только у креативщиков.
Какой же манямирок у этого теоретика. Вот правду говорят - преподают кодинг только те, кто не осилил продуктовую разработку.
Не осиливают продуктовую разработку только те, кто предподает кодинг?
341x256, 8:45
>Вот правду говорят - преподают кодинг только те, кто не осилил продуктовую разработку.
"Кто умеет - делает, кто не умеет - учит". Джордж Бернард Шоу
https://www.youtube.com/watch?v=UHG0rUFZW9Q
Чушь, смысл создание игр - это их дальнейшая продажа в стим (Если ты Бог с кучей бабла, то и на консолях, но будем реалистами). Ты можешь сделать игру на JS и продавать её в стим? Нет.
>>199076
Мы живём в капитализме, смысл что-либо делать в кап. обществе - получение денег. Сможет ли гей дев принести тебе деньги, если ты живёшь в РФ? Нет. Конец дискуссии.
Ну да, это же в РФских универах платят по 300к в наносекунду, а кодеры, работающие на забугорье живут от зарплаты до зарплаты и охуевают от подорожания моркови.
Поясните пожалуйста про C++. C#, Python, Java, Kotlin, Go - имеют ли эти языки свои ниши в геймдеве и какой предпочтительнее и перспективнее?
Чтобы получить больше $$$$$ нужно нажать ctrl+4.
Не благодари.
А если серьезно, смысл капитализма в накоплении капитала. Никто не заставляет тебя ебашить если капитал не нужен.
>Ты можешь сделать игру на JS и продавать её в стим?
На электроне сделать десктопное приложение и в стим.
map
dmp
snf
Спасибо!
Или всё мрак и тлен и удел байтоёба - банковские бэкэнды?
Нельзя. Графон уже неоднократно напилен в множестве движков, которые сейчас не такие уж и дорогие, бери и используй. То есть ты просто хочешь заново поизобретать колесо, при этом чтобы тебе ещё и платили как будто ты первооткрыватель мира.
C++ — почти весь серьёзный геймдев.
C# — почти весь низкобюджетный геймдев на юнити.
Python — есть неказистый pygame уровня старых туториалов по опенгл и больше нихуя. Но ещё конечно можно в блендере аддоны делать.
Java — майнкрафт на нём. Но я бы не сказал что на жаве массово делают игры.
Kotlin — только для андроид приложений.
Go — язык для серверов, на нём нет никакой графики, интерфейсов, а если и есть, то нахер никому не упали. Этот язык гугл создал для своих внутренних нужд. Эдакий C++ для тупых.
На JS можно клепать игры для соцсетей. Фермы там всякие, купи кристаллы чтобы стало красиво.
> на нём нет никакой графики, интерфейсов
Есть, даже есть игра в стиме на го написанная, https://daigostudio.com/bearsrestaurant/en/. Но да, все эти либы больше для фана, чем для полноценной разработки игорей.
> Эдакий C++ для тупых.
Язык вообще не похож на плюсы. Да и сам ты тупой
Это пусть программист решает. Главное чтобы игра была интересная. Просто игорь тонет.
А в чем твоя роль в таком проекте?
Планирую ближе к февралю начать пилить 2d мультиплеер ARPG диаблоклон
Сама концепция очень простая - ходишь по помещениям, начиная с гардероба и заканчивая туалетами, находишь предметы, какие-то просто лежат, какие-то можно получить, совершив какое-то действие, например, выбрав правильный вариант ответа мобу.
Самое интересное, это то, что я имею: минимум знаний в программировании, опыта в разработке игр тоже нет, графику буду делать самостоятельно, есть люди, которые могут немного помочь с кодом, но в основном вся работа на мне. Времени осталось полгода, в день могу уделять этому от часа до семи, в среднем 3-4.
Главные вопросы: 1.На каком движке лучше работать. 2. Можно ли сделать игру в изометрии, а если нет, то в каком виде будет проще воспроизвести конкретные локации, чтобы было понятно что это за помещения. 3.Есть ли какие-то бесплатные гайды по этой теме. 4.Где будет удобнее и проще всего работать с картами, кодом и прочим 5. js, python, c#, c++???
И главное: реальные ли я вообще ставлю цели? Можно ли вообще что-то такое сделать без знаний и опыта на начальном этапе? На данный момент очень горю этой идеей, сайт-магазин делать не хочется :0
ты просто заебешься рисовать. все кодерки фантазируют что затык только в коде а он не только в коде.
>сайт-магазин делать не хочется :0
а зря. за историю так никто нихуя и не родил ничего путёвого. вот ты думаешь магазин это каталожек, карточка товара? да нихуя блядь. сделать быстро, сделать интерактивно, сделать варианты, категории, фильтры человеческие, сделать чтобы редактикарование и актуализация были быстрыми и удобными - это все хуй. не говоря уже о том чтобы взять технологии которые не устареют, обмазать все типчиками.
просто это область макак и для макак. нормальную работу там не оценят.
Дело в том что рисую я лучше чем пишу код, так что основная проблема именно в этом
>В принципе поинт и клик механику можно и в Ренпи сделать.
Разве пустой проект ренпая не больше пустого проекта юнити весит?
www.youtube.com/watch?v=dNLOavhtV-s
> все кодерки фантазируют что затык только в коде а он не только в коде
Это мягко говоря не так. Затык в геймдизайне, и кодерки в большинстве своём не настолько тупы чтобы этого не понимать.
> 1.На каком движке лучше работать.
Unity неплох для одиночной разработки. Много всяких прикольных штук упрощающих разработку. Много всяких пресетов, в том числе для изометрической игры. Есть бесплатные наборы графики.
> 2. Можно ли сделать игру в изометрии, а если нет, то в каком виде будет проще воспроизвести конкретные локации, чтобы было понятно что это за помещения.
От чего нельзя то? Сделать можно все. Главное что бы был подходящий набор графики.
> 3.Есть ли какие-то бесплатные гайды по этой теме.
Для Unity целый вагон гайдов. Большинство из них бездарная копипаста с западных каналов. Если умеешь в английский. то смотри/читай официальные гайды.
> 4.Где будет удобнее и проще всего работать с картами, кодом и прочим
Прямо в Unity Он попытается заменить тебе и фотошоп и блендер, на сколько сможет. Но само собой уступает всем этим узкоспециализированным программам. Но для вкатывания функций хватит.
> 5. js, python, c#, c++???
Если выбиерешь Unity, то C# там особой и выбирать то не надо. На js писать охуеешь. Сперва нужно знать весь js на уровне эксперта. Иначе полгода будешь только код отлаживать. Питон это тебе в Godot. Движок неплохой, но как по мне не дотягивает до Unity пока. С++ без 5 лет стажа даже не суйся.
> реальные ли я вообще ставлю цели? Можно ли вообще что-то такое сделать без знаний и опыта на начальном этапе?
Внезапно можно. Современные игровые движки очень юзерфрендли. Надо быть полным дебилом что бы не написать там простую игру с примитивной механикой. Тем более есть шанс, что тебе зайдет.
Сап Двач. Я кароче загорелся идеей сделать NFT игру на unity. Все сам делать в принципе умею, но пара лишних рук без пользы не пропадет. Кто заинтерисован - делим все пополам. Контакты: AndrewGalak6578#0916
Три в ряд на мобилки делают на Дефолде и прочих lua-движках. Чем JS хуже lua? По тестам даже быстрее.
да, тетрис конечно невероятно развивает, ведь там абстрактные кубы падают на абстрактные кубы. то ли дело в марио, хуета для дегродов - скорость и высота прыжка, ловкость рук, запоминание красочных локаций, поиск нужного подхода к мобам/боссам...
В СССР была аналоговая техника а в Британии цифра. Для унификации игр лучше всего подходит именно цифра.
Пилю двумерный игорь с процедурной генерацией мира (да, как майнкампф).
По задаче - нужно, чтобы мир состоял строго из комнат заранее заданной формы. Условный желаемый результат обрисован на пике 1. Комнаты обладают заданными свойствами и в реальной игре будут очень сильно разные, суть вопроса не в этом, но отсюда следует, что генерить комнаты алгоритмами лабиринтов нельзя. Соседство одинаковых комнат и наличие "незалитых" клеток допускается. Раскладываем не рандомно, а по зерну мира, чтобы мир можно было воспроизвести.
Проблема, которая стоит передо мной - все процедурные генераторы, что я видел, генерируют какой-нибудь шум перлина, и потом оперируют каждой ячейкой на поле (в майнкрафте - блок). В моем случае ячейка является не самостоятельной, так как обязательно принадлежит какой-то комнате. Поднять дискретизацию, чтобы одня ячейка = одна комната нельзя, т.к. комнаты, не квадратные и сильно разных размеров.
Какие есть мысли по этому поводу:
Генерировать комнату согласно функции шума на клетку, начиная с какого-либо угла (например, левого верхнего) а далее при генерации пропускать занятые этой комнатой клетки. Т.о. следующая комната заспавнится на свободной клетке с поправкой на то, что вокруг нее занято (пик 2). Возникающая проблема - это хорошо работает, когда игрок будет двигаться "по шерсти" генерации, но совершенно не работает, если он пойдет в обратную сторону - мы не знаем заранее, какой именно комнатой занята клетка правее существующих комнат (на пик 2 справа), и какого-то адекватного способа это узнать мне в голову не приходит. Получается, чтобы это узнать, надо пройтись алгоритмом по клеткам еще правее и еще выше, а для тех клеток у нас точно такая же ситуация неведения.
Довольно простой костыль - генерировать комнаты пачками в квадратных чанках (пик 3). Внутри чанка генерация все также идет в одном направлении, обеспечивая процедурное размещение комнат, а снаружи чанки квадратные и одноразмерные, что позволяет генератору свободно "шагать" чанками в любую сторону. Решение неплохое, но мне тут не нравится то, что границы чанков будут заметны игроку - это всегда будет стена, и никогда - комната, размещенная в двух чанках сразу. Увеличением размера чанка проблема только усугубляется, будет длиннющая стена из нескольких комнат вдоль границы чанка. Можно было бы конечно разрешить генератору размещать комнаты с "выездом" на соседний чанк (пик 3 справа), но тогда мы возвращаемся к предыдущей проблеме неопределенности, только уже на уровне чанков - мы не можем уверенно поставить комнату, так как не знаем, не занята ли ее клетка "хвостом" из соседнего чанка. А чтобы сгенерировать соседний чанк и проверить, надо сгенерировать соседние с ним, и т.д.
Не удивлюсь, если подобное решение уже давно изобретено, просто я куда-то не туда смотрю. Как вообще называется эта техника раскладывания битого кафеля, чтобы гуглить? Заранее благодарен.
Пилю двумерный игорь с процедурной генерацией мира (да, как майнкампф).
По задаче - нужно, чтобы мир состоял строго из комнат заранее заданной формы. Условный желаемый результат обрисован на пике 1. Комнаты обладают заданными свойствами и в реальной игре будут очень сильно разные, суть вопроса не в этом, но отсюда следует, что генерить комнаты алгоритмами лабиринтов нельзя. Соседство одинаковых комнат и наличие "незалитых" клеток допускается. Раскладываем не рандомно, а по зерну мира, чтобы мир можно было воспроизвести.
Проблема, которая стоит передо мной - все процедурные генераторы, что я видел, генерируют какой-нибудь шум перлина, и потом оперируют каждой ячейкой на поле (в майнкрафте - блок). В моем случае ячейка является не самостоятельной, так как обязательно принадлежит какой-то комнате. Поднять дискретизацию, чтобы одня ячейка = одна комната нельзя, т.к. комнаты, не квадратные и сильно разных размеров.
Какие есть мысли по этому поводу:
Генерировать комнату согласно функции шума на клетку, начиная с какого-либо угла (например, левого верхнего) а далее при генерации пропускать занятые этой комнатой клетки. Т.о. следующая комната заспавнится на свободной клетке с поправкой на то, что вокруг нее занято (пик 2). Возникающая проблема - это хорошо работает, когда игрок будет двигаться "по шерсти" генерации, но совершенно не работает, если он пойдет в обратную сторону - мы не знаем заранее, какой именно комнатой занята клетка правее существующих комнат (на пик 2 справа), и какого-то адекватного способа это узнать мне в голову не приходит. Получается, чтобы это узнать, надо пройтись алгоритмом по клеткам еще правее и еще выше, а для тех клеток у нас точно такая же ситуация неведения.
Довольно простой костыль - генерировать комнаты пачками в квадратных чанках (пик 3). Внутри чанка генерация все также идет в одном направлении, обеспечивая процедурное размещение комнат, а снаружи чанки квадратные и одноразмерные, что позволяет генератору свободно "шагать" чанками в любую сторону. Решение неплохое, но мне тут не нравится то, что границы чанков будут заметны игроку - это всегда будет стена, и никогда - комната, размещенная в двух чанках сразу. Увеличением размера чанка проблема только усугубляется, будет длиннющая стена из нескольких комнат вдоль границы чанка. Можно было бы конечно разрешить генератору размещать комнаты с "выездом" на соседний чанк (пик 3 справа), но тогда мы возвращаемся к предыдущей проблеме неопределенности, только уже на уровне чанков - мы не можем уверенно поставить комнату, так как не знаем, не занята ли ее клетка "хвостом" из соседнего чанка. А чтобы сгенерировать соседний чанк и проверить, надо сгенерировать соседние с ним, и т.д.
Не удивлюсь, если подобное решение уже давно изобретено, просто я куда-то не туда смотрю. Как вообще называется эта техника раскладывания битого кафеля, чтобы гуглить? Заранее благодарен.
Тупил в фоне над этой задачей пару дней, но стоило написать сюда, как пришла мысль класть чанки не совсем уж квадратно-гнездово, а со смещением по строкам, ака кирпичом. Горизонтальные швы-стены все еще останутся, но уже лучше, чем швы по обоим осям.
Тем не менее, выслушаю если есть что добавить.
Не только, ещё и те, кто либо слишком стар для нее, либо кого она по каким-либо причинам заебала
Делаю RTS/TD на движке Unity. Сейчас в процессе написания сетевого кода. В Unity есть собственные сетевые компоненты, но я решил попробовать написать всю сетевую часть сам, дабы прокачать свой скилл. На данный момент уже реализовано TCP-соединение между двумя копиями игры, через которое можно передавать поток байт. Вопрос вот в чем: а какие именно данные передавать?
Существует сетевая модель "lockstep", при использовании которой игра просчитывается параллельно на нескольких компьютерах, а между собой компьютеры обмениваются лишь действиями, которые произвел каждый игрок. Такая схема, как я понял, примечательна очень малым расходом сетевого трафика, поэтому очень часто используется для RTS, где много юнитов. И можно было бы сделать так, но опасаюсь столкнуться с главной проблемой этой сетевой модели - рассинхронизацией состояний, связанной с тем, что на разных архитектурах данные рассчитываются по-разному. Хочется, чтобы игра без проблем запускалась и на любом компе, и на консолях (тем более, что управление геймпадом уже реализовано), и подозреваю, что потрачу много времени на реализацию этой модели, а потом поймаю ворох рассинхронизаций и заебусь искать их причины. Впрочем, я могу ошибаться.
Существует другая сетевая модель: "клиент-сервер". Как я понимаю, клиенты отсылают серверу действия пользователей, потом на сервере выполняются все расчеты игровой логики, а потом клиентам пересылаются некоторые данные, которых достаточно, чтобы отрисовать визуал игры. Я посчитал, сколько данных придется передавать мне, чтобы все выглядело, как надо. То есть, количество юнитов, их позиции, направление, текущая анимация, потом позиции и направление всех выпущенных снарядов, ракет, лазерных лучей... И получилось около двух МБ в секунду!!! Это если отправлять "пакет координат" в каждом игровом кадре. А если не в каждом, на клиенте игра будет идти рвано...
Короче, объясните, как поступают в таких ситуациях опытные программисты? Какие данные передавать, чтобы не грузить сеть так сильно, и при этом чтобы все работало?
Делаю RTS/TD на движке Unity. Сейчас в процессе написания сетевого кода. В Unity есть собственные сетевые компоненты, но я решил попробовать написать всю сетевую часть сам, дабы прокачать свой скилл. На данный момент уже реализовано TCP-соединение между двумя копиями игры, через которое можно передавать поток байт. Вопрос вот в чем: а какие именно данные передавать?
Существует сетевая модель "lockstep", при использовании которой игра просчитывается параллельно на нескольких компьютерах, а между собой компьютеры обмениваются лишь действиями, которые произвел каждый игрок. Такая схема, как я понял, примечательна очень малым расходом сетевого трафика, поэтому очень часто используется для RTS, где много юнитов. И можно было бы сделать так, но опасаюсь столкнуться с главной проблемой этой сетевой модели - рассинхронизацией состояний, связанной с тем, что на разных архитектурах данные рассчитываются по-разному. Хочется, чтобы игра без проблем запускалась и на любом компе, и на консолях (тем более, что управление геймпадом уже реализовано), и подозреваю, что потрачу много времени на реализацию этой модели, а потом поймаю ворох рассинхронизаций и заебусь искать их причины. Впрочем, я могу ошибаться.
Существует другая сетевая модель: "клиент-сервер". Как я понимаю, клиенты отсылают серверу действия пользователей, потом на сервере выполняются все расчеты игровой логики, а потом клиентам пересылаются некоторые данные, которых достаточно, чтобы отрисовать визуал игры. Я посчитал, сколько данных придется передавать мне, чтобы все выглядело, как надо. То есть, количество юнитов, их позиции, направление, текущая анимация, потом позиции и направление всех выпущенных снарядов, ракет, лазерных лучей... И получилось около двух МБ в секунду!!! Это если отправлять "пакет координат" в каждом игровом кадре. А если не в каждом, на клиенте игра будет идти рвано...
Короче, объясните, как поступают в таких ситуациях опытные программисты? Какие данные передавать, чтобы не грузить сеть так сильно, и при этом чтобы все работало?
Мечтаю о большем количестве творчества в жизни.
Во-первых, для таких целей - только юдп, на тсп ты разве что в пасьянс паук кооп прикрутить сможешь.
Во-вторых, данные не отправляются каждый кадр, в реальном времени отправляются только команды, изменяющие состояние на сервере (юнит 1 отправился на точку А), а на клиенте происходит отрисовка состояния согласно предиктивной модели (для уменьшения задержки). То есть клиент уведомил сервер, что юнит 1 пошел на точку А, и у себя сам тоже его начал двигать, не дожидаясь подтверждения сервера, предполагая, что эти данные до сервера дошли. Кроме изменения состояния периодически (речь о единицах в секунду) пересылаются также пакеты синхронизации, чтобы собственно уравнять то, что происходит на клиенте с тем, что на сервере. Таким образом, нет траты траффика на пересылку игрового мира каждый кадр, и рассинхрон между клиентом и сервером обычно крайне мал, так что моменты синхронизации незаметны игроку.
Из-за этого подхода всеми известный эффект серверных лагов заключается не в том, что на клиенте никто не может двигаться, пока не получен ответ от лагающего сервера, а в том, что игроков телепортирует рывками, в том числе управляемых локально игроком - таки успевает произойти рассинхронизация между действиями игрока и предиктивной модели в игре, и состоянием на сервере. Пакет синхронизации возвращает клиенты в то состояние, которое сервер считает валидным, а там всегда есть валидация, иначе хакиры.
Алсо,
>в каждом игровом кадре
почему-то на юнити распространена отвратительная практика рассчетов, связанных с игровой логикой, каждый кадр. Наверное, потому что вкатуны ничего дальше метода Update() в мануале не осиливают, а раздел про многопоточность дропают уже на заголовке сложна непонятна хочу модельки в редакторе красить.
Самый очевидный подводный камень - фпс на разных машинах внутри одной игровой сессии может быть сильно разный, со всеми вытекающими последствиями.
>В СССР же думали о будущем и думали о развитии подрастающего поколения. Дикий форс кубика рубика, всякие шахматные секции, центры научно-технического творчества молодёжи, разные радиокружки, кружки авиамоделирования, юный техник. Вот это вот все. Какие нахуй марио? Ты что пиздонулся? Никому они нахуй не нужны были в СССР.
Почему же тогда у "тупых пиндосов" были самые умные процессоры?
>отрисовка состояния согласно предиктивной модели
>пересылаются пакеты синхронизации
то есть, по сути, в результате получится тот самый "lockstep", и разница будет в том, что при любых расхождениях за истину будут приниматься данные сервера?
>для таких целей - только юдп
ну, переделать не долго
>вкатуны ничего дальше метода Update() не осиливают
просто игра и так, через Update, работает около 150 fps, поэтому пока не до оптимизаций было) Но я определенно уделю этому время - про лаги из-за разной кадровой частоты я и сам задумывался.
>просто игра и так, через Update, работает около 150 fps
А теперь представь, что игросервер - не твой локалхост, а датацентр или твой кореш, до которых пинг 100мс (оптимистично). А у тебя сетевой io выполняется в потоке, предназначенном для рендера. Енжой 10 фпс.
>А не пользоваться по часу в день в шкилке или шараге.
Да школка и шарага - это пиздец, летящий в ночи.
Они, блядь, хотят, чтобы школотрон всё свое время денно и нощно тратил на эту сраную школу. Сначала 6 (8) уроков отсиди, потом ещё домашнее задание сделай (ещё часа 3). А потом ещё летом книги почитай. Ей-богу, охерели совсем. Не дают нормально оттянутся, посидеть за компом часа 3 хотя-бы.
Я когда разделался с этой сраной школой и инстом - как гора с плеч. Я свободен! А государство ещё мечтает, чтобы я детей родил, да побольше! А ну нахуй, чтобы дети маялись, и я с ними тоже - следил, помогал!
Знаете, это сраное государство уж слишком шибко тянет свои потные ручки во все сферы жизни.
>проебал спектрум-сцену начала девяностых когда писали кучу этого твоего хуинди
И какая же это была сцена? Насколько распространённая? 3,5 анона-спектрумиста что-то там дрочили?
Распространённость тогдашних спектрумов ни в какое сравнение не идёт с нынешней распространённостью компов.
>В СССР же думали о будущем и думали о развитии подрастающего поколения.
Они, пожалуй, перебарщивали с этим. Считали - чисто развлекалово - нахуй. Будет одно развивалово. Перекосы плановой экономики, как они есть.
Точно также с кинематографом. Какие-то хуи в министерствах решали, что нужно народу. Порнуха под запретом. Тупые сортирные комедии не снимают. Боевики голливуд-style - натужно чёто-там высрали кондовое, унылое. А вот пропаганда - это да!!! Хвала КПСС, речи генсека, заседания Верховного Совета льются изо всех щелей.
>Это все лютый треш, никогда не встречал ребенка, который серьезно бы такими вещами интересовался и ходил бы туда без понукания родителей.
Такое бывает, но весьма редко. Такие люди - весьма ценные уникумы. Особенные, одарённые люди, не такие как все - серая быдломасса. Будущая интеллектуальная элита общества.
Элита по-определению не может быть многочисленной.
Можно сделать некие presets. Шаблоны комнат (скажем, штук 7 вариантов). Ты когда генерируешь карту мира, штампуешь прямо эти шаблоны. Которые заранее ты ручками нарисуешь и сохранишь в ресурсах игры.
Кстати, шаблоны могут быть кастомизируемыми. На них можно указать места, где возможна вариативность. Например, варьировать цвет стен, внешний вид дверей и ламп, и т.п.
Дальше больше. Можно сделать в этих шаблонах собственные скрипты, в которых будет прописан код, который создаёт различные детали шаблона. Т.е. если основной код решил расположить эту комнату, пользуясь этим шаблоном - вызывается скрипт шаблона, который заведует какой-то конкретикой их создания.
Я бы ещё мог бы сделать некую state-machine, которая заведовала бы генерацией мира. Она определяет, например шансы, какая комната будет генерироваться следующей. Если выпала комната А, дальше скорее всего мы сгенерируем комнаты В, Г, Д. А вариант "А" мы уже генерировать не будем. Вариант "Б" становится маловероятным.
Ещё, можно сделать некий более высокий уровень, который бы сгенерировал бы глобальную карту мира. По которой, в некоторой области, например, будут генерироваться преимущетвенно комнаты категории X, а в других крупных областях - комнаты категории Y. Что-то вроде биомов minecraft
Ну они не были в курсе насколько видеоигры хороши как пропаганда.
Сверх этого, можно ещё так поступить. Ты слышал про физические симуляции?
Как идёт расчёт fluid mechanics, например? Там задаётся некая среда, состоящая из ячеек. В каждой ячейке задаётся количество определённых вещей - например температура, давление, количество горючего вещества (топлива), количество кислорода.
Далее, запускается симуляция, которая по определённым физическим законам (диффурам), расчитывает, что со всем этим происходит.
Например, если в ячейке много топлива, кислорода, и высокое давление - в ней начинается горение, а значит повышается температура и давление.
Если в ячейке высокое давление, её содержимое стремится разполстись во все стороны. Это означает, что ячейка делится топливом и кислородом с соседними ячейками. Но не просто так, а только в том случае, если в соседних ячейках давление ниже! Т.е. это надо ещё выяснять, куда попрёт материя.
Ещё физический закон может быть такой, что под действием силы тяжести, плотная материя стремится вниз (в основном топливо). Но если материя с высокой температурой - под действием силы архимеда, она будет вытесняться более холодной материей.
В общем, тут вырисовываются очень весёлые вещи.
Идея в том, что мир для игры можно рассчитать примерно таким же способом.
Причём, это надо рассчитывать не сам мир - а некую "карту высокого уровня", о которой говорилось ранее.
Задать некие исходные условия, запустить моделирование, получить эту карту.
По которой, появятся, например, области богатые ресурсами, области, богатые монстрами, и т.п. Определённые виды комнат.
Сверху этого, можно даже запустить некий генератор "историй", который бы рассчитал бы предварительную историю мира. Т.е. сообразно некоторой логике, мир жил своей жизнью до того, как здесь появился игрок. Монстры и NPC ходили по карте, что-то там делали. И вот сейчас мы видим текущую ситуацию.
Всё это можно просчитывать заранее, когда ты создаёшь уровень, и сохранить в файле, который ты положишь в ресурсах игры.
Ещё можно запилить что-нибудь вроде бредогенератора. Видел, как компьютер генерирует тексты, вроде бы человеческие, но лишённые всякого смысла?
Что-то подобно можно сделать и для генерации лабиринтов.
Я слышал, для этого используются марковские цепи. Можешь изучить этот вопрос.
В моем случае одна комната и есть шаблон. fsm для генерации пока что нужен будет в том виде, как описано в моем посте - чтобы не полагаться на шум в чистом виде, но еще учитывать обстановку и не пересекаться комнатами. Биомы с разными вероятностями для разных видов комнат планируются, да. Про генератор истории - хз, оверкилл кажется для инди-казуалки.
Было бы круто, если бы кто-то написал продвинутый генератор мира для minecraft. Чтобы этот генератор взял бы некую исходную карту континентов, запустил бы моделирование тектонических процессов на масштабе миллионов лет, где бы эти континенты бы дрейфили, сталкивались, образовывались бы горы, реки, залежи ископаемых, леса, ну и т.п. Это всё ещё сдабривается моделированием климата. Чтобы были бы вулканические процессы, которые бы генерировали бы земную твердь. Сюда же можно добавить бомбардировку метеоритами, которые образуют кратеры. Ну и в итоге работы генератора - мы получаем некую карту мира, где биомы, реки и леса заданы не случайным образом, а получены по некоторым законам.
>Про генератор истории - хз, оверкилл кажется для инди-казуалки.
Ну если ты прогаешь для себя - это интересная тема для экспериментов. Такого я ещё нигде не видел. По-моему, отличная фича для будущих игр, которые будет создавать человечество.
Если бы в No man sky или в Elite Dangerous так бы сделали - игроки бы писали кипятком, т.к. вселенная перестаёт быть такой уж рандомной, и у неё появляется нечто особенное.
Кстати, играл в X4 ? В которой динамическая эволюция мира?
>a study path for game programmer, типо информация для вката
>первый пункт
>SICP, кирпич Кормена и прочий кал
Да нет, уважаемый, давайте-ка обойдемся без этого говна какого-то дегенерата в шапке.
> Поясните за алгоритмы процедурной генерации мира.
Добро пожаловать в wave function collapse. Правда, я не знаю, как его можно приложить к неквадратным чанкам, но уверен, ты справишься.
Я просто хочу сказать, что процедурно генерируемые миры с использованием примитивных вещей, вроде perlin noise, или незамысловатых алгоритмов, где банально по рандому что-то там генерируется. Все эти миры получаются как-то очень уж унылыми и однообразными. Достаточно полетать в них более-менее, как всё становится понятно. Тот же minecraft. На малом масштабе, в пределах блоков 500 - ещё что-то интересное есть. Но вот при более крупных масштабах, если карту отзумировать, там получается какая-то унылая каша.
И спрашивается, как всё это преодолеть? Чтобы мир стал бы поинтереснее?
Вообще говоря, мы все знаем про контент, который делается самим человеком.
Он вот, подчас, выходит интересным. Почему это так - обширная тема, здесь не рассматривающаяся.
Вот если брать генерируемый контент. Я не знаю достоверно, что да как. Здесь поле для дискуссий.
По-моему, такой контент будет интереснее, если при его генерации будут действовать какие-то нетривиальные законы, закономерности, параметры. И они все будут влиять на получающийся мир.
Эти законы могут действовать на очень разных масштабах. Они могут как на масштабе многих биомов действовать. Так и в пределах одного биома. Но по-моему, даже с такими законами, всё равно, если мы будем всё дальше и дальше отдалять карту - рано или поздно у нас опять получится каша.
Но впрочем, имеет ли это значение? Мы можем прийти к такому масштабу, что ни в жизнь не обойти и не объехать. Какая разница, что там получается?
Впрочем, мы можем добавлять уровни, на которых работают законы. Уровень 500 блоков, уровень 2000 блоков, 5000 блоков, 15000 блоков, и так далее.
Кстати, в мире можно поселить какие-то там живые силы, агенты, NPC - которые точно так же будут его преобразовывать. И эти NPC будут жить по своим законам.
Вообще говоря, бесконечно простирающиеся миры - это какой-то сюр. Наша Земля, вот, имеет вполне конечную площадь. Так что можно поступить аналогично - сделать игру, где ты будешь ходить не на плоскости (как в случае плоской Земли). А по сути - по поверхности планеты, где можно обогнуть Земной шар, и выйти к исходной точке, но уже с другой стороны. И моделирование можно будет делать конкретно для конечной площади планеты, а не бесконечного мира. Проблема бесконечного отдаления карты перестанет существовать.
Я просто хочу сказать, что процедурно генерируемые миры с использованием примитивных вещей, вроде perlin noise, или незамысловатых алгоритмов, где банально по рандому что-то там генерируется. Все эти миры получаются как-то очень уж унылыми и однообразными. Достаточно полетать в них более-менее, как всё становится понятно. Тот же minecraft. На малом масштабе, в пределах блоков 500 - ещё что-то интересное есть. Но вот при более крупных масштабах, если карту отзумировать, там получается какая-то унылая каша.
И спрашивается, как всё это преодолеть? Чтобы мир стал бы поинтереснее?
Вообще говоря, мы все знаем про контент, который делается самим человеком.
Он вот, подчас, выходит интересным. Почему это так - обширная тема, здесь не рассматривающаяся.
Вот если брать генерируемый контент. Я не знаю достоверно, что да как. Здесь поле для дискуссий.
По-моему, такой контент будет интереснее, если при его генерации будут действовать какие-то нетривиальные законы, закономерности, параметры. И они все будут влиять на получающийся мир.
Эти законы могут действовать на очень разных масштабах. Они могут как на масштабе многих биомов действовать. Так и в пределах одного биома. Но по-моему, даже с такими законами, всё равно, если мы будем всё дальше и дальше отдалять карту - рано или поздно у нас опять получится каша.
Но впрочем, имеет ли это значение? Мы можем прийти к такому масштабу, что ни в жизнь не обойти и не объехать. Какая разница, что там получается?
Впрочем, мы можем добавлять уровни, на которых работают законы. Уровень 500 блоков, уровень 2000 блоков, 5000 блоков, 15000 блоков, и так далее.
Кстати, в мире можно поселить какие-то там живые силы, агенты, NPC - которые точно так же будут его преобразовывать. И эти NPC будут жить по своим законам.
Вообще говоря, бесконечно простирающиеся миры - это какой-то сюр. Наша Земля, вот, имеет вполне конечную площадь. Так что можно поступить аналогично - сделать игру, где ты будешь ходить не на плоскости (как в случае плоской Земли). А по сути - по поверхности планеты, где можно обогнуть Земной шар, и выйти к исходной точке, но уже с другой стороны. И моделирование можно будет делать конкретно для конечной площади планеты, а не бесконечного мира. Проблема бесконечного отдаления карты перестанет существовать.
Потому что мне на голом асме под дос было проще графику писать, в разы, хоть воксельную, чем под D3D.
В принципе, люди, когда хотят такой простой API, применяют некую обёртку над имеющимся интерфейсом (D3D, скажем).
А бузинес откуда? Они ж тупые дауны, в марио игравшие и "юнный технек" не читавшие.
нах ты срешь
Справедливости ради, уже не самую популярную, как минимум Майнкрафт обогнал
>>268284
Это не гайд по вкату, а инфопомойка.
>>In the game industry, there are diffrent types of programmers/engineers. And of course not every book in the list is for every one. Also I try to show some recommended path and optional ones.
>>
>>I agree that it may be an ideal or over-ambitious, but it is like a RPG that you may want to level up and select your path in the skill tree, which may spread over decades of "playtime". And not everyone can go through to the advanced levels. Game developers can also find different ways of improvements, e.g., develop mixed skills of artist side (becoming TA), game designer side (becoming TD), or even a generalist who can produce a whole game project by himself.
>>
>>I started programming and game development in the young ages. Lack of sufficient background knowledge, I wasted quite some time in trial-and-errors and reading bits by bits randomly available at those times. I really hope some of the best books I could have read at suitable time in my life.
>>
>>As mentioned in readme:
>>
>>The books shown in the WORK represent knowledge/skills that may/should be acquired by game programmers. There are other important ways of learning, such as practicing, courses, industrial/academic conferences/publications, etc.
>>
>>You may need those knowledge in the career, or you may not. Your mileage may vary.
https://github.com/miloyip/game-programmer/issues/54
Открой гугл и скажи калькулятор.
Слева на калькуляторе число Пи. Это кнопка ещё и анимирована. Нажми по ней и поиграй в ту самую игру.
Правильный результат:
+|+|-|-| |-|+|-|
-|+|+|+| или |-|+|-|
-|+|-|-| |-|+|-|
+|+|-|-| |-|+|+|
Неправильный результат:
+|+|-|-| |-|+|-|
-|-|+|+| или |-|+|-|
-|+|-|-| |-|-|-|
+|+|-|-| |-|+|+|
Есть ли красивые алгоритмы для этой задачи или мне остается только делать случайную хуйню, а потом повторными проходами соединять куски?
Ладно. Я просто сделал рекурсивную генерацию. Если вдруг кому надо https://codeshare.io/nzrV63
Спасибо, именно что то подобное искал.
Поясни за ситуацию в игровой индустрии.
Слыша сейчас для ру-студий проблема с кадрами, стоит ли свичнутся из фулстак-сириус-уебмакакинга с 8 лет опыта в гейдев?
Если да, то с чего лучше начать переход? Чтобы в ближайшие месяцы получить оффер на 100к+?
Всю жизнь мечтал делать игори, мне кажется самое время начать.
854x480, 1:34
Начни с участия в TWG в разделе /gd!
А готов ли ты из уважаемого вебгосподина, вальяжно раскладывающего тасочки, превратиться в погоняемого кабаном кодерка, у которого каждый день срака в мыле из-за проёбаных сроков и желание повеситься из-за 60часовой рабочей недели?
> Всю жизнь мечтал делать игори, мне кажется самое время начать
Так начни делать. Почему вы так рвётесь поработать на дядю? Тем более тебя посадят делать какое-нибудь говно. Ты с одной только мобилки можешь больше миллиона ежемесячно зарабатывать, дав пососать всем этим сеньорам 300к, которые жопу себе годами рвут. Попутно можешь ещё делать хуинди мечты на ПК или консоли.
если в найтройках поставить соответсвующий режим - будет работать в консоси настоящими символами
настройках*
Z bias.
Всё ок. А что?
Накидай годноты для вката. Плюсы немого изучал, уже 2 года в средневузе отучился на прогера.
> Слыша сейчас для ру-студий проблема с кадрами
эта проблема не проходящая никто не хочет работать бесплатно
> стоит ли свичнутся из фулстак-сириус-уебмакакинга с 8 лет опыта в гейдев?
> Чтобы в ближайшие месяцы получить оффер на 100к+?
Там такой уровень зарплат у каких-нибудь арт-директоров или лид-разработчиков (1-2 на студию) и те друзья основателя. Все остальные работают за 30-50 тысяч. И дай бог, в серую.
> Если да, то с чего лучше начать переход?
Сишарп, юнити. В Сишарп сильно не зарывайся, чисто базовые операторы языка. Собирёшь проект по туториалам и можешь с пинка открывать в почти любую студию - твой уровень будет на голову выше любого другого соискателя. Ты не представляешь какие отбитыши туда приходят.
Геймдев это такой же мадагаскар в мире айти как какие-нибудь веб-студии пилящие интернет-магазины на битриксе. Разработчики уровня выше среднего в профессиональном геймдеве уже не требуются. А требуются там скриптомакаки, которые могут быстро наговнякать требуемое из купленных сворованных ассетов, старых проектов этой же студии и верх мастерства - подключить апи магазинов и аналитики и всё это за выходные.
> Почему вы так рвётесь поработать на дядю?
Потому что даже нулёвые анонимы понимают, без промазанного продвижения никому нахуй не нужны твои игруньки. Так что просто хочется миновать этот период больших амбиций и сразу приступить к делу.
> Ты с одной только мобилки можешь больше миллиона ежемесячно зарабатывать
А можешь и не получать. Добиться этого можно имея бесплатный трафик или у игры будет не нулевой ретеншн, чего вкатывальщику добиться нереально. Умея же в это всё проще пойти к тем самым владельцам дешевого траффика в найм.
aframe
> алгоримты рандомизации лута
Блядь, а алогоритм подтирания жопы тебе не озвучить? Берёшь гспч, дальше включаешь блядь голову на секунду и придумываешь свой "алгоритм". Совсем уже ебанулись что ли...
Ещё раз, долбоёбушка, что ты подразумеваешь под "алгоритмом рандомизации лута"? Формально задачу можешь поставить?
Я не он.
0. Персонаж имеет уровень.
1. Мобы разного уровня
2. Лут - рекорд с набором полей. Итемы могут групироваться в комлект. Подсчитать цену как функцию по сумме полей рекорда плюс цена дополнительных рекордов при полном или частичном комплекте?
3. Чем ценнее лут тем он чаще выпадает у высокоуровневых мобов, но и не нулевая вероятность выпасть у низкоуровневых.
4. Если выпал итем из комплекта, то вероятность выпадания других частей того же комплекта выше чем других комплектов, но ниже чем у отдельных итемов.
5. Учитываем выпадение золота. Общая стоимость выпадающих вещей и золота не должна превосходить предел для уровня персонажа.
6. Выпадение зелий должно быть сбалансировано чтобы не превозмогать но и была мотивация покупать зелья у торговцев за золото собранное с мобов.
7. Рандомное предложение у торговцев зависит в такой же степени от уровня персонажа.
Лично я бы у каждого конкретного итема в игре имел свою вероятность выпадания, а факторы досчитывал умножая базовое значение на коэффициенты. Как в уравнении про прышельцев.
Не очередной унылый рейкастинг, а именно полигоны, с текстурингом и прочим?
Растеризатор свой что ли хочешь? На хабре был курс статей "Пишем свой ОпенГЛ" или как то так.
Полигоны как раз унылый код, ничего не дающий сверх того, что элементарно делается на опенгл. Рейкастинг позволяет рендерить штуки, недоступные для полигонов, и вместе с тем плохо ложится на ГПУ до самых последних моделей, поэтому его часто и делают как упражнение на ЦПУ.
>ничего не дающий сверх того, что элементарно делается на опенгл
ну на опенгл например не получится сделать нормальное простое освещение, приходится ебаться всякими defferedshading и прочей хуитой. На софтрендере можно хоть 5 миллиардов динамических источников света применить, проц их спокойно провернет
Тоже самое со всякими объемными туманами и т.д.
А все потому что видяха не любит большие объемы данных перегоняемые из оперативки, и не любит условия (без которых сложно сделать что-то
Если прям миллиарды разве что. +- миллион спокойно прожует, говорю как челик который на куде кодит регулярно.
Проблема будет только в объеме памяти и скорости работы с ней.
Обещаю лишь одно: на цпу это будет в тысячи (ты-ся-чи) раз медленнее.
> Это все лютый треш, никогда не встречал ребенка, который серьезно бы такими вещами интересовался и ходил бы туда без понукания родителей.
Ебанутый что ли? Там были исключительно те кому это нравилось копаться в железках, делать автомобили всякие, игрушки, самолёты на радиоуправлении. Это ВСЕМ нравилось.
> А вот как раз какая-то часть интересующихся компуктерными игрульками имеют мотивацию к занятиям по программированию.
Именно в таком клубе, который не развалился после совка (сейчас правда уже развален нахуй), я и научился программеровать на паскале в 1996-2000 годах. И игры там делали, просто ни у кого компов не было кроме как клубе, по этому игры были на уровне говна, кек.
Впрочем, руководитель написал за пару недель билиард. На си. Псевдо-3D.
>>266883
>Такое бывает, но весьма редко. Такие люди - весьма ценные уникумы. Особенные, одарённые люди, не такие как все - серая быдломасса. Будущая интеллектуальная элита общества.
Сопля меньше 25 лет, плиз.
Этим даже в 90е вообще все занимались, просто потому что могли. Каждый интересовался электрухой, что-то делал, какую-нибудь хуйню мутил, химия, авто, компуктеры.
Потом конечно всё это нахуй убилось тому чо другие времена наступили, но ТОГДА это было нормой.
>Как в играх хранятся данные 100500 домиков с эльфами внутри и у эльфов предметы в карманах?
Зависит от фреймворка.
На самом низком уровне - в сжатых матрицах. Иногда не в сжатых. Иногда просто в массивах с отношениями, по сути матрица, но массивы разной длинны. Иногда просто какая-то структура двухстрочная. Вариантов не так много, но достаточно.
>Есть ли какой-то аналог базы данных?
Нет. Это просто хранилище какое-либо, буфер, несколько функций над этим хранилищем и всё. Даже типов данных зачастую нет.
В БД есть транзакции хотя в играх тоже, но там другое, слой СУБД, данные имеют типы. В играх это слишком дороха.
>>433660
> это просто таблица таблиц.
Обосранчик, ты? Узнал тебя по твоей хуете в голове, кек
Бля. Какая конченная пиздося. Ибанись.
Двачую. Тоже ходил в те годы в кружок при "дворце пионеров". Правда, железками не занимались. Когда шел в кабинет, каждый раз кекал с выставки "кружка ракетомоделистов", потому что ракеты у них не летали, а были просто склееными трубочками бумаги. Так вот на сам кружок-то я пошел уже потому, что дома batya из Германии притащил Commodore 64 (а знакомые подгоняли дискеты с пиратками - культура взаимообмена была очень развита). И мы с ним переводили инструкции с немецкого и переписывали программы на BASIC из книг. Причем я наловчился переписывать с совершенно других диалектов бейсика из советских книг, которые стоили копейки. Так вот, когда я пришел в кружок, там было занятие, на котором учили писать понг, и пока другие пытались писать код под диктовку препода, я уже добавлял в игру звуки отскока от стенок. То есть на курсы я уже пришел подготовленным. Уж не говоря о том, что я прочитал кучу книг, по технологиям которых у меня и близко не было - учебники паскаля, пролога, какой-то операционки (возможно CP/M), и понимание этого тоже пригодилось, косвенно, хотя бы чтобы вкатиться в DOS. В кружке учили Си, может быть не особо глубоко, самое продвинутое что помню - рисование линии брезенхемом. И да, самый продвинутый ученик там написал на экзамен свою игру... Достал спрайты багги из Дюны2, она у него ездила по карте, оставляла следы. Для тех лет и возраста, это, пожалуй, достижение.
Говорить, что "вообще все" занимались программированием, химией, это абсурдное заявление. Либо троллинг, либо незнание тогдашних реалий на грани аутизма. Я сменил тогда 5 школ из-за переездов, в т.ч. и в Москве. И средний уровень старшеклассников могу описать как "с трудом умеет читать". Один из тысячи, может, занимался чем-то из СТЕМ в свободное время, в Москве. В регионах дели еще на 10. В каких-нибудь дальневосточных жопах вообще никто.
Вот чем реально ВООБЩЕ ВСЕ занимались: алкашка, наркотики, дворовые банды, мелкий криминал.
Мань, ты про поздние 90е и 00е говоришь. А речь идёт либо про мухосранские клубы и городки, которые по инерции сохранили все советское, либо про ранние 90е в том же дс и питере.
Тогда в каждом классе были несколько олимпиадников, и человек 5-10 которые в клубах и музыкальных школах учатся.
Хуй знает в какой параше ты там жил, но не проецируй что везде так было. Конечно так стало, стало везде, например к 04-06 году не было ни одного города в которой не было наркоты, бухла и развала. Но пяток-другой лет ранее там было относительно нормально.
Двачую, 90е наглядно показали что представляло из себя это самое "совецкое образование" без пропаганда. Вся страна заряжала банки у телика, бухала, смотрела рабыню изауру, несла деньги в сорта ммм и верила абсолютно любой ахинее из спид инфо.
А всё потому что в совке не учили думать, только зубрить что скажут. Любое думанье вышибалось кирзовым сапогом ещё с детсада. Поэтому и сейчас полно в доску тупых формалистов, потолок которых твердить зазубренное с выпученными от ярости глазами когда с ними кто-то не соглашается.
768x432, 6:59
Что мешает бороться против системы?
> Сишарп, юнити. В Сишарп сильно не зарывайся, чисто базовые операторы языка. Собирёшь проект по туториалам и можешь с пинка открывать в почти любую студию - твой уровень будет на голову выше любого другого соискателя. Ты не представляешь какие отбитыши туда приходят.
> Геймдев это такой же мадагаскар в мире айти как какие-нибудь веб-студии пилящие интернет-магазины на битриксе. Разработчики уровня выше среднего в профессиональном геймдеве уже не требуются. А требуются там скриптомакаки, которые могут быстро наговнякать требуемое из купленных сворованных ассетов, старых проектов этой же студии и верх мастерства - подключить апи магазинов и аналитики и всё это за выходные.
Не. Такие действительно часто приходят, но в любой норм студии ты должен знать паттерны, реактивное программирование, внедрение зависимостей, асинхронщину, мвц и мвп.
Сейчас то же самое, только хуже, деньги несут в казино под личиной игр и майнинг, а уж заряжать банки куда лучше чем заниматься дрочкой на уродов нигропидорожирух и травлей.
> Не. Такие действительно часто приходят, но в любой норм студии ты должен знать паттерны, реактивное программирование, внедрение зависимостей, асинхронщину, мвц и мвп.
Ебать, то есть программирование игрулёк почти что равно десктоп или мобилки.
Я, вообще, мимокрокодил, но тема интересная зацепила глаз, меня сейчас как раз увлекла почему-то математика для 3д рендеринга и вот уже понеслось, что я по-сути пишу простейшей рендерер, хотя и использую оупенГл, есть мысли всё с нуля сделать ака написать софтваре-рендерер. Вообще, есть что в этом напрвлении двигаться?
> Вся страна заряжала банки у телика, бухала, смотрела рабыню изауру, несла деньги в сорта ммм и верила абсолютно любой ахинее из спид инфо.
Это и были либерахи котоыре совок хотели развалить. Процентов 30 таких. Хотели заряжать банки и бухать - начали заряжать и бухать.
Нет это делали бабушки и заставляли еще внуков сидеть перед телевизором с Чумаком. И в Хапер инвест бабульки тащили активнее всех свои сбережения вынимая их из под матрасов.
>внедрение зависимостей
Очень плохая хуйня, за такое бьют по рукам. Ногами.
>мвц и мвп.
Устарело уже. Теперь это различные state системы.
>>437396
>Ебать, то есть программирование игрулёк почти что равно десктоп или мобилки.
Смотря какое. Ведь и на DOTS можешь начать писать.
>Вообще, есть что в этом напрвлении двигаться?
Сделай свою ECS, популярно сейчас.
>Нет это делали бабушки и заставляли еще внуков сидеть перед телевизором с Чумаком.
Либерахи-бабушки, всё так. Ты думал среди бабок нет либерах которые совок ненавидят?
>И в Хапер инвест бабульки тащили активнее всех свои сбережения вынимая их из под матрасов.
Примерно как сейчас либерахи в пирамиды тащат свои копейки.
>Очень плохая хуйня, за такое бьют по рукам.
Понимаю, в любом нормальном проекте обязательно должна быть куча связей.
Какая ещё куча связей? Связь одна - данные которые приходят в функцию.
Или ты там через все функции через скоупы пишешь? Ебать ты.
Такая, что у тебя в объекте создаётся другой объект и это происходит постоянно и всюду. Либо такая, что этот объект передаётся через конструктор (не так хуёво, но так или иначе этот объект нужно где-то создавать).
Я чё по твоему на хуёвых проектах не работал?
>Такая, что у тебя в объекте создаётся другой объект
Ебаать.
>и это происходит постоянно и всюду.
У меня нет, но я давно уже своё пилю.
>Либо такая, что этот объект передаётся через конструктор (не так хуёво, но так или иначе этот объект нужно где-то создавать).
Звучит как поедание говна.
>Я чё по твоему на хуёвых проектах не работал?
Ну я на парочке бывал, но там такого не было. Этож вообще жесть какая-то, не? Или всё настолько плохо в индустрии?
> Очень плохая хуйня, за такое бьют по рукам. Ногами.
Схуев ли? Если не безмозгло использовать, то норм. А по-другому ты нормально все базовые зависимости и не раскидаешь.
Почти в любой норм конторе требуют знать зенжект.
> Устарело уже. Теперь это различные state системы.
Каво?
> Смотря какое. Ведь и на DOTS можешь начать писать.
Эта хуйня вообще мертвая и неюзабельная уже несколько лет в альфе и ее постоянно перепиливают.
> Сделай свою ECS, популярно сейчас.
Уже есть готовые нормальные ецс помимо юнитевской. Вообще ецс написать так то легко.
>>437396
> есть мысли всё с нуля сделать ака написать софтваре-рендерер. Вообще, есть что в этом напрвлении двигаться?
Ну в программированиие графики можно вкатиться, да.
Я сам тоже софтар рендер писал и сейчас потихоньку шейдеры изучаю
По всей видимости через глобальные переменные синглтон, в котором прописаны все зависимости.
>Схуев ли? Если не безмозгло использовать, то норм.
Ну вообще норм конечно, но проблемы 100% будут. И тестируемость очень плоха, по сравнению с другими возможностями.
>А по-другому ты нормально все базовые зависимости и не раскидаешь.
Стратегия, например. Хотя жопа болеть будет на больших объемах. Да и вообще такие асбтракции не нужны. Это пиздец.
>Каво?
Синглтоны на стейте, например.
>Эта хуйня вообще мертвая и неюзабельная уже несколько лет в альфе и ее постоянно перепиливают.
Видел четыре продакшена на нём на галлерах. Работало хорошо.
> Вообще ецс написать так то легко.
И даже нужно!
>>438161
Сервислокатор очевидный.
>>438273
Или это.
> Ну вообще норм конечно, но проблемы 100% будут. И тестируемость очень плоха, по сравнению с другими возможностями.
Эм, с чего бы это?
Если надо можешь мок сделать вместо любой реализации который просимулирует любое поведение
> Стратегия, например. Хотя жопа болеть будет на больших объемах.
А стратегия тут причем? Стратегия выбирает какие шаги алгоритма выбрать, а не зависимости раскидывает.
> Да и вообще такие асбтракции не нужны. Это пиздец.
Как ты ваще без абстракций программировать собрался? Ток не говори что у тебя все системы намертво прикручены друг к другу.
> Синглтоны на стейте, например.
Заебумба, вот другие работяги обрадуются синглтонам. А поддерживаемость какая, ух
> Сервислокатор очевидный.
Пчелидзе, сервис локтор имеет ровно ту же самую задачу, что и внедрение зависимостей - которое по сути эволюция сервис локатора.
Сейчас сервис локатор справедливо считается антипаттерном, потому что 1) нужно вручную ебаться с инициализацией и её порядком 2) зависимости рандомно раскиданы по коду, если нужной зависимости нет - сразу это не заметишь, а итоге оьсер случится хз когда. А если в начале сразу все зависимости подтягивать, то нах тебе сервис локатор лол 3) все классы зависимы от сервис локатора
В любом проекте сложнее тетриса, особенно который ты делаешь не один - сервис локатор тонну говна в жопу зальет
>Эм, с чего бы это?
С тобой куча вкатунов работает которые 100% что-то сломают.
>Если надо можешь мок сделать вместо любой реализации который просимулирует любое поведение
Проблемы начинаются когда появляются либы, отдельные участки говнокода и проебаных интерфейсов, ошибок в классах и вот это вот всё. Дебагинг будет просто пиздецом.
>А стратегия тут причем? Стратегия выбирает какие шаги алгоритма выбрать, а не зависимости раскидывает.
Через стратегию можно раскидывать и завсимости так-то.
>Как ты ваще без абстракций программировать собрался? Ток не говори что у тебя все системы намертво прикручены друг к другу.
У меня екс, очевидно. В конторках фреймворки видел всякие. Где-то лет 10 назад просто писал как кармак синглтон на 2к строчек.
>Заебумба, вот другие работяги обрадуются синглтонам. А поддерживаемость какая, ух
>В любом проекте сложнее тетриса, особенно который ты делаешь не один - сервис локатор тонну говна в жопу зальет
И это всё ещё лучше для отладки, доступа и комбинаторики. Просто нормальные интерфейсы сделать на фреймворке и всё работает нормльно, возможно даже ебли не будет.
Ну или просто нормальный фреймворк ещё сделать.
>Где-то лет 10 назад просто писал как кармак синглтон на 2к строчек.
Хотя это и не синглтон был, смесь чистых функций с синглтоном.
А тебе быстро нужно генерировать? Можешь попробовать генетический алгоритм если есть время на генерацию.
Самый пиздец, что я в теории понимаю, как это сделать, просто не знаю, как объяснить движку, чего я хочу
Тааак, ну чо ебать, 5 часов спустя я таки почти разобрался. Нашёл вот этот видос https://youtu.be/Z-mbe4k5Wa4 , уже вышел на финишную, но не понимаю, как прикрутить позицию спавна. Позицию ствола из другого класса оно считывать чёта отказывается. Как фиксить? Как заспавнить Actor с привязкой к текущим координатам игрока?
Данке. Даже не знал, что есть такая доска
Отличный тред, спасибо за книгу, ещё будет сообщите пожалуйста.
Что лучше изучать? Всегда хотел делать игры, но не знал как, с чего начать, как подойти, организовать. Чтобы можно было самому создать без команды.
Попробуй браузерку запилить
как в ECS решается проблема, когда для процессинга одного объекта нужна пара компонентов, а для другого нужно двадцать?
например волк имеет позицию, велосити, коллайдер и мозги
а игрок умеет прыгать, плавать, летать, триггерить триггеры, еще и инпут принимает
и всё это модифицирует velocity
как выглядит апдейт метод такой системы? ифами проверять есть ли у объекта такой-то компонент, есть ли такой компонент и т.д.?
получается всё сводится к огромноой уберфункции апдейта?
в примерах специально примитив показывают, где квадратик двигается по экрану, и в коде всё няшно и компактно
Ты дебил блять. Какую игру на ECS, нахуя это тебе надо? Контуженный сука, иди блять нормальными вещами позанимался.
Тебе не нужен ECS для питона, обмудак. Да и чтобы писать тру ECS и быть тем ещё наркоманом.
А так в Гугле первая ссылка на фреймворк:
https://github.com/benmoran56/esper
> пробую переделать свою игру на ECS. язык питон
Бери готовые ECS, если у тебя не йоба-планы, но йоба-планы не делают на питоне.
> как в ECS решается проблема, когда для процессинга одного объекта нужна пара компонентов, а для другого нужно двадцать?
В чем проблема? Запускаются системы по компонентами и всё.
> как выглядит апдейт метод такой системы? ифами проверять есть ли у объекта такой-то компонент, есть ли такой компонент и т.д.?
У каждой ECS по разному, но по дефолту и самая наивная реализация - выбираем все сущности у которых есть компоненты M и N, делаем над ними что-то.
Не существует никаких объектов. Существует несколько массивов данных, по которым проходятся системы. Вместо объекта используй слово "сущность", потому что сущности вообще-то не константны, ты можешь в какие-то моменты времени поменять компоненты у сущности в твой объект будет совершенно другим объектом.
> получается всё сводится к огромноой уберфункции апдейта?
Хуй знает, лучше погугли и попытайся понять что такое ecs.
>У каждой ECS по разному, но по дефолту и самая наивная реализация - выбираем все сущности у которых есть компоненты M и N, делаем над ними что-то.
смотри, во всех примерах:
> фор энтити с ворлд.гет(позишн, велосити):
> позишн += велосити
а как это мне видится в жизни:
> for энтити in ворлд.гет(позишн, велосити):
> if энтити.хэс(инпут_с_жостика):
> ____велосити += инпут_с_жостика.инпут_вектор
> if энтити.хэс(сапоги_скороходы)
> ____велосити = сапоги_скороходы.скороходистость
> if энтити.хэс(прошел_квесты_школы_бегунов)
> ____велосити = прошел_квесты_школы_бегунов.бонус
> if энтити.хэс(джамп):
> ____велосити.з += джамп.джамп
> if ... (50 проверок только для игрока)
> if ... (20 проверок общих для всех демонов)
> if ... (6 проверок только для зеленого подвида демона)
> if ... (6 проверок только для синего подвида демона)
> позишн += велосити
т.е. вся изолированная логика мувментов собирается в один котёл мувментсистем, правильно понимаю?
или для каждого делать плеер_мувментсистем, демонс_мувментсистем, мужик_с_лодкой_мувментсистем, озлобленный_волк_из_квеста_про_10_шкур_мувментсистем и т. д.?
>У каждой ECS по разному, но по дефолту и самая наивная реализация - выбираем все сущности у которых есть компоненты M и N, делаем над ними что-то.
смотри, во всех примерах:
> фор энтити с ворлд.гет(позишн, велосити):
> позишн += велосити
а как это мне видится в жизни:
> for энтити in ворлд.гет(позишн, велосити):
> if энтити.хэс(инпут_с_жостика):
> ____велосити += инпут_с_жостика.инпут_вектор
> if энтити.хэс(сапоги_скороходы)
> ____велосити = сапоги_скороходы.скороходистость
> if энтити.хэс(прошел_квесты_школы_бегунов)
> ____велосити = прошел_квесты_школы_бегунов.бонус
> if энтити.хэс(джамп):
> ____велосити.з += джамп.джамп
> if ... (50 проверок только для игрока)
> if ... (20 проверок общих для всех демонов)
> if ... (6 проверок только для зеленого подвида демона)
> if ... (6 проверок только для синего подвида демона)
> позишн += велосити
т.е. вся изолированная логика мувментов собирается в один котёл мувментсистем, правильно понимаю?
или для каждого делать плеер_мувментсистем, демонс_мувментсистем, мужик_с_лодкой_мувментсистем, озлобленный_волк_из_квеста_про_10_шкур_мувментсистем и т. д.?
Вообще хуй знает так это или нет, смотри и разбирай конкретные ECS.
Пишу так как я бы сделал и как делаю. Но у меня своя собственная ECS в которой я обсираюсь перманентно.
>а как это мне видится в жизни:
Ну сам-то как думаешь нужно ли в каждом кадре лезть в данные и всё пересчитывать или нет? Это всё на эвентах должно работать.
>> if энтити.хэс(сапоги_скороходы):
>> if ... (50 проверок только для игрока):
>> if энтити.хэс(прошел_квесты_школы_бегунов):
Это всё берется с БД (или просто с твоих массивах которые вместо БД) и ебашится в отдельную систему, хуй знает, систем_обмундирвоание() там или что-то такое, эквип_систем(). Ну и квест_систем(). Эти системы собирают все мультипликаторы велосити и создают один статичный мультипликатор. Ты по массиву этих статичных мультипликаторов без всяких ифов просто проходишь системой и увеличиваешь велосити всех заинтересованных энтити.
В каждом кадре нет необходимости, очевидно, проходить по всей БД. Только если изменения наступили.
>> if энтити.хэс(инпут_с_жостика):
>> if энтити.хэс(джамп):
Каждый инпут просто заставляет включаться все системы связанные с инпутом.
> т.е. вся изолированная логика мувментов собирается в один котёл мувментсистем, правильно понимаю?
Не так как ты описал, но да.
>мужик_с_лодкой_мувментсистем, озлобленный_волк_из_квеста_про_10_шкур_мувментсистем и т. д.?
Если этого требует ситуация, то нужно будет делать и так.
смотрю доклад по овервотчу (он на екс). и в общем да, всё так и происходит:
https://www.youtube.com/watch?v=W3aieHjyNvw
есть как и крупный апдейт метод, который чекает горы компонентов
так и мужик_с_лодкой_систем, который делает всё, что касается мужика с лодкой, и пишет в велосити. и уже потом будет использоваться мувментсистемом ниже по апдейту, так и несколько видов ортогональных по смыслу мувментсистемов
видимо, не всё так страшно, как я это себе нарисовал в голове. даже для крупной онлайн игры. просто рефакторишь все эти простынки в >систем_обмундирвоание(), и рано или поздно получится неплохая модульная архитектура
> есть как и крупный апдейт метод, который чекает горы компонентов
Чел, нет никаких апдейт методов. Никто там ничего не чекает. Есть системы которые проходят по компонентам в каждом кадре. И сущности, которые получаются в результате этого.
В самой системе можно что угодно делать. Может я не так понял тебя, но выглядит так будто ты хочешь СИСТЕМЫ запускать по чеку компонентов и всякое такое. Но это не так, такое поведение должно быть сведено к минимуму.
я про апдейт систем в гейм лупе.
вроде как все системы имеют апдейт метод. или бывают особые случаи?
https://youtu.be/W3aieHjyNvw?t=360
с 6:00 он приводит в пример афк систему. c 6:50 звучат фразы
> in order for this behavior to run an entity that's going to be cast against the system must have the entire tuple
> an AI bot has a Stats component but it doesn't have a Connection component or an InputStream so it's not going to be subject to this behavior
> these system behaviors look at those slices and you must have the whole set
что тут значит последняя фраза? кто куда смотрит? то, что системе нужны компоненты Connection, InputStream и Stats мне понятно. вроде тут не видно, что энтити проверяется на наличие компонент кроме Connection? код просто без задней мысли обращается к InputStream и Stats. тут есть какой-то хитрый синтаксис, обработка ошибок доступа, или этот код просто подразумевает, что наличие Connection гарантирует наличие InputStream и Stats на энтити?
>я про апдейт систем в гейм лупе.
Что значит апдейт систем? Запуск систем? Системы запускаются от многих факторов. Некоторые системы работают вообще всегда. Некоторые запускаются потому что обсервер/евент сработал. Некоторые по иным причинам.
Хуй знает на самом деле что там как правильно запускать их. Лично я хочу ещё погуглить и спиздить решение.
> вроде как все системы имеют апдейт метод. или бывают особые случаи?
Эээ нуу. Наверное? Не знаю про что ты. Вообще эта вся залупа та ещё залупа и я сам почти нихуя не понимаю
>>511293
>или этот код просто подразумевает, что наличие Connection гарантирует наличие InputStream и Stats на энтити?
Любая система подразумевает что у неё есть ячейки памяти которые она читает и ячейки памяти в которые она пишет.
ты не знаешь, что можно почитать про екс в целом? а то доставать клещами из гугла крупицы инфы, смотреть рандомыне видосики, читать форумчики, и стаковерфлоу это весело, но делать это на каждый аспект игры весьма утомительно
например, интересует, как с екс делать гуй, а особенно инпут который может идти в игру или в окно
>Любая система подразумевает
я про случай, если есть Connection, но нет InputStream, например. ну в общем не особо-то и интересно уже, видимо да, в их игре такого просто не бывает, да и всё
>ты не знаешь, что можно почитать про екс в целом? а то доставать клещами из гугла крупицы инфы, смотреть рандомыне видосики, читать форумчики, и стаковерфлоу это весело, но делать это на каждый аспект игры весьма утомительно
Придется. Всё не так просто как хотелось бы. Есть несколько книг и видосов, но в целом хуй, я ничего нормального не нашёл, чтобы прям топово и понятно.
> например, интересует, как с екс делать гуй, а особенно инпут который может идти в игру или в окно
Сделать можно. Сам пытаюсь делать. Всё равно это всё зависит скорее от евентов-обсерверов/вложенного апдейта или дерева зависимостей, чем от екс и систем. У меня, покрайней мере. Из плюсов - объекты это не объекты, а сущности, могу удалять и добавлять компоненты к объектам и превращать их во что угодно.
> я про случай, если есть Connection, но нет InputStream, например.
Тогда это будет другая система.
> ну в общем не особо-то и интересно уже, видимо да, в их игре такого просто не бывает, да и всё
Смотри какая хуйня. Система это просто какой-то цикл по выбранным компонентам. У системы УЖЕ забиты какие компоненты ей нужны.
>У системы УЖЕ забиты какие компоненты ей нужны
а где?
я сейчас пользуюсь фреймворком, там системы это максимально абстрактная хрень, реально цикл по сущностям, отфильтрованных по компоненту. ничего не забито. подтягиваешь компоненты, какие тебе нужно. подтягиваешь компонент с сущности, которого нет, как вот тут: >>511293 - получаешь очевидный AttributeError эксепшн
>а где?
Ну епты, в системе. В системе когда лезешь в компоненты какие ты забиваешь что там тебе нужно, a = arr[index]. Не забиты, а просто объявлены переменные, которые нужны для этой системы.
>я сейчас пользуюсь фреймворком,
Что за фреймворк?
>там системы это максимально абстрактная хрень, реально цикл по сущностям, отфильтрованных по компоненту.
Ну да, как-то так это и должно быть впринципе.
> ничего не забито. подтягиваешь компоненты, какие тебе нужно. подтягиваешь компонент с сущности, которого нет, как вот тут: >>511293 - получаешь очевидный AttributeError эксепшн
Компоненты это просто массивы. Системы это цикл по сущностям, в системах получают доступ к конкретным значениям в этих массивах. Если ты пытаешься получить доступ к неизвестному массиву по хуй знает какому индексу - ты очевидно ничего не сможешь сделать.
портируй. там всего лишь 1 файл на 200 строк кода без докстрингов
https://github.com/benmoran56/esper/blob/master/esper/__init__.py
и лицензия добрая
>портируй. там всего лишь 1 файл на 200 строк кода без докстрингов
Нихуя они крутые. У меня конечно примерно так же, но позабористее и мозги себе сломал над системой евентов. Как всё там просто.
Годно
лениво рапортую, что всё получилось. удалось переделать всё на ECS. кажется я нащупал "правильную" архитектуру игры. и ECS реально помогает избавиться от проблемы, где всё ссылается на всё, и какой бы ни была твоя архитектура, это всегда дерьмовая архитектура, где каждая фича это очередная головная боль в жопе
производительность чуть пониже, чем через ООП. видимо, связано с возросшим количеством циклов, ведь на питоне даже циклы медленные, и их надо учитывать. но речь о -5%, что не критично для моей 2д игрушки. больше упора в убогие структуры данных и алгоритмы
короче, рекомендую ECS для геймдева
В стиме есть примеры успешных игр на JS + Electron. Vampire Survivors тот же, идёт пошустрее иного кала на юнити.
не знаю. ты попробуй, а нам расскажешь
В детстве всегда охуевал от диссонанса что я понимаю под игрой, и какую ебанину называют игрой окружающие (карты, нарды, тетрис блядь, конструктор ебаный и т.п.). Помню у приятеля обнаружился перестроечный клон DnD, это был экстаз.
Вот чё лагает и выводит кулеры на первую космическую даже в главном меню.
https://store.steampowered.com/app/1105670/The_Last_Spell/
Где-то слышал что карточные игры изи на ECS делать. На ECS вообще всё изи делать, но карточные мол типо особенно заебись из-за обилия всяких эффектов и наложений.
То есть "лерп" между 0 радиан и 1 радианами должен пройти через точки 3/2 пи, пи, 1/2 пи и только после этого достичь угла 1 радиан.
это обычный лерп, он не работает так как я описал
в общем всё оказалось просто, если по часовой, то угол Б должен быть меньше угла А (то есть если он больше, вычитаем два пи), и наоборот
Я вот хз, как такое вообще возможно.
Типо хочу что-то, но не знаю что, лишь бы что. Еще скажи, что цель - поднять бабла, тогда бинго будет.
Как это вообще работает? Откуда вы вообще вылезаете?
Ради бабла не пилят ЛИШЬ БЫ ЧЕ (не говоря про то, что ради бабла закатываться в игры это само по себе шиза).
А если не ради бабла, то ради чего блядь? Я вот имею планы нескольких дрочилен и вряд ли впишусь в другие, мне это не интересно, а как можно работать над не интересным тебе, когда еще и не платят?
Ты вкатун в ГД что ли? Если вкатун - беги. Серьезно, есть более простые, лучше оплачиваемые и дегенеративные области в ИТ. А тут ты кончишь тем, что будешь за борщ делать казуалочки на мобилу и нафаршировывать их микротранзакциями, пока нормальный человек в них играть не сможет.
Оно тебе надо?
Ошибки игровой логики не на уровне тру-катч главного цикла обрабатывают.
Каждая подсистема игры имеет свои типовые проблемы о которых она вещает в лог. Системы ответсвенные за саму логику игры просто скипают обработку ввереных им объектов, если в их сущностях недогруженны нужные данные или чего-то еще им не хватает. Игрок тогда видит как игру плющит, но она не падает ведь отсутвие данных или их неправильная обработка это error, но еще не critical.
Если очень кратко, то в общем так:
1) Неисправимые - те, с которыми текущий код в принципе ничего не может сделать, кроме того, что ебнуться погромче и скинуть все говно наверх. Где уже верхний софт будет думать, че делать - перезапустить модуль или тоже ебнуться.
2) Исправимые - те, которые код может исправить и продолжить работу. Вот их скорее всего ты имеешь ввиду. Их надо залогировать, резетнуться (ну или исправить как либо еще) и продолжить работу.
3) Ожидаемые, вообще не ошибки как таковые, а ожидаемые отказы. Хз, например ввод пользователем некорректного символа. Вот их вообще лучше не трайкетчить (хотя зависит от их частоты) юзер инпут и трай-кетчем можно ловить, он раз в год приходит.
Если очень кратко, то в общем так:
1) Неисправимые - те, с которыми текущий код в принципе ничего не может сделать, кроме того, что ебнуться погромче и скинуть все говно наверх. Где уже верхний софт будет думать, че делать - перезапустить модуль или тоже ебнуться.
2) Исправимые - те, которые код может исправить и продолжить работу. Вот их скорее всего ты имеешь ввиду. Их надо залогировать, резетнуться (ну или исправить как либо еще) и продолжить работу.
3) Ожидаемые, вообще не ошибки как таковые, а ожидаемые отказы. Хз, например ввод пользователем некорректного символа. Вот их вообще лучше не трайкетчить (хотя зависит от их частоты) юзер инпут и трай-кетчем можно ловить, он раз в год приходит.
>>564886
>>564887
спс, стало чуть яснее.
я не про абстрактные типовые проблемы, которые банальными проверками решаются, а просто про всяке алгоритмы, которые не обработали какой-нибудь вырожденный случай, залезли в пустой массив, неожиданно для разраба поделили на ноль и т.д. но когда такая ошибка происходит в каком-нибудь поиске пути, смысл крашить игру? просто пусть непись топчется на месте да и всё
>что ебнуться погромче и скинуть все говно наверх. Где уже верхний софт будет думать, че делать - перезапустить модуль или тоже ебнуться.
Очень асбтрактно и скорее всего не правильно, будет что то вроде:
Npc->Controller->AI->TargetFinder->FindTask->FindAlgo->Find(x).
- Вот Find(x) у тебя ебнулся, не по причине что не нашел (ожидаемой ошибке), а по причине неисправимой, т.к. ты обосрался.
- Он кидает эксепшен, который попадает в FindAlgo.
- FindAlgo тоже наебывается, но т.к. у него нет (допустим) своих эксепшенов, он сам ничего не трай-кетчит и просто наебывается пропуская эксепшен вверх.
- Тут он попадает в FindTask, этот уже (допустим) кетчит исключения и оборачивает его в свой и тоже наебывается.
- Все это дело ловит TargetFinder. Вот он в принципе уже может че-то сделать. Как минимум залогировать говно, потом войти в UNAVALIABLE состояние и игнорировать все задачи.
Получишь полнофункционального НПЦ, но с отъебнутым поиском и записью лога.
понятно. в моем случае цепочки намного проще из-за ЕКС
в общем, надо искать такие места, где любые ошибки ведут к некритическим последствиям, и там их игнорировать и логировать
Не игнорируй ошибки. Никогда, потом забудешь и поебешся.
Слив любой ошибки в никуда, без четкого понимания почему и зачем, это что-то из худших практик.
речь о том, стоит ли крашить игру или "заигнорить" ошибку каким-либо образом. точнее обработать, ведь если буквально заигнорить ошибку, это и приведет к крашу
Если ты будешь явно игнорить ошибку - скорее всего ты всегда можешь ее явно залогировать хотя бы.
А вообще - ясен хуй не все строго, даже гото иногда пригождается.
В крупных компаниях хорошо платят, но этим же разрабам платили бы больше в неигровых компаниях.
А вообще грустно, что так получается. Геймдев - самая непрокачанная из всех ИТ индустрий. Тебе нужно знать дохуища всякого и даже того, что не используется в неигровых компаниях. Упростили работу с движком и на том спасибо
Ну оно скорее наравне стоит.
Если идти в машин лёрнинг или рвать жопу за место веб разработчика, то с большей долей вероятности денег будет дохуя. Пойдёшь в гейдев - денег будет в два раза меньше, чем в предыдущих. Пиздос, спать не могу, уже не знаю куда мыслить. В действительности, если идти мечтой, то может и выгореть что-нибудь, например офер с юбисофт монреаля. А если идти в деньги и бизнес, то к 40 годам остопиздеет как и программирование так и жизнь. Такова участь, ёбта. Тут главное понять, хочешь ли ты делать игры, или хочешь в них играть.
"Делать то, что любишь - свобода. Любить то, что делаешь - счастье"
Дают — бери, бьют — беги.
Смотря на сколько ты тщеславный и зависимый от окружающих.
Если тебе не западло в 30 оказаться не самым успешным человеком, но при этом заниматься тем, чем нравиться - вперед.
Если тебе стремно появиться перед однокласниками бывшими на кредитоведре, стремно сказать тне, что живешь с мамкой и т.п.
То иди в деньги.
Вообще, правда в том, что занимаясь тем чем нравиться, ты добьешься гораздо больших результатов, чем в мерзкой тебе сфере.
Но:
1. Это не точно.
2. Можешь не добиться.
у меня есть небольшой гуи фреймворк сделанный для игры. с иерархическими виджетами, кнопочками, вьюшками, боксами, коллбэками и всем таким
думаю попробовать сделать то же самое на ECS и посмотреть, есть ли профит
оче интересная тема хотя в сам ецс я еще не до конца въехал
вот такое накопал:
https://hal.inria.fr/hal-02147180/document
> Пойдёшь в гейдев - денег будет в два раза меньше
Геймдев дает свободу. Ты можешь лизать анус дяде за копейки, а можешь выпускать свои игры и зарабатывать миллионы. Я выбрал второе и прилично разбогател.
Расскажи свою историю.
Всех дядек, которые выпускают свои игры берут или под крыло издательства и, по сути, они становятся наёмными, или выпускаешь условный пиксельный рогалик, сделанный за год и заработав на нём тысяч 100 от силы
Так я читал же истории, когда лютые прогеры получали в геймдеве меньшую зарплату, чем мидлы в каком-нибудь гугле. Меня очень интересует вопрос денег, так как даже сам Кодзима, один из моих любимых разрабов, говорил, что делает игры ради денег и что очень любит деньги. И я его понимаю. Лично мне нужны деньги не на яхты и квартиры, а на возможность создать уже свою уютную компанию, а возможно и издательство. Деньги = возможности. Люди, говорящие, что в геймдев идут не из-за денег, в моих глазах просто глупцы, так как не видят возможностей
Модест прилично разбогател... Он с мечтательной улыбкой на лице разглядывал блестящие медяки в руке, шевелил их пальцем как бы пересчитывая несметные сокровища.
- Куплю новые носки. - мысленно произнес он и мельком бросил взгляд на свои озябшие в снегу пальцы ног, торчащие из разорванных в лохмотья ботинок.
Погруженный в сладостные грезы он не заметил как к парадной подъехала карета. Из кареты вышел представительного виду мужчина средних лет облаченный в строгую темно серую шинель и высокий цилиндр. Мужчина опираясь на трость вальяжно подошел к швейцару у входа.
- Авдей, голубчик, скажите давно этот человек ошивается здесь у двери - мужчина указал тростью на стоящего в стороне Модеста.
- Ваше блогородие, господин PHP программист, доброго утра вам! - вытянувшись в стойку выкрикнул швейцар. - давно, давно он тут стоит. Я пытался его прогнать, он видимо блаженный, ничего не понимает. Все только твердит, что вы непременно его должны выслушать.
Тут Модест как бы очнулся из своих грез и увидел, того человека, ради которого он торчал здесь как столб в снегу с темноты.
- Матер, Мастер! - закричал и запрыгал от восторга Модест, так что грязные лохмотья от его одежды стали стали взвиваться во все стороны. - я сделал, то что вы посоветовали! Я больше не пишу игры на С++. Я сделал свою первую сайт визитку для работного дома!
Лол. Ну тогда тебе надо читать, не про то как че-то делать, а как втирать быдлу хуйню и разводить работодателя на бабки.
> Тебе надо читать истории, как люди зафейлились или почему не смогли
Зачем? Может мне ещё начать читать истории раковых больных, как они под конец жизни срали и ссали под себя, и мучительно подыхали? А потом читать истории подохших в автокатастрофах? Истории бомжей, которые проебали всё в своей никчёмной жизни?
Надо смотреть на успешные примеры и работать самому не покладая рук. Тогда в конце концов ты чего-нибудь добьёшься. Ты говоришь про ошибку выжившего, но даже если взять двачерский раздел /gd, то там люди, которые реально создавали что-то годное, в результате пришли к успеху. И только двачеры, которые создают никому не нужное шизофреничное говно, кукарекают про ошибку выжившего и как всё плохо.
Благая ты маня.
Хуй знает, что тебе посоветовать, кроме как пойти на ставочках поиграть или книжки про успех прочитать.
Еще раз - истории успеха это просто бахвальное чтиво, они не несут никакой полезной информации. Ты не знаешь, что человек НЕ СДЕЛАЛ, что бы зафейлится.
Это литералли литература для бедных.
Это обоссано уже в куче исследований и размышлений.
Пример:
- Петух "Кодзима" хотел наклевать живот побольше
- Петух "Кармак" тоже.
Петух кодзима, много бегал и кукарекал, обильно клевал зерно. И, разжирел.
Петух кармак, много бегал и кукарекал, обильно клевал зерно и на хуй в суп отправился.
Читая книги петуха кодзимы, ты никогда не узнаешь, что не хуй кукарекать перед окном фермера.
Блядь ебанись, я серьезно должен это объяснять?
Как с помощью glm сгенерировать 2D текстуру с шумом Перлина?
1) разработка на макоси совсем боль? или жить можно и есть какие-то годные варианты, чтобы было удобно
2) больше склоняюсь, к разработке на плюсах поэтому
а) будет заметно сложнее, чем на юнити и шарпе?
б) как-то советовали, если хочется на с++, то попробовать не с анриала и к нему плюсов, а попробовать свой небольшой движок на плюсах написать - насколько это хороший способ? (как я понимаю, на это может уйти минимум год, учитывая, что с 0)
3) Не к холивару вопрос, но у раста есть перспективы в геймдеве, или он пока за свои основные сферы применения борется?
писать движок и на нем игру на порядки сложнее, чем делать игру на готовом движке. поэтому уже давно никто не пишет свои движки. через год так и будешь движок писать, превозмогая задачи, которые по умолчанию решены и отлажены в движках
но если кругозор важнее готовых игр, то самое то
1920x1080, 0:22
c++ yt - konstantin vladimirov
>Хочу попробовать поразрабатывать игры небольшие для себя
Никто не запрещает.
>отвлечься от основого направления
Какого?
>разработка на макоси
Обязательна, если разрабатываешь под макось и айось.
>чтобы было удобно
Используют конструкторы.
>больше склоняюсь, к разработке на плюсах
Но по вопросам твоим, тебе не следует этого делать.
>будет заметно сложнее
Будет.
>попробовать свой небольшой движок на плюсах написать - насколько это хороший способ?
Хороший способ потерять время и выгореть.
>у раста есть перспективы в геймдеве
Есть движки, но они пока ни на что не претендуют. С твоими навыками лучше взять что-то популярное и простое.
Ох уж эти двачеры...
Прочитав 100 историй выигравших в лотерею, ты будешь знать, что кто-то выиграл в лотерею.
Тебе это знание как поможет?
Не существует "развивающих" игр и "дегродных" игр. Все игры это один большой тест на IQ - и я сейчас говорю о тех тестах IQ, которые применяются в армии США, а не тех скуфидонских тестах, на которых ты 200 баллов набрал. Это тест на скорость реакции, способность быстро принимать решения, восприятие аудио/визуальной информации, определение угроз, решение задач, зачастую под временными ограничениями. Все игры в каком-то смысле "развивающие", и детям полезно в игры играть, потому что от них становятся умнее, а не тупее, как ты убеждён.
https://scitechdaily.com/research-shows-that-playing-video-games-increases-your-intelligence/
>On average, the children spent 2.5 hours a day watching TV, half an hour on social media, and 1-hour playing video games. The results showed that those who played more games than the average increased their intelligence between the two measurements by approximately 2.5 IQ points more than the average. No significant effect was observed, positive or negative, of TV-watching or social media.
то же читал эту мудрую мысль в книги богатый папа бедный папа.....
Да кто такой этот ваш ошибка выжившего.
Детишки почитают про лямбда-вычисления и напишут свой смузи-язык с сахаром, что тут такого?
Накидали все что смогли нагуглить, лол.
ИМХО в шапку нужно только Unity и все что с ним связано
90 процентов вкатунов даже это не осилят
Тогда уж только Годот.
>Прочитав 100 историй
>Прочитав 100 историй
Прочитав сто охуительных историй!
Одна сотня просто охуительнее сотни другой!
Вы видите копию треда, сохраненную 14 июня 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.