Форум » » Советы по реализации » Ответить

Советы по реализации

Hertz: Да, на форуме уже есть темы "вопросы" и "как это сделать?", но там обсуждается в основном код. А здесь я предлагаю советоваться по поводу самого построения игры.

Ответов - 60, стр: 1 2 3 All

Hertz: Итак, мне нужен совет по реализации карты. Собственно в игре будет город, по которому можно будет перемещаться, причём количество перемещений в течении "игрового дня" будет ограниченно энергией героя (проще говоря он будет уставать ходить туда-сюда и ему нужно будет отдыхать у себя дома). При этом (возможно, но не факт) на расход энергии будет влиять отдалённость того или иного объекта от места жительства героя. Перемещаться можно будет разными способами (пешком, автобус, такси, авто). Как лучше всего реализовать карту? 1) таблица, где в каждой ячейке будет небольшой gif-фрагмент карты (возможно с координатами) 2) текстовый список, в котором будут написаны названия всех известных мест которые можно посетить 3) текстовый список адресов

Серый Волк: Голосую за второй вариант ) Не знаю, какова будет степень "погруженности" в игре, но адреса не кажутся хорошей идеей.

MasterSet: Карта лучше ИМХО. Если сумеешь реализовать прямо - что не совсем тривиально на QSP. А если список, то лучше вложенный и систематезированный - не просто все названия по порядку.


Nex: Hertz однозначно текстом.

Ajenta: Да, Hertz, лучше текстом. Второй вариант. Я, правда сейчас делаю первый, но никому не советую.

MasterSet: Неужели оно даже на Аэро криво выходит? (

Ajenta: MasterSet Не, оно везде хорошо выходит, но с этим надо долго возиться. :) Лучше потратить это время на текст :) Хотя, конечно, никто ведь не запрещает.

MasterSet: Никаких компромисов. Лучше потратить время на все вместе и сделать круто.

Hertz: Вообще я решил, что второй вариант самый подходящий и ес-сно его нужно систематизировать, иначе это уже не список. Но предполагаемая отдалённость мест друг от друга так же будет в игре, поэтому систематизировать я их буду географически, так называемыми районами. Т.е. будет текстовая карта.

MasterSet: Я кстати для виллы ровно сейчас пишу схему перемещений. Благо там все рядом и вопрос удаленности не стоит. Но я решил тоже текстовой навигацией, тем более что пунктом назначения там могут выступать не только места но и люди.

Ajenta: я тоже ещё подумаю :)

Hertz: кстати, могли бы тоже написать как у вас и что задумывается. мозговой штурм ещё никому не вредил. я свою систему почти додумал, завтра кину пару картинок, чтоб посоветоваться

Ajenta: У меня сложно всё, как всегда. Да и не люблю я свои идеи кучей обдумывать. Так что извиняйте. :)

MasterSet: Условия форума плохо подходят для брейн-шторма. Пока никаких революционно новых решений я не применял, так что и делиться особо нечем ) Если будет какая-то реально интересная находка - напишу.

WladySpb: Да, на самом деле брейншторм если и проводить, то лучше на канале) Правда, ифовцы в большинстве своём индивидуалисты, все пишут свои шедевры в одиночестве... Почти никто не умеет работать в команде, и почти никто не пытается)

Ajenta: Как это никто :)) WladySpb Напоминаю, что у меня теперь есть инет :) И можно кооперироваться.

MasterSet: Тут простой кооперацией не обойтись, тут нужна иерархия и подчинение. А кто же другого над собой главным признает, если ему за это не заплатят? ) Вспоминаются бессмертные строки: Однажды лебедь раком щуку... А воз и ныне там

MasterSet: Я вообще промолчу в тряпочку

Hertz: А я не брезгую чужими советами, со стороны-то всяк виднее...

WladySpb: Ajenta Ну, мы по моему уткнулись в разграничение обязанностей, и невозможность прийти к решению что делать) Впрочем, я прекрасно помню наши планы, только времени пока нет даже свою игру доделать

