All streams
Search
Write a publication
Pull to refresh
0
0
aGLex @aGLex

User

Send message
К какому пункту относится использование библиотек для Property-based тестирования таких как ScalaCheck?
Ждем отдельную статью про Катю со спойлерами про Go
Слишком быстро компилируется программа и нету времени почитать хабр?
Добавь в исходники жизни.
Нет, не необходимо, но очень желательно. Иначе в чем смысл, если не в создании чего-то нового.
Спасибо за статью и описание своего опыта.

Но не могу согласиться с советами в конце статьи:

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


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

2) После составления дизайн-документа, подумайте о всех возможных модельках в игре. Составьте четкий план по моделированию – что нужно прежде всего, а что может и подождать. Четкий план всегда поможет сориентироваться, когда теряется нить разработки.


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

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

Такой подход может не подходить к разработке внутри команды, поскольку пока программисты пишут и играются в прототип, то дизайнерам и художникам нечем заняться, т.к. еще непонятно, что будет в игре. Но для indie-разработчиков это позволит сэкономить время, деньги и силы на старте проекта.
Было бы интересно узнать про использование Play в продакшене
на какое число людей рассчитано помещение, где будет проходить встреча?
а можно поподробнее, а то сколько не ковырял так и не получилось настроить чтобы нормально русские буковки отображались.

Information

Rating
Does not participate
Registered
Activity