Pull to refresh

Comments 35

хочу что бы запуская игру я попадал в игровой процесс
а не пол часа лазил по меню настройки и обучалкам
помню еще на 386 компе что бы запустить игру
нужно было переписывать autoexec.bat и config.sys
подобрать драйвера для звука, мышки, keyrus…
и все это нужно было проделывать чуть ли не для каждой игры.
сейчас таких проблем нет. любую игру можно запустить практически на любом устройстве.
меню игры должно быть второстепенным. чем то дополнительным. откуда можно просто выбрать нужные настройки. а не ждать пока оно загрузится
и все это нужно было проделывать чуть ли не для каждой игры.

Совет — не надо было их удалять после и не требовалось бы повторной настройки.


любую игру можно запустить практически на любом устройстве.

И она скажет что хочет DX11


а не ждать пока оно загрузится

Кассеты заменяются дискетами, дискеты — HDD. скорость загрузки уменьшается, если кто-то не понимает механизма работы (т.е. происхождения ожидания), то что он ищет здесь? Сейчас, к слову, тоже не всё быстро грузится (если не SSD/i7/Vega), хотя я уже и достаточно далёк от самих игр.

Ну как обычно, суть не уловили, а второстепенные мысли стали критиковать.
Смысл был в том, что некоторые игроделы, уделяют сотворению меню слишком много внимания. Там и музыка, и графика, и анимация.
А что бы запустить игру нужно пройти целый квест.
Если брать «старые времена», то достаточно было запустить экзешник. Если требования выполнены (карта VGA, если игрушка для VGA, переменная окружения прописана один раз для звука), то всё запускается. Один раз надо запустить утилиту конфигурирования — указать что есть, если отличается от дефолта, но это до-PnPные времена, который и был сделан, тобы любая домохозяйка запускать могла.
UFO just landed and posted this here

Советуют в основном из-за того простого факта, что нуля сделать игру сложно. А большую игру невероятно сложно. Ведь многие новички приходят с идеями в стиле "я хочу сделать игру как третий ведьмак, но с добавлением вот этих замечательных идей (тут идет перечисление на три листа)".


Почти любая деятельность начинается с небольших проектов, где люди оттачивают базовые навыки, которые нужны постоянно. При этом разработка игр сложна тем, что требует множество различных навыков. И один из самых сложных — умение управлять проектами, даже большие успешные студии, делающие AAA проекты, постоянно испытывают сложности с этим. Сделав небольшой работающий проект будет уже понятно, что программисты умеют работать с движком и реализовывать игровую логику, геймдизайнеры имеют представление о том, как делать и балансировать игровые механики, сценаристы умеют придумывать сюжет и делать интересных персонажей, и т.д.


Более того, на поздних стадиях начинаются задачи, которые на начальных этапах вообще никак не появляются. Поиск издателя, работа с сообществом, даже банальный вопрос того, как об этой игре будут узнавать будущие игроки. И будет очень грустно, если крупный проект, который довели невероятными усилиями до приемлемого состояния, развалится на этой стадии. У начинающих студий чаще всего нет людей, которые это уже умеют. Просто потому что эти все вопросы решили люди, которые выпустили уже игру. И нужно либо в экстренном режиме получать новые знания, либо искать новых людей, которые это умеют.


Поэтому небольшой проект даст хотя бы некоторое представление о том, способны ли эти люди в принципе реализовать что-то. Очень просто может оказаться, что на каком-то этапе часть потеряет интерес, часть поссорится со всеми, часть окажется просто плохи в том, за что они взялись, а часть поймет, что разработка игр им на самом деле не интересно, а они хотят от жизни что-то совсем другое.


Коммерческое инди имеет довольно узкий коридор целесообразности проектов (я не говорю про тех, кто это делает по фану, получая основные средства из других источников). Типичная инди студия не обладает огромным бюджетом для разработки в течении долгого времени большой коммандой. Игру нужно сделать в краткие сроки ограниченным количеством людей, либо будет грустно и голодно. Даже если задумывать большой проект, нужно из него выделить небольшую часть, которую можно быстро сделать и выпустить, начав получать средства на дальнейшее развитие. Поэтому многие остаются на уровне некрупных проектов. Они нашли свою нишу, где они делают хорошие, продаваемые проекты, которые приносят стабильный доход.