Ajenta: WladySpb Ну ладно, тогда после куспко. :) ;)

MasterSet: Вот такой еще совет мне бы возможно пригодился. Сначала преамбула: В японских виртуальных новеллах как правило используется система с разветвлением сюжета в нескольких ключевых точках, что в итоге приводит к довольно большому вариантов концовок. Иногда неверный выбор или серия выборов может обрубить игру посередине и дать "плохую концовку". И ЧСХ, эти выборы почти всегда совершенно не очевидны. Ну например, приглашаешь ли ты девушку в ресторан или в кино. Заранее абсолютно не понятно какой может быть результат в том или в другом случае. Фактически, на 80% ты действуешь наугад. Зато, вроде как неожиданные повороты сюжета. В чем собственно амбула? Я сейчас делаю игру очень похожую по построению на японскую VN, но выборы там по большей части довольно очевидны. Вплоть до явного выбора между хорошим и плохим поступком - одно из двух. И в последствии сюжет вывертов не преподносит - т.е. "хороший" выбор действительно оказывается хорошим, а "плохой" - плохим. Таким образом мы получаем гораздо большее понимание того, какое влияние на сюжет оказывают действия персонажа. Можно как то планировать дальнейшие события. С другой стороны, пропадает интерес самой ситуации выбора. Когда не знаешь, то словно играешь в лотерею и это может заводить само по себе. Каково ваше мнение?

Hertz: Так, а в чём проблема? ИМХО, контроль ситуации - это именно то, что и нужно игроку. Если я сделал хорошее дело - я хочу чтобы меня хвалили за это. Мне кажется, что суть интерактивной новеллы в том, чтобы персонажи были настолько интересными, что хотелось бы играть в неё несколько раз выбирая каждый раз новый путь, как бы следить за действиями ГГ в разных ситуациях...

MasterSet: На том и стоим. Но сколько людей столько мнений. Хочу понять приоритеты. Может выдумаю еще что-то.

Nex: VN и текстовые игры, хоть и являются близкими родственниками, но все же это разные жанры. Если уж сравнивать, берите книгры - они целиком построены на ситуационном выборе, и очень в этом преуспели. Выбор не обязан быть ни предсказуемым, ни непредсказуемым - все зависит от конкретной ситуации и желаний автора. Игра должна быть интересной, а получается ли это из-за хорошего сюжета, или интересных ситуаций выбора - дело автора. Для ситуационного выбора хорошим тоном будет предоставить игроку несколько логичных вариантов поведения, каждый из которых будет иметь свои плюсы и минусы, очевидные для игрока. Примеры плохого выбора: Вас бросила девушка. Что делать? 1. Повешусь 2. Застрелюсь 3. Напьюсь (Выбор слишком очевиден) Перед вами две двери. В какую пойдете? 1. В левую 2. В правую (Слишком мало информации для осознанного выбора) Пример хорошего выбора: К вам приближается агрессивно настроенный гопник, по его оценивающему взгляду вы понимаете, что сейчас расстанетесь с последними деньгами. Что делать? 1. Отвлечь внимание и атаковать 2. Повиноваться и отдать часть денег, сделав вид, что больше нет 3. Убегать

Nex: Кстати, очень рекомендую прочесть Билль о правах игрока.

MasterSet: А ссцылку?

Hertz: ссылка

Nex: Hertz не ту ссылку даешь. Вот - Билль о правах игрока на IFWiki Также очень рекомендую почитать раздел статей "Выразительные средства" - ссылка

MasterSet: Вот это ИМХО ересь: XVII …знать, насколько он продвинулся в игре И еще большая ересь использовать разбиение на "главы", что бы игрок знал насколько он близок к завершению. Да и абстрактные очки я не люблю. В жизни вы знаете сколько времени до конца той или иной истории в которую вы попали? Иногда вы можете предполагать что-то, иногда понятия не имеете. Но что уж точно так это то что боженька не показывает вам на небе надпись "Вы набрали 52 очка из 100 возможных". Скорее вы ориентируетесь на то, каков желаемый результат и что еще вам нужно сделать, чтобы прийти к нему. А глав в игре может быть 3, а может и 100. А может вообще не быть - и это неплохой вариант. Кроме того, все что там написано довольно сильно ориентировано на парсерные игры, а у нас как-никак менюшный. Многие вещи просто не актуальны. Но для общего развития полезно, спасиб.

