Рейтинг темы:
  • Голосов: 1 - Средняя оценка: 5. Если голосов меньше 5 оценка не показывается.
  • 1
  • 2
  • 3
  • 4
  • 5
Модель разработки для community-driven игр жанра 18+ по типу симуляторов
#1
Выдалось у меня свободное время и решил припомнить форум Альбедо, посмотреть что тут нового происходит. Как поживают такие игры как студентка, провинциалка, ЭТО и др. К сожалению, нового не увидел. Разработка этих игр зашла в тупик и выбраться из него похоже уже не сможет. Задумался, почему же так произошло? Идея ведь интересная, вокруг игр собралось целое сообщество. Есть спрос на такие игры, игроки хотят новых фич, ивентов, сюжетных линий и прочих радостей несмотря на то что это просто текст с картинкой из интернета в общем доступе. Проблемы назывались на форуме неоднократно и я решил выделить наиболее важные и подумать, что можно с этим сделать.

Начну с истории про разработчика Васю. Вася любил поиграть в игры, шарил в компах и даже программировал немного. В какой-то момент он решил создать свою крутую игру от которой все будут фанатеть, и от Васи конечно. Начиналось все здоровски. Вася в силу разных причин выбрал пикантную нишу и начал постигать искусство разработки игр. Он узнал что игра состоит из множества частей, таких как визуальная часть, программный код, сюжет, механика и множество других. В процессе постижения наткнулся на такой инструмент как QSP. Васе он очень зашел, так как порог вхождения был очень низкий. Вася, как самый настоящий человек-оркестр игродела, придумал маленький мир и вдохнул в него контента. Васе понравилось его творение. Он решил поделиться им с окружающими. Игроки распробовали. Все были в восторге. Через некоторое время игроки стали все чаще просить Васю добавить контента в игру, а некоторые даже указывали на баги. Вася щедро отсыпал контента и фиксил баги. Так продолжалось непродолжительное время. Вася не чувствовал отдачи и стал терять интерес. Тут он стал просить ребят периодически скидываться ему на пиво. Кто-то таки скидывался и Вася продолжал. Маленький мир уже порядком увеличился в размере и начал тонуть под собственным весом. Поставки контента шли с большими задержками, Вася старался починить проект и зарефакторить код. Это был тяжелый труд, так как Вася в силу неопытности поначалу писал страшненький, трудноподдерживаемый и плохо масштабируемый говнокод. Преимущества QSP обернулись против Васи. Он очень старался, при этом просил все больше на пиво. Страсти накалились. Игроки стали обвинять Васю в забагованном говнокоде, отсутствии обновлений и выпрашивании денег на то, что они не видят. Они говорили он нихера не делает уже и просто выпрашивает деньги. В какой-то момент Вася решил отвлечься от жарких дискуссий, пошел на балкон, закурил и призадумался. И тут он подумал про себя "Да пошли они нах*й! Уе*ки!". Вася высказал все что думает об игроках и с этого момента разработка прекратилась, а Вася скрылся в неизвестном направлении. Тем не менее, в игру играли и хотели большего. Находились умельцы которые исправляли дефекты, добавляли контента в игру. Все это было очень вяло и в какой-то момент от развития игры все отказались, но играть то хотелось! Начались дискуссии и том, как это переделать, собрать команду, как монетизировать и много других вопросов. Много было мыслей высказано, интересных мнений, но ничего не сделано и не придумано.

Где ошибся Вася? Почему так произошло? Пусть каждый сделает свои выводы из этой истории smile

Допустим, у нас есть идея, сюжет, сценарий и т.д. Мы готовы начать разработку. На мой взгляд, учитывая сообщество, тематику игр, геймплей и некоторые другие факторы, можно попробовать такую модель разработки.
Во главу угла поставить базу данных. Она будет где-нибудь на гитхабе, в свободном доступе. В ней будет содержаться информация об игровом мире: локации, персонажи, путь к картинке, тексты, сюжетные линии и т.д. Плюс ко всему этому будет храниться информация об условиях перехода, об эффекте перехода или действия. Базой будут заведовать специально обученные люди.
Следующий компонент это движок, который будет поднимать эту базу как in-memory. Движок будет содержать механику игры, логику взаимодействия с базой и фронтендом (внешней частью, интерфейсом пользователя). Им может заведовать как отдельный человек, так и несколько. Если человек забросил - не беда, можно не копаться в его говнокоде и под базу сделать новый движок.
И наконец, интерфейс пользователя, который в идеале будет максимально слабо связан с бэкендом, то есть движком. Таким образом, интерфейс тоже можно будет заменить.

Что мы получаем? Контент будет отдельно в базе и папке с картинками. Нужен хороший скилл в проектировании БД и тогда мы получим упорядоченный контент, который расширяется за счет добавления записей в таблицы и картинок в папку. Расширять игру станет гораздо проще и доступнее. Многие смогут предлагать свои идеи и их будет не трудно реализовать. Движок и интерфейс будет заменяемы. Возможно автор забросит свое детище и даже не даст исходники. Ну и йух с ним, будет не трудно написать новый, игра продолжится, подхватит новое поколение. Или тоже самое с разработчиком пользовательского интерфейса. Разделение труда в действии. Каждый может проявить именно свою специализацию и даже заработать на ней. Разработчик движка будет, например, на патреоне понемножку получать. А разработчик интерфейса собирать краудфандинг на определенную фичу. Кто-то проявит себя как крутой писатель, создатель контента. Аналогично. Community-driven development.

Возможно стоит задуматься и ... попробовать? Что думаете, господа? Есть желающие поучаствовать?

 
2
Ответить
#2
(23.11.2019, 20:27)5fd3ce82 писал(а): Преимущества QSP обернулись против Васи.
Может всё проще? Есть человек, который хочет создавать игру, то проект развивается. Если такого человека нет, то не развивается. И это не зависит от движка. За любым проектом прежде всего стоят люди, которые готовы что-то делать.
(23.11.2019, 20:27)5fd3ce82 писал(а): Базой будут заведовать специально обученные люди
(23.11.2019, 20:27)5fd3ce82 писал(а): Нужен хороший скилл в проектировании БД
Где их взять?
(23.11.2019, 20:27)5fd3ce82 писал(а): будет не трудно написать новый
Ага, дело пяти минут.
(23.11.2019, 20:27)5fd3ce82 писал(а): Community-driven development.
Весь этот комунити девелопмент заканчивает тем, что половина людей пропадает, а половина друг с другом сорятся. а потом кто-то создает тему на форуме: а чой-то игру никто не разрабывается, уот сволочи.

 
Ответить
#3
@d1a4bf95, скилл всегда какой-то нужен, везде. Без него никак. Написать новый движок или интерфейс действительно в разы легче и быстрее если все слабо связано. Это не дело пяти минут, но и не что-то сверхсложное, привязанное к языку, платформе или чему-то еще. Сообществу предлагаются варианты развития игры, добавления контента, а они уже голосуют. Большинство всегда довольно.

