تحويل «دورة حياة الكيان البرمجي» إلى Visual Novel قابلة للّعب: مراجعة شاملة لتكرار كامل
هذه المرة لم يكن الأمر مجرد “إلباسه واجهة قارئ”، بل تحويل الملف النصي الكامل 软件体的生命周期.md فعلاً إلى رواية بصرية بأسلوب GALGAME ياباني قابلة للّعب، مع الالتزام منذ البداية وحتى النهاية بقيْد صارم: لا يُسمح إلا بالزيادة على النص الأصلي لا النقصان، ولا يجوز إسقاط أي تفصيلة نصية.
لم تكن العملية إصدارًا واحدًا نهائيًا، بل كانت نمطًا تقليديًا من “نجعله يعمل أولًا، ثم نزيل الإحساس بالنشاز تدريجيًا” عبر تكرارات متواصلة. وبالنظر إلى الوراء يمكن تقسيمها تقريبًا إلى المراحل التالية.
1. نقطة البداية واضحة جدًا: ليست اقتباسًا مختصرًا بل تحويلًا كاملًا محافظًا على الأصل
كان الهدف من البداية صارمًا:
- مصدر السيناريو هو الملف المحلي
软件体的生命周期.md - يجب إدخال النص كاملًا إلى اللعبة
- لا يجوز—بسبب تحويله إلى لعبة—حذف النص الأصلي وتحويله إلى ملخص أو نسخة حوارية أو نسخة رواية خفيفة
- يمكن تعزيز طريقة العرض، لكن محتوى النص نفسه لا يجوز تقليصه
لذلك لم تكن الفكرة الجذرية للمشروع “كتابة نص VN”، بل “تقطيع النص الأصلي إلى بنية فقرات مناسبة لتقدّم الرواية البصرية، مع الإبقاء على النص الأصلي كاملًا قابلًا للمراجعة”.
ولذلك ترى أن النظام بأكمله لاحقًا—مثل تنقل الفصول، عرض النص الأصلي كاملًا، تحديد الفقرات، المراجعة، حفظ التقدم—يدور حول هذا الشرط ويخدمه.
2. النسخة الأولى تعمل، لكنها لا تبدو كرواية بصرية
بعد الانتهاء من النسخة الأولى، لم تكن المشكلة الكبرى نقص وظائف، بل أن الروح ليست صحيحة.
رغم أنه صار ممكنًا تقدّم النص وعرض المحتوى وتقطيع الفقرات، إلا أن الواجهة بدت أقرب إلى قارئ صفحات مع لوحة تحكم، لا إلى GALGAME يابانية. وكان رد فعل المستخدم مباشرًا: “هذه الواجهة ليست صحيحة إطلاقًا، اجعلها UI على طريقة galgame اليابانية.”
لذا كان محور أول إعادة بناء ليس إضافة وظائف، بل تصحيح اللغة البصرية أولًا:
- فصل طبقة المسرح وطبقة المقدمة وطبقة صندوق النص من جديد
- إعادة تصميم عنوان الفصل وصفحة اسم الكتاب وبطاقات الانتقال بأسلوب الرواية البصرية
- تحويل صندوق النص إلى صندوق حوار VN مثبت على المسرح بدل بطاقة ويب عادية
- جعل منطقة كلام الشخصية ولوحة الاسم وشريط التقدم وزر التقدّم أقرب إلى تخطيط الرواية البصرية اليابانية
أهمية هذه الجولة هي: أن يبدو كأنه لعبة أولًا، ثم نكمل تفاعلات اللعبة التي ينبغي أن تكون موجودة.
3. استكمال رسومات الشخصيات، وتطور المسرح من “وجود صورة” إلى “يشبه المسرح”
طرح المستخدم مطلبًا واضحًا: كل شخصية يجب أن يكون لها رسم (立绘).
لذلك لم نكتفِ بوضع صور لبضعة أبطال، بل بنينا نظام رسومات الشخصيات فعلًا:
- إدارة بيانات رسومات الشخصيات بشكل مستقل
- لكل شخصية تموضعها على المسرح وأسلوب عرضها
- دعم تموضع شخصية واحدة، شخصيتين، وعدة شخصيات على المسرح
- عند حديث شخصية تُبرز، والشخصيات المستمعة تُخفَّف
- نص الحوار يدعم ألوانًا تقابل كل شخصية
لكن هذا الجزء مرّ أيضًا بعدة جولات صقل. ظهرت عدة مشاكل نموذجية:
- بعض الشخصيات لا يظهر منها إلا النصف السفلي
- صندوق النص كبير جدًا ويحجب المسرح
- عند وجود عدة شخصيات معًا يبدو المسرح مكتظًا
- في صور مصغرات الحفظ، كثيرًا ما تُقصّ الرؤوس أو لا يبقى إلا الأرجل
ثم جاءت سلسلة من التعديلات لمعالجة ذلك:
- تعديل ارتفاع المسرح ومنطق تحجيم الرسومات
- التفريق بين أحجام رسومات human / digital / entity
- السماح بإزاحة المسرح أفقيًا وعموديًا وتكبيره/تصغيره
- إعداد توزيع slot أكثر منطقية لعدة شخصيات على المسرح
- إصلاح تركيب صور المصغرات قدر الإمكان للحفاظ على الشكل الكامل وتجنب قصّ الشخصيات بشكل سيئ في بطاقات الحفظ
بعد ذلك لم يعد الأمر “بضع صور موضوعة فوق بعضها”، بل بدأ يمتلك إحساسًا واضحًا بالمسرح.
4. حرية صندوق النص كادت تتحول إلى نظام تخطيط قابل للضبط
في هذا المشروع، كان صندوق النص أكثر جزء يراقبه المستخدم بشدة، وهو أيضًا أكثر جزء تم تعميقه لاحقًا.
قدّم المستخدم سلسلة مطالب شديدة التحديد:
- دعم تخصيص موضع صندوق النص
- دعم تغيير الحجم من الزوايا والحواف
- دعم ضبط الشفافية
- دعم سرعة نص تصل لأقصاها حتى يظهر فورًا
- دعم ألوان نص مختلفة حسب الشخصية
- لا يجوز قفل صندوق النص بعرض كامل
- يمكن جعله أضيق أو أعرض
- يجب ألا يحجب الرسومات دائمًا
- في التخطيط الزمني (التموضع الأيمن) يجب وضعه في أقصى اليمين
لذلك لم ننتهِ بمجرد “سحب صندوق النص”، بل جعلناه تدريجيًا نظام تخطيط كامل:
- دعم سحب صندوق النص لتحريكه
- دعم التحجيم بثماني اتجاهات عبر الحواف الأربع والزوايا الأربع
- دعم ضبط العرض والارتفاع بحرية
- دعم تخطيطات جاهزة: وسط، أسفل يسار، أسفل يمين، أعلى يسار، أعلى يمين
- دعم الشفافية وحجم الخط وتباعد الأسطر
- دعم حفظ التخصيص ضمن التقدم واستعادته لاحقًا
- تغيّر موضع صندوق النص يحرّك المسرح/يتجنّبه لتقليل حجب الشخصيات
هنا حصل تحول مهم:
في البداية، رغم دعم تغيير الحجم، بقيت مشكلة “أضيق وضع ما زال بعرض كامل” و”يبدو بصريًا كأنه مقفل”. لاحقًا خُصصت إصلاحات لعرض الحد الأدنى، والعرض الافتراضي، ومنطق الحجم المخصص، حتى تحققت حرية التحويل التي أرادها المستخدم فعلًا: تحوّل حر لا “يبدو قابلاً للتعديل لكنه عمليًا لا يتحرك”.
5. العناوين، انتقالات الفصول، ومعلومات الحجز: حذف زائد بعد زائد
اتجاه تكراري واضح آخر كان إزالة عناصر UI الزائدة التي تقطع القراءة تدريجيًا.
اشتكى المستخدم من أمور نموذجية:
- هل يمكن أن تختفي هاتان الخانتان في أعلى اليسار تلقائيًا دون ترك حجز
- عنوان الكتاب وعنوان “الفصل x” الكبير يظهر مرة واحدة فقط عند تبديل الفصل، لا أن يقفز في كل جملة
- لا تُبقِ كتل الشرح معلّقة على الشاشة دائمًا
فأجرينا عدة جولات لضبط “يظهر فقط عندما يجب أن يظهر”:
- تعديل صفحة اسم الكتاب/عنوان الفصل ليظهرا لفترة قصيرة فقط عند تبديل فصل حقيقي
- إخفاء العناوين الكبيرة وخانات الحجز تلقائيًا أثناء القراءة العادية
- في المشاهد بلا رسومات لم نعد نعرض بطاقة حجز فارغة كبيرة
- شريط HUD العلوي يتلاشى تلقائيًا بعد الخمول
- تلميحات القراءة على سطح المكتب تنسحب تلقائيًا بعد الخمول
- تلميحات السحب ومقابض التحجيم تضعف أثناء القراءة الهادئة وتعود عند التفاعل
- وسوم أسفل الرسومات تتلاشى تلقائيًا في وضع القراءة الهادئ، وتضيء مجددًا عند التفاعل أو تغيّر الشخصية
كل هذه التعديلات كانت تفعل الشيء نفسه:
خفض إحساس “واجهة أداة”، ورفع إحساس “إخراج قراءة/عرض”.
6. استكمال أساليب التقدّم، لتصبح التجربة أقرب لرواية بصرية حقيقية
إلى جانب التقدم الأساسي، استكملنا عادات تفاعل VN الشائعة بشكل جيد:
- النقر خارج صندوق النص للتقدّم
- عجلة الفأرة: التالية/السابقة
- المسافة، Enter، أسهم الاتجاه للتقدّم
- التشغيل التلقائي
- تخطي المقروء
- زر أيمن أو اختصار لإخفاء الواجهة
- الضغط المطوّل على منطقة فارغة لتبديل إخفاء الواجهة (على الهاتف)
وهنا أيضًا لم يكن الأمر صحيحًا من أول مرة.
مثلًا، إصلاح حديث كان لمشكلة: عندما تُفتح عناصر التحكم تعمل العجلة، لكن بعد طيّ التحكم تصبح العجلة غير فعالة. السبب أن منطقة النص اعتُبرت خطأً “منطقة يجب اعتراض التمرير فيها”. بعد تعديل هذا الحكم، أضفنا أيضًا عودة تلقائية لضمان أنه لاحقًا “بعد طيّ التحكم، وضع مؤشر الفأرة فوق نص المتن يظل يسمح بالتقدم/الرجوع عبر العجلة”.
هذه الإصلاحات صغيرة لكنها حاسمة، لأنها تحدد مباشرة هل المنتج يشبه VN فعلًا يمكن قراءتها طويلًا أم لا.
7. الحفظ، المراجعة، عرض النص الأصلي: ليست وظائف ثانوية بل وظائف أساسية
لأن المشروع اشترط منذ البداية “حفظ الأصل”، فبعض الميزات التي تعد إضافات في الألعاب عادةً أصبحت هنا وظائف رئيسية:
- حفظ تلقائي
- حفظ سريع / تحميل سريع
- حفظ يدوي متعدد الخانات
- عند التحميل تُستعاد مواضع صندوق النص وأبعاده وتفضيلات القراءة
- مراجعة المقاطع الأخيرة
- تنقل الفصول
- عرض النص الأصلي مع الفهرس
- الرجوع من فقرة اللعبة إلى رقم سطر النص الأصلي وتحديده
وخاصة “عرض النص الأصلي” و”ربط الفقرة برقم سطر الأصل”، فهما في الواقع يجعلان “تحويله إلى لعبة” أمرًا شفافًا:
لست مضطرًا للتقدم فقط داخل طبقة اللعبة؛ يمكنك في أي وقت العودة إلى بنية النص الأصلية الكاملة لترى بالضبط إلى أي سطر وصلت.
8. صور مصغرات الحفظ وتفاصيل وضع القراءة: كلها صقلتها تعديلات دقيقة متكررة
في المراحل اللاحقة، ما استهلك الوقت لم يعد الوظائف الكبيرة، بل كمًا هائلًا من التفاصيل التي “ستنفر المستخدم من النظرة الأولى، لكنه قد لا يستطيع وصفها بجملة واحدة”.
مثل:
- قصّ رأس الرسم في صورة الحفظ المصغرة
- وسوم أسفل الرسومات تشبه معلومات تصحيح
- تلميحات صندوق النص ومقابض السحب بارزة جدًا
- HUD العلوي إن بقي دائمًا يخطف الانتباه
- عند وجود عدة شخصيات تتشتت عين القارئ بسبب UI
هذه المشاكل غالبًا لم تُحل بإضافة وظائف، بل بالتحكم في الإيقاع:
- ما الذي يجب أن يبقى ظاهرًا دائمًا
- ما الذي يجب أن يتلاشى
- ما الذي يظهر فقط عند hover
- ما الذي ينبغي أن يظهر مؤقتًا فقط عند تبدّل الحالة
بعد هذه التعديلات، يصبح الإحساس واضحًا أنه ينتقل من “صفحة ويب مليئة بالوظائف” إلى “رواية بصرية يمكن قراءتها بهدوء”.
9. التحقق الآلي هو مفتاح استمرار التكرار في المرحلة المتأخرة
قال المستخدم جملة كانت واضحة جدًا: “فقط واصل تعزيز وتحسين والتحقق من وظائف خدمتنا بنفسك.”
لذلك لاحقًا لم أعد أعدّل المشهد فقط، بل استكملت سلسلة تحقق آلي أيضًا. في المشروع توجد مجموعة سكربتات تحقق واجهة على نمط Playwright لإعادة فحص هذه النقاط الأساسية مرارًا:
- هل العنوان يظهر/يختفي في الوقت المناسب
- هل صندوق النص الافتراضي يحجب المسرح
- هل السحب/التحجيم/الالتصاق لصندوق النص تعمل طبيعيًا
- هل الموضع والحجم المخصصان يُحفظان ويُستعادان
- هل HUD العلوي يتلاشى تلقائيًا
- هل تلميحات القراءة ومقابض السحب تضعف عند الخمول
- هل درج الحفظ والحفظ التلقائي وصور الحفظ السريع المصغرة تعمل
- هل عدة شخصيات على المسرح تتجاوز الحدود على سطح المكتب/الهاتف
- هل الضغط المطوّل لإخفاء الواجهة على الهاتف يعمل
- هل التقدم بعجلة الفأرة بعد طيّ التحكم يعمل
هذا يعني أن التحسينات اللاحقة لم تعد “نصلح A ونراهن ألا ينكسر B”، بل يمكن التعديل مع الرجوع والاختبار.
هذه القدرة مهمة جدًا لمشاريع UI عالية التفاعل؛ وإلا فغالبًا ما يحدث في المراحل المتأخرة “أصلحت A فانفجر B”.
10. الحالة الحالية للمشروع
حتى الآن، مشروع GALGAME الخاص بـ《软件体的生命周期》 صار يمتلك قابلية لعب وقراءة متكاملة نسبيًا:
- الاحتفاظ بالنص الأصلي كاملًا، لا اقتباسًا ملخصًا
- واجهة رئيسية بأسلوب GALGAME ياباني
- إدماج رسومات جميع الشخصيات
- ألوان نص مختلفة حسب الشخصية
- انتقالات تبديل الفصول وعرض صفحة اسم الكتاب
- سحب صندوق النص وتحجيمه بحرية وضبط شفافيته
- سرعة نص تدعم الظهور الفوري
- النقر خارج صندوق النص للتقدّم
- عجلة الفأرة: السابقة/التالية
- تشغيل تلقائي، تخطي، إخفاء UI
- حفظ تلقائي/سريع/يدوي
- مراجعة، تنقل الفصول، عرض النص الأصلي
- تكييف لسطح المكتب/الهاتف
- عدة جولات صقل لإزالة “إحساس الأدوات”
- سكربتات تحقق آلي للرجوع المستمر
إذا كان الهدف الأول “تحويل ملف md إلى لعبة”، فالوصف الأدق الآن هو:
حوّلنا نصًا طويلًا كاملًا إلى نظام رواية بصرية قابل للقراءة، قابل للّعب، قابل للتتبّع والرجوع، وقابل للصقل المستمر.
11. أكثر ما كان ممتعًا في هذا المشروع
بالنسبة لي، أكثر ما كان ممتعًا في هذا التطوير ليس “صناعة صفحة GALGAME”، بل أن العملية كلها توضح بشكل نموذجي حقيقة واحدة:
غالبًا ما يصبح الشيء “بشكل لائق حقًا” ليس لأن النسخة الأولى تكدّس كل الوظائف، بل لأن المستخدم يواصل الإشارة إلى “ما الذي لا يبدو صحيحًا”، ثم نزيل هذا الإحساس بالنشاز جولة بعد جولة.
تغذية المستخدم الراجعة كانت شديدة التحديد، وكثير منها لم يكن مجرد “حسّنها قليلًا”، بل:
- هنا يحجب الصورة
- لماذا هذا مقفل بعرض كامل
- لماذا هذا يقفز في كل جملة
- هذا لا يظهر إلا النصف السفلي
- لماذا لا يختفي أعلى اليسار تمامًا
- لماذا تتعطل عجلة الفأرة بمجرد طيّ التحكم
هذه النقاط المحددة جدًا التي “لا تبدو مريحة للعين” هي ما دفع المشروع في النهاية من “يعمل” إلى “معتبر”.
لو استمر العمل لاحقًا، فأرى أن اتجاهات الصقل الممكنة تشمل:
- توحيد أكبر لأسلوب رسومات الشخصيات
- إخراج أدق للفصول ونظام BGM/SE
- نظام CG/تبديل خلفيات أكثر اكتمالًا
- قدرة أقوى على تنسيق السكربت
- طريقة نشر/تغليف أكثر رسمية
لكن ضمن هذه الجولة الحالية، لم يعد هذا demo، بل نموذج VN أولي مكتمل إلى حد كبير وقابل للتكرار المستمر.