Рейтинг темы:
  • Голосов: 1 - Средняя оценка: 5. Если голосов меньше 5 оценка не показывается.
  • 1
  • 2
  • 3
  • 4
  • 5
Модель разработки для community-driven игр жанра 18+ по типу симуляторов
#31
Мне понравился подход когда есть ядро игрового мира с механикой и правилами и есть API (в виде DSL или напрямую) для скриптовки. Не надо тратиться на интерфейс для расширения игры. Главное чтобы этот API был попроще и документация понятная. А все данные вынести в базу, например, SQLite. Думаю в этом направлении попробовать. Расширять такое можно через пулл-реквесты с добавлением соответствующих доков.

Кстати, появился желающий делать игровой интерфейс. Правда на JavaFX, т.к. знает хорошо только джаву.

 
Ответить
#32
(28.11.2019, 04:01)33fc48a7 писал(а): С чего бы в любой игре с открытыми исходниками приходилось делать эвенты и искать под них картинки второй раз? Они и так никуда не деваются, когда девелопер игру забрасывает.
Их надо будет перегонять в другой движок например или в другую логику мира, если автор захочет поменять сеттинг или область действия.
@7ee35192, аналогично, я когда планировал проэкт рогалика, я даже его разбил на 3 "части" сам город, в котором есть персонаж и всякие возможности для одевания, эвентов и развития этого самого города а также доска объявлений, через которую персонаж-приключенец выходит на эвенты. Эти самые эвенты, часть которых представляет собой подземелья с боевкой, событиями и возможно некоторыми уникальными механниками, а вторая часть это более простые квесты, например короткие эвенты, вроде: "разобраться с шайкой разбойников" или скажем "убить гоблинов, терроризирующих купцов на тракте" или даже чтобы тебе дала королева эльфов... топор в смысле. И редактор вот этих простых эвентов, чтобы любой желающий и имеющий идею мог сделать такое коротенькое приключение.

 
It's Alive! It's Alive!
Ответить
#33
(28.11.2019, 13:32)6e7f7b83 писал(а): Я кстати думал о чём-то подобном. Представьте: вот у вас есть сделанная вами игра и вы ходите сделать к ней генератор событий, чтобы любой человек со стороны мог добавить в любую локацию своё событие. Как по мне, тут главное ключевых переменных сделать поменьше, попонятнее и пологичнее, чтобы этот "человек со стороны" в них не запутался. А так что же: список локаций, список персонажей, список переменных, условия, ветки диалогов... А если дать возможность добавлять локации и персонажей (или даже ввести такой объект, как "случайный НПС"), то "сделанная вами игра" для начала процесса уже как бы и не нужна. Во всяком случае лично вам не нужно наполнять её контентом. Вот нужно ли это будет другим - это вопрос. Ну так, кинуть идею для затравки, а дальше может кто и подхватит.
если поолучится сделать, то выйдет превеселый конструктор. Удаляем все данные игры из него полностью и делаем свою новую с нуля без каких либо навыков. Остальное доучиваем в процессе.

 
Ответить
#34
звучит не реалистично, если вам надо добавить рандом эвент это делается 1 строчкой . if=... добавляй не хочу
если вам надо добавить сложный эвент зависящий от десятка переменных и различных условий заколебетесь делать интерфейс под добавление этого эвента. и всеравно будут возникать поломанные эвенты и надо будет лезть в код и ковыряться чтобы понять что пошло не так

 
Ответить
#35
(28.11.2019, 04:01)33fc48a7 писал(а): У нас речь шла про чтение и текстовые файлы, не бинарники, там ситуация немного другая.
Так суть в том что с текстовыми файлами всё ещё хуже обстоит при таких объёмах, если в один файл многое положить. Когда сохранял RPG_RT.ldb через liblcf в XML (да JSON был бы компактнее, но тем не менее) для отладки заметил что sublime text виснет при открытии, а notepad++ так тормозит что с ним невозможно работать, vscode ещё терпимо тянет и можно кое-как ориентироваться по файлу как нужно.
Но обычно до такого не доводят и дробят файлы как-то по смыслу. Это кстати должно быть произойти и в случае с VH ибо rpg2000 позволяет хранить события внутри карт, но японцы почему-то большую часть событий нафигачили в общий файл, если бы это была база данных, а не тупо огромный бинарный массив, то оно бы работало гораздо лучше, так как в норм БД полная перезапись не ведётся.

