کویسٹ آرکیٹیکچر

کوئی اسکرپٹ نہیں ہیں۔ منطق موجود ہے: Romergo میں نوڈز اور ویری ایبلز کس طرح سے ترتیب دیے گئے ہیں۔

جب گیم ایڈیٹر میں منطق کی بات کی جاتی ہے، تو عموماً لوگ فوراً اسکرپٹس کی طرف چلے جاتے ہیں۔ کہیں پر مصنف JavaScript لکھتا ہے، کہیں Python، اور کہیں وہ انجن کی اپنی زبان سیکھ رہا ہوتا ہے۔ یہ تقریباً لامحدود آزادی فراہم کرتا ہے، لیکن اس کے ساتھ نحو کی غلطیاں، جام شدہ حلقے، ناموافق پلگ انز، اور ایسا کوڈ بھی آتا ہے جسے چھ مہینے بعد اس کا مصنف بھی دیکھنے سے گھبراتا ہے۔

میں نے Romergo میں ایک مختلف راستہ اختیار کیا۔ کویسٹ کے اندر کوئی بھی مرضی کا اسکرپٹ نہیں ہے۔ فنکشن داخل کرنا، نیٹ ورک ریکویسٹ کرنا یا پلیئر تک براہ راست رسائی حاصل کرنا ممکن نہیں ہے۔ اس کے بجائے، کہانی ایک محدود لیکن کافی وضاحتی سیٹ سے جمع کی جاتی ہے: منطقی نوڈز، ویریبلز، شرطیں اور اثرات۔

اس کا یہ مطلب نہیں کہ Romergo میں صرف سادہ شاخیں بنائی جا سکتی ہیں۔ کھلاڑی کے فیصلے یاد رکھے جا سکتے ہیں، پوائنٹس گنے جا سکتے ہیں، اختیارات کو دکھایا یا چھپایا جا سکتا ہے، اگلے ابواب میں مختلف راستے منتخب کیے جا سکتے ہیں، بے ترتیب واقعات ترتیب دیے جا سکتے ہیں اور انٹرایکٹو انٹرفیس بنایا جا سکتا ہے۔ بس، حکم «اس کوڈ کو چلاؤ» کے بجائے مصنف بیان کرتا ہے «اس حالت میں یہ ہونا چاہئے»۔

گراف پہلے سے ہی ایک پروگرام ہے

سب سے بنیادی منطق Romergo براہ راست باب کے نقشے پر موجود ہے۔ مناظر کو عبوری راستوں کے ذریعے جوڑا جاتا ہے، اور خاص نوڈز فیصلہ کرتے ہیں کہ کھیل کس سمت میں آگے بڑھے گا۔

اگر بہت آسان بنائیں تو، چھوٹا سا کویسٹ اس طرح نظر آتا ہے:

شروع
  ↓
گارد کے ساتھ گفتگو
  ↓
کیا پاس ہے؟
  ├─ ہاں → بند آرکائیو
  └─ نہیں → متبادل راستہ

یہ پہلے ہی قابل عمل منطق ہے۔ Player ابتدائی نوڈ میں داخل ہوتا ہے، سین دکھاتا ہے، ہسٹری کی حالت پڑھتا ہے اور مناسب ٹرانزیشن منتخب کرتا ہے۔ مصنف اسی راستے کو ایک سمجھنے کے قابل نقشے کے طور پر دیکھتا ہے، نہ کہ if، goto اور سروس شناخت کنندگان کے مجموعے کے طور پر۔


*حقیقی Flow کا ایک ٹکڑا Builder میں: Final Accusation کا منظر Switch میں فیصلہ پہنچاتا ہے، پھر کچھ If / Else حالت چیک کرتے ہیں اور مختلف اختتام تک کہانی کو تقسیم کرتے ہیں۔ نیچے کھلی Logic پینل تمام دستیاب سیٹ دکھاتی ہے: Dead End، Checkpoint، If / Else، Switch، Random اور Teleport۔*