Цитата:Может всё проще? Есть человек, который хочет создавать игру, то проект развивается. Если такого человека нет, то не развивается. И это не зависит от движка. За любым проектом прежде всего стоят люди, которые готовы что-то делать.
Нет, в жизни все не так просто. Это как складывать все яйца в одну корзину и надеяться авось пронесет. А ведь он забросит, 100%. Гарантированно забросит. Задача в том, чтобы другие смогли подхватить эту активность как можно проще и быстрее. Новое поколение энтузиастов. От движка зависят возможности игры, масштабируемость, платформы, на которых ее можно играть, как легко ее поддерживать и много чего еще.  Человек-оркестр на QSP это что-то вроде "делаю всего понемногу, но ничего толком не умею". Потому я и написал что в такой модели можно разделить труд и при этом люди будут слабо связаны и каждый сможет получать денежку за свою работу и эти люди могут меняться без существенного ущерба проекту.

Начинать холивар про QSP смысла не вижу. Многие и так понимают его проблемы, при этом не являясь разработчиками.

 
Ответить
#4
Концепт идеи в целом хороший, я даже когда сам планировал игрушку делать тоже планировал разделение ее на некие модули, правда пиво у меня закончилось до разработки, но... Для класической разработки тебе достаточно одного Васи, у которого есть желание и пиво, при этом Васе не обязательно обладать какими-то реальными навыками. Тот же самый кусп по гайдам курится за несколько дней, поиск картинок, если не слишком заморачиваться с описанием и соответствием ему или банально подгонять его под описание тоже не сложен, как и написание текстов. В конце концов каждый ну или почти каждый писал в школе сочинения, и раз уж человек способен объяснить почему шторы красные, у него не возникнет проблемы написать плохонький сюжет.

Что же до предложенного @8d4ac8e8, варианта разработки: одного Васи уже недостаточно и минимальных требований к участникам проэкта уже больше. Тобишь нужен человек, умеющий работать с базами данных. Человек, умеющий и желающий сортировать то, что вносится как участниками, так и новыми разработчиками.
Далее нужен человек, могущий и умеющий писать движок и способный адаптировать его под прием данных из того способа хранения, который выбирает человек отвечающий за базу.
Далее нужен разработчик юзер интерфейса, который должен не только адаптировать его под движок, но и в идеале конечно, сделать так, чтобы людям было удобно и комфортно играть.
Также, в идеале нужны люди, заполняющие эту базу данных и адаптирующие тексты, которые пишут желающие под единый формат. И возможно еще люди, заменяющие или добавляющие отсутствующие картинки. Или того, кто сможет сделать и обработать 3д модели под текст.

Возможно ли найти таких людей? Разумеется! Каждый ли из обладающих навыками, которые необходимы для подобной разработки будет работать бесплатно\за пиво? Разумеется нет. Просто потому что для большинства разработка хобби, а предложенный вариант предлагает полноценную работу, пусть возможно и не 40 часов в неделю.
Как бы немного на патреоне или краундфайндинг это все-таки не тоже самое, что будет получать такой же специалист за ту же работу, если он скажем будет работать даже на фрилансе. Плюс, если найдется желающий на чистом энтузиазме, то при его уходе разработка также застопорится, особенно если это будет наиболее высокий член своеобразной иерархии. Тобишь если уходит разработчик интерфейса, то работа стопорится, но интерфейс (пусть и плохонький\кривой) разработать может допустим и человек с минимальными знаниями в сфере програмирования. Уходит разработчик движка и если он один, а так в начале скорее всего и будет, то стопорится не только его работа, но и работа разработчика интерфейса, особенно если разраб движка унес часть своих наработок. А теперь у нас ушел человек, занимающийся бд. И все. У нас не заполняются новые эвенты от комьюнити, не вносятся картинки, не продвигается разработка движка, потому что не понятно что еще будет с бд, и интерфейса, потому что не понятно что с движком. И это отбросив все конфликты по поводу контента: скажем не нравится разработчику движка зоо контент или допустим однополый. Он не включает в движок ссылки на него и игроки получают вместо контента шиш. Другой пример, подобный контент не нравится тому, кто занимается бд. Он его в принципе и вырезать может. Или он может не нравится игрокам и тогда от разработчика пользовательского интерфейса его потребуют вырезать.

И конечно и на пиво надо собирать уже не Васе, а Васе, Пете, саше и Сереге, ну можно еще Никите, но не обязательно.

В общем идея хорошая, но для ее реализации нужно чуть ли не со старта иметь готовую команду, схожую во взглядах. Причем желательно дублирующую друг друга.


В общем идея очень интересная, но также очень сложнореализуемая.

 
It's Alive! It's Alive!
Ответить
#5
Предлагаю поступить так. Посмотрим, есть ли кто-то желающий поучаствовать в этом безобразии. Можете написать мне в личку или отписаться здесь. Давайте договоримся заранее, что если вы учитесь в школе или недавно поступили в университет - пожалуйста учитесь. Предлагаю на первых порах откреститься от тематики 18+ от слова совсем, позже объясню почему.
Выделим такое понятие как "первая итерация". На этом этапе нужен максимально простой и тупой сюжет, с такими же текстами. Какой-нибудь более менее живой движок и простейший фронтенд. Аналогично с базой. Это этап экспериментов. Как только мы определимся как лучше организовать архитектуру мы сделаем первую публичную версию, аналогично без 18+. Предложим затестить кому-нибудь, получим обратную связь. Будет много косяков, займемся ими. Далее начнется вторая итерация. Мы уже по факту научимся разрабатывать это добро.