Плохо ли это? Зависит от ситуации конкретного человека или студии. Готовы ли они на большой риск? Есть ли у него семья? Скажем, студия может начать с кучки 20-летних студентов, готовых работать за еду идею. Но время идет, у кого-то появилась семья, кто-то взял ипотеку, кто-то не может работать в авральном режиме за копейки, кто-то просто хочет более высокий уровень жизни. Крупный проект может иметь цикл разработки в несколько лет. И если начать с него, то высока вероятность, что к этому моменту он будет просто не готов, а люди не будут готовы продолжать работать за идею.


Поэтому многие статьи сразу говорят "не пытайтесь откусить сразу столько, сколько вы не сможете прожевать".

UFO just landed and posted this here

Нет, не кажется. Если проект делать очень долго, то это уже сильно добавляет сложности само по себе. У людей есть жизнь, которая имеет ограниченную продолжительность, и потребности, которые требуют материальных ресурсов для их удовлетворения. И выгорание — реальность жизни, если человек готов потратить полгода на проект, значит нужен проект на полгода. Либо нужен другой человек через полгода.


Грубо говоря, есть большая разница в организационной сложности. Большим, продолжительным проектом значительно труднее управлять, планирование становится кошмаром, бюджеты сложно оценивать, а из-за постоянных изменений (которые неизбежно будут) все заранее намеченные вчера планы завтра могут кардинально измениться. Более того, сложившаяся практика управления может быть просто не подходящей для доведения проекта до конца. В конечном счете, именно управление процессами может спасти или утопить проект при том самом выгорании.


Во-вторых, есть большая разница в сложности создания цельного и увлекательного игрового процесса. Множество различных механик порождает огоромное количество сочетаний, добавление новых влечет изменения в старых, которые порождают новые изменения и т.д. Это такой порочный круг, причем большее число механик делают круг только больше. И это только на стадии их создания. Потом, после их реализации, приходит понимание о необходимости изменений, по разным причинам, от простых "это не интересно" или "это сильно сложно" до классической "это отрицательно влияет на игровой баланс". В итоге может получиться, что вроде и возможностей очень много, но чего-то цельного не получается. Иногда идеи просто не работают.


В-третьих, техническая сложность нелинейна от размера. Чем больше кодовая база, тем сложнее вносить дополнения или изменения. А так как стабилизация требований будет происходить очень поздно в цикле разработки, это повлечет огромное количество этих самых изменений. Что очень часто негативно сказывается на качестве.


В конечном счете "невероятно сложно" значит очень простое "очень мало кто на это способен". И неспособность потратить на что-то неограниченное количество времени — одна из причин. Точно так же почти кто угодно может (в теории) переплыть Ла-Манш, но сколько людей реально это могут?

UFO just landed and posted this here
Одну простую. Потом одну чуть сложнее. Потом одну ещё чуть-чуть сложнее. И так далее.

С моей точки зрения, тебе говорят «переплыви четырёхметровую реку, а потом переплывай Ла-Манш» не потому, что полученный опыт приблизит тебя к решению задачи (хотя и это тоже, особенно в программировании, где после завершения проекта у тебя остаются и опыт, и куски кода), а потому, что пока ты не переплыл ни одной реки, ты вообще не понимаешь, твоё это или нет. И лучше понять, что на самом деле ты не хочешь этим заниматься, на середине четырёхметровой речки, когда всё, что ты вложил — это пять минут на попробовать, чем на середине Ла-Манша, когда ты уже чёрт знает сколько барахтаешься в этой воде и ненавидишь себя, Ла-Манш, воду и всё человечество.
UFO just landed and posted this here
Конечно, кому-то проще так. А кто-то упорно собирается покорять Эверест, хотя мог бы сначала подняться на 500-метровый холм и понять, что ему вообще не нравится ни процесс, ни результат. Сколько людей, столько и подходов =)
Вообще, на мой взгляд, подход будет жизнеспособным только при инкрементально наращиваемой сложности.
Задумываешь много, начинаешь с малого, там, где оно стыкуется с «много» ставишь заглушки. Чувствуешь в себе силы, снимаешь часть заглушек, делаешь реальные вещи. И т.д. и т.п. Как капуста, с кочерыжки к последним листкам. Просто иначе есть шанс получить кадавра, к примеру, с продвинутым паффайндингом, но без графики вообще, или с ровно одной картой, на которой этот паффайндинг работает. И опустившиеся руки.
На мой взгляд, мораль статьи как раз в том, чтобы не потерять запал из-за того что «еще столько надо сделать». Слона надо есть кусочками.
UFO just landed and posted this here
Задумываешь много, начинаешь с малого, там, где оно стыкуется с «много» ставишь заглушки.

