गेम निर्माण की योजना
शुरुआत
मुझे लगता है कि यह भी बताना चाहिए कि आखिर गेम ही क्यों।
सच कहूँ तो कोई बहुत भव्य कारण नहीं है। AI की मदद से जल्दी code लिखने की बात अब आम हो चुकी है, और मुझे लगता है कि बहुत-से लोग इस बदलाव को पहले ही महसूस कर रहे हैं। Game development की शुरुआत असल में एक थोड़े विलासी सवाल से हुई: ऐसी कौन-सी चीज है जिसे मैं सच में एक shippable form में बदल सकता हूँ?
पहले यह ऐसा क्षेत्र था जहाँ सिर्फ development और operations resources को देखकर भी आसानी से कदम नहीं रखा जा सकता था। अब लगता है कि समय ऐसा हो गया है जहाँ बिना बहुत सोचे भी शुरुआत की जा सकती है। ऊपर से, ऐसा कुछ बनाना जिसे मैं खुद भी आनंद लेकर देख सकूँ, और ऐसा development करना जो नौकरी से ज़्यादा शौक के करीब लगे, उसमें भी एक अलग तरह का romance है।
प्रस्तावना उम्मीद से लंबी हो गई। इस पोस्ट में मैं उन game genres के बारे में बात करना चाहता हूँ जिन्हें मैं आगे बढ़ाना चाहता हूँ, और यह भी कि मैंने यह रास्ता क्यों चुना।
इम्प्लीमेंटेशन क्रम
पहला genre Story Quiz क्यों है
मैंने सबसे पहले Story Quiz को चुना। यह visual novel जैसी संरचना है जहाँ कहानी आगे बढ़ती है, और बीच में या अंत में deduction solve करके player experience हासिल करता है। इस genre को पहले चुनने की वजह सीधी है। मज़े का केंद्र साफ़ तौर पर story और deduction में है, जबकि operational burden को अपेक्षाकृत कम रखा जा सकता है।
यहाँ AI को हर जगह ले जाने की जरूरत नहीं है। उलटे, मुझे लगता है कि यही बात महत्वपूर्ण है। Story Quiz में मैं AI को grading और production support के करीब रखना चाहता हूँ, जबकि actual play experience इंसानों द्वारा तय किए गए rules और direction के ऊपर रहे। इससे operations बेकाबू नहीं होते, और साथ ही यह भी test किया जा सकता है कि क्या writers अपनी खुद की works publish कर सकते हैं।
यह अब भी शुरुआती चरण में है, लेकिन implementation direction पहले ही उसी ओर जा चुकी है। Manuscript को सीधे DB में डालने के बजाय, मैं Markdown manuscript → parsing → script enhancement → prompt generation → translation → import जैसी pipeline के जरिए story production के लिए AI को optimize करना चाहता हूँ।
source.md
-> parse-episode.py
-> script-doctor.py
-> prompt-gen.py
-> translate-story.py
-> /bo/story-quiz/games/import
Story Quiz कहाँ तक implement हो चुका है
मौजूदा repository के आधार पर देखें तो Story Quiz अब केवल idea stage में नहीं है। Player side पर game list और detail, session creation, resume, answer submission और epilogue lookup तक जुड़ी हुई APIs पहले से हैं। Backoffice side पर games, characters, phases, blocks, quizzes और background assets को अलग-अलग manage करने वाली structure भी मौजूद है। इसके ऊपर पूरा game data JSON में import, export करने का flow भी जुड़ चुका है, इसलिए इसे अब एक single game नहीं बल्कि publishable content format की तरह treat किया जाने लगा है।
महत्वपूर्ण बात यह है कि यह genre content data और play session को अलग रखते हुए बढ़ रहा है। एक game characters, phases, blocks, quizzes और background assets में बँटा है, जबकि session side पर current phase, current quiz, used hints, score और progress state अलग से manage किए जाते हैं। यानी author द्वारा work को edit करने वाला flow और player द्वारा उसे consume करने वाला flow पहले ही अलग layers में बँट चुके हैं।
Grading भी उसी philosophy का पालन करती है। Objective questions तुरंत grade हो जाते हैं, जबकि subjective questions KEYWORD_ONLY, LLM_ONLY, HYBRID, MANUAL जैसी strategies और backoffice review flow के जरिए संभाले जाते हैं। मेरे लिए महत्वपूर्ण बात यह नहीं है कि AI हमेशा सही हो। महत्वपूर्ण बात यह है कि केवल वही problems AI को दी जाएँ जिन्हें AI संभाल सकती है, और बाकी सब कुछ human review के लिए खुला रहे।
Publishing experiment के लिए delivery layer को भी अलग तरह से व्यवस्थित किया जा रहा है। Cover और card images public source path और preset-based thumbnails के जरिए deliver होती हैं, और Asset Studio को इस तरह रखा गया है कि Story Quiz और Mystery के character aur background assets एक साथ manage किए जा सकें। आखिरकार Story Quiz एक game भी है, और work production, review aur publishing pipeline का पहला test ground भी।
अगला कदम Mystery क्यों है
अगर Story Quiz author द्वारा design किया गया structured experience के करीब है, तो Mystery उससे कहीं ज्यादा जीवित genre है। Player केवल clues पढ़कर नहीं रुकता। वह roles लेता है, बात करता है, एक-दूसरे पर शक करता है, और situation को लगातार update करता है। यह काफ़ी niche genre है, लेकिन अगर यह सही बैठा, तो engagement कहीं ज्यादा गहरा हो सकता है।
और ठीक यहीं AI का भार काफ़ी बढ़ जाता है। Story Quiz में AI को सीमित रूप से इस्तेमाल किया जा सकता है, लेकिन Mystery में NPC reactions, interrogation, hint assistance और scenario reinforcement जैसी चीजें core experience के कहीं ज्यादा करीब हैं। मैं इस genre को दूसरा चरण मानता हूँ, जहाँ AI सचमुच play experience के अंदर प्रवेश करती है।
Mystery कहाँ तक पहुँचा है
क्योंकि मैं कई tracks पर एक साथ काम कर रहा था, इसलिए Mystery भी अब उस स्तर तक पहुँच गया है जहाँ एक छोटा prototype आँखों से देखा जा सकता है। Platform APIs में scenario lookup, session creation और invite code join, ready state, start, phase transition, notes, items और interrogation records पहले से जुड़े हैं। Sessions tickets, invite codes, player lists और state transitions के आधार पर manage किए जाते हैं, और starting items, starting notes तथा starting interrogations जैसे data भी अलग से जुड़े हुए हैं। यानी एक असली round चलाने लायक session model पहले ही खड़ा हो चुका है।
Production side और भी दिलचस्प है। Mystery में Draft Scenario नाम का backoffice flow है, और generation stages को CONCEPT → TRUTH → CHARACTERS → TIMELINE → CLUES → ROLEPLAY → WORLD_BUILDING → SYNOPSIS → PROLOGUE → EPILOGUE में बाँटा गया है। यह simple text generation नहीं है। यह answer, motive, character relationships, alibis, clues और role reactions को अलग-अलग nodes की तरह treat करने का तरीका है। मुझे लगता है कि यह structure बहुत महत्वपूर्ण है। Mystery में logical consistency stylish sentences से पहले आनी चाहिए।
Real-time dialogue side का skeleton भी पहले से मौजूद है। Game session chat APIs में character dialogue, SSE streaming responses और AI assistant chat शामिल हैं, और हर conversation interrogation history में store होती है। यानी यह ऐसी structure नहीं है जहाँ AI सिर्फ जवाब फेंकती है। इसे इस तरह design किया गया है कि conversation session के भीतर memory की तरह जमा हो। यह शायद वह क्षेत्र है जहाँ AI dependency सबसे तेज़ी से बढ़ेगी।
MMORPG को आखिरी चुनौती की तरह क्यों देखता हूँ
MMORPG मेरे लिए सिर्फ technical curiosity नहीं है। यह personal nostalgia से भी सीधे जुड़ा है। मैं यह test करना चाहता था कि Lineage जैसी अनुभूति, जिसे मैं लंबे समय तक खेलता था, आज के tools और structure के साथ कितनी दूर तक दुबारा बनाई जा सकती है। अगर यह आगे चलकर commercialize भी हो जाए तो उससे बेहतर क्या होगा, लेकिन उससे पहले असली सवाल यह है: इतने भारी genre को मौजूदा development method के साथ कितनी दूर तक धकेला जा सकता है?
मुझे यह भी लगता है कि MMORPG implementation में ऊपर बताई गई कई structures को worldbuilding, story और NPC setup के लिए reuse या adapt किया जा सकता है।
क्या MMORPG बहुत कठिन नहीं है
दिलचस्प बात यह है कि मौजूदा mmorpg-service में भी specs के आधार पर काफी code पहले से निकाला जा चुका है। मैं यह तक कह सकता हूँ कि आज के coding agents का स्तर लोगों की कल्पना से भी आगे है। सिर्फ कुछ prompts के साथ real-time MMORPG के client और server दोनों generate किए जा सकते हैं।
Game को broadly Lineage जैसी भावना के साथ implement करने की योजना है, और server side पर Netty-based gateway, session manager, Redis session synchronization, duplicate login handling, world और zone creation, tick scheduler, maps और pathfinding, AOI synchronization, combat broadcast, inventory और shop, तथा drop और spawn flows पहले ही implement होकर अलग service के रूप में deploy किए जा चुके हैं।
Runtime side पर GameWorld कई Zones को manage करता है और session तथा world indexes को अलग करके players को attach करता है। Monsters simple spawn objects की तरह नहीं, बल्कि IDLE, PATROL, CHASE, ATTACK, RETURN, DEAD जैसे FSM states वाले runtime entities की तरह manage किए जाते हैं। Trigger system trap damage, spells, dialogue और chat जैसी world reactions को सीधे execute करता है। इसके ऊपर world time और weather को अलग से persist करने वाला WorldContinuum भी है।
एक सीढ़ी बनाते हैं
Story Quiz कम operational burden के साथ work publishing को test करने वाला genre है। Mystery वह genre है जहाँ AI role-based deduction के रूप में play experience के अंदर प्रवेश करती है। MMORPG वह genre है जहाँ सबसे भारी real-time world में यह test किया जाता है कि मौजूदा development method कितनी दूर जा सकती है।
इसीलिए ये तीनों अलग-अलग projects नहीं हैं, बल्कि एक ही सीढ़ी के हिस्से हैं। मैं सबसे हल्के genre में पहले production pipeline और review structure को खड़ा करना चाहता हूँ, फिर AI interaction की density बढ़ाना चाहता हूँ, और आखिर में real-time world तक पहुँचना चाहता हूँ।
अंततः मैं जो देखना चाहता हूँ वह सरल है। सवाल यह नहीं है कि AI की वजह से games कितनी जल्दी बनते हैं। सवाल यह है कि AI को कहाँ रखना चाहिए ताकि game ऐसी चीज बनी रहे जिसकी जिम्मेदारी इंसान आखिर तक ले सके। Omnilude में games बनाना इस समय मेरे लिए उस सवाल को सबसे गंभीर ढंग से test करने का तरीका है।
समापन
पिछले posts में मैंने coding style के बदलाव और backend structure के बारे में बात की थी। यह लेख उस सवाल का जवाब ज्यादा है कि उसी structure के ऊपर मैं वास्तव में किस तरह के games बना रहा हूँ, और किस क्रम में बना रहा हूँ।
अगली बार मैं फोकस को और संकरा करना चाहता हूँ, और या तो यह अधिक ठोस रूप से लिखना चाहता हूँ कि Story Quiz की publishing pipeline वास्तव में कैसे चलती है, या फिर यह कि Mystery के लिए AI interrogation structure को मैं कैसे design कर रहा हूँ।