Ajenta: А я думаю. что игрок должен знать, что в игре три главы, к примеру. или видеть карту - по которой надо ходить. В общем, чтобы было что-то, чтобы игра не казалась бесконечной.

Nex: MasterSet некоторые действительно неактуальны, из-за того, что билль написан для парсерных игр, но ради оставшихся его стоит прочесть.

MasterSet: Угу. Вызывает интерес и такой еще разрез... В ходе написания игры вырабатывается некий подход к оформлению кода, некоторые наработанные приемы, которые используются там раз за разом. Но где-то к середине игры у вас может возникнуть новая идея, о том как тол или иной подход можно улучшить. И тут мы сталкиваемся с проблемой. Чтобы заработал улучшенный подход требуется внести довольно серьезные и общирные правики в уже написаный, работающий и отлаженный код. Замечу, что это надо делать не для исправления ошибки, а просто для внесения новой функциональности или удобства. Но лениво. Сталкивался с этим уже неоднократно. Вот свежий случай. В La Villa Esperance реализована смена времени суток, причем ночь так же является игровым временем. При этом все локации пресдавтленны в игре графически. Как несложно догадаться, смена темного и светлого времени суток должна отражаться в графическом дизайне локаций. Так или иначе эта проблема решалась с начала игры, но теперь появилось более оптимальное решение, однако оно требует изменений в существующий код игры, а он уже близится к 200 kb. У вас такое бывает? Как предпочитаете решать проблему?

Hertz: Бывает... Нужно просто писать код так, чтобы его легко было править. Т.е. все повторные элементы выносить и не повторять их. Например, если у тебя в начале каждой локации в коде определяется день или ночь, то лучше это определение дня или ночи положить в отдельную локацию и реализовывать через gosub. Тогда и менять придётся код только в одном месте. Я стараюсь всегда делать так.

MasterSet: Определение то лежит в отдельной локации. А вот ссылки на задники лежат в коде тех локаций где они участвуют. Иначе не выходит, потому что задники меняются в процессе происходящем на локации. Это уже сделано, значит теперь надо искать все такие случаи и править их ручками. Делать легко модифицируемый код, конечно хороший совет, но трудно реализуемый. Особенно когда ты понятия не имеешь, что именно будешь модифицировать по ходу. Я так как я экспериментирую с вариантами интерфейса на которые QSP не заточен, эта задача усложняется вдвойне. Как говориться - хорошая мысля, приходит опосля.

Ajenta: 200 кб это фигня - значит всё ещё можно не только исправить, но и переписать пару раз :))

MasterSet: Ajenta пишет: А я думаю. что игрок должен знать Я хардкорщик. Считаю что игрок должен знать в идеале столько же, сколько и его герой в рамках игры. Другое дело что в таком виде это не реализуемо. Но можно добиться хотя бы того, что бы при первом прохождении игры игрок знал НЕ БОЛЬШЕ чем ГГ. А если уж игра дает игроку данные которых нет у ГГ, я считаю это плохой миной. Но это конечно индивидуальные предпочтения. Не рассматривайте как призыв делать только так, а не иначе. Ajenta пишет: 200 кб это фигня - значит всё ещё можно не только исправить, но и переписать пару раз :)) Типун тебе на язык! Особенно учитывая что Дед Лайн - 28 текущего месяца. Цигель-цигель. И вообще я ленивый.

Byte: Это дедлайн по заявкам. Потом еще 2 месяца.

Ajenta: MasterSet пишет: Особенно учитывая что Дед Лайн - 28 текущего месяца. Типун тебе на язык. :) Я вообще ещё только начала игру писать. :)