Я думаю любой кто на этом форуме более менее продолжительное время находится подумал что-то вроде: "Да где ты нахер найдешь специалистов, да еще и за бесплатно, чтобы они такое продолжительное время работали, не слились, не спились и т.д.?". Это вопрос мотивации или "нахера мне это?". Есть две основные причины. Это приобретение и прокачка скиллов, а также перспектива заработать. Даже если заработать на проекте не получится - с вами останутся ваши скиллы, которые вы сможете монетизировать устроившись программистом, дизайнером или еще кем-нибудь. Это будет ваше портфолио. Думаю теперь понятно почему лучше откреститься вначале от 18+. Это то, что вы сможете показать работодателю или заказчику. Еще одна причина, по которой нужно отказаться от 18+ это командная разработка. Ребят, нужно будет выйти из сумрака и общаться голосом. Если же все пойдет отлично и получится монетизировать - можно пойти дальше, насколько фантазии хватит. Хоть конкурента mnfclub делать или еще чего. В этой схеме вы ничего не теряете. Наоборот, это классная возможность прокачать себя.

На каждое направление в идеале будет минимум 2 человека. Если кто-то по каким-то причинам сливается - ищем замену. Передача знаний должна происходить гораздо проще. Будем использовать инструменты командой разработки. Вроде бы Jira и Confluence бесплатны до 10 человек с хостингом в их облаке. Там же будут храниться знания чтобы новичкам было проще присоединиться.

Есть такие направления на данный момент:
- геймдизайн. Серьезных требований нет, но нужно будет какие-то локации придумывать, характеристики персонажа и т.д. Нужно будет писать много документов в Confluence. А также на первых порах самому писать все тексты и искать картинки;
- база данных. Проектированием могу заняться самостоятельно, обговорив концепцию с геймдизайнером. Если же тут вдруг есть крутые БДшники, желающие поучаствовать - ждем;
- фронтенд. По большому счету неважно какой язык программирования вы знаете, но более менее хорошо знать его надо. Общение будет скорее всего происходить через JSON, а клиент будет десктопный вначале, рядом с которым будут картинки. Имеет смысл попробовать Electron JS. Не нужен хостинг, который бы хранил контент, кроссплатформенность, можно подстроиться под все устройства и много других плюшек;
- движок. Я планировал им заняться на Java/Scala. Возможно будут какие-то другие интересные предложения, пожалуйста. Так как база у нас будет вначале маленькая, а движок мало кому нужен - можно попробовать Heroku с его бесплатным тарифом.

Жду ваших сообщений. Желательно в личку. Опишите кто вы, что вы, чем сейчас занимаетесь, расскажите о себе и своих умениях, что заинтересовало и т.д. Еще раз предупреждаю. Вначале все точно будет без 18+. А общение будет происходить не только текстом.

 
Ответить
#6
(23.11.2019, 20:27)5fd3ce82 писал(а): Расширять игру станет гораздо проще и доступнее.
А можно подробнее о том почему добавлять ивенты в "базу" будет гораздо проще и доступнее, чем добавлять точно такие же ивенты в игровые файлы любого другого движка? В чем разницу вы видите?

 
Ответить
#7
@66bef1d5, можно сделать интерфейс к БД который позволит упростить этот процесс, помимо прочего он может проверять добавляемый текст на наличие логических и синтаксических ошибок, что особенно актуально при массовых правках.
Прям "гораздо" проще и доступнее он вряд ли будет чем например JSON.

 
Ответить
#8
@31e3cf1d, но ведь можно сделать абсолютно такой же интерфейс, который вместо записей в БД будет генерировать игровые файлы для любого существующего движка. То есть если это и будет проще, то это не преимущество собственно самой БД.
Свёрнутый текст:
Идея с кастомным интерфейсом для добавления контента кстати интересная.

 
Ответить
#9
Что подразумевается под игровым файлом? Идея проста. Отделить котлеты от мух, данные от логики. Хранилища для данных бывают разные, главное чтобы поддерживалась целостность и непротиворечивость. Можно и правда сделать интерфейс, с помощью которого добавлять и редактировать контент. Фантазия может далеко зайти smile Были бы заинтересованные лица.

 
Ответить
#10
(26.11.2019, 07:12)5fd3ce82 писал(а): Что подразумевается под игровым файлом?
Файл в котором описан код добавляемого ивента. В Ren'Py это .rpy файлы например, в QSP отдельные локации в редакторе.