(28.11.2019, 04:01)33fc48a7 писал(а): Предвзятая какая-то метафора, я тоже так могу smile
Это как сказать, что все движки позволяют использовать хоть правую ногу, хоть левую ногу, хоть на обоих бежать, если вам так нравится. Вы говорите, а давайте прыгать только на правой ноге, вообще не используя левую. Я говорю, что ничто не мешает вам прыгать на одной только правой в любом движке. Но вы выбираете делать свой движок в котором левую ногу вообще отрезают, просто чтобы не дай бог на нее кто-то по незнанию не наступил.
Ну в движках всё сложнее, если переводить на эту аналогию, то тут очень много рук и ног, каждая со своими особенностями. Новички используют что им первое попалось и показалось правильным, либо то что диктует тот или иной движок, но разные движки под разные задачи писались — вроде руки ноги есть а приспособлены они хорошо только под определённую специфику их применения. А если углубляться то и качество тех или иных рук и ног в разных движках очень разнится.


(28.11.2019, 06:20)33fc48a7 писал(а): 3. Добавляешь свой код к этому .txt файлу.
Это надо под этот формат написать кодогенератор, что отдельная своя задача, кроме того чтобы сгенерировать рабочий код надо откуда-то взять переменные игры для работы, вручную их добавлять это добавить ещё один слой ошибок, следовательно надо писать парсер который разберёт структуру уже существующей игры. Это не так просто. Может когда-нибудь я напишу подобное полуавтоматическое решение чтобы перетащить QSP на более современную платформу заодно это поможет вытащить все ошибки/несостыковки в играх и перетасовать логику в новый формат к которым уже можно будет применять карту диалогов. Ибо опыта в написании парсеров (это можно сказать своя целая дисциплина по которой книги пишут) я потихоньку набираюсь. И кстати говоря существующие универсальные парсеры с набором схем весьма отвратны и под них делать схемы больно.
Если парсить форматы (не все) ещё не так сложно, то языки (не все) парсить гораздо сложнее.
Вот например нашёл статейку https://habr.com/ru/post/348314/ ознакомься.
Вообще я где-то встречал библиотеку для работы с сырым QSP-файлом, но не уверен что работать напрямую будет проще, а так есть возможность миновать этап TXT.

(28.11.2019, 06:20)33fc48a7 писал(а): Пусть меня поправят, но задача не выглядит даже сравнимой по сложности с написанием того движка, которым вы собирались заниматься. Я бы даже сказал, что все что для этого нужно уже входит в ваш список задач по созданию описанного в первом посте движка, кроме собственно перевода из вашего кастомного формата в код на куспе.
Я бы не стал считать что люди которые умеют программировать какие-то определённые вещи умеют программировать что угодно. Каждая специфика требует вникание в неё и опыт связанный с ней. Бывают пересечения, но даже когда они бывают они редко когда-либо полные. На вникание и получение опыта может потребоваться не мало времени и сил. Потом оно конечно уже смотрится не таким сложным.
Тут надо определиться что такое движок, в существующих движках типа ренпая много лишнего, это комбайны «всё включено» со своими заморочками и наследием (ошибками дизайна архитектуры которые потом героически преодолевают).
Если сравнивать затраты написания ренпая с нуля то да это очень много работы и гораздо проще написать конвертер в него.
Но кто сказал что для создания удобной текстовой игры с картинками нужен весь функционал ренпая да ещё с нуля?

 
Ответить
#36
(30.11.2019, 14:14)d7594d31 писал(а): чтобы сгенерировать рабочий код надо откуда-то взять переменные игры для работы, вручную их добавлять это добавить ещё один слой ошибок, следовательно надо писать парсер который разберёт структуру уже существующей игры
Даже если возникнет проблема со сбором переменных руками, полный их список элементарно достается скриптом в несколько строчек, который тупо ищет все инициализации переменных. И я никогда не предлагал редактировать легаси\уже существующий контент через новый интерфейс, поэтому вообще нет причин говорить о парсинге старого кода.

(30.11.2019, 14:14)d7594d31 писал(а): Если сравнивать затраты написания ренпая с нуля то да это очень много работы и гораздо проще написать конвертер в него.
Я в принципе не вижу каких-то отдельных "затрат на написание конвертора", которые и так не входят в задачу по написанию своего движка с интерфейсом добавления ивентов. Юзеровские данные из формы в обоих случаях нужно считать и записать в какой-то вид. Будут эти данные писаться в JSON или .rpy скрипт - имплементация обоих вариантов по времени занимает одинаково.

