Media is too big
VIEW IN TELEGRAM
Мистер Whisp предложил фреймрейт анимаций уронить, а шо стилево как будто, но с телеграфией атак прям надо будет подзапариться.
🔥11
Forwarded from Fawkek.obj
This media is not supported in your browser
VIEW IN TELEGRAM
Скоро, вместе с новым запеканием всех текстур в один psx атлас 🎮
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
Не мог нормально заснуть гоняя вот такую мыслю:есть механики которые я хочу добавить и реализовать, но их фактически невозможно лорно обосновать, в итоге ловлю себя на том что нарративные ограничения мешают делать тот геймплей который я хотел бы видеть(а процесс геймдизайна такой, что это видение меняется постоянно).
При этом я делаю геймплейноцентричную игру и не то чтобы есть история которую я хотел бы непременно рассказать,скорее определенный вайб передать, но в то же время ограничения нужны чтобы сохранять целостность и иметь возможность закончить игру в принципе.
В итоге застрял на вопросе, нужно ли бить себя по рукам за желание отойти от заложенного на старте разработки и делать то что должен(сам себе по выдуманному контракту) или же нужно делать как чувствуешь.
При этом я делаю геймплейноцентричную игру и не то чтобы есть история которую я хотел бы непременно рассказать,скорее определенный вайб передать, но в то же время ограничения нужны чтобы сохранять целостность и иметь возможность закончить игру в принципе.
В итоге застрял на вопросе, нужно ли бить себя по рукам за желание отойти от заложенного на старте разработки и делать то что должен(сам себе по выдуманному контракту) или же нужно делать как чувствуешь.
🔥5🤝5
никита рендерит сиджи
Не мог нормально заснуть гоняя вот такую мыслю:есть механики которые я хочу добавить и реализовать, но их фактически невозможно лорно обосновать, в итоге ловлю себя на том что нарративные ограничения мешают делать тот геймплей который я хотел бы видеть(а процесс…
This media is not supported in your browser
VIEW IN TELEGRAM
Короче, вот моё решение этого головняка.
Отбранчевался в проект-песочницу без визуала и прочего, где на сермате могу тестировать механики и самые удачные закидывать уже в проект.
Решаю сразу несколько задачек так:
1. Не засоряю основной проект ненужными механиками и хламом
2. Нет ограничения на эксперименты, могу больше креативить с механиками
3. Не страшно ломать системы хы
Но вот уже исходя из этого понял, что хочу перемотку времени кор механикой делать, как и физические взаимодействия с объектами, прям кайфую когда с ними экспериментирую. Мне не хватает этого в играх сейчас, поэтому возвращаю утраченные технологии древних.
Отбранчевался в проект-песочницу без визуала и прочего, где на сермате могу тестировать механики и самые удачные закидывать уже в проект.
Решаю сразу несколько задачек так:
1. Не засоряю основной проект ненужными механиками и хламом
2. Нет ограничения на эксперименты, могу больше креативить с механиками
3. Не страшно ломать системы хы
Но вот уже исходя из этого понял, что хочу перемотку времени кор механикой делать, как и физические взаимодействия с объектами, прям кайфую когда с ними экспериментирую. Мне не хватает этого в играх сейчас, поэтому возвращаю утраченные технологии древних.
🔥9
Forwarded from Из Мобайла в Инди. Антон Слащёв.
Гейм-дизайн документы не нужны
Я не большой сторонник создания "Библии Дизайна" игры, где заранее описываются ВСЕ ее механики, нюансы, весь планируемый контент и тд.
Причины две:
1) Никто этот документ не прочтет.
Ну вот правда. Вообще никто.
Даже тот, кто его написал, не будет его читать еще раз.
В лучшем случае все будут пропускать его через ИИшку и получать выжимку.
Возникает вопрос - почему тогда сразу не дать выжимку?
2) Документ устаревает, как только его написали.
Невозможно заранее определить, как будут работать все механики в игре и какой ее точный скоуп.
В процессе разработки все поменяется десять раз.
Актуализировать документ каждый раз огромная морока (и опять же - его и первый раз никто не прочитал, а уж перечитывать тем более не будут).
Нет смысла пытаться высечь что-то в камне - в разработке игр это не прокатывает.
А что же тогда делать?
Вообще не писать документацию и работать "по вайбу"?
Нет, конечно.
Я сторонник того, что игра с т.з. дизайна должна иметь два типа документов:
1) Концепт-документ (не путать с питчем, питч - это для издателей и партнеров, не для разработки).
Емкий документ на несколько страниц, который высокоуровнево описывает идею проекта, USP, геймплей, прогрессию, мету, контент и в общих чертах затрагивает, какие основные механики и контент планируются.
Именно в общих чертах, потому что все изменится.
Задача этого дока - как раз быть той самой выжимкой, которая в целом даст представление об игре, ее скоупе и ключевых вещах, но не углубляясь в детали.
Концепт-документ при этом должно быть можно разбить на ключевые задачи в спринты, без наполнения, широкими мазками.
2) ТЗ на отдельные фичи
Когда разработка доходит до какой-то фичи (или контента) из бэклога - по ней уже пишется подробное ТЗ (если нужно, конечно).
С деталями, нюансами и тд. В процессе они тоже, конечно, могут измениться, и это ок.
Таким образом документация как бы прыгает от высокоуровневого описания до очень детального тогда, когда это нужно.
Но конечно, вместо тысячи слов всегда лучше иметь картинку, а вместо тысячи картинок - билд или прототип :)
Поэтому крутой прототип всегда заменяет огромные дизайн-доки.
В частности поэтому меня удивляет, когда геймдизайнеры в резюме пишут "умею составлять ГДД".
Правда такова, что в общем-то кто угодно умеет составлять ГДД. Особенно в пост-gpt эру.
Наверное, даже недавно оцифрованный мозг мухи может его составить :)
Толку, правда, от этого мало.
Вот уметь взять концепт и довести его до прикольного, понятного прототипа, который можно показать команде - вот это реально скилл.
А попросить чат-гпт по набору мыслей написать ГДД - это не самый ценный геймдизайн-навык.
Я не большой сторонник создания "Библии Дизайна" игры, где заранее описываются ВСЕ ее механики, нюансы, весь планируемый контент и тд.
Причины две:
1) Никто этот документ не прочтет.
Ну вот правда. Вообще никто.
Даже тот, кто его написал, не будет его читать еще раз.
В лучшем случае все будут пропускать его через ИИшку и получать выжимку.
Возникает вопрос - почему тогда сразу не дать выжимку?
2) Документ устаревает, как только его написали.
Невозможно заранее определить, как будут работать все механики в игре и какой ее точный скоуп.
В процессе разработки все поменяется десять раз.
Актуализировать документ каждый раз огромная морока (и опять же - его и первый раз никто не прочитал, а уж перечитывать тем более не будут).
Нет смысла пытаться высечь что-то в камне - в разработке игр это не прокатывает.
А что же тогда делать?
Вообще не писать документацию и работать "по вайбу"?
Нет, конечно.
Я сторонник того, что игра с т.з. дизайна должна иметь два типа документов:
1) Концепт-документ (не путать с питчем, питч - это для издателей и партнеров, не для разработки).
Емкий документ на несколько страниц, который высокоуровнево описывает идею проекта, USP, геймплей, прогрессию, мету, контент и в общих чертах затрагивает, какие основные механики и контент планируются.
Именно в общих чертах, потому что все изменится.
Задача этого дока - как раз быть той самой выжимкой, которая в целом даст представление об игре, ее скоупе и ключевых вещах, но не углубляясь в детали.
Концепт-документ при этом должно быть можно разбить на ключевые задачи в спринты, без наполнения, широкими мазками.
2) ТЗ на отдельные фичи
Когда разработка доходит до какой-то фичи (или контента) из бэклога - по ней уже пишется подробное ТЗ (если нужно, конечно).
С деталями, нюансами и тд. В процессе они тоже, конечно, могут измениться, и это ок.
Таким образом документация как бы прыгает от высокоуровневого описания до очень детального тогда, когда это нужно.
Но конечно, вместо тысячи слов всегда лучше иметь картинку, а вместо тысячи картинок - билд или прототип :)
Поэтому крутой прототип всегда заменяет огромные дизайн-доки.
В частности поэтому меня удивляет, когда геймдизайнеры в резюме пишут "умею составлять ГДД".
Правда такова, что в общем-то кто угодно умеет составлять ГДД. Особенно в пост-gpt эру.
Наверное, даже недавно оцифрованный мозг мухи может его составить :)
Толку, правда, от этого мало.
Вот уметь взять концепт и довести его до прикольного, понятного прототипа, который можно показать команде - вот это реально скилл.
А попросить чат-гпт по набору мыслей написать ГДД - это не самый ценный геймдизайн-навык.
👍1
Forwarded from Виртуальный Лёкича Уголок
Новая раздача на #FAB, забирайте распространяйте радуйтесь если можете
1. Asian Canal Environment (Asian Canal Environment Asian Ancient Bridge Old 3D )
2. Paladin RPG Set
3. Global Search Pro
1. Asian Canal Environment (Asian Canal Environment Asian Ancient Bridge Old 3D )
2. Paladin RPG Set
3. Global Search Pro
🔥3
Media is too big
VIEW IN TELEGRAM
Короч мысля какая, а что если смерть сделать частью механик, раз у нас тут заигрывание со временем.
Поэтому добавил кнопку для альтернативного оживления, после которого мы ресаемся на последнем "костре" иии можем использовать свою тушку чтобы решить какую-то головоломку или заклинить ловушку там
Поэтому добавил кнопку для альтернативного оживления, после которого мы ресаемся на последнем "костре" иии можем использовать свою тушку чтобы решить какую-то головоломку или заклинить ловушку там
🔥9
This media is not supported in your browser
VIEW IN TELEGRAM
Рилсики над будет в таком формате попилить
💯4