(26.11.2019, 07:12)5fd3ce82 писал(а): Идея проста. Отделить котлеты от мух, данные от логики.
Это все еще не объясняет каким образом добавлять контент станет гораздо проще и доступнее.
Свёрнутый текст:
Вот просто для справки пара скринов как этот контент выглядит:
[Изображение: https://i.postimg.cc/RV0qQ4yD/image.png]
[Изображение: https://i.postimg.cc/SRxQrfTM/image.png]

 
Ответить
#11
@66bef1d5, Примерно так например: [Изображение: https://i.ibb.co/3rpHxGs/c7f2c5e6-1783-46ae-af86-eae09ed75683.jpg]
Скрин редактора эвентов из второй теи.

 
It's Alive! It's Alive!
1
Ответить
#12
@2f4af7de, спасибо за годный пример, но как я уже писал, интерфейс для создания ивентов никакого отношения к вышеизложенной идее с БД не имеет. Этот скрин как раз прекрасно это иллюстрирует - чтобы подобный интерфейс прикрутить к игре никаких промежуточных плясок с БД не требуется.

В ту же Провинциалку хоть сейчас его рисуй и добавляй.

 
Ответить
#13
@66bef1d5, что делает этот интерфейс по вашему? Он генерирует данные, которые затем где-то сохраняются. Назовите хранилище файлом или базой данных, суть одна. Данные надо где-то хранить. Будь это файл или СУБД. Есть движок, который потом гоняет эти данные ничего не зная о них кроме структуры.

Касательно примера из QSP:
Данные и Логика

Данные могут храниться в разных форматах. Будь это реляционная БД, JSON или еще какой-нибудь свой кастомный формат. Как вы понимаете словосочетание "база данных"?

Допустим, у нас магазин. Мы постоянно добавляем, приходуем какие-то товары, назначаем им ценник, акции, списываем, продаем и т.д. Так вот, идея разделения данных и логики в том, чтобы не добавлять каждый товар в код вместе с его акцией, не менять ценник в коде и не удалять его потом оттуда когда списываем. Данные будут храниться в СУБД. Будет отдельная программа, которая добавляет туда товары, акции и списывает их. И будет основная программа, которая описывает бизнес логику без привязки к конкретным товарам и акциям.

 
Ответить
#14
@8d4ac8e8, спасибо за объяснения, но к моему вопросу это опять-таки никак не относится. Ответа я видимо так и не получу, так что просто озвучу свое мнение, что добавление нового контента ваша идея никак не упростит (в отличие от создания интерфейса для добавления контента, который можно прикрутить к абсолютно любой игре).

Свёрнутый текст:
А само по себе то что вы предлагаете и так делается всеми, вы сейчас изобрели концепцию игрового движка. Хорошая новость в том, что некоторые люди уже пришли к такой же идее и заранее понаписали разных движков. Или если вам так больше нравится, то люди уже понаписали кастомных "форматов для хранения игровых данных" и к ним движков. Скрипт для Ren'Py, который описывает тот же ивент, что в вашем примере "Данных", будет гораздо лаконичнее и не потребует содержать никакой дополнительной информации помимо той, что в ваших "данных" уже есть. Так что добавить новый ивент в игре на Ren'Py и вашей гипотетической игре будет одинаково сложно через промежуточный интерфейс, а без интерфейса значительно легче на Ren'Py так как его все-таки разрабатывали много лет профессионалы и он менее избыточный, есть кучи туториалов и много людей уже знакомы с его "форматом хранения данных".

Граница где заканчивается игровой движок и начинается игра условна и обычно проводится между тем кодом, который можно переиспользовать для других игр (игровой движок) и тем кодом, который нельзя переиспользовать (сама игра). Вы просто предлагаете написать игру с нуля и объявить все что можно игровым движком. Но как ты розу не назови - суть от этого никак не изменится.
То есть авторы Ren'Py или любого другого игрового движка уже проделали все, что вы собирались сделать, и остается только заполнить их "БД". Если вам не хватает тех функций, что там есть из коробки, то вместо того, чтобы "писать игровую логику на их движке", думайте об этом как о "расширении их движка". Ведь в вашем примере точно так же, чтобы добавить любой минимальный функционал нужно "лезть в движок и расширять его", хотя в реальности это никак не отличается от написания "игровой логики" на любом другом движке.

А "игровую логику" и "данные" у себя в игре и так каждый разработчик разделяет насколько ему удобно. Никто не пишет функций посреди игрового текста, ну мб за исключением новичков, которые просто не в курсе того как правильно делать.
Вы же видимо решили возвести это в абсолют и даже вместо элементарных if'ов, которые вы возможно считаете "игровым кодом", использовать такие вот JSON конструкции, которые означают абсолютно то же самое просто синтаксис другой.

Отвязаться от синтаксиса конкретного языка и изобрести свой собственный может иметь смысл, например если вам зачем-то нужно портировать игру на несколько движков. Однако ваш пример с тем, что мол так проще если уйдет разработчик вашего "движка" и не оставит вам исходников, кажется мне несколько натянутым, учитывая что все популярные движки для текстовых игр и так опен-сорсные, и шанс того что их разработку прекратят гораздо меньше, чем шанс ухода Васяна с форума. Да и так как у вас в "движке" по сути вся игра кроме контента, то в любом случае вам придется абсолютно всю игру заново писать.
Однако к легкости добавления контента это все равно никак не относится.

Вот на эту игру еще можете посмотреть https://albedo.pw/thread-5025.html?highlight=enchanted, там автор вроде как пошел еще дальше у него весь текст в одном "файле"\"базе" (в одном passage) откуда он его каждый раз достает, если мне не изменяет память. Я так понимаю, что если бы он туда же ссылки на картинки и условия перенес, то это было бы именно то, что вы хотите сделать?

 
Ответить
#15
(26.11.2019, 03:43)33fc48a7 писал(а): но ведь можно сделать абсолютно такой же интерфейс, который вместо записей в БД будет генерировать игровые файлы для любого существующего движка. То есть если это и будет проще, то это не преимущество собственно самой БД.
Можно, но есть особенности:
1. зависит от формата движка, не под каждый движок легко это сделать, под базу данных это проще. Каждый движок делался под свои нужды и накладывает свои ограничения, тут Lambada хочет написать свой движок как сам видит.
2. если это текстовые файлы то когда они будут огромными работать это будет тормознее, либо надо заморочиться, в БД уже заморочились.
Он говорил про «расширять игру», в этом плане база удобнее, навигация проще, у БД есть быстрый поиск, фильтрация, можно доставать данные по условиям и т. д.
Но естественно тут не всё так однозначно, вопрос архитектуры движка очень важный.
В принципе я не вижу тут возможности удобной реализации без хороших интерфейсов.
Руками набирать тип события и прочее без автодополнения и без уже сформированных списков неудобно и будет проигрывать привычной портянки из ifelse, даже если это чище и потом когда-нибудь окупится.

Кстати прямо чистого отделения логики от данных здесь нет, просто логика делится на отдельную машину состояний в исходном коде и данные условий привязанные к диалоговым веткам и объектам для неё в базе. Чище кстати тут вряд ли возможно в принципе сделать. Делать код для обработки данных из базы для каждого диалога технически чисто, но с практической точки зрения бред, игра не веб-приложение и тащить привычки может быть губительно.
И этот подход с машиной состояний несёт свои как преимущества так и недостатки:
Более унифицированная и надёжная логика, расширяется централизовано, а не где-то там в трёхтысячном диалоге производится условие которое ломает всё состояние игры из-за маленькой опечатки (присвоена похожая по названию переменная) и прочих логических ошибок.
Отсюда и в какой-то мере недостаток, нельзя сделать нестандартное условие на месте, это надо добавлять логику в машину состояний, нужно немного больше подумать и продумать дизайн нового условия для машины состояний.
Плохо написанная машина состояний может сама стать узким местом и не давать легко расширять игру.
Хорошо написанная исключит вызов низкоуровневых кишков и за счёт этого легко написать функцию истории поведения игрока что полезно для отладки, а ещё если чуть больше подумать можно сделать отмену состояний и своего рода перемещение в прошлое. Главное чтобы кишки не делали всякие грязные «магические» действия.

 
Ответить
#16
(27.11.2019, 15:37)d7594d31 писал(а): 1. зависит от формата движка, не под каждый движок легко это сделать, под базу данных это проще. Каждый движок делался под свои нужды и накладывает свои ограничения, тут Lambada хочет написать свой движок как сам видит.
Подгибать интерфейс под чей-то движок вероятно будет несколько сложнее, однако эти дополнительные усилия ни в какое сравнение не идут с задачей написания своего движка со сравнимым функционалом.
Я бы предпочел увидеть хоть какой-то результат, и с привязкой к уже существующему движку шанс куда-то продвинуться хотя бы кажется ненулевым.

(27.11.2019, 15:37)d7594d31 писал(а): 2. если это текстовые файлы то когда они будут огромными работать это будет тормознее, либо надо заморочиться, в БД уже заморочились.
В оригинальном посте планировалась именно оффлайн игра. Могу ошибаться конечно, но для игры полностью на стороне юзера можно хоть Войну и Мир понаписать - до проблем с производительностью там должно быть очень далеко.

(27.11.2019, 15:37)d7594d31 писал(а): Он говорил про «расширять игру», в этом плане база удобнее, навигация проще, у БД есть быстрый поиск, фильтрация, можно доставать данные по условиям и т. д.
Я подразумевал конкретно добавление нового контента в игру. Можно наверное сказать, что удобный доступ к уже существующим данным как-то косвенно помогает добавлять новый контент, например так быстрее находить прошлые примеры реализации чего-либо, однако это уже немного похоже на натягивание совы на глобус.

(27.11.2019, 15:37)d7594d31 писал(а): Более унифицированная и надёжная логика, расширяется централизовано, а не где-то там в трёхтысячном диалоге
Если это является целью, то мне кажется, что в каком угодно движке есть возможность не совать логику в случайные места. И если ее все-таки решают поместить именно туда, то только потому, что сами считают, что так удобнее.

 
Ответить
#17
(27.11.2019, 17:14)33fc48a7 писал(а): однако эти дополнительные усилия ни в какое сравнение не идут с задачей написания своего движка со сравнимым функционалом.
Ну это смотря под какой движок, и смотря как свой движок будет запиливаться (необязательно же всё писать с нуля, есть библиотеки готовые под какой-то функционал).
Тут обычно бесполезно человека настроить на написание инструмента к другому движку если он сам горит идеей написать написать собственный.

(27.11.2019, 17:14)33fc48a7 писал(а): В оригинальном посте планировалась именно оффлайн игра. Могу ошибаться конечно, но для игры полностью на стороне юзера можно хоть Войну и Мир понаписать - до проблем с производительностью там должно быть очень далеко.
Так речь про оффлайн игру.
Возьмём например ту же VH, что как раз примерный аналог по объёму произведения «Война и Мир» там вот rgp2000 где для хранения используются бинарные файлы, они перезаписываются при правке целиком и вот перезапись RPG_RT.ldb весьма медленная. Если преобразовать этот файл в текстовый формат то не каждый редактор его прожуёт. Такие игры само собой редкость, но тем не менее что мешает какому-то совместному проекту тоже стать огромному долгострою?
Хотя это всё сферически-специфически, обычно такое разбивают на более мелкие файлы.

(27.11.2019, 17:14)33fc48a7 писал(а): Я подразумевал конкретно добавление нового контента в игру. Можно наверное сказать, что удобный доступ к уже существующим данным как-то косвенно помогает добавлять новый контент, например так быстрее находить прошлые примеры реализации чего-либо, однако это уже немного похоже на натягивание совы на глобус.
Ну в идеале такой движок смахивает на конструктор, то есть входной порог ниже. В нём проще деление по специализации. Какому-нибудь сценаристу не нужно учить язык программирования чтобы создать диалоги, управлять состоянием ГГ и т.д.
Но это всё теория. Глубоко развивать эту тему мне сейчас не охота, пусть сам автор разовьёт.

(27.11.2019, 17:14)33fc48a7 писал(а): Если это является целью, то мне кажется, что в каком угодно движке есть возможность не совать логику в случайные места. И если ее все-таки решают поместить именно туда, то только потому, что сами считают, что так удобнее.
Новички не знают как правильно и когда движок держит их в правильных рамках они привыкают к правильному подходу.
К тому же другие движки могут навязывать другую парадигму разработки, против который переть может быть больно.
Как бы лодкой по дорогам не поедешь, да можно приделать колёса и грести по асфальту (особые умельцы там могут и сильнее поизвращаться), но не кажется это немного странным?

 
Ответить
#18
(27.11.2019, 03:52)33fc48a7 писал(а): @8d4ac8e8, спасибо за объяснения, но к моему вопросу это опять-таки никак не относится. Ответа я видимо так и не получу, так что просто озвучу свое мнение, что добавление нового контента ваша идея никак не упростит (в отличие от создания интерфейса для добавления контента, который можно прикрутить к абсолютно любой игре).
А как я предлагал? Не помню чтобы я предложил конкретный способ добавления контента. Вставки в реляционную БД через SQL? Или предложил вариант с сериализацией в файл? Когда я привел пример с магазином там как раз упоминалась отдельная программа для работы с данными. Например, чтобы добавлять новые товары. Идея была в том, что данные должны храниться не там же где бизнес-логика, а где-то отдельно. В куске кода который я привел предполагалось что мы откуда-то читаем данные, преобразуем в объект и гоняем на движке. У третьего варкрафта был свой редактор насколько я помню, с помощью которого можно было создавать карты и не только. Движку важна только структура. Что значит "прикрутить интерфейс"? Как вы его к QSP прикрутите?

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

Вот как пример скрипт поведения Иллидана в мангосе: https://github.com/mangos/ScriptDev3/blob/master/scripts/outland/black_temple/boss_illidan.cpp
У них отдельный проект под скрипты поведения мобов, правда нет предметно-ориентированного языка под это дело. Зато они прикрутили Lua чтобы кастомизировать интерфейс пользователя. Заметьте, в начале перечислены константы. Они могут ссылаться на текст, спелл или еще что-нибудь. База потом указывает где найти это, какую картинку отображать, какую анимацию сделать, какой эффект будет и т.д.

Тем не менее, напоминаю, есть основной код движка который это перемалывает. Ему все равно какой спелл передается, важно чтобы это действительно был код спелла. Движок потом вытаскивает информацию о спелле из БД и применяет. Клиент занимается отображением этого добра.

 
Ответить
#19
@66bef1d5, Как я вижу, разница в том, что база данных позволяет разрабатывать как бы квази игру: даже если кто-то забросит, то наработки останутся, а интерфейс привязан к конкретной игре, тобишь если вдруг игра перестанет разрабатываться или даже существовать, можно будет с легкостью воссоздать новую на том же базисе. И не придется делать эвенты и искать под них картинки второй раз.


Плюс, это дает возможность например попробовать новые движки не перенося под них каждый эвент "ручками".

 
It's Alive! It's Alive!
Ответить
#20
@8d4ac8e8, в двух словах, если я вас правильно понял, то вы высказали идею, которая вот уже пару месяцев у меня вертится в башке: Нужна понятная любому дауну CMS для разработки визуальной новеллы, или даже песочницы. Лучше всего этот движок сваять на каком нибудь продвинутом языке с довольно низким порогом вхождения, чтобы тем, кто захочет выйти за пределы этого движка был проще?


Создание игры в этом случае будет выглядеть так, я Вася. У меня есть идея добавить в игру выхухолей, я открываю эту хрень добавляю объект выхухоли. Место где их можно встретить, условия при которых выхухоли появляются и собственно, что должно происходить при их появлении. Языка я не знаю, да и фиг с ним... В интерфейсе итак всё понятно. Сюда вписать выхухолей, сюда "в кустиках ипутся", сюда вставить картину. сюда скольк времени прошло, сюда изменения в характеристики гг и т.п. Всё это должно быть максимально гибко...

 
Ответить
#21
[quote="Суббота" pid='391330' dateline='1574896881']
@8d4ac8e8, в двух словах, если я вас правильно понял, то вы высказали идею, которая вот уже пару месяцев у меня вертится в башке: Нужна понятная любому дауну CMS для разработки визуальной новеллы, или даже песочницы. Лучше всего этот движок сваять на каком нибудь продвинутом языке с довольно низким порогом вхождения, чтобы тем, кто захочет выйти за пределы этого движка был проще?

Ну Твайн уже есть же:
http://twinery.org/

На нём например даже FreeCities сделаны, то есть возможностей достаточно.

 
Ответить
#22
@d1a4bf95, вы не правы. Тут очень важен выбор движка. Потому, что рано или поздно, если у Васи есть желание и он постоянно занимается разработкой он навертит овердофига ивентов, а его аудитория всё равно заскучает и скажет: Вась, ну, твоя альбедо, рубедо, провинциалка, Это, нужное подчернуть уже надоела... преврати её в песочницу. И задача окажется как, если бы человеку который построил красивую деревью из соломы вдруг предложили: А теперь сделай нам такео же, но ракету и чтобы в космос полететь могла. Конечно. можно и из топора кашу сварить добавив в QSP ХТМЛ и джаву, а для особо хитрых еще и Си. Можно сразу сделать на Ренпаи и тогда остальное можно просто за счет возможностей Питона хоть ИИ к игре прикрутить. А можно взять тот же ренпай и добавить к нему шаблонов или сделать новый движок более продвинутый и интуитивно понятный чем Ренпай.


@7ee35192, лично мне интерфейс твайна не показался очень интуитивно понятным. К тому же движок вроде ограничен лишь ХТМЛом? Нет?


(24.11.2019, 16:14)5fd3ce82 писал(а):
Свёрнутый текст:
Предлагаю поступить так. Посмотрим, есть ли кто-то желающий поучаствовать в этом безобразии. Можете написать мне в личку или отписаться здесь. Давайте договоримся заранее, что если вы учитесь в школе или недавно поступили в университет - пожалуйста учитесь. Предлагаю на первых порах откреститься от тематики 18+ от слова совсем, позже объясню почему.
Выделим такое понятие как "первая итерация". На этом этапе нужен максимально простой и тупой сюжет, с такими же текстами. Какой-нибудь более менее живой движок и простейший фронтенд. Аналогично с базой. Это этап экспериментов. Как только мы определимся как лучше организовать архитектуру мы сделаем первую публичную версию, аналогично без 18+. Предложим затестить кому-нибудь, получим обратную связь. Будет много косяков, займемся ими. Далее начнется вторая итерация. Мы уже по факту научимся разрабатывать это добро.

Я думаю любой кто на этом форуме более менее продолжительное время находится подумал что-то вроде: "Да где ты нахер найдешь специалистов, да еще и за бесплатно, чтобы они такое продолжительное время работали, не слились, не спились и т.д.?". Это вопрос мотивации или "нахера мне это?". Есть две основные причины. Это приобретение и прокачка скиллов, а также перспектива заработать. Даже если заработать на проекте не получится - с вами останутся ваши скиллы, которые вы сможете монетизировать устроившись программистом, дизайнером или еще кем-нибудь. Это будет ваше портфолио. Думаю теперь понятно почему лучше откреститься вначале от 18+. Это то, что вы сможете показать работодателю или заказчику. Еще одна причина, по которой нужно отказаться от 18+ это командная разработка. Ребят, нужно будет выйти из сумрака и общаться голосом. Если же все пойдет отлично и получится монетизировать - можно пойти дальше, насколько фантазии хватит. Хоть конкурента mnfclub делать или еще чего. В этой схеме вы ничего не теряете. Наоборот, это классная возможность прокачать себя.

На каждое направление в идеале будет минимум 2 человека. Если кто-то по каким-то причинам сливается - ищем замену. Передача знаний должна происходить гораздо проще. Будем использовать инструменты командой разработки. Вроде бы Jira и Confluence бесплатны до 10 человек с хостингом в их облаке. Там же будут храниться знания чтобы новичкам было проще присоединиться.

Есть такие направления на данный момент:
- геймдизайн. Серьезных требований нет, но нужно будет какие-то локации придумывать, характеристики персонажа и т.д. Нужно будет писать много документов в Confluence. А также на первых порах самому писать все тексты и искать картинки;
- база данных. Проектированием могу заняться самостоятельно, обговорив концепцию с геймдизайнером. Если же тут вдруг есть крутые БДшники, желающие поучаствовать - ждем;
- фронтенд. По большому счету неважно какой язык программирования вы знаете, но более менее хорошо знать его надо. Общение будет скорее всего происходить через JSON, а клиент будет десктопный вначале, рядом с которым будут картинки. Имеет смысл попробовать Electron JS. Не нужен хостинг, который бы хранил контент, кроссплатформенность, можно подстроиться под все устройства и много других плюшек;
- движок. Я планировал им заняться на Java/Scala. Возможно будут какие-то другие интересные предложения, пожалуйста. Так как база у нас будет вначале маленькая, а движок мало кому нужен - можно попробовать Heroku с его бесплатным тарифом.

Жду ваших сообщений. Желательно в личку. Опишите кто вы, что вы, чем сейчас занимаетесь, расскажите о себе и своих умениях, что заинтересовало и т.д. Еще раз предупреждаю. Вначале все точно будет без 18+. А общение будет происходить не только текстом.
1) за основу взять более или менее живой движок. Берем например Ренпай и допилить к нему расширение, которое делает простым добавление в игру времени и календаря, например, погоды и т.п. плюшек к которым мы привыкли во всякого рода Провинциалках. Но для этого нужен человек понимающий питон и нужно развивать раздел форума для подготовки тех, кто желает начать понимать питон. Растить команду. Для вдохновения смотрим на Фашион Бизнес от decentmonkey. Он туда еще от игры к игре новых плюшек добавляет
2) ну, да.... письменно мы ни до чего не договорились за много лет на форуме, когда есть возможность быстро просмотреть форум и остановиться лишь на действительно интересных мнениях, а тут вдруг выйдем в голос и начнем перебивать друг друга, пить курить в микрофон, слышать звуки как кто-то писает и какает разговаривая с нами... и сделаем необыкновенное. Вот только кто вам сказал, что после такой деанонимизации вас будет сложно идентифицировать, если вы тут хотя бы одну порнокартинку запилите на форум или ляпнете чего-нить по неосторожности? Впрочем, идентифицировать при желании и так не сложно.


Про базу данных не очень пронял, поэтому попробую догадаться: 1) это будет некая база в которую каждый сможет добавить свои наработки на пробу всем желающим. Из нее же можно будет взять эти наработки и добавить в свою игру, которую также можно будет потом в эту базу данных закинуть. И тут возникает вопрос: как будет модерироваться эта БД? А то туда накидают такого... чт в этом утонут всё, кто туда нырнет.

 
Ответить
#23
(27.11.2019, 17:52)d7594d31 писал(а): Тут обычно бесполезно человека настроить на написание инструмента к другому движку если он сам горит идеей написать написать собственный.
Ну мало ли, попытаться стоит.