ابھی Logic پینل میں چھ بنیادی نوڈز ہیں:

• **گیم کا اختتام** موجودہ راستے کو روکتا ہے۔ یہ ہار، برا اختتام، یا محض جان بوجھ کر بند کیا گیا نتیجہ ہو سکتا ہے۔
• **چیک پوائنٹ** اس مقام پر حالت کو محفوظ کرتا ہے اور نیا واپسی کا سفر شروع کرتا ہے۔ کھلاڑی چیک پوائنٹ پر واپس جا سکے گا، لیکن اس کے پیچھے نہیں جا سکے گا۔
• **اگر / ورنہ** ایک قاعدے کی جانچ کرتا ہے۔ صحیح نتیجہ میچ ہونے والے شرط پر لے جاتا ہے، جبکہ غلط ایک بیک اپ راستہ رہتا ہے۔
• **سوئچ** اس وقت استعمال ہوتا ہے جب انتخاب دو سے زیادہ ہوں۔ اس کی شاخیں اوپر سے نیچے چیک کی جاتی ہیں: پہلی میچ ہونے والی شرط عمل کرتی ہے، اور بغیر شرط والی شاخ ڈیفالٹ انتخاب بن جاتی ہے۔
• **Random** منسلک آؤٹ پٹ میں سے ایک کا انتخاب کرتا ہے۔ randomness اپنے seed اور پروگریس کے مرحلے کو محفوظ رکھتا ہے، اس لیے save کو بحال کیا جا سکتا ہے بغیر اس کے کہ کھلاڑی کو کسی دوسرے راستے پر بے ترتیب بھیج دیا جائے۔
• **Teleport** خود کچھ نہیں فیصلہ کرتا۔ یہ طویل بصری رابطے کو توڑنے اور بڑے نقشے کے دور دراز حصوں کو محتاط طریقے سے جوڑنے میں مدد دیتا ہے۔

Start اور Finish باب کو فریم کرتے ہیں، عام مناظر مواد دکھاتے ہیں، اور منطقی nodes انہیں راستوں میں تبدیل کرتے ہیں۔ اس سطح پر ہی ایک linear کہانی، ایک شاخ، کئی اختتام، ایک تصادفی واقعہ اور محفوظ واپسی پوائنٹ بنایا جا سکتا ہے — بغیر کسی script کی ایک بھی لائن کے۔

متغیر ایک کہانی کی یادداشت ہے

ایک گراف کافی نہیں ہے اگر کہانی کو یاد رکھنا ہے کہ پہلے کیا ہوا تھا۔ اس کے لیے کھیل میں تین سادہ قسم کے متغیرات ہیں:

• boolean حقیقت کو محفوظ رکھتا ہے: چابی ملی ہے یا نہیں، ہیرو نے جھوٹ بولا ہے یا نہیں، الارم فعال ہے یا نہیں؛
• number ایک عدد محفوظ رکھتا ہے: اعتماد، صحت، شواہد کی تعداد یا شہرت کے پوائنٹس؛
• string منتخب قدر محفوظ رکھتا ہے: راستے کا نام، فریکشن یا حل کا کوڈ۔

ہر ویری ایبل کی ایک کلید، مصنف کے لیے ایک قابل فہم لیبل اور ابتدائی قیمت ہوتی ہے۔ عددی ویری ایبل کے لیے اضافی طور پر کم از کم اور زیادہ از زیادہ کی وضاحت کی جا سکتی ہے، اور سروس ویری ایبل — کو پلیئر کے اسٹیٹس پینل سے چھپایا جا سکتا ہے یا صرف شرط پوری ہونے پر دکھایا جا سکتا ہے۔