Я с этим согласен (сам так и делаю всегда), но всё-таки новичок не знает и не умеет ставить хорошие заглушки и не знает, когда они нужны, а когда нет.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Мне кажется тут вопрос мотивации и знания программирования в целом.

Если человек начинает делать игры не имея опыта в программировании, то «складывание кубиков» как раз таки поможет освоить движок и язык. Так же как изучение программирования начинают с простых алгоритмов и программ, а не с большого проекта.

Сужу в том числе по своему опыту: я уже около 5 лет работаю как .Net разработчик, уже год делаю свою игру (как хобби проект) и очень ограничиваю свою фантазию, чтобы наконец его закончить. Например: пошаговый бой (облегчает обработку команд игрока и ИИ), боевой ИИ просто выбирает действие по скриптованым приоритетам, перемещения в бою опять же нет.

И опыт промышленной разработки очень помогает в структурировании кода, в моём представлении человек который с нуля хочет стать инди и начинает сразу с ммо просто запутается в своём коде и игра так и не получится.
UFO just landed and posted this here

Почему все рекомендуют начинать с прописей и никто с написания трилогии?


Те, кто начинал делать проэкт, где 5 разных расс, тонны оружия и обязательный онлайн — так и остались на уровне поста в gamedev.ru с узнаваемой грамотностью (некоторые слова стали даже отдельными терминами — пара строчкой выше есть).


Я не вижу разницы в сложности сделать платформер или ммо или квест

Сложность ММО уже в первой букве (да вообще в каждой), без понимания этого не понять остального.

UFO just landed and posted this here
Есть вариант что те, кто смогли — начали с минимального. Пример сразу крупного проекта, который видел — E5 (но это не 5 лет назад), но его хитрость в том, что он не был сразу крупным, первые несколько лет(!) это было вообще потихоньку развивающееся технодемо движка и только потом, после появления издателя, оно стало игрой.
А вот так сразу написать игру/ОС/СУБД или ещё что, то как-то не приходят на ум.
Если вы не говорите о больших студиях, но говорите о сольных выступлениях, то сделать большое сразу — сложнее. Причём и сложнее и дольше. Потому, что человек-разработчик-юный вряд ли имеет представление обо всех компонентах игры. Научиться делать каждый компонент хорошо можно только одним способом. Изучив его досконально. Или хотя бы до того уровня, который будет считаться приемлемым. В каждом компоненте есть сложности, которые хорошо известны практикам, но увы не известны теоретикам, потому что понять их можно только начав делать что-либо, но не теоретизируя лежа на диване.

Учитывая то, что игра многокомпонентная система стоит снизить количество компонент, потому что увязывание их вместе обязательно родит конфликты, и нужно будет искать решения этих проблем. Если кто-то вдруг пытается сразу сделать сложный проект заканчивается это фиаско с 99% гарантией. Попыток взлётов с этих стартовых площадок зафиксировано… если честно я таких не припомню. У каждого разработчика до большого проекта, в котором он завяз словно бегемот есть проекты меньшего масштаба, и законченные. Хотя бывают и такие разработчики, которым сама разработка приносит удовлетворение, и которых швыряет с одного проекта на проект, которым интересно решать задачи, а не доводить игру до своего логического конца. Под логическим концом понимается релиз, доставка игры публике, а не коммерция. Потому, что коммерция это ещё один компонент, которые автору игры придётся изучить.