(27.11.2019, 17:52)d7594d31 писал(а): Так речь про оффлайн игру.
Возьмём например ту же VH, что как раз примерный аналог по объёму произведения «Война и Мир» там вот rgp2000 где для хранения используются бинарные файлы, они перезаписываются при правке целиком и вот перезапись RPG_RT.ldb весьма медленная. Если преобразовать этот файл в текстовый формат то не каждый редактор его прожуёт. Такие игры само собой редкость, но тем не менее что мешает какому-то совместному проекту тоже стать огромному долгострою?
Хотя это всё сферически-специфически, обычно такое разбивают на более мелкие файлы.
У нас речь шла про чтение и текстовые файлы, не бинарники, там ситуация немного другая.

(27.11.2019, 17:52)d7594d31 писал(а): Новички не знают как правильно и когда движок держит их в правильных рамках они привыкают к правильному подходу.
К тому же другие движки могут навязывать другую парадигму разработки, против который переть может быть больно.
Как бы лодкой по дорогам не поедешь, да можно приделать колёса и грести по асфальту (особые умельцы там могут и сильнее поизвращаться), но не кажется это немного странным?
Предвзятая какая-то метафора, я тоже так могу :)
Это как сказать, что все движки позволяют использовать хоть правую ногу, хоть левую ногу, хоть на обоих бежать, если вам так нравится. Вы говорите, а давайте прыгать только на правой ноге, вообще не используя левую. Я говорю, что ничто не мешает вам прыгать на одной только правой в любом движке. Но вы выбираете делать свой движок в котором левую ногу вообще отрезают, просто чтобы не дай бог на нее кто-то по незнанию не наступил.