MasterSet: Byte пишет: Это дедлайн по заявкам. Байт, ты зачем мне настрой сбиваешь? Работа программиста она ведь занимает ровно столько времени склолько на нее выделено. Поэтому заявка будет только одновременно с плюс-минус стабильно работающей игрой. А потом два месяца я их все буду править до вменяемого состояния. Нет, правда есть шанс, что если вилла хорошо успеется, то я заявлю еще одну игрушку и вот ее то буду делать следующие два месяца. А еще во всем что я наваяю надо будет грамматику и стилистику править. Ууу.... не. Дедлайн на основные работы 28-е полюбому. Ajenta пишет: Я вообще ещё только начала игру писать. :) Ну ты же у нас опытный, матерый демиург. Победитель предыдущего года и вообще фаворит. Ты по-быстренькому справишсо )

Ajenta: Я фаворит?!! Типун тебе на язык ещё раз. :)))

MasterSet: OFFTOP А деваться некуда. Выиграла прошлый, автоматом в следующем фаворит. Cest la vie. ONTOP Обидно прямо, такие карисивые идеи приходят по ходу разработки, о том как оптимизировать код. Но для этого его придется переписывать напрочь. ЧСХ, потом это забудется да и не получится применить в другой игре, потому что там и специфика будет другая.

Nex: Оптимизацией кода можно заниматься бесконечно.

Ajenta: MasterSet Если совсем хорошая идея, то лучше переписать. 200 кб действительно немного. Зато потом удобнее будет.

MasterSet: В данном случае это примерно половина игры. Переделывать 50% целиком, что бы потом еще 50% было легче сделать? Такое прокатит только если трудозатраты на вторую половину будут отрицательными )

WladySpb: Аджента у нас не фаворит... Аджента у нас фаворитка) Вообще да, переписывать код это извращение, проще взять на заметку, и в следующей игре использовать более структурируемый код, поддающийся переработке в процессе.

Ajenta: Ну если 50%, то согласна, лучше сделать как говорит Влади.

MasterSet: WladySpb пишет: Аджента у нас фаворитка) Насколько мне известно, по-хорошему это слово не склоняется. Впрочем, никогда не думай, что ты иной, чем мог бы не быть иначе, чем будучи иным в тех случаях, когда иначе нельзя не быть. Особенно с новыми правилами (sic!)рускава языку.

WladySpb: MasterSet Я перестал уважать правила русскава языка после того, как предложили отменить букву Ё ) А фаворитка по моему вполне нормальное слово, хотя я не специалист, но такое склонение не режет слух, как например "бухгалтерша" или "секретарша".

Hertz: для простоты опишу условную модель. Есть два персонажа: А и Б. Оба движутся по сюжетной линии. Есть два режима: когда ГГ либо А, либо Б. Второй является NPС. В каждом режиме перед А и Б будут различные выборы, которые влияют на сюжетную линию. Поскольку сюжетная линия в целом будет общей для обоих, то возникает дилемма: что делать с выборами NPС? вижу два варианта: 1) рандом т.е. если играя за персонажа А игрок в месте Ц выбирает между 1, 2, 3 и 4, то играя за персонажа Б - в месте Ц персонаж А (уже NPС) случайным образом выберет из 1 2 3 4 вне зависимости от действий ГГ. 2) жесткий выбор т.е. если играя за персонажа А игрок в месте Ц выбирает между 1, 2, 3 и 4, то играя за персонажа Б - в месте Ц персонаж А (уже NPС) совершенно точно выберет один вариант (выбранный автором игры), например 2. как лучше? Заранее оговорю: вариант, когда персонаж Б (ГГ) может влиять на выбор персонажа А (NPC) в месте Ц не подходит. Такова концепция игры. Вот.

MasterSet: Как то сложно у тебя. Во-первых, не NPS а NPC, все-таки бо Non-Player Character. А выбор варианта зависит от твоего желания. Как тут посоветовать какой лучше? Хотя я знаю какой - нужно написать AI )))

Ajenta: Hertz ИМХО: Вообще если тебе не лень прописывать варианты, то делай рэндом в обоих случаях, так интереснее и непредсказуемей. А если лень, то лучше тогда делай второй вариант.

