За Програмирането и Книгите-игри

2011:

<Episode Id="23" Title="23">
<Tab/>Коя от кодовите думи имаш?
<br/><br/>
<Option Episode="10" Condition="codewords has thief" Visibility="true">крадец</Option>
<Option Episode="10" Condition="codewords has criminal" Visibility="true">престъпник</Option>
<Option Episode="20" Condition="codewords has brother" Visibility="true">брат</Option>
<Option Episode="30" Condition="(!codewords has brother) and (!codewords has criminal) and (!codewords has thief)" Visibility="true">Нито една от горните</Option>
</Episode>

<Episode Id="24" Title="24">
<Tab/>- Имам проблеми с „Тъмното братство” – отвърнах. – Ако не се бях измъкнал от Аркадия, можеше вече да съм мъртъв.
<br/><Tab/>Капитанът ме погледна с недоверие, а отзад някой изсумтя. Чернокосият мъж се обади с нервен тон:
<br/><Tab/>- Внимавай какви ги говориш, пишлеме! Да не мислиш, че ще ти повярваме на глупостите тук? Някои неща не са за шега!
<br/><Tab/>Реших да им кажа малко повече, защото не ми харесваше накъде ситуацията тук, а в Карсеп така или иначе ме очакваха прекалено много неприятности, че да ме притесняват допълнителните, които можех да си навлека с издаване на информация.
<br/><Tab/>- Не се шегувам – казах сериозно. – Работил съм не веднъж с братството, а последния път бях така забъркан, че да имат полза да се отърват от мен. Собственикът на „Куцата медуза”, Тано, той вземаше задачите.
<br/><Tab/>Нямаше как все някой от тях да не е чувал ако не за Тано, то поне за „Куцата медуза” и хората, които се събираха на това място. Кръчмата имаше своята слава сред тези среди.
<br/><Tab/>Печелиш 2 точки "Респект" и кодова дума "брат".
<br/><br/>
<Add To="respect" Value="2" />
<Add To="codewords" Value="brother" Title="брат" />
<Option Episode="16">Продължи напред</Option>
</Episode>

Това в браузър ли се визуализира или е предвиждано за native мобилно приложение?

Възможно ли е при теб да имаш мета събитие вътре в избор - <Add To/> вътре в <Option/>, след като бъде натиснат линка?

Възможно ли е при теб да имаш мета събитие вътре в условие? От това, което виждам <Add To/> таг ще присъства вътре в Condition property, което ако е така, е кофти смес.

И последно - имаш ли възможността да извикваш външни функции директно в Condition property или в тялото на Episode?

- В момента XML формата се обработва от Silverlight app на Legacy of Kreya, което е кофти решение, но нямах избор - беше това или нищо.
- Не е възможно, не е и нужно - събитията се случват на ниво "епизод", не на ниво "клик", освен случаите с магазин и избор на умения, които не са илюстрирани в дадения пример
- Виж горния отговор
- Не, но condition-ите имат достатъчно добра AND / OR / NOT булева алгебра да извършиш каквото ти трябва

Предположих, че не е било нужно за конкретния пример. Аз искам да постигна вариант, както при inkle, където възможно най-много случаи от съществуващи механики са покрити лесно без да утежняват описанието на самия текст.

Например, някой път събитието - явно не в твоя случай - трябва да се случи на ниво "клик", а не на епизода, на който попадаш, тъй като към този епизод може да водят "кликове" от няколко други места, но само на определени от тях да се случва събитието.

Според мен това, че имаш булева алгебра от conditions не е достатъчно. Самите conditions трябва да е възможно да бъдат nested.

Например, правенето на заклинание от 4-то ниво изисква 5 мана точки. Обаче, ако си под влиянието на опиат, пиян си, под влияние на чужда магия и т.н. всички твои заклинания, не само от 4-то ниво, вече могат да изискват 10 мана точки. Тогава, при действието "правене на магия", играта трябва да отчете правилната цена за твоята мана.