اس میں سب سے اہم بات یہ ہے کہ ویری ایبلز پورے کویسٹ کے تسلسل سے تعلق رکھتے ہیں، نہ کہ صرف ایک منظر سے۔ اگر پہلے باب میں پلیئر نے پاس حاصل کیا، تو چوتھے باب میں اسی فلیگ کو چیک کیا جا سکتا ہے۔ فائنش کے ذریعے اگلے باب میں جانے پر اسٹیٹس صفر نہیں ہوتا۔ یہ منتخب کردہ اختیارات، لاگو شدہ اثرات، چیک پوائنٹ اور موجودہ رینڈم اسٹیپ کے ساتھ محفوظ رہتا ہے۔

یوں ایک سادہ مصنفی سائیکل بنتا ہے:

کھلاڑی کا انتخاب ایک قیمت لکھتا ہے
              ↓
متغیر حالت کو محفوظ رکھتا ہے
              ↓
شرط اسے بعد میں پڑھتی ہے
              ↓
گراف، منظر یا انٹرفیس اس پر رد عمل دیتا ہے

مثال کے طور پر، پہلے منظر میں "پائی گئی تصویر دکھائیں" کا انتخاب portrait_revealed = true مقرر کر سکتا ہے۔ بعد میں **اگر / ورنہ** نوڈ اس فلیگ کو چیک کرے گا اور نیا مکالمہ منظر کھولے گا۔ اس کے بعد، ٹرمینل انٹرفیس صرف ان کھلاڑیوں کے لیے اضافی ریکارڈ دکھائے گا جنہوں نے تصویر کو کھولا تھا۔

ایک متغیر تین مختلف حصوں کو ایک کوئسٹ سے جوڑتا ہے۔ اس کے لیے منیم طور پر سینز یا ابواب کے درمیان ویلیو منتقل کرنے کی ضرورت نہیں ہے: وہ ایک مشترکہ گزرنے کی حالت کو پڑھتے ہیں۔


*ویری ایبل route میں ایک کارڈ پر مستحکم کلید، واضح نام، ویلیو کی قسم اور حالت کی نمائش دی گئی ہے۔ انتخاب اور شاخوں کے ساتھ تعلقات اسی صفحے کے نیچے موجود ہیں۔*

انتخابات لکھتے ہیں، شاخیں پڑھتی ہیں

عام منظر میں، حالت کو تبدیل کرنے کا سب سے واضح طریقہ یہ ہے کہ انتخاب کے متبادل پر اثر شامل کیا جائے۔ بصری ایڈیٹر میں یہ اس طرح نظر آتا ہے جیسے کسی چیز کو تفویض کرنا:

«مریم پر اعتماد کریں» → ally = "mary"
«اکیلا جانا» → ally = "none"

اس کے بعد Switch کھلاڑی کو ally کے مطابق مطلوبہ منظر میں بھیج سکتا ہے۔ متغیرات کا صفحہ الگ سے دکھاتا ہے کہ کون سے انتخاب متغیر کو لکھتے ہیں اور کون سی شاخیں اسے پڑھتی ہیں۔ یہ ایک چھوٹی سی تفصیل ہے، لیکن بڑے مشن میں یہ سینکڑوں مناظر کی تکلیف دہ تلاش کو بدل دیتا ہے۔


*Switch کی شاخیں اوپر سے نیچے کی طرف چیک کی جاتی ہیں۔ اس مثال میں، آزمایشگاهی راستہ route = lab پر کام کرتا ہے، جبکہ رہائش route = habitat پر کام کرتا ہے۔*

شرائط عام موازنات کو سپورٹ کرتی ہیں:

• برابر اور نا برابر؛
• زیادہ، زیادہ یا برابر؛
• کم، کم یا برابر؛
• قیمت موجود ہے یا ابھی تخلیق نہیں ہوئی۔

سادہ صورت میں، مصنف متغیر، آپریٹر اور قیمت براہ راست If / Else یا Switch کی ترتیبات میں منتخب کرتا ہے۔ زیادہ پیچیدہ منطق کے لیے، عمومی runtime گروپس **تمام شرائط**، **کوئی شرط** اور نفی کو سمجھتا ہے۔

اس طرح کے اصول کو ساختی طور پر بیان کیا جا سکتا ہے:

{
  "op": "all",
  "conditions": [
    { "op": "gte", "key": "evidence", "value": 3 },
    { "op": "eq", "key": "alarm_active", "value": false }
  ]
}

یہ ایک چھوٹے اسکرپٹ کی طرح لگتا ہے، لیکن بنیادی طور پر ایسا نہیں ہے۔ یہاں کوئی فنکشن کال نہیں کیا جا سکتا یا کچھ اتفاقیہ نہیں بدلا جا سکتا۔ Romergo پہلے سے تمام مجاز عملیات کو جانتا ہے، ساخت کی جانچ کرتا ہے اور اسے Builder کے پریویو اور شائع شدہ Player میں یکساں طور پر انجام دیتا ہے۔

اثرات: پروگرامنگ زبان کے بغیر چھوٹے احکامات

حالت شرط کو پڑھتا ہے، اور اثر اسے تبدیل کرتا ہے۔ Runtime Romergo کئی ایٹمی عملیات کی حمایت کرتا ہے:

• set ایک مخصوص قدر کو لکھتا ہے؛
• inc اور dec عدد کو بڑھاتے یا گھٹاتے ہیں؛
• toggle ایک منطقی جھنڈا تبدیل کرتا ہے؛
• clamp عدد کو دی گئی حد کے اندر رکھتا ہے۔

عام انسپکٹر میں بنیادی سیناریو جان بوجھ کر سادہ ہے: ایک متغیر منتخب کریں اور set کے ذریعے نئی قدر درج کریں۔ جدید انٹرفیس لاجک میں، حالات اور اثرات کو قابل جانچ ڈھانچوں کی طرح ترتیب دیا جا سکتا ہے۔ مثال کے طور پر، ٹرمینل کے حالات کے درمیان منتقلی ایک ہی وقت میں فیصلے کو یاد رکھ سکتی ہے، ثبوت شامل کر سکتی ہے اور الارم چلا سکتی ہے:


*اثر براہِ راست جواب کے آپشن سے منسلک ہے: تین اختیارات route میں lab، habitat اور server کی قدریں لکھتے ہیں۔ متغیر کا فیلڈ اور نئی قدر حتیٰ کہ تنگ انسپیکٹر میں بھی علیحدہ رہتے ہیں۔*

[
  { "op": "set", "key": "terminal_decision", "value": "cut-power" },
  { "op": "inc", "key": "evidence", "amount": 1 },
  { "op": "toggle", "key": "alarm_active" }
]

اس طریقۂ کار میں ایک اہم حد موجود ہے: یہ کسی بھی فارمولا کا کیلکولیٹر نہیں ہے۔ آپ evidence * trust / 2 نہیں لکھ سکتے، کوئی حلقہ شروع نہیں کر سکتے یا اپنی فنکشن نہیں بنا سکتے۔ پیچیدہ رویہ کئی واضح مراحل سے تیار کیا جاتا ہے، اور منطق کی توسیع نئے قابلِ جانچ آپریشن runtime کے ذریعے کی جاتی ہے، نامعلوم کوڈ کے اجرا کے ذریعے نہیں۔

مصنف کے لئے یہ تھوڑا کم لا محدود ہے، لیکن کہانی متوقع رہتی ہے۔ ایک ہی اثرات کو شائع کرنے سے پہلے چیک کیا جا سکتا ہے، محفوظ کیا جا سکتا ہے، کھلاڑیوں کے درمیان ہم آہنگ کیا جا سکتا ہے اور ترقی کی لوڈ کے بعد دوبارہ چلایا جا سکتا ہے۔

کیوں منطقی نوڈ کے اندر ابھی تک ایک اور Flow نہیں ہے

تمام پیش گوئی کے باوجود موجودہ طریقے کا ایک ایماندار نقصان ہے: بغیر تجربے کے شخص کے لیے "متغیر - آپریٹر - قیمت" فارم پہلے ہی پروگرامنگ لگ سکتی ہے۔ اور جب پاس میں حالتوں کے گروہ اور کئی اثرات نمودار ہوتے ہیں، تو اعلانیہ ساخت Player کے لئے محفوظ رہتی ہے، لیکن ضروری نہیں کہ مصنف کے لیے آسان ہو جائے۔

