Валера Питанов
тогда, без обид, но делай игру, а не дрочи программирование.
Пусть это будут блок схемы в UE. Копипаста чужого кода или дрочка Claude. Но главное - сделать игру. Криво, косо, коряво, но сделать. Довести хотя бы самый всратый платформер от начала и до конца.
Прибегай к изучении программирования, когда ну прям никак без него. Иначе ты не игру будешь делать, а осваивать пятилетний курс в сжатые сроки.
Ты не поверишь, но ОЧЕНЬ много людей имеют охрененные навыки, но полностью завершенной даже самой убогонькой игрульки - у них нет. Только прототипы в духе "Это прототип где можно махать мечом".
Вот прям реально попробуй сделать игру, с UI, звуками, уровнями, где есть начало и конец и полный игровой цикл.
Хоть к визуальному программированию прибегай или чужой помощи.
Для начала, глянь Ассеты на Kenney.nl . Там есть все, что бы сделать практически в любом жанре игру по открытой лицензии, которая тебя ни к чему не обязывает.
какие нахуй пруфы. Все дело в фиксированной цене. Условно говоря, речь и спор то пошел от того, что я сказал, что у MSAA - ФИКСИРОВАННАЯ ценая. Т.е. она всегда одинаковая. Какая бы графика у тебя не была, стоимость MSAA растет только от количество сэмплирований и разрешении рендера. Все, точка. Хоть у тебя сцена с одним кубом, хоть у тебя на экране триллион полигонов. MSAA сожрет фиксированное количество фреймтайма.
В целом да, MSAA такое себе сглаживание:
Пруфы я кстати скинул, см. ссылки выше про рендер с хабра.
если у тебя игра выдает 300фпс.
MSAA и любой другой постпроцессинг сожрать может и 80% ФПС.
Если у тебя 60фпс, то постпроцессинг и мсаа сожрет 5-10% ФПС. Тупо потому что сожранное ms фиксированное, вне зависимости от нагрузке на сцену.
И как я сказал ранее, оно не эффективно в 2к/4к.
В целом вон, возьми godot 3 или UE4 с Dx10 таргетом. Запусти профайлер и увидишь, что msaa увеличивает стоимость фрейма на фиксированное значение в ms.
да никакая. Просто меня смущает, что MSAA приписывают все возможные грехи, выводят какие-то корреляции с количеством полигонов и т.п. Хотя технически - это просто блур с отсечением по тесту глубины в несколько проходов. От чего оно жрет фиксированное количество ms фреймтайма. И с никаких хуев оно больше жрать не будет.
Во круг срача с MSAA и DLSS и FSR набежало "экспертов", каждый бросается цифрами чуть космическими.
Хотя вон. MSAA тянулся на карточках 16-18 летней давности и норм было.
Но вот сегодня MSAA какой то не такой! Вот не работает оно.
Я не спорю, у нас сейчас есть TAA + апскейл и они лучше работают.
Но не надо в уши ссать, что мол "MSAA съест 90% фпс на 5090!"
Квалити наверное даже по лучше
В соноре интерактивных обьектов и способов одно заюзать на другое наверное по более будет.
Сложно сказать. В Неваде можно всех слать нахрен, вступить в банду рейдеров, помогать мафиозникам и т.д.
В Sonore вариаций событий по больше мне показалось.
Там буквально можно например возьмем банду рейдеров из соноры. Там как минимум есть три варианта событий:
- 1 помочь им легализоваться, как легальное поселения и закончить жизнь рейдеров
- 2 помочь им стать более сверепой бандой отморозков.
- 3 всех убить.
---
Аналогично с канибалами.
- Помочь им стать нормисами
- Помочь им стать сильнее
- Всех убить
----
Но тут про посыл наверное вопрос.
В Соноре четко виден общий посыл всех сюжетных арок.
- Молодые против Стариков
- Прогресс против Традиций
- Старое против Нового
Но всегда есть кнопка "KILL ALL"
как раз таки наоборот.
ООП за счет наследования порождает оверхед. А так же наследование усложняет чтение. По этому композиция лучше всего подходит для игр.
Зачастую лучше юзать ECS (Entity Component System) или EC (Entity Component). А сами Entity чаще всего являются God Object.
Да и вообще, адепты ООП и SOLID сейчас пойдут меня пиздить, но ООП немного подустарело концептуально (привет трейты, корутины и прочее добро). Да даже пресловутый питон возьми.
На UE как раз таки наследования слишком уж дохуя. И это наследование порождает такой раздутый оверхед, что на Godot самая минимальная сущность что-то около 12 байт занимает, то на UE - UObject за 50+ байт. А ACharacter весит за 2000+ байт (короче 2КБ, а значит 2000 уникальных ACharacter - это уже дохера, тупо на пустые капслы без модели, текстуры и данных), что создатели стратегий и массовых баталий вынуждены отказаться от всех свистоперделок ACharacter и переизобретают велосипеды на APawn, а то и на AActor.
В 28 лет решил стать разработчиком игр завел Telegram-канал. Планирую писать о пути в геймдеве,
Ну хуйней же маешься.
Свой канал, блог... Словно ты сам себя пытаешься убедить, что тебе это надо, хотя ты явно хочешь заниматься чем то другим.
У меня была книга "Бьярн Строустроп" толщиной больше чем все тома "война и мир", и пока я был эникейщиком-слаботочником, зубрил этот талмуд, а не блоги делал и прочее, потом на заводе прогал РЛС.
Во первых:
Поебать во сколько решил стать разрабом.
Просто делай это.
Во вторых:
Выбери цель и иди к ней.
Ты хочешь стать разрабам что бы лутать 100500 $ наносек?
Тогда геймдев - не твое. Геймдев - самая низкооплачиваемая отрасль в IT, при этом одна из самых требовательных отраслей. Смотри в сторону мобильных приложений, сервер-клиент интерфейсов, микросервисов и немного скиллов в DevOps, что бы не быть дятлом, который перекрашивает кнопки за 100500 наносек.
Ты хочешь сделать игру своей мечты, с караванами и блэкджеком?
Тогда делай игру, а не программируй. Действовать надо от обратного. В начале делаешь игру, потом, если не хватает новыков - эти навыки восполняешь. Не хватает навыков программирования и без них, ну вот вообще не обойтись - только тогда учись.
Ты можешь быть трижды пиздатым программистом, но игру это тебе сделать не поможет.
Полный лох в программировании, но хороший дизайнер/писатель/музыкант, который делает, дешевую подделку на РПГ мейкере, где нету ничего кроме диалогов и убегания от врага, сделает игру лучше, чем супер пиздатейший программист на UE5, который не может высрать маломальскую интересную механику.
Пример: Dust: An Elysian Tail (игру сделал саунд-дизайнер с кривыми руками, но сделал!)
в геймдеве ООП в целом не очень любят и любой игровой движок - сплошной антипаттерн.
Наследованию предпочитают композицию. А лучше в место наследования - трейты.
Многие движки не соблюдают полиморфизм в рантайме или вообще его запрещают.
Про инкапсуляцию я вообще молчу. Практически все вываливают наружу.
Проще все свойства и функционал сделать публичным, а не заниматься хуйней с инкапсюляцией, френд-классами и т.п. Да и вообще, игры любят рантайм, а значит мы должны иметь возможность считать все свойства обьекта в любой момент, все его компоненты, все свойства его компонентов, что бы с этим что-то делать.
Ну и игры прощают UB. Нам не важна точность физики, закономерности и т.п. В отличии от бизнесс ПО, игра может работать не правильно, чем не работать вообще.
игры это такое болото, когда начнешь погружаться. Банальный Гейм дизайн потребует от тебя не скиллы программирования, а тупо документирования.
Я бы посоветовал начать с азов геймдизайна.
Гугли "Как написать ГДД".
Вот пример ГДД с одного джема, команды победителей:
https://buildin.ai/share/4594255e-225a-4604-88b2-f8248cf0eb83
попробуй написать для начала игру на бумаге. Весь ее геймплей и прочее.