Удачно е да имаш възможност да слагаш едни в други комбинация от условия или комбинация от събития + условия. Нещата изглеждат много по-подредени и няма да се появяват салами в кода. Удобно е, че ако тестерите на книгата решат, че геймплея става невъзможен при 10 мана точки под влиянието на опиат, но е ОК при 8, променяш само на едно единствено място в кода.

Конкретно примера за маната не е ли по просто ако си под въздействието опиат или почие директно да вземеш накаква стойност която винаги ти добавя +5 към разхода докато не отпадне въздействието?

Ако ти добавя +5 в продължение на 20 епизода после ще трябва да отидеш и ръчно да редактираш ако искаш да промениш това +5 на 20 места.

А ако е сложно условие, например ако прибавя +3 за 1-во ниво, +5 за 2-ро ниво, +10 за 4-то ниво, става още по-саламесто.

Ако на дадено място използваш комбинация от умения - да кажем, нямаш еди-коя-си магия от 4-то ниво, но можеш да постигнеш ефекта с две по-низши магии от 2-ро и 3-то ниво съответно, и си под въздействието на опиат в това време, става направо напрягащо цялото това да се опише в самия XML.

Друго нещо е определени събития да се случват само ако набор от условия отговарят на истината. Големи проверки с двевника бяха особено силно застъпени в "Герои" на Ерик Берт, трябва да харесам някоя по-сложна от там за илюстрация на пример.

Btw решението на Inkle да споделят engine-a си с open source света е интересно бизнес решение. На който му е любопитно може да прочете тук - www.develop-online.net/tools-and-tech/wh...-and-sorcery/0219536

Следващото им заглавие, което разработват от известно време, ще е повече визуално-ориентирана книга-игра отколкото текстова. Лично аз предполагам, че ще излязат с нещо по-добро от Tin Man, които пуснаха "The Warlock of Firetop Mountain".

Като цяло ми харесва много тенденцията, която забелязвам у компаниите, които се занимават с разработването на мобилни и компютри игри по книгите-игри. Бих искал догодина да изляза и аз с някакъв конкурентоспособен продукт.

Визирах проверка.
Ако имаш кодова дума фиркан разхода за мана ти е +5 или х2, според системата в книгата. Така в кода виднаги ще се прави проверка дали ще имаш завишен разход на мана, а текста на кода е един и същ и можеш с няколко щраквания да го смениш на всякъде като блок.

Спасе, в момента, в който трябва да разчиташ на edit -> replace в голям блок от текст, ще допускаш грешки. Не ми се влиза в спор с теб защо това е така, ти си човек, който прави много тексто-обработка, но аз съм програмист и като такъв съм мързелив, знам, че допускам грешки и искам максимално да предовратя това. Мазалото става още по-голямо като сте няколко души, които работите по един и същи текст. Да видя как ще си "подвиквате" какви промени правите върху текста и кога.

Визираш нещо различно и по-опростено. Давам ти други примери. Говоря за случаи, в които имаш вложени една в друга проверки. Както и вложени проверки и събития. Вместо да описвам 20 различни проверки, мога да опиша само 5-6 и да ги преизползвам. Нищо не ти пречи да направиш абсолютно всичко на ръка, но когато правиш следващата книга-игра, която е по-различна от тази, трябва да преправяш много от нещата наново.

Ще се опитам да опиша по-подробно ситуациите.

Да кажем, че в текста на много и разнообразни места се използват магии и заклинания.

Имаш герои с различни показатели, между които да избираш. За един клас герой - магьосник, правенето на заклинания от 1-во ниво изисква 1 мана. За друг - войн, 3 мана.

В текста на самата игра имаш следния епизод:

Първо, играта трябва да прецени дали опцията да направиш заклинание е активна - имаш ли заклинание от 1-во ниво, имаш ли необходимата мана, под влияние на опиат ли си. Вместо да напиша вътре в самия XML тези проверки една след друга, аз си създавам функция - CanCastSpell, на която подавам параметър заклинанието - Bolt.

Така изнасям мета проверките извън текста. Функцията се извика от кода CanCastSpell(bolt) и вътре в нея ще се проверят в каквато последователност или булева алгебра е необходимо логиката за клас, за първо ниво магия, за опиат.