(30.11.2019, 14:14)d7594d31 писал(а): Но кто сказал что для создания удобной текстовой игры с картинками нужен весь функционал ренпая да ещё с нуля?
Писать движок собственно для показа картинок и текста с переходами в 2020м вообще странно, это все умеет браузер, который есть на каждом компьютере.

 
1
Ответить
#37
(30.11.2019, 16:04)33fc48a7 писал(а): Даже если возникнет проблема со сбором переменных руками, полный их список элементарно достается скриптом в несколько строчек, который тупо ищет все инициализации переменных. И я никогда не предлагал редактировать легаси\уже существующий контент через новый интерфейс, поэтому вообще нет причин говорить о парсинге старого кода.
Разница в том, что база данных предоставляет не просто список, выводимый при помощи скрипта, а множество таких список и сортировок, по нужным критериям. Грубо говоря твой список, это список всех книг в библиотеке, а база данных-каталог в котором можно найти книгу нужного автора и жанра куда быстрее.

 
It's Alive! It's Alive!
Ответить
#38
(30.11.2019, 16:04)33fc48a7 писал(а): Даже если возникнет проблема со сбором переменных руками, полный их список элементарно достается скриптом в несколько строчек, который тупо ищет все инициализации переменных. И я никогда не предлагал редактировать легаси\уже существующий контент через новый интерфейс, поэтому вообще нет причин говорить о парсинге старого кода.
Не буду спорить потому что надо детально смотреть что там можно, а что нет. В некоторых языках можно динамически инициализировать переменную склеивая два куска текста например ещё с числом, а потом специально обращаться и так даже делают иногда (сам когда-то давно баловался похожим "метапрограммированием"). А в других такое возможно с ассоциативными массивами/хэштаблицами. Ещё там где типы задаются неявно желательно этот тип узнать, либо придётся всё приводить к строке что не оптимально, хотя в ряде случаев в одну переменную пишут и строки и числа и не всегда легко размотать такой клубок. Короче по-хорошему это не элементарно достаётся. Впрочем для простых игр или игр с однозначной структурой может и прокатить пройтись регуляркой.
Но вообще наколеночное решение которое тупо сбоку и толком не знает о игре не факт что хорошо приживётся (то что нагенерировано и старый код могут разойтись и внезапно могут появиться пересечения переменных что приведёт к странным ошибкам, следить за этим надо хорошо и строго навязывать методологию именования), хотя для проектов с нуля может и пригодиться.
Надо только не забыть добавить строчку
Код:
<!-- ВНИМАНИЕ, ДАННЫЙ ФАЙЛ СГЕНЕРИРОВАН АВТОМАТИЧЕСКИ, НЕ ТРОГАЙТЕ ЕГО РУКАМИ! -->


(30.11.2019, 16:04)33fc48a7 писал(а): Будут эти данные писаться в JSON или .rpy скрипт - имплементация обоих вариантов по времени занимает одинаково.
Неа. Это уже похоже на теоретику.
Мне сериализовать объекты/массивы из памяти в джсон 2 строки (если выкинуть строчки по проверке на ошибки), одна из них вызов библиотеки JSON, вторая запись в файл, а вот с rpy это не так. Мне надо написать генератор кода ренпи-питона, либо найти готовую библиотеку под это (и научиться ей правильно пользоваться), но даже имея генератор надо всё равно ещё задать правила генерации из внутреннего представления в представление которое поймёт renpy, то есть ещё изучить ренпи. Это ещё поверхностно, там будут свои нюансы.

(30.11.2019, 16:04)33fc48a7 писал(а): Писать движок собственно для показа картинок и текста с переходами в 2020м вообще странно, это все умеет браузер, который есть на каждом компьютере.
Ну вообще-то Lambada как раз предлагал использовать электрон который суть браузер только местами порезанный и причёсанный под автономную работу.
Да причём тут вывод текста и картинок? Это меньшая часть движка и сейчас полно библиотек для работы с графикой.
Кстати с браузером надо ещё уметь работать, а то некоторые не очень здоровые особи могут всё генерировать в один большой html-dom, где просто неактивные экраны "скрыты" и чем больше игра на таком движке, тем тормознее она будет обрабатываться в обозревателе.

Давай закончим на этом.

 
1
Ответить
#39
(24.11.2019, 09:33)de295492 писал(а): И конечно и на пиво надо собирать уже не Васе, а Васе, Пете, саше и Сереге, ну можно еще Никите, но не обязательно.

Мне нравится как все начинают с энтузиазма а потом все опирается на деньги. Согласен, без материальной поддержки сложно поддерживать интерес к своему детищу но ведь не обязательно просить людей денег за развитие. Вообще есть много способов монетизации. От рекламы до подписки на контент. Есть сайты которые по сути купят право на публикацию игры... Не нужно ориентироваться на выручку от проекта сразу, ее не будет. Изначально нужно фиксировать взгляд на идее, если она интересна и команде интересен проект они его сделают и это положит начало их делу, а если нет то их обвинят в том что проект изначально ничего не предвещал и зря вы не развернули дискуссию на еще 20 страниц на форуме после которых любой проект умирает еще до рождения.