ایسا لگتا ہے کہ ایک دن بصری نوڈز اور خود منطق کے اندر آنا فطری ہے۔ شرطوں کی فہرست کے بجائے، آپ بلاکس **اور**، **یا**، **نہیں** کو جوڑ سکتے ہیں، متغیرات کا موازنہ کر سکتے ہیں اور اقدار کو تبدیل کر سکتے ہیں۔ کاغذ پر یہ متن یا JSON کی نسبت زیادہ دوستانہ نظر آتا ہے۔

لیکن پھر میں حقیقی منظر نامہ تصور کرتا ہوں: مصنف ایک باب کے نقشے پر منطقی نوڈ کھولتا ہے، اور اس کے اندر ایک اور Flow اپنے نوڈز اور روابط کے ساتھ دیکھتا ہے۔ یہ گراف کے اندر گراف کی مانند ہے۔ یہ سمجھنا ضروری ہے کہ آپ اس وقت کہاں ہیں، کہانی کی سطح پر واپس کیسے جائیں اور دو Flow میں سے کس میں غلطی تلاش کریں۔ ایک نئے کے لیے، ایسی داخلی سطح موجودہ شکل سے بھی زیادہ خوفناک ہو سکتی ہے۔

اس لیے فی الحال سمجھوتہ کیا گیا ہے۔ کہانی کا راستہ بصری رہتا ہے، اور نود کے اندر شرائط اور اثرات مختصر، واضح فیلڈز میں دکھائے جاتے ہیں۔ یہ کام کرتا ہے، لیکن میں انٹرفیس کو حتمی حل نہیں سمجھتا۔ ممکن ہے بعد میں تیار ٹیمپلیٹس، مرحلہ وار ترتیبات اور بصری بلاکس کا زیادہ سمجھ میں آنے والا امتزاج آئے — ایسا جو واقعی پیچیدگی کو کم کرے، نہ کہ اسے ایک اور ایڈیٹر میں منتقل کرے۔

منطق صرف نقشے پر موجود نہیں رہتی

انٹرفیس مناظر ایک ہی حالت استعمال کرتے ہیں۔ ویجیٹ، پیغام، جواب کا انتخاب، کام، اطلاع یا میڈیا اسٹریم صرف showWhen کے مطابقت پانے پر ظاہر ہو سکتا ہے۔ میٹرک کی قدر کو متغیر سے جوڑا جا سکتا ہے، اور ویجیٹ کی حالت کے درمیان منتقلی تاخیر کے بعد، شرط کے مطابق یا کھلاڑی کے عمل کے بعد شروع کی جا سکتی ہے۔

مثال کے طور پر، بورڈ کمپیوٹر کی اسکرین اس طرح برتاو کر سکتی ہے:

1. شروع میں صرف لاک شدہ ٹرمینل نظر آتا ہے۔

2. کھلاڑی کے انتخاب کے بعد اثر terminal_unlocked = true کو سیٹ کرتا ہے۔

3. شرط جہاز کا منصوبہ اور نئے بٹن کھولتی ہے۔

4. بٹن دبا نے ویجیٹ کی حالت بدل دی اور evidence کو بڑھا دیا۔

5. جب evidence >= 3 ہوتا ہے، ایک چھپی ہوئی اطلاع ظاہر ہوتی ہے اور کہانی کے نئے مشن کی شاخ دستیاب ہو جاتی ہے۔

باب کا نقشہ، عام انتخاب اور انٹرایکٹو انٹرفیس تین مختلف نظام نہیں بناتے۔ وہ ایک ہی اسٹیٹ آبجیکٹ کو پڑھتے اور تبدیل کرتے ہیں۔ اس لیے ڈائیلاگ میں ملنے والا ثبوت انٹرفیس کا ایک عنصر کھول سکتا ہے، اور انٹرفیس کے اندر عمل اگلے منظر کو بدل سکتا ہے۔

