यूज़र फीडबैक इकट्ठा कर हर दिन अपने-आप डेवलप और डिप्लॉय होने वाले वेब गेम की निर्माण कहानी

यूज़र के फीडबैक आइटम इकट्ठा करके अगले दिन डिप्लॉय किए जाने वाले कॉन्सेप्ट पर मैंने एक वेब गेम बनाया।
AI टूल्स से परिचित होने के लिए बनाया गया यह प्रोजेक्ट है, और GitHub भी पब्लिक है, इसलिए आराम से देख सकते हैं।
game: https://spiralwave.frogred8.dev
github: https://github.com/frogred8/SpiralWave

• प्रोजेक्ट ओवरव्यू और योजना
  • प्रेरणा और उद्देश्य: उन्नत AI टूल्स (Gemini आदि) का उपयोग करके vibe coding का प्रयोग करना और अब तक इस्तेमाल न की गई तकनीकों को लागू करते हुए वेब गेम डेवलपमेंट की कोशिश करना।
  • डेवलपमेंट दिशा: यूज़र की राय हर दिन अपने-आप लागू होने वाले 'समय-सीमित संसाधन-संग्रह' मिनी वेब गेम के रूप में तय किया गया।
• शुरुआती प्रोटोटाइप बनाना
  • मुख्य कॉन्सेप्ट: प्रतिस्पर्धा या नुकसान के बिना संसाधन इकट्ठा करने और skill tree बनाने वाला गेम।
  • AI का उपयोग: कागज़ पर बने स्केच को प्रॉम्प्ट में बदलकर TypeScript, Vite, Phaser आधारित बेसिक गेम स्ट्रक्चर 30 मिनट में लागू किया।
• जटिल लॉजिक लागू करने की सीमाएँ और सीधे समाधान
  • skill tree डेवलपमेंट: बुनियादी prerequisite skill लॉजिक AI से लागू कराया, लेकिन बीच के node को cancel करने पर नीचे के node भी chain की तरह cancel हो जाने वाले जटिल लॉजिक को AI हल नहीं कर पाया, इसलिए इसे सीधे खुद लागू किया।
  • test code छोड़ना: बार-बार बदलती डिज़ाइन और तेज़ डेवलपमेंट स्पीड के कारण जानबूझकर test code लिखे बिना आगे बढ़ा गया।
• बड़े पैमाने की refactoring और AI debugging की विशेषताएँ
  • UI अलग करने का काम: एक ही फ़ाइल के बहुत बड़ी हो जाने के कारण UI कोड अलग किया गया, लेकिन एकरूपता और संरचनात्मक संतोष कम रहा; साथ ही यह भी पुष्टि हुई कि बड़े कामों में प्रॉम्प्ट को मज़बूत करके दोबारा काम कराने का तरीका प्रभावी है।
  • execution order bug: refactoring के बाद आए runtime error (state update और UI display का क्रम उलट जाना) पर AI ने केवल guard code ही बढ़ा-चढ़ाकर जोड़ा; आखिरकार मानव डेवलपर ने flow समझकर सीधे दो लाइन कोड बदलकर इसे सरलता से हल किया।
  • AI की गलतियाँ काफ़ी हद तक इंसानी जैसी लगीं, जिससे एक अजीब-सा एहसास हुआ।
• Git auto commit और गाइड लागू करना
  • प्रॉम्प्ट गाइड बनाना: बार-बार निर्देश देने की झंझट कम करने के लिए tech stack और काम करने के तरीके को व्यवस्थित करने वाली guideline फ़ाइल (GEMINI.md) जोड़ी गई।
  • automation workflow: कोड का काम पूरा होने के बाद agent चलने का समय, निर्देश प्रॉम्प्ट, और काम का सारांश शामिल करने वाले commit message अपने-आप बनें, ऐसा सेट किया गया ताकि simple review का effort कम हो सके।
• auto update architecture डिज़ाइन और optimization
  • deployment तरीका बदलना: शुरुआती योजना के अनुसार हर 2 घंटे में real-time auto deployment करने का विचार runtime bug की ऊँची दर (लगभग 25%) के कारण build stability कम होने से छोड़ दिया गया, और अलग daily test build बनाकर deploy करने का फैसला लिया गया।
  • Cron workflow: node:cron का उपयोग करके 'फीडबैक संग्रह → परिष्करण → code generation → build और release बनाना → deployment' तक जाने वाली monolithic संरचना का automation process बनाया गया।
  • release note अपडेट: Docker instances के बीच server list फ़ाइल को common volume के रूप में share किया गया और 5 मिनट expiry cache लागू कर load नियंत्रित किया गया; साथ ही यूज़र के बहुभाषी अनुरोधों को अंग्रेज़ी में refine करके फिर दोबारा translate कर release note दिखाने के लिए लागू किया गया।
• डेवलपमेंट के दौरान हटाई गई सुविधाएँ
  • leaderboard राय recommendation (Like) फीचर (identifier की अनुपस्थिति और API call cost का बोझ)।
  • अधिक परिष्कृत skill data management tool (कल्पनाशक्ति की सीमा और सीधे JSON संशोधित करना अधिक प्रभावी होना)।
  • service-वार Docker distributed environment बनाना (operations और management complexity को कम से कम रखने के लिए 1 image में एकीकृत)।
  • यूज़र राय लागू होने पर email notification फीचर (signup के बिना mail collection की वैधता और दुरुपयोग का जोखिम)।
  • side ads जोड़ना (platform approval process की थकान और कम unit price के मुकाबले प्रभाव नगण्य)।
• AI आधारित डेवलपमेंट पर टिप्पणी
  • productivity और testing का trade-off: डेवलपमेंट implementation speed लगभग 10 गुना बढ़ गई, लेकिन verification (QA) में लगने वाला समय और थकान भी उसी अनुपात में बढ़ने की सीमा सामने आई।
  • code quality की विशेषताएँ: function unit स्तर पर पूर्णता ऊँची है, लेकिन readability कम होने से पूरे flow को समझना कठिन होता है, और जहाँ स्थानीय hard coding फ़ायदेमंद होती, वहाँ भी अनावश्यक रूप से भारी generalization pattern लाने की प्रवृत्ति देखी गई।

[recast7838]

दिलचस्प है।