Bleeding Demoness - Ludum Dare 44
В рамках участия в зарубежном конкурсе Ludum Dare под номером 44 сделал игру.
Не полностью, но общие черты там все есть. Тема конкурса была Your life is your currency.
Типа твоя жизнь — это твой ресурс. На самом деле, в прошлом году, пытался принять участие, но так упоролся, что ничего не вышло. В прошлом году, еще не расчитал свои силы. Но вот в этот раз типа получилось.
В моей игре задумка такова.
Играть надо за демонессу. И она постоянно истекает кровью. Вернее, когда много ходит.
А в остальном, обычный простой платформер. Надо убивать врагов черной магией (клавиша проблем), и когда выполнится условие победы в уровне, то откроется портал. В который надо уйти и перейти на след уровень.
Примерно, эта идея уже реализована.
Не хватает некоторых нюансов, вроде истории. То есть текстаили картинок с историей перед игровой, може быть между некоторыми уровнями. Не хватает разнообразия врагов, музыки.
Ну и сами уровни надо продумать и сделать. Плюс минус, а так думаю, все есть.
Как играть в эту творческую поделку?
управление простое.
Стрелки — движение
Пробел — черная магия (атака)
Эскейп — выйти в меню,выйти из игры
Хотел бы найти также какого-нибудь художника
Хотел бы найти также какого-нибудь художника. Который все отрисует. В подходящей готической (можно кавайной) стилистике. приветствуется темный романтизм, готика,кавай, Ханс Руди Гигер, вампиры и всякое такое. Нету ли такого художника?
По идее я бы хотел такого типа рисунки.
Но то что я нарисовал слегка отличается.)))) Хотя и так тоже можно))))) Поэтому и пробую найти художника. ТАкой эксперемент для меня.
Эту игру, если все сложится, планирую разместить на ITCHIO. Бесплатно.
Имя художника будет на главном экране снизу написано.
А также, сделаю отдельный экран с авторами игры ,куда имя художника также внесу.
А игру с моим супер-мега артом я бы сделал отдельно))))))) Тогда, прикольно было бы. Как раз потренился бы со своим артом. И поменял бы механику. БЫло бы аж две мега игры)))
Вообщем будет такой простой платформер. Сложным игру делать не планирую. Сам не люблю хардкорные игры. Сам как бы впечатлен Bubble Bobble, к примеру. Иногда поигрываю в тетрис, галагу. И прикольно поиграть в простые игры. Вернее, указанные мною примеры, не такие уж и простые. Но я бы свою игру не стал бы делать сложной))) Просто игра по фану.
Ссылка на ЛУДУМ ДАРЕ страничку — https://ldjam.com/events/ludum-dare/44/bleeding-demoness
Ссылка на моем сайте — www.dimalink.tv-games.ru/bleedingdemoness
Ну вот как бы рассказал. И повторю вопрос.
Нету ли такого художника? Вот типа референсы что примерно хотел бы. Но можно обсудить)))
- 30 апреля 2019, 15:34
- 03
нет такого!
кстати а чего сразу на итч не залил?
побегал нифига не понял... что за двиг?
Жаль что нет. Сам так нарисовать не смогу - как придумал в идее)))
На Итчио - не стал. Уровней мало и они больше как демо идут и врага всего два. Плюс думал арт подулучшить (думал).
Там надо бегать к врагам, сздали желательно. И жать пробел. Подбегаешь сзади - жмешь пробел. Враг умирает.
Убиваешь врагов, ждешь когда появится анкх справа сверху. Это чатсь интерйфеса. А на урвоне появляется портал. ЖЕЛТЫЙ круг в стене. Бежишь в него. Вот и все что нужно))))
Попутно при движениях игрок истекает кровью))) Враги тоже наносят урон.
Двиг. Это мое творчество на СИ++,SDL2.0 под виндоус. Я как бы по си++,с шарп. Принципиально.
ну если я верно понимаю то для самописки прикольно... суть я понял но всё же геймплей деревянноват и типо через 7-10 почти одинаковых уровней как-то не понял к чему это всё хД...
Ну да. Да, урвоней разнообразных мне не хватает. Просто сделал их как успевал. Чтобы было к чему все это - надо какой то текст добавить может с картинками. Типа история. И врага всего то 2 сейчас.
угу в плане сроков понимаю это всегда Ы!
Тебе не в геймдев тогда. Чай не 1990-е на дворе.
Но почему? Если нравится человеку, то почему б нет
Потому что это программирование. Геймдевелопер должен делать в основном геймплей, а не программы. А тут получается как, придумал ты ТЗ, писал его час, ну два. А реализовываешь неделями.
Ты в Конях тоже не программировал? Все кнопочками делал?
Куда деваться? Так и есть. Ты не в курсе что геймдев - очень наукоемкое производство? На пару минут геймплея может уйти 8-16 часов труда.
А ты не понял моей основной мысли, да? Программировал я-программист. Геймдизайнили все, в том числе я-геймдизайнер. Программирование игры это проклятье, чёрная работа, а не конечная цель, и даже не основная часть создания игры.
программирование это настоящий ад) хотя иногда хочется туда вернуться, но только на недельку, а не годами шпарить скрипты)
Не согласен, есть типы игр, где киллер-фича для реализации требует хардкорного программирования независимо от движка. А есть - где требуется хардкорное рисование. И т.д.
Типы? Не жанры? Интересно, о чём речь.
Не важно, жанры или не жанры. Например, если я обещаю игру, в которой на маленькой локации будет миллион юнитов одновременно, тут нужна оптимизация. А для этого нужна квалификация и местами правка исходников движка под свои нужды.
В 2019 году нет ни одного движка, кастомного или из коробки, способного в 60FPS просчитывать поиск пути и все взаимодействия группы в миллион (1,000,000) юнитов в терминах StarCraft (ну пускай первого даже) на компьютере среднем по Стиму (4 ядра ~3ГГц, 8ГБ ОЗУ, NVIDIA GeForce GTX 1060). Опровергнешь?
Щас начнётся "ну я примерно сказал, ну не миллион". И не юнитов, а партиклов, и это для визуальных эффектов для обсчёта на видеокарте. Тогда я где-то даже соглашусь.
Это я к тому что важно - жанры или не жанры, типы или не типы. Спорить можно только о конкретных задачах или хотя бы видах задач.
Их не надо все заново пересчитывать каждый кадр. Вот тебе и первый шаг оптимизации - не вычисляй то, что не нужно.
Ух ты. Я писал на Паскале, Си с плюсами и без, шарпе, GML, JavaScript, и думаешь я этого не знаю?
Так опровергнешь или нет?
Ладно, я уточню - юниты должны ДВИГАТЬСЯ одновременно в заданную точку. Иначе почему это вообще юниты? Если они не двигаются, это здания. Как те раскладные требушеты в Age of Empires II или тот же Siege Tank терран.
Не тупи, есть алгоритмы (heatmap), которые для константного мира считают все пути до заданной точки. Количество юнитов при этом не важно.
Также не надо вычислять пути, например, для неподвижных в данный момент юнитов.
В постановке задачи не было константного мира, а я хочу динамический, и открытый, и ММО. Ты размахиваешь руками, говоришь "а вот хочу космос, хочу миллион!". А никакого космоса всё равно не достичь, но самое главное - геймдеву это не нужно. Геймдев, построенный вокруг программирования, обречён не вымирание.
Ну и ещё, в таком тоне как ты обсуждаешь серьёзные вещи будто я первоклашка, предлагаю тебе разговаривать дальше в гордом одиночестве. Меня не задевает твоё хамство, но оно попросту неконструктивно.
Ты не понял. Когда мир меняется, карта путей пересчитывается. Не каждый кадр и не для каждого юнита. А для каждого изменения мира и для каждой точки назначения.
Судя по твоим высказываниям, в обсуждаемых вопросах ты не имеешь опыта вообще.
Твоя тактика обсуждений - это сузить тему обсуждения до очень мелкого примера и заявить, что если в ключе твоего примера мои аргументы не работают, то они не работают в принципе. Но так не канает, дружище. Если тебя в обсуждении интересует только конкретный пример, то приводи его до обсуждения, а не задним числом.
Всё я понял. Подводишь все жанры всех игр под базу пылинок врезающихся в стенки, обсчитываемых на видеокарте. Методология однако.
Говоришь, я сужаю тему. В твоём исполнении обсуждение перетекает в обобщение до "миллиона юнитов-геймплейных-партиклов, может типов, а может видов игр, и вообще деньги платятся".
У меня действительно нет опыта в реализации миллиона юнитов. У кого в мире он есть? Если ты имел в виду партиклы, то надо было так и говорить. Под юнитом я понимаю объект, который обладает графом состояний, выбирает как ему себя вести в разных ситуациях на основе своего маленького недо-ИИ, как то: мало здоровья - бежать к своим медикам, но если приказано Stand Ground, то стоять до последнего. У него есть хитпоинты, плюс-минус щиты, мана, переносимые на себе ресурсы или другие юниты если это транспорт, аммуниция, которая может жрать общий ресурс игрока (см. Казаки) или производиться в отдельных арсеналах (см. Морские Титаны). И это реальная задача, а не какие-то пушиночки в колбочке.
У партиклов тоже есть хитпоинты и куча других параметров. Но они не выбирают, как себя вести. Выбирает за них система партиклов, так же действует и система юнитов. Сортирует, какие были недавно в зоне активных действий и какие надо обновить. Группирует близко стоящие юниты, чтобы, например, поиск врага происходил не индивидуально, а для всей группы сразу.
Разумеется, речь не идёт про вызов onUpdate() каждый кадр для каждого юнита на карте. Это расточительно.
Похвалился знаниями, молодец. К чему мы пришли? Утверджение моё не опроверг, весь геймдев твой общий пример, мягко говоря, не объемлет - огромное количество игр разрабатывается "вширь" по видам взаимодействия объектов, а не "вглубь" по созданию толпы из них.
Я принципиально ничего не отвечал, так как твоё утверждение искажает мои аргументы в удобную тебе сторону.
Огромное количество игр разрабатывается средненькими специалистами. Если привлечь специалистов выше среднего, то можно сделать игру круче, чем огромное количество игр. Хотя бы круче в одном из аспектов. А если это означает больше прибыли, то и возможность привлечь специалистов в других областях, чтобы будущие игры были круче во многих аспектах сразу.
Вширь/вглубь - это не хорошо и не плохо. Раш зерглингами - полноценная тактика. Игра про расстреливание толп зомбей - полноценная игра.
Чтобы что-то искажать, надо сначала что-то понятное утверждать, а не "ну не важно какие игры, не важно миллион или нет, юниты или партиклы, главное что я знаю что можно ОПТИМИЗИРОВАТЬ и это круто". Казуистика.
> прибыль
> специалисты
> устроиться на работу
Я понял. Мы из разных миров, меня интересует только работа в супер-малочисленных группах, в идеале 2 человека-оркестра (полу-оркестра?). Все эти ААА-штучки мимо. Кодзима ведь гений? А все остальные люди это просто оформители, ну, подтанцовка. Хочешь быть геймдевелопером - разбирайся во всём. И при этом в коде и современных технологиях и API видеокарт - как можно меньше.
Ну так мне так и непонятно, как ты собрался заставить 1,000,000 юнитов (или партиклов) перемещаться из точки A в точку B. Без вот этих вот "тут мы можем не вычислять, а тут контроллер контролирует эти юниты сверху". Квадрат из 1000x1000 юнитов должен начать перемещаться, обходя препятствия, пускай по статическому ландшафту. И если ты не можешь оптимизировать эту задачу при её пиковой нагрузке, FPS просядет, и разрушается твой аргумент. Не вся аргументация, а конкретный аргумент, о котором мы так должно говорим.
Если не понял, то переспроси. Оптимизировать можно всегда, но не в любом случае до миллиона юнитов. Если изначально поставить задачу игры с миллионом юнитов, то она достижима. Совместными усилиями программистов и геймдизайнеров. Круто - это про восприятие игрока, а не про восприятие мной своей профессии (она не крутая, а просто увлекательная).
Меня интересует разработка игр, а не разбираться в чьих-то мирах. Малочисленно или многочисленно - я решу в процессе. Оба варианта имеют достоинства и недостатки.
То ли ты и не пытаешься понять, то ли прикидываешься. Алгоритм, который я привёл в пример работает так, что каждой клетке или узлу на карте присваивается расстояние до точки назначения. Это делается один раз, пока не поменяются связи между узлами или не поменяется/добавится точка назначения. Этот набор расстояний общий для всех юнитов с одинаковой точкой назначения, поэтому количество юнитов тут не роляет. Причём связи - это связи самого мира (ландшафта), без учёта юнитов, тыкающихся друг в друга. Это поиск пути для большого количества юнитов. Обход препятствий (как раз избегание тыкания друг в друга) - это отдельная тема, но эта тема, кстати, как раз пересекающаяся с физической симуляцией партиклов.
Именно это меня в этом вопросе интересовало больше всего.
Это всё интересно (нет, правда, без подкола), но как это адресует изначальное обсуждение ++/# стоит/не стоит заниматься? Я только понял что есть ещё и твоя точка зрения. Ну, пусть будет, что. Не убедился что она чем-то приоритетнее высказанной мной.
Это у тебя надо спросить, если ты спрашиваешь наводящие вопросы, то как-то для тебя адресует. Если, конечно, ты не троллишь, но это снова тогда твои проблемы, сам себя затроллил.
Приоритеты зависят от задач и исполнителей. Где-то стоит, где-то не стоит. Я считаю, что мне мало полезного даст C#. А вот C++ я уже владею неплохо, так что почему бы не прокачать ещё? Ты боишься лезть в C++, а я боюсь лезть в арт и музыку. Разрабатывать игры мешает тебе? Нет. Разрабатывать игры мешает мне? Нет.
Наводящие вопросы были для того чтобы понять, о каких юнитах-партиклах речь, и в какой плоскости мы вообще что обсуждаем. Обменялись мнениями, и ладно.
Я не боюсь лезть в C++, я из него вырос, а некоторые не понимают как это. Другим людям я просто напоминаю, что альтернатив достаточно много, и почти все из них более целевые по своему назначению.
Вот пример, не считал, но в комменте к видео указано "millions of particles to collide with their environment" (и где-то на 9:30 мужик вводит в поле 2 миллиона).
Именно. Партиклы, не юниты. Но пре-рендер делает чудеса, не нужно столько партиклов в реальном времени в реальных задачах. И вернёмся к теме - VFX-дизайн это часть современного ААА-геймдева, но никак не его ядро, ни ААА, ни не-ААА. В каких-то отдельных 0,01% проектах это может быть и полезно.
Это геймплейные партиклы, если ты не понял.
Powder Toy? В любом случае, партиклы это не юниты.
Я привык называть юнитами все активные объекты, которые участвует в игровом процессе. Не песчинки под ногами и пылинки от взрыва, а именно такие, которые, например, могут атаковать игрока. Вот на видео как раз такие и показываются.
Т.е. если мухи кусают игрока и визуализируются как партиклы, то это юниты.
Дефолтный контекст слова "юнит" при обсуждении видеоигр - стратегия, и на момент 2 мая 2019 года не существует такого устоявшегося термина как "геймплейный партикл", который ты только что (сегодня) придумал.
https://en.wikipedia.org/wiki/Strategy_video_game#Units_and_conflict
То, о чём ты говоришь, называется проджектайлы (projectile), и в существование 1000000 проджектайлов на среднестатистической машине в 60FPS я поверю куда более охотно. Только зачем это всё нужно. Наверное, твоему работодателю это нужно? Это не значит что весь мир только за этим и гонится.
Так я и не говорил, что если стратегия, то нельзя миллион юнитов. Можно.
У тебя рук не хватит управлять всеми индивидуально, будешь как-то кучковать, вот и компьютер, кучкуя, осилит соответствующие вычисления.
Какой весь мир? Весь мир фанатов ретро-игр, как ты? Большинство людей не разрабатывает игры. А какие разрабатывают, вольны выбирать, куда им гнаться, а куда - нет.
Они и выберут. Это не значит, что я не имею права высказываться. Про ретро-игры мимо, я их не фанат, я в них просто очень хорошо разбираюсь, с конкретной целью - брать от них лучшее.
Извиняюсь, я имел в виду не фанат-геймер, а фанат-разработчик.
Вот и именно, ты разбираешься только в каком-то узком подмножестве игр, которое почему-то называешь "всем миром".
Но в мире есть место и тем, кто гоняется за артом, и кто гоняется за скоростью, точностью, и кто гоняется за UX, и кто гоняется за играми про стачки и революции.
Я не брался утверждать, за чем гонится весь мир. Но я берусь утверждать, что не за тем что ты выше озвучил, и вот почему:
Нет таких типов игр. То что ты назвал, это что-то из разряда демосцены, а не киллер-фича. А смотрите-ка, мы можем вот так много. Ну и что. Игру этим сделал? Фичу? Да вряд ли.
При чём в нашем диалоге вообще весь мир?? :'D
Конечно, есть. Называется AAA-шутер. Киллер-фича - очень много пикселей/полигонов/динамики/реализма - нужное подчеркнуть.
Ну например? Я недавно прошёл Medal of Honor: Warfighter. Что именно такого прям ХОРДКООООРИЩЕ там надо было запрограммировать по-твоему? QTE со сложным (бесполезным) выбором, чем взламывать дверь? Бесконечные патроны у напарников? Игра в догонялки на машине? Или там нет киллер-фичи?
Или давай Overwatch обсудим. Единственное зачем там кодить свой движок - это синхронизация потока игры от 12 игроков раскиданных по разным регионам. Там хорошо работает физика, но я понятия не имею, писали они с нуля её или нет (не думаю). Система звука у них кастомная, это очень грамотно продумано и сделано. Но киллер-фича ли это?
Я одолел сюжетку Destiny 2. Там что?
В студию игры и киллер-фичи.
Ладно, ок, не каждый AAA-шутер, а каждый шутер-пионер очередного нового "поколения". Вот графика - это киллер-фича. И динамика, интерактивная и не очень (например, разрушение ландшафта пулями игрока или разрушение только деревянных стен или разрушение только в катсцене).
Примеры - Quake, Half-Life 2, Crysis 1, ну и так далее и тому подобное.
Разрушение ландшафта - это сложно?
Было в Worms (которые в свою очередь являются сильно выросшим симулятором артиллерии Scorched Earth) сто лет назад (в 1995), хоть это и 2D шутер, но давно. Пока что Майнкрафт подобрался к этому наиболее близко, шутером не являясь. Вспоминается вот этот прототип: https://gamin.me/games/cubageddon
Было в Вангерах с их воксельным движком, который работал на первом Пентиуме с его 133МГц.
Да, сложно. Чем красивее (т.е. реалистичнее) ландшафт, тем сложнее разрушение ландшафта.
Идейно. Но пока что стоит проблема хотя бы генерировать более-менее реалистичный ландшафт, не то что разрушать.
Итог - выяснилось, что тип игр, о котором ты говоришь, называется "игра-пионер %чего-то%", или как минимум открывающая новую эпоху %чего-то%, в примере - графики. С утверждением, что такая игра требует каких-то особенных вложений сил, спорить трудно. Но мы совсем забыли - рендеринг пикселей не формирует набора правил для играния. А значит утверждение остаётся верным:
Программирование удивительной системы разрушения ландшафтов создаст эффектность, но играть в одну лишь рассыпающуюся землю никто не будет. Игру создаёт геймдизайнер, моя мысль была об этом. А большинство игр не пионеры, и это всегда так было (я не о том что шлакообразных игр всё больше вообще в последнее время).
Сразу вспомнил:
https://codeparade.itch.io/marblemarcher
Вот человек закодил какие-то супер-фракталы которые в реалтайме в 3D рендерятся и по ним шарик прыгает. Игра? Технически да. А толку? Тут бы добавить лифты, возможность прыгать хотя бы на небольшую высоту, менять гравитацию. Да тут огромный простор для развития, который не будет задействован его автором. Потому что программист - не геймдизайнер.
Его не обязательно генерировать. Артовики завезут же.
Зачем ты внезапно цитируешь самого себя? И какая мне разница, проклятие для тебя что-то или нет? Программирование позволяет автоматизировать чёрную работу, будь то работа художника или мастера-настольщика.
Игру создаёт команда разработчиков.
Не нужно делать большинство игр. Нужно делать одну увлекательную игру.
Как ты будешь увлекать, программированием нового, волнами баланса легко-сложно, артом, сюжетом - это решать тебе. Вся соль как раз в том, чтобы не повторять за большинством. Даже взять клонеров - они рулят, когда повторяют за одной успешной игрой, а не когда уже других таких же клонеров полно.
Ты говоришь так, как будто это конец света. Познакомься с геймдизайнером, и сделайте вместе эту же игру, но немного изменённую.
Нужно, не нужно. Я говорю что есть.
Игру создают геймдевелоперы. Так покажи мне арт-директора, который должен влиять на геймдизайн? Что это за зверь?
Да нет.
Само собой, но это не отменяет того что оно само по себе чёрная работа, если сравнивать с геймдизайном, компоновкой видеоряда, написанием сценариев, да с чем угодно.
Игра - это не только правила выигрыша, но и всё взаимодействие с игроком. Это входит в геймдизайн. И взаимодействие по визуальной части одновременно входит в арт.
Пример арт-директора: Satoru Takizawa (игра Breath of the Wild). Успокоился?
Смешно. Сразу видно, ты мало занимался тем, что ты перечислил. По твоему геймдизайн - это придумал, написал бумажку, и работа кончилась? А вот нихуя, она только начинается.
Сценаристы - это чуть ли изгои игровой индустрии, им приходится подстраиваться под остальную команду и переписывать всё по много раз.
Приём входа от игрока и его обработка - это игра. Обратная связь это уже не игра, это visual media (+аудио, разумеется), такое же как в любых других фильмах, рекламе и так далее.
Что и требовалось доказать - ноунейм, его имя не на слуху и его никто не знает. Геймдизайнеры, в отличие от арт-директоров - очень даже "неймы".
Про сценаристов не в курсе, изучу на досуге.
А ты из HR-отдела, что ли? Каждый видит то что он хочет.
Нет, игра - это цельное произведение. Интерактивность (которая есть и в не-игровых компьютерных программах) подразумевает работу в обе стороны.
А, так ты жаждущий славы, ну давай-давай. Непонятно, зачем мне что-то доказывать, мог бы сразу так и сказать.
Килобайты пустой болтовни по пустым вопросам.
Я жаждущий работоспособных проектов, а не плохо запрограммированных оживших картинок, напрасно прогибаемых под арт-директора. Я не жажду славы, я скорее пытаюсь её избежать, но это будет очень трудно, и вряд ли получится.
Обратного и не утверждалось. Но при этом: без приёма входа и его обработки игра перестаёт быть игрой; без картинок, звука, стилистики, сеттинга, игра остаётся игрой. Я имел в виду обратную связь в таком ЖЫРНОМ виде, в каком её понимают сейчас, чтоб было и то и это. А не просто минимальная графика или текст. И всё это является частью аргументации против "арт-директоров" как отдельной важной должности конкретно для геймдева.
Есть разница между минимальной графикой на отъебись и минимальной графикой, например, в Into the Breach, где внутренние состояния объектов чётко доносятся до игрока.
Не понимаю, зачем ты всё время акцентируешь внимание на программирование графики. В игре очень много, кроме графики, всего надо программировать.
Чтобы не было лишних вопросов: да, и геймплейный код тормозит, и его надо оптимизировать. И в 2D пиксельарт игре.
Ну, мы начали про какие-то партиклы, и заверте.
Тогда, когда плохо написан. Оптимизировать можно не только в C++, и я бы даже сказал, что оптимизация алгоритма от языка не зависит.
У каждой виртуальной машины есть предел. Если достигаешь его, то зависит. Прекрасно жить в мире, где есть только ретро-игры, ретро-игры даже под эмуляцией летают.
Это уже оптимизация реализации, а не алгоритма. Я имею в виду, что оверхед от неправильно построенной архитектуры запросов намного больше и хуже, чем от выбора C++ или не C++.
Тут много всего участвует, помимо последовательности команд. Взаимное расположение данных в памяти. Оптимизация компилятором (хотя в некоторых скриптовых языках есть JIT как альтернатива). Приостановка исполнения для сборки мусора.
На горизонте есть всякие более гибкие языки, типа Rust и D, возможно, постепенно они (или следующее поколение) выживут C++. А пока оно всё ещё надо. И для движков, и для игр.
Для больших игр. Инди-играм оно нужно очень мало и очень редким.
Так в этом и суть инди-игры, что она редкая, такая, какую раньше не видели, такая, какую хотят её разработчики, а не среднеарифмическое по больнице.
Если ты выпускаешь то же, что и вокруг тебя кишит, в чём же ты инди?
Я вот не хочу игры про дофамин, я хочу игры про подумать и технологии. Я в них играю, и я их разрабатываю. Это моё инди.
Так-то оно так, но есть ещё и непаханное поле "сделать имеющимися давно известными средствами игру лучше чем всё ранее существовавшее в жанре и около". Хотя изначально инди это всё что угодно без поддержки издателя, но я понял что ты про Инди.
Хорошее дело.
Да, ещё хотел добавить - Haxe это реально намного лучше, чем C++/C# для инди-игр.
"Без поддержки издателя" - это уже следствие такого расклада :-)
Для этого надо сначала повторить, что уже сделано, наработки. Это тоже долго по-своему. Короткого варианта разработки хорошей игры я не вижу, есть только длинный и бесконечный варианты.
Пробежавшись по списку фич C#, складывается впечатление, что C# и Haxe примерно равнозначны. Поэтому мне сейчас не интересно тратить время на C#. А там - хз.
Кстати, сразу что-то забыл одно направление, где инди приходится писать быстрый код - VR. Некоторые инди туда рвутся активно до сих пор (вроде денег дают конторы-изготовители железок).
Не видел ни одной действительно хорошей VR-игры, которая стоила того чтоб в неё вообще играть, не говоря уже о том чтоб оптимизировать это. Что платформы, что игры, в VR всё столь же многообещающе сколь по факту из рук вон плохо, ИМХО. Может лет через 5.
в какие VR-игры ты играл?
Названий не помню. Везде либо невменяемое управление, либо камера, либо всё плоское и скучное. Основной упор на общение и мультиплеер, то есть то что к геймплею непосредственно не относится, а только его усиливает и окружает.
Подскажи хорошие?
Я упоминал парочку в этом и в этом комментарии.
Да, я помню. Вот это вот именно та пара исключений, которая ложка мёда в бочке дёгтя, подтверждающая основное правило. Надежда умирает последней, в VR есть много большее что можно сказать, но то ли технологии не пришли, то ли время. Поживём - увидим.
Тебе кинул уже пример на видео, частицы тыкаются в стенки и в игрока (т.е. не просто графика). Благодаря оптимизациям.
Ты сейчас разговариваешь сам с собой. Я написал про обещание игроку миллиона юнитов в гипотетической моей игре, будь то стратегия, шутер, ферма или что ещё. А не про обещание тебе увеличить лимит юнитов в твоей любимой игре.
Гипотетическая твоя игра либо потребует грандиозного прорыва в мире полупроводниковой электроники, либо квантовых компьютеров, либо будет предназначена для супер-узкого круга сотрудников какого-нибудь MIT. Тоже вариант, но я думал мы про общедоступный, общепонятный геймдев. Ну и либо это не будут юниты, делов-то. Я тоже могу сделать объект "миллион юнитов" и вычислять его по частям, лениво и по месту, но миллионом полноценных юнитов (как я понял твоё изначальное высказывание) это не будет.
Конкретно в 2019 и, видимо, 2020.
Моё изначальное высказывание подразумевает, что для моей (гипотетической, я её не разрабатываю в данный момент и не планирую) игры и для тех юнитов, что у меня в игре, миллион - это посильное технически количество, но такое, что произведёт впечатление на игроков (т.е. раньше такого количества не видели).
"по частям, лениво и по месту" - это методы оптимизации. Не читерство, а просто экономия ресурсов, так как результат такой же. Но с точки зрения игрока - это полноценный миллион полноценных юнитов.
Но опять-таки, волшебных палочек тут нет, сначала прототипируем и проверяем, что миллион в нашем случае достижим, а потом уже обещаем, а не наоборот.
Так нет же. Железо уже есть в домах, но его потенциал не раскрывается. Даже операционные системы всё тормознее вместо того чтобы быть быстрее.
Про браузеры вообще грустно, железо вычисляет рекламные баннеры и трекинг действий пользователя, а не полезный контент.
Это отдельная тема для разговора, совершенно не из области геймдева. Да, это правда. Но железо есть и в руках пользователей смартфонов, и с некоторых пор большая часть геймеров планеты - казуальщики, со вкусами которых у меня, и, наверное, у тебя - ничего общего. Кого там удивлять, и зачем - непонятно.
Вот я про это и говорю. Ты то и дело увиливаешь. Зачем большая часть геймеров? Вполне достаточно той части геймеров, например, которая радуется каждому увеличению количества полигонов на виртуальном дереве.
Но можно допустить, что кому-то нравится эта часть, очевидно
А кто-то мазохист, и что. Думаю, мало кто любит, когда в той же области, в которой он занимается своим делом, кто-то делает это же шиворот навыворот.
Опять же - может быть человеку доставляет удовольствие именно такой процесс производства. В чем проблема?
Если "делать игру на языке программирования" это "принцип", то много игр не сделать. Другой вопрос, есть ли человеку так много сказать в геймдеве. Может, это и не проблема тогда...
Пожалуй много не сделать)). Я как бы именно СИ просто хотел изучить. Вот такая у меня цель еще.
Как бы - да. Делать игры без программирования - мне лично и не хочется даже. А еще и с программированием -и программирование освоить. Нахожу это значительно интересным и полезным. Лично для себя. Соглашусь, что программирование - конечно сложное занятие. И его следует тренировать и практиковать.
Как сказал Стив Джобс в одном из интервью - Каждый человек должен научиться программировать или хотя бы попробовать.Программирвоание учит думать, мыслить логически. Те это полезнее чем там передвигать элементы типа кнопок и форм с места на место. Но цена этому - сложность и время.
Каждый в этой стране должен учиться программированию, потому что это учит тебя думать...» (Стив Джобс).
Как мне кажется, к примеру, бизнес, в целом стремиться иметь быстрые решения. Те это наверное отттуда всякие эти Юнити и конструкты. Типа средства которые все упрощают.
Тут очень много всего написано. Конечно все это читаю))). Не всегда есть что сказать.
ТО есть ты не программируешь игры в хорошем смысле этого слова. Не пишешь кучу кода чтобы оживить все это и все такое.
А сторонник тоже разных КОНСТРУКТОРОВ? Я просто не знаю, что это такое КОНСРУКТОРЫ, ГЕЙМ МЕЙКЕРЫ,РПГ МЕЙКЕРЫ. слышал о них,но не знаю как именно там делается. И насколько там все прописывается. ТАм наверное свой скриптовый язык. И при помощи его надо кодить. Так себе это представляю.
Я программирую игры, но ненавижу это делать, устал от этого. Да, Game Maker Language это скриптовый язык похожий на Си. Только в котором не надо писать вагон ключевых слов типа class GameObject { public static void Main() { только чтоб сделать одно действие.
В Си нет классов. А писать классы обязательно в Яве, ты что-то перепутал.
Я всё правильно написал - GML похож именно на Си без классов, а писать вагон ключевых слов надо в C++ и C# которые мы тут обсуждаем.
Это да, я на Си++ поэтому почти никогда не писал.
На С# вагон по-меньше и там более безопаснее, но зато там инициализацию структур и массивов очень неудобно сделали.
Поэтому мне нравится писать на Lua. Минимум лишних слов, там уже и списки и хэш-таблицы есть, убирать за собой мусор самому не надо.
В Си не надо писать приведённый тобой вагон
Да и в C++ не надо классов на каждое действие. Чрезмерное употребление классов вредит производительности вашей программы.
Повторюсь, именно на него и похож Game Maker Language.
Да я уже понял, будем считать, что ты просто описался в следующем предложении.
То есть для игр предлагается свое решение. Game Maker, Constructor. А например, что из этого лучше для игр типа Bubble Bobble, Galaga, Tetris? Чтобы попробовать))
Да на самом деле стоит просто всё попробовать. Прежде всего найти какие есть встроенные примеры от авторов движка, и есть ли там что-то похожее. Взять самое похожее на требуемое и переделать на ровно то что нужно. А потом сравнить, где было проще.
Я так привык к Визуал Студия и СИ, что как то прпоустил мимо того что GameMAker денег стоит) Зашел на сайт, увидел там все это дело. Я так понял нужен комплект за 39 долларов КРИАТОР набор. А так как визуал студия - бесплатного у них нету.
Есть триалка. Ещё есть старый старый Гамак Лайт, не особо ограниченный по функциям: http://game-maker.ru/viewpage.php?page_id=3
Например, можно попробовать 8.0, но из старых любой хорош кроме 6.
думаю оба пойдут... но насколько я знаю гамак больше про код всё таки а констракт больше про кнопки.
Так и есть.
А что, у программирования есть какие то хорошие и плохие смыслы? Программирование ведь - процесс переноса алгоритма с естественного языка на язык машины. Если машина понимает язык Game Maker и реализует твой алгоритм, то чем это плохо?
В конструкторах не мало программирования, но оно сосредоточено на игровой логике, а не на рутинных операциях. Если начать докапываться то даже в какой-нибудь студии на С++ или С# ты тоже занимаешься чем-то подобным. Ты решаешь какую-то задачу вне контекста более низкого уровня. Например, того на каком процессоре будет твоя программая выполняться. Будет ли это Intel или AMD, 32 ил 64 бита? На каких ядрях будет выполняться твоя программа? А какая там адресация памяти, какая разрядность шины? Как оптимизировать конвейер или кэш? Какие прерывания ты должен получать от устройств ввода разных производителей? Ты же не захламляешь этим свой скоуп работ? Эти задачи решает IDE, с которой ты работаешь, компилируя твой код для работы на разных железках.
То что ты пишешь под вопросами - это все решает компилятор и драйвера железа.
Вот именно, точно так же конструкторы решают вопросы примитивной алгоритмизации того что остаётся неизменным для 99.999999999% игр.
Наверное ничем не плохо))) Да, IDE многое делает за разработчика.
Там довольно обычный ООП только без инкапсуляции (потому что модульность для других игр не подразумевается и никто тебе лишнего не насрёт, разве только ты сам если рукожоп). Ты так же классы заводишь, наследование, описываешь поведение. Отличие в том что ты это делаешь теперь в более удобном интерфейсе. Вместо написания class и кучи деклараций - жмёшь кнопочку и у тебя сразу окно открывается где ты работаешь с этим объектом. Ну и плюс к этому удобное управление ассетами (как с точки зрения общего состава, так и с точки зрения адресации к ним). Ещё и редактор уровней неплохой со всеми вытекающими.
Скриптовый язык есть да. Но он ничем не отличается от любого другого Си-подобного языка. Основные ключевые слова те же, но команды другие - специфичные для области игростроя. Всё равно что ты специальную библиотеку подключишь. Только работает всё из коробки без написания лишнего синтаксиса только потому что так НУЖНО (например, когда ты делаешь new и хуелион неведомых тебе параметров).
С# - это не 1990.
Многие игры, делаемые на фреймворках, пишутся на Си/С++ в Visual Studio (н-р, SFML).
Так что не надо так категорично. Долго и нудно только совсем все писать с нуля, не используя никаких библиотек.
Многие игры это сколько из скольки, и насколько они геймплейно интересны (не будем задавать вопрос о деньгах даже)? Мало ли что где пишется и на чём. Есть такое понятие как Предметно-Ориентированный Язык. Почему-то с базами данных работают на SQL, с проектированием электроники - на VHDL, со сложными математическими формулами для научных работ - на LaTeX. Для игр придумали, в частности, си-подобный Game Maker Language, и разумеется такой язык не один. Но нет, мы хотим делать игры на языках общего назначения!
Ты опять затеваешь бесполезный спор, только из-за того что не хочешь признать что тебя понесло. Вот сейчас ты взял и сменил тему с "языки программирования в играх" на "языки вообще".
Программирование - это часть разработки игры. И ВСЕ! Это то, благодаря чему ты можешь сделать геймплей и взаимодействия (и вообще устройство игры) такими как ты хочешь и как тебе надо, а не только так, как за тебя решил автор конструктора, например, Bitsy. А общие языки программирования выбирают только для того чтобы каждому новичку не пришлось учить новый ЯП в очередном игровом движке. Программирование одними играми не огранивается, иногда проще взять уже существующий ЯП, чем придумывать новый, идеально подходящий для каждого конкретного применения.
Я не менял темы. Программировать игры надо на языках, для этого созданных. Ты ведь не программируешь базы данных на C++? Задайся вопросом, почему, и станет понятно что тему никто не переводил. Почему тогда надо делать игры на языках общего назначения?
Пора бы уже отвыкать от культа поклонения Электронно-Вычислительным Машинам.
Дело в том, что C++ уже давно не популярен как язык общего назначения. Но у него есть своя область применения - оптимизация. Благодаря этому он всё ещё востребован.
Но для того, чтобы выучить оптимизацию с помощью C++, сначала надо немного выучить C++.
Пора бы уже отвыкать от культа поклонения Электронно-Вычислительным Машинам.
Касательно, меня сам поклонник БЛЕЙД РАННЕРА. Стилистики такой. И как бы осваивая программирование скорее начинаю для себя все это)))) Ты вот лично сторонник человеческих интерфейсов и чтобы машина стала человечнее?
Я понял для себя, что машина -это машина. Она иная. Типа построена по другим принципам. Вроде Спока из Стар Трека. Логика, алгоритмы. Код. Сам кстати не всегда дружу с логикой. Сейчас вот не могу передать это словами)))
А, так это вроде как... причастие к искусству хакеров? Не самоцель как "напишу свой движок и буду все игры на нём делать". Я понял. Я промахнулся.
Машина должна быть человечнее, да, но не настолько человечной, чтобы следовать приказам кого попало. Появление Drag'n'Drop конструкторов в конце 2010-х годов скорее дискредитировало идею лёгкой разработки игр, нежели помогло её продвинуть в массы, потому что эффективность сборки игры из предварительно заданных блоков, без кода, пусть и с настраиваемыми вариациями, слишком низкая. Сужу по Game Maker, Stencyl, Construct / Multimedia Fusion 2/3, Scratch и забыл как ещё там называлось. Блюпринты тоже, хотя с ними действительно в последнее время стали работать коммерчески. Не всё, за что платят, того стоит.
Именно из-за того что DnD довольно кривое, слишком уж ограниченное от этого начали отказываться вроде как. Поэтому и в GMS2 вывели совсем отдельный режим делать через код. А так да, обычно разработчики видели DnD и думали что это программирование для детей. Впрочем, если бы в GMS не было режима написания кода, то вряд ли он кому-нибудь когда-нибудь толком сдался бы. Но и код коду рознь. В Game Maker в своё время выпилили лишние декларации, оставив только суть, которая необходима для алгоритмизации игр. В том же Stencyl когда я его ковырял лет пять назад тоже был вариант писать свои куски кода, но для этого нужно было знать AS3 со всей подноготной и с особенностями реализации в самом конструкторе. Такой ереси в Game Maker, к счастью, не было с тех версий, с которых он попал мне в руки.
Не совсем понял, какие декларации из Гамака выпиливали. Princess Remedy сделана на GM5, и там никаких непонятных деклараций я не видел, почти всё как в самом последнем Гамаке. Когда-то давно я ради интереса качал и GM1.0, 2.0, 3.0, и там тоже ничего такого не видел.
О том, что в GML на моей памяти не было лишнего кода. Никогда не нужно было писать int/float, всякие там new, class, описывать свойства как public/private/protected, не нужно и события как функции объявлять, а потом ещё явно указывать event-listener-ы
Это так было не только на твоей памяти, но и вообще всегда, с самой первой версии. У него конечно есть другие недочёты, но этот аспект - идеален.
Где-то как-то. Отчасти я еще думал сделать движок для типа игр. Типа тетрис на этом своем движке, галага там на этом, что то еще - на своем. И продолжать такую практику. Какой нить мега тетрис задом наперед - снова написать все с пустого проекта. ТО есть продолжать практику СИ.
Мне вот неприятно что люди не знающие Си могли бы писать игры))) Но я незнаю так ли это))) Вот там в теме повыше чел - психолог, сделал игру, с виду прикольную и пояснил что мало писал кода. Например, по хорошему ему надо было научитсья СИ сначала, потом уже что-то писать. В моем видении. Но это мое личное мнение)) И как бы пофиг)) Мир идет другим путем.
Тот психолог работает на Констракте, в котором кода вообще тупо не существует. Всё из блоков и констант которые в них вбиваются. У Си есть множество применений там, где нужна скорость, но игра стала слишком сложным и многокомпонентным явлением, чтобы делать всё только на нём. На Си хорошо кодить, но трудно скриптовать.
Вздор. Вот тебе, например, несколько актуальных вакансий в геймдеве (в т.ч. в Питере).
Скриптеров там не хотят, хотят именно программистов движков (!) и инструментария.
Ну и если ты посмотришь внимательно, C++ и C# - это внезапно языки скриптинга UE4 и Unity соответственно.
И что, там в вакансиях где-то требуется иметь в портфолио клон Галаги или Тетриса?
И в этом нет ничего хорошего.
Программистам, как правило, не нужно портфолио. Только навыки + резюме. Так что да, пишешь клон Галаги на плюсах, изучаешь язык. А если полезешь в UE4 сразу на первых этапах, то будешь его каждый день крашить.
Я бы не отказался от быстрого текстового скриптинга в UE4 из коробки.
Но прими это как данное: специалисты в геймдеве нужны, а деньги им платятся.
Так дело в том что крашить UE4 будет не программист, а ущербность выбора C++ в качестве скриптового языка. Просто поднимать эти темы я должен не с вами. Да и в руководстве об этом могут давно догадываться, бизнес-процессы трудно и долго разворачивать. Но виноваты во всём старпёры-сишники, которые пихают свои перфокарты в 21 век, которые в нём не нужны. Может в 2020-х что-то изменится.
Я про деньги тему не заводил, а специалистов не дискредитирую. Просто это уже в свою очередь не инди-геймдев, а максимум инди-программирование.
Почему же? Кто-то зарабатывает своими играми, а кто-то - разработкой на заказ, целиком или по частям. И это всё геймдев.
Я про инди речь не заводил, но инди тоже может сделать игру с миллионом юнитов, сэкономя, например, на арте. Так же как инди может сделать графику с миллионом мазков кистью, экономя на геймплее.
Это тоже геймдев, но не весь геймдев такой, и главное в геймдевелопере это делать игры, а не делать деньги. Деньги надо делать во вторую очередь. А именно - игра должна быть очень хорошей, а деньги - просто хорошими, чтоб было где жить, что есть, и на что лечиться. Если кому-то нужно 10к$ в месяц, это не проблема. Проблема, если на самом деле игра не стоит ничего. Но так как цена игры выводится из спроса на неё, а спрос из культурной картины, на которую влияет игрожур, то... о чём мы вообще там говорили...
Дался тебе этот миллион юнитов. В чём его назначение - один раз кого-то удивить? Напомню, я критиковал позицию "Я принципиально хочу писать игры на C++, C#".
Не все умеют делать игры целиком. Но это и не надо, потому что любой принимающий участие в разработке игры - это разработчик игр.
Согласен. Но получать навыки прямо на работе - это в разы быстрее, чем в свободное от какой-то левой работы время.
Программирование не одноразовое. Опыт и наработки никуда не деваются.
Например, сначала удивляешь игроков, а потом устраиваешься на работу в любую контору, где надо тоже в игре много юнитов. А если не удивляешь игроков, то можешь всё равно устраиваться.
И? Выучить простой скриптинговый язык можно за пару недель, не заранее, а когда пригодится.
А вот кто-то хочет принципиально писать сам музыку, а не покупать готовую - и что, музыканты по твоей логике не нужны в геймдеве что ли?
QA не разработчик игр, он их тестировщик. Видеоигровой композитор или спрайтер - не разработчик игр, он их оформитель. Так же само и видеоигровой программист - просто автор компонентов игры.
Это, увы, не означает что они потом автоматически пригождаются. Я однажды написал свой дебаггер. Просто потому что мог. Он работает, и мог бы кому-то пригодиться, но он упустил своё время и контекст использования. То что я сделал в 2013 году, нужно было сделать в 2008 году. И с тех пор все эти наработки лежат мёртвым грузом, и единственный плюс - я просто поставил себе цель и её выполнил, утверждаясь в мнении о своей компетентности. Но можно было поставить другую цель, более полезную и на момент создания, и в будущем.
Нет, спасибо.
НЕТ СПАСИБО!111111111
А зачем учить Си за пару... (месяцев? лет?) если он непонятно когда и для чего именно пригодится? Чтобы можно было устроиться на работу?
Как я и сказал выше, это оформители игр, а не разработчики. Даже в самых музыкально-ориентированных играх из ряда BeatMania, osu! и подобных.
Сам ты оформитель. xD
Как я и сказал выше, разработчики - те, кто приложил руку к разработке (но не к издательству, тестированию, локализации и т.п.).
Не скажу за других, но для меня и разработка игр, и программирование - это хобби. Они не происходят друг из друга, хотя и поддерживают друг друга (то есть я не учил программирование для разработки игр и не разрабатывал игры для изучения программирования, я просто занимался поочерёдно хобби, и всё само собой училось).
Собственно, я и не работал ни на какой работе, кроме той, на которой я делал то, чему научился в качестве хобби.
Я думаю, тебе хорошо там, где ты есть.
Это называется соавторы. Музыкант и художник - не разработчики, но это ничуть их не принижает. Они - опора и поддержка проекта, без которой современная игра невозможна. Но так было не всегда, и чистая игра без профессиональной графики и музыки останется игрой, а вот без программы, которую придумывают и реализуют разработчики, игрой быть перестанет.
Не согласен. Арт-директор - разработчик, его решения могут сильно повлиять на геймдизайн и программирование. Художники - разработчики, они работают в команде арт-директора.
Какая-то мантра. Настольные игры работают без программирования. А непрофессиональный арт должен быть подкреплён хотя бы профессиональным умением показать через него геймплей. Например, игрок должен увидеть через арт размеры невидимого коллайдера. Это задача игрового художника-разработчика, в отличие от просто художника.
Если в какой-то конторе придумали что для создания игр нужен арт-директор, флаг им в руки, ведь это не так. Назови мне какого-нибудь известного арт-директора? Кто это? Где это?
Старший художник? Менеджер отдела художников? Под его руководством художники могут разрабатывать что угодно. Кроме игры.
Настольные игры работают по правилам - это и есть их программа. Соблюдение правил (выполнение программы) обеспечивает мастер или даже много мастеров (в нашей аналогии - процессор). Естественно, в настольной игре без мастера любой может сказать что нарушено правило... если ему/ей это интересно. Программа-то от этого никуда не девается, и именно она составляет собой игру.
Я не сказал, что арт-директор нужен. Хотя в инди-игре единственный артовик - это и есть арт-директор. Не потому, что он направляет команду из одного человека, а потому что направляет игру в части арта.
Ок. Но эта программа - конечный результат разработки. А разработчик программы находится под влиянием, в том числе, арта и сеттинга. До такой степени, что понимает, что это более продуктивно, чем просто циферки оборачивать в арт и сеттинг, и привлекает создателей арта и сеттинга непосредственно в процесс разработки (отсюда разработчики игры, не являющиеся разработчиками "программы").
В той мере, в какой создатель арта и сеттинга влияют на геймдизайн, они разрабатывают игру. Ну и можно сказать что если сценарист добавил к сценарию что-то, что заставляет геймдизайнера добавить к 10 уровням ещё один, то сценарист пусть будет на 10% разработчик игры. Ценная информация.
Вообще разработчик должен находиться под влиянием своей целевой аудитории.
Вот тут я считаю, что целевая аудитория должна быть под большим влиянием, чем наоборот. :)
В обе стороны, разные типы влияния. Игроков надо слушать, но и не забывать говорить своё. Главное чтоб было, что.
Напомню, я критиковал позицию "Я принципиально хочу писать игры на C++, C#".
Подумаю над этим.
старпёры-сишники, которые пихают свои перфокарты в 21 век
Вот кстати, правда, в каком-то смысле, здорово было бы, чтобы все писали КОД. Как во времена MSX2, ZX Spectrum. То есть чтобы код писать))))))) А не юзать конструкторы)))))) Я тех времен не застал. Просто предполагаю что там так было. Это мое мироощущение.
Есть одна удивительная деталь - Game Maker это изначально конструктор, но уже более чем 10 лет как в нём есть Game Maker Language, и поэтому на каждый КОД (в котором участвую) я пишу код. Или Гаминатор. Или Ludum Dare. Или что угодно. Тут главное то, что я не пишу его на С++. И да, вы не найдёте работу кодить на Game Maker Language. Но мы же о разработке игр, а не о том на что жить.
Пожалуй, выйгрышнее наверное и правда юзать КОНСТРУКТОР, ГАМЕ МЕЙКЕР для конкурса. Сжатые сроки. И с чистого листа или условной наработки на СИ - дольше было бы.
Если будет решено попробовать Гейм Мейкер, проконсультирую по любому вопросу как в нём сделать что угодно. Особенно для ретро-игр, он более чем достаточен.
Вот кстати в эпоху ту. Плюс минус вышла Snatcher Хидео Кодзимы. Это я для примерения))) Согласись круто)))) Потрясающие заставки)))
Холодный звук звукового синтезатора из MSX 2 и рок запилы версии для СЕГА СД особенно продвигают, лично меня.
Заставки крутые, что тут скажешь. И музыка тоже. Когда-то в играх их не было, и игры были скучными.
И в этом нет ничего хорошего."
то есть как это?
Ну вот так это. Был в UE раньше UnrealScript, стоило его правильно развивать, а не выкидывать. В его отсутствие можно было бы добавить Python, Lua, что-нибудь. C++ позволяет очень эффективно вычислять байты, равно как и очень эффективно стрелять себе в ногу. Польза первого не очень велика для большинства игр, а вред второго - огромен. В C# в ногу стреляется менее эффективно, но и байты вычисляются не так быстро. Естественно, везде есть API для присовокупления быстро работающих библиотек, так что в конечном итоге, в правильных руках, объединение внешних библиотек с любым из языков, включая тот же GML, даст один и тот же результат, только с разными акцентами вложения сил.
По моему опыту C# в юнити - слишком много текста.
Есть такая штука как "выразительность языка" - это единица смысла на количество символов. Чем меньше кода тебе нужно написать для передачи смысловой единицы, тем более выразителен язык. Так вот C# нихуя не выразителен в этом плане. Примерно 70% всего написанного в коде С# - лишний хлам. Конструкции очень громоздкие и сложно воспринимаются даже если ты сам автор кода и возвращешься к нему через N времени.
Думаю, C# специально сделали более Pascal'еподобным чтобы сложнее было выстрелить себе в ногу.
Да нет, просто автор Pascal, Delphi и C# один и тот же - https://ru.wikipedia.org/wiki/Хейлсберг,_Андерс
И что он думал и умел, то и сделал.
Почитал твои мысли. Можно спросить прямо. А как надо делать игры? Я имею ввиду твой подход. НУжно брать движок и на нем делать. И не надо делать типа Empty Project и писать все в коде, это не оптимально. Оптимально взять КОНСТРУКТ или еще что либо и таким средством запилить желаемое.
Уяснить пытаюсь.
Сразу ключевой вопрос - должна ли задуманная игра пробивать существующие рамки? Вот как scorched носится со своими партиклами, мол, миллион это много. Да игроку только первые 5 минут важно, сколько их, а потом пофиг, главное чтоб смотрелось и игралось круто.
Я для себя сразу говорю - нет, не должна.
Если задуманная игра - клон, или "такое же, но лучше", то ей вообще ни к чему выходить за пределы принятых рамок, она просто должна прыгнуть немного выше.
Есть например вот такая странная игра - https://store.steampowered.com/app/513360/Mu_Cartographer/
Мне на неё не хватило бы Гейм Мейкера. Но я не собираюсь делать что-либо подобное.
Так что сначала надо ответить - что ты собираешься делать, какие игры. Жанры, как минимум. 2D или 3D. Кто-то должен это 3D рисовать, разумеется.
Я не ношусь с партиклами, и вообще не собираюсь в программирование графики, хоть и немного касаюсь этой темы на работе.
А про рамки ты слишком оптимистичен, даже если 2D и в десять раз меньше амбиции, чем у обычной (с точки зрения игрока) современной игры, то всегда найдётся, чему тормозить. Можно вилять типа "ой, я захотел то, что нельзя в гейммейкере, ну ладно, сделаю всё по-другому", а можно оптимизировать код, и будет так, как задумывал изначально. И то, и другое - вполне вариант.
В "гейммейкере" можно подключить любую DLL-, SO- и даже DYLIB-библиотеку. Есть там и шейдеры. А, стало быть, возможности у всех одинаковые. Отличается только инфраструктура решения проблем - IDE и архитектура игрового движка.
Только в худшем случае для достижения цели через DLL может понадобиться написать свой собственный движок в виде DLL. Тогда это будут не равные возможности, а использование двух движков, когда можно было использовать только один свой.
Сначала должна быть такая уникальная и очень важная цель, чтобы писать какой-то неведомый супер-движок с нуля.
Подводя итог твоей аргументации: C++ изучать не нужно, потому что в Гамаке можно подключить DLL с геймплейным кодом твоей игры на C++, написанную феей и положенной к тебе под подушку.
А что, разве не так?
Геймдевелопер вынужден опираться на всю эту "сишнячину", но те кто пишут на C++, никогда не смогут разработать игру лучше того, чей интеллект не деформирован попытками договариваться с электронно-вычислительными машинами о том, какие байты куда пересылать.
И по поводу Гамака - да эти DLL там нафиг не упали. Ни одна из известных игр сделанных на нём не вычисляет игровую логику вовне, вся она написана на Game Maker Language, и это правильно. Это если тебе прям вообще никак в Гамаке не сделать твой гуголплекс юнитов, можешь заморочиться. А Гамак это как Python или Lua тот же. Скриптовый и лёгкий.
Верно. Кроме деформации интеллекта, вот если ты продавец в магазине, то тебе путь только в продажи игр, разработку игр не осилишь никак? :)
Я всё это знаю, что ты тут вещаешь про скриптовые языки, я не только ими пользовался в движках, но и привязывал к своим C++ "движкам" и создавал свои мини-языки. Большую часть игр я написал на Haxe, а не на C++. Но твоя логика, кем кому быть и что кому учить, весьма однобока. Причины у всех разные, интересы - тоже.
Набор возможностей человека формируется из его среды. Если ты продавец, вокруг тебя продавцы, тебе интересно продавать, то разрабатывать ты можешь только в оставшееся время, то есть слабо и плохо. Чтобы нормально разрабатывать, не обязательно бросать продавать, но придётся провести серьёзные изменения - сменить социальную среду. Чтобы разрабатывать, надо быть среди разработчиков. Или уж по крайней мере подальше от продавцов с их продавцовой логикой.
Я ровно одному человеку тут посоветовал, а не всем всегда и везде. Я посчитал что ему будет полезно побыстрее программировать разные игровые механики, нежели долго прописывать каждую из них. Для того чтобы делать игры, нужно прототипировать, а не декларировать классы и возвращать значения из функций в функции.
Согласен. С одной поправкой - чтобы делать игры, не обязательно их делать одному человеку целиком.
Конечно, не обязательно. Но и делать их вместе тоже не обязательно.