Если вы считаете, что большой проект можно сделать — сделайте это, и докажите остальному миру, что они не правы. Подобным образом я потратил десяток лет, если не более, пытаясь найти какие-то свои пути в мире изобразительного искусства, и по прошествии лет бесцельной борьбы и поиска решений, пришел к выводу что тысячелетний опыт художников прошлого назван опытом не на пустом месте. Люди итеративно оттачивали технологию рисования. Начиная от наскальных рисунков (что были довольно простыми надо сказать) до тех полотен, что мы видели и наблюдаем в музеях и по сей день, как предметы искусства, того лучшего что смогло достичь человечество за множество столетий.

С разработкой игр похожая ситуация. Как малыш изучает «буквицы» ему приходится начинать с азов. Отождествлять картинку с буквой. Затем он изучает слоги. Затем слова. И ещё очень нескоро он начинает читать. Ещё дальше этап написания собственных текстов. Так работает всё сущее. Так работает природа вокруг нас. Сущности сложные состоят из сущностей простых. Так работает и строитель. Кто угодно. Постигая простые, краеугольные понятия, чтобы затем воздвигнуть фундамент и начать выстраивать здание. Редко когда постройка происходит наоборот.
И сразу вспомнилась игра с паззлами и нарративом.
image
Добавлю еще одну потенциальную мину разработки игр — готовый инструментарий к неготовой игре. Это актуально не для всех игр, но если все таки актуально, то многие на него попадаются…

В какой-то момент разработки Вы поймете, что Вам нужно либо создавать библиотеку контента, либо генерировать его случайным образом.

Создавать библиотеку вручную довольно муторно, кроме того во многих случаях генерация случайного контента является несомненным плюсом игры, поэтому Вы говорите себе: «Я сейчас сделаю генератор и потом буду использовать его в игре, и это будет хорошо!».

После какого-то времени разработки этого у Вас получается отличный генератор, но сил на саму игру уже не хватает… Даже если сил хватает, то неготовая игра еще «дышит» и может значительно меняться — это нормально. Но у Вас уже есть готовый инструментарий, который необходимо поддерживать, чтобы он соответствовал изменениям игры. И силы уходят не туда…

Правильно делать игру с MIN контента и лишь на финальной стадии делать инструментарий…

Да. Очень распространённая ошибка пилить игровой движок, вместо, собственно, игры)
Как пример — Alternativa3D.
Есть и обратные примеры — это store.steampowered.com/app/466560/Northgard для которого написали новый движок (heaps), на своём языке(haxe).
Правда это далеко не первый проект.
Автор в статье приводит ссылку на свои игры и я решил рассмотреть их подробнее на предмет того, насколько можно доверять его опыту.

Итак, начнем с того, что автор пишет «обязательно продайте игру, не выкладывайте в свободный доступ». Однако у него они все бесплатны.

Pixel Art Shooter.
«Pixel Art Shooter is a physics-based puzzle game» — цитата из описания. Игра не основана на физике, шарики просто падают вниз, без сложных столкновений или чего-то такого. С тем же успехом можно и тетрис так назвать. Хотя нет, после более детального осмотра физика там нашлась (если подбить шар в полете — он вылетит за пределы экрана), просто в геймплее она роли не играет.
Ужасное управление, клавиши от 1 до 6 и энтер, цифру еще и нужно держать пока шар летит. Управление щелчком мыши было бы проще и интуитивнее, реализовать его в GameMaker'e (а игра сделана там) было бы не сложнее. Еще HTML5 и книжная ориентация намекают на то, что игра для мобильных платформ, что делает управление еще более странным.
С самого начала нет никакого туториала или даже намеченной цели, но это не такая уж и проблема, ведь вся игра сводится к раскладыванию шариков по цветам и выкидыванию лишних за пределы поля. Если сделать это проще и красочнее — может получиться неплохая игра для детей до пяти лет.