یہیں پر declarative منطق واقعی پروگرامنگ کی طرح محسوس ہونا شروع ہوتی ہے۔ صرف فائلوں، فنکشنز اور ایونٹ بس کی بجائے، مصنف تاریخ کی سمجھ میں آنے والی چیزوں کے ساتھ کام کرتا ہے: حقائق، انتخاب، شرائط اور منتقلیاں۔

میں جان بوجھ کر ناپسندیدہ JavaScript کیوں نہیں شامل کرتا

اسکرپٹ ڈالنے کی صلاحیت کسی بھی نئی مکینک تک پہنچنے کا سب سے چھوٹا راستہ لگتی ہے۔ لیکن جیسے ہی شائع شدہ کویسٹ کو خودکار کوڈ چلانے کا حق ملتا ہے، پورے پروڈکٹ ماڈل میں تبدیلی آ جاتی ہے۔

یہ فیصلہ کرنا ضروری ہے کہ کون سے براؤزر API اس کوڈ کے لیے دستیاب ہیں، نیٹ ورک اور اسٹوریج کو کیسے محدود کیا جائے، لامتناہی لوپس کے بارے میں کیا کیا جائے، quest کو آف لائن کیسے منتقل کیا جائے، اسے مشترکہ کھیل میں کیسے ہم آہنگ کیا جائے، اور یہ کیسے یقینی بنایا جائے کہ پرانی پروجیکٹ اپ ڈیٹ کے بعد Player میں کام جاری رکھے۔

اعلامی قاعدہ کسی بھی فنکشن کے مقابلے میں زیادہ بورنگ ہے — اور بالکل اسی وجہ سے زیادہ قابل اعتماد ہے۔ اسے چلانے سے پہلے درست کیا جا سکتا ہے۔ یہ سمجھا جا سکتا ہے کہ یہ کونسی متغیرات پڑھتا اور لکھتا ہے۔ یہ محفوظ طریقے سے سلسلہ کے درمیان میں ترقی کو محفوظ کر سکتا ہے۔ quest کو براؤزر، خودمختار بلڈ اور مربوط Player میں یکساں طور پر انجام دیا جا سکتا ہے۔

یہاں محدود لغت منطق میں رکاوٹ نہیں ڈالتی، بلکہ اس کی حدود مقرر کرتی ہے۔ اگر واقعی کوئی مفید عمل ظاہر ہوتا ہے، تو بہتر ہے کہ اسے عمومی runtime میں شامل کیا جائے اور تمام مصنفین کو یکساں تصدیق شدہ رویہ دیا جائے، بجائے اس کے کہ ہر پروجیکٹ اپنا انجن ایجاد کرے۔

میٹھے کے طور پر — اپنا HTML اور CSS

اس کے ساتھ Romergo اب بھی اصل کوڈ کے لیے جگہ چھوڑ دیتا ہے وہاں جہاں یہ سب سے محفوظ ہے: عام منظر کی ترتیب میں۔

پراجیکٹ میں آپ HTML اور CSS پر ظاہری شکل کے لیے اپنی تھیم بنا سکتے ہیں اور اسے مختلف ابواب میں استعمال کر سکتے ہیں۔ HTML تیار شدہ علاقوں کی ترتیب کو مقرر کرتا ہے — جواب کی ونڈو، پورٹریٹ، کردار کا نام، متن، سوال اور منتخب کرنے والے بٹن۔ CSS ان علاقوں میں نمایاں تبدیلیاں کرنے کی اجازت دیتا ہے: فریم، پس منظر، کارڈ کی شکل، مارجن، ٹائپوگرافی اور اسکرین کے سائز پر ردعمل۔