ASBer: MasterSet пишет: Как тут посоветовать какой лучше? Хотя я знаю какой - нужно написать AI ))) В данном случае достаточно присвоить вариантам ряд параметров и написать оценочную функцию, которая в зависимости от текущего состояния игры вычисляет вес для каждого варианта по его параметрам. Далее выбираем вариант с наибольшим весом. Например, в каждом варианте выбора можно указать благоприятность этого варианта для А и для Б. Если персонаж А ранее поругался с Б, оценочная функция Б будет ставить наибольшие веса вариантам, наименее благоприятным для А. В результате Б начнет пакостить А. Как правило, сложность заключается в написании самой оценочной функции :)

Hertz: Ajenta пишет: ИМХО: Вообще если тебе не лень прописывать варианты, то делай рэндом в обоих случаях, так интереснее и непредсказуемей. Так варианты в любом случае будут прописаны. Я ж объяснил - по одному и тому же сюжету движется несколько героев, а за одного из них решает что делать игрок. Развитие событий будет прописано для всех персонажей в любом случае. ASBer это интересный вариант, надо попробовать...

MasterSet: Нужны свежие идеи для рунной магии в Хранителе Старграда. Магия там рунная и непосредственно в бою не применяется. Т.е. мы считаем что заклинание может держаться один день, вплоть до какого-то события либо действует мгновенно но в мирной, спокойной ситуации. Сейчас есть всего два заклинания в шести вариантах каждое: прокачка оружия элементыми силами и прокачка доспеха ими же. Хитов у персонажа нет - если его ранили, то он должен либо прямо в бою вылечиться зельем, либо падать. Соответственно вариант лечилки не проходит. Думаю будет еще заклинане на дополнительный хит. Возможно на повышение коэффицента брони. Что еще можно сделать? Кидайте идеи без разбора, первое что в голову придет. Я разберусь можно ли это приспособить

Nex: Заклинание "навигации" - всегда знаешь где ты находишься и куда идти; Магический шар/освещение - понятно; Видеть ауру - чуешь ауру NPC (добрый/злой/нейтральный); Защита от магии - защищает от простых магических атак и ловушек; Сытость-бодрость - пока действует заклинание, не голодаешь и не устаешь; Приворот - повышает харизму.

MasterSet: Решил обойтись четырьмя линейками заклинаний по шесть типов в каждой. Прокачка оружия, прокачка доспехов, прокачка самого себя и призыв монстра. Того, с вариациями 24 заклинания. Учитывая что игра не про магию, думаю хватит. А руническая система будет немного напоминать цветохимию, хотя ко мне эта концепция пришла независимо. Идеи в общем витают воздухе ) ЗЫ: Ах да. Еще будет 25 заклинание - портал хаоса. Это если перепутал что-нибудь в рунной последовательности. Дает рандомный эффект.

Сидан Рейдан: Ну-ка, граждане, у кого фантазия активирована? Моей, похоже, пора менять энерджайзер. Суть: В теоретической локации есть две условных группы действий. Первая - это действия, выполняемые книжным персонажем. Протагонистом сюжета, короче. Вторая - некоей не то астральной, не то ещё какой бестолковой силой (я её природу в сюжете ещё не придумал...), которая, как бы, вроде и тоже персонаж, но чёткого обличия по началу игры не имеет. Но активно участвует. Так вот, собственно, вопрос. Как бы можно было визуально, доходчиво разделить действия персонажа и этой силы в "списке действий"? Конструкция "<b>Название действия</b>", я так понимаю, технически не катит... UPD: Ох ты ж чёрт, катит О_о Переформулировка вопроса. Можно ли как-то задать действию цвет, опять-таки, для доходчивого визуального разделения? <color=blue>Название действия</color> -...всё-таки не работает.

Byte: Неправильно задаешь цвет. <font color=red>ТЕКСТ</font>

Сидан Рейдан: Чорд >_< Не только фантазии пора менять батарейки... Спасибо)



полная версия страницы