Скажу больше - чатГПТ отлично понимает русский язык) можно написать буквально следующее:
"Хочу, чтобы при нажатии на карту она увеличивалась, переворачиваясь лицевой стороной вверх, а остальные карты уменьшались, раздвигаясь на ширину увеличения карты"
которую может было бы реализовать применив простейшее наследование.
О да, Но я вроде как и понимаю, что нужно делать, а вот как сделать - не выходит. Сильно не хватает теоретической базы, видео и книги помогают, но прогресс идет очень медленно
делается профессионалами на колленках
Согласен с тем, что это тоже большой труд. Более того - все эти мини-игры с мисслидовскими рекламами тоже сложно делать. Многие считают, что мобилки ими переполены, но только представьте, как в такой конкуренции сложно сделать игру, которую а) заметят игроки, б) игра им понравится и в) которая будет приносить доход, покрывающий все расходы на нее.
Если посмотреть с этой стороны, то выбор жанра имеет смысл - конкуренции в нем все так же много, но обычно разработка таких игр - очень дорого. Прям совсем очень. Не многим профессиональным командам удается завершить игру к техланчу - не говоря уже о том, чтобы выпустить ее хоть как-то. А у меня из расходов - дошик да квартплата))
не о какой расширяемости и речь идти не может
К счастью для минимальной версии расширяемость мне особо не нужна)) Ее задача - проверить r1 (сколько поигравших игроков вернутся в игру на следующий день). Если с ней все будет хорошо - то все проблемы с кодом сами собой отпадут (будет проверенная гипотеза, что игроки готовы в такое играть = можно кидать деньги в разработку). Если с ней все будет плохо - то беспокоиться тем более смысла нет.
Хотя я согласен с тем, что подходить к разработке нужно грамотно, а не с наскока как я.
нет диздока твоей игры, хотя бы в формате концепта или списка игровых механик
На самом деле, все не так плохо) Есть заранее продуманный список фичей, которые нужны для минимальной версии. Пока что серьезные проблемы только с фичей, которую делаю сейчас - ее в первоначальном списке не было. Тут, действительно, не уследил, когда анализировал референсные игры и похожие механики.
Еще, действительно, есть проблема в планировании - довольно неграмотно декомпозировал фичи на задачи, отчего порядок их внедрения пришлось менять
не понятно что ты собственно говоря хочешь сделать
О, тут я старательно нагнетаю интригу) Полное объяснение всех механик и причин, почему были выбраны именно они, хочу сделать в одной из последних статей (впрочем, до нее осталось недолго). По задумке получится как книга, где в последней главе все объясняется, и читатель складывает разрозненные ранее кусочки паззла в единую картину)
Меня остановило то, что так уже сделано в скрипе Spawner)
На этот момент на сцене уже есть куча деактивированных героев и противников - и абсолютно все массивы в других скриптах, где используются герои, ссылаются именно к ним. Проблема с тем, чтобы как-то либо создать копию героя (причем нужен только визуал), либо имеющегося героя активировать и ставить в нужное место.
Подумал, что второй вариант - это как-то слишком. Зачем мне там нужен герой, который умеет находить противника, драться и все такое? Так что решил сделать что-то вроде визуального клона. Но, для того, чтобы не создавать еще кучу объектов, сделал всего один, которому и присваиваю нужный визуал. Пока что это просто спрайт, но и с анимацией проблем возникнуть не должно.
Хотя очень может быть, что я ошибаюсь и вообще делаю неправильно - наверняка есть способы и проще, и производительнее
Хмм, возможно, и выложу в открытый доступ. Только нужно будет перед этим подумать о безопасности игроков: и как и выложить код, и как сделать так, чтобы при этом никакие данные игроков при этом нельзя было получить + никак на эти данные повлиять. Пока не смотрел, как делается серверная часть - может, будет достаточно просто не публиковать то, что с ней связано
Пожалуй, воспользуюсь советом, пока не стало сильно поздно - спасибо!
Спасибо! Да, мне и самому не нравится передавать в метод больше одного (!) значения) всячески стараюсь такое избегать) Про структуру вроде понял - получится, вместо условного (int aa, int bb, ..) сделать условную (MyStruct numbers)
Хмм, про settings.StartLevel = 1; нужно подумать - примерно понял, что мне это даст, но надо продумать детали. Спасибо!)
Изначально хотел сделать, чтобы смерть противника просто увеличило какое-нибудь число в этом скрипте (что-то типа "int totalDead++"), и просто сравнивать if (totalDead >= ActiveEnemies.Count). Но чисто гипотетически возможна способность воскрешения. И, вроде бы, при этом можно делать так "totalDead--", но мне почему-то кажется, что тогда обязательно появятся баги. Но спасибо - нужно будет потестировать.
P.S. Сейчас подумал - хотя нет, я как-то иначе хотел сделать. Написанный сейчас вариант вроде как более чем рабочий
В общем, верно, да) немного спойлеров: тут описаны не все детали) глобально все то же самое, но часть кода раньше времени может анонсировать мое видение проекта, которое несколько отличается от референсного лабиринта из AFK arena
На самом деле, проблема есть ещё с планированием. За один присест выполнять три пункта из фичей - это как-то слишком. Очень желательно разнообразие задач и чредовать разные типы. Например, делать фичу - делать сервер - делать фичу - заняться аналитикой - ну и так далее
Поддержу. Ещё может помочь аналитика - я завел табличку, в которой отслеживаю реакцию на печатаемые статьи. Указываю, какие изменения вношу и какие выводы делаю, исходя из реакции. Думаю, это поможет сделать вот эти посты интереснее)
И самое главное! Прям самое-самое, это основа всего. Тебе самому должно быть интересно писать статью. Веселись, когда ее пишешь, дурачся. Получай удовольствие от ее написания.
А с аналитикой должно быть интересно разбирать реакцию читателей. То же самое - если при составлении веселишься и получаешь удовольствие, то все хорошо.
Ну и вишенкой на торте (уже после использования всех советов) - попадание в целевую аудиторию. Мои статьи пока что сильно мимо - ищу такой баланс, который будет и интересно читать, и больше соответствовать характеру хабра
Но тут не только опытные профессионалы читают статьи - возможно, кто-то хочет сделать игру, но его отпугивает, что "программирование - это сложно". А тут наглядный пример, что это вообще не помеха.
Кроме того, есть много статей из разряда "делал игру - наступил на все грабли", но они не дают представления, на какие именно. А тут буквально описаны все грабли, на которые можно наступить при разработке)) По сути, одна из задач этих статей - передать опыт самого процесса создания игры)
Вообще, крупным играм стоит поучиться у мобилок - как минимум в интерфейсах. Мобилки для удержания игрока стараются быть максимально комфортными и удобными в интерфейсах, чего не скажешь о крупных играх...
Если взять тот же рейд шадоу легендс, который из каждого утюга звучит, то можно увидеть, что он ставит перед игроком достаточно задачи, над которыми ему приходится думать)
Но при этом оформлен он в достаточно простую форму по восприятию. Ну а так да - побеждает обладатель самого толстого кошелька
То, какую игру создавать (стратегию или тупой автобаттлер), диктует не только желание автора (или авторов) сделать что-то именно в таком жанре, но и рынок. А рынок показывает, что такие автоигры зарабатывают гораздо больше, чем стратегии.
Из этого можно сделать косвенный вывод и о том, что игрокам интересно - ну не будут они платить за неинтересные им игры.
Игры - это бизнес. Даже авторы инди игр считают, что их игра понравится выбранной целевой аудитории, и большая часть таких авторов рассчитывает на то, что игра, над которой они трудятся, принесет им деньги.
Вообще, связка "творчество vs коммерция" довольно интересная тема)
Ну и кроме того, подобные игры только выглядят просто. Они и сделаны для того, чтобы выглядеть просто - так они собирают большую аудиторию. Но я согласен, что у многих таких игр нет при этом достаточной глубины.
p.s а что плохого в современном гейминге?)) Недавно вышла "pathfinder wrath of the righteous" - у меня на нее слюнки текут)
Согласен с тем, что учиться нужно - как и грамотно подходить к написанию проекта. Но и в таком "безалаберном" подходе есть свои плюсы)
Во-первых, обучение в процессе. Все эти подводные камни, о которых сотни раз написано, гораздо лучше усваиваются на практике (нуу, у меня xD)
Во-вторых... С таким подходом я не осознаю всей сложности того, за что я взялся. Если бы я хорошо понимал, насколько это сложно, я бы 100% не начал делать эту игру xD
И в третьих, у меня позиция такая: если не умеешь что-то делать, это не значит, что ты не можешь сделать что-то классное))
И просто пример того, что незнание программирования не должно останавливать от попыток сделать то, что хочешь))
Тут даже со своим скиллом понимаю ,насколько все плохо в видео)) Но она выпущена, работает и собирает деньги!
Скажу больше - чатГПТ отлично понимает русский язык) можно написать буквально следующее:
"Хочу, чтобы при нажатии на карту она увеличивалась, переворачиваясь лицевой стороной вверх, а остальные карты уменьшались, раздвигаясь на ширину увеличения карты"
И он выдаст код))
О да, Но я вроде как и понимаю, что нужно делать, а вот как сделать - не выходит. Сильно не хватает теоретической базы, видео и книги помогают, но прогресс идет очень медленно
Согласен с тем, что это тоже большой труд. Более того - все эти мини-игры с мисслидовскими рекламами тоже сложно делать. Многие считают, что мобилки ими переполены, но только представьте, как в такой конкуренции сложно сделать игру, которую а) заметят игроки, б) игра им понравится и в) которая будет приносить доход, покрывающий все расходы на нее.
Если посмотреть с этой стороны, то выбор жанра имеет смысл - конкуренции в нем все так же много, но обычно разработка таких игр - очень дорого. Прям совсем очень. Не многим профессиональным командам удается завершить игру к техланчу - не говоря уже о том, чтобы выпустить ее хоть как-то. А у меня из расходов - дошик да квартплата))
К счастью для минимальной версии расширяемость мне особо не нужна)) Ее задача - проверить r1 (сколько поигравших игроков вернутся в игру на следующий день). Если с ней все будет хорошо - то все проблемы с кодом сами собой отпадут (будет проверенная гипотеза, что игроки готовы в такое играть = можно кидать деньги в разработку). Если с ней все будет плохо - то беспокоиться тем более смысла нет.
Хотя я согласен с тем, что подходить к разработке нужно грамотно, а не с наскока как я.
На самом деле, все не так плохо) Есть заранее продуманный список фичей, которые нужны для минимальной версии. Пока что серьезные проблемы только с фичей, которую делаю сейчас - ее в первоначальном списке не было. Тут, действительно, не уследил, когда анализировал референсные игры и похожие механики.
Еще, действительно, есть проблема в планировании - довольно неграмотно декомпозировал фичи на задачи, отчего порядок их внедрения пришлось менять
О, тут я старательно нагнетаю интригу) Полное объяснение всех механик и причин, почему были выбраны именно они, хочу сделать в одной из последних статей (впрочем, до нее осталось недолго). По задумке получится как книга, где в последней главе все объясняется, и читатель складывает разрозненные ранее кусочки паззла в единую картину)
И спасибо за критику!
Зато интересно!)
Меня остановило то, что так уже сделано в скрипе Spawner)
На этот момент на сцене уже есть куча деактивированных героев и противников - и абсолютно все массивы в других скриптах, где используются герои, ссылаются именно к ним. Проблема с тем, чтобы как-то либо создать копию героя (причем нужен только визуал), либо имеющегося героя активировать и ставить в нужное место.
Подумал, что второй вариант - это как-то слишком. Зачем мне там нужен герой, который умеет находить противника, драться и все такое? Так что решил сделать что-то вроде визуального клона. Но, для того, чтобы не создавать еще кучу объектов, сделал всего один, которому и присваиваю нужный визуал. Пока что это просто спрайт, но и с анимацией проблем возникнуть не должно.
Хотя очень может быть, что я ошибаюсь и вообще делаю неправильно - наверняка есть способы и проще, и производительнее
Ахах, спасибо xD
Хмм, возможно, и выложу в открытый доступ. Только нужно будет перед этим подумать о безопасности игроков: и как и выложить код, и как сделать так, чтобы при этом никакие данные игроков при этом нельзя было получить + никак на эти данные повлиять. Пока не смотрел, как делается серверная часть - может, будет достаточно просто не публиковать то, что с ней связано
Пожалуй, воспользуюсь советом, пока не стало сильно поздно - спасибо!
Спасибо! Да, мне и самому не нравится передавать в метод больше одного (!) значения) всячески стараюсь такое избегать) Про структуру вроде понял - получится, вместо условного (int aa, int bb, ..) сделать условную (MyStruct numbers)
Хмм, про settings.StartLevel = 1; нужно подумать - примерно понял, что мне это даст, но надо продумать детали. Спасибо!)
Изначально хотел сделать, чтобы смерть противника просто увеличило какое-нибудь число в этом скрипте (что-то типа "int totalDead++"), и просто сравнивать if (totalDead >= ActiveEnemies.Count). Но чисто гипотетически возможна способность воскрешения. И, вроде бы, при этом можно делать так "totalDead--", но мне почему-то кажется, что тогда обязательно появятся баги. Но спасибо - нужно будет потестировать.
P.S. Сейчас подумал - хотя нет, я как-то иначе хотел сделать. Написанный сейчас вариант вроде как более чем рабочий
Спасибо! Поищу ещё такие моменты)
В общем, верно, да) немного спойлеров: тут описаны не все детали) глобально все то же самое, но часть кода раньше времени может анонсировать мое видение проекта, которое несколько отличается от референсного лабиринта из AFK arena
На самом деле, проблема есть ещё с планированием. За один присест выполнять три пункта из фичей - это как-то слишком. Очень желательно разнообразие задач и чредовать разные типы. Например, делать фичу - делать сервер - делать фичу - заняться аналитикой - ну и так далее
Спасибо!) Обязательно что-нибудь такое добавлю)
+
Статьи в первую очередь должны быть интересными. Если при этом полны технических деталей, то это вдвойне кайф)
Кстати, в следующей серии статьи протестирую)))
Поддержу. Ещё может помочь аналитика - я завел табличку, в которой отслеживаю реакцию на печатаемые статьи. Указываю, какие изменения вношу и какие выводы делаю, исходя из реакции. Думаю, это поможет сделать вот эти посты интереснее)
И самое главное! Прям самое-самое, это основа всего. Тебе самому должно быть интересно писать статью. Веселись, когда ее пишешь, дурачся. Получай удовольствие от ее написания.
А с аналитикой должно быть интересно разбирать реакцию читателей. То же самое - если при составлении веселишься и получаешь удовольствие, то все хорошо.
Ну и вишенкой на торте (уже после использования всех советов) - попадание в целевую аудиторию. Мои статьи пока что сильно мимо - ищу такой баланс, который будет и интересно читать, и больше соответствовать характеру хабра
Понимаю недовольство и даже согласен с ним)
А ответ "зачем" дал в комменте выше)
Понимаю) и понимаю, почему минусы)
Но тут не только опытные профессионалы читают статьи - возможно, кто-то хочет сделать игру, но его отпугивает, что "программирование - это сложно". А тут наглядный пример, что это вообще не помеха.
Кроме того, есть много статей из разряда "делал игру - наступил на все грабли", но они не дают представления, на какие именно. А тут буквально описаны все грабли, на которые можно наступить при разработке)) По сути, одна из задач этих статей - передать опыт самого процесса создания игры)
Вообще, крупным играм стоит поучиться у мобилок - как минимум в интерфейсах. Мобилки для удержания игрока стараются быть максимально комфортными и удобными в интерфейсах, чего не скажешь о крупных играх...
Если взять тот же рейд шадоу легендс, который из каждого утюга звучит, то можно увидеть, что он ставит перед игроком достаточно задачи, над которыми ему приходится думать)
Но при этом оформлен он в достаточно простую форму по восприятию. Ну а так да - побеждает обладатель самого толстого кошелька
Ох отхвачу щас минусов... Но да ладно.
То, какую игру создавать (стратегию или тупой автобаттлер), диктует не только желание автора (или авторов) сделать что-то именно в таком жанре, но и рынок. А рынок показывает, что такие автоигры зарабатывают гораздо больше, чем стратегии.
Из этого можно сделать косвенный вывод и о том, что игрокам интересно - ну не будут они платить за неинтересные им игры.
Игры - это бизнес. Даже авторы инди игр считают, что их игра понравится выбранной целевой аудитории, и большая часть таких авторов рассчитывает на то, что игра, над которой они трудятся, принесет им деньги.
Вообще, связка "творчество vs коммерция" довольно интересная тема)
Ну и кроме того, подобные игры только выглядят просто. Они и сделаны для того, чтобы выглядеть просто - так они собирают большую аудиторию. Но я согласен, что у многих таких игр нет при этом достаточной глубины.
p.s а что плохого в современном гейминге?)) Недавно вышла "pathfinder wrath of the righteous" - у меня на нее слюнки текут)
upd: узнал, что не выпущена. Но, тем не менее, есть рабочая версия. Будем считать, что имел ввиду именно это
Согласен с тем, что учиться нужно - как и грамотно подходить к написанию проекта. Но и в таком "безалаберном" подходе есть свои плюсы)
Во-первых, обучение в процессе. Все эти подводные камни, о которых сотни раз написано, гораздо лучше усваиваются на практике (нуу, у меня xD)
Во-вторых... С таким подходом я не осознаю всей сложности того, за что я взялся. Если бы я хорошо понимал, насколько это сложно, я бы 100% не начал делать эту игру xD
И в третьих, у меня позиция такая: если не умеешь что-то делать, это не значит, что ты не можешь сделать что-то классное))
И просто пример того, что незнание программирования не должно останавливать от попыток сделать то, что хочешь))
Тут даже со своим скиллом понимаю ,насколько все плохо в видео)) Но она выпущена, работает и собирает деньги!
Но опять же - соглашусь ,что обучение важно
Нууу, в моем понимании, база данных - просто способ представления информации 😅 типа json, xml и так далее - просто формат данных
Судя по всему, я сильно заблуждаюсь) когда вернусь к этому пункту, поизучаю, как обстоят дела на самом деле