(27.11.2019, 20:21)5fd3ce82 писал(а): Что значит "прикрутить интерфейс"? Как вы его к QSP прикрутите?
1. Пишите приложение как на скриншоте:
2. В нем без написания кода создаете свой ивент, заполняя поля, и нажимаете кнопочку "Готово".
3. Ваше приложение считывает данные из формы и переводит их в код как на скриншоте:
4. Ваше приложение добавляет этот код в QSP файл вашей провинциалки.
Вы открываете QSP файл своей провинциалки плеером и наслаждаетесь новым контентом.
Свёрнутый текст:
Между 3 и 4 можете даже добавить промежуточную запись в БД в вашем метаформате.

(27.11.2019, 20:26)de295492 писал(а): если вдруг игра перестанет разрабатываться или даже существовать, можно будет с легкостью воссоздать новую на том же базисе. И не придется делать эвенты и искать под них картинки второй раз.
С чего бы в любой игре с открытыми исходниками приходилось делать эвенты и искать под них картинки второй раз? Они и так никуда не деваются, когда девелопер игру забрасывает.

(27.11.2019, 23:30)99836486 писал(а): К тому же движок вроде ограничен лишь ХТМЛом? Нет?
Twine поддерживает JavaScript.

 
Ответить
#24
(27.11.2019, 23:30)99836486 писал(а): 2) ну, да.... письменно мы ни до чего не договорились за много лет на форуме, когда есть возможность быстро просмотреть форум и остановиться лишь на действительно интересных мнениях, а тут вдруг выйдем в голос и начнем перебивать друг друга, пить курить в микрофон, слышать звуки как кто-то писает и какает разговаривая с нами... и сделаем необыкновенное. Вот только кто вам сказал, что после такой деанонимизации вас будет сложно идентифицировать, если вы тут хотя бы одну порнокартинку запилите на форум или ляпнете чего-нить по неосторожности? Впрочем, идентифицировать при желании и так не сложно.
К сожалению, так уж вышло, что разрабатывать программное обеспечение может только более менее взрослая особь человека-разумного. Постоянно орущие и кидающиеся дерьмом макаки врятли осилят это. ПО можно разрабатывать в распределенной команде, но нельзя это нормально сделать без голоса. Иногда вместо того чтобы переписываться часами достаточно на 5 минут созвониться и решить вопрос.
К тому же я говорил, что лучше откреститься от темы 18+ при разработке основного каркаса. Когда он будет готов на его основе можно будет создавать другие игры. Хоть для взрослых, хоть для детей. В идеале получится сообщество как у QSP или MANGOS.

