которая позволяет не заботиться о таких бессмысленных вещах, как MVC, разделение на компоненты, и прочих). Простота GDScript позволяет писать большие куски кода, которые будут «попросту работать»,, после чего у вас не будет возникать желание вернуться к ним.
Ясно понятно. А потом мы удивляемся, откуда в играх столько нелепых багов, которые разработчики починить месяцами не могут. Нуачо, "просто работает" же, "желания вернуться" не возникает.
Если брать архитектуру движка, то она позволяет достаточно удобно работать с объектами и ресурсами игры. От основных движков этот отличает всё-таки архитектура, которая работает с нодами и не позволяет, например повесить больше 9000 компонентов на объект. Советую попробовать движок в деле.
"Ведущим программистам нужен чистый и организованный код, что приводит к увеличению времени разработки. Аргументируют такой подход тем, что «мы должны быть готовы заменить программистов в любой момент, поэтому код должен быть читабельным и поддерживаемым». В действительности, такая разработка займет больше времени и едва ли окупится в долгосрочной перспективе."
На счет этого не очень согласен, если проект большой и с большим термином поддержки, то возможность заменить разработчиков в любой момент времени все таки выше, чем "написать побыстрее". Для проектов с коротким циклом жизни (до 2х лет) - самое то.
Я сомневаюсь что автор вообще где-то работал программистом, не говоря уж о лиде и техническом директоре. Автор на уровне джуна, нет представление об архитектуре и качестве кода. Крайне вредная статья с точки зрения программиста. А на счет гейм-дизайна вроде интересно.
Не знаю, работал он или нет, но он прав. Инди-игру человек делает в свободное от основной работы время и за бесплатно, поэтому важнее получить результат быстрее и не "перегореть", чем выдать качественный код.
Нужен ли качественный код на этапе прототипа, в статье говорится о том, что необходимо протестировать скорее, как идея будет работать, потому что на бумаге всегда получается одно, а на деле другое. Никто не мешает после создания прототипа подумать об архитектуре и брать оттуда только наработки, которые могут помочь в дальнейшей реализации. Например, в текущем проекте, я вместо отправления сигнала в нужный нод, просто ещё раз считаю нужное значение, но это не значит, что в дальнейшем всё так и будет, так как мне необходимо сначала просто разобраться например с основной механикой прототипа, а не думать о качестве кода, потому что если выяснится, что основная механика не будет работать, как задумывалось, есть ли смысл вообще продолжать?
"Вы можете попробовать найти издателя, но большинство из них – мошенники."
Интересно мнение издателей на это высказывание.
Да такое же. БОльшинство разработчиков, которые хотят денег на разработку - мошенники.
Тут скорее про "издателей", вроде дагестанских технологий и прочих таких компаний
Что-то сомневаюсь, что создание игры это именно весело. Интересно - да, но весело - не уверена.
которая позволяет не заботиться о таких бессмысленных вещах, как MVC, разделение на компоненты, и прочих). Простота GDScript позволяет писать большие куски кода, которые будут «попросту работать»,, после чего у вас не будет возникать желание вернуться к ним.
Ясно понятно. А потом мы удивляемся, откуда в играх столько нелепых багов, которые разработчики починить месяцами не могут. Нуачо, "просто работает" же, "желания вернуться" не возникает.
Если брать архитектуру движка, то она позволяет достаточно удобно работать с объектами и ресурсами игры. От основных движков этот отличает всё-таки архитектура, которая работает с нодами и не позволяет, например повесить больше 9000 компонентов на объект. Советую попробовать движок в деле.
"Ведущим программистам нужен чистый и организованный код, что приводит к увеличению времени разработки. Аргументируют такой подход тем, что «мы должны быть готовы заменить программистов в любой момент, поэтому код должен быть читабельным и поддерживаемым». В действительности, такая разработка займет больше времени и едва ли окупится в долгосрочной перспективе."
На счет этого не очень согласен, если проект большой и с большим термином поддержки, то возможность заменить разработчиков в любой момент времени все таки выше, чем "написать побыстрее". Для проектов с коротким циклом жизни (до 2х лет) - самое то.
Что вы думаете про Steam direct? И про прилив инди игр пачками, мне кажется это сильный удар по гем деву и будет как в гуглплее что непробиться
Ох сколько ошибок, эх телефон
Я сомневаюсь что автор вообще где-то работал программистом, не говоря уж о лиде и техническом директоре.
Автор на уровне джуна, нет представление об архитектуре и качестве кода.
Крайне вредная статья с точки зрения программиста.
А на счет гейм-дизайна вроде интересно.
Не знаю, работал он или нет, но он прав. Инди-игру человек делает в свободное от основной работы время и за бесплатно, поэтому важнее получить результат быстрее и не "перегореть", чем выдать качественный код.
Нужен ли качественный код на этапе прототипа, в статье говорится о том, что необходимо протестировать скорее, как идея будет работать, потому что на бумаге всегда получается одно, а на деле другое. Никто не мешает после создания прототипа подумать об архитектуре и брать оттуда только наработки, которые могут помочь в дальнейшей реализации. Например, в текущем проекте, я вместо отправления сигнала в нужный нод, просто ещё раз считаю нужное значение, но это не значит, что в дальнейшем всё так и будет, так как мне необходимо сначала просто разобраться например с основной механикой прототипа, а не думать о качестве кода, потому что если выяснится, что основная механика не будет работать, как задумывалось, есть ли смысл вообще продолжать?
Толковый мужик, не везде согласен, но видно что текст выстрадан и опыт наработан приличный.
PS: как раз помираю со своей игрой
И не ты один.
Не совсем понятно, зачем ПЕРЕВОДЧИК навставлял в текст картинок АБСОЛЮТНО не относящихся ни к движку, ни к статье? Это что за педерасня?
Я ничего не вставлял, это вставили редакторы DTF