تیار شدہ موضوعات **Standard**, **Minimalism**, **Brutalism**, **Romance** اور **Neon** تصدیق شدہ رینج بغیر دستی ترتیب کے دکھاتے ہیں۔ جب کوئی کسٹم تھیم Romergo بنایا جاتا ہے تو یہ منتخب ٹیمپلیٹ کو کاپی کرتا ہے: اس کے بعد اس کا HTML اور CSS ترمیم کیے جا سکتے ہیں اور فوری طور پر اصل Player پریویو میں چیک کیے جا سکتے ہیں۔


*یہاں کوئی کنسپٹ آرٹ نہیں ہے: بائیں طرف اصل CSS شامل موضوع Brutalism دکھایا گیا ہے، دائیں طرف وہی کوڈ موبائل پریویو میں نتیجہ دکھا رہا ہے۔ Desktop / Mobile سوئچر سے فوری طور پر ریسپانسیو اصول چیک کیے جا سکتے ہیں، اور صارف کا موضوع منتخب ٹیمپلیٹ کی کاپی سے کام شروع کرتا ہے۔*

لیکن بارڈر ویسا ہی رہتا ہے۔ صارف کے HTML میں <script>، ایونٹ ہینڈلرز، فارم، iframe اور بیرونی وسائل موجود نہیں ہیں۔ CSS بیرونی url() یا @import کو لوڈ نہیں کر سکتا۔ سین کے لازمی علاقے اپنی جگہ پر رہنے چاہیئیں؛ اگر ٹیمپلیٹ انھیں کھو دے، تو Player محفوظ ڈیفالٹ اسٹائل کی طرف واپس آتا ہے۔

یعنی HTML اور CSS اس بات کے ذمہ دار ہیں کہ **کہانی کیسا نظر آتی ہے**، جبکہ نوڈز، ویریبلز، شرائط اور ایفیکٹس اس بات کے لیے ہیں کہ **یہ کیسے کام کرتی ہے**۔

مجھے بالکل یہ تقسیم پسند ہے۔ مصنف قویست کو بصری طور پر باقیوں سے مختلف بنا سکتا ہے، لیکن اس کو مکمل کرنے کے باوجود یہ پھر بھی عام قابل جانچ runtime کا حصہ رہتا ہے۔ بیرونی سطح کو مکمل طور پر دوبارہ رنگ دیا جا سکتا ہے اور دوبارہ بنایا جا سکتا ہے، بغیر اس کے کہ ہر موضوع کو الگ پروگرام میں تبدیل کیا جائے۔

کوڈ کے بغیر کوڈ — منطق کی غیر موجودگی نہیں ہے

Romergo کا مقصد پروگرامنگ کی زبان کو تصویروں سے بدلنا نہیں ہے۔ گراف پیچیدہ ریاضی کے لیے موزوں نہیں ہے، اور ایٹمی اثرات کا مجموعہ خودکار نظام کے لیے ایک کمرشل انجن نہیں بنے گا۔

لیکن انٹریکٹو کہانی کے لیے زیادہ تر دیگر چیزیں درکار ہوتی ہیں: حقیقت کو یاد رکھنا، کاؤنٹر کو تبدیل کرنا، کوئی ورژن کھولنا، راستہ منتخب کرنا، انٹرفیس کی حالت دکھانا، واپسی کا نقطہ محفوظ کرنا اور یہ تمام فیصلے اگلے باب تک پہنچانا۔

اس کے لیے نوڈز اور ویریئیبلز سکرپٹس کا سادہ ورژن نہیں بلکہ کہانی کی سب سے براہِ راست زبان بن جاتے ہیں۔ مصنف کمپیوٹر کو کمانڈ نہیں دیتا بلکہ دنیا کے اسبابی تعلقات کو بیان کرتا ہے: کھلاڑی نے انتخاب کیا، حالت بدل گئی، کہانی نے ردعمل ظاہر کیا۔

اور اگر تھوڑا سا اصل کوڈ چاہیے، HTML اور CSS پھر بھی میٹھے میں انتظار کر رہے ہیں۔

ڈیولپمنٹ بلاگ پر واپس جائیں