(28.11.2019, 04:01)33fc48a7 писал(а): 3. Ваше приложение считывает данные из формы и переводит их в код как на скриншоте:
4. Ваше приложение добавляет этот код в QSP файл вашей провинциалки.
Окей. А давайте конкретнее. Как я добавлю что-то в существующий код этим конструктором если QSP ничего про него не знает? А чтобы учитывать существующий контент нужно ведь парсить весь QSP и, если это возможно, конвертировать в удобный для восприятия и редактирования визуальный формат. Добавляем что-то или редактируем, затем наша форма генерирует весь QSP заного. Сразу с формы кстати не получится сгенерировать, нужен все равно промежуточный этап с промежуточной структурой данных. Я бы посмотрел, где и за какие деньги вы бы нашли таких умельцев. И для чего? Чтобы создавать ивенты для провинциалки, которая работает только виндой? С такими знаниями надо куда-то типа гугла. По мне так проще разработать "убийцу" mnfclub.com.

Если ПО заранее заточено под определенные данные и форматы, то задача существенно упрощается. Нам не надо зависеть от чего-то или кого-то. Мы договариваемся заранее что у нас на входе и выходе, какой протокол общения и т.д. Максимум это сделать какой-нибудь внутренний DSL для скриптования игровых объектов чтобы сэкономить на интерфейсе.

 
Ответить
#25
(28.11.2019, 05:06)5fd3ce82 писал(а): Как я добавлю что-то в существующий код этим конструктором если QSP ничего про него не знает?
Я не уверен даже в чем вопрос, но например:
1. Берешь .qsp файл с игрой.
2. Расшифровываешь из .qsp формата в .txt текстовик.
3. Добавляешь свой код к этому .txt файлу.
4. Запаковываешь .txt файл обратно в .qsp формат.
QSP расшифровывается как Quest Soft Player. Плееру совершенно ничего знать о "конструкторе" не нужно. Плеер только читает код, который лежит в .qsp файле и выполняет его. Каким образом код туда добавили, руками ли в редакторе вроде QGen, или вот таким вот "конструктором" плееру совершенно безразлично.