След което, ако човек избере тази връзка, ще последва събитие - CastSpell(bolt), в което ще има AdjustManaPoints().

И за единия, и за другия случай трябва да събера информация за текущия персонаж на играча, която е мета и историята не я касае. Така текстът остава четим, а аз мога да преизползвам в кода логиката за IsOpiated(), AdjustMana(spell level, character class) и т.н.

По всяко време мога да сменя правилата, по които маната бива използвана. Мога лесно да вкарам и допълнителни състояния на героя като Stunned, Prone, Bashed без да пипам самия XML.

На мен ми е интересно в твоя случай как е представено това описание. Викаш в таблица, формула, фиксирано е подробност, но може би аз не мога да си го представя съвсем точно какво имаш предвид. Шаблони - да, но какви шаблони визираш?

Edit: Само да поясня - това може да бъде описано по много начини - в отделни файлове, в различни формати, в база данни таблици (предполагам, че това си имал предвид), а кодът да е само консуматор и да навързва логиката. Просто във фрагмента от XML на Торо не видях всички възможности и си предтсавям има ли ги, няма ли ги.

ringlas писа: писа:

Например, някой път събитието - явно не в твоя случай - трябва да се случи на ниво "клик", а не на епизода, на който попадаш, тъй като към този епизод може да водят "кликове" от няколко други места, но само на определени от тях да се случва събитието.

В този епизод отиваш на X, в другия отиваш на Y. X=Y (copy paste) с разликата, че на едното място губиш 5 мана, а на другото - 10. Не е елегантно или ефективно решение, но е ефикасно.

Например, правенето на заклинание от 4-то ниво изисква 5 мана точки. Обаче, ако си под влиянието на опиат, пиян си, под влияние на чужда магия и т.н. всички твои заклинания, не само от 4-то ниво, вече могат да изискват 10 мана точки

Слагаш два отделни избора за кастване на заклинанието - единия е с condition да си пиян, другия с condition да не си пиян. Правиш visibilty-то на тези два избора да е False, т.е. когато не изпълняваш condition-а, въобще не се показва. Играчът винаги вижда само едното "Направи заклинание (5)" или "Направи заклинание (10)". Отново е спорно колко е универсално - ако има някакъв супер ескалирал случай да има една камара if-ове ще се убиеш да copy-paste-ваш Option-и, от които накрая играчът ще вижда един, не е ефективно, но е ефикасно.

Торо,

Абсолютно през цялото време говоря за ефикасност.

Ефикасността показва отношението на постигнатия резултат спрямо вложените разходи (енергия, труд, финансови средства). Ефикасността е свързана с икономичността на действията. Чрез нея се дава отговор на въпроса, дали нещата се вършат икономично, по "правилния" начин. Колкото вложените разходи са по-малки, толкова по-ефикасни са действията и мероприятията.

Това, за което ти говориш, е да направиш нещото да работи. Това не е добра практика при поддържане, промяна, добавяне на нови функционалности и прочие. Сам знаеш това много добре. Идеята, поне според мен, е да обменим best practices. Аз виждав такива в app-a на Inkle.

Съгласен съм и че не е добра практика да се съшиват нещата.
Обяснявам просто, че със семплата система също са възможни решения на посочените проблеми, които ми се стори, че считаш за нерешими чрез нея.


3.2.14 ефикасност - степен, до която планираните дейности са изпълнени и планираните резултати са постигнати
3.2.15 ефективност - съотношение между получени резултати и използвани ресурси
q-systems.5co.org/index.php?topic=528.10;wap2

и още

Другата ефективност (efficiency), която за разграничение ще кръстим ефективност КПД (коефициент на полезно действие) означава правенето на нещата по най-икономичен начин, с минимум ресурси. Някои колеги си вършат работата с 300 телефонни разговора и 900 изговорени минути, а други вършат същата работа с 500 разговора и 2000 минути.

И последната дума в категорията е ефикасност. Ефикасност е постигането на целта, способността да достигнем желаното количество ефект или успех. За разлика от ефективността КПД, ефикасността не се интересува от количеството използвани ресурси за постигане на целта, а само от постигането й.
www.academy-for-leaders.bg/blog/post/81