Rogue Drop.
Для того, чтобы в неё поиграть нужно послать автору письмо, чего я не буду делать. Хватит и тех нескольких скриношотов.
Итак, пиксельарт. Просто и примитивно, рисуй в Paint'e как хочешь, пихай в игру и будет хорошо? Нет, нет и нет. На скриншотах как-раз яркие примеры плохого обращение с пиксельартом. Видите, некоторые пиксели словно прямоугольные и в целом картинка выходит кривой? Это связано с тем, что нельзя масштабировать пиксельную графику на значения не кратные степеням двойки. Звучит сложно, но написано чуть ли не в каждом адекватном туториале на тему. Особенно ужасно, кстати, это отразилось на шрифтах. Еще нельзя поворачивать отдельно взятый спрайт на произвольное значение. Да и вообще поворачивать нельзя, нужно рисовать отдельно. Что выходит видно на первом же скриншоте.

Zombie Ride Share.
Даже не буду долго задерживаться. Это не игра. На GameMakere такую поделку за вечер сделает школьник не имеющий опыта в программировании, а при небольшом опыте работы в программе — и вовсе минут за 15.

Wizard Golf RPG.
Увы, не имею яблочной продукции, чтобы посмотреть а по ссылке (!) скриншоты недоступны. Даже не могу уверенно сказать, своя у автора графика или из ресурс-пака.

Drill Planet.
Пример того, как делать не нужно, а именно не нужно выпускать игру, которую даже не пытался тестировать.
Третья кнопка в меню: окошко с именем переменной «global.HiScore» вместо значения. Ну ошибся человек, поставил, зачем-то, лишние кавычки в коде, но разве трудно проверить хоть раз одну из трёх кнопок?
Опять же, в игре нет туториала. Да, она примитивна, но туториал — это одно из обязательных требований издателей к таким играм. Еще одно — паузу, которой здесь тоже нет. Зато есть стирание рекорда без подтверждения. Графика из ресурс-пака, кстати.
Игровой процесс. При попытке управлять мышью главный герой бежит к курсору, что неинтуитивно на круге-то, и дергается на месте, когда добегает до курсора. А еще становится неуязвим к противникам, уж не представляю, какие там в коде костыли.

Вместо вердикта.
Эта статья написана в духе «я пытался сделать так-то, у меня не получилось, поэтому не пытайтесь и вы». Хотя и написана хорошо, какое-то доверие даже внушает, пока на «игры» автора не взглянешь.
Судя по вашей аналитике вы уже сделали несколько игр, есть удачные?
Увы, в своё время я не наткнулся на такую статью, поэтому разработка моих проектов затянулась. Надеюсь в ближайший год-два один из них увидит свет.
Хотя году в 2015-м, когда пошла мода на такие простые html5-игры я пытался продать раннер, но тщетно. На fgl (сайт-аукцион для flash и html5) до продажи не дошло, а нагло рассылать предложение на почты сайтов мне не хватило настойчивости.
Я давно уже забил на мотивирующие статьи и просто делаю игры.
Вычитал в одном форуме про «метод прогрессивного джипега в разработке игр». Суть вкратце: на каждой итерации разработки игра должна быть полностью проходима и закончена. Метод вполне рабочий. Только нужно сразу иметь целостное видение игры перед началом разработки. Тогда всё идёт как по маслу.
Звучит неплохо, но добавит сложностей. В готовый проект зачастую сложнее впихнуть какой-то элемент, чем реализовать его в процессе разработки. Ситуативно, конечно, но все же.
4 года назад начал делать fintank.ru (нужен пинг 0...50ms). Проект рассматриваю как возможность иногда вечерами поупарываться с алгоритмами. Сервак на C++, клиент на голимом JS. Дизайн, геймплей, цели, игровой баланс — не, не слышал. Мозг вообще на эту тему не работает.

Основная идея игры была в том, что игроки могут разрушить или построить любой кирпичик мира и все изменения перманентны (навсегда, пока другой их не выпилит). Ну и, типа, можно строить себе будку и ныкать в неё ништяки. Но вот с балансом беда полная. При увеличении цены стройки накопить себе на хату почти нереально, а при снижении — засирают карту бетоном)
Sign up to leave a comment.

Articles