Моё перерождение в командира слизи
Хей-хей, ребята, это снова я, Значки.
И я снова хочу попробовать сделать хентайную игру, с крутой рпг-составляющей, генерацией мира, добычей ресурсов, исследованиями, производственной цепочкой и строительством базы.
Если получится, конечно!
Разработку решил разделить на циклы по три недели, которые поочерёдно будут включать в себя рисование, написание программного кода и сочинение каких-нибудь композиций — чтобы поменьше уставать из-за работы над одним и тем же.
Отчёты по проделываемой работе будут находиться где-то в комментариях.
Посмотрим, сколько я продержусь и чего смогу сделать на этот раз ^__--
- 02 января 2020, 19:40
- 07
А почему на часах 21 час всего?
Может ЧУТЬ-ЧУТЬ попроще? :yak:
Ещё три часа на работу и сон, лол.
Но ведь это дни из 3 недель (21 суток) всего, не? Просто выглядит совсем уж как часы. У тебя в сутках целых 3 часов не хватает - неудивительно что не успеваешь!
Хорошо кому-то!
Интересно, а как у тебя с рисованием? Получится делать, не перерисовывая?
Главное, чтобы получилось делать.
Остальное со временем и опытом приложится.
Ты хотел сделать пятиминутную игру. Начни с этого.
Нет, ты хочешь сыграть в такую игру, а не сделать.
Одному человеку даже просто стратегию делать долго, а ты опять хочешь убийцу "героев" сделать.
Мало. Надо 8-10 часов.
Просто посчитай. 5+3+3 = 11
5+8+8 = 21
что как бы в 2 раза больше.
Я бы посоветовал сделать так. Начни с выходных. За 20 часов сделай основу (прототип, как на "КОД") который уже будет работать ("вглубь"). И больше ничего не добавляй. А потом, по будням делай игру "вширь", добавляя отдельные спрайты, уровни, звуки. Делай вширь на основе пока не надоест. Как надоест - тест-релиз на гамине.
Потом, если еще останется желание - можешь допильнуть немного, исправить баги и косяки.
Еще 1 час в день - мало, надо хотя бы 2. Когда садишься что-то делать, у тебя уйдет 10-20 минут только на то чтобы "включиться" в работу. Чтобы вспомнить на чем ты остановился, что хотел дальше делать, открыть все программы и разогнаться. Потом, в конце надо еще 10-20 минут чтобы "дописать до точки", оставить игру в стабильном, а ресурсы в допиленном состоянии, а не бросать прямо посередине написания функции или рисования спрайта.
В итоге, с одним часом, только на то чтобы включиться-выключиться из работы у тебя будет уходить 10-30 минут.
Лучше 1 раз сесть на 3 часа, чем сесть 3 раза по 1 часу.
У меня есть дополнение насчет дописания до точки. Чисто собственный опыт, но оч хочется поделиться.
Так вот.
Полностью плюсую, что бросать посреди написания кода вообще не вариант, но вот недорисованные спрайты, как мне кажется, наоборот могли бы помочь побыстрее включиться в работу. Тогда хотя бы не надо думать, с чего начать что-то делать, потому что "ага, а вот у меня тут графоний недорисован". Дотыкал пискельную титьку, а дальше как по маслу.
Лучше списки с чекбоксами с вечера на следующий день составлять XDD
Пожалуй ты прав. Недорисованный спрайт ничего не сломает.
Важнее не сколько ты времени будешь тратить, а сколько за это время успеешь сделать.
Нужно понимать что вначале у тебя все будет медленно. Поэтому всегда надо начинать с очень простой игры (я с крестиков-ноликов начинал). Со временем, с набором опыта, прогаться и рисоваться будет быстрее и за то же время ты будешь делать больше.
Если в прошлый раз ничего не вышло, значит нужно понижать планку (в 2-3 раза), а не повышать.
каковы результаты твоей стратегии и гарантии что данная стратегия даст нужный результат?
Пересказываю свой опыт. Чтобы не наступать на мои грабли.
У меня у самого куча недоделанных прототипов. Основная причина - выяснялось что я не очень-то хочу их делать. Либо они сразу получались неинтересные.
и вдруг ты толкаешь с граблей в яму?
В яме хотя бы грабель нету.
У тебя просто нет пиксельный титек
Еще по поводу свободного времени. Если ты каждый день сидишь и думаешь "а чем бы мне заняться?", значит оно у тебя есть. Если ты так не думаешь, значит у тебя его нет и тебе придется что-то выкидывать чтобы его освободить.
А со сном лучше не шутить, надо спать не меньше 8 часов.
Сонный и больной человек не может выполнять сложную для ума работу. Прогать вообще грех - можно сделать только хуже, написать код неправильно, насажать багов, которые потом еще дольше будешь исправлять.
Еще лучше никогда не спешить. Когда ты торопишься, ты экономишь только время, но сильно проигрывашь в качестве. Потом тебе придется потратить еще больше времени чтобы все исправить и переделать в нужное состояние. В итоге в сумме ты потратишь больше времени и сил, чем если бы изначально делал это не торопясь.
Удачи с новым начинанием! Пусть в этот раз получится. Главное - не останавливаться. :)
Цикл 1, день 1.
Чтобы на 10-й день иметь возможность что-то выводить на экран, начал потихонечку делать тайлы, и первыми среди них - стены.
Чтобы более не мучиться с 30-ю вариантами, решил, что буду собирать стены программно из кусочков, по такому принципу:
В качестве основы взял стены из RimWorld, растянув блоки таким образом, чтобы они подходили тем габаритам спрайтов персонажей, с которыми мне хочется работать:
... и затем малёх перерисовал спрайты, сделав их более контрастными при большом удалении и более детализированными при приближении, благо формат 94х94px позволяет:
Также мне хочется в будущем программно как-то накладывать цвет на стеночки, чтобы можно было таким образом либо дать широкий выбор материалов для строительства, либо замутить что-то интересное с освещением:
+ плиточка пола
Не пиши отчеты так часто. Раз в неделю - достаточно.
Лучше трать время на игру, а не отчеты.
У-у-у.
Я фидбека хочу.
Фидбекить нужно игру, а не процесс деланья игры.
*фидбежить, я полагаю.
А, не, фидбечить.
Именно такое слово использует Alex007 на стримах по второму старкрафту, когда рассказывает про взаимодействие темпларов и различных вражеских юнитов с энергией.
Я кстати тоже всё планирую сделать эротическую игру с такими же примерно составляющими
и симуляцией мира с календарём и сменой сезона, но всё также теряется мотивация и начинаю делать что-то другое, а ещё постоянно конкурсы отвлекают, где нужно делать новую игру.)
Вначале хотел пикселявый арт:
Потом пробовал обычный арт, но дальше работа не уходила, всё что-то мешает,
например подсмотрев идеи, захотелось сделать свою команду из нескольких человек,
пришлось бы перелопачивать много всего:
ЗЫ Удачи с новым начинанием, Разери! Может глядя на тебя я тоже себя замотивирую, или нет, как обычно)
Цикл 1, день 4.
Вирм
6-й уровень, ветка ламий
Я, типа, нормально отношусь к совету делать побольше контента перед публикацией новостей, но если я буду отписываться редко, то мне будет сложновато считать дни + мне правда хочется показать, что я делаю.
Так что, представляю вашему вниманию, плоды моих недавних усилий:
Эволюционное древо слизи
(пришлось давать ссылку на картинку вот так, поскольку встроенная вставка изображений
резала разрешение, как шакал)
Я предполагаю, что в моей игре должна быть возможность прокачивать подчинённых юнитов, делая их действительно отличающимися и ценными, поэтому я принялся мутить эволюционное древо для самого базового и слабого монстра, который будет в начале доступен игроку - малой слизи.
Вначале с рисовкой я халявил (что хорошо видно по ветке моллюсков и несчастному доппельгангеру), но затем смекнул, что качественные наброски будет очень легко превращать в финальные спрайты, поэтому дальше начал напрягаться.
На эволюционном древе остались ещё пустые места: некоторые из них появились, чтобы сделать более плавным и логичным (по внешнему виду или способностям) эволюционный переход + присутствие некоторых высокоуровневых монстров нужно, чтобы сделать соответствующие ветки развития впечатляющими и равноценными остальным.
Плюс к тому, мне хотелось бы ещё замутить тёмную ветку развития, с мимиками, суккубами и тёмными колдунами.
Остаток рисовательного времени в этом цикле я посвящу поиску всяких клёвых образов и поз для монстров, рисованию оставшихся набросков, а также постепенному переводу набросков в финальные спрайты (полагаю, одни спрайт на один новый набросок).
С большим интересом готов воспринять возможные названия для "продвинутой дриады", "продвинутой алрауны" и для оставшихся чувих из ветки хилеров, а также призываю пофантазировать на тему того, какие фантастические монстры нормально смотрелись бы в тёмной ветке развития.
Картинка прикольна, напомнила карточные игры!
Идея: а может, напечатать все спрайты и сделать карточную игру? Тогда можно не музицировать и не программировать, и хоть рпг, хоть рогалик, хоть несыть по жанру.
Карточные игры это круто, я сам думал над такой идеей,
только так и не придумал боёвку ибо сложно баланс рассчитать, всегда получается, что какие-то карты лучше других, и просто не используешь/не берёшь слабые) В идеале вот бы систему, где все карты хороши по своему, но это очень сложно делать
Я считаю, что проще начать с PvE коопа, если уж делать многопользовательскую игру. По многим причинам.
Ну я про однопользовательскую и имел ввиду PvE, но да ладно, просто мультиплеер я вообще не уверен, что смогу когда-нибудь осилить, ибо не особо программист и не понимаю во всех этих тонкостях.
Но в картах не нужно программирование, а в PvE не нужен прям идеальный баланс)
Ms-Dos давно еще делал карточную игру, не знаю, чем у него там дело закончилось. Скорее всего, ничем.
Я таких (всех) слов не знаю, поэтому ХЗ чем бы помог, но схема супер. Вполне хороший концепт.
Эволюционное дерево прикольное) мне нравится, типа покемонов и ещё немного напоминает Dragon Quest
Мне кажется, лучше сделать больше базовых юнитов, и сделать для каждого более простое древо развития. Большая проблема с большим деревом в том, что игроку будет очень сложно ориентироваться, куда направлять эволюцию изначально, чтобы получить желаемую конечную роль. Например, каким образом мне знать, что если я хочу танка, то мне надо развивать слайма в медузу, специализирующуюся на параличе, который не имеет никакого отношения к танкованию? Или каким образом "яд" внезапно превращается в "невидимость+криты"? Даже если всё дерево будет доступно сразу, игроку надо будет пересмотреть все 30 (или сколько у тебя там) юнитов, пытаясь найти нужного. А уж если у тебя будет несколько базовых юнитов с такими деревьями...
Еще проблема может быть в том, что пока ты хотя бы немного прокачаешь юнита в правильную ветку, то у тебя попросту не будет юнита, выполняющего соответствующую роль. То есть, чтобы получить хотя бы базового хила, тебе нужно будет прокачать одну слизь четыре раза, а чтобы получить хотя бы какого-то танка - 5 раз.
Так что, как по мне, логичней было бы иметь несколько базовых юнитов, имеющих более узкие (всё еще общие) специальности, которые будут логично перетекать в следующие (например, физ-юнит начинает с атаки, но развивается в физ-урон/танкование, маг поддержки начинает с хила, но развивается в хил/бафы, маг атаки начинает с маг-атаки, но развивается в атаку/дебафы/контроль и т.д.). Игроку будет сразу понятно, что не стоит брать физовика, если хочешь хила. Посмотри в сторону Disciples 2, там это довольно хорошо проработано.
Хорошая идея, в процессе балансировки геймплея (если до него доживу) подумаю над этим.
Что касается моих рисовашек прямо сейчас, то наброски и спрайты в любом случае лишними не будут (даже если что-то не будет в итоге доступно игроку - переедет в раздел противников), так что... пока просто продолжаю.
Но я мысль услышал и запомнил, да.
Лол, смотрите, какую схемку в интернете нашёл:
... и если достаточно заинтригованы, чтобы перейти на первоисточник и посмотреть, кто и почему так упарывается, то ВОТ.
Вполне ничего себе заготовка для какой-нибудь фантастической игры, кстати.
Похоже на Уголь!
А? Про что речь?
Я про свою поделку
Шото сложно, но зато можно упороться и своё что-то придумать слишком задротное, не отталкиваясь от чужих правил, чтобы была своя псевдонаука в своей игре :3
Цикл 1, день 6.
Заполнил пустующие места в ветках ламий и кракенов:
Нормально перерисовал слайма для последующей покраски:
И уже начал кой-чего красить:
Хотя и не особо уверен насчёт "малого слайма" - если голова/руки и самый низ ещё ничего, то туловище какое-то пластмассовое.
Следствие того, что начал красить без нормально проработанного наброска --_--
Палитру при рисовании слаймов хочу постепенно менять, кстати.
Благодаря этому можно будет сделать норм цветовой переход: на втором уровне - к тине, на третьем уровне - к моллюскам и медузе, на четвёртом - к ундине.
А ещё я подготовил спрайтики дверей, так что самая-пресамая основа для развлечений с генерацией подземелья у меня уже будет:
Всем монстро-девочек!
Злая Природная Вода из ВанПанчМена)
Персонаж неплохо выглядит, а кирпичи как-то странно... не могу понять что именно не нравится:
то ли слишком большое разрешение (а детализация не высокая), то ли цветовая гамма (белый цвет по краям).
Вначале на секунду показалось будто белый цвет это артефакты от слишком пережатого JPG.
Как вариант, цветовую гамму можно стырить из других скриншотов или игр, где кажется красивее,
я так обычно делаю, например с Зельды или других игр, лучше ярко-белый цвет не использовать для
подземелий, и палитру лучше облагородить не серыми цветами, а немного зелёным, синим или слегка красным оттенком:
Спасибо за скринцы, что-нибудь оттуда вытащу.
Но я же, это... и так собирался стеночки в разные цвета красить.
Цикл 1, день 10.
Немного провтыкал с началом периода программирования, но (вроде бы) нормально покрасил первые четыре спрайта из главной эволюционной линейки слизьки.
Особенно горжусь кистями рук старшей слизи (самая правая).
Процесс их рисования остался за кадром, но это было что-то из топ-10 эпичных аниме-битв, ребята.
Завтра начну трогать юнити и C#.
Не знаю уж, что там наковыряю, но постараюсь успеть за следующие несколько дней хотя бы спрайтик какой на экран научиться выводить, лол.
Прикольные спрайты. Растешь!
Спрайты да. C# - про игру можно забыть, будешь месяцами читать про итераторы и короутины. :yak: Ты вот Питон (или то был Луа? я забыл) пробовал, и то там чё-т решил не продолжать, а тут берёшь полновесный не-скриптовый язык общего назначения. Нуууу... такое.
Самые правые кисти и вправду хороши.
Это вопрос мне или Разери?
Я Луа пробовал, но не продолжаю не из-за Луа.
Разери тоже пробовал Луа. Но там как бы дело не в самом Луа, я полагаю, а в том, что Лёв, как фреймворк, предоставляет самый базовый минимум, и нужно писать велосипеды (ну или брать готовые решения, что тоже сопряжено с некоторыми сложностями, возможно)
В Юнити может быть всё иначе - я не пробовал, не знаю.
Я тоже пока что не знаю, но через какое-то время у меня хотя бы будет более точная информация и выбор.
ну хз чо там месяцами читать про итераторы и корутины, тем более что в гугле комментированный код для юньки есть практически на любой возможный случай.
один раз понять, всю жизнь пользоваться
Мне щас бы опять перейти на личности и спервадобейся (типа, если там нечего читать, где вот конкретно ТВОИ игры более чем конкурсного формата?), но от этого устал уже я сам, и обсуждать это просто не буду.
лол. в стиме
Это я и назвал конкурсным форматом - на коленке и по фану делается легко. Я даже не о продажах, а просто о интересе и объёме геймплея. Раз уж на Стиме, то там сразу видно и интерес в разрезе публики, а не только мнение одного анона с одного Гамина.
ваще хз как ты притянул сюда антирес(Greenlight;Price: $8.99;Owners: < 20,000;Followers:55) и объем геймплея - раз уж мы говорим о коде. У меня есть траблы с геймплеем, с рисунками с модельками, с левелдизайном, но вот проблем с кодом, тем более неразрешимых проблем - ваще не встречал.
Любая проблема с кодом на юньке в течение пары часов разрешается мануалами, гитхабом и плагинами. Полностью разрушаемое окружение без просадок - ня, шикарный UI - вот он, шейдеры, сетевой код, встроенная реклама - из коробки. раннер в котором мир заранее генерируется на основе битов музыкального трека и реагирует на частоту и амплитуду нот через полгода баловства в пограмирование - achievement unlocked. ну и докинем туда сабстенс, мекаминм, синемашин, пробилдер, навмеш - и может так случится что и несложные итераторы и корутины даже не понадобятся
предсказание интереса публики к игре по возможностям языка - это какой-то оч сильное колдунство
Вот уж компонент игры таки да.
Не показатель для рекомендаций всем подряд. Достигаторство не делает игр, а делает только достижения. Увы, у людей господствует именно такая логика, поэтому почти все годами "делают" "игры" и "советуют" "инструменты". Вообще в инди-геймдеве мира, я не про Гамин. Никому не интересно брать и херачить как чёрт, как это по-трушному в девяностые делали. Нет, не в пост-СССР (и даже частично не-пост), а там, где делали игры в это же время.
До этой мысли нужно 2-3 фазовых перехода пройти от моих высказываний.
ну это достигаторство которое полностью зависит от удобства кодинга
Это не всегда кодинг, а в идеале это должен быть вообще не кодинг, но мы всё ещё в 2020.
Я кстати сейчас тоже переучиваюсь на C# в юнити, свой код пишу так чтобы не было вообще корутин,
я просто их не люблю, так что можно и без корутин писать. Всё время обычными переменными мерю, а для диалогов и других задержек пишу специальный внутренний язык, точнее переписываю с JS на С#, чтобы оно работало без компилятора, а то компилятор в юнити сильно раздражает, чем больше скриптов, тем больше паузы между компиляцией, даже если просто в код добавил коммент или одну букву.
В целом соглашусь, что C# это слишком жёстко для начала.
PS выглядит скриптер как обычный текст) а я его разбиваю через space и return символы,
а потом с помощью switch ищу нужную функцию, только начал движок, он ещё такой чистый,
но потом опять будет грязь и куча мусорных скриптов и файлов, которые забыл зачем сделал,
не знаю как вести свой проект чистым, видимо нужно чтобы инструментарий был готов, а в юнити есть много вещей, которые нужно либо самому делать, либо ассеты искать, и потом получается свалка((
Сабж учится за три часа, и нужен раз в полмесяца.
А для ГМа учится за 0 часов и нужен раз в никогда.
???
Это только один пример, таких вещей много.
Вот кстати Game Maker, мне кажется отличный инструмент для Разери.
Он полегче в разы будет, чем юнити.
Меньше придётся писать дополнительных скриптов.
Я не имею ничего против Game Maker, как впрочем и других инструментов, но мне кажется нет легких или сложных движков если их рассматривать в таком ключе. Есть движки и инструменты с которыми ты хорошо знаком, а есть - нет. Поэтому даже если Game Maker и кажется простым, то если человек не имеет опыта по его использованию, он возьмет то, что ему ближе. Я не говорю конкретно о raseri. Я говорю вообще :)))) Когда мы рассуждаем на такие темы, то нам кажется, но реальность такова, что все это лишь домыслы не имеющие ничего общего с реальностью :))))) Сколько придется писать будет зависеть от конкретной задачи и тех идей, которые хочется воплотить. Иногда хочется сделать именно то, чего нет и еще не было. Поэтому времени на это на любом движке может уйти столько, что уже не имеет значения какой движок выбран.
Насколько я понял Разери ещё не имел опыта с C# и Юнити, но если ошибаюсь, то тогда да, может быть Юнити будет проще, если есть уже опыт с ним, но с нуля легче освоить будет конструкторо-подобный движок, типа: Game Maker или Construct 2 (3-я часть с подпиской, и не особо отличается по технологиям)
Ещё Multimedia Fusion, классический конструктор.
По моему глубокому убеждению и исходя, что тут писалось про юнити - это далеко не самый лучший инструмент. Компиляция проекта например не должна происходить долго. Если это происходит - это повод задуматься над альтернативами. Либо вы что-то не так делаете. Например в среде Delphi проект разбивается на модули и скомпилированные модули естественно не компилируются, что сильно сокращает общее время компиляции - компилируются только те модули, в которых было сделано изменение. Если в юнити таких простых вещей нет или они сделаны абы как, либо чтобы понять как это использовать надо во что-то там вникать - значит система на самом деле недоделаная и недружелюбная. Я удивляюсь как многие на нем мучаются пытаясь что-то сделать. Не мучайте себя, выберите другую систему. Есть много движков и систем программирования, где все это делается автоматически и не требует вообще никаких познаний.
То что юнити разрекламирован это понятно, но лучше он от этого не становится. Я понимаю тех кто уже с ним долго работает или вынужден это делать. Но остальные то - зачем вы с ним мучаетесь ?
Конструкторы я бы тоже не советовал если нужно сделать какой-то глубокий проект, а не простенький прототип или на уровне того. Конструкторы - на то они и конструкторы.
А вот что касается функционала визуальной новеллы, то я например для своего проекта ria pc game все делал сам и это заняло на самом деле не так уж много времени. Было бы желание.
Но я конечно вас понимаю, если уж ввязался в юнити, то деваться некуда. Но все-таки. Если вы изучали js и использовали его в юнити может тогда взять node.js ? Или вообще писать браузерную версию игры на html 5 а потом скомпилировать в исполнимый файл. Тогда ваши js скрипты потребуют не так много изменений или по крайней мере это будет проще реализовать чем пытаться переписать на c# параллельно делая рефакторинг - т. е. улучшая старый код (рефакторинг это по большей части улучшения кода - изменение названий переменных чтобы они лучше читались, улучшение читабельности кода и т. п.)
Я конечно изложил свою точку зрения и не навязываю никому и ничего. Просто больно видеть как вы мучаетесь с инструментами которые на самом деле не помогают делать игру, а мешают.
Нужно брать не то что первое попалось под руку, а немножко использовать научный поход. Иначе вместо создания игр вы будете заниматься мазохизмом.
Уж наверное разработчики таких сред как Visual Studio и Delphi имеют больше опыта, чем те кто делал unity 3d или Game Maker. Game maker сделан кстати на delphi. А unity 3d надо полагать на c#, хотя изначально он писался на c++ когда c# еще не было и в те времена он еще был более-менее подъемным движком. Во что это сейчас превратилось вы видите сами. И многие пользуются старыми его версиями. О чем это говорит ? Что движок не прогрессирует, а регрессирует. Не помогает разработке, а мешает. Так что надо делать выводы и искать альтернативы.
Ну а те кто не видит альтернатив конечно пользуйтесь наздоровье, я ничего против этого движка не имею. Каждому свое.
Опыта в разработке игр? Ну, это как-то вряд ли.
Только старый:
В 2005 C# уже 3 года как был доступен для пользования разработчиками, и уже 12 лет как был придуман.
За остальное даю меч.
Опыта в разработке приложений конечно же. Не игр. Программирование, а не геймдизайн конечно. Для игры неважно криво она сделана или нет. Игрокам на это наплевать. Главное чтобы игра была интересной и захватывающей. Игра может при этом бажить и вылетать. Одно с другим никак не связано с точки зрения игроков. Но вот разработчик который мучается с такой кривой средой разработки однозначно потратит больше усилий. Только в этом ключе я имел в виду. Геймдизайн и прочие фишки создания игр я здесь не подразумевал.
Просто любой инструмент рассчитан на комп определенной мощности. Юнити новых версий будет тормозить на старом компе, дельфи и студия новых версий тоже. UE4 вот вообще почти топового железа требует.
Поэтому да, со слабым компом приоритеты в выборе движка\среды другие. А те у кого не тормозит смотрят с непониманием - какое им дело все скрипты перекомпилируются или не все если это занимает полсекунды.
Это точно. Но важно чтобы и железо и софт работали хорошо. И опыт разработки тоже играет роль. Если опыта нет, железо старое, софт глючит и тормозит да его еще и применяют не по назначению, то создание игры в этом случае превратится в ад. Может быть когда игры только только начинали делать, например тот же Периметр, в далеком 2000 - 2001 годах, тогда проблема стояла остро. Софт нужно было писать свой (движок), железо нужно было как можно более новое и мощное. Но сейчас с тех пор появилось много всего - и софта и железа, так что и выбор есть и необязательно использовать прям самое новое и свежее, тем более в новом могут быть ошибки, да и тормозит оно всегда больше. Плюс надо его еще освоить. А вот не очень новое и уже проверенное временем, вышедшее хотя бы 1-2 или чуть больше лет назад - смысл осваивать есть. Сейчас уже нет смысла гнаться за новинками и пытаться быть в тренде разработки с использованием самых современных инструментов. Инди разработчику это просто не нужно, да и не успеть. Хотя наверное и крупные студии не будут гнаться за новизной. Это большие риски. Мы живем сейчас в период, когда появились новые приоритеты - направленные на лучшее использование того, что уже проверено временем. А то что было разрекламировано и широко внедрялось не всегда показывает качество и проверку временем. Так что надо ориентироваться не только на популярность.
В этом плане ГМ кстати сильно сдал - 8.1 компилировался намного быстрее, а Студия 1 - намного медленнее, хотя функции были примерно те же самые. В Студии 2 наконец сделали компиляцию только того что изменилось, а не всего подряд, но это всё ещё медленней чем 8.1 из 2011 года, а интерфейс при этом где-то улучшили, где-то ухудшили. Хотя так почти у всех сред разработки что я видел - делать что-то лучше, не делая при этом хоть что-то другое хуже, тупо трудно.
Согласен. Идеального не существует. Как нового, так и старого.
Я может немного не понял суть, но я как раз наоборот рекомендую Разери перейти на что-то попроще, чем юнька. Хотя в остальном согласен, сам я на юнити, только потому-что она бесплатная да и уже давно, привык, если бы Game Maker был бы с такой же моделью продаж, то я бы давно освоил GM, жаль что я не купил Game Maker раньше, пока в кредитах не погрязла наша семья.
Ещё смотрю в направлении годот, но там пока неизвестно когда документацию освою и уроки.
Мне самому как художнику хочется поменьше писать кода и побольше заниматься разработкой самой игры,
то есть скрипты уровней, скрипты ситуаций в игре, диалоги, и сами уровни/локации.
Все правильно. Но вот насчет простоты наверное совет (с моей точки зрения) не совсем правильный. Чем меньше возможностей у движка или среды разработки, то учитывая то, что возможности никогда не используются на 100%, будет очень сложно достичь желаемого на движке или в среде разработки имеющей ограниченные возможности. Чем среда разработки проще (или движок), тем возможностей там меньше. Значит и игру можно будет сделать только самую простейшую. А проста это хуже воровства. Тем более в геймдеве. Простые игры это по сути клоны других простых игр - этого барахла пруд пруди. Поэтому совет не совсем правильный. Чем сложнее игра, тем шансы сделать её качественной выше. Понятно что сделать сложную игру на порядок сложнее чем простую. Но простую сделать интересной и качественной шансы еще меньше. Вот к примеру простая игра: Flappy Bird. Ну и что с ней делать ? :)))) А вот взять Периметр: Геометрия войны, которую делали более 4 лет ? Да сравнение конечно несопоставимое и результат заранее неочевиден. Но 100% или где-то 99,9% что разработчик как минимум после создания Периметра почуствовал что он хоть какую-то часть своих лучших идей смог воплотить. А что имеем с разработчиком Flappy Bird ? Да ничего. Он не то что доволен собой и своей игрой, а наоборот - плюется от неё, потому что и игра уже опротивела и то что его хвалят явно незаслуженно - тоже. Популярность и простота не синонимы качества. Как и критика, которая бывает разной. Например Периметр многие считают не то чтобы посредственной игрой, но не такой, какой она должна была быть. Но Периметр это лучшая игра от Российских разработчиков за последние 15 лет. Я имею в виду в жанре RTS. Конечно были и еще ряд проектов, но Периметр явно выделяется среди них. И это главным образом потому что игра сложна в реализации. Ну а представьте что бы было если бы разработчики решили реализовать свои идеи в виде простой игры ...
А что имеется ввиду под простотой? Flappy Bird с Периметром сравнить - это конечно жесть)
Я сам не люблю слишком простые игры, только глубокие по гемплею.
На Game Maker и Construct 2 при особой усидчивости можно сделать хоть Скайрим, хоть Fallout в 2D пиксельарте. Правда придется совместить с некоторыми элементами Зельды:
1) убрав например сохранение всех вещей брошенных на землю
2) не делать куча объектов контейнерами
3) сделать один контейнер у себя дома, чтоб БД не перегружать (как в Rune Factory)
4) не делать проверку AI неписей, которых не видно на экране
5) не сохранять состояния локаций на момент выхода из неё как в той же Кастлевании.
Но глубокую игру всё ещё можно создать
Также при должной находчивости на тех же конструкторах можно собрать свой 2D пиксельный Mount n Blade, убрав большие Базы Данных. И тут тоже никакого "воровства", глубокий гемплей можно сохранить, просто придётся отказаться от огромного количества переменных в этих Б.Д., вместо 100 не уникальных городов можно иметь 5 уникальных городов на всей глобальной карте, и вместо 10000 генералов, по карте вполне могут ходить 10 глобальных генералов и остальные локальные, те кто быстро исчезнут и сгенерируются пока видно на экране, как в той же GTA, например бандиты или крестьяне.
PS я сам люблю глубокие игры, но простые в реализации, в том плане что простота тут является помощником в урезании ненужного, но оставить нужные глубокие элементы, как например я очень хочу в своих играх сделать прохождение игр различными путями, и это также возможно сделать и с конструкторами
Проблема не в том, что нельзя сделать, а в том, что смысла в этом мало. Больше мучений и переоценки сложности проекта: сделаю за неделю, а на самом деле и за год не сделать. :))) Проблема в том, что когда смотришь игры со стороны - ты не знаешь всех деталей и сложностей процесса. Вот когда начнешь делать - тогда увидишь, что это не так легко. Впрочем зачем я это вам говорю. Вы это и сами прекрасно понимаете. Другой вопрос, что да - всегда хочется верить что сможешь. Потому и пытаешься. Плохого в этом ничего нет, нужно пробовать себя во всем. Правда не всегда это время проходит с пользой для проекта. Например брошенные проекты уже не принесут наверное никакой пользы, разве что опыта прибавится.
На Construct2 скайрим ты точно не сделаешь, уж поверь. На GM точно не. И тут даже усидчивость не поможет...
Я думаю имеется в виду 2д-версия - "(хоть Скайрим, хоть Fallout) в 2D пиксельарте" а не "хоть Скайрим, хоть (Fallout в 2D пиксельарте)".
Это точно не будут полноценные игры, скорее пародии минут на 5-10 геймплея...
Почему?
чисто ради информации... 3-4 года ушло на создание игры скайрим, команда которой составляла 100 человек или около того, второе - это функциональное ограничение что первого, что второго движка. Если говорить о Конструкт 2, то это скорее поделка для детей, нежели продукт для создания чего-то серьезного...
Зачем Skyrim, если есть Dwarf Fortress?
Не играл пока ни в то, ни в другое.
Рассуждать о достоинствах игр в которые никогда не играл. Ну это знаете ли странное занятие ;) Это непостижимая логика. Чем для вас хороши или плохи такие игры, если вы в них никогда не играли и вряд ли будете ? Ну я конечно понимаю, я сам не любитель всяческих ММО РПГ и иже с ними :)))) Куда привычнее классические однопользовательские компании. Сидишь и спокойно без нервов играешь. Вот никогда не мог понять людей которые в такие игры не играют, а как будто на работу ходят. Впрочем каждому свое. Кто-то любит классику, а кто-то онлайн.
И так видно, что DF более сложная, чем S, игра, притом инди. Для AAA характерны повышенная детализация и реализм графики, которые сильно сковывают разработку геймплейной составляющей (имею в виду не столько в творческом плане, сколько в реализации, например, сколько можно персонажей одновременно показать на экране и т.п.).
Мой вопрос в контексте разработки, а не играния. Играть понятно, что лучше в обе, если есть на это время.
Кстати да, чем более стилизованный графоний, тем легче делать игру.
Можно эти усилия вложить на другие вещи, а не полировка графона.
Очень много сил вкладывается на 3D и реалистичные вещи (чтобы персонаж ставил ноги правильно, мимика, анимация и прочие мелочи сжирающие ресурсы разработчиков), если вырезать эти вещи, то и игру в разы станет легче делать.
Я тут сейчас экспериментирую в Tic80, хочу соединить JRPG с Kenshi и Bitsy гемплеем, чем проще графон и физика, тем меньше головняка)
Dwarf Fortress выглядит по описанию эпично, но в самой игре я мало что понял.
Как-то не зацепило, наверное мне нужен более казуальный интерфейс, ну хотя бы как в Mount n Blade, где всё достаточно легко сразу понимаешь, кроме некоторых нюансов)
Казуальная версия DF это Rimworld. DF по сути очень похож, но только мир трехмерный (можно строить катакомбы в 3д) и живой (приходящие чуваки и события не генерируются по мере обнаружения игроком а существуют и взаимодействуют без него). Правда и баланса в DF нет, да и само слово баланс к нему не очень применимо - DF это генератор офигительных историй, а не игра в обычном понимании.
---
а, ну и в DF нет прямого управления, поэтому если ты видишь как дворфы тупят, то не можешь просто приказать пойти туда и взять то, а должен проявлять "смекалочку".
Меня даже Rimworld напугал. Там показалось слишком много всего и сразу в интерфейсе.
Хотя я люблю залипательные игры типа Mount n Blade и Kenshi, но это походу на порядок сложнее, чтоб разобраться во всём.
Может когда-нибудь я попробую разобраться с этим.
Ванильный Rimworld это развлечение для маленьких котят.
Самая вкуснота начинается с глобальным HSK-модом.
https://vk.com/hardcore_sk
Копировать легче чем быть первопроходцем. А сколько из этих людей не нужно в двухмерных играх, в отличие от трёхмерных - это ещё надо разобраться. Моделей-то в двухмерной игре нет, геометрия на целое измерение проще. И так далее.
А главное непонятно при чём тут GM. Типа, на UE4 или Юнити, Алекс мог бы сделать свой Скайрим?
Ну я просто планирую (уже где-то 4 года проектирую движок) сделать 2D игру с открытым миром, взяв концепцию Скайрима и скрестив в Зельдой, то есть буду делать только то что смогу, то что не осилю буду упрощать. Это конечно не будет тем самым Скайримом, я просто возьму тот функционал, что смогу сделать и буду оперировать им, а что не смогу, то как бы даже и не буду пытаться) тот же ИИ неписей и врагов я не планирую делать, ИИ у меня будет из игр Зельды или ещё проще.
Постепенно я понял что мог бы всё сделать и проще. И теперь переписываю движок на C# с оптимизацией и упрощением, заодно прикинул, что почти всё это можно сделать и в конструкторе, надеюсь когда-нибудь доберусь до этого эксперимента)
Почему нельзя сделать пиксельную игру на 5-10 часов? Что мешает?
Пародии, ну в принципе тоже неплохо, грамотные пародии до сих пор имеют спрос)
Я не имею ввиду Скайрим как он есть, я имею ввиду стилизованный и упрощённый, ближе к Зельде, но со свободой мира, где не надо лезть в подземелья, если не хочешь, где можешь в любой город сразу приехать. Сложный AI врагов и неписей, базы данных, 3D графику и прочие ништяки мы конечно отметаем сразу)
Ворвусь.
А зачем? Мало места на экране будет? Возможно. Но технически это реализуется в ГМ нормально (два раза делал)
2-3 похоже про сундуки с предметами? Думаю тоже делается в ГМ (в Бумажном, правда там 1 предмет. А в игре Дрейка Кристальное - там вообще мноха предметов).
спорное решение для игр с открытым миром, как по мне.
А как сложно сохранение делать? Лично я не смогу такую сложную БД делать и решил для себя обнулять уровни как в Зельде или Кастлевании.
Ну в целом есть минусы. Но если к этой игре относиться как к Зельде, в которой можно не проходить подземелья (по желанию), или можно идти сразу в большинство мест (пока сильные враги не убьют), то не так плохо, в принципе.
Ну и ещё добавить логичный ландшафт, в большинстве 2D игр по Зельде нет логичного ландшафта,
который проходится логичными "инструментами":
1) вода - просто создать или купить лодку, или научиться плавать, а не подбирать особый предмет
(это уже элемент открытого мира, где ты можешь инструмент получить когда сам решишь, а не по сценарию)
2) пропасть - варианты прохождения: воздушный шар, летающие расы, магия полёта
3) болото - просто идти аккуратно, иначе можно увязнуть в трясине (быть внимательным, инструменты не нужны)
4) дорога - в Зельдах редко есть логичная дорога по которой курсируют торговцы, путники и стража,
это есть в открытых мирах, и это тоже можно добавить в игру, это тоже окрасит игру с открытыми миром, можно генерировать неписей по типу GTA (в зависимости от ландшафта и времени суток генерируются свои неписи, которые создают иллюзию жизни)
5) дикая местность, чем дальше от дороги, тем опаснее, это тоже логично для открытого мира, обычно же в RPG и Зельдах местность делиться на прямоугольные зоны по уровню, вместо этих прямоугольников можно отталкиваться от цивилизованной местности и дикой, ну и по логике мира Властелина Колец сделать зоны типа гробниц и некрополей самыми ужасными местами, а не обычными рядовыми локациями как в обычных RPG с почти бесплатным лутом и экспой в виде зомби.
На самом деле не так сложно, как кажется. Вообще этот метод я подсмотрел почти случайно в структуре файлов игры Систем Шок 2 (вернее файлов сохранений конечно).
Там был не один файл, а несколько - включая отдельные файлы на локацию, где (я предположил) и была информация о динамических объектах (условные ящики, предметы и т.д.)
А формат может быть простым текстовым, где пишется тип, положение и какой-то ещё параметр (если в лоб решать эту задачу).
Если конечно сам замысел сделать Зельду-Кастлу, то да - свои подходы есть.
Вот взять к примеру Взертоса - у меня там враги спавнятся и это на 50% геймдизайнерское решение, а на другие 50% - я просто не смог сохранять врагов нормально (таковы особенности реализации, думаю теперь бы я написал иначе). Но вот предметы сохраняются - положение и тип (+\- ещё параметр)
Иными словами - ДД это делал в Гамаке ещё 4 года назад. Объём его игры - примерно как половина первой Диаблы, только без генерации, а с конкретным левел-дизайном.
На GBRII у меня был перманентно разрушаемый мир. Там как раз и была логика 1 файл сохранения на 1 локацию. Только я не запоминал каждый объект в текстовый файл, т.к. есть функция game_save(name). Вот такие гейм сейвы были на каждый уровень.
Зачем вообще делают самописные сейв файлы, когда есть функция сохранения всего: дело в том, что когда персонаж возвращается на старую локацию и загружается состояние локи, вы увидите, что глобальный сейв запомнил в том числе и параметры персонажа. Т.е. персонаж будет стоять там, где вышел с локации когда-то давно, иметь прошлогодний хп и все пройденные квесты сбрасываются нахер.
Так вот, оказалось, что проще поступить наоборот. Уровни запоминаем с помощью глобального game_save(name), а вручную остается сохранить только самого персонажа, вместо того, чтобы писать сейв для множества объектов с кучей параметров.
Так что задача сделать сохранения уровня Skyrim на GameMaker'e решается внутри недельного джема. Но придется и с файлами поработать и с чисткой, и особенно если вы хотите держать сразу несколько состояний мира в нескольких сейвах, тогда есть над чем запариться.
И всё же это не тянет ни на 100 людей, ни на много месяцев работы, верно?
Не, я к тому, что это не прямо так легко делается, как я описываю, лично мне поразмыслить пришлось. Но это все так же уровень недельного джема.
Кажется я столкнулся с какой-то проблемой при использовании этого сейва. Возможно как раз "запомнил в том числе и параметры персонажа", а может какие-то ещё особенности были. Но так или иначе было полезно с файлами поработать.
А вот в Бумажном я пошёл чуть дальше и сохраняю один файл, а там всё на ds_map, внутри которой ещё ds_map, внутри которой ещё ds_map, внутри которой ...
На JSONах?
Там с game_save одна проблема только, что она не запоминает структуры данных.
JSON использовал для БД различных, а вот данные сохранений именно ds_map (ds_map_write - по сути ds_map в строку записывает, которая уже в файл записывается) - в ГМС есть возможность их сохранить в файл, но файл не читаемый т.е. это не json.
Хм, вероятно поэтому и отказался от game_save - что структуры не сейвит.
"Я не юзал эту фичу, значит она никому не нужна". Классика.
Давай так. Поставлена задача - спрайт врага после получения урона должен на протяжении 0.2 секунд мигать (исчезать/появляться) с периодичностью в 25 миллисекунд. Просто ради интереса, как ты предложишь это решить? Желательно с подходом fire-and-forget, чтобы запустить и не париться.
Я создаю скрипт с обычной переменной int в виде таймера, потому-что боюсь корутины в коде, ведь при удалении объекта, корутину тоже надо останавливать, а запаришься вспоминать сколько я таймеров запускал,
мне очень часто нужны всякие мини таймеры, а о переменных внутри скрипта не стоит париться, при удалении объекта ничего не произойдёт с ними
"Я юзал эту фичу, значит она всем нужна". Классика.
alarm[0]=2
alarm[1]=12
В событие alarm 0: visible=!visible; alarm[0]=2;
В событие alarm 1: visible=1; alarm[0]=-1;
Это для 60FPS, и конечно 33,33 миллисекунды это не 25 миллисекунд, но много ли разницы. Мне в случае такой претензии интересно, как оригинальный код предполагалось синхронизировать с 60-герцовыми экранами, или с 144-герцовыми.
Если все алармы уже использованы (ни разу такого не видел в реальных проектах), можно добавить свой.
Ну да, именно это я имел ввиду. Спасибо за нахождение в моих словах смысла, о котором даже я не догадывался.
Но ведь я тебе лично ничего и не писал. Я писал форевервосьмопусу.
По коду, я так понимаю, возражений нет, так что - в чём проблема, непонятно...
Попробовал в Tic-80 написать на Lua, вроде работает:
Oчень страшный код, правда? _invincibilityEnds можно инициализировать тут же (оно определяется как Time.time + InvincibilityTime в момент получения урона), но мне это значение нужно локально в скрипте, поэтому оно ставится в другом методе скрипта.
Ну как тебе сказать. Не страшный, но https://en.wikipedia.org/wiki/Boilerplate_code
У меня в коде конкретно - таймер, количество шагов, таймер, количество шагов. А тут? Я знаю C#, и я знаю что тут происходит - мы определяем метод (1), имплементирующий (2) интерфейс (3) IEnumerator (4), йилдящий (есть такое слово вообще?) (5) результат вызова очередного WaitForSeconds (6). Это как минимум 6 ненужных вещей нужно выучить. Теперь посмотри на мой код:
alarm[0]=2
alarm[1]=12
В событие alarm 0:
visible=!visible;
alarm[0]=2;
В событие alarm 1:
visible=1;
alarm[0]=-1;
Один таймер работает раз в 2 кадра, перезапуская себя, другой срабатывает ровно 1 раз через 12 кадров. Тут для понимания происходящего нужно знать только понятия таймера и кадра.
Или так - у тебя 7 строк кода (скобки и пропуски я не считал) с вызовами методов, проверкой условия, возвратом; у меня - 6 строк, все из которых - просто присваивания.
Естественно, можно написать то же самое в один аларм, тогда будет ещё короче, но сложнее читаться.
Давай вот Алекса спросим, ему, как "менее программисту", виднее, какой код понятней и легче пишется.
Мне кажется ты не очень правильно понял что такое boilerplate code и кидаешься терминами чтобы казаться значимее
Не знаю что тебе кажется, но я привожу в доказательство конкретный код против конкретного кода - в одном нужно сделать много вещей, в другом мало, чтобы достичь одного и того же результата. Как насчёт обсудить именно код? Если это не бойлерплейт, то как ты это назовёшь?
Бойлерплейт код повторяющиеся участки кода, которые вынуждены быть использованы во многих классах практически без изменения, например листенеры для объектов и систем в Entity Component System парадигме.
Это же просто корутина, которая вызывается где надо простым StartCoroutine(HandleFlickering()).
Не вижу ничего "много" в этом коде, а в твоем коде вообще ничего не понимаю. Что такое alarm? Что такое 0? Что за события? Можно ли как-то переназвать этот alarm, а 0 заменить на человекопонятный enum, чтобы через месяц не пришлось рыскать по всему проекту чтобы понять, что изменилось?
Почему должно понадобиться рыскать по тому, что написано один раз правильно и всегда работает?
И что же, помимо мигания спрайта, в проекте не будет куча таких скопипащенных короутин, все из которых имплементируют энумератор, все из которых йилдят?
Ну да, потому что ты знаешь только свой инструмент. Это же логично.
Получается, что
нельзя, и надо использовать захардкоденные названия для вызова ивентов и держать в голове, что каждый ивент делает?
Твои выводы не коррелируют с тем, что я отвечал - enum'ы в ГМе есть, просто у меня порядочно много других полезных вещей, которыми я могу заняться помимо консультирования Юнитиводов по движку, прекрасно доступному для изучения самостоятельно.
Стрелочка, естественно, не поворачивается, да?
Зачем я вообще это пишу, в случае с кситом она никогда не поворачивается, сколько не старайся.
Чиво, какая стрелочка? Не разбираюсь во всех мемах на свете если что.
Я вам конкретный код привёл, конкретно назвал Юнитевский код бойлерплейтом, и вы ничего из этого не оспорили. Конструктивно обсудите - и докажете.
Пока что я вижу задачу из мира розовых единорогов - мигать раз в 25 миллисекунд. Это какой фреймрейт, 40? На каких устройствах это нужно, где столько герц? А вот именно что ни на каких, и сразу понятно, что ставящему такую задачу всё равно, что именно он ставит, для него это просто цифры и просто буквы чтобы просто программировать.
Забей, я всего лишь бесполезный разработчик, пилящий никому нахер ненужные вещи на богомерзком сишарпе. Зачем ты вообще на меня свое драгоценное время тратишь. С удобством разработки на гамаке ты бы за это время три игры с нуля релизнуть бы успел. А тут какое-то хуюнити, в котором на одни корутины надо получать диплом четыре года.
Заметь, я ничего подобного не говорил. Я просто сказал про короутины, и заверте.
По итогам этого "заверте", видно что в ГМе удобнее и проще делать вполне конкретную вещь. Под этим понимается меньше кода как такового, и меньше уровней абстракции, для ровно такой же гибкости.
Пожалуйста, не используй термин неправильно, в твоей же скинутой википедии он объясняется
Ты мне два раза сказал что я его использую неправильно, но не ответил на мой вопрос:
Утвердительный ответ на него означает что прав один из нас, а отрицательный - что другой. Начал говорить - так договаривай?
Кажется, я самое интересное пропустил.
По чистому коду я вижу, что первому элементу массива alarm назначают значение 2, а второму элементу назначают значение 12. Каким образом значения массива имеют отношение к кадрам, для меня, как для стороннего читателя, является загадкой.
Хотя это конечно же я зажрался со своим семантическим программированием.
Про массив тебе кстати тоже знать не надо для решения этой задачи - объективно говоря, это просто квадратные скобочки с цифрами. Посмотри на этот код как человек который не знает всего что ты знаешь вообще из программирования общего назначения.
Справка, с которой положено работать чтобы делать какие-либо проекты, отвечает на этот вопрос за пару секунд:
http://docs2.yoyogames.com/source/_build/3_scripting/4_gml_reference/instances/instance_variables/alarm.html
Теперь открываем справку по короутинам, добро пожаловать:
https://docs.unity3d.com/ru/current/Manual/Coroutines.html
Опять таки, для меня как для человека даже имеющего определенные познания в базовом коде, это выглядит как эдакий мистический код. Знание того, как работают массивы, никак не помогает мне осознать, что назначение массиву значения 2 на самом деле обозначает "вызови какой-то там ивент через два кадра".
Извини, я вынужден напомнить, что чуть выше писал:
А ты мне отвечаешь:
Так оно и не должно тебе помогать. Ты просто полагаешь, что выучил программирование и этими знаниями сейчас будешь все проблемы расшвыривать с дороги, но есть много способов решить одну и ту же задачу. Для некоторых шагов вперёд нужно делать шаги назад.
По поводу "осознать, что назначение массиву значения 2 на самом деле обозначает "вызови какой-то там ивент через два кадра"." - а где в твоём коде написано что Time.time это текущий момент, а не какое-то непонятное "время времени"? Для того чтобы работать в конкретной среде, надо осваивать конкретную среду, а не общие законы.
The bottom line - программирует программист (а кодит кодер, более узкий спец), игры делает разработчик игр, и с годами эта линия будет проявляться всё сильнее и сильнее.
Блин, мне как художнику больше нравится лаконичность кода, чем меньше символов, тем легче понять код, надо бы постепенно изучать ГМ) Хотя конечно юнити я не брошу, ещё нужно долгострой достраивать)
При том что Алекс знает, что это менее гибко, но "плохая" гибкость "простых" игровых движков типа ГМа, Multimedia Fusion или Констракта за 15 последних лет вышла на такой уровень, что это уже "достаточно гибко". Таковы реалии.
на практике наоборот
На чьей практике? Вот у Алекса есть практика, я не думаю что он с тобой согласится. В моей это тоже не так, и уточню, что речь не о том чтобы всё сжимать в a.b=c.d();.
Наверное это зависит от мышления или психологии, просто когда вижу красивые целые предложения из привычных английских слов в виде операторов и переменных, то мне становится сложно читать, потому-что они очень длинные, я для юнити сделал свой скриптер, где очень короткие операторы, стараюсь избегать длинных названий.
Мне Tic-80 понравился, потому-что там операторы очень короткие типа:
if btn(0) then print("ok") endи самое главное операторов очень мало, чем меньше операторов, и чем меньше символов в них,
тем лучше для моего понимания кода
О чём и речь.
нет, тут речь об ужасном костыле из за незнания языка(разговорно). при взгляде на переменную ты должен получать весь контекст, а не шариться по пыльным полочкам собственных абстракций
А мне даже нравятся механики, которые можно описать малым количеством кода. Это значит, что меньше багов в коде, меньше объяснять игроку в туториалах и проще потом скомбинировать с другими механиками.
малое количество символов и малое количество кода - разные вещи
Не спорю.
А чойта коммент подредактирован?
Без понятия, я в основном дополнял новыми ссылками, а не правил существующее. Если там было что-то важное, можешь цитировать как будто оно там есть.
А что по части, если этот объект внезапно удалиться, я слышал что надо корутины отменять перед удалением объекта. Хотя не помню, может имелось ввиду что-то другое, что там есть проблемы с корутинами, но с тех пор я что-то боюсь пользоваться ими.
Рубрика "страшилки с Кситилоном". :D
Спрайтик на юнити на экран можно и без C# выводить :3
загузил текстуру как спрайт, перетащил этот спрайт на уровень
Мне нравится пожёще.
Мне нравится как сделано во всяких Tic-80 и Pico-8 и тот же Love2D, где спрайт выводишь командой
в любой кадр, к сожалению в юнити этого нет, мне очень хочется такую опцию в юньке, но увы.(
Разери, вообще, в юнити будешь очень долго с инструментарием возиться.
Лучше выбери конструктор или движок с готовым инструментарием типа Game Maker или Conctruct2.
Я сам когда-нибудь на один из них переберусь, когда с кредитами разберусь.
Иначе провозишься с созданием инструментария, а не создания игры.
Я сейчас для юнити пишу куча всякого, чтобы просто помочь себе в разработке игры в будущем.
Тонна неблагодарной работы, просто чтобы делать то, что в некоторых движках уже готово сразу.
Та же плавная загрузка уровней (готово сразу в Stencyl), или скриптер чтоб создавать скрипты для уникальных уровней без компиляции (в том же Game Maker изменение скрипта не мучает тебя компиляцией по минуте или Godot), в юнити компиляция в большом проекте доходит до 1 минуты, просто чтобы один символ поменять.
Что имеется ввиду? Асинхронная подгрузка уровней? Есть же давно.
Нет, когда экран плавно одного уровня сменяется на другой или плавно затеняется чёрным экраном,
в юнити приходится создавать отдельную камеру для этих целей, чтоб она между уровнями существовала
и скрипт соответствующий писать для этого надо. Как раз вот думаю как делать подобную плавную перезагрузку уровня на C#, раньше я на JS сидел и хочется сделать как-то более грамотнее.
Звучит как специфическая логика. Странно обвинять движок в том, что он не имплементит за тебя какой-то специфический функционал, который далеко не во всех играх используется.
А в плане оптимизации, я бы вообще давал игроку ложную картинку подгружаемого уровня вместо того чтобы ждать пока он загрузится и уже тогда давать ему его изображение.
Оно специфично, но используется в 95-99% играх есть какой-то плавный приём смены уровней или локаций, никогда не видел в готовых играх, чтобы один уровень резко менялся на другой, всегда есть какой-то промежуточный эффект или переход или картинка загрузки как в том же Skyrim - Loading Screen.
Там много таких специфичных, но часто используемых вещей без которых игра будет выглядеть сырой:
1) свой скрипт смены кнопок управления, в юнити ужасная реализация, но я не смотрел в 2019-х версиях, может там уже норм
2) база данных всего текста для перевода на другой язык
3) внутренний скриптер для создания уникальных уровней и диалогов без компиляции
4) Свой скрипт глобальных переменных. В юнити всегда нужно, чтобы переменные были в скрипте на каком-то объекте. Это немножко выматывает, ибо приходится много пустых объектов размещать на уровнях, и ещё и следить, чтобы эти пустые объекты случайно не удалились.
5) свой менеджер уровней, ибо просто закинуть уровни в меню Scenes in Build, там получается каша, когда уровней становится больше 100
PS я пока это всё писал, то часто думал о том, где бы найти такой конструктор, где всё за меня уже готово, ибо надоело программировать вспомогательные инструменты для создания игры)
Мне кажется, ты что-то делаешь не так - вот в 2011 году пишут, как это делается:
https://answers.unity.com/questions/50716/how-to-make-a-global-variable-in-unity.html
Возможно что-то не так делаю, хотя static использую. Но я боюсь слишком часто использовать static, потому выношу скрипты в пустые объекты, когда базы данных делаю, например для вещей или системных звуков,
чтоб был лёгкий доступ к ним
static для хранения игровых геймплейных данных лучше не использовать, это низкоуровневая вещь, которая нужна для реализации нужного code flow игры. Конкретно в юнити статики лучше использовать для методов, которые нужно часто вызывать, и они не привязаны к MonoBehaviour
Ну вот тем более, оказывается я вообще зря использовал static, ибо обычно я для гемплейных данных и использую. Например у меня в старом коде есть
static public int HeroHealth;и много другого подобного
Используй ScriptableObject для хранения таких данных. Ты можешь перекинуть ScriptableObject здоровья игрока в любое нужное место прямо в редакторе, без создания сложнозапутанного кода с static переменными.
Я не понял что я не так сделал, но попробовал один раз пример с официального сайта юнити,
и у ScriptableObject данные есть, пока не пройдёт немного времени или не откроешь заново юнити, то все эти объекты становятся девственно чистые и все данные пропадают, короче я подумал что тут нужна особая магия и пока забил на них, используя обычные префабы)
SO это временные хранилища, ты в них данные помещаешь в одном месте, и читаешь в любых других нужных местах
А вот в чём было дело) с таким пониманием надо ещё раз попробовать тот пример, может и правда пригодиться для игровых данных
Достаточно написать один раз и использовать во всех играх. Или взять чужой бесплатный, полно их в интернете.
Грузи текст для всех языков из json файла, который правится отдельно, очень удобно.
Можно свой написать, если очень надо, то и в виду визуального node-based редактора.
Все можно хранить в scriptable object.
Не вижу проблемы, если иметь глобальную неудаляемую сцену с объектами, которые переходят из сцены в сцену (это игрок, менеджеры всякие, камеры и т.п.), то каждая сцена это всего-лишь набор препятсвий с врагами, предметами для собирания и прочего, каждая сцена существует отдельно и ее нужно лишь загрузить.
Почему бы не сделать одну камеру и делать ей фейд, а после фейда загружать нужный уровень, при этом сама камера является неуничтожимой при смене сцен?
Не понимаю проблем с "писать скрипт надо", игровые движки для этого и нужны, и это простейшая логика, которая одинаково пишется на каждом из популярных движков. С другой стороны, для игры порнографического характера с монстродевочками не проще ли взять RPG Maker, людям там все равно геймплей не очень важен, главное чтобы арт был посочнее.
Давно написал на JS, теперь заново переписываю на C#, потому-что юнити отказались от JS (давно отказались от JS, но я только недавно решил перейти, ибо слишком много скриптов переписывать, меня это пугало) Тут ещё один камень в огород юнити, они часто отказываются от тех инструментов, на которые я уже всё написал и теперь приходится переучиваться, как было с JS, так и старой системой частиц.
А ещё у меня тогда было мало опыту, поэтому в скриптах много "велосипедов", это ещё одна причина, почему приходится создавать скрипт с нуля, ибо это всё плохо работает и не оптимизированно.
Я имею ввиду, что последнее время я занимаюсь с созданием вспомогательной логики, а не игровых скриптов.
И немного подустал от этого.
За советы спасибо, подумаю как сделать специальный системный уровень, чтоб там было всё сразу включая героя, только не придумал как сделать так чтобы системный уровень создавался, если он ещё не был создан,
ведь для этого нужно чтобы на каждом уровне уже был какой-то системный скрипт, который бы загружал бы этот системный уровень.
Ну, на уровне обычно и так нужен системный скрипт, который, скажем, загружает данные об объектах с сохраненного состояния. В своей наработке я делал такой подход (я там еще отказался от переноса общего уровня между сценами, мне было проще перезагружать его для каждой сцены, так как это решало много проблем, например, с загрузкой сохранения). Еще вариант есть загружать системный уровень в главном меню, еще до того как начал загружать первый уровень.
Это плохой вариант, ибо я запускаю для теста всегда тот уровень, который редактирую, а там точно не уровень главного меню, а скорее обычная локация над которой в данный момент работаю)
Ну я же уже написал как это сделать
Можно использовать такое свойство перед методом:
[RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)]
С таким свойством перед методом, этот метод будет запускаться каждый раз, как ты запускаешь игру в редакторе. В методе ты можешь загружать основную сцену со всеми контроллерами и игроком. Так очень просто тестить отдельные уровни - вместо того чтобы сначала загружать сцену-менеджер, а потом уровень (для чего придется либо править каждый раз код, либо менять переменные в редакторе), ты можешь использовать это свойство и проверять, загружена ли сцена-менеджер. Если нет - загружать ее, а потом уже, как обычно, соединять менеджер с загруженной сценой. Для этого поможет объект, который должен существовать в каждом уровне, и ты этот объект ищешь после завершения загрузки сцены и привязываешь его к менеджеру.
Звучит сложновато, но в коде на самом деле просто все. Это позволяет отвязать друг от друга многие элементы и править их по отдельности.
Спасибо, звучит как то что мне нужно)
Чтобы отвязать все эти элементы друг от друга.
Погуглю примеры и инфу
Вот только каждый разработчик делает это по своему, и каждому свой метод удобнее. У меня есть метод, который я сам юзаю (подсмотрено на работе), очень простой и удобный в применении, с удобным для создания и структуризации перевода форматом, и я не знаю, смог бы я его использовать вне C#.
Статические классы/переменные/синглтоны/ScriptableObjects.
точно, спасибо за напоминание, хотел загуглить можно ли синглтон создать вне объекта вообще,
то есть даже если на уровне вообще нет ни одного скрипта, но синглтон сам инициализируется без никого,
всё время забываю это название и забыл что хотел нагуглить)
https://gamin.me/posts/20838?comment=268152#comment_268152
Я так понял, что Алекс не обвинял Юнити в отсутствии фейд-инов всяких, просто как художнику ему интереснее если в коробке уже есть всякие прикольные штуки.
В красивых! И да, в подавляющем большинстве в двухмерных. В этом-то и затык.
Точно) Я пока изучаю демку ГМ и процесс разработки игры, но по ощущениям, в нём уже легче и комфортнее делать игру с нуля, чем в юнити) Хотя инструментарий придётся писать, но поменьше, чем в юнити.
Вроде для диалогов в ГМ тоже ничего нет.
Ну да, это же не конструктор визуальных новелл. Впрочем, я тебе кидал свою систему, написанную 10 лет назад, она вполне работоспособна и до сих пор.
Чем мне нравятся конструкторы визуальных новелл и Битси, тем что диалоги уже из коробки)
Странно что многие другие конструкторы игр это не предоставляют, даже если позиционируются как дружелюбные для полных новичков или не для программистов.
Это какбэ правильно. Ты тогда можешь не просто затенять, а делать это с различными эффектами. Или между переключения и сцен вставил катсцену...
Вот тут согласен, возможность разбивать солюшн на проекты довольно упростила бы процесс компиляции, сейчас это можно делать только через костыли.
А там нельзя как-то галочкой отмечать, какие файлы включать в текущий билд, а какие нет?
GM можно вообще не перекомпилировать: https://yellowafterlife.itch.io/gamemaker-live
Но этим колдунством не пользуется практически никто, разве что повыпендриваться. Да и двухмерные проекты не весят так много, чтобы прям убивать время компиляцией.
А в ГМ есть пауза в одну минуту, когда в скрипте ты написал один символ?
Просто в Юнити компиляция скриптов проходит во время процесса, а не когда уже игру билдишь.
Я тут недавно комментарий в скрипте немного поправил и чуть не психанул) ибо забыл, что в юнити теперь всё будет минуту блокироваться и не потестить сразу, пришлось идти чай пока себе наливать)
В 2019 версии юнити Visual Studio 2019 компилирует скрипты сразу как ты сохраняешь изменения, без необходимости переходить в окно юнити.
Если скриптов становится очень много, что время компиляции становится очень долгим (никогда не встречал компиляцию в одну минуту, если честно), можно воспользоваться Assembly Definition - делишь скрипты на небольшие библиотеки, и перекомпилироваться будет только библиотека с измененным скриптом, а не все сразу.
Я на Notepad++, не помню почему я забил на Visual Studio, то ли VS долго открывался на моём старом ноуте, то ли по другим причинам, или потому-что эта программа много весит.
А Visual Code я не смог настроить, что прописывать в системной строке, там какая-то каша всегда открывается, вместо нужных скриптов из проекта. Сколько ни гуглил решений, всегда что-то не то было и потому остался на Notepad++.
зависит от PC, у меня слабый ноут, а скриптов где-то около 150) правда многие из них маленькие и ещё они на JS, но всё же.
Сейчас перешёл на C#, компиляция пока что очень быстрая, но скриптов пока-что всего 2 переписал с JS на C#) так что поживём увидим, будет ли лучше или также)
Visual Studio может долго загружаться, но после загрузки она довольно шустрая, это лучшая бесплатная IDE для Unity, которая уже и официально поставляется с движком. Не знаю насчет Notepad++, но в VS много удобных инструментов для рефакторинга и контроля над кодом, я рекомендую пересесть на нее, раз уж пересел на C#
Я просто даже не знаю что такое рефакторинг, наверное не пригодится)
В Notepad++ я по старинке открываю все скрипты по отдельности, а не целый проект, так и программирую где-то с 2012-го) уже давно привык
Пригодится, через пару лет работы над проектом. Но не в том случае если меняешь движки как перчатки, а я так помню, у тебя именно это и происходит, так что НУ НЕ ЗНАЮ. :yak:
У меня долгострой пишется годами, лет 5-7 наверное уже) потому у меня и 150 скриптов накопилось в юнити на JS, а теперь приходится это ещё всё переносить на C#
мусора там кучу накопилось, неужели рефакторинг мусор будет помогать выискивать) надо бы загуглить что это)
Никому не нужная вещь, забей
Рефакторинг - переписывание кода так, что с ним легче работать, но при этом сама роль кода остаётся такой же.
Подводные камни включают, например:
1) переписал, и теперь не работает;
2) пока переписывал, переключился на новую фичу и запутался;
3) переписывал так часто, что забыл сделать игру;
4) переписал, и стало ещё хуже.
Так что делай бэкапы и не переусердствуй понапрасну :D
Если нет желания повышать технический скилл программирования, то лучше и правда что-то менее программировательное использовать, в юнити по незнанию можно таких дров нарубить (и мне кажется что компиляция в одну минуту это одно из последствий)
скорее всего) я уже руки опустил добивать эти 150 скриптов на JS на старой юнити, и начал с нуля на C#, с новым опытом, пока что компиляция идёт быстро, даже радует, перед тем, как начать новое ядро скриптов, я даже написал план, что никогда при программировании раньше не делал, так что технический скилл растёт, но не так быстро, ибо ещё надо рисовать и прочее)
Я сначала прочитал вопрос как "есть ли в ГМе команда чтоб игру поставить на паузу на минуту", м-да.
Нет там такой паузы. Там есть долгая упаковка при компиляции вообще, особенно на Андроид, Иксбокс и подобные громоздкие платформы. Но я думаю у Юнити с этим не лучше.
У Юнити при выборе платформы для экспорта идёт какая-то перестройка проекта, относительно долгая. Ну и потом ещё компилируй\экспортируй_игру. Не помню как в ГМС, но кажется там никаких ожиданий при смене платформы вообще нет, а вот в Юнити есть и приходится ждать пока проект "перестроится" под новый выбор.
Ну есть первая сборка, которая длится долго. Но с файлами игры ничего не делается, просто кэш строится.
Вроде, это можно делать когда непосредственно билдишь билд игры, но в дебаге Юнити компилит сразу все скрипты. Вообще, эту фичу можно отключить, и перезагружать ассеты по требованию, а не автоматически, но это не решает проблемы с тем, что изменение одного символа приводит к полной перекомпиляции.
Но это проблема не шарпа, а самой юнити, которая тупо не позволяет разбивать логику на проекты (обычно студия не компилит проекты, которые не изменились).
Цикл 1, день 18.
Мало-помалу и достаточно вразнобой ознакамливался с основами C#, проходил тутор в юнити по созданию простенькой двумерной пошаговой игры (там это гордо называется роглайком), а также решал всякие разные вопросы типа "почему я не могу создать учётную запись для Visual Studio", "Почему у меня перестала запускаться куча программ после установки Visual Studio", "Почему у меня нет нужных шаблонов для написания простеньких исполняемых программ в Visual Studio".
Когда я начинал рисовашки - то были новогодние каникулы и у меня была прорва времени, а сейчас начались рабочие будни и я иногда, приходя с работы, за столом засыпал, не то что был способен всерьёз чему-то учиться. Так что в некоторые дни я не делал просто нифига и по итогу я мог бы сказать, что эти девять дней прошли скорее не особо продуктивно.
СПРАЙТИК НА ЭКРАН В СВОЕЙ СОБСТВЕННОЙ ПРОГРАММЕ Я ЕЩЁ НЕ ВЫВОЖУ, ЛООООЛ.
Но я думаю, что начну это делать несколько попозже, да.
Думаю, это вполне выполнимо, как минимум.
Сейчас будут три денька в музычке.
Осваивать какие-то серьёзные программы для этого дела я пока не хочу (есть риск тоже убить всё время без создания какого-либо заслуживающего упоминания контента), так что пока просто снова потыкаю чё-нить в Guitar Pro 6.
Caustic хорош.
Видимо это одна из причин почему я забил на Visual Studio и продолжил пользоваться Notepad++, который без удобств, но код написать можно)
Нужно было просто взять ГеймМейкер :yak: И это даже не столько шутка сколько правда. Вероятно бесплатная версия имеет какие-то дикие ограничения (раньше для студии было ограничение в 10-15 ресурсов (каждого типа)), но начинать и особенно 2д игры думаю лучше именно с ГМ
Я сразу в комментах предупредил про подводные камни с Юнити, где надо устанавливать дополнительные инструменты, с которыми ещё и возникают дополнительные проблемы, и это только вершина айсберга подводных камней)
А по GM. Вроде в демке теперь там ограничение на 30 дней, это хуже, чем демка 8.1 версии, которую я недавно скачал и обрадовался что там неограниченное время, можно поизучать в размеренном темпе)
Но раньше Разери думал куда деньги деть) если ещё осталось, то может стоит купить себе GM в стиме, цена где-то в 1600 ру)
Или купить тебе асепрайт, чтобы ты сделал игру, а Разери поиграл :o)
лол не надо Aseprite, лучше сразу GM, там и сразу графический редактор встроенный есть, хотя я шучу конечно)
Вот кстати да, забыл ещё и я написать, что так сказать "начальная развёртка" проекта в Юнити мне показалась долгой. Сам этап "сейчас начну делать игру" прям как-то не очень. Возможно, если сделать на Юнити N+ игр, то это вообще времени занимать не будет, но мы же про начало работы.
По скидке около 1килорубля ГМС2 стоит, да. Навигация правда там может запутать поначалу, может где есть за очень дешева ГМС1 (илинет)
Я на юнити сейчас начинаю новый проект, на новом языке)
Пишу стартовые скрипты, это жесть как не быстро, но если юнити с C# не перейдёт ещё на один язык,
то в этот раз скрипты пригодятся для того чтоб стартовать новые проекты на долгий период.)
Они переходят на свой язык с кусочками синтаксиса c#, который вроде называется burst
Серьёзно? Да они достали менять, то отказались от JS, то от системы частиц.
Опять что ли учить новую инфу для старого редактора? D:
Может тогда не стоит и пытаться писать свой долгострой на C# на юнити
и ждать когда они допилят этот бёрст? Я просто хз.
Вроде недавно в прошлом году оно вышло 1.0 и сосуществует пока с обычным c#. Но я сильно не интересовался.
По-моему, для проверки временем, плохи что C#, что GML, что какие-то Бёрсты (хотя пока о нём говорить рано), что язык CON-скриптинга в Duke Nukem 3D. Именно поэтому делать надо на том, на чём ты можешь быстро сделать всё что хочешь. Может, то что ты хочешь, это вообще не долгострой, при правильном подборе инструментов. Во всяком случае, в плане кода, в отличие от очевидного объёма по графике, музыке, звукам. (на этом месте пора остановиться, потому что чувствую как подступает абилка Мегаинформатика)
а есть где почитать? а то я только "A burst is a particle emission event" вижу
Я не сохранял закладки, почитай рекламные проспекты по поводу выхода последних версий и всякие статьи от Араса П. и видосы от Майка Эктона.
Кситилон советует Гамак @ 14 лет опыта в Гамаке, релиз на Иксбоксе самостоятельно @ Минусуют
ДД советует Гамак @ ??? @ Плюсуют
Логично! :yak:
Все просто триггерятся на это, как на очередной повод холивара! yak
Просто людям бомбит, оттого что у них самих ЧСВ не позволяет спокойно смотреть на факты. На 3D-движках в целом глупо делать 2D-игры, это ж очевидно.
Исправил 12 на 14 кстати, ибо. Но не больше, нет. Где-то там.
Ну тут ты неправ, например. Нет никаких "глупо". Если есть - расскажи как это определяется.
Можно 2д игры на 3д движках делать, 3д игры на 2д движках, платформеры на РПГМейкере, Интерактивную литературу в ПаверПоинте - что угодно, одним словом. Главное, чтобы игра была хорошая, и ни у кого вопросов не возникало и желания что-либо опротестовать. Вот один факт, а остальное - домыслы, ровным счетом.
Так что это не вопрос ЧСВ. Нет никакого ЧСВ в том, чтобы быть приверженцем одной или другой IDE, одного или другого языка - это попросту странно, и понять это затруднительно. Есть смысл гордиться яблоками, которые ты вырастил, а не гордиться тем, что покупаешь вот те яблоки в магазине вместо вот тех других с наклеечкой.
ЧСВ понимаемо может появиться, когда сделал хорошую игру человек. А ЧСВ от того, что он выбрал ГМС или Юнити - это странно, не понимаю. Не понимаю о каком ЧСВ тут может идти речь вовсе.
пример с яблоками некорректен. обладание хорошим инструментом нехило поднимает и чсв и мотивацию и прочее. паджеро вместо лады, гибсон вместо самика, ДИгл вместо NambuType94
хотя и яблоки тоже способны так работать. Например можно гордо жовать DwarfFortress вместо Bejeweled
В комментариях к этому же посту обсуждалось именно это - насколько много БОЛИ надо испытать прежде чем ты напишешь один таймер. Щас опять набегут со своими "один раз выучить - никогда не забыть" - даже если это так, захламлять память ненужными абстракциями - что в этом хорошего?
https://gamin.me/posts/20838?comment=268156#comment_268156
"у тебя 7 строк кода (скобки и пропуски я не считал) с вызовами методов, проверкой условия, возвратом; у меня - 6 строк, все из которых - просто присваивания."
Не глупо ради одного таймера проходить такое программно-архитектурное расстояние? Твое мнение?
А это всего лишь одна простейшая вещь, одномерная, мы до пространства координат даже ещё не дошли. В Юнити тебе придётся писать кватернионы для того чтобы работать в двух измерениях - обоснуй что это необходимо? Если не необходимо, не делает ли это затею глупой?
Главное, чтобы игра вообще была, и желательно создавалась удобно и побыстрее. Об этом тут и речь.
Поясню на примере, взятом из воздуха: человек начал изучать Юнити около 2012 года, считается на фирме серьёзным спецом, Senior Unity Dev, участие в конференциях, командировки, отпуск, страховка, и так далее. Получает $2000, может $3000 в месяц.
И тут вдруг оказывается, что корутины можно не знать, что грубо говоря от половины до двух третей всей инфраструктуры никогда не обязательно было осваивать, и что если массово делать двухмерные игры на хорошо под это приспособленных движках, то не будет ни $3000, ни $2000, нисколько в месяц - это рабочее место, созданное за последние 7 лет, проживёт только года три, и всё. Поэтому надо включить всю свою гордость и пытаться мне доказывать, что ВСЕ должны учить корутины, ведь это легко вписывается в уже сложившуюся иерархию профессиональных геймдевунов со их спонсорами, лоббированием де-факто калечного для геймдева ВиАра, от которого людей тошнит, "вам это будет полезно в НАСТОЯЩЕМ программировании, а не в каких-то там игрушках", и так далее.
Пожалуй, ты прав, дело не в ЧСВ. Это только защитная реакция, а причина - в профессиональной деформации.
в обсуждении про кориутины было не "надо", а "несложно". таймер изи пишется без них. кватернионами не оперируешь непосредственно. дальше какаято хуита про рептилоидов. Стыдно молодой человек
"Главное, чтобы игра создавалась удобно и побыстрее" - о! именно этим популярность движков и объясняется
Тогда отвечает Александр Друзь оригинальный постер - зачем же было приводить пример корутин там, где они наоборот не нужны?
https://hh.ru/search/vacancy?L_save_area=true&clusters=true&enable_snippets=true&text=unity+developer&showClusters=false
Съел?
не, не понял чего там. Если бизнес готов столько платить, то наверно из-за выгоды, а не заради спонсировать ненужное и лоббировать нерабочее
Золотые слова - практически все инди-проекты и стартапы прогорают. Игры реально не нужны в таком большом количестве и в таком малом качестве, как их сейчас делают на плохих инструментах плохо обученные люди.
https://forum.unity.com/threads/the-scary-stats-about-indie-developer.473305/
https://www.quora.com/Is-it-true-that-85-of-indie-game-developed-games-are-financial-failures
А вывод из этого простой:
как эти ссылки связаны?
Ты даешь ссыль на малограмотного разраба четыре года создающего мобилкоигры и теперь считающего, что Unity-напарник за 150К в месяц принесет ему дополнительную прибыль.
во второй - омг! 8 из 10 школьников не становятся миллионерами занимаясь разработкой игор.
ну и Depending on how you define your terms, decide who qualifies as "indie", what counts as a financial result from the game, and where you set your thresholds, you could probably argue 98% or more, or 20% or fewer, indie projects were financial failures.
Это к тому что разработка инди-игр, в отличие от азартных игр и ААА, это вообще не бизнес, это рулетка. И если бизнес куда-то там что-то платит, то это не значит что оно обязательно выгорит - просто есть такой тренд, который рано или поздно перегорит.
хмм, ну да. такая же рулетка как и любой другой бизнес. выше прибыль - выше риск, в этом и романтика инди. Меньше риска - меньше инди
То что бизнес платит означает что у него есть основания для подобного риска. Степень реалистичности его притязаний легко определить через его опыт в сфере
Я о том и говорю, что нет. Есть бизнес который в разы надёжнее. Если ты тоннами закупаешь картошку, которую тоннами всегда покупают, у тебя очень мало шансов прогореть. Инди-игра не картошка. Пост Нупра на тему хороший вспомнился: https://gamin.me/posts/18185
а есть бизнес в разы ненадежнее.
но не на порядки, бо свято место пусто не бывает. и бизнес с малыми рисками и высокой прибыльностью тут же станет бизнесом с высоким риском из-за конкуренции. Рынок решаэ.
Потому что если необходимое действие выполняется редко, мне удобней запустить один раз один метод, который выполнит это действие асинхронно, вместо того, чтобы городить пачку отдельных переменных чисто ради того, чтобы обновлять их в условном тике/апдейте ради этого действия?
То есть, аргумент в том, что проще скопипастить, чем что-то писать вручную?
А теперь про архитектуру вычислений.
Асинхронность нужна там, где ты не знаешь, когда тебе прийдёт ответ, например - когда ты посылаешь запрос на веб-сервис ачивок в облаке, и получаешь его неизвестно когда, или вообще не получаешь - тогда обработчик срабатывает уже по таймауту, с соответствующим статусом.
Для таймера, время срабатывания которого точно известно, ты только заводишь лишний поток вычислений, который ещё должен проходить через планировщик. 1000 таких асинхронных таймеров скорее всего повалят игру, тогда как 1000 и даже 2000 переменных - нет. Ещё неизвестно что займёт меньше памяти, помимо процессора. 10000?
Я не совсем понял, о чем речь.
В общем, по контексту местных я уже понял, какое у тебя впечатление о моих навыках программирования, но всё еще не понимаю, почему ты тратишь свое время на мои детские каракули. Просто игнорь нуба, мои слова не имеют никакого веса, их не стоит принимать серьезно.
Нет, ну почему же. Программист ты грамотный, и я не думаю что знаю больше тебя именно в программировании, соответственно не пытаюсь тебя учить программировать - это не моё дело по совсем иной причине, чем наличие или отсутствие веса чьих-либо слов. Дело в том, что когда я упомянул короутины, я даже не помнил что это такое, так как когда-то их изучал, доказал себе что они едва ли пригодятся под таким углом в таких задачах, и намеренно забыл. Но ведь в этом и весь, что называется, point.
Тогда, видимо, и я не понял. Пускай так и будет, а вместо теории о нас говорит практика.
У корутин вся прелесть в том что это не отдельный поток (в смысле операционной системы). Просто у юнити есть список корутин и он на каждом кадре вызывает один шаг каждой из них (кроме уснувших). Поэтому хотя они конечно потяжелее одной переменной, но тысяча таймеров на корутинах будут летать.
И то хорошо. Будь это потоки, была бы совсем беда.
Юнити запускал пару раз, но банальное гугление примеров и документации говорит о том, что помимо, О УЖОС, кватернионов, есть "классические" углы Эйлера. В любом случае, даже если решишь кватернионы юзать, то это не выглядит чем-то сложным. Можно сказать, что и векторы в двухмерном пространстве не нужны, давайте просто пару чисел юзать, зачем там эти какие-то скалярные произведения нужны. Или векторные произведения, что и того страшнее.
По поводу подсчета строк кода на таймеры - меня этот пример не особо впечатлил ни в одну, ни в другую сторону. И так, и эдак читаемо, кому что нравится. Я вот не знаю, в тех поделках, которые делал я, я куда больше времени тратил на размышления о том что и как сделать, чем на, собственно, стучание по клавиатуре. Я бы пережил это и с одним синтаксисом, и с другим. Я понимаю там промышленная разработка (the ИНДУСТРИЯ - но мы же, вроде, не в ней. Ну, я точно нет, ты тоже вроде был против) - может там и имеет смысл, но для всяких пиксельных 2д увеселений и тот, и другой варианты годятся.
По поводу доказывания чего-то с Сениор Юнити Ассет Флип 3кк в секунду - очевидно, что это глупо. Однако пытаться кому-то доказать, что на самом деле ему не нужны корутины и прочее - это примерно что-то из того же разряда. Можно просто обменяться мнениями и ехать дальше по своим делам, мне идея переубеждать кого-то уже кажется стремной в целом, если только от этого не зависит моя жизнь, здоровье и прочие базовые вещи.
Ну, игры есть и на гамаке, и на юнити. Затрудняюсь сказать на чем их больше, причем.
Так ведь ГМ так и работал все эти годы. И все игры на нём сделаны без этого. Кроме, понятное дело, тех велосипедов трёхмерных.
Нафига оно надо, мусорить геометрией в мозге человека который должен делать игры, а не воплощение математической воли на математических пространствах?
Мы-то не в ней, но твои поделки на игровые джемы и, скажем, Хейзера поделки на игровые джемы - это качественно разный уровень. Выход на Стим уже лет 5 как не критерий, а вот выход на игровые консоли это уже вроде как индустрия, но мы-то сами всё равно инди. Так что всё остаётся в заданных рамках.
На Юнити, конечно, т. к. из-за наличия рабочих мест на него, туда не только идут прикладные математики, программисты и мегаинформатики, но и лезут люди гуманитарного склада ума, которые взращивают в себе исключительно оный и далее, и потом искренне удивляются, как же так, почему игра не делается.
Я так понял, что нужны люди только... хм... людоцентрического склада ума? :yak: Раз и условная математика, и условная гуманитарная наука оказываются вредными.
Ты вообще пишешь с одной стороны, что нинужны нам ваши корутины и прочие векторы, и без них игры делаем, с другой стороны - мы издаем на консоли, мы в индустрии. Тогда встает закономерный вопрос - раз так, то может всё же попробовать векторы с корутинами, вдруг всё ещё более индустриально станет?
Не, я не говорю за всю планету. Просто, в среде конкретно инди-разработки, думать надо об играх.
Хейзер уже пробовал, ничего индустриальным не стало. Зачем пробовать мне, если вот уже есть такой опыт.
Я сейчас пробую исходник этой игры скомпилировать хоть в каком-нибудь Юнити - будь то в новом, в старом 4.0.0 на котором оно делалось ещё тогда, или в каком-то среднем - ничерта не работает. То есть даже просто компиляция, даже на той же версии IDE. И там не ошибки уровня "не хватает шрифта в системе", как написал бы ГМ. Шрифта тоже не хватает, но там у нас:
И так далее. Для кого это всё сделано, непонятно, но явно не для людей.
Тем временем я беру ЛЮБОЙ свой исходник начиная с 2007 года, конвертирую его, внимание, из GM6.0 в 8.1 (2011), потом в Studio 1, потом в Studio 2, и игра, которую я делал на Windows XP, попадает на актуальный в 2020 году Xbox One. Как так? А вот так. Сколько использовано кватернионов, углов Эйлера, векторов, корутин? Нисколько.
Исключение составляет только базированное на execute_string(), то есть той самой компиляции на лету, которую пришлось выпилить ради кроссплатформы. Но и там ошибки уровня моей логики, а не просто "какой-то мэш где-то что-то".
У ДД игры явно посложнее твоих в плане программирования. Так что логично.
Ну да, ну да. Разве что тем, что он делает 3D в Гамаке, хотя он для этого не особо предназначен, просто ему по приколу. А так - в чём принципиальная разница?
В том, что одни люди молча анализируют свои минусы, а другие от них открещиваются как Кситилтн.
Я тоже умею отпускать ничем не обоснованные саркастические комментарии. А что сказать-то хотел? Пруфов нет - сложность игр, как и их хорошесть, меряется в одинаковых неизвестных попугаях.
Вот скажем, в Замке Невозврата 2 например 216 комнат с генерацией, во Взертосе никакой генерации нет. Взертос это примерно как мои танчики с ГБРа Йео, только в который добавили дерево скиллов, много текста и моделек. И ещё листаемые комиксы, делаются легчайше. Вот сам ДД, скажи мне что это не так?
Н..н..но ведь... Бумажное....
В Бумажном есть генерация. На самом деле она была и в Вояжоре Пистоне, и ещё давно в каких-то "Орках". В свою очередь в Бумажном нет системы сбора артефактов и осколков меча, статусов от статуй, 30 локализаций... так что какая игра какой сложнее - это ещё вопрос.
Каких попугаев? Я и без попугаев вижу, что Взертрес технически и масштабно сложнее Замка. Генерация - это не какая-то сверх задача, которая тебя сразу возводит в ранг великих разработчиков.
А, ты видишь. Ну молодец. Генерация была просто как пример, потому что ты с потолка взял и что-то там сказал по какому-то там твоему мнению, без критериев чтоб другие люди померяли и оценили - да, действительно сложнее. Мне не обязателен никакой ранг, чтобы об этом говорить. У меня есть опыт, которого нет ни у тебя, ни у ДД, и этого вполне хватает.
А ты Кситилон.
Только опыт ДД плюсуют, а твой минусуют почему то
Потому что ЧСВ.
Как быть в этом случае? Говори свой рецепт
Меньше трындеть, больше игр делать.
А чё, в замке 2 есть генерация уровней? Я даже не заметил, всё время всё квадратное вокруг.
Он имеет ввиду, что в определенной комнате замка, спавнится уникальный предмет из списка и надо сделать так, чтобы он не заспавнился потом в других комнатах — Великая Генерация
А, ну ясно.
Пояснение для зрителей с поп-корном: в Замке Невозврата 2 работает алгоритм генерирующий переходы между комнатами как по горизонтали, так и по вертикали, то есть - ох щи, держитесь за углы Эйлера - трёхмерный. То что этим двоим людям "ну ясно", говорит о многом в данном случае.
Ксит. Ты с ума сошел со своими играми.
Может все таки слизи хочешь разеривской?
Это вряд ли. А могли бы игры делать.
На самом деле генерация именно ВСЕГО замка в Замке (лол) не столь простая задача, как может показаться. Ведь там ещё переходы нужно правильно сгенерировать из комнаты в комнату и с этажа на этаж. То что "предмет из списка" это понятно, что просто, а вот связать трёхмерный замок это куда сложнее.
Защитнег нарисовался, ага
Можно устроить джем генерации 3д помещений! YAK
Другое дело, что поставить в комнату заранее готовый паттерн это не так сложно. И даже больше - Ксит упоминал моего Вояжора Пистона и я там такого реализовывал (но в игру не вошло это).
На самом деле ДаркДес третий программист нашего проекта.
Просто ради интереса - какой по счёту я предлагатель фич для вашего проекта? :D
7-й? В титрах все есть, именно в том порядке, в котором происходило комментирование на Коленке.
На самом деле там этого нет! И моделек нет, но модельки есть вне-игры, а в самой игре пре-рендер у которого есть свои плюсы и минусы
Голливуд в телеграме заменился на роботов? Вот это интересно!
Постепенно делаю РОБОТОЗАМЕЩЕНИЕ
:kot:
Как-то слишком спокойно всё.
Накидываю.
С тобой-то мне зачем спорить, ты ж не мой оппонент? Идёшь C# изучать - ну иди, наслаждайся. :yak:
О, да... полные булки наслаждений
Лол) ну я лично посоветовал GM или другой конструктор, потому-что оно полегче Юнити в разы,
и тем более если планируешь быстро стартовать проект, GM тут больше подходит, чем Юнити.
А если хочется больше сложности, то можно и Юнити и C#)
Я мог бы даже что подсказать по C#, но мой способ кода слишком сомнительный, ибо создаю свои странные велосипеды с квадратными колёсами на C#) Я например для внутреигровых переменных использую большой массив Dictionary, чтоб был доступ к этим переменным через обычный текст String) мне так удобнее, чтоб сделать свой язык программирования для быстрого написания диалогов без компиляции.
Тем временем исполнение любого кода на лету (без компиляции) было в ГМе с 2005 по 2011, а дальше было нещадно выпилено при обновлении до Studio 1. Что за мир ебалайства-то такой, а.
Я на этом свой дебаггер написал, и пост об этом был на геймдеве.ру 6,5 (!) лет назад.
http://www.gamedev.ru/projects/forum/?id=179080
Все ссылки дохлые. Какая разница, если всем милее свои квадратные велосипеды. Не чувствую мотива помогать людям больше - надо было брать когда дают, и слушать когда рассказывают.
Да шо ты нам статьи свои суешь, видели мы твои статьи. 7 лет прошло.
В том-то и дело что прошло, а всем нужны готовые решения для копипасты вместо того что у меня есть. Это Алексу пригодилось бы, если бы он смотрел в ту сторону.
Почему ты думаешь что Алексу пригодится статья Кситилона. Сам же говоришь, что он смотрит в другую сторону.
"пригодилось бы" != "пригодится", попробуй прочитать мой комментарий ещё раз.
Хочешь слизи разеривской?
Это не ко мне.
Я определённо хотел бы вернуться в прошлое, когда были финансы и прикупить GM, но сейчас жизнь в кредит)
и в прошлом не задумывался о переходе на более простой язык типа GM, а когда пытался задуматься, то GM казался более сложным, чем обычный конструктор типа Multimedia Fusion (и непривычным для меня, и так получалось, что я всегда мимо GM проходил, то нет финансов, то кажется чем-то непривычным)
С Юнити легко задалось, потому-что он доступен сразу, хотя он определённо в разы сложнее, пришлось перебарывать себя (я всё-таки не особо программер) ради такой халявно предоставленной возможности в виде юньки и учить JS (на тот момент мне сказали что C# сложнее, и это тоже был плохой выбор, теперь мой долгострой так и не родившись создаётся заново уже на C#, хотя в этот раз свой микроязык создал за пару суток, что уже радует, раньше уходили на это месяцы)
Долгий путь, однако. Я даже отговаривать не возьмусь - у тебя это длится реально годами, в отличие от Разеривских наскоков по-быстрому оприходовать движок чтоб уже или готово или ладно, потом сделаю. Не в обиду, Разери. :yak:
Наблюдая за всей этой темой я удивляюсь только одному - почему ты не рисуешь значки почему никто не рекомендует GODOT ?! :YAK:
Рекомендую!
если не 3д и не мобильная игра, но для 2.5д тоже пойдёт
А чем 3д там плох? (я пока fps tutorial ограничился, 3д и работа с ним выглядят вполне хорошо)
Он может подойти, если знаешь, что делаешь. А если говорить в целом (а ля "я нуб, посоветуйте движок для 3д"), то высока вероятность, что нет.
- gles3-рендерщик практически не поддерживается в пользу vulkan; ждите версии 4.0 как минимум, чтобы получить стабильный современный рендер; в gles2 меньше функционала
- баг с компиляцией материалов, из-за которого игра может подвисать на секунду, если на экране появляется новый материал, шейдера которого пока нет в кэше драйвера видеокарты
- нет occlusion culling, ожидайте, что игры от 1го-3го лица могут работать медленно
- нет искоробочного редактора ландшафтов
- нет искоробочного LOD
Умельцами портируются функции с gles3 для gles2, не знаю на сколько это костыльно, но факт - gles2 начинает выглядеть лучше...
Полноценного редактора ландшафтов нет, но помнится мне есть некий плагин предлагающий хоть что-то... HeightMap вроде, с поддержкой лод, опять же вроде...
Окклюзион завезут в версию 4.0 вместе с вулканом... Отказавшись от gles3 и оставив gles2 для мобилок.
Нубам Godot в 3D точно не подойдёт, да и сам 3D скорее плох чем хорош... А если 2D и 2.5D то welcome. Но это все имхо...
Годот тоже выглядит неплохо, на первый взгляд легче Юнити, ну хотя бы потому-что там динамические переменные как в Lua, и нет компиляции после того как написал хоть что-то в коде. Тем самым можно не делать дополнительный язык для уникальных уровневых скриптов, а всё писать в обычном коде Годота.
Плюс в годот сразу встроенный редактор кода есть, что выгоднее отличается от мучений Разери с Visual Studio.
А ещё там операторы короче, чем в Юньке, что является плюсом лично для моих фетишей короткого кода :yak:)
Есть тип переменных variant, который будет содержать в себе любой тип данных, а все другие переменные можно строго типизировать... Что тоже очень удобно.
Мало того есть возможность запуска кода прям в редакторе, Карл(!!!). Достаточно добавить строку tool в начало скрипта.
Gdscript хорош, как lua в love2d. Хотя есть gdnative - поддержка c#, c ++ и прочего, для тех кто любит еблю с Mono и другими сторонними редакторами...
Я последнее время люблю редакторы, где всё сразу встроено. Не люблю тяжеловесные дополнительные программы устанавливать, чтобы просто текст писать типа Visual Studio. Но Game Maker и Construct2 пошли даже дальше, там сразу и графоний можно рисовать, мне часто лень открывать другие редакторы, так состояние потока разработки нарушается и начинаешь отвлекаться, а через минуту уже совершенно другой фигнёй страдаешь, просто потому что устал ждать когда откроется эта чёртовая дополнительная программа.)
Поток нарушен, настроение на сконцентрированную разработку снижается) Моему мозгу только дай причину попрокастинировать, так сразу начнётся) потому лучше бы всё сразу было доступно без дополнительных установок, ожиданий и открываний.
а я думал там по дефолту все переменные с плавающим типом
нужно ли что-то чтоб строго типизировать? ну просто например в JS нужно написать строку типа
pragma strictСтрого типизируются данные для того, чтобы не происходило меньше путаницы и на выходе ты получал то, что нужно. Иногда все разложить по полочкам гораздо лучше, чем потом заниматься выборкой. Но это так, на вкус и цвет...
Я просто и сам часто "строго типизирую". Так что мой вкус в сторону строгой типизации, но с возможностью
некоторых переменных иметь как текстовое значение, так и int. Например для списка плавающих переменных, типа словаря, где я не уверен какой слот будет int, а какой будет String. Вроде в годоте так тоже можно делать, где в одном списке будут храниться как текст, так и числа.
Да, словарь хорош:
найс, то что надо, я и говорю как в Lua :3
А строгая типизация как делается (или там не нужно ничего дополнительного вводить,
типа как у JS строку
pragma strict)?И можно ли использовать подобный словарь во время использования строгой типизации?
Словарь ты можешь использовать при любых случаях, никаких прагма писать не надо... В любом случае ты же контролируешь тип входящих и исходящих параметров...
Как в паскале примерно, через двоеточие ставишь типы (у функции - через стрелочку), но можно не ставить, будет либо автоматом тип в зависимости от другого кода, либо variant (динамический тип).
Цикл 1, день 21.
Наколенная музыка для сражений, в которых решается судьба ваших голеньких подчинённых:
>>234<<
Большая просьба: включить музычку и поделать под неё что-нибудь постороннее, чтобы было ясно, не мешается ли она и нормально ли слушается на фоне.
Ну и эта... напишите, как вообще оно :D
Да.
Краткость - таланта сестра.
Нормальная штука, для сражений пойдет. Дисторшн только слишком нажористый, помягче бы, слишком много грязи.
ок, если вменяемо переозвучить. так буэ, зомби-шутер или что-то уродливо-пиксельное про космос. самый агрессивный кусок хочется еще, ощущение словно он не раскрылся до конца.
бубнилка на палммютах четкая
Цикл 2, день 2.
Наконец-то снова рисовашки, фуф.
Сделал набросок "Старшей тины", заполнив одно из пустых мест древа эволюции:
... и начал прорисовывать в пиксельарте персонажей в ветке природы:
(попытаюсь ещё подумать над кистями рук средней девицы)
Мне хотелось бы как-нибудь по-плавнее перейти цветами от зелёного цвета к телесному и как-то побаловаться с контрастом между более светлой кожей и более тёмной листвой (даже если и то, и другое будет на каком-то персонаже зелёного цвета), так что мне ещё предстоит подобрать или найти где-то подходящую палитру.
Кисть руки средней девицы, взять у девицы справа, левую кисть...
Найс, мне нравится почти всё кроме кистей средней барышни, они не няшные, а большие и как-то странно вывернуты, короче хз, хочется чтобы они были более миниатюрнее (то есть в таком разрешении менее прорисованы, всё равно тут пальцы не получится прорисовать), ну хотя на вкус и цвет товарищей нет, просто первая реакция)
Чёй-та комменты новые не появляются и мечей ставят мало...
Только не говорите мне, что для этого нужно контент предоставлять о_0
Не, не будем.
король сующий свои пальцы куда ему вздумается уже не торт...
Теперь там милашечная лисичка.
А ещё немного сегодняшнего:
- подгонял анатомию Алрауны под анатомию остальных монстродев.
Не окончательный вариант.
Цикл 2, день 18.
Проходил "Программирование на С# с Юнити для начинающих", переписывая код и проверяя работу всяких штук, потихоньку знакомясь с синтаксисом, встроенными функциями и принципами извлечения из IDE нужных мне вещей.
Из-за необходимости вникать во множество впервые встретившихся мне фич кривая обучения показалась довольно крутой и безблагодатной, кое-какие не работающие примеры кода (было и такое, лол. Старая версия учебника попалась?...) выбешивали, а необходимость изучать кое-какие посторонние и не интересующие меня вещи (связанные с коллайдерами для движущихся объектов, например) просто потому, что за компанию там предоставлялась действительно нужная мне инфа... делала меня грустной пандой.
ТЕМ НЕ МЕНЕЕ!
Я всё-таки кой-чё смог извлечь, мне стала подвластна магия вывода на экран изображений, а это значит, что зацепиться за написание кода для игры я смог и с этого плацдарма уже начну (скорее всего, некоторые вещи переписывая, с приобретением опыта) расширять и углублять код для моей игры.
Крайне маленький шажок для Гамина, но зато большой шаг для меня ^_____^
в Годоте и кажется в Game Maker магия вывода на экран менее костыльная,
вроде есть в обоих редакторах прямое рисование графики, без создания объектов,
и очень жаль что в Юнити этого нет, ибо мне часто удобнее всё отрисовать кодом,
чем плодить гору объектов и настраивать родительские связи.
Вот оно - визуальное программирование в действии. На unity 3d. Но зато c# изучишь. Ты прям как Армстронг: маленький шаг для меня, но большой шаг для всего человечества :)))) Когда с юнити наиграешься советую скачать Directx SDK и изучить примеры приложений из него. Пользы будет намного больше. Проверено на личном опыте. Игру быстрее при этом конечно не напишешь, но розового восприятия unity 3d как движка для эффективного написания игр поубавится. Я не стал нырять в это болото, так как знаю о чем говорю. Но как говорится попытка не пытка ;)
Не берусь утверждать, но кажется этот совет хороший для программиста, но не для универсала,
кто пилит всё и графоний и программу. Больше сил и времени уйдёт, лучше посоветовать более простой инструмент. Но я не смотрел DirectX SDK, просто одно название пугает, что там слишком много всего надо изучать. Мне самому как человеку, что быстро бросает проекты и легко теряет мотивацию (мне кажется Разери также, но это не точно) сложные инструменты ещё больше отнимут времени и не останется мотивации на разработку самой игры.
PS юнити, кстати тоже не самый лёгкий инструмент, лично я его изучал, потому-что на то время он был доступнее других, хотя сейчас думаю переходить на другой более лёгкий движок, типа Game Maker или может что-то ещё, чем проще конструктор, но всё ещё на нём легко делать любую игру (2D), тем лучше.
Вот именно.
Мне кажется, что инструмент для работы должен быть сложен ровно настолько, насколько это действительно нужно.
И поэтому решил использовать трёхмерный движок для двухмерной игры, oh boy, here we go again... (нет, я устал уже от этой бойни подушками из несделанных проектов)
Видимо, ты не мне отвечал тут, а Мегаинформатику.
потому что 3д даже 2д делает лучше
https://cv1.pikabu.ru/video/2020/02/12/1581536812257880628_720x404.webm
> лучше
> просто закрываются другие углы чем ранее
Ну не знаю.
Так это и в 2д реализуется обычном. Чего-то эксклюзивно 3дшного как раз не показано.
Если бой подушками происходит ещё и в пижамах, то это норм тема.
Игра на Юнити не обязана включать в себя какой бы то ни было 3D-контент, и там не нужны никакие костыли для работы с 2D-графикой, это движок для игры любого жанра и вида, я бы так сказал.
А на гамаке тоже можно с 3D работать, пример - бумажное подземелье :P
Тут ты прав, но это про графику. Я про 2D-пространство. Ну вот я загуглил как перемещаться например по нажатию стрелок:
И уже сразу трёхмерный вектор, лишний ноль в скобках, ещё и сраный дельтатайм.
Потому что Unity3D - движок трехмерный и все объекты в нем находятся в трехмерном пространстве.
Поэтому position, rotation, scale у трансформов (положение объекта) - всегда трехмерные. Что тебе не нравится в deltaTime - не понятно.
там вроде можно юзать и Vector2, лень тестить, но вроде у меня раньше работало, или это было в JS,
точно не помню)
В Юньке наблюдение за игровым полем осуществляется через т.н. "камеру" - объект, имеющий определённое положение в пространстве и, в следствие этого, определённую зону видимости.
И меняя координату Z камеры, мы меняем... просто напросто уровень масштабирования/охват изображения на экране.
Что-то вроде зума, приближения/отдаления на колёсико мыши.
Реализуемое гоооораздо проще и быстрее (в плане кода), чем если бы нам пришлось это делать трансформацией исходного изображения после построения всей нужный графики перед выводом каждого следующего кадра.
Так что как минимум в объекте камеры третья координата полезна.
Что касается также взаимодействия с векторными параметрами - подчеркну, я пока что изучил движок не слишком крепко, так что инфа не соточка, но скорее всего: менять можно не только вектор целиком, но и отдельный его компонент, например:
transform.position.X += ...
... что должно при определённых обстоятельствах лишать нас необходимости прописывать в коде не интересующие нас, относящиеся к третьему измерению, компоненты.
Думаю, в операциях задавания поворота спрайта это должно быть ярко выражено.
Но мы это проверять конечно же не будем я это ещё посмотрю и, если ошибся, отпишусь тут.
Также, если испугало выражение Input.GetAxis("Horizontal") - то в "Horizontal" хранятся значения клавиш, отвечающих за горизонтальное перемещение (в данном случае камеры) - как в "положительную сторону", так и в "отрицательную", а сама конструкция целиком ещё и даёт нам информацию, какие именно из этих клавиш нажаты и куда нужно производить движение.
Т.е., это на самом деле довольно компактная форма записи, лишающая нас необходимости писать довольно много кода.
Если сравнивать с Löve, конечно.
низя transform.position.x ридонли тип.
меняя координату Z камеры мы меняем именно физическую z координату на сцене. и если ты переключишься в орфопроекцию(а это то что тебе скорее всего надо в 2д) все увеличение пропадет. для филд оф вью камеры есть филд оф вью.
третья координата геймобжекта обычно это бек- и форвардграунды. в марк оф нинджа туда еще периодически сдвигается коллайдер, похоже, чтобы обеспечить невзаимодействие с чужими коллайдерами видимости когда герой прячется за дверью например. в дабл драгоне это может быть физическое перемещение героя ближе-дальше(вверх-вниз) по игровой площадке
Эх, а я думал - вот круто Разери всё написал. Ну что за. XD
Хотя вот это прикольно.
В скриптах не на шарпе вроде можно.
Это кстати меня парит, потому-что в JS можно было спокойно работать с одной осью,
я всегда писал типа, но в C# нужно больше символов кода к сожалению:
trans.position.x += 0.1f;ты видяшки посмотрел юньковские туториалы? там все от построения базовой 2d сцены до анимирования, постеффектов и генераций. после них учебник тебе нужен будет тольк по спецфическим вещам типа шейдеров
Да, но кто так вообще делает, лол.
Спасибо за объяснение, конечно.
А что думаешь про дельта-тайм?
я deltaTime вообще не использую, лол, сейчас мой пост закопают лопатами :3
просто я пишу все перемещения в FixedUpdate, там фиксированно всё движется,
но есть некоторые специфические минусы такого способа, но как ни крути,
все объекты перемещаются по отношению друг к другу одинаково, даже если это не правильно
с точки зрения профи.
Хотя только недавно задумался, сейчас пока переписываю код с нуля c JS на C#, возможно тут уже буду использовать deltaTime.
Мне просто не особо нравится дополнительно умножать всё и вся на дельту,
чтобы независимо от частоты кадров всё перемещалось одинаково фиксированно,
мне приходится делать зависимость от кадров FixedUpdate, потому-что люблю более простой код.
Я думаю, что всё равно имеет смысл умножать на дельту, даже если она постоянная. Ведь потом можно захотеть поменять количество физических тиков, и физика сломается.
Мне всё равно не нравится писать лишние символы)
А можно там дельту определить например в скрипте Game и потом ссылаться на неё?
так хотя бы меньше символов будет, ну например:
В скрипте Game (delta статичная float):
delta = Time.deltaTime;В других скриптах (это всё короче, чем Time.deltaTime):
trans.position += new Vector2(0.1f,0) * Game.delta;Если делать через свойство, то в принципе да.
Для ортографического режима камеры (часто в 2д используется) бесполезна Z ось), но если там перспектива,
несмотря на то что изображение 2D, то да, у меня в игре про пони камера была не ортографическая,
и Z ось там могла работать при желании.
Дельта-тайм с одной стороны правильно, потому что юнити не прибит гвоздями к 60 фпс, там может быть и 216 фпс и 30, а двигаться игрок должен с одинаковой скоростью.
А неправильно т.к. более сложная физика (те же прыжки) с нефиксированным дельтатаймом все равно пойдет вразнос, так что в этих случаях лучше управлять объектом с помощью физики а не прибавляя скорость к координате. Но это уже вопрос к авторам туториала. Для симулятора ходьбы формула вполне подойдет.
то есть можно и не юзать дельту?
Просто я обычно все перемещения переношу в FixedUpdate и не умножаю на дельту,
вроде косяков особо не было, во всех моих играх такой подход используется,
и вроде никто не жаловался что где-то персонаж быстрее или медленнее ходит.
Хотя если присмотреться, то есть рывки)
Ну да, меня этот мусор типа deltaTime в в коде логики тоже бесит. Он для каких-нибудь визуальных эффектов, партиклы там включить\выключить, не для перемещения.
В крайнем случае ты всегда сможешь свой MyFixedUpdate сделать на базе Update, парой строк сравнив deltaTime с требуемым.
Хотя умножать на какую-нибудь константу есть смысл т.к. размерность у скорости и координаты все-таки разная. Удобнее же скорости не в абстрактных пикселях хранить, а скажем в тайлах\секунду.
Я на дельту умножаю в своих играх только когда игра стоит на паузе и FixedUpdate не работает.
Там нужно время подгонять, чтобы движения окон и курсора и эффектов не было быстрее в зависимости от частоты кадров.
Лишний ноль тут добавлен просто потому что (указывание z компонента опциально даже для 3Д вектора). Можно создать и двухмерный вектор (они с трехмерным нормально друг с другом работают), но по факту разница между применением двухмерного и трехмерного векторов в 2Д в юнити сводится к цифре в типе класса.
Дельтатайм нужен для вменяемого передвижения вне зависимости от кадровой частоты. 2Д или даже юнити тут ни при чем, насколько мне известно.
> Дельтатайм нужен для вменяемого передвижения вне зависимости от кадровой частоты. 2Д или даже юнити тут ни при чем, насколько мне известно.
Для вменяемого перемещения нужно сделать физику которая вызывается с шагом физики (как правило фиксированным, т.к. это сильно упрощает алгоритмы интегрирования), а не привязывать обработку логики к отображению кадров.
Но для простых примеров да, можно и дельтатайм.
ну перемещение же не обязано быть связанным с физикой
Я так понял, это спокойно заменяется на "геометрию которая вызывается с шагом геометрии".
дельтаТайм применяется во втором случае чтобы скорректировать фреймрейт, чтобы перемещение(или любой другой процесс во времени) не зависел от частоты кадров. Те две строчки которые ты процитировал уже полностью обеспечили тебе стабильное перемещение объекта по двум осям. Почему бы ими не пользоваться?
фикседДельтаТайм нужен в третьем, при расчете процессов связанных с физикой потому что физика тикает стабильно, независимо от фпс
У меня вопрос в контексте выбора движка - почему это не встроено в движок уже изначально? Есть ли причины дельтаТайм НЕ использовать?
ну всмысл?
перемещение можно организовать бесятком разных способов; оси инпута можно использовать сотней разных способов; процессы происходящие во времени могут быть привязаны к фпс а могут и нет; дельта тайм вроде учитывает внутренний таймСкейл, но иногда такая зависимость не нужна и можно пользоваться коэффициэнтом системного времени.
это удобная поправка которую хошь ставь хошь не ставь, в зависимости от задачи. И вопрос скорее не в том почему дельтаТайм не встроен в процессы, а зачем бы вообще добавлять неизвестную величину неочевидно где-то откуда-то на все влияющую, когда сейчас ее можно сознательно добавить куда угодно шестью тыцами по клавиатуре
Тут ты прав, но код выглядит так, будто не использовать его нельзя. Если можно не использовать, уже лучше.
Меня самого тоже коробило от такого написания кода, но потом привык :)
Я просто люблю короткие операторы в коде, а в юнити получается так что целые предложения получаются.
Мне б больше зашло, если бы этот самый код выглядел меньше, хотя бы на чуть-чуть я б его легче запоминал:
но этот код не рабочий, юнити не хотят превращать это долгое GetAxis("Horizontal") просто в X,
в юнити есть и более страшные большие названия, хотя бы вспомнить
состояние SendMessageOptions.DontRequireReceiver, которое могло быть в разы короче.
Я отдельно сделал для себя файл, где все эти длинные операторы записаны,
я не особо умею работать с автозаполнением, мне проще кусок кода скопировать, который я ранее уже писал,
типа snippets, но даже так, я теряюсь в огромных текстах, если бы там меньше было бы символов,
я б меньше терялся в коде юнити.
Ну, это второй конец палки под названием "гибкость". Horizontal - всего лишь название оси. Ты можешь ее переименовать, а можешь создать еще парочку осей для разных ситуаций (например, если тебе вдруг надо сделать два набора осей для игры двух игроков на одной клаве). Поэтому предварительно придуманные свойства не совсем подходят.
Кстати, да, я сделал дополнительный скрипт "Key" , это как Input, только с моим личным переопределением
клавишь, ибо в юнити переопределение клавишь ужасное, в этом превью перед запуском игры окне.
И дельту сделал статичной переменной в скрипте Game, хотя саму дельту редко использую.
Теперь мой код выглядит заметно короче, и он рабочий, минус только в том, что пришлось делать 2 дополнительных скрипта Key и Game)
А в итоге, с этими дополнительными скриптами, у меня в JS версии юнити игры где-то дополнительных 150 скриптов) теперь я конечно сокращаю переписывая на C#, предположительно их будет где-то 30, вместо 150-ти, с тем же функционалом
PS transform я тоже люблю сокращать при инициализации,
как и rigidbody и collider, не люблю все эти длинные юнитовские названия, хотя бы чуть-чуть короче выходит:
Transform trans = transform;Rigidbody rigid = GetComponent<Rigidbody>();Collider2D coll = GetComponent<Collider2D>();PPS Раз уж пошла такая пьянка про сокращения, я ещё подумываю сократить ужасно длинную команду
добавив статическую функцию в скрипт Game,
чтобы в итоге можно было писать без SendMessageOptions.DontRequireReceiver
а то надоело вспоминать, куда я этот snippets подевал c SendMessageOptions.DontRequireReceiver
PPPS блин, я ошибся, тут же куда-то надо gameObject добавить, тогда чуть длиннее(
У меня культурный шок от того что люди хвалятся тем как СОКРАЩАЮТ названия вместо разработки игры. А особенно от вот этого:
То есть, ну, в ГМе это вообще не нужно - нет никакого объекта коллайдера, потому что это просто лишняя абстракция. Есть событие коллизии, и это уже и есть конечная точка архитектуры проекта, ведь зачем тебе коллайдер если у него не прописаны коллизии? (физические симуляции сейчас не обсуждаем, для них там есть fixtures, joints и прочая мура, но зачем вообще физическая симуляция в игре кроме как для понтов, либо если игра ПОЛНОСТЬЮ об этом как Angry Birds, Gish и так далее)
Ксит, ну я уже говорил, я б давно юзал тот же гейм мейкер, если бы мне его дали бесплатно,
но мне дали бесплатно только юньку, так что пришлось вот так вот извращаться)
Может чуть позже, я всё таки куплю GM, ибо давно хочу перейти на простой язык и редактор.
Мне дали бесплатно Game Maker 6.0 в 2006 году.
В 2012, когда я пришёл на Гамин, я всё ещё пользовался бесплатным Game Maker 8.1 Lite. Да, там был их (не интерактивный и без ссылки) баннер при загрузке игры, но и делов-то.
Замок Невозврата 2 практически полностью создан на функционале доступном в бесплатной тестовой версии без лицензии (потому что это примерно 90% функционала). Стоил он правда $25, а современный даже по региональной цене больше. Хочешь сэкономить - бери 1) в Стиме, сконвертируешь в админке потом в не-Стимовую; 2) во время распродажи; 3) Я же уже сказал что могу подарить тебе копию.
А ещё, за 30 дней триалки тебе кристально ясно будет, твой это инструмент вообще или нет. Зачем платить деньги, если оно не твоё и ты его никогда не используешь уже купленный. Будь реалистом.
Да я как раз хочу поизучать 8.1 демо версию, там нет ограничений по времени,
а в новом гамаке уже кончилось. Пока я возился с юней, так и не мог выделить время на изучение GM. Я б конечно не отказался от подарка :3
C# в Юнити отстоен в своей перегруженности, это верно.
Но это всё равно лучше Гамака, это же все знают.
Лучше, разумеется. Для строго определённых классов игр - 3D, MMO, ассет-флипы.
brofoce, getting over it, kingdom rush, pony island, night in the woods
Это типа реквест чтоб я показал что каждую из них можно сделать быстрее чем они делались исторически? Потому что можно. Делать я это, конечно, не буду, т. к. хоть это и будет отличаться по скорости в разы, всё равно делать игры это существенно долго. Вторая причина - клонировать всегда быстрее чем делать с нуля - это в свою очередь не клоны чего-то предыдущего, поэтому если даже сделать быстрее, как отделить одно ускорение от другого. А вот как - надо сделать ТЗ и снять полное видео как делается игра строго по нему. Однажды и такой джем стоило бы провести. На самом деле я с Джаззом об этом думал ещё в 2013 году, но как-то. Правда там было не о движках, а вообще просто "кто что может сделать по готовому ТЗ".
А могли бы вместо флуда что-то для джема делать.
Как я, например.
Я так и не смог выбрать сюжет, как-то не вкатил ни один. Прикольная гора и кристаллы. И кажется что виг-вамы тоже из камня, забавно.
Кстати, можно нескромный вопрос?
Сколько у меня должно быть примерно баллов по Шпиль-Крафт-Верку? :D
322-332-321-4, я думаю.
==^_____^==
нет, конеш. у нас же джентльменская беседа. "я считаю, что на другом инструменте я сделаю тоже самое быстрее" для мня достаточный аргумент. в принципе
Да, но... на самом деле, я бы сделал такое. Но не в этом месяце. И году. И. Или.
Насколько я понял, в Юньке это просто отдельный класс/скрипт,
к которому надо ещё подключиться, чтобы начать с ним работать,
этот момент меня также и в Юне и в Годоте бесил) я хочу чтобы в одном объекте у меня сразу было всё сразу и проверка коллизии, и физика и трансформации объекта в одном, а не в трёх разных скриптах/классах.
Чисто если для себя скрипт столкновений писать, то у меня в одном классе будет всё сразу,
как я сделал в Lua на Тик-80, и скорее всего могу повторить на Юнити, но минус только в том,
что я не математик и могу проверять столкновения только с прямоугольными объектами
и у которых не меняется угол наклона, поэтому приходится подключать всю эту сложную структуру(
чтобы столкновение было и с другими формами.
пушто у коллайдера есть куча свойств на все случаи жизни, пушто коллайдер и ригидбодий это разные вещи, пушто коллайдеры разные и рассчитывают разные коллизии и настраиваемо взаимодействуют по слоям, пушто в большинстве случаев коллизии и коллайдеры не нужны и можно их не вешать
Да, но мы тащим их в каждый коллайдер без вариантов, насколько я понял. Это означает автоматический оверхед там, где его никто не просил. Посмотрел ссылку, ну, если взять все эти коллайдеры и ригидбоди, то функционал такой же как у fixtures/joints/встроенные коллизии (см. Collision masks), просто в 3D. Но самое легковесное это, конечно, прямая проверка координат без масок и СМС.
Тут согласен.
Честно говоря, большой недостаток кодинга в юньке в том, что практически каждый объект наследуется от монобеха, который наследуется от юньковского объекта, таким образом всем кастомным компонентам достается весь багаж наследованных переменных и методов. Поэтому я люблю интерфейсы.
Так ведь ничего делать не надо, второй и третий параметры опциональные.
будет нормально работать
Серьёзно? Просто на старой юньке, у меня постоянно были ошибки, если например в объекте не было функции MyFunc на некоторых объектах, с тех пор и добавляю третье свойство.
То есть теперь SendMessageOptions.DontRequireReceiver уже не нужна, даже если этой функции нет в объекте?
А, я не совсем правильно понял твое сообщение. Подумал, что тебе в принципе не нравится третий параметр. Если тебе нужно конкретное значение, отличимое от стандартного в методе, тогда не, забудь, надо указывать.
Окей! Жаль эта функция не по дефолту.
Просто я часто использую для разных вещей, и в особенности проверка урона.
Ну например я ударяю мечом, и все кто попадают в радиус коллайдера отправляю сигнал
"Hurt", но бывает так что не на всех объектах есть в принципе вообще проверка урона и функция Hurt.
Или при BroadcastMessage когда отправляю массово всем чайлдам какое-то сообщение, тоже не у всех есть нужная функция.
> Я не стал нырять в это болото, так как знаю о чем говорю.
Странное высказывание.
Очень похоже на мою текущую личную жизнь.
Мож пора это, отдельные посты для обнов создавать? А то секция комментов уже подвисать начинает.
Бесконтрольно делиться и жить своей собственной жизнью.
Наверное можно, но уж тогда раз в цикл или раз в два цикла, для того чтобы побольше полезной инфы было.
го второй сезон аниме Про перерождения в слизня
и еще строчку по каждому комменту в пост, чтобы в динамике видеть
Т.е. чтобы пост сам по себе состоял из кусков информации в духе:
- результаты цикла рисования N
- результаты цикла погромирования N
- результаты цикла музыки N
- результаты цикла рисования N +1
- результаты цикла погромирования N +1
- результаты цикла музыки N +1
и так далее?
Можно.