(24.11.2019, 05:00)5fd3ce82 писал(а): Нет, в жизни все не так просто. Это как складывать все яйца в одну корзину и надеяться авось пронесет. А ведь он забросит, 100%. Гарантированно забросит. Задача в том, чтобы другие смогли подхватить эту активность как можно проще и быстрее. Новое поколение энтузиастов. От движка зависят возможности игры, масштабируемость, платформы, на которых ее можно играть, как легко ее поддерживать и много чего еще.  Человек-оркестр на QSP это что-то вроде "делаю всего понемногу, но ничего толком не умею". Потому я и написал что в такой модели можно разделить труд и при этом люди будут слабо связаны и каждый сможет получать денежку за свою работу и эти люди могут меняться без существенного ущерба проекту.

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

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

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

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

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

 
if (!is_type('Programmer')) die('not for you');
Ответить
#40
(04.12.2019, 14:06)476388e4 писал(а): Мне нравится как все начинают с энтузиазма а потом все опирается на деньги. Согласен, без материальной поддержки сложно поддерживать интерес к своему детищу но ведь не обязательно просить людей денег за развитие. Вообще есть много способов монетизации. От рекламы до подписки на контент. Есть сайты которые по сути купят право на публикацию игры... Не нужно ориентироваться на выручку от проекта сразу, ее не будет. Изначально нужно фиксировать взгляд на идее, если она интересна и команде интересен проект они его сделают и это положит начало их делу, а если нет то их обвинят в том что проект изначально ничего не предвещал и зря вы не развернули дискуссию на еще 20 страниц на форуме после которых любой проект умирает еще до рождения.
Я не про выручку, я скорее про то, что если будет каждый человек работать автономно, то когда захочется монетизации, не "если", а "когда" потому что на определенном этапе проэкт переходит те рамки, за которыми можно работать чисто на энтузиазме, с ооочень редкими исключениями, тогда монетизацию будут собирать не команде, а именно что пете и васе. Я не говорю, что это плохо, или что модель нежизнеспособна, просто это будет трудно, но если все получится, наверное это будет достаточно стабильная модель.
(04.12.2019, 14:06)476388e4 писал(а): Если кто-то готов проявить инициативу в создании команды для подобного проекта я бы подошел по сути на все роли, хоть в некоторый (бэкэнд) я и не считаю себя даже хорошим программистом (да и вообще я не программист, а менеджер) я бы мог сверстать что-то что бы положило начало всему. Дайте знать если у этого всего будут еще энтузиасты, ведь я тоже старался запустить комьюнити проекты не мало раз. Все упирается в то что комьюнити на этих же форумах твердят что хотят лишь потреблять, но не производить контент. Я уверен что если комьюнити интересен проект то он будет идти вперед не смотря на разработчиков которые уже давно отьехали.
Не только в комьюнити, но и в то, что разрабам интересно одно, комьюнити другое, а иногда разные интересы даже в одной команде. Взять ту же провинциалку, из которой вырезали зоо контент, а потом выпустил(а) часть команды отдельным модом. Поэтому, прежде чем обьединяться, было бы круто обрисовывать интересы)

 
It's Alive! It's Alive!
Ответить
#41
Lambada, просто нахуй. Сделайте это, сделайте то. Выссказывания в духе Фауста. Возьмите, БЛЯДЬ, и сделайте. Тупо возьмте, сука, любую, заинтересовавшую Вас версию любой игры и делайте. А растекаться камофьёй по древу тут все горазды.

 
Ответить
#42
@28d7847f, очень экспрессивно, но можно вопрос: что такое камофья? Я просто первый раз подобный термин встречаю. Что же по сабжу, говорить всегда проще чем делать, равно как и советовать. Потому что совет дается из соображений идеального представления ситуации, а ситуация всегда решается исходя из реального ее представления.

 
It's Alive! It's Alive!
Ответить
#43
@2f4af7de, я так понимаю это однокоренное с cum

 
Ответить
#44
@e2f4f37b, ну я тоже подозреваю, что он малафья хотел написать, но вдруг это какое-то слово обозначающее что-то другое и мы ошибаемся?

 
It's Alive! It's Alive!
Ответить
#45
@2f4af7de, не ошибаетесь. Что хотел писать, то и написал.

 
Ответить
#46
@2f4af7de, Джек Восьмеркин - американец )))
Чо поделать.. язык развивается.

 
Ответить


Переход:


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