(28.11.2019, 05:06)5fd3ce82 писал(а): А чтобы учитывать существующий контент нужно ведь парсить весь QSP и, если это возможно, конвертировать в удобный для восприятия и редактирования визуальный формат.
Это уже делают редакторы вроде QGen. Нам то зачем это делать?
Если же речь только о новом контенте, добавленном уже через сам "конструктор", то интерфейс "конструктора" и есть удобный для восприятия и редактирования визуальный формат. Как ты ивент создавал, так же его и просматриваешь\редактируешь. Учитывая что ты сам из формы генерируешь код куспа, то в обратную сторону, из своего сгенерированного кода в форму, проблем считать не будет.

(28.11.2019, 05:06)5fd3ce82 писал(а): Добавляем что-то или редактируем, затем наша форма генерирует весь QSP заного.
Если под "генерацией" ты понимаешь перевод данных из формы в код куспа и перевод текста из .qsp в .txt, то да. Проблемы в этом впрочем я совершенно не вижу.

(28.11.2019, 05:06)5fd3ce82 писал(а): Сразу с формы кстати не получится сгенерировать, нужен все равно промежуточный этап с промежуточной структурой данных.
Совершенно не вижу причин почему бы это было так. Но как я уже писал, если есть желание, то это можно сделать конечно.

(28.11.2019, 05:06)5fd3ce82 писал(а): Я бы посмотрел, где и за какие деньги вы бы нашли таких умельцев.
Пусть меня поправят, но задача не выглядит даже сравнимой по сложности с написанием того движка, которым вы собирались заниматься. Я бы даже сказал, что все что для этого нужно уже входит в ваш список задач по созданию описанного в первом посте движка, кроме собственно перевода из вашего кастомного формата в код на куспе.

 
Ответить
#26
@66bef1d5, я не знаю что вам еще сказать, возможно вы о чем-то другом совершенно говорите. Возможно вы разрабатывали синтаксические анализаторы, парсеры, компиляторы и подобные дико сложные вещи. Тогда и правда, чего тут сложного для вас. Взял да расшифровал из QSP в текстовик, добавил код в этот .txt файл (шта?), а потом как запаковал(?) .txt в QSP.

Как говорил один известный программист: "Talk is cheap, show me the code. (с)". Приведите пожалуйста примеры кода, а мы проникнемся.

 
Ответить
#27
@8d4ac8e8, я даже хз, шутка это или нет. QSP это опенсорсный проект, код расшифровки\зашифровки .qsp файла доступен любому желающему. Судя по быстрому поиску, есть готовая утилита TXT2GAM, которая это делает. Код для игр на куспе можно писать в .txt файл и конвертировать его в .qsp этой утилитой. А вы сейчас о чем-то своем вообще говорите кажется.
Вот ссылка на скачивание утилиты http://qsp.su/attachments/txt2gam011.zip.

 
Ответить
#28
@8d4ac8e8, Так-то, условный QGen умеет экспортировать код в txt формат, который оперирует правилами txt2gam.

 
Ответить
#29
Сейчас проясним кто что имел ввиду.

Вы все таки хотите интерфейс типа такого?
Свёрнутый текст:
https://ibb.co/Rv3WXZS
Или уже достаточно писать в txt файл? Кто будет писать в txt, человек напрямую или через интерфейс? Как интерфейс будет считывать существующий txt и создавать новый после редактирования или добавления контента? Ему не надо ничего парсить или генерировать? Есть какая-то утилита для этого чтобы распарсить txt и построить структуры данных с которыми можно работать в коде какого-то языка? Почему тогда нет этого интерфейса? Где у нас будет логика? В том же txt? Она тоже через интерфейс будет описываться?

 
1
Ответить
#30
Я кстати думал о чём-то подобном. Представьте: вот у вас есть сделанная вами игра и вы ходите сделать к ней генератор событий, чтобы любой человек со стороны мог добавить в любую локацию своё событие. Как по мне, тут главное ключевых переменных сделать поменьше, попонятнее и пологичнее, чтобы этот "человек со стороны" в них не запутался. А так что же: список локаций, список персонажей, список переменных, условия, ветки диалогов... А если дать возможность добавлять локации и персонажей (или даже ввести такой объект, как "случайный НПС"), то "сделанная вами игра" для начала процесса уже как бы и не нужна. Во всяком случае лично вам не нужно наполнять её контентом. Вот нужно ли это будет другим - это вопрос. Ну так, кинуть идею для затравки, а дальше может кто и подхватит.

 
Ответить


Переход:


Просматривают эту тему: